本文因项目实际问题而起，简要分析了 RN Bundle 的结构。

本文同时发表于我的个人博客

引

原本计划在完成『ReactNative源码解析——渲染机制详解』一文后，暂停 RN 相关的总结分享，谁料项目中通过RN分包同时加载两个业务 bundle 时出错了！索性对 RN Bundle 研究一番，遂总结出此文。

Overview

使用 ReactNative 开发的业务，无论是通过内置还是动态下发的方式发布，都需要将业务 JavaScript 代码打包成 bundle。 JavaScript 作为一门动态脚本语言，为何需要打包这个过程？打包主要有以下几个用途：

开发 RN 业务时，一般会使用 JSX 语法『糖』描述 UI 视图，然而标准的 JS 引擎显然不支持 JSX，所以需要将 JSX 语法转换成标准的 JS 语法；
开发 RN 业务时，通常使用的是 ES 6，目前 iOS、Android 上的 JS 引擎还不支持 ES 6，因此需要转换；
JS 业务代码会依赖多个不同的模块(JS 文件)，RN 在打包时将所有依赖的模块打包到一个 bundle 文件中，较好地解决了这种复杂的依赖关系；
JS 代码的混淆。

RN 打包过程中的转码主要依赖 Babel 实现。

ReactNative Bundle

RN Bundle 从本质上讲是一个 JS 文件，其主要由三部分组成：polyfills、module 定义、require 调用。

Polyfills

polyfills 部分主要是在 JS context 中做一些准备工作，如：声明 ES 6 语法中新增接口、定义模块方法(如：模块声明方法__d、模块引用方法require等)、设置global.__DEV__变量等。如上图，polyfills 都闭包方法，定义的同时被调用。 polyfill具体规则定义在node_modules/metro-bundler/src/defaults.js中：

exports.polyfills = [
require.resolve('./Resolver/polyfills/Object.es6.js'),
require.resolve('./Resolver/polyfills/console.js'),
require.resolve('./Resolver/polyfills/error-guard.js'),
require.resolve('./Resolver/polyfills/Number.es6.js'),
require.resolve('./Resolver/polyfills/String.prototype.es6.js'),
require.resolve('./Resolver/polyfills/Array.prototype.es6.js'),
require.resolve('./Resolver/polyfills/Array.es6.js'),
require.resolve('./Resolver/polyfills/Object.es7.js'),
require.resolve('./Resolver/polyfills/babelHelpers.js')];

defaults.js中还有其他有意思的信息^_^

module definitions

为了更直观的了解 RN Bundle 中模块的定义，我们先来看一个例子：如上图一个非常简单的 RN Demo，在打包生成的 bundle 中变成如下的格式：很明显，为了看懂上图所示的打包结果，必须先了解一下__d为何物，细心的同学，可能已经在 polyfills 小节中发现了__d的定义(第12行)，即__d就是define方法，其完整的源码定义在：node_modules/metro-bundler/src/Resolver/polyfills/require.js中(代码略有删减)：

global.require = require;
global.__d = define;

const modules = Object.create(null);

function define(factory, moduleId, dependencyMap) {
    if (moduleId in modules) {
        // that are already loaded
        return;
    }
    modules[moduleId] = {
        dependencyMap,
        exports: undefined,
        factory,
        hasError: false,
        isInitialized: false };
}

可以看到define方法前三个参数分别为：factory 方法、module ID以及dependencyMap。 调用define方法定义模块，实质就是以 moduleID 为 key 向模块注册表(modules)中注册模块相关的信息(exports、模块factory方法、isInitialized等)。 好了，下面我们再次回到 RN Bundle 中 module definition。

module ID

在 RN 中，为了唯一标识每个模块，解决模块间的依赖问题，在打包生成 bundle 时，为每个 module 生成一个唯一的 moduleID，moudleID 为从0开始递增的数字。另外，RN 在打包 bundle 时，按模块间依赖关系深度遍历(弦外之音就是，根组件的 moduleID 为0)。

module factory

从上图可知，module factory 方法主要做了以下几件事：

所有 import 转换为require方法调用(import是 ES 6新增语法，需要转换)(第58、60行)；
创建组件类(第62~83行)，其中最关键的方法就是render；
导出(exports)组件类(第85行)；
注册根组件(第87~89行)，详细信息请参看ReactNative源码解析——渲染机制详解一文。

通过 module factory 中的 render方法，再次看到 JSX 标签被转换成了createElement方法调用。

require calls

RN Bundle 最后部分是 require calls：

;require(50);  // InitializeCore.js
;require(0);

require方法参数为 moduleID，RN Bundle 最后这两个require调用分别加载了InitializeCore以及RNDemo(根组件)模块。下面我们来看看，require具体做了哪些事(与模块定义方法define定义在同一文件中)：

function require(moduleId) {
    const module = modules[moduleId];
    return module && module.isInitialized ?
    module.exports :
    guardedLoadModule(moduleIdReallyIsNumber, module);
}

