本文主要介绍 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 部分将结果保存到文件中。