背景

隨著業(yè)務(wù)的發(fā)展，每一個(gè) React Native 應(yīng)用的代碼數(shù)量都在不斷增加，bundle 體積不斷膨脹，對(duì)應(yīng)用性能的負(fù)面影響愈發(fā)明顯。雖然我們可以通過(guò) React Native 官方工具 Metro 進(jìn)行拆包處理，拆分為一個(gè)基礎(chǔ)包和一個(gè)業(yè)務(wù)包進(jìn)行一定程度上的優(yōu)化，但對(duì)日益增長(zhǎng)的業(yè)務(wù)代碼也無(wú)能為力，我們迫切地需要一套方案來(lái)減小我們 React Native 應(yīng)用的體積。

多業(yè)務(wù)包

第一個(gè)想到的就是拆分多業(yè)務(wù)包，既然拆分為一個(gè)業(yè)務(wù)包不夠，那我多拆為幾個(gè)業(yè)務(wù)包不就可以了。當(dāng)一個(gè) React Native 應(yīng)用拆分為多個(gè)業(yè)務(wù)包之后其實(shí)就相當(dāng)于拆分為多個(gè)應(yīng)用了，只不過(guò)代碼在同一倉(cāng)庫(kù)里。這雖然可以解決單個(gè)應(yīng)用不斷膨脹的問(wèn)題，但是有不少局限性。接下來(lái)一一分析：

• 鏈接替換，不同的應(yīng)用需要不同的地址，替換成本較高。
• 頁(yè)面之間通信，之前是個(gè)單頁(yè)應(yīng)用，不同頁(yè)面之間可以直接通信；拆分之后是不同應(yīng)用相互通信需要借助客戶端橋接實(shí)現(xiàn)。
• 性能損耗，打開(kāi)每個(gè)拆分的業(yè)務(wù)包都需要單獨(dú)起一個(gè) React Native 容器，容器初始化、維持都需要消耗內(nèi)存、占用CPU。
• 粒度不夠，最小的維度也是頁(yè)面，無(wú)法繼續(xù)對(duì)頁(yè)面中的組件進(jìn)行拆分。
• 重復(fù)打包，部分在不同頁(yè)面之間共享的工具庫(kù)，每個(gè)業(yè)務(wù)包都會(huì)包含。
• 打包效率，每一個(gè)業(yè)務(wù)包的打包過(guò)程，都要經(jīng)過(guò)一遍完整的 Metro 打包過(guò)程，拆分多個(gè)業(yè)務(wù)包打包時(shí)間成倍增加。

動(dòng)態(tài)導(dǎo)入

作為一個(gè)前端想到的另一方案自然就是動(dòng)態(tài)導(dǎo)入（Dynamic import）了，基于其動(dòng)態(tài)特性對(duì)于多業(yè)務(wù)包的眾多缺點(diǎn)，此方案都可避免。此外擁有了動(dòng)態(tài)導(dǎo)入我們就可以實(shí)現(xiàn)頁(yè)面按需加載，組件懶加載等等能力。但是 Metro 官方并不支持動(dòng)態(tài)導(dǎo)入，因此需要對(duì) Metro 進(jìn)行深度定制，這也是本文即將介紹的在 React Native 中實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入。

Metro 打包原理

在介紹具體方案之前我們先看下 Metro 的打包機(jī)制及其構(gòu)建產(chǎn)物。

打包過(guò)程

如下圖所示Metro打包會(huì)經(jīng)過(guò)三個(gè)階段，分別是 Resolution、Transformation、Serialization。

image

Resolution 的作用是從入口開(kāi)始構(gòu)建依賴圖；Transformation 是和 Resolution 階段同時(shí)執(zhí)行的，其目的是將所有 module（一個(gè)模塊就是一個(gè) module ） 轉(zhuǎn)換為目標(biāo)平臺(tái)可識(shí)別語(yǔ)言，這里面既有高級(jí) JavaCript 語(yǔ)法的轉(zhuǎn)換（依賴 BaBel），也有對(duì)特定平臺(tái)，比如安卓的特殊 polyfills。這兩個(gè)階段主要是生產(chǎn)中間產(chǎn)物 IR 為最后一階段所消費(fèi)。

Serialization 則是將所有 module 組合起來(lái)生成 bundle，這里需要特別注意 Metro API 文檔中 Serializer Options 中的兩個(gè)配置：

