携程RN渲染性能优化实践

旧城等待， 2023-02-21 12:59 143阅读 0赞

**一、背景**

随着 React Native 在前端业界规模性的应用越来越多，各大厂也对其渲染性能越来越看重。

渲染性能的主要评判指标是FMP与TTI，在 React Native 以跨平台前端框架身份逐步替代 Native 原生界面的同时，两者的渲染性能对比也逐渐浮出水面。

同时，渲染性能调优在业内已存在许多可借鉴的经验，而在项目实践的过程中，往往能体验到现实与理想的巨大差距。

参考业内先行者的经验，针对线上项目做渲染性能优化时，往往会出现事倍功半或不尽人意的情况。

概括主要原因是以下几个方面存在问题：

1）缺少可量化的渲染性能评判标准

2）缺少可量化、可视化的优化工具

3）简单堆砌式的使用多种优化方式，容易相互抵消优化效果

4）优化方式仅局限于前端，忽略了 Native 或 Service 优化方向

本文将从理论方案、实操经验以及实用工具三个方面介绍携程在 React Native 渲染优化方面的经验，希望能给业内的前端伙伴提供实际的帮助与启发。

**二、评判标准**

评判标准是基于用户交互体感实践出的量化数据，数据达标的界面可做到近似Native 界面交互体感，其中FMP和TTI是渲染优化的两个重要指标。

**2.1 FMP**

用户交互中，“白屏”体感的特征指标。

“白屏”的原因简单概括如下：

*  Bundle 包热更新
 *  启动 React Native 容器
 *  业务代码加载耗时
 *  服务请求耗时

但FMP耗时并非越短越好，若业务逻辑较为复杂，一味地缩短FMP容易造成TTI耗时过久，在整体性能优化上适得其反。

**2.2 TTI**

用户交互中，“直出”体感的特征指标。

该指标同样经过实践，得出1.6s和1.2s两条符合良好用户体感的数据线。

*  1.6s是正常发送服务请求界面的基准
 *  1.2s是采用提前发送服务请求界面的基准

与FMP不同的是，TTI耗时越短，用户“直出”的体感越好，但也需注意界面功能的完整性（如功能阉割、功能操作延迟较多等情况）。

**三、优化方向**

有了可量化的评判标准后，可以针对性地确认优化方向。

以携程国际机票列表页为例，如图所示从开始调整至界面渲染结束，主要分为FMP与TTI两个阶段。

![format_png][]

理论上，减少这两个阶段的耗时，就可提升渲染性能。

下面将从客户端（Native）、前端（React Native）、服务端（Service）三个方向来作详细讲解。

**3.1 客户端（Native）**

**3.1.1 React Native 容器**

**Hermes 渲染引擎切换**

Facebook 发布的 Hermes 引擎，在实践中的效果优异，iOS与Android端的TTI指标有明显降低。

有兴趣的同学可看下这篇文章：[Hermes引擎分析][Hermes]

**React Native 容器热启动**

当 Native 打开一个崭新的 React Native 界面时，需要经过如下步骤：

![format_png 1][]

其中启动 React Native 容器至加载业务代码所消耗的时长是FMP指标的关键因素。

而容器热启动的意义在于将界面加载过程中的必经流程提前运行，加快界面渲染的速度。

通常，当有多个界面采用流式加载的方式时，再前一个界面调用 Native API 提前启动下一个界面所需的 React Native 容器。

**React Native 容器复用**

当多个界面采用流式加载，往往会存在ABAB 式的用户流水。

![format_png 2][]

由于A界面在打开B界面的时候，是作为一个容器被B界面遮罩，并没有被关闭，所以A界面只被打开了一次；而B界面在这用户流水过程中实际被打开了两次，即返回A界面时，B界面的容器就被销毁了，同时其中的 React Native 容器也被销毁。

基于上述场景，可以发现优化点在于容器及其中的 React Native 容器内容可以被缓存，便于下一次进入时可以被复用。

这里需要注意两个风险点：

1）过多的容器及其中的 React Native 容器内容被缓存时，容易造成内存溢出，从而引起 App Crash；

