【性能调优】场景资源分帧实例化：加载卡顿的帧预算控制

实战应用：用在哪里

进场景瞬间的卡顿来自一次性实例化大量节点：一个面板 50 个控件、一张地图 300 个物件，同一帧全部 create 就是卡顿来源。分帧实例化把创建工作按帧预算切片，每帧只创建一部分，玩家看到的加载从"卡一下"变成"渐进出现"。适用于：大面板打开、场景切换、批量列表渲染。

帧预算控制的实现

每帧设定预算（如 3ms），循环创建节点直到预算耗尽，剩余工作延到下一帧：

local task = { list = nodes, idx = 1, budget = 0.003 }

function task.step()
    local frameStart = os.clock()
    while task.idx <= #task.list do
        createNode(task.list[task.idx])
        task.idx = task.idx + 1
        if os.clock() - frameStart > task.budget then
            return false                    -- 预算用尽，下帧继续
        end
    end
    return true                             -- 全部完成
end

task.step 挂到统一心跳调度器每帧调用，返回 true 时注销自身。预算数值按机型分档：高配 5ms、中配 3ms、低配 1.5ms。

实例化的三项降耗

创建本身就是大头，三项降耗让预算内能创建更多节点：控件模板预克隆（clone 比逐属性 set 快 2 倍以上）；纹理提前异步加载（创建时纹理已在缓存，省去同步读盘）；层级扁平化（节点树每深一层，创建与遍历成本都上升）。三项配合后，50 控件的面板实例化总耗时从 18ms 降到 7ms，一个半帧即可完成。

体验细节

分帧创建的渐进出现要有视觉设计：加载中显示占位底图或骨架屏，避免"控件逐个蹦出来"的突兀感。进度反馈按已完成比例更新进度条。全部完成后执行一次整体回调（播放入场动画、开放交互）。分帧技术不改变总工作量，改变的只是"把卡顿摊薄到玩家无感"——这是所有分帧类优化的共同思路。

分帧创建的顺序按玩家视线重要性排：先创建屏幕中心区域与高价值控件，边缘与装饰节点最后创建。玩家注意力集中的区域先就位，渐进加载的过程就不会被感知为缺内容。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。