function guardedLoadModule(moduleId, module) {
    return loadModuleImplementation(moduleId, module);
}

function loadModuleImplementation(moduleId, module) {
    module.isInitialized = true;
    const exports = module.exports = {};
    var _module = module;
    const factory = _module.factory, dependencyMap = _module.dependencyMap;
    const moduleObject = { exports };
    factory(global, require, moduleObject, exports, dependencyMap);
    return module.exports = moduleObject.exports;
}

如上代码所示，require方法首先判断所要加载的模块是否已经存在并初始化完成。若是，则直接返回模块的exports，否则调用guardedLoadModule方法(最终调用的是loadModuleImplementation方法)。 loadModuleImplementation方法获得模块的factory方法并调用，最终返回模块的exports。

小结

从上文的分析可知，加载一个 RN Bundle，主要完成三件事：

准备 JS 执行环境(polyfills)；
定义所有需要的模块(module define)；
加载InitializeCore以及根组件模块(require)。

通过上文分析，应该能清楚的区分模块定义与加载的关系：

模块定义(define)：将模块相关的信息(其中最重要的就是factory方法)添加到模块注册表中，仅此而已；
模块加载(require)：在 JS context 中调用模块factory方法，创建模块类并在组件注册表中注册根组件。

以盖房子作比喻：

模块定义：将盖房子需要的材料运入场地；
模块加载：真正地将房子盖起来。

ps：上文所示的 RN Bundle 都是开发环境下打出来的(打包命令中--dev为 true)，这样的 Bundle 是没有经过混淆的，其可读性较好。经过混淆的 Bundle，大概长这样：

!function(e){e.__DEV__=!1,e.__BUNDLE_START_TIME__=e.nativePerformanceNow?e.nativePerformanceNow():Date.now()}("undefined"!=typeof global?global:"undefined"!=typeof self?self:this);
!function(r){"use strict";function e(r,e,t){e in u||(u[e]={dependencyMap:t,exports:void 0,factory:r,hasError:!1,isInitialized:!1})}function t(r){var e=r,t=u[e];return t&&t.isInitialized?t.exports:i(e,t)}function i(e,t){if(!c&&r.ErrorUtils){c=!0;var i=void 0;try{i=n(e,t)}catch(e){r.ErrorUtils.reportFatalError(e)}return c=!1,i}return n(e,t)}function n(e,i){var n=r.nativeRequire;if(!i&&n&&(n(e),i=u[e]),!i)throw o(e);if(i.hasError)throw a(e,i.error);i.isInitialized=!0;var c=i.exports={},d=i,s=d.factory,f=d.dependencyMap;try{var l={exports:c};return s(r,t,l,c,f),i.factory=void 0,i.dependencyMap=void 0,i.exports=l.exports}catch(r){throw i.hasError=!0,i.error=r,i.isInitialized=!1,i.exports=void 0,r}}function o(r){var e='Requiring unknown module "'+r+'".';return Error(e)}function a(r,e){var t=r;return Error('Requiring module "'+t+'", which threw an exception: '+e)}r.require=t,r.__d=e;var u=Object.create(null),c=!1}("undefined"!=typeof global?global:"undefined"!=typeof self?self:this);
__d(function(e,t,r,l){Object.defineProperty(l,"__esModule",{value:!0});var n=t(12),s=babelHelpers.interopRequireDefault(n),a=t(24),o=function(e){function t(){return babelHelpers.classCallCheck(this,t),babelHelpers.possibleConstructorReturn(this,(t.__proto__||Object.getPrototypeOf(t)).apply(this,arguments))}return babelHelpers.inherits(t,e),babelHelpers.createClass(t,[{key:"render",value:function(){return s.default.createElement(a.View,{style:styles.container},s.default.createElement(a.Text,null,"This is a demo"))}}]),t}(s.default.Component);l.default=o,a.AppRegistry.registerComponent("RNDemo",function(){return o})},0);

问题

好了，本文既然是因问题而起，最后简要介绍一下遇到的问题：问题的描述很清楚是根组件没有注册，由于刚刚分析完 RN 的渲染机制，知道这个错误描述的出处(来自AppRegistry模块的runApplication方法)：问题也很明显是在组件注册表runnables中找不到要运行的根组件。起初我们怀疑是因为两个业务 bundle 有冲突在加载时出错了。但 debug 下来并没有出错提示。最终请教相关人士，得知是两个业务 bundle ID 一样，导致第二个 bundle 没有被正确定义(define方法首先通过要定义的模块 ID 判断该 ID 是否已注册，若已注册直接返回)。

两个业务 bundle ID 会一样与我们使用的拆包方案有关。

问题清楚了，修改就简单了，在此不细述了。

通过这个问题，也说明了对底层实现方案了解的必要性。了解的越深，在遇到问题时思考的视角就会越广。

简述 ReactNative Bundle

引