8.1 Metro打包与双端构建
8.1 Metro打包与双端构建
本节摘要：Metro 是 RN 的打包器与开发服务器，负责把散落的 JavaScript 模块变成可执行的单包；双端原生构建则把这份包与原生工程合成最终产物。本节拆解 Metro 的三段流程，讲清调试构建与发布构建的差异（这正是「开发很顺、上线变样」的根源），并给出产物体积与启动性能的构建侧优化杠杆。本节是交付链的第一站，8.3 的签名上架以它的产物为原料。
Metro 的三段流程
Metro 干三件事。解析：从入口文件出发，沿着依赖语句递归找出全部模块，构成依赖图——这也解释了为什么循环依赖会造成诡异的行为差异，依赖图在解析期就定了形。转换：把每个模块编译成目标环境能执行的形态，语法降级、按平台后缀择优（3.2 节的平台专属文件就是在这里被择中）——开发期为了热刷新速度逐模块转换，发布期则要考虑确定性。序列化：把转换后的模块写成有限几个产物文件，模块按需加载的分组也在这里定下。
调试构建与发布构建的差别不在流程，在取舍：开发构建牺牲体积与执行速度，换取热刷新、报错可读、随时插桩；发布构建压缩混淆代码、剔除开发辅助、启用字节码编译（Hermes 的预编译在此生效）。理解这对取舍，很多「开发环境没问题、生产环境才出现」的灵异事件就有了答案：两套构建里运行的代码形态本就不同——比如依赖生产模式假设的代码，在开发构建的宽松环境里反而暴露不出问题。
双端构建：从源码到产物
JavaScript 产物只是原料，真正的成品由双端原生构建产出。iOS 侧经 Xcode 构建系统完成编译、链接、资源打包，产出归档（调试期直装模拟器，发布期导出用于分发的归档）；Android 侧经 Gradle 完成，调试期出直接安装的应用包，发布期建议产出应用束（AAB），由商店按设备分发裁剪后的安装包——这是「按需下载」的收益来源，对包体敏感的市场尤其明显。构建配置里对启动性能影响最大的两处：引擎是否启用字节码（2.3 与 6.3 讲过它的启动红利），以及新架构开关是否与依赖库兼容（7.3 的清单在此兑现）。
图：从源码到用户手机的完整流水线
构建变体与环境分层
「测试环境接口连的是测试服务器」这类需求，正解是构建变体加环境分层，而不是发版前手动改配置（手动改配置的事故率有排行榜的话，它常年第一）。变体思想：同一份代码按配置组合产出调试版、预发版、发布版，接口域名、功能开关、日志级别都作为环境配置在构建期注入，产物自带身份，装错环境的包一眼可辨。
JS 侧的环境注入有个安全边界要划清：注入的只是「非敏感配置」（域名、开关、采样率），任何密钥类内容都不走这条路——客户端的一切注入内容都应视为可被解包读取，8.4 的安全清单会把这条再强调一次。
// 环境配置模块：按构建变体注入，业务代码只 import 这一份 const configs = { debug: { apiBase: 'https://api.dev.internal', logLevel: 'verbose' }, staging: { apiBase: 'https://api.stg.internal', logLevel: 'info' }, release: { apiBase: 'https://api.example.com', logLevel: 'warn' }, }; export default configs[__DEV__ ? 'debug' : process.env.BUILD_VARIANT || 'release'];
双端的原生变体机制与 JS 侧呼应：Android 的构建类型与渠道维度、iOS 的构建配置与目标，都允许同一工程产出不同身份的产物。两端变体的命名与用途对齐，是持续交付流水线（8.3 会讲）的地基——流水线自动化到深处，拼的就是「变体定义得清不清楚」。
体积与启动的构建侧杠杆
包体积是两端共同的关注点，构建侧的杠杆按性价比排序：其一，资源瘦身——未压缩的图片、多套分辨率的冗余切图，是包体的常驻大户，构建前先清点；其二，依赖治理——npm 生态里「装一个拖一串」是常态，定期用依赖分析工具清点体积贡献，警惕为一个小函数引入全家桶；其三，引擎字节码——Hermes 字节码通常小于压缩源码，体积与启动双赢；其四，Android 应用束的分发裁剪，让用户只下载适配自己设备的部分。启动侧的杠杆在 2.3 已立口径，构建侧的配合项是：确认发布构建真的启用了字节码与压缩——发布配置被误改回调试形态的事故，每年都有人踩。
体积治理还有一条「预算制」的进阶玩法：给产物体积立年度基线与单版本增量上限，超出预算的合并请求要说明理由或裁掉等量体积。体积与性能一样，靠「发布前突击清一次」是守不住的，靠制度才守得住——这条经验与 6.1 的性能预算完全同构，可以合并成团队的一句话规范：一切会随时间变差的指标，都要有预算与看守者。
完整案例：一次「线上白屏」的构建归因
背景：某版本上线后部分用户冷启动白屏，热启动正常，且集中于特定机型批次。操作：先按 2.3 的三段口径排除服务端与首屏渲染问题（接口正常、埋点显示 JS 包加载完成事件未触发）；对比发布构建产物，发现出问题的包字节码编译未生效——构建机的一次工具链升级让发布配置的引擎开关被静默跳过，包以源码形态分发，特定系统的解析路径触发兼容缺陷。修复：发布构建流程加「产物自检」步骤——检查产物特征确认字节码生效、体积在基线区间，异常即阻断发布；工具链升级纳入变更管控。结果：白屏消失，同类风险被自检关卡拦截在发布前。解读：这个案例是本章方法论的缩影——「线上问题先看构建形态」应成为条件反射，两套构建的差异就是最常被忽视的变量。变式：若问题出现在热更新之后，侦查重点转为「热更包与原生底包的版本匹配」，那是 8.3 要立的规矩。
本节要点回顾
- Metro 三段流程：解析定依赖图、转换定平台形态、序列化定产物分组；
- 两套构建两种取舍：开发求快可读、发布求小求稳，线上灵异事件先查构建形态；
- 双端产物线：iOS 归档导出、Android 应用束裁剪分发，配置影响启动与体积；
- 体积杠杆有排序：资源瘦身、依赖治理、字节码、分发裁剪，按性价比逐个上；
- 产物自检入流程：字节码生效与否、体积基线，机器把关优于人眼。
产物能出来了，敢不敢发要看测试。下一节布防：从函数到真机的三层火力网。