2）复用 React Native 容器内容时，会保持上一次会话的全局变量，容易造成业务逻辑错误。

**3.1.2 Bundle**

**Bundle 预下载**

在非业务型界面中，提前下载之后可能会被打开的业务界面 Bundle（若有更新增量存在）。

该方案仅对 Bundle 提前进行下载操作，并不会进行增量文件加压及更新。

使用该方案后，会面临如下的问题：

1）App中的界面数量往往比较多，全部使用 Bundle 预下载可能会造成网络下载列队阻塞，影响正常使用。

2）Bundle 存在下载失败的概率，会丧失预下载的想要达到的效果。

针对上述可能出现的问题，需要进行深度优化：

1）预下载的时机需要符合如下几个条件：

*  利用底包优势，以 Native 实现的界面
 *  业务改动频率较低
 *  具备一定停留度的界面

2）采取优先级异步多线程下载策略，按不同维度设定优先级，如 Bundle 使用率。

3）重试机制，类似 setInterval 轮询增量更新列表

**Bundle预加载**

在 React Native 容器热启动之前，解压 Bundle 文件并更新。

通常配合 React Native 容器热启动和 Bundle 预下载使用。

Bundle 的加载完成了下述3件工作：

1）更新Bundle文件

2）编译JS代码

3）执行JS代码

随着 React Native 容器采用 Hermes 引擎，Bundle 被打包为单个文件，相比使用 JSCore 被打包成多个文件来看：

1）更新 Bundle 文件阶段，单文件的更新速率优于多文件

2）编译JS代码阶段，单文件减少了多个文件加载耗时

**3.1.3 Native To React Native API**

**Sync 同步**

React Native 与 Native 之间采用异步通信机制，当线程繁忙时，会产生阻塞和等待。

另，在首屏渲染过程中，内存获取数据比较慢的场景也会出现，耗时可能高达200ms。

解决上述问题，主要有以下几个方向：

*  对内存读写数据类 API
 *  Sync API 耗时可控在毫秒级
 *  Chrome Dev 不支持 Sync，需特殊处理
 *  有利于解决阻塞依赖 Native 异步接口调用的场景

此时，使用 Sync 同步方案显得可行，可解决如下场景：

*  获取 ABTesting 实验号
 *  获取本地 Storage 内容
 *  获取功能开关列表
 *  获取屏幕 Size
 *  SOTPCookie

**3.2 前端（React Native）**

**3.2.1 Bundle 瘦身**

Bundle 中存在几种文件类型，针对不同类型选择不同的优化方案：

*  代码字符串
 *  Iconfont 字符串
 *  图片文件

**代码字符串**

冗余代码是代码 Size 的主要问题，而冗余代码的产生主要源自于四个方面：

*  已下线的需求代码
 *  已结项的实验代码
 *  NPM 冗余调用
 *  缺乏抽象的重复代码

解决方案：

*  整理已下线需求，删除相应代码及库文件
 *  使用组件库及方法库，减少重复代码
 *  抽象可复用的组件，使用高阶组件

**图片文件**

在打包压缩过程中，图片文件的压缩比极低，越大的图片占用的 Bundle Size 越大。

解决方案：

*  较大的图片在保证清晰度的前提下压缩后打包
 *  视业务场景使用网络图片替代
 *  较小图片可以使用 IconFont 替代

**3.2.2 模块**

**LazyRequire**

在编译过程中，import会被编译成 require，require 所完成的功能是读取JavaScript 模块并执行。

而大模块的执行会耗费较多时间，使得界面加载速度变慢。

因此，优化的方向是当模块被需要才加载。但 React Native 提供的标准 require 目前并不支持动态加载。

需要修改 React Native 源码的打包功能，使其支持动态加载功能，并提供出对应的 API 来供业务方实现。

使用示例如下：

import {lazyRequire} from 'react';
    let moduleA = lazyRequire('../src/ModuleA');

**动态加载**

使用 import 语句导入模块时，会自动执行所加载的模块。而当使用组件库或公共方法库的时候，往往并不希望如此。

