RN中,发布js代码时,会打包成jsbundle形式。随着业务的增大,jsbundle体积也会逐渐增大,特别是多Module场景下,会生成多个jsbundle(包含相同的基础)。不仅增加APP、热更新包体积,也对jsbundle的加载效率造成很大影响。针对jsbundle的拆包,成为集成RN必须考虑的问题。
拆包目的
- 解决jsbundle体积过大
- 按需分步加载,提高加载效率
- 提高热更新包diff/load效率
react-native bundle 命令
react-native bundle是RN的将js代码打包成jsbundle命令。具体使用方式不再赘述,可以通过react-native bundle -help查看。对index.js进行打包,执行:
react-native bundle --entry-file ./index.js --dev false --bundle-output index.jsbundle --bundle-encoding utf-8 --platform "ios"
以index.js为入口,将index.js以及dependence文件打包,在当前目录生成index.jsbundle。分析index.jsbundle文件(删减后):
// header:各依赖模块引用部分
var __DEV__=false,__BUNDLE_START_TIME__=this.nativePerformanceNow?nativePerformanceNow():Date.now(),process=this.process||{};process.env=process.env||{};process.env.NODE_ENV='production';
// body:入口模块和各业务模块定义部分
__d(function(e,r,a,i,l){var n=r(l[0]);babelHelpers.interopRequireDefault(n);r(l[1])},11,[12,17]);
// footer:入口模块注册部分
require(11);
生成的jsbundle基本分成3个部分:
- 头部:全局定义,主要是define,require等全局模块的定义
- 中部:模块定义,RN框架和业务的各个模块定义
- 尾部:引擎初始化和入口函数执行
__d是RN自定义的define,__d后面的数字是模块的id,是在RN打包过程中,解析依赖关系,自增长生成。__d结构:
// 一个基本的结构。注:v0.55,之前的版本define可能不同
__d(
function(e,r,a,i,l){
var n=r(l[0]);
babelHelpers.interopRequireDefault(n);
r(l[1])
},
11,//模块 id
[12,17]
);
// define
__d(
function(global, ...) { (module transformed code) },
moduleId,
dependencyMap?,
moduleName?
);
针对不同模块的入口js文件打包,将生成不同jsbundle对比,可以发现:
- jsbundle的头部相同
- 中部很多模块的定义存在大量重复
- 如果模块js中AppRegistry.registerComponent,尾部的入口模块id基本相同,如上例中的require(11)
实际上头部和中部重复的模块占用了500K的大小,每个入口js生成的jsbundle都会包含这500K代码。这就是我们拆包需要解决的一个主要问题之一。
拆包方案
对RN的bundle命令有了了解,我们可以理清一个思路:将共通基础部分的模块define与具体的业务模块define分拆,避免重复写入jsbundle。
基于这个思路,有几种主流方案:
- diff and patch。将jsbundle通过diff,生成common和每个业务的patch包,然后在APP运行时对common和patch合并成执行的jsbundle。
- 修改RN的bundle命令打包流程,使得直接生成common+business包
- 修改RN的unbundle命令,生成common+business包
实际上,方案1是目前其他各种方案的基础,也是最简单的拆包方案。方案2、3需要较强的nodejs编码能力,另外,RN的升级非常平凡,变动较大,侵入式的生成方案成本较高。本篇只针对方案1做介绍,方案2、3另行介绍,也可参照文末链接,手Q、携程等解决方案。
注:unbundle命令可以完成默认方式的拆包,生成以__d结构为单位的js文件集。但RN的unbundle不支持iOS平台。
common.js 共通模块定义
diffandpatch方案的基本原理,是将业务模块与共通模块jsbundle进行对比,获取差异性的patch。所以,common模块的定义很重要。一般只包含基本的react引用:
// common.js
import React from 'react';
import {} from 'react-native';
以common.js 为--entry-file打包,生成common.js:
react-native bundle --entry-file ./common.js --dev false --bundle-output common.jsbundle --bundle-encoding utf-8 --platform "ios"
这样,对RN基础模块的define就全部生成在common.jsbundle中。
businese.js 业务模块定义
这里要注意的是,业务js的入口文件,最好将common.js的代码加入到头部,保持与common.js一致:
// business.js
import React from 'react';
import {} from 'react-native';
/*
* business contents
*/
这样打包出来的business.jsbundle,common部分模块的id会保持一致,否则可能出现很多id不一致的情况。
business.jsbundle与common.jsbundle 做diff分拆
这里有两种不同的diff方式。
1. 简单diff patch
直接对business.jsbundle与common.jsbundle做diff,将差异点生成patch文件。
APP运行加载business时,将common.jsbundle和business.patch直接merge合成business.jsbundle。
这种方式简单,实现快。针对热更新,也可以通过patch的方式实现。但问题是,虽然可以避免common模块重复打包进jsbundle的问题,但在APP运行时,merge后的business.jsbundle仍然摆脱不了体积大、加载缓慢的问题。
2. 针对__d模块define的diff
简单diff方案无法解决加载缓慢的问题,本质还是到客户端,一次load整个业务jsbundle的方式问题。如果有一种方式,可以动态注入新的jsbundle,那么,就可以分步加载js模块。
2.1 RCTBridge JS动态注入实现
RN本质是通过jscontext来实现js代码的加载和执行。RN与js的交互方式需要了解底层实现。对于jsbundle加载来说,在native侧,一个重要的地方,是RCTBridge对象的使用。
RCTRootView内部持有了一个RCTBridge,但是这个RCTBridge并没有太多的代码,而是持有了另一个RCTBatchBridge对象,大部分的业务逻辑都转发给BatchBridge,BatchBridge里面写着的大量的核心代码。
我们可以通过initWithBundleURL初始化时,或者注册delegate方式,将jsbundle赋值给bridge:
// RCTBridge 初始化
- (instancetype)initWithBundleURL:(NSURL *)bundleURL
moduleProvider:(RCTBridgeModuleListProvider)block
launchOptions:(NSDictionary *)launchOptions
// delegate
- (instancetype)initWithDelegate:(id<RCTBridgeDelegate>)delegate
launchOptions:(NSDictionary *)launchOptions
- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
此时的jscontext环境已经注入了加载的jsbundle。考察BatchBridge的方法列表,我们发现一个私有方法,可以在BatchBridge初始化jsbundle后,动态注入新的jsbundle:
- (void)enqueueApplicationScript:(NSData *)script
url:(NSURL *)url
onComplete:(dispatch_block_t)onComplete;
我们可以通过extension的方式,将方法公开:
@interface RCTBridge()
@property(atomic, strong) RCTBridge *batchedBridge;
- (void)enqueueApplicationScript:(NSData *)script
url:(NSURL *)url
onComplete:(dispatch_block_t)onComplete;
@end
这样就可以在后续向BatchBridge注入新的jsbundle:
// self.bridge = [[RCTBridge alloc] initWithBundleURL:commonJSLocation moduleProvider:nil launchOptions:nil];
NSString *businessPath = [[NSBundle mainBundle] pathForResource:@"business" ofType:@"jsbundle"];
NSData *busJSCode = [NSData businessPath];
[self.bridge.batchedBridge enqueueApplicationScript:busJSCode url:[NSURL businessPath] onComplete:^{
dispatch_async(dispatch_get_main_queue(), ^{
RNFuncViewController *vc = [[RNFuncViewController alloc] initWithModuleName:@"Business" bridge:self.bridge];
[self.navigationController pushViewController:vc animated:YES];
});
}];
如此,我们就实现了jsbundle的动态注入。
2.2 js注入为目的的分拆
如果直接拿上面简单分拆后的common和business jsbundle直接进行分步加载,RN会load报错。这是因为,通过两次react-native bundle打出的jsbundle,会存在相同模块id的define,产生冲突。diff需要遵循几个策略:
2.2.1. 对比common.jsbundle,对于business.jsbundle中多出的__d,需要设定一个唯一的start_id,从start_id开始,增量的对新的__d的模块id做替换。例如:
// index2.js
import React from 'react';
import {AppRegistry} from 'react-native';
import App2 from './App2';
AppRegistry.registerComponent('App2', () => App2);
common和index2 存在两个差异__d(红色为差异点)。其中第一个差异__d的模块id相同,都为11(实际上入口模块id):
// common.jsbundle 差异部分
__d(function(e,r,a,i,l){var n=r(l[0]);babelHelpers.interopRequireDefault(n);r(l[1])},11,[12,17]);
// index2.jsbundle 差异部分
__d(function(e,r,t,n,p){var i=r(p[0]),u=(babelHelpers.interopRequireDefault(i),r(p[1])),l=r(p[2]),a=babelHelpers.interopRequireDefault(l);u.AppRegistry.registerComponent('App2',function(){return a.default})},11,[12,17,307]);
__d(function(e,t,r,n,l){Object.defineProperty(n,"__esModule",{value:!0});var o=t(l[0]),a=babelHelpers.interopRequireDefault(o),s=t(l[1]),i=(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 a.default.createElement(s.View,{style:c.container},a.default.createElement(s.Text,{style:c.welcome},"Welcome to React Native!"),a.default.createElement(s.Text,{style:c.instructions},"To get started, edit AppNext.js"),a.default.createElement(s.Text,{style:c.instructions},"Press Cmd+R to reload,\nCmd+D or shake for dev menu"))}}]),t})(o.Component);n.default=i;var c=s.StyleSheet.create({container:{flex:1,justifyContent:'center',alignItems:'center',backgroundColor:'#F5FCFF'},welcome:{fontSize:20,textAlign:'center',margin:10},instructions:{textAlign:'center',color:'#333333',marginBottom:5}})},307,[12,17]);
设定index2.jsbundle的start_id为1000,做替换:
// 替换后的index2.jsbundle 差异点
__d(function(e,r,t,n,p){var i=r(p[0]),u=(babelHelpers.interopRequireDefault(i),r(p[1])),l=r(p[2]),a=babelHelpers.interopRequireDefault(l);u.AppRegistry.registerComponent('App2',function(){return a.default})},1000,[12,17,1001]);
__d(function(e,t,r,n,l){Object.defineProperty(n,"__esModule",{value:!0});var o=t(l[0]),a=babelHelpers.interopRequireDefault(o),s=t(l[1]),i=(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 a.default.createElement(s.View,{style:c.container},a.default.createElement(s.Text,{style:c.welcome},"Welcome to React Native!"),a.default.createElement(s.Text,{style:c.instructions},"To get started, edit AppNext.js"),a.default.createElement(s.Text,{style:c.instructions},"Press Cmd+R to reload,\nCmd+D or shake for dev menu"))}}]),t})(o.Component);n.default=i;var c=s.StyleSheet.create({container:{flex:1,justifyContent:'center',alignItems:'center',backgroundColor:'#F5FCFF'},welcome:{fontSize:20,textAlign:'center',margin:10},instructions:{textAlign:'center',color:'#333333',marginBottom:5}})},1001,[12,17]);
注意,第一个__d的模块id替换为1000,第二个替换为1001。同时,因为第一个dependence到了第二个,所以在dependencyMap中将原来的307改为1001。
index2.jsbundle中,删除其他行代码,只保留上面两条修改过的__d,保存为新的index2.jsbundle。
2.2.2 修改require
实际上运行上面新的jsbundle,仍然会报错。这是因为,我们还未修改入口require。报错信息可能跟AppRegistry相关。
在jsbundle的尾部,是模块的调用入口。对比可以看到,common和index2的入口id都是11。现在index2中id11改为1000,所以,需要在index2中增加id为1000的入口。最终index2.jsbundle:
__d(function(e,r,t,n,p){var i=r(p[0]),u=(babelHelpers.interopRequireDefault(i),r(p[1])),l=r(p[2]),a=babelHelpers.interopRequireDefault(l);u.AppRegistry.registerComponent('App2',function(){return a.default})},1000,[12,17,1001]);
__d(function(e,t,r,n,l){Object.defineProperty(n,"__esModule",{value:!0});var o=t(l[0]),a=babelHelpers.interopRequireDefault(o),s=t(l[1]),i=(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 a.default.createElement(s.View,{style:c.container},a.default.createElement(s.Text,{style:c.welcome},"Welcome to React Native!"),a.default.createElement(s.Text,{style:c.instructions},"To get started, edit AppNext.js"),a.default.createElement(s.Text,{style:c.instructions},"Press Cmd+R to reload,\nCmd+D or shake for dev menu"))}}]),t})(o.Component);n.default=i;var c=s.StyleSheet.create({container:{flex:1,justifyContent:'center',alignItems:'center',backgroundColor:'#F5FCFF'},welcome:{fontSize:20,textAlign:'center',margin:10},instructions:{textAlign:'center',color:'#333333',marginBottom:5}})},1001,[12,17]);
require(1000);
再次运行RN,发现可以实现分步加载common和business。
分布加载多个业务
按照上面的拆包方法,可以进一步将多个不同business拆包。按需加载business.jsbundle。native端加载对应business.jsbundle后,按照对应的moduleName来调用business。
为进一步提高加载效率,可以考虑bridge池缓存预加载好common.jsbundle的bridge,进入具体的business,注入具体的business.jsbundle。
本文介绍了RN中拆包以及分步加载jsbundle的思路。理解拆包,重要点还是在jsbundle的构成,以及RN与js的交互原理上。本文介绍的方案都很基础,如需实际操作,还需要相应的脚本协助,以及native端加载管理流程。
参考资料:
携程是如何做React Native优化的
React_Native拆分bundle之patch拆包
基于拆分包的React Native在iOS端加载性能优化
React Native按需加载 手Q狼人杀探索之路