第 5 章 调度、优化与出厂验收

第 5 章 · 调度、优化与出厂验收

本章要回答的三个问题：游戏在自己电脑上满帧，为什么装到手机上就掉成幻灯片？资源越堆越多，加载越来越慢，内存隔三差五崩溃，仓库该怎么管？最后一公里——多人协作、多平台打包、上线后的崩溃，各自的值班要点是什么？本章是值班室的调度科与质检科。

为什么会有这一章

前四章的工作是"把游戏做出来"，本章的工作是"把游戏做成能交付的产品"。两者隔着一道著名鸿沟：开发机上一切美好，真机上帧率跳水、内存爆炸、安装包超限、上线后崩溃率飙升。鸿沟的成因不神秘——开发机性能过剩掩盖了浪费，编辑器加载资源太宽容掩盖了仓库失序，单人开发掩盖了协作规范缺失。本章就是把这三类掩盖的账全部翻出来。

本章五节按"先内后外"排列：性能与对象池是向内省账，Addressables 是仓库改制，版本控制是建立交接班制度，平台发布与排查是出厂质检，最后的实战项目把全书内容串成一次完整的值班演练。读到本章，建议手边就有那个一路跟着做的平台跳跃项目——每一节都能直接在它身上落地。

读完能解决什么

• 用 Profiler 定位一个真实掉帧点，区分 CPU 逻辑瓶颈与渲染瓶颈；
• 判断哪些对象该进对象池，写出线程安全意义上的"借还式"池子；
• 用 Addressables 把资源改成按需加载，说出它与 Resources 的本质区别；
• 建立一套团队 Git 规范：分支模型、场景合并的规避策略、冲突处理流程；
• 完成 Android 与 WebGL 两个平台的打包，并按清单排掉发布后的常见崩溃。

各节怎么分工

本章全景：从内省到出厂的五道工序

一句金句：优化不是玄学是查账——每一毫秒都有出处，每一份内存都有流向，Profiler 就是账本。

出厂验收的检查流

值班室问答：新手高频三问

问：优化从哪里下手？感觉到处都可能有问题。
从测量下手，从不从感觉下手。Profiler 里耗时排行第一名的函数，就是你唯一需要关心的地方；把它销掉，再看新的第一名。优化的收益永远是"排行最前面那一项"的函数，跟改动的难易程度无关。

问：Addressables 概念太多，分组、标签、地址，先搞哪个？
先搞分组，其他都是辅助。分组决定"这批资源什么时候进内存、进不进首包"，是供货策略本体；地址是取货单号，标签是批量操作的快捷方式。用三五个组把资源按加载节奏划开，剩下的功能用到再学。

问：包打出来了，编辑器里没问题，真机白屏，查哪里？
先查打包场景列表是否包含启动场景（编辑器直接运行不走这个列表），再查控制台有没有脚本编译错误被打包流程忽略，最后看目标平台的图形接口与压缩纹理是否被真机支持。三处按序排查，覆盖绝大多数"编辑器正常、真机异常"的病例。

先决条件

• 前四章的项目：有真实玩法、有 UI、有粒子，才有账可查；
• 愿意真机测试：性能与发布两节的结论必须在真机上验证，编辑器数据只能参考；
• Git 基础操作（5.3 节会补协作纪律，但不从零教命令）。

本章的阅读方式也和前四章不同：它更像一本维修手册，适合带着当前项目的具体问题来查。正在掉帧就先读 5.1，资源加载慢就翻 5.2，准备打包直接看 5.4。但 5.5 的实战演练例外——它假设你按顺序读完前四章，然后一口气完成总装，那种"零件全部备齐、拧成一台整机"的体验，值得专门留一个整块时间。

往下走到哪

本章结束于一次完整出厂：优化过的、资源按需加载的、打包到真机可玩的作品。5.5 节的实战项目是全书的毕业典礼，也预留了继续深造的接口——网络对战、DOTS 大规模实体、XR 交互，都是这间值班室可以加盖的新楼层。