• 簽名為 createModuleIdFactory， type 為 () => (path: string) => number。 這個(gè)函數(shù)為每個(gè) module 生成一個(gè)唯一的 moduleId，默認(rèn)情況下是自增的數(shù)字。所有的依賴關(guān)系都依仗此 moduleId。
• 簽名為 processModuleFilter， type 為 (module: Array) => boolean。這個(gè)函數(shù)用來(lái)過(guò)濾模塊，決定是否打入 bundle。

bundle 分析

一個(gè) React Native 典型的 bundle 從上到下可以分為三個(gè)部分：

• 第一部分為 polyfills，主要是一些全局變量如 DEV；以及通過(guò) IIFE 聲明的一些重要全局函數(shù)，如： __d、 __r 等；
• 第二部分是各個(gè) module 的定義，以 __d 開(kāi)頭，業(yè)務(wù)代碼全部在這一塊；
• 第三部分是應(yīng)用的初始化 __r(react-native/Libraries/Core/InitializeCore.js moduleId) 和 __r(${入口 moduleId})。
  我們看下具體函數(shù)的分析

__d函數(shù)

function define(factory, moduleId, dependencyMap) {
    const mod = {
        dependencyMap,
        factory,
        hasError: false,
        importedAll: EMPTY,
        importedDefault: EMPTY,
        isInitialized: false,
        publicModule: {
            exports: {}
        }
    };
    modules[moduleId] = mod;
}

__d 其實(shí)就是 define 函數(shù)，可以看到其實(shí)現(xiàn)很簡(jiǎn)單，做的就是聲明一個(gè) mode，同時(shí) moduleId 與 mode 做了一層映射，這樣通過(guò) moduleId 就可以拿到 module 實(shí)現(xiàn)。我們看下 __d 如何使用：

__d(function (global, _$$_REQUIRE, _$$_IMPORT_DEFAULT, _$$_IMPORT_ALL, module, exports, _dependencyMap) {
    var _reactNative = _$$_REQUIRE(_dependencyMap[0], "react-native");

    var _reactNavigation = _$$_REQUIRE(_dependencyMap[1], "react-navigation");

    var _reactNavigationStack = _$$_REQUIRE(_dependencyMap[2], "react-navigation-stack");

    var _routes = _$$_REQUIRE(_dependencyMap[3], "./src/routes");

    var _appJson = _$$_REQUIRE(_dependencyMap[4], "./appJson.json");

    var AppNavigator = (0, _reactNavigationStack.createStackNavigator)(_routes.RouteConfig, (0, _routes.InitConfig)());
    var AppContiner = (0, _reactNavigation.createAppContainer)(AppNavigator);

    _reactNative.AppRegistry.registerComponent(_appJson.name, function () {
        return AppContiner;
    });
}, 0, [1, 552, 636, 664, 698], "index.android.js");

這是 __d 的唯一用處，定義一個(gè) module。這里解釋下入?yún)?，第一個(gè)是個(gè)函數(shù)，就是 module 的工廠函數(shù)，所有的業(yè)務(wù)邏輯都在這里面，其是在 __r 之后調(diào)用的；第二個(gè)是 moduleId，模塊的唯一標(biāo)識(shí)；第三部分是其依賴的模塊的 moduleId；第四個(gè)是此模塊的文件名稱。

__r函數(shù)

