基于拆分包的React Native在iOS端加载性能优化

刘亚东 58无线技术 2017-11-24 09:52 Posted on

自从Facebook于2015年在React Conf大会上推出React Native，移动开发领域就掀起了一股学习与项目实践的热潮。ReactNative不仅具有良好的Native性能，更具备web快速迭代的能力。这两大特性使得React Native在推广的过程中顺风顺水，而且在国内互联网公司的应用比国外还火热。58 APP从2016年就开始基于ReactNative进行项目实践，并已经对外进行了一些分享。目前项目已进入React Native深度研究与实践阶段。

在ReactNative深度实践的过程中，一个关键的问题是React Native页面的加载性能。如果不对这部分进行处理，在低端机上很容易出现短暂的空白，影响用户体验。在React Native加载性能优化方面，业界已经有了一些讨论和解决方案，但在针对问题解决的系统性和可操作性方面还有所欠缺。

本文将基于主流的拆分包思想，系统性地介绍我们在iOS端处理React Native加载性能问题的经验，以期给同行提供一些借鉴，避免重复趟坑。

拆分包实现方案一：

为什么要拆分包：基于完整JSBundle加载存在的问题

58同城具体将React Native应用在项目中大概是2016年初，当时主要参考的资料是FaceBook提供的React Native文档以及官方Demo。按照文档的理解，创建RN页面的只需要创建对应的RCTRootView并将其添加到对应的Native视图中即可，因为RCTRootView是一个UIView的容器，它承载着React Native应用，因此如何创建RCTRootView成为了解决问题的关键。根据根据官方API，如下图1所示：

图1 RCTRootView API

从API文档可以看出，创建RCTRootView必须创建对应的RCTBridge，RCTBridge是JS与Native通信的桥梁，因此问题的关键转化为了如何创建RCBridge。查看React Native源码发现，如下图2所示：

图2 RCTBridge API

从API的接口可以看出，参数中的bundleURL既可以是远程服务器具体的、完整的、可执行的jsbundle的地址，也可以是本地完整的jsbundle对应的绝对路径，那么该如何选择使用哪种bundleURL？

首先对比下两种bundleURL优缺点：

1、就读取jsbundle文件耗时而言。读取远程服务器的jsbundle首先要建立网络连接，然后再读取jsbundle文件，而且依赖用户当时的网络环境状况，增加了不稳定性，显然使用本地bundleURL在时间方面更具优势。

2、就实现jsbundle文件热更新成本而言。远程服务器中的bundleURL可以实时更新不依赖native的发版。而使用本地的bundleURL，若要实现实时更新则需要一套完整的热更新平台支持。显然远程服务器的bundleURL更具优势。

3、就用户的使用APP成本而言。远程服务器的bundleURL在每次进入RN页面时都会消耗流量，而本地bundleURL则不需要消耗用户流量或者仅仅在用户第一次加载RN页面的时候消耗流量，减少用户的使用成本。显然就用户使用成本而言本地bundleURL更具优势。

综上所述，使用本地的bundleURL能更好的减少读取本地JSBundle时间以及用户使用APP的成本，提高用户体验，增强用户黏性。

但是随着使用React Native业务场景的增多，RN页面数量也随之增加，与之对应的是JSBundle文件增多。复杂的业务逻辑也会导致JSBundle体积越来越大，最直接影响就是App size增大。以实际数据为例：

一个ReactNative页面对应的完整JSBundle文件一般为700KB，如果项目中存在300个React Native页面则需要内置的资源就会增加210MB（700KB*300），显然这是无法接受的！因此如何减少内置资源体积大小是当时制约React Native能否应用到项目中的一个关键因素。在此背景下引出了引出了方案一的设计，首先了解下方案一的拆包思想。

拆分包基本思想：

通过分析各ReactNative页面的JSBundle文件发现一个完成的ReactNative页面代码结构可以分为模块引用、模块定义、模块注册三部分。其中模块引用主要是全局模块的定义,模块定义主要是组件的定义（原生组件、自定义组件）,模块注册主要是初始化以及入口函数的执行。

通过对比发现，不同的JSBundle文件包含着大量重复的代码，那么试想下能否通过优化打包脚本来对JSBundle进行优化，将框架本身的内容从完整的JSBundle中抽离出来只剩下纯业务的JSBundle文件，等到真正需要加载React Native页面的时候再将业务的JSBundle文件与重复的JSBundle文件进行合并，生成一个完成的、可执行的完整的文件，然后进行加载。事实证明这种方案是可行的，也即是项目中使用的拆分方案JSBundle的拆分与合并，简单来讲如下图3、图4所示：

图3 FE拆分图4 Native合并

简单解析一下这两个图：

