![]()
GMTC 全球大前端技术大会是由极客邦科技旗下 InfoQ 中国主办的技术盛会，关注前端、移动、AI 应用等多个技术领域，促进全球技术交流，推动国内技术升级。主要面向各行业前端、移动开发、AI 技术感兴趣的中高端技术人员，大会聚焦前沿技术和实践经验，旨在帮助参会者了解大前端&移动开发领域的技术趋势与实践案例。
7月4日，58同城资深前端工程师蒋宏伟老师受邀参加 GMTC 全球大前端技术大会，为大家带来精彩分享。
本文整理自蒋宏伟老师在 GTMC 2021 演讲稿《58RN 页面秒开方案与实践》，分享内容亮点颇多，广受现场同学好评。
今天和大家分享的主题是《 58RN 页面秒开方案与实践》。先自我介绍一下，我叫蒋宏伟。我在 2015 年入职的 58，在 2016 年开始从事 RN 相关工作，在 2017 年成为 58RN 的负责人。这几年来，推动了不少 RN 性能方案的落地。
做性能优化，耗时是降低了，但对业务来说有什么收益呢？第一次，我确实被问住了。我就带着这个疑问，去统计首屏时间和访问流失率的关系。我发现了一个有意思的规律。首屏时间每降低 1 s，访问流失率降低 6.9%。我们拿着 6.9% 的预期收益数据，推动了几个业务性能优化的落地。整体上讲，预测的流失率收益跟实际的流失率收益其实是差不多的，但有分化。具体来讲，性能好的页面实际收益比预期收益差，性能差的页面实际收益比预期收益好。这也很好理解，性能好的页面，流失率已经很低了，进一步优化空间已经很小了。当我们知道性能优化的收益会分化后，自然把更多的关注重点，落在了那些还没有实现秒开的页面上。我们就设计了几个指标：流失率、首屏时间是事后指标，秒开收益指标是事前指标。秒开收益指标会告诉你，如果你的页面实现了秒开，你的流失率会降低多少？我们希望用这一系列的指标，来驱动业务进行性能优化。同时，我们也会给业务提供一些低成本、甚至无成本的优化方案，帮助业务的节约优化成本。用预期指标驱动业务，业务选择方案，方案提高实际指标，这就是我们设想的一个收益驱动的模型。第一部分：首屏时间采集方案。最重要的指标是首屏时间，首屏时间算出来了，流失率和秒开收益指标其实就算出来了。第二部分：性能优化方案。包括动态更新优化、框架初始化优化、业务请求优化、metro-code-split 四个部分的优化。先说下指标这一块，最重要的指标是首屏时间，首屏时间算出来了，流失率和秒开收益其实就算出来了。
我们先来看一个页面的加载流程，它大概有 5 个阶段：
第 2、3、4、5 个时间点，都可以定义为首屏时间。首屏时间定义不一样，耗时也不一样，而且差距非常大。因此，我们需要先选择一个指标，作为首屏时间的定义。首屏时间我们选择的是 LCP 这个指标。为什么呢？- LCP 是最大内容绘制的时间点，这个时候页面中的大部分元素都已经展示出来。
- LCP 可以实现非侵入式的采集，不需要业务手动的去埋点。
- LCP 是 W3C 的草案，这是一个重要的原因。你告诉别人，你的首屏指标是 LCP，别人就懂了，不用过多解释。
为了能让大家更好的理解 LCP 算法的实现，先给大家铺垫一下。用大白话讲，LCP 就是你看得到的最大元素，它渲染出来的时间。但是这里存在一个问题，LCP 是随时间变化而变化的。比如，第 2 张图片的最大元素，和第 5 张图片的最大元素，不是同一个元素，不同的元素渲染出来的时间是不一样的，LCP 也不一样。也就是说，一个页面的 LCP 值会随时间变化而变化，那应该上报哪个 LCP 值呢？应该上报最终收敛的 LCP 值，也就是可视区加载完成时的 LCP 值。LCP 是 Web 的标准，在 RN 中并没有实现，应该怎么实现呢？- 由 Native 线程，记录用户进入时的 Start 时间戳。
- 由 Native 线程，将 Start 时间戳注入到 JS Context 中。
- 由 JS 线程，在页面渲染过程中进行计算，并不断更新 LCP 值。
- 由 JS 线程，计算得到 End 时间戳，并上报最终的 LCP 值。
此时，最终上报的 LCP = End Time - Start Time。其中难点是怎么收敛 LCP，也就是如何判断可视区完全加载。我们采用的规则是，当所有元素都加载完成，且底部的元素也已经加载完成时，可视区加载完成。元素有一个调用周期，先调用 render，再调用 layout。只调用了 render 的元素，是没有加载完成的元素。调用了 render 且调用了 layout 的元素，是加载完成的元素。能够判断一个元素是否加载完成了，也就能够判断可视区是否加载完成了。讲具体方案之前，先来讲一下，我们性能优化的整体思路。
做任何性能优化之前，我们要先分析性能的结构是什么，然后找到性能瓶颈，根据瓶颈来出具体的优化方案。一个 RN 应用的性能结构，整体上看，分为 2 个部分， Native 部分和 JS 部分。再具体一点，又可以分为 6 个部分。以下是一个未优化的、比较复杂的、动态更新的 RN 应用的耗时结构：
从大体上讲，上述 6 个结构，可以分为 3 个瓶颈。
瓶颈一：动态更新
互联网产品有一个特征是快速试错，这就要求业务能够快速迭代。为了支持业务快速迭代，就要求应用能够动态更新。动态更新，肯定要发请求，要发请求就会拖慢性能，比如 Web。如果和 Native 一样，进行资源内置，性能会好很多，但又如何动态更新呢？动态更新和性能似乎是一对矛盾体，有什么权衡之策吗？我们开始想到的方案是，通过资源内置来提高页面性能，通过静默更新来动态更新。用户首次进来时，已经有内置资源了，不会有请求，页面可以直接渲染出来。与此同时，Native 线程会并行进行静默更新，询问服务端是否有最新版本，如果有就会下载 bundle，更新 cache。用户下次进来时，就能使用上次缓存的资源，直接渲染页面，并在后台同时静默更新下下次的资源。依此类推，用户每次进入时，都没有请求，可以直接渲染页面，性能很好。有一个小细节需要注意，用户每次使用的都是上次缓存的资源，而不是线上最新的资源。因此存在一种风险，一个有严重 BUG 的版本被用户缓存下来了，且不能得到更新。为此，我们又设计了强制更新功能，在静默更新成功后，由 Native 线程通知 JS 线程，由业务根据具体的情况决定是否强制更新到最新版本。- 增加 App 体积。特别对于超级 App 而言，体积已经非常大了，要增加体积很难。
- 新版本覆盖率低。72 小时新版本覆盖率为 60% 左右，相对于 Web 来说很低。
- 版本碎片化严重。多个内置版本和多次的动态更新，会导致版本碎片化的问题，推高了维护成本。
因此，我们进行了一些改良。用资源预加载，替代了资源内置。这就很大程度避免了包体积、覆盖率和碎片化的问题。静默更新依旧保留了，来更新可能出现的 BUG 版本。资源预加载的话题其实已经讲烂了，我这里给大家提供一个新视角，“权利”的角度。谁应该有预加载的权利？是 RN 框架，还是具体业务？把权利给框架，框架是可以把所有页面的资源都预加载了，但这样做明显效率很低，对于平台级 App 而言，一个 App 有几十个甚至上百个 RN 应用，大部分预加载的资源用户用不上，这就造成了浪费。把权限给业务，让具体业务一个个加载，又非常麻烦。信息即权利，谁拥有信息，权利就给谁。最开始，框架没有任何有用信息，但业务可以根据业务数据，预估预加载资源的使用概率，因此调用预加载的权利应该给业务。当用户已经使用过某个 RN 应用后，用户对该应用是有偏好的。框架知道了用户的偏好信息，这时权利应该给框架。框架可以在 App 启动后，进行版本预请求。针对动态更新瓶颈，我们使用了资源预加载和静默更新的方案。耗时从未优化的 2280 ms，降低到了 1610 ms，降幅 29%。瓶颈二：框架初始化瓶颈
JS 线程和 Native 线程是异步的通讯的，每次通讯都是通过 Bridge 进行序列化和反序列化完成的。在通讯之前，JS 线程和 Native 线程不在一个 Context 中，是不知道彼此存在的。因此，Native 不知道 JS 会使用那些 NativeModule，只能初始化所有的 NativeModule，而不是按需初始化，这就是框架初始化性能慢的原因之一。在 RN 新架构中，有计划把异步 Bridge 通讯替换成同步 JSI 通讯，从而实现按需初始化。可惜的是，目前按需初始化功能还没有实现，框架初始化的优化我们还是要做的。我们的 App 是混合应用，首页用的不是 RN。因此，能在 App 启动后，先执行 RN 内置包，初始化所有的 NativeModules。在用户真正进入到 RN 页面时，只执行 RN 业务包，这样性能自然会快上很多。该方案最大的难点是拆包。如何把一个完整的 bundle 包，正确的拆成 React 内置包和 Biz 动态更新包呢？最开始，我们用的是 google 的 diff-match-patch 算法，该算法会对比新旧文本的区别，生成一个 patch 文件。同理，可以使用 diff-match-patch 算法，对比业务包和内置包的区别，生成一个 patch 动态更新包。但是，patch 实际是一个“文本补丁”，“文本补丁” 是不能单独执行的。不能满足先执行内置包，再执行动态更新包的要求。后来，我们改造了 metro，实现了正确拆包，从而实现了框架预执行。一个完整的 bundle，由若干 module 组成，怎么区分某个 module 是属于内置包，还是动态更新包呢？内置 module 的路径或者说 ID，有一个特征，它是在 node_modules/react/xxx 或 node_modules/react-native/xxx 路径下的。可以先提前记录所有的内置 module 的 ID，在打包时，将属于内置 module 都过滤掉，生成只包含业务 module 的动态更新包。metro 拆包的动态更新包是“代码补丁”，可以直接执行，能够满足先执行内置包，再执行动态更新包的要求。其中有一个细节是，内置包中要增加一行 require(InitializeCore) 的代码，来调用内置包中 defined 的 modules。增加这一行代码，首屏耗时大概可以多减少 90 ms。针对框架初始化瓶颈，我们使用了拆包内置和框架预执行的方案。耗时从未优化的 1610 ms，降低到了 1300ms，整体降幅 43%。瓶颈三：业务请求瓶颈
动态更新瓶颈、框架耗时瓶颈优化完后，再来看一下业务瓶颈。业务瓶颈主要由业务请求和业务渲染两部分组成，请求是比较好优化的，所以我们先针对业务请求瓶颈做优化。但是，不是每个应用它都适合做缓存，不是每个应用它的数据都适合在上个页面预加载。因此，我们需要一种更加通用的方案。仔细观察一下，Init 部分和业务请求部分是串行的，是不是可以改为并行？我们的思路是，由 Native 代替 JS，在用户进入页面时直接并行的请求业务数据。- 在 Native 下载的资源文件中，会同时包含 Biz 业务包和原始的业务请求的 URL。
- 原始 URL 中会包含动态的业务参数，该变量会根据事先约定的规则进行转换。例如，将
58.com/api?user=${user}转换为 58.com/api?user=GTMC。 - Native 并行执行 Biz 包渲染页面，和发起 URL 请求获取业务数据。
- JS 侧直接调用 PreFetch(cb)，即可获得 Native 侧请求的数据。
针对业务请求瓶颈，我们使用了业务数据并行加载的方案。耗时从未优化的 1300 ms，降低到了 985 ms，整体降幅 57%。应用上述方案，大部分页面都可以实现秒开。那还有性能优化的空间吗？代码执行瓶颈
RN 页面渲染的慢的另外一个原因是，RN 需要执行完整的 JS 文件，即使 JS 中有不需要执行的代码。我们来看一个案例。一个页面包含 3 个 tab，用户进来时只会看到 1 个 tab。理论上，只需要执行 1 个 tab 的代码即可。但实际上，另外 2 个看不见的 tab 的代码也会下载和执行，拖慢了性能。将代码拆成两部分，首屏代码先执行，非首屏代码懒加载和懒执行，类似 Web 中的 Dynamic Import，这就能提高首屏性能。但 RN 官方并没有提供 dynamic import 功能，于是我们决定自己做。目前，dynamic import demo 已经在 RN 0.64 版本中跑通了。业务初始化时，可以只执行 Biz 业务包，在跳转到 Foo、Bar 两个 dynamic 页面时，才会动态的下载对应的 chunk 动态包。退出 dynamic 页面再次进入，不会再下载，会利用原有的缓存，直接渲染 dynamic 页面。RN dynamic import 的实现，我们参考的是 TC39 的规范。
业务只需要写一行代码 import("./Foo") ，就可以实现代码懒加载和懒执行。剩下的所有工作，都在框架层和平台层做了。在 runtime 运行时，业务执行 import("./Foo") 之后，框架层会去判断 ./Foo 路径对应的 module 是否已经 install。如果没有 install，就会通过 ./Foo 路径找到对应 chunk 包的 URL 地址，接着下载和执行 chunk，最后渲染 Foo Component。Chunk 包的 URL 是一个 CDN 地址，显然上传 CDN 和记录 Path 和 URL 关系的工作，不是在 runtime 运行时做的，而是在 compile time 编译时做的。在平台层的编译过程中，会将 Path 和 URL 的关系表存在 Biz 包中，这样 Runtime 才能通过 Path 找到对应的 URL。- Project：一个项目由若干个文件组成，文件之间会有相互依赖关系。
- Graph：每个文件会生成一个对应的 module，所有 module 及其依赖关系组成了一个 graph。
- Modules：给 dynamic module 的集合进行“着色”，进行区分。
- Bundles：将多个 module 的集合打包成多个 bundle。
其中最为关键的步骤是，给 dynamic module 的集合进行着色。- 分解着色：一个 Graph 的着色的情况可以分解为若干个基础的 case，这些基础 case 的着色方案是已经确定下来的。
- dynamic map：着色完成后，会将“绿色”“蓝色”这些 dynamic module 集合的 Path 根路径记录下来，并和其 bundle 的 CDN URL 地址组成一个 dynamic map。
- Path to URL：Dynamic map 会打包到“白色”的 Biz 业务包中，因此在 runtime 调用
import() 时，可以通过 Path 找到对应的 URL。
上述很多细节没有展开讲，关注实现细节实现的同学可以关注一下我们的开源工具 metro-code-split。metro-code-split：https://github.com/wuba/metro-code-split我们通过分析性能结构，找到了 3 类性能瓶颈，并产出了不同的优化方案。下图就是我们秒开方案的分类表，图中列举（预期）收益、生效范围和生效场景，希望对大家的技术选型有所帮助。这里重点和大家聊一下，RN 新架构。在最新版本中，RN 新架构的 3 个功能已经稳定，包括 JSI 同步通讯、inlineRequire 懒执行和 Hermes 引擎。其中，最让人惊喜的是 Hermes 引擎，目前已经可以同时在 iOS 和 Android 中使用了。Hermes 引擎相对于原来的 JSCore 引擎最大的区别是，Hermes 会进行预编译，在编译时就会将 JS 文件编译成 bytecode 文件，这样在运行时就能直接使用 bytecode 文件进行执行了，能够大幅减少 JS 执行耗时。经过测试我们发现，一个耗时 140 ms 的页面，能够降到 40 ms，降幅 80%。在我们为业务提供性能优化方案的同时，我们也需要关注业务的落地情况。为了能让更多业务实现秒开，我们通过非侵入式收集的方式，收集了流失率、首屏时间、秒开收益等指标。在我们的实践中，这种将技术优化与业务收益挂钩的方式，更容易被业务接受，推动起来也更容易。最后，希望我们的秒开方案和收益驱动的实践，能给大家带来启发，谢谢大家。蒋宏伟：58同城资深前端工程师，用价同城前端组组长。2015年加入 58同城，现负责 58RN 和 Hybrid 跨端框架。目前专注于大前端监控系统的搭建和落地。留一个问题：LCP 首次内容绘制算法能够适用于骨架屏应用吗？
欢迎在评论区踊跃发言，将于本周三（7月14日）下午18:00公布答案，并挑选优质回答，送出58技术周边奖品一份。