function metroRequire(moduleId) {

    ...

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

function guardedLoadModule(moduleId, module) {

    ...

    return loadModuleImplementation(moduleId, module);
}

function loadModuleImplementation(moduleId, module) {

    ...

    const moduleObject = module.publicModule;
    moduleObject.id = moduleId;
    factory(
        global,
        metroRequire,
        metroImportDefault,
        metroImportAll,
        moduleObject,
        moduleObject.exports,
        dependencyMap
    ); 
    return moduleObject.exports;

    ...
}

__r 其實(shí)就是 require 函數(shù)。如上精簡(jiǎn)后的代碼所示，require 方法首先判斷所要加載的模塊是否已經(jīng)存在并初始化完成，若是則直接返回模塊，否則調(diào)用 guardedLoadModule 方法，最終調(diào)用的是 loadModuleImplementation 方法。loadModuleImplementation 方法獲得模塊定義時(shí)傳入的 factory 方法并調(diào)用，最后返回。

方案設(shè)計(jì)

基于以上對(duì) Metro 工作原理及其產(chǎn)物 bundle 的分析，我們可以大致得出這樣一個(gè)結(jié)論：React Native 啟動(dòng)時(shí)，JS 測(cè)（即 bundle）會(huì)先初始化一些變量，接著通過(guò) IIFE 聲明核心方法 define 和 require；接著通過(guò) define 方法定義所有的模塊，各個(gè)模塊的依賴關(guān)系通moduleId 維系，維系的紐帶就是 require；最后通過(guò) require 應(yīng)用的注冊(cè)方法實(shí)現(xiàn)啟動(dòng)。

實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入自然需要將目前的 bundle 進(jìn)行重新拆分和組合，整個(gè)方案的關(guān)鍵點(diǎn)在于：分和合，分就是 bundle 如何拆分，什么樣的 module 需要拆分出去，什么時(shí)候進(jìn)行拆分，拆分之后的 bundle 存儲(chǔ)在哪里（涉及到后續(xù)如何獲?。?；合就是拆出去的 bundle 如何獲取，并在獲取之后仍在正確的上下文內(nèi)執(zhí)行。

分

前面有說(shuō)過(guò) Metro 工作的三個(gè)階段，其中之一就是 Resolution，這一階段的主要任務(wù)是從入口開(kāi)始構(gòu)建整個(gè)應(yīng)用依賴圖，這里為了方便示意以樹(shù)來(lái)代替。

image

識(shí)別入口

如上所示就是一個(gè)依賴樹(shù)，正常情況下會(huì)打出一個(gè) bundle，包含模塊 A、B、C、D、E、F、G?，F(xiàn)在我想對(duì)模塊 B 和 F 做動(dòng)態(tài)導(dǎo)入。怎么做呢第一步當(dāng)然是標(biāo)識(shí)，既然叫動(dòng)態(tài)導(dǎo)入自然而然的想到了 JavaScript 語(yǔ)法上的動(dòng)態(tài)導(dǎo)入。

只需要將 import A from '.A' 改成 const A = import('A') 即可，這就需要引入 Babel 插件（）了，事實(shí)上官方 Metro 相關(guān)配置包 metro-config 已經(jīng)集成了此插件。官方做的不僅僅于此，在 Transformation 階段還對(duì)采用動(dòng)態(tài)導(dǎo)入的 module 增加了唯一標(biāo)識(shí) Async = true。

此外在最終產(chǎn)物 bundle 上 Metro 提供了一個(gè)名叫 AsyncRequire.js 的文件模版來(lái)做動(dòng)態(tài)導(dǎo)入的語(yǔ)法的 polyfill，具體實(shí)現(xiàn)如下

const dynamicRequire = require;

module.exports = function(moduleID) {
    return Promise.resolve().then(() => dynamicRequire.importAll(moduleID));
};

總結(jié)一下 Metro 默認(rèn)會(huì)如何處理動(dòng)態(tài)導(dǎo)入：在 Transformation 通過(guò) Babel 插件處理動(dòng)態(tài)導(dǎo)入語(yǔ)法，并在中間產(chǎn)物上增加標(biāo)識(shí) Async，在 Serialization 階段用 Asyncrequire.js 作為模板替換動(dòng)態(tài)導(dǎo)入的語(yǔ)法，即

const A = import(A);

//變?yōu)?

const A = function(moduleID) {
    return Promise.resolve().then(() => dynamicRequire.importAll(moduleID));
};

Asyncrequire.js 不僅關(guān)乎我們?nèi)绾尾鸱?，還和我們最后的合息息相關(guān)，留待后續(xù)再談。

樹(shù)拆分

通過(guò)上文我們知道構(gòu)建過(guò)程中會(huì)生成一顆依賴樹(shù)，并對(duì)其中使用動(dòng)態(tài)的導(dǎo)入的模塊做了標(biāo)識(shí)，接下來(lái)就是樹(shù)如何進(jìn)行拆分了。對(duì)于樹(shù)的通用處理辦法就是 DFS，通過(guò)對(duì)上圖依賴樹(shù)做 DFS 分析之后可以得到如下做了拆分的樹(shù)，包含一顆主樹(shù)和兩顆異步樹(shù)。對(duì)于每棵樹(shù)的依賴進(jìn)行收集即可得到如下三組 module 集合：A、E、C；B、D、E、G；F、G。

