一、背景
满帮集团移动团队2018年初开始尝试React Native，经过近三年的发展，目前已经承载了大部分的核心业务场景，涉及16+的业务模块、200+页面，日均PV数据在千万级。核心业务也使用React Native开发后，我们脱离了APP发版的限制，统一使用动态发版。相比于APP发版，动态发版频率提高了很多，一周最低两版，有时一周甚至会发5个版本。
2018年上线React Native时，用的是当时比较新的0.51版本。在后续的版本中，Facebook官方引入了诸多新的特性，比如Hooks、Hermes引擎等等。我们继续使用0.51版本，这些新特性都无法使用，而且社区中很多基于更新版本ReactNative的第三方库业务也无法使用。因此，在使用0.51版本3年之后，我们决定升级到目前较新的0.62版本。
二、0.62版本改进
在之前，我们一直使用的是0.51版本，不过，在经过近两年的迭代后，React Native发布了0.62版本，并且0.60以上版本相比之前的版本，性能有了大幅的提高，主要体现如下。
2.1 性能提升
相比于0.51版本，0.62最大的改进是，android上使用了Hermes作为JS执行引擎，在启动速度、内存占用、JS运行效率上都有非常大的提升。
2.2 稳定性提升
从0.51版本到0.62版本，修复了大量功能性和稳定性bug，比如Native 部分的SDK的健壮性得到了很大的加强，例如Android中 ReactHostView，在 show() 和 hide() 的安全性都进行了加强。又如ViewManager 部分， 不合法时直接进行了异常处理。
2.3 社区生态
ReactNative生态主要分为两部分：
React 本身语言特性。
0.51 使用的是 React 16.0， 0.6x 使用的是 16.11.+， 中间新增了很多令人兴奋的新特性，例如 16.2.0 的 Context 、 16.8.0 的 Hooks , 这些无疑是开发的利器！
React Native、React第三方库
社区的第三方库往往两年一个周期提高 React 的依赖版本，例如比较有名到导航库 :
React-Navigation , 并且增加很多实用的新特性, 例如 ReactNative 内部路由栈开始支持页面间的激活、回到后台等特性。这在我们日常开发中非常实用。
2.4 Android端性能
0.6x开始，Android端引入了Hermes引擎，带来了很大的性能提升。相比于JSC，Hermes最大的改进是支持直接运行JS代码预编译的产物，因此冷启动性能上有很大提升，同时内存占用也有一定下降，但是包体积增大了一些。
为了了解清楚性能提升数据，我们在Android端对JSC和Hermes进行了性能对比测试，测试设备：VIVO X21 RAM：6G。
2.4.1 冷启动耗时数据
从上图可以看出，Hermes+HBC的冷启动耗时相较于JSC+JS下降了50%以上，因此我们决定使用Hermes+HBC的方案。
2.4.2 包体大小数据
从上图可以看出，HBC二进制包的压缩比明显不如Jsbundle, 体积几乎是后者的两倍, 但是这一点可以通过后续的拆包, 端上转化HBC 等手段规避。
2.4.3 代码指令处理速度
面对大量运算以及解析的时候， JSC 性能衰退特别严重，而Hermes则相对平稳, Hermes 和 JSC 耗时比基本在 1/6 左右, 出色的处理速度对帧率、 动画流畅度都有很大的提升。
2.4.4 内存占用
从上图测算出来的数据可以得出两条结论：
1、ReactNative 0.62 内存表现明显优于 ReactNative 0.51，这得益于Hermes的加载机制，不会把整个文件一次性load进内存解析。
2、ReactNative 0.62 的内存抖动较平缓， 这得益于 Hermes 执行的产物是二进制， 而非JS代码，不需要二次转码。
整体操作流程，涉及 4 个 ReactInstanceManager 和 5个页面， 节省了 56 M 内存空间，收益确实可观。
2.5 iOS端性能
从0.51升级到 0.62后，iOS端的JS引擎依然只有JSC。但是在Jsbundle之外，支持了RAM格式， 采用RAM 以及 inline方案，冷启动速度和内存都可以得到很大的改善。但是考虑到我们后续要做基座拆分，因此没有使用RAM格式，iOS端依然使用JSC+Jsbundle的方案。因此，iOS端在内存、冷启动、指令执行速度上并没有太大提升。不过最近发布的React Native 0.64 版本，官方在iOS上也开始支持 Hemers。
从性能数据上看，Android端性能有非常大的提升。升级后也能使用hooks等React的最新特性，提升开发效率，因此我们决定升级到0.62版本。
三、执行一次无感知升级
3.1 挑战和风险
3.1.1 多部门合作协作
如前所述，ReactNative承载了满帮大部分的核心业务场景，涉及16+业务模块，200+页面，50+开发人员。满帮集团的业务在高速发展期，各种业务运营活动的开展都以天为单位计时。业务多、人员多、迭代节奏快、稳定性要求高。需要统筹多个测试、开发团队以及发版团队等多条线的工作。
3.1.2 SDK升级与高频率发版并行
为了满足快节奏的业务迭代，我们每周最低发布最低两次动态版本（最高一周能发布5次）。我们要求技术改造不能影响业务迭代（包括APP版本迭代和动态版本迭代），任何业务需求不能因为技术改造而延期。因此我们需要 0.51 发版工作和 0.62 升级工作同步进行， 而且要互不干扰。
3.1.3 降低升级成本
快节奏高频率的发版下，SDK升级不能给业务需求的开发、测试带来过多的负担，需要把对业务开发、测试的影响尽可能的降低。本次升级作为跨越3年的大版本升级，涉及到非常多的 Release Note，我们需要尽力从底层兼容这些差异性，从而尽可能得降低开发人员修改面以及降级测试人员的回归力度，近而降低各方面的成本。
3.1.4 保证线上稳定
满帮集团核心的两款APP日均UV在500万级别，对APP体验的要求又非常严苛，异常率上升万分之一，都会导致客户投诉率提升，稳定性保障是升级方案的重中之重。但是，无论我们方案做得多完美，谁也不能保证不会有意外状况发生。因此我们需要在第一时间感知到线上异常，降低影响并及时修复。
本次React Native SDK升级，就像是给一辆以120码高速行驶的重型卡车更换轮胎，稍有不慎就会翻车。
3.2 升级方案原则
3.2.1 低风险
主要主要包括两点：
1.业务风险低：不影响业务需求的迭代。
2.稳定性风险低：不影响线上的稳定性，异常率要控制在极低的水平。
3.2.1.1 发布方案设计
为了满足上面两个条件，我们决定采用分批次、灰度的方式发布上线。
分批就是把线上用户分成多个批次，一个批次上线完成后再进行其他批次的。满帮有四款APP:运满满司机端、货车帮司机端、运满满货主端、货车帮货主端，我们结合业务特性分析后，采用的方案是两个司机端第一批上，两个货主端第二批上。
灰度放量现在业内用的非常普遍了，这里不再解释含义，下文中会详细说明灰度方案的细节。
3.2.1.2 告警和回退方案设计
真正做到低风险，我们还需要把线上问题扼杀在摇篮， 我们需要告警机制。升级前的满帮ReactNative已经有告警机制，因此我们只需要把 0.62 拆分出一个统计维度单独计算， 因为前期灰度的量少，如果和原先的告警机制复用就很难触发告警条件。
遇到线上顽疾短时间内无法解决的我们还需要有降级方案，能够短时间内把线上的 0.62 切换到 0.51， 待问题解决后再切回 0.62.。
3.2.2 低成本：
这里的低成本是指对业务开发、测试的影响尽可能的降低。降低代码修改量、修改难度，从而降低开发投入的人力成本；降低影响范围，从而缩小测试回归范围、降低回归力度，从而节省测试投入的人力成本。
3.2.2.1 一套代码
为了降低风险，我们采用的是多批次灰度放量的形式发布上线，整个上线周期会持续很长一段时间，在上线期间，各个业务模块都在不断的迭代开发新的需求。也就是说，存量的业务代码和新需求的业务代码，都要兼容两个版本的SDK。要兼容两个版本的SDK，最简单的方案是维护两套代码，分别适配两个版本的SDK，但是这样需要写两遍代码，对业务开发来说是非常沉重的负担。为了避免这种负担，我们提出了一套代码适配两个版本SDK的方案。
3.2.2.2 开发环境切换
一套代码适配两个版本SDK，代码当然要放在一个分支上。在开发业务需求时需要分别在两个版本SDK环境上运行代码，我们提供了环境切换脚本，可以使用一行命令切换到不同的ReactNative环境上。比如：司机端在线上已经进行灰度放量了，货主端还没有开始放量，对于需要同时在司机&货主两端运行的代码，开发人员可以通过脚本切换到不同的环境进行开发, 如下图。
3.2.2.3 代码修改扫描
为了进一步降低开发人员的适配成本，我们开发了专门的脚本工具，可以扫描出所有需要修改的地方，并给出具体的修改方法。
采用如上的方案，我们做到了升级风险完全可控（通过多批次灰度升级控制稳定性），又把开发人员的适配成本将到了最低（通过一套代码适配两个版本的SDK和脚本扫描修改内容）。
四、前期准备
4.1 API changes梳理
升级之前，需要先梳理两个版本SDK之间的API差异，对0.51到0.62的所有修改有全面的认识。API change分为两种：
- breaking change
- 非breaking change
我们的方法是暴力阅读了0.51~0.62所有版本的Release Note，整理出了所有breaking changes，并给每个breaking change制定专门的适配方案。例如AsyncStorage，0.51版本的AsyncStorage用法是xxx，0.62版本的用法是yyy，所以0.51版本的代码和0.62版本的代码互相不兼容。我们的适配方案是统一采用我们自己封装的Bridge[MBBridge.app.storage]。
//npm install --save @react-native-community/asyncstorage
不建议使用
// import AsyncStorage from '@react-native-async-storage/async-storage';
// 建议修改为Bridge形式
// 根据KEY获取VALUE
MBBridge.app.storage.getItem({ key: BootPageModalKey.KEY_IS_SHOW_BOOTPAGEMODAL }).then(res => {
if (this.isGuidanceSwitch(res?.data?.text)) {
retuReactNative null
}
})
// 存储<KEY,VALUE>
MBBridge.app.storage.setItem({ key: Constant.StorageKey.Common.RefeReactNativeame, text: commonStore.refeReactNativeame })4.2 代码适配方案
公司业务迭代节奏是一周三版甚至更多， 且主要使用的是ReactNative技术栈, 因此如果在如此快节奏的开发节奏下还要同步两套代码(0.51 && 0.62) , 那成本就太高了。因此我们觉得采用一套代码能够同时适配 0.51 和 0.62的方案：对于所有不兼容的API，封装一层适配层，屏蔽底层差异。如下图所示：
例如，导航库的适配思路如下：
修改前如下
import { StackNavigator } from "native-navigation"
const RootStack = StackNavigator(...)
export default class xxxx extends Component<any, any> {
render() {
retuReactNative (
<RootStack screenProps={this.props} />
)
}
}修改后，ReactNative-lib-protocal 就是我们的协议层
import { createStackNavigatorCompat, createAppContainerCompat } from "@ymm/ReactNative-lib-protocal"
const RootStack = createStackNavigatorCompat(...)
export default class StickerPageRouter extends Component<any, any> {
render() {
const App = createAppContainerCompat(RootStack)
retuReactNative (
<App screenProps={this.props} />
)
}
}然后，协议实现层代码如下。
import { NavigationActions } from 'react-navigation';
export default class StackActionsCompat {
static reset(resetAction: any){
retuReactNative NavigationActions.reset(resetAction)
}
static push(pushAction: any) {
retuReactNative NavigationActions.push(pushAction)
}
static pop(popAction: any) {
retuReactNative NavigationActions.pop(popAction)
}
static popToPop() {
retuReactNative NavigationActions.popToTop()
}
}这样业务开发同学就可以实现一套代码跑在两个React Native版本上， 节省维护两套代码的成本。
4.3 脚本工具
这里的工具包括三个：
1、 API检查工具(支持本地 && CI/CD)；
2、代码工程环境切换工具；
3、运行环境检查工具。
4.3.1 API检查工具
API检查工具是为了检查那些在 0.51 环境能运行而在 0.62 上不再兼容的API，为了解决这个问题， 我们针对两个版本众多变动点抽象出API检测的规则。检查工具使用 Python 脚本编写，开发同学既可以在本地检查(直接运行python脚本或者运行npm命令) 也可以在Jekins打包时启用该检查， 检查效果如下：
4.3.2 环境切换工具
工程环境切换工具则是为了方便开发同学能够方便得切换 0.51 和 0.62 的协议实现层 和 配置文件(package.json、metro.config.js 等) ，这块可以用 Shell 或者 Python 实现。
这个工具保证了业务开发同学能够在一个分支上进行开发，而不用把关注点放在 0.51 和 0.62 的API差异和配置差异上。
4.3.3 环境检查工具
运行环境检查工具则是为在测试环境检查 ReactNative SDK 环境和 Bundle 产物不匹配的情况，例如 0.51 原生SDK加载了 0.62 的 Bundle/HBC， 或者 0.62 原生SDK加载了 0.51 的Bundle 包，从而避免不必要的麻烦以及沟通成本：
五、落地方案
下图是我们升级计划的一个简图， 整个流程以角色为纬度，划分为四条主线： 开发人员、测试人员、APP版本、 动态版本。每一条主线对应的时间轴在关键时间点都有详细的Action。
例如：对于业务开发人员(第一条线)来说, 需要在 2020-12-18 日把适配的业务代码合入 dynamic-1231 主发布分支，随后 0.51、0.62 公用一套代码直至整个升级流程结束。
5.1、分批升级
如前所述，我们采用的是分批升级的方案，司机端APP第一批上线，货主端APP第二批上线。
Android端为了这次升级，对 React Native 的环境进行了插件化。为了尽可能的控制风险，第一批次Android司机端上线是通过插件动态发布的形式进行的：0.62版本的SDK和HBC的产物同时通过动态升级的方式下发到端上。动态发布的方式可以非常灵活的控制灰度节奏：为了确保稳定性，我们可以把灰度时间拉的足够长。而且，我们的动态升级平台支持线上实时回滚。
我们基于稳定性的角度出发，决定Android端通过动态升级的方式上线。但是保证稳定性的同时，也不能影响业务需求上线，0.62版本的SDK和HBC产物在线上灰度发布的同时，也会基于0.51版本的SDK和jsbundle产物同步做业务需求的发布。也就是说：0.51 和 0.62 环境需要在较长时间的在线上并行存在。
整个灰度过程中比较重要的一点是线上环境的功能同步问题：0.51 和 0.62 的产物会分别以各自的节奏发布到线上，不能相互干扰，但是同时又都必须包含所有的业务需求。
例如：0.51 每 2 天一个版本， 而 0.62 灰度周期是 10 天， 因此需要保证用户无论使用的是 0.62 还是 0.51 都需要包含最新的功能， 我们的策略如下：
如上图所示，0.51 和 0.62 的发布是两条平行的线， 0.62 的版本号在设计上要大于 0.51的版本号(保证了0.62 的产物永远不会被 0.51 的产物覆盖)，每一次 0.51 业务包的发布都会同步发布一个 0.62 的业务包，因此可以保证以下两点：
1、线上用户使用的功能始终是最新的；
2、0.62产物始终按照自己的节奏灰度， 不会被0.51的产物覆盖。
待0.62灰度全量之后, 线上不会再发布 0.51 的业务包，线上升级切换完成即可。
5.2、CI/CD
由于0.51 和 0.62 的业务 Bundle 需要较长时间的在线上并行存在， 以及两个版本的环境、产物也会存在不兼容的情况。因此除了有测试阶段的环境检测手段之外， 还需要在CI/CD阶段插入我们的一系列校验流程：
1.环境切换；
2.把检查兼容API的python脚本集成到构建过程中；
3.根据产物类型来生成版本号规则：
- 0.51版本号规则 ：5.91.xxx.yy
- 0.62版本号规则：5.91.1xxx.yyyy
4.针对Android的hbc产物生成额外的map并上传ftp。
5.3、数据准备
这里主要是埋点，用来和 0.51 版本的数据区分开，我们期望线上 0.62 版本 产生的数据能准确得反应升级的真实情况(访问占比、稳定性)， 同时我们也为 0.62 的数据单独配置了告警策略。
六、线上验证
项目上线以后，我们所要做的就是及时跟进线上数据， 验证前期实验室数据， 以及关注监控数据， 及时调整方案。
6.1 每日报表输出
在62升级包灰度期间，每日会有报表输出， 包括每个模块的DAU、PV、JS异常用户数、JS异常率、SDK异常用户数以及SDK异常率等， 开发和测试同学可以从整体了解线上运行的状况。我们也提前制定了预案，异常率达到一定阀值时就停止灰度。
6.2 性能数据输出
以Android端的性能数据为例，最终我们从线上采集到的性能数据如下，和我们线下测量的数据基本吻合：
1、包大小
Android端采用的是Hermes+HBC的方案，打包输出的产物从字符串格式的.jsbundle变为二进制包 .hbc, 包体积因此增长了 45% 以上。这是以空间换时间的一个优化(JIT 变为 AOT)。
2、冷启动
采用Hermes+HBC的方案后，指令运行速度大大提升，冷启动时长时减少了约64% ，启动速度提升了近三倍，基本符合我们之前的测试和预期。
3、热启动
我们做了引擎复用机制，引擎创建一次后，会驻留内存，因此第二次启动就是热启动了。热启动的过程相较于冷启动，没有JS代码加载、初始化执行等耗时操作。因此、热启动时长几乎没有改善，这也基本符合我们之前的测试和预期。
4、内存占用
Hermes引擎执行HBC，省掉了JS代码解释的过程，因此冷启动单页面运行时内存减少了 30%以上。
6.3 后续批次
第一批次的升级工作基本告一段落, 在这中间会沉淀不少最佳实践：上线计划、容错方案、测试计划、性能分析 等，第二批次货主端的升级工作仅需要在这基础上做微调整， 上线风险和整体计划会流畅很多。
司机端第一批次对稳定性做了基本的验证，我们可以确定风险整体可控。因此，货主端第二批次上线时，直接采用了跟随APP发版的方式上线。
iOS端没有插件化机制，因此两个批次都是采用跟随APP发版的方式上线，使用AppStore默认的7天灰度。