您好,登錄后才能下訂單哦!
這篇文章主要介紹“React Native中怎么實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入”的相關(guān)知識(shí),小編通過(guò)實(shí)際案例向大家展示操作過(guò)程,操作方法簡(jiǎn)單快捷,實(shí)用性強(qiáng),希望這篇“React Native中怎么實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入”文章能幫助大家解決問(wèn)題。
隨著業(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)用的體積。
第一個(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í)間成倍增加。
作為一個(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 的打包機(jī)制及其構(gòu)建產(chǎn)物。
如下圖所示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。
一個(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ù)的分析
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è)是此模塊的文件名稱。
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)用,最后返回。
基于以上對(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
如上所示就是一個(gè)依賴樹(shù),正常情況下會(huì)打出一個(gè) bundle,包含模塊 A、B、C、D、E、F、G。現(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ù)再談。
通過(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)
通過(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 之類(lèi)定義 (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
是在生成階段寫(xiě)入主 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)完成了。
關(guān)于“React Native中怎么實(shí)現(xiàn)動(dòng)態(tài)導(dǎo)入”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí),可以關(guān)注億速云行業(yè)資訊頻道,小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。