完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn
同样是打开一个面板，有的秒开，有的掉帧——差别通常不在逻辑代码，而在渲染层。Cocos 系引擎每帧提交的绘制命令（DrawCall）数量、纹理切换次数、UI 树深度，共同决定界面开销。一次 DrawCall 就是 CPU 向 GPU 下达的一次绘制指令，几百次还撑得住，上千次就开始掉帧；每切换一张纹理，还要付出重新绑定资源的代价。界面卡顿排查，先查这两项。
引擎自动合批的前提非常苛刻：相邻的节点使用同一张纹理、同一份材质，且中间不能被不透明节点打断。所以散图直接拖进界面的做法天生反合批——十个图标十张纹理，十次绑定十次绘制。UI 合图（图集）就是解药：把面板里所有小图打包进一张 2048×2048 大图，所有图标共享同一纹理，绘制命令天然合并。
实操规范：按"面板"而非按"类型"打图集——同一个面板里出现的图必须同图集，跨面板共用的通用件（按钮底、边框、货币图标）进公共图集。合图后用引擎的渲染统计面板对比 DrawCall 数，从 400 降到 60 是常见幅度。特别提醒：加了自定义 Shader 的控件会打断合批，一个面板里至多一两处，别给普通图标乱穿衣服。
层级过深。UI 树每层都要做变换计算与遍历，策划堆出来的十层嵌套容器是常客。把深层布局拍平、隐藏节点用可见性开关而非反复创建销毁，能同时降低构建耗时与渲染开销。
内存泄漏。Cocos 的节点树是引用计数世界，两个经典泄漏点：从场景里 removeChild 但别处还握着引用；注册了事件监听却从不注销，闭包把整棵界面树抓在手里。排查看两个地方——切场景后内存水位是否回落、同一面板反复开关内存是否阶梯上涨。规范是"谁注册谁注销"，界面基类统一在 onExit 里反注册全部监听。
接到界面卡顿反馈，按固定顺序走：先看渲染统计的 DrawCall 与纹理切换（八成是图集问题）；再查 UI 树深度与隐藏节点数量；然后测开关面板的内存曲线定位泄漏；最后才怀疑逻辑代码。顺序对了，大部分问题十分钟内现形；顺序错了，会在错误日志里浪费一下午。
