干货 | RN框架在携程旅行鸿蒙应用的全业务适配实践

作者简介

携程鸿蒙框架技术团队，负责携程旅行鸿蒙系统原生应用开发，为鸿蒙生态用户提供一站式旅行服务。

团队热招岗位：资深移动端工程师、高级iOS开发工程师

携程作为鸿蒙生态在旅游行业的重要合作伙伴，早在鸿蒙服务卡片时期就和华为开始合作。2023年9月，华为宣布鸿蒙原生应用启动开发，同年12月，我们完成携程旅行鸿蒙Beta版本的开发，技术上基于Web+部分原生的方案实现。24年6月HarmonyOS Next系统正式内测后，为了让鸿蒙生态的用户使用到携程一站式的旅行服务，我们开始在鸿蒙系统上对全业务进行适配。

• 一、RN在携程业务使用现状

• 二、技术选型（为什么选择CRN）

• 三、CRN适配实践

• 3.1 版本升级

• 3.2 差异化工作

• 3.3 原生组件开发

• 3.4 组件C化

• 四、遇到的问题和解决办法

• 五、性能优化

• 5.1 CRN预加载

• 5.2 RN TurboModule运行在Worker线程

• 5.3 RN 指令精简

• 5.4 分帧渲染

• 5.5 后续性能优化

• 六、成果和未来规划

一、RN在携程业务使用现状

2019年，携程开始在线上使用RN框架，并结合自身的业场景，对RN框架进行了开发和改造，研发了CRN框架（以下简称CRN）。2021年，CRN成为携程主流的开发框架。集团内有20+个App接入CRN框架，其中核心的App都已接入。携程旅行App中，200+个业务Bundle在线上运行，业务页面数量超过2000个，超过80%的业务使用CRN。

二、技术选型（为什么选择CRN）

从新技术的选择到落地的实践上看，业务对技术的要求往往是以下几个方面：

1）功能全，全量业务都能快速的适配上线

2）性能好，用户体验多端一致

3）成本低，复用现有在其他平台的运行的代码

为了满足业务需求，鸿蒙的实现技术上我们选择了CRN，主要考虑：

1）基建成熟度高：有配套研发/测试/发布/运营监控系统，内部交流活跃，知识沉淀深

2）业务适配成本小：业务不需要重新再开发一遍，可以使用现有的业务代码

3）开发能快速上手：业务开发还是使用原有的技术进行开发，在鸿蒙上运行

4）产品迭代效率：支持每个周期的产品迭代，快速在鸿蒙系统的手机上线

三、CRN适配实践

3.1 版本升级

线上携程旅行App使用的React Native（RN）版本是0.70.1，而鸿蒙RN版本是0.72.5。因此，适配鸿蒙的第一步是将RN版本从0.70.1升级到0.72.5。

版本升级包含了如下几个方面：

3.1.1 RN版本差异分析

我们对比RN 0.70.1 和 0.72.5 框架库的差异，整体改动点不多。为了降低业务方升级成本，我们在框架底层对废弃的组件和API变更做了兼容，尽可能减少业务使用方的改动。

3.1.2 CRN框架改造

CRN框架覆盖了文档、工具、开发框架、发布、监控、排障全链路。对应框架的改造也从这几个方面进行。

1）在文档方面，我们编写了详细的业务升级文档，列出业务方需要关注的点和常见问题。

2）在工具方面，提供了一键式CLI升级工具，只需在业务工程执行一行升级命令，即可完成工程升级改造。

3）在开发框架方面，改造涉及点比较多，包括：

• 对Native运行时升级，升级RN 0.72.5 核心库，合并对官方RN库的自定义改动点。

• 对JS打包工具升级，支持现有的拆包逻辑，合并对官方RN库的自定义改动点。

• 梳理使用到的社区三方库，统一三方库版本升级至鸿蒙RN三方库要求版本。

• 对Hermes引擎进行升级，合并自定义改动点。

• 对RN自定义组件和API进行新架构改造。

4）在发布方面，对现有的CRN发布系统进行改造，支持选择鸿蒙平台进行单独发布。发布的产物下发和线上IOS/Android进行隔离，保证测试上线阶段，不影响已经上架的IOS/Android应用。

待后续鸿蒙应用稳定，再支持一键同时发布IOS/Android/HarmonyOS Next平台。

又考虑到业务场景存在一套代码，跨RN版本发布。发布系统改造，支持了发布时根据发布单选择的RN版本，自动选择依赖配置进行打包发布。提升业务发布效率。

5）在监控方面，实现鸿蒙端的监控数据上报，接入到现有的监控系统，方便线上监控。

6）在排障方面，实现鸿蒙端的异常数据上报，接入现有排障系统，方便线上排障。

3.1.3 业务工程改造

1）业务方按照提供升级文档和工具进行具体业务工程改造。

2）升级改造后，进行本地开发环境测试，发现问题，解决问题。

3）本地测试通过后，进行打包发布，进入集成测试阶段。

在升级过程中，工作量最大的部分是“RN自定义组件和API实现新架构改造”。

这里先介绍下RN新架构。RN新架构是指从0.68版本开始后的架构。主要包括：

• Turo Modules 模块系统，替换老架构中的Native Modules，用于JS到Native的API同步调用。

• Farbic 组件系统，替换老架构中Native Component，支持同步渲染。

由于鸿蒙RN只支持新架构，所以需要将RN自定义组件和API实现进行新架构改造。在携程旅行App中，我们使用有100+的自定义组件和API。这部分的改造工作量非常大，建议在做适配时优先处理这部分工作。

3.2 差异化工作

在RN版本升级到0.72.5后，开始鸿蒙端特有的适配。

鸿蒙RN框架特点：

• 已实现了官方RN大部分组件、API

• 已实现社区常用的三方库

• 自定义组件和API需要应用开发自行实现

差异化工作：

1）自定义组件和API实现

• 100+自定义组件和API，基于鸿蒙原生开发实现，再封装提供给RN调用

• 按优先级分阶段实现这些自定义组件和API，保持上层JS接口不变

2）RN工程改造

• 添加react-native-harmony和react-native-harmony-cli依赖库

• 适配Platform.OS，Platform.select等API

• 实现xxx.harmony.js文件，逻辑与IOS保持一致

• 升级三方库版本，如react-native-gesture-handler，从1.X版本升级到2.X版本

• 三方库版本升级后，对不兼容的地方做适配

3.3 原生组件开发

携程CRN框架经过近8年的迭代，业务线非常复杂，