假设 Common.js 文件为公共方法库

import A from './A';
    import B from './B';
    import C from './C';
    export {
        A,
        B,
        C
    }

此时若希望只引用 Common.js 中的A模块，即

import {A} from './Common.js';

但实际B和C模块代码也被执行了。

为了使程序能如你所愿的仅执行A模块，需要使用属性 getter 动态 require 的方式来修改 Common.js 文件。

这样在使用到A模块的时候才会执行 require('./A').default，并不会加载B和C。

至此，使用该方式导出模块可以减少引用模块时的无效加载数量，达到优化渲染速度的目的。

**3.2.3 渲染方式**

**骨架屏/呼吸态**

骨架屏是有效减少用户体感“白屏”的有效措施，通常在骨架屏完成耗时较长的关键性任务，如核心服务请求、重要异步回调等。

同时，骨架屏也是缩短 FMP 标准的重要方法，主要方式：

*  减少加载骨架屏之前的非必要模块引用
 *  核心服务请求参数的拼接可放在骨架屏渲染之前完成
 *  骨架屏自身的渲染结构足够简单

**分批次渲染**

分批次的概念主要运用在列表型界面或内容型界面。

顾名思义，是将界面需展示的内容，分成不同阶段/批次进行渲染，阶段/批次的数量根据业务自身情况而定，往往以覆盖满屏幕的主要区域为宜。

该方案对提升TTI有较大作用，可数量级的减少渲染内容，从而降低渲染耗时。

**渐进式渲染**

React Native 渲染的本质是将 JSX 构建的虚拟 DOM 树通过 Native Render 的方式绘制界面内容。

虚拟 DOM 树结构越复杂，Native Render 所需绘制的时间也越长。

从这个特性出发，可以通过降低虚拟 DOM 树结构的复杂度来减少渲染耗时，用尽可能短的时间到达 TTI 阶段。

降低虚拟 DOM 树结构复杂度的底线是最低程度得保证业务功能的完整性，而在其渲染完成后（达到TTI阶段），通过 setState 去更新渲染完整的虚拟 DOM 树结构即可。

下面两幅图在渲染过程中采用了渐进式渲染，可观察航空公司部分：

![format_png 3][]

**延迟渲染**

界面在相对复杂的情况下，渲染的模块会比较多，渲染的耗时也会随着需要渲染的模块数水涨船高。

对待渲染的模块区分核心和非核心，或者区分模块需渲染的轻重缓急，优先渲染核心/重要的模块，符合界面基本交互功能（达到TTI阶段），再渲染非核心/次要模块来完成整个界面的渲染工作。

**按需渲染**

界面中不可避免的会存在一些浮层或者二级界面，下面统称为次级界面。

这次次级界面在TTI阶段前，大部分是不需要进行渲染的，可以配合 LazyRequire 的方式完成。

**预渲染**

空间换时间的经典方案。

假设存在流式界面A -> B，若能在A界面时能够提前渲染B界面的话，理论上可以做到在打开B界面时做到“直出”效果。

若要做到上述方案，需要结合多个优化方案，这里只分析“预”的实现方式。

在A界面时，通过 Native API 热启动一个新的 React Native 容器，同时在新容器内预加载B界面的 Bundle 并执行。

当从A界面进入B界面时，由于B界面已经完成/正在渲染，B界面可达到“直出”效果。

**优化结构**

虚拟 DOM 树的结构越复杂，所需消耗的渲染时长也就越久，也就越晚到达 TTI 阶段。

首先，通过工具去观察虚拟 DOM 树结构的深度和广度，使用渐进式渲染方案减少深度，同时也使用分批次渲染方案减少广度。

其次，由于研发过程属于 TeamWork，一个结构合理的 UI 组件库可以大幅减少优化结构所需的工作量。

**3.3 Service**

**优先发送服务请求**

从进入界面到渲染界面完成（即TTI阶段）需要经过许多代码逻辑阶段，研发人员需要理清这些逻辑阶段的依赖关系，并做出优先级的策略。