JS端拆分：在打包阶段，通过特定的策略将一个完整的JSBundle拆分成两个JSBundle。

Native端合并：Native端通过文本处理，将Common部分的JSBundle与业务部分的JSBundle合并成一个文件。

拆分包实现方案一

基于以上拆分包的思想，我们可以得出所谓拆分方案就是JS端将完整的JSBundle文件通过脚本拆分为Common.jsbundle文件和Bussiness.jsbundle文件。Common.jsbundle文件是指包含React Native基础组件以及相关解析代码的JS文件，Bussiness.jsbundle文件是指包含业务代码的JS文件。Native端通过内置或者热更新平台下发的方式获取Common与Bussiness文件，待真正需要展示React Native页面时通过合并的方式生成一个完整的JSBundle文件并加载

JS端如何实现的拆包

首先我们了解下JS端如何进行jsbundle文件的拆分？整体流程如下图5所示：

图5 FE端JSBunlde拆分整体流程

1、如何获取common.jsbundle文件。

a) 首先通过React Native提供的指令react-native initAwesomeProject 来创建一个空的工程
b) 然后根据WBRN打包平台生成jsbundle文件，由于该文件不包含任何业务代码，所以该文件就是所需要的common.jsbundle文件。具体使用的指令如下：react-native bundle--entry-file ./index.ios.js --dev false --bundle-output common.bundle--bundle-encoding utf-8 --platform "ios" 。

2、如何获取bussiness.jsbundle文件。

a) 首先,不同的React Native页面通过WBRN打包平台生成不同的、完整的complete.jsbundle文件。
b) 其次,通过Google提供的google-diff-match-patch算法，将complete.jsbundle与common.jsbundle文件进行对比，最终由WBRN打包平台输出两者的差异的描述文件，也即是bussiness.jsbundle文件。

JS端的JSBundle是如何存储Native端的？

根据不同业务场景需要，通过WBRN热更新平台为不同的bussiness.jsbundle其配置相关参数信息，例如：版本号、是否需要强制更新APP、是否执行下次生效策略、jsbundle下载地址等参数。

然后通过热更新平台下发至Native端，整体流程如下图6所示：

图6 JSBundle下发Native整体流程

Native端每次进入React Native页面时向WBRN热更新平台请求当前bussiness.jsbundle的最新信息，若需要更新，则下载最新的diff并将其保存在本地，以确保本地存储的是最新的jsbundle文件。具体的流程如下图7所示：

图7 JSBundle下发Nativex详细流程

1、根据当前bussiness.jsbundle的版本号、BundleId等参数请求WBRN热更新平台，获取当前bussiness.jsbundle文件的最新信息。

2、根据返回的信息判断是否包含commonUrl来判断是否需要更新common.jsbundle文件，若需要，则下载最新common.jsbundle并保存在沙盒中同时更新common文件对应的配置文件。若不需要，则common.jsbundle不做任何操作。

3、根据返回的信息中jsbundle的版本号与本地jsbundle的版本进行比较，判断是否需要更新bussiness.jsbundle，若需要，则下载最新的bussiness.jsbundle并保存在沙盒中同时更新该bundle对应的配置文件，否则不执行任何操作。

4、根据返回的信息中isForceUpdate来判断bussiness.jsbundle是否需强制更新，若需要，则立即生效并展示新的页面。否则，展示旧页面，实行下次生效策略。

1、在common.jsbundle需要更新的情况下，无论business.jsbundle是否需要强制更新都直接展示最新的页面。

2、如果本地不存在对应的buniness.jsbundle文件，则下载对应的business.jsbundle后，无论最新信息是否为强制更新则都展示最新的页面。否则在非强制更新情况下展示旧的页面。

3、如果bussiness.jsbundle下载失败，出于用户体验的角度，如果本地存在旧的bussiness.jsbundle文件，则先展示旧的页面。

最终，Native端通过热更新平台或者内置的方式将Common.jsbundle文件以及bussiness.jsbundle文件存储在Native本地，存储的目录结构如下图8所示：

图8 JSbundle本地存储目录

从上图可以看出，存储在沙盒中的文件不仅包含common.jsbundle和bussiness.jsbundle而且包含两个plist文件，其中JSBundleIndex.plist文件就是上文提到的bundle配置文件，用于记录每个本地jsbundle对应的版本号，每次与WBRN热更新平台的最新jsbundle文件版本号进行比对，从而判断是否需要进行更新当前bussiness.jsbundle。BundleExcepion.plist文件用于记录每个本地jsbundle文件对应的异常次数，一旦某个bussiness.jsbundle文件异常次数超过一定的阈值，则会启动看门狗策略，删除本地相应的bussiness.jsbundle文件，再次进入React Native页面时从服务器下载最新的bunssiness.jsbundle文件，以确保不会因为jsbundle文件的损害导致页面一直加载异常。