image

當(dāng)然在實(shí)際場(chǎng)景中，各個(gè)模塊的依賴遠(yuǎn)比這個(gè)復(fù)雜，甚至存在循環(huán)依賴的情況，在做 DFS 的過(guò)程中需要遵循兩個(gè)原則：

• 已經(jīng)在處理過(guò)的 module，后續(xù)遇到直接退出循環(huán)
• 各個(gè)異步樹(shù)依賴的非主樹(shù) module 都需要包含進(jìn)來(lái)

bundle 生成

通過(guò)這三組 module 集合即可得到三個(gè)bundle（我們將主樹(shù)生成的 bundle 稱為主 bundle；異步樹(shù)生成的稱為異步 bundle）。至于如何生成，直接借助前文提到的 Metro 中 processBasicModuleFilter 方法即可。Metro 原本在一次構(gòu)建過(guò)程中，只會(huì)經(jīng)過(guò)一次 Serialization 階段生成一個(gè) bundle?，F(xiàn)在我們需要對(duì)每一組 module 都進(jìn)行一次 bundle 生成。

這里需要注意幾個(gè)問(wèn)題：

• 去重，一種是已經(jīng)打入主 bundle 的 module 異步 bundle 不需要打入；一種是同時(shí)存在于不同異步樹(shù)內(nèi)的 module，對(duì)于這種 module，我們可以將其標(biāo)記為動(dòng)態(tài)導(dǎo)入單獨(dú)打包，見(jiàn)下圖

image

• 生成順序，需要先生成異步 bundle，再生成主 bundle。因?yàn)樾枰獙惒?bundle 的信息（比如文件名稱、地址）與 moduleId 做映射填入主 bundle，這樣在真正需要的時(shí)候可以通過(guò) moduleId 的映射拿到異步 bundle 的地址信息。
• 緩存控制，為了保證每個(gè)異步 bundle 在能夠享受緩存機(jī)制的同時(shí)能夠及時(shí)更新，需要對(duì)異步 bundle 做 content hash 添加到文件名上
• 存儲(chǔ)，異步 bundle 如何存儲(chǔ)，是和主 bundle 一起，還是單獨(dú)存儲(chǔ)，需要時(shí)再去獲取呢。這個(gè)需要具體分析：對(duì)于采用了bundle 預(yù)加載的可以將異步 bundle 和主 bundle 放到一起，需要時(shí)直接從本地拿即可（所謂預(yù)加載就是在客戶端啟動(dòng)時(shí)就已經(jīng)將所有 bundle 下載下來(lái)了，在用戶打開(kāi) React Native 頁(yè)面時(shí)無(wú)需再去下載 bundle）。對(duì)于大部分沒(méi)有采用預(yù)加載技術(shù)的則分開(kāi)存儲(chǔ)更合適。

至此我們已經(jīng)獲得了主 bundle 和異步 bundle，大致結(jié)構(gòu)如下：

/* 主 bundle */

// moduleId 與 路徑映射
var REMOTE_SOURCE_MAP = {${id}: ${path}, ... }

// IIFE __r 之類定義
(function (global) {
  "use strict";
  global.__r = metroRequire;
  global.__d = define;
  global.__c = clear;
  global.__registerSegment = registerSegment;
  ...
})(typeof global !== 'undefined' ? global : typeof window !== 'undefined' ? window : this);

//  業(yè)務(wù)模塊
__d(function (global, _$$_REQUIRE, _$$_IMPORT_DEFAULT, _$$_IMPORT_ALL, module, exports, _dependencyMap) {
  var _reactNative = _$$_REQUIRE(_dependencyMap[0], "react-native");
  var _asyncModule = _$$_REQUIRE(_dependencyMap[4], "metro/src/lib/bundle-modules/asyncRequire")(_dependencyMap[5], "./asyncModule")
  ...
},0,[1,550,590,673,701,855],"index.ios.js");

...

// 應(yīng)用啟動(dòng)
__r(91);
__r(0);

/* 異步 bundle */