为了更快的将服务请求发送出去，利用等待服务返回数据的时间差去运行其他渲染所需的逻辑，待服务数据返回后再去渲染界面。

但需要注意的是，若服务返回时间较长，可能会子执行完其他逻辑时进入 render阶段，当服务返回数据后再次 render，造成 TTI 阶段耗时有所延长。

解决方案是采用服务预搜索后，使用同步请求服务数据的方式来避免重复/无效 render。

**按需异步获取数据**

类似按需渲染的场景，同一个界面需要请求的服务个数往往不止一个，除了渲染界面主要模块所必须的核心服务外，其他次要模块的服务请求可以放在 TTI 阶段后请求。

![format_png 4][]

图中红色部分的模块，在渲染的界面中并不属于核心模块，可以采取延迟按需请求的方式获取数据后再进行渲染。

**服务预搜索**

除静态界面外，几乎所有 CSR 界面都需要在渲染过程中发送服务请求，再根据服务请求返回的内容渲染界面。

等待服务请求响应的时长将直接拖慢到达 TTI 阶段的耗时，而提前发送服务请求是否可行？

前端在发送服务请求前往往需要拼接较多的请求参数，这些参数中存在很多变量，而变量的来源有许多是来自于用户交互。

正因为这样的场景较多，提前发送服务请求的难度也陡然上升。同时，也会给服务端带来请求数量成倍增加的副作用。

处理的方式有以下几种，可根据业务形态的不同进行选择或组合：

*  区分业务不同场景，针对大部分场景做提前请求服务的操作
 *  需要依据多个用户交互结果作为请求参数的场景，可配合 BI 用户模型做到较精准的提前请求

在提前发送请求服务后，在进入下一界面时，代码逻辑仍然会正常发送服务请求，这里需要做好网络缓存。具体操作方式如下：

*  请求服务时，根据请求的 url 和参数通过 Hash 生成一个唯一的 Key
 *  请求返回时，将返回的数据存入本地
 *  在一定时间内，发送相同 url 和参数的请求，都会匹配已生成的 Key，从本地拿取数据返回，而不进行真实的网络请求

**四、实践工具**

每个项目/界面的业务逻辑不同，从而代码逻辑也不相同。显然在优化不同界面时，采用的优化方案也不同。

那么，在优化界面过程中该如何选取适合的优化方案，显得尤为重要，而这个过程中，经验并不能起到决定性的作用。

需要借助线上和线下两方面的工具来完成性能分析工作后，再依据经验选择合适的优化方案。

**4.1 Offline**

借助 Chrome Devtool Performance，可以分析运行时的性能表现，主要借助以下两种方法采样性能数据。

*  调试环境：通用的 Web 性能分析方案，打开 React Native 调试功能-->运行项目-->采样数据。
 *  真机环境：在测试环境中修改 React Native 代码，模拟 Profile 数据结构生成埋点数据。

以上两种方法存在部分差异：

*  调试环境：采样数据来自于模拟器，数据的真实性存在偏差，多用于快速试验优化方案效果。
 *  真机环境：采样数据来自于真实机型，数据的真实性较为可靠，多用于验证优化方案效果，以及针对特殊机型验证优化效果。

两种方式采样到的性能数据，分为 Timing 和 Console 两种。

**4.1.1 Timing**

作用是分析视图组件渲染顺序与耗时，如下图使用 Timing 火焰图，在视图渲染层面分析性能：

*  组件渲染顺序与耗时：“火焰模块”的长度标识组件渲染耗时（包括其子组件），至上而下可以分析组件的渲染顺序。
 *  组件间渲染空闲时间：通过两个“火焰模块”之间结构，分析各模块组件之间的渲染顺序，其中空白部分表示组件渲染空闲的耗时。

![format_png 5][]

**4.1.2 Console**

作用是通过代码执行层面分析性能，如下图使用 Console 时序图分析性能：

*  代码块执行耗时：单个模块表示该代码块执行的总耗时，可以更直观的分析代码块的执行顺序。
 *  异步与同步代码之间的关系：简单的埋点计时并不能精确计算异步耗时，而模块与模块之间的叠加关系，可以直观分析异步代码的执行耗时。

