3.5 烘焙与打包流程：把发布变成流水线

核心结论

Cook（烘焙）与 Package（打包）是发布前最后一道大工程。Cook 的作用是把编辑器格式资产转成目标平台格式（贴图转 ASTC、音频转平台 codec、shader 编译成移动版）。理解 Cook 机制，就能解释 90% 的"打包前正常、打包后异常"玄学问题。

Cook 的本质

官方文档对 Cooking 有完整说明（https://www.wanxiangyundang.top/read/unreal-engine-5-8-docs/cooking-content-in-unreal-engi-d847 与打包总览 https://www.wanxiangyundang.top/read/unreal-engine-5-8-docs/packaging-and-cooking-games-in-dc8f），一句话概括：

Cook = 按平台 + 按地图（Map）过滤资产，转成目标平台可用的格式。

关键推论：只有被地图引用的资产才会被 Cook。这带来两个常见 bug：

• 打包后某个资产消失 → 它没被任何地图/蓝图引用（或只在运行时软引用）。
• 打包后贴图变糊 → Cook 时按目标平台重新压缩了（ASTC 有损）。

打包前置检查清单

打包方式：图形界面 vs 命令行

• 图形界面：File -> Package Project。小项目够用。
• 命令行/.Automation：大项目唯一选择。可复现、可脚本化、可接 CI。

命令行打包的大致套路：

# 编译+cook+打包（示意，细节按项目）
UnrealEditor.exe <Project> -run=cook -targetplatform=Android_ASTC
UnrealEditor.exe <Project> -build -cook -package -platform=Android

CI 集成时把每次构建产物上传到内部服务器，全员共享同一包，避免"我的包好、你的包崩"。

常见坑与解法

坑 1：Cook 报OOM/时间过长

原因：一次 Cook 所有平台所有地图。

解法：按地图增量 Cook，Cook 只列需要的地图；开 CookParallel 选项（多线程）。大项目一晚一个平台很常见。

坑 2：打包后材质颜色不对

原因：sRGB/Linear 空间在 Cook 压缩后被改；或 ASTC 压缩偏色。

解法：导入时设好 sRGB；必要时美术在目标机上对色板。这是压不下去的代价，接受它并建立色板验收。

坑 3：新版本下载后玩家丢存档

原因：打包时改了 Project Settings -> Packaging -> Build Version 的某个 ID，或 sandbox 路径变化。

解法：版本规划时固定好存储 Key（Android Version Code 只增不减）。

坑 4：多人开发时 Cook 结果不一致

原因：本地 Saved/Cooked 缓存被污染。

解法：CI 机器每次清缓存重新 Cook；本地开发用 -cooksinglepackagedfile 做快速验证。

我的发布流水线（里程碑节奏）

每个里程碑（约 2 周）一次完整流程：

1. D1 上午：性能关卡回归 + 修超预算项（0301）。
2. D1 下午：出 Development 包，内部试玩一下午，收 bug。
3. D2：修 bug → 出 Shipping 包 → 跑真机三机验收（高/中/低各一）。
4. D2 晚：上传商店/分发渠道，附构建记录（版本号、主要改动）。

这条流水线跑顺后，"发布日"不再是通宵，而是两天常规迭代。

相关节点速查

• 烘焙：Build -> Cook Content 或命令行 -run=cook
• 查 cook 结果：Saved/Cooked/<Platform> 目录
• 打包总览：官方 https://www.wanxiangyundang.top/read/unreal-engine-5-8-docs/packaging-and-cooking-games-in-dc8f；构建运营深入：https://www.wanxiangyundang.top/read/unreal-engine-5-8-docs/build-operations-cooking-packa-6e7f
• Verbose cook log：-cook -log -verbose，专治玄学问题

心得：打包这一环最怕"靠玄学"。把 Cook 机制讲给团队（ cook 只收被引用的资产 这一条就能解释一半怪事），再把流程固化成 CI，团队的发布焦虑会肉眼可见地下降。可复现的流程胜过任何救火英雄。