本文主要介绍 bundle 命令的执行过程，以及 Facebook 专门为 react-native 开发的打包工具 Metro(针对 v0.30.2) 的基本原理。
local-cli
进入 react-native 源码目录，其中有一个 local-cli 的子目录。 local-cli 下包含了所有的 react-native 的二级命令。bundle 包中包含了 bundle & unbundle 命令的实际逻辑.
它和 Metro 的关系是：
react-native 调试时的 debug 功能、差分构建、混淆等功能都在 Metro 中实现。 Local-cli 只是 Metro 的一个调用方。可以看出他们之间是一个典型的 C/S 结构。
bundle 文件结构
理解包结构之前需要先了解 CommonJS。
图片来源于网络
- polyfills 部分定义了公用的关键字， 例如 __DEV__, __BUNDLE_START_TIME__ 等等；还有一个关键的模块定义函数 define
- 模块声明部分则是将所有 es6 的模块转换成使用 define 函数重新声明
- 最后通过一个 require 函数从业务入口开始执行
- 在构建过程中会给每个 module 分配一个唯一的 id， 在执行过程中都是通过 id 找到对应的 module，而不是通过文件名称。
Client 侧逻辑
client 的 bundle 命令逻辑实现都在 local-cli/bundle/buildBundle.js 内。
Server 侧逻辑
Metro 内部包含了很多功能。
- 在 debug 环境下，内部会开启一个 http server。客户端通过 reload 操作，触发 server 重新构建；或者选择差分构建；
- 在 release 环境下，只需要走全量构建即可。
这里我们分析 release 环境下的构建流程：
id 生成策略
Server 的构造函数中有一个 createModuleId 的参数，这个函数的作用是创建 moduleId。 默认实现如下：
'use strict';
function createModuleIdFactory() {
const fileToIdMap = new Map();
let nextId = 0;
return path => {
let id = fileToIdMap.get(path);
if (typeof id !== 'number') {
id = nextId++;
fileToIdMap.set(path, id);
}
return id;
};
}
module.exports = createModuleIdFactory;
这个策略很简单， 即每次都自动增1， 如果已经分配过的不会重复分配。
_buildGraph
这个是整个构建中最复杂的逻辑，主要功能是根据 entryFile 生成全局所有的依赖图谱。
plainJsBundle
它的逻辑也很简单，在拿到整个依赖图之后，遍历所有的 module， 将其转为用 define 函数调用。
function plainJSBundle(
entryPoint: string,
pre: $ReadOnlyArray<Module<>>,
graph: Graph<>,
options: Options,
): string {
for (const module of graph.dependencies.values()) {
options.createModuleId(module.path);
}
return [
...pre,
...graph.dependencies.values(),
...getAppendScripts(entryPoint, graph, options),
]
.filter(isJsModule)
.map(module => wrapModule(module, options))
.join('\n');
}
server 的工作到 plainJsBundle 就结束了。后面再由 client 部分将结果保存到文件中。