![format_png 6][]

**4.2 Online**

业务代码在上线后，存在许多环境因素，如网络情况、机型覆盖面、OS系统、Bundle 更新及解压等。

性能优化的目的是让用户切实提升使用 App 的感受，线上性能数据采样就成了重要的试金石。

线上性能数据采样主要记录的是界面渲染的 TTI 和 FMP 耗时点，采样的方式主要采用屏幕像素检测，检测用户访问的界面屏幕渲染出像素点的耗时。

采集到 FMP 和 TTI 数据之后，根据 App 版本、OS 系统类型、时间周期等维度进行拆解，绘制出对应的性能波形图和P90覆盖情况。

## 具体可见文章[《携程无线APM升级实践》][APM]。 ##

**五、小结**

渲染性能已然成为大前端工程师必须面对的一道课题。本文通过工具及方案的介绍，将前端优化的视野打开，更加系统得看待渲染性能问题。

叠加使用各种优化方案在优化渲染性能方面具备一定的普适性，部分优化理论同样也适用于 H5 与 Native 平台。

## 关于奇舞周刊 ##

《奇舞周刊》是360公司专业前端团队「奇舞团」运营的前端技术社区。关注公众号后，直接发送链接到后台即可给我们投稿。

![format_png 7][]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxY3kxU3kzZ0EweW8zM3NpYWdpYUdtam1RYXpnQ3QxQTVKcXhQb3A2ZXNXcjkzeVptbVJYdGlhVEhwY1ROZnhkNWlhbUczeWpMZks2ZWtmZWcvNjQw?x-oss-process=image/format,png
[Hermes]: https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ%3D%3D&idx=1&mid=2697268816&scene=21&sn=17a0aa1d1dc5adf1e65642bc5088701c#wechat_redirect
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxY3kxU3kzZ0EweW8zM3NpYWdpYUdtam1RVTI4U3lIdTFRWjVRdFh2MjZpY3NOQVN5MENZRE5BVUNraDVORXNuaWNxVVZzQXlFTWhsTzkwYWcvNjQw?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxZXVXVFBpYjVDQWdubkhHVEZSQU9DYnUyR012a0NLS1NMMjNpYlhvMDJtNVlpYmljRDNSZ0NtMlZ1QUlNNWliaE1YdUJ1c3cxSW1sVTZ4aWF5QS82NDA?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9rRWVEZ2ZDVmYxZXVXVFBpYjVDQWdubkhHVEZSQU9DYnVsR25pYVBKVU9TenBxSXBGNXhVQ1FRREZFaWM3WlhwQk1IQzRibjRCWnNPVmtQRk45cm1pYXlqa2cvNjQw?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxY3kxU3kzZ0EweW8zM3NpYWdpYUdtam1RMGtvZ1BMMkpxWk9QWUszWXpBemljMG54TzZrVFZFejRQek11TjFTSDdyR3JuZ2N0QXhib3pkdy82NDA?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxY3kxU3kzZ0EweW8zM3NpYWdpYUdtam1RSmtIbXR4N293S3JURUh4STB3Z3d6WXJlVlBBQllvN1RNMGJmNzRJMWxBc0swdmhkaGxMd0J3LzY0MA?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9rRWVEZ2ZDVmYxY3kxU3kzZ0EweW8zM3NpYWdpYUdtam1RWlNxRnd4N2VJUjVTMUNGZUdoZm1IRU1Udloxb2x0ZWlhVVlLSXNROERMTGJ0c0JScGNNUkxrdy82NDA?x-oss-process=image/format,png
[APM]: https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ%3D%3D&idx=1&mid=2697269379&scene=21&sn=1227a77caf29ae0e732d976f3f909540#wechat_redirect
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9NcEdRVUhpYWliNGliNmo5WDlzMmtpYmZhaWNCTG1JbTZkVUJxeW1WbWlhS3FHRkVQbjBHM1Z5Vm5xUWp2b2duSHE0Y01pYmF5VzI0MDBqNE95RXRkejVma01ibUEvNjQw?x-oss-process=image/format,png