9.2 打包 Cook 与平台发布

9.2 打包 Cook 与平台发布

本节摘要：Cook 把内容转换成目标平台格式，打包把引擎与内容装配成发行产物，两者是"编辑器工程"到"玩家成品"的必经工序。本节拆解各阶段做什么、配置怎么区分开发版与发布版、平台合规要提前备什么料。

编辑器里能跑，不等于能发出去

团队在编辑器里跑得行云流水的项目，第一次打包常见四种翻车：包体比预期大出数倍、启动卡在黑屏半分钟、某个远程引用的资产在成品里直接丢失、某个平台提交被打回因为合规材料不全。四类事故共同的根源是同一个：发布管线不是"导出按钮"，是一条有自己规则的工序链——Cook 阶段的格式转换、引用完整性检查、平台特定配置，每一环都可能翻出编辑器里看不见的问题。理解这条链，才能在立项时就把"发布友好"做进日常，而不是发版前抢救。

本节在知识体系中的位置：它是交付主线的核心节，依赖第四章的引用体系（Cook 的"带哪些内容"完全由引用链决定），并为 9.3 的版本迁移提供验证终端——迁移做完，最终要在打包成品上验收。

工序链：Cook 与打包各做什么

Cook 是内容的目标平台转换：贴图按目标硬件的压缩格式重压、着色器按目标图形接口预编译、蓝图字节码化。它慢——大工程首次 Cook 以小时计——但它是一次付清的投资，成品不再带着源格式与编译开销。Cook 的范围判定规则只有一条：从默认地图与配置出发、沿引用链可达的资产。这条规则解释了大部分体积事故：被硬引用拖进来的远方资产（4.2 的案例）、挂在项目设置里的"以防万一"的地图、目录里从未被引用却因为目录级打包规则混进来的内容——体积审计就是从引用链找不该上车的乘客。

打包在 Cook 之后：把引擎运行时、平台层与 Cook 后的内容装配成发行产物，按配置（开发、发布）裁剪调试能力。开发配置保留日志与调试通道，给内部测试；发布配置关闭控制台、压缩体积、开启平台合规要求的所有约束，给玩家。两者必须都出、分开验收——只在开发配置上测过的项目，发布配置里常会翻出"调试分支里的代码副作用"与"控制台命令被滥用"两类暗伤。

发布工序链全景

两道前置校验值得做成日常习惯而非发版动作：资产校验（命名规范、引用完整性、贴图格式）在提交阶段就跑，问题在产生时拦截；体积审计每次大版本跑一遍，对比上次增量，异常膨胀当版本查清——带着"上次为什么多了几百兆"的疑问发版，比事后追查便宜得多。

配置与平台：三张核对单

发布前的核对单按三张准备。内容单：默认地图清单正确、按平台分级的画质档位（第九章各系统的档位在此落地）、分平台资源裁剪（高清贴图只进高配平台包）。代码单：源码构建与预编译二进制的授权与一致性确认、插件在目标平台的可用性清单、崩溃上报与日志通道按配置开关。合规单：平台方要求的内容分级材料、隐私条款入口、目标平台的签名与证书（桌面平台较简、移动与主机平台材料多、周期长）。三张单的共同精神是"提前"：签名证书的申请周期、分级材料的审核周期都不听项目排期的指挥。

案例：把首次打包从四小时压到一小时

背景：独立团队首次给合作项目出正式包：Cook 加打包四小时，且包体超标八吉字节，迭代几乎无法进行。目标：既压时间又压体积。

操作：第一步，体积审计：用打包日志与资产审计工具列出体积前列资产，发现三类异常——一套从未启用的完整关卡模板被目录级规则打进了包、一批四倍分辨率的原始贴图没有走平台压缩、演示用的全部语种音频全量打包。第二步，逐类处理：关卡的目录规则改为按引用打包，贴图重设平台压缩并限制最大分辨率，音频按目标语种裁剪。第三步，时间压缩：开启共享材质着色器缓存与增量打包（日常迭代只 Cook 变更部分），把出完整包的动作限定在版本节点。第四步，双配置验收：开发配置测功能，发布配置测体积、启动时间与帧率，记录三项基线数字。

结果：包体从超标八吉降到目标内，日常增量打包十几分钟，完整包一小时内；启动黑屏时间同步缩短——因为砍掉的正是一大块启动即加载的内容。

解读：这个案例的两笔账都很典型。体积账的三类异常各有出处：目录级打包规则是"图省事"的产物，绕过了引用链这个唯一合理的边界；未压缩贴图是 4.1 导入规范欠的账；全语种音频是内容管理欠的账——发布事故很少是新问题，多半是日常纪律的期末考试。时间账的核心是区分"日常迭代包"与"版本完整包"两种产物，增量机制服务前者、完整流程服务后者，用一条管线包打两种需求是自我折磨。变式一：出 8.2 的专用服务器产物——同一管线换服务器目标，无头配置，验收重点是启动与迁移语义。变式二：多平台分发包——按平台出不同画质档位与裁剪清单，核对单的内容单一节就是为它准备的。

常见坑：把"发布配置打不出包"留到发版前一晚才第一次尝试。发布配置会暴露与开发配置不同的问题集（合规、调试代码副作用、平台约束），第一次发布配置的打包应该排在里程碑早期，哪怕只出一个能跑的包。

本节要点回顾

• Cook 是付清一次的平台转换投资，范围由引用链决定，体积审计从引用链找异常乘客。
• 开发与发布双配置都要出，调试分支的副作用只在发布配置里现形。
• 三张核对单：内容、代码、合规，共同精神是提前——证书与审核不跟排期走。
• 区分日常迭代包与版本完整包，增量机制管日常、完整流程管节点。
• 第一次发布配置打包排在里程碑早期，发布问题集要早暴露。

高频问答

问：打包失败报"缺少引用"从哪查起？
报错信息里给的通常是资产路径，按三步走：确认该资产是否真被需要（不需要就从引用方移除）、需要的话确认它在项目里且未损坏（右键能打开验证）、确认引用方不是通过字符串路径硬找的资产（字符串找资产绕过引用链，Cook 收录判定不到它——改成资产引用或把目标加入打包白名单）。

问：启动时的黑屏时间怎么缩短？
黑屏对应的是启动加载：默认地图的体积、启动即加载的巨图资源、初始化的插件数量。对症三招：给启动地图瘦身或加轻量过场、巨图改异步按需加载、禁用不用的插件。启动时间与帧率一样是预算，也要有基线数字并复测。

问：补丁更新（热更）走什么路径？
内容级更新走分包与补丁机制：把可变内容分进独立包，补丁只重发变更包，主程序不动。它的前提是首发时就做好分包规划——后补的分包边界会牵动引用结构。这也是 4.2 软引用的又一处回报：挂单式内容天然适合远端下发。