// 業(yè)務(wù)模塊
__d(function (global, _$$_REQUIRE, _$$_IMPORT_DEFAULT, _$$_IMPORT_ALL, module, exports, _dependencyMap) {
  var _reactNative = _$$_REQUIRE(_dependencyMap[0], "react-native");
  ...
},855,[956, 1126],"asyncModule.js");

合

大部分工作其實(shí)在分這一階段已經(jīng)做完了，接下來(lái)就是如何合了，前面有提到過(guò)動(dòng)態(tài)導(dǎo)入的語(yǔ)法在生成的 bundle 中會(huì)被 AsyncRequire.js 中的模板所替代。仔細(xì)研究下其代碼發(fā)現(xiàn)其是用 Promise 包裹了一層 require(moduleId) 來(lái)實(shí)現(xiàn)。

現(xiàn)在我們直接 require(moduleId) 必然是拿不到真正的 module 實(shí)現(xiàn)了，因?yàn)楫惒?bundle 還沒(méi)有獲取到，module 還沒(méi)有定義。但可以對(duì) AsyncRequire.js 做如下改造

const dynamicRequire = require;
module.exports = function (moduleID) {
    return fetch(REMOTE_SOURCE_MAP[moduleID]).then(res => {  // 行1
        new Function(res)();                                 // 行2
        return dynamicRequire.importAll(moduleID)            // 行3
    });
};

接下來(lái)一行行進(jìn)行分析

• 行1將之前 mock 的 Promise 替換為真正的 Promise 請(qǐng)求，先去獲取 bundle 資源，REMOTE_SOURCE_MAP 是在生成階段寫入主 bundle 的 moduleId 與異步 bundle 資源地址的映射。fetch 根據(jù)異步 bundle 的存儲(chǔ)方式的不同選擇不同的方式獲取真正的代碼資源；
• 行2通過(guò) Function 方法執(zhí)行獲取到的代碼，即是模塊的聲明，這樣最后返回 module 的時(shí)候就已經(jīng)是定義過(guò)的了；
• 行3 返回真正的模塊實(shí)現(xiàn)。
  這樣我們就實(shí)現(xiàn)了合，異步 bundle 的獲取、執(zhí)行就都在 AsyncRequire.js 內(nèi)完成了。

總結(jié)

至此我們就完成了 React Native 動(dòng)態(tài)導(dǎo)入的改造。相對(duì)于多業(yè)務(wù)包，因?yàn)槠鋭?dòng)態(tài)特性使得業(yè)務(wù)方使用的時(shí)候所有修改都在同一個(gè) React Native 應(yīng)用內(nèi)部閉環(huán)完成，外部無(wú)感知，多業(yè)務(wù)包的眾多缺陷也就不存在了。與此同時(shí)構(gòu)建時(shí)會(huì)充分利用第一次的生產(chǎn)的 IR，這樣每一個(gè) bundle 不需要再單獨(dú)走 Metro 的完整構(gòu)建流程。

當(dāng)然有一點(diǎn)是必須需要考慮的，那就是我們對(duì) Metro 進(jìn)行改造之后，對(duì)于后續(xù)的升級(jí)是否有影響，導(dǎo)致只能鎖定 React Native 和 Metro 版本。這個(gè)其實(shí)完全不用擔(dān)心，從前面的分析可以知道，我們對(duì)于整個(gè)流程的改造可以分為兩部分：構(gòu)建時(shí)、運(yùn)行時(shí)。在構(gòu)建時(shí)我們確實(shí)新增了不少能力，比如新的分組算法、代碼生成；但是運(yùn)行時(shí)則是完全基于現(xiàn)有版本能力的增強(qiáng)。這就使得動(dòng)態(tài)導(dǎo)入的運(yùn)行時(shí)無(wú)兼容性問(wèn)題，即使升級(jí)到新版本依然不會(huì)報(bào)錯(cuò)，只不過(guò)再我們?cè)俅胃脑鞓?gòu)建時(shí)之前失去了動(dòng)態(tài)導(dǎo)入的能力。

最后真正在生產(chǎn)環(huán)境上使用還有一些工程上的改造，比如：構(gòu)建平臺(tái)適配、提供快速接入組件等等限于篇幅就不在此詳述了。

到此這篇關(guān)于React Native中實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入的示例代碼的文章就介紹到這了,更多相關(guān)React Native動(dòng)態(tài)導(dǎo)入內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論