Native端如何实现的合包

通过以上步骤就完成了React Native页面FE端JSBundle文件的拆分和分发，那么Native端如何使用拆分后的文件呢？关于Native加载React Native页面整体的详细流程如下图9所示：

图9 JBundle加载流程

1、根据跳转协议中的bundleId进入到对应的载体页。

2、通过缓存管理模块检测本地沙盒中是否包含bundleId对应的bussiness.jsbundle文件。若存在，则从本地读取对应的bussiness.jsbundle文件，并通过Google-diff-match-patch算法将common.jsbundle文件与bussiness.jsbundle文件进行合并，生成对应的complete.bundle文件，若不存在，则检测内置中是否含有该bunssiness.jsbundle文件，如果存在，则先执行步骤三，否则执行步骤四。

3、然后通过JSBundle加载管理模块读取complete.bundle文件，加载并展示。

4、若沙盒中和内置中均不存在bussiness.bundle文件，则通过jsbundle网络管理模块从服务器下载bussiness.bundle保存到本地沙盒同时记录其版本号，重复进行第二步骤。

5、同时向服务器请求当前bussiness.bundle的最新信息，根据返回内容来判断是否需要强制更新页面，如果不需要强制更新则后台下载并执行下次生效的策略，否则立即刷新当前页面。

6、如果当前页面已经是最新页面，则不做任何操作。

方案一数据对比：

假设完整的页面共600KB，其common.jsbundle大小为531KB，bussiness.bundle大小为70KB。以100个ReactNative页面而言，如果不使用拆分包逻辑，需要（531KB+70KB）KB*100=60M空间。使用拆分包方案一后，100*70KB+531KB=7.5M，节省空间为87.5%，如下图10所示：

图10 数据对比

方案一仍需要解决的问题

从上图可以得看出，使用方案一优化后，同样数量的React Native页面减少的87.5%的存储空间。但相对于未拆分方案其增加了两次I/O操作以及一次文件的合并操作，增加了时间消耗。高端机上增加的这部分时间消耗不太影响用户体验，低端机设备则会出现短暂的空白页面，影响了用户体验。那么是否存在一种方案可以在拆包的前提下减少JSBundle的I/O次数呢，从而减少JSBundle文件的读取时间，答案是肯定的，也即是接下来将要介绍的方案二。

拆分包实现方案二

在引入方案方案二之前首先有必要了解下React Native的整个加载过程，根据FaceBook提供的一篇文章，可以看出ReactNavtive从加载到渲染完成主要包括以下六个阶段，如下图11所示：

图11 ReactNavtive加载整体过程

1、Native Initialization阶段：主要初始化JavaScript虚拟机和所有后备模块（磁盘缓存，网络，UI管理器等）。

2、JS Init + Require 阶段:从磁盘读取最小化的JavaScript软件包文件，并将其加载到JavaScript虚拟机中，该虚拟机将解析它并生成字节码，因为它需要初始模块（大多数为React，Relay及其依赖项）。

3、Before Fetch 阶段：加载并执行事件应用程序代码，构建查询并启动从磁盘缓存读取数据。

4、Fetch阶段：从磁盘缓存读取数据
5、JS Render阶段：实例化所有React组件，并将它们发送到本地UI管理器模块进行显示。

6、Native Render：通过计算阴影线程上的FlexBox布局来计算视图大小; 在主线程上创建和定位视图。

上图清晰的记录了每个阶段占用时间的百分比，所以可以直观的看出耗时最多的是js init+ require阶段，也即是jsbundle的加载和执行阶段。

因此如何缩短js init+ Require时间是提高RN页面展示速度的关键也即是方案二所要解决的问题。接下来详细分析下React Native load JSBundle和执行JSBundle文件的过程：如下图12所示：

图12 JSBundle 加载代码片段

以上是React Native框架load JSBundle的相关代码片段，从上图代码中可以看出，片段1主要是执行的是JSBundle的加载过程。片段2主要是初始化组件，片段3主要是初始化组件配置表config，并将配置表注入到JSContext中。片段4主要是执行js操作。那么如何实现加载过程的优化呢？

实现方案二的理论猜想：

如果能有一种方式可以使React Native分步加载JSBundle并且不需要合并，那么就能减少1次合并操作与1次读取complete.jsbundleI/O操作，理论上就可以有效的缩短页面加载时间，事实证明这种方案也是可行的。因为JSContext是由GlobalObject管理JavaScript执行的上下文,在同一个GlobalObject对应的同一个JSContext中执行JavaScript代码，执行多个JavaScript是没有区别的，所以在同一个JSContext中分步加载common.jsbundle与bussiness.jsbundle效果应该是一样的。