在移动互联网产品迅猛发展的今天，技术的不断创新使得企业越来越注重降低成本、提升效率。为了在有限的开发资源下迅速推出高质量、用户体验好的产品，以实现公司发展，业界催生了许多移动端跨平台解决方案。这些方案不仅简化了开发流程，还极大地提升了产品的兼容性和可维护性，确保企业能够在最短时间内，以最经济的成本，将卓越的产品体验带给广大用户。
1 项目背景
随着碧桂园服务业务的增长和需求更新频率的提升，有限的开发资源已经无法满足快速开发产品的需求。在此背景下，移动端原生 APP 开发的不足逐渐显现，主要体现在：
- 研发效能相对较低：同一个业务需求，需要双端开发人员各自独立实现，这在一定程度上浪费了开发资源；
- 更新时效性低：APP 更新需要经过应用市场的审核，审核过程需要一定时间，尤其 iOS 平台还存在被拒绝的风险；
- 用户体验相对较差：每次需求功能上线，用户都需要实时更新 APP 安装包。
鉴于此，我们开始深入思考移动端跨平台优化的方向，并着手实施解决方案。
2 移动端跨平台技术简介
当前，移动端跨平台从底层实现上主要分为 Web、原生和自渲染三大类技术。
2.1 Web 渲染技术
基于 WebView 的实现方案，以 Cordova 和 Ionic 为代表，本质上是 WebView 加载网页的过程。具体流程：加载本地的 index.html，加载与该 html 相关的资源文件，从而渲染出完整的 APP 界面。
- 优势：技术门槛相对较低，对 H5 前端开发人员友好，跨平台一致性和高研发效率。
- 劣势：WebView 的启动和渲染流程都非常耗时，功能受限于 WebView 内核，在一些重交互或动画复杂场景，性能无法满足诉求，整体用户体验差。
2.2 原生渲染技术
基于各平台自身的 JavaScript 解析引擎实现，以 React Native 和 Weex 为代表。这些框架在上层使用高/级前端语言进行开发（如 React Native 采用 React，Weex 采用 Vue），然后通过对应平台的 JavaScript 解析引擎对代码进行解析，在 Engine 层转换成原生组件进行渲染，并通过 Bridge 层进行通讯。
- 优势：顶层采用 H5 语言，对前端开发友好。底层使用平台自己的组件渲染，性能相对较好，用户体验佳。
- 劣势：JavaScript 层与 Native 平台层频繁通讯带来的性能瓶颈，且对动画要求高的组件需要原生组件的支撑。
2.3 自渲染技术
基于各平台底层渲染的公开 API 实现 UI 渲染引擎，以 Flutter 为代表。该框架在上层使用 Dart 语言，而底层则由 Flutter 实现了 Skia 跨平台渲染引擎，从而实现了 UI 层与原生环境之间的高性能数据交互。
- 优势：Native 作为宿主环境，UI 组件直接通过渲染引擎进行绘制，既确保了两端的一致性，又提供了良好的性能和用户体验。
- 劣势：上层采用 Dart 语言，对前端开发人员不太友好，增加了学习和上手的难度。
3 技术选型
碧桂园服务的大管家 APP 自 2018 年上线以来，已经发展成为一个拥有数十个内部功能模块的复杂应用，其中包括地图标识和轨迹等交互复杂的模块。此外，大管家 APP 的需求功能迭代比较频繁，因此在综合考虑技术方案时，我们关注到 React Native 的几个优势：
- 原生渲染能力，能提供接近于原生 APP 的用户体验；
- 采用 React 作为顶层语言，对 H5 开发人员友好；
- 可以封装现有 APP 原生组件，暴露给 JS 层使用。
基于以上优势，我们最终选择 React Native 作为“大管家 APP”项目的技术框架，并据此进行了技术调研，以确保我们的选择是合理的。以下是我们进行技术调研时参考的一组对比数据：
4 技术实践
4.1 APP 大体架构设计
大管家 APP 基于新框架的四层架构设计具有高度的可扩展性和业务适配能力，整合了 Native APP 外壳、H5 页面、React Native 页面以及 Native 页面的技术混合方案。
系统层（Native）：在原生 APP 的底层，我们根据不同平台的 API 封装了一系列的 Native Modules，包括 Router 路由组件、定位组件、H5 Bridge 组件、RN Bridge 组件、微信分享组件以及 UI Modules 如地图组件、日期组件等。
通讯层（Bridge）：分别实现了 H5 Bridge 和 RN Bridge，有效地抹平底层系统 API 的差异，为上层应用提供了一致的接口。
路由层（Router）：实现 H5 通用容器（涉及到微信小程序等第三方平台）、React Native 通用容器（一般场景首选）和原生页面等路由模块（复杂场景），以供上层业务场景使用。
业务层（Business）：产品需求决定业务层选择。我们根据业务是否需要支持第三方平台来确定是否选择 H5 路由模块，如果不涉及第三方平台我们根据需求中包含复杂动画需求，选择原生路由模块，剩下场景全部使用 React Native 路由模块。
4.2 React Native 在 APP 上落地
1、两端 APP 接入 React Native
根据 React Native 官网指导引入相关依赖，构造 React Native 页面通用容器并实现容器路由。
iOS 端实现部分主要流程：
- 参考官网使用 Cocoapods 引入依赖（node_modules 目录下 React Native）；
- 引入相关头文件 RCTRootView.h；
- 定义属性变量 RCTBridge 和 RCTRootView；
- 实现代理 RCTBridgeDelegate 构造 React Native 通用容器。
Android 端实现主要流程：
- 在项目的 build.gradle 文件中为 React Native 和 JSC 引擎添加 Mave 源的路径，必须写在 "allprojects" 代码块内；
- 在 APP build.gradle 文件中添加 React Native 和 JSC 引擎依赖；
- 启用原生模块的自动链接；
- 实现 Android 通用容器。
2、React Native 工程搭建
我们采用了单工程多 Bundle 的设计策略（即每个页面都单独打包成一个 Bundle 文件），工程中内部引入了现有的 iOS 和 Android 原生 APP 工程，这些 APP 工程必须放置在 React Native 工程的根目录下。对于 iOS 和 Android 端，我们分别设置了一个统一的 React Native 页面容器，以便整合和管理。React Native 工程结构如下：
3、Bundle 动态更新
下面是我们实现的 Bundle 差分、APP 加载 Bundle、APP 更新 Bundle 及后台管理流程。每一个页面 Bundle=基础 Bundle+差分 Bundle，我们实现一个管理后台专门管理这些差分 Bundle 和基础 Bundle，并能生成一个 Bundle 配置列表，随着需求的不断迭代更新，APP 通过拉取配置列表实现 Bundle 加载和更新，实时替换刷新用户界面。
4、Bundle 模块开发
我们通过对部分旧模块进行 React Native 改造。对于新业务模块，我们将优先选用 React 开发。下图是一个聊天用户列表 Bundle 实现示意图：
4.3 React Native 落地效果
我们回归文章一开始提出的本质问题和项目目标时，我们发现使用 React Native 带来了以下显著优势：
1、提高移动端性能
从生日提醒页面实现数据看，文件大小的显著差异使得 React Native 页面在加载和启动速度上远超 H5。H5 页面在 UI 长列表绘制时会时不时出现失帧，而 React Native 页面在帧率和内存占用方面展现出较 H5 更显著的优势。
2、提升研发效能
从实践来看，React Native 同时吸收 H5 的研发效率、动态更新和原生的 UI 用户体验等优势，提高了研发效率和用户体验，支撑了大前端团队的敏捷研发交付。
3、媲美原生 UI 体验
以下是 UI 层渲染节点图：
RCTRootView 是 iOS 的视图组件，从图中可以看出，UI 节点最终都是原生的视图组件来呈现的，因此渲染效果和性能是完全和原生相差无几。值得注意的是，我们在所有 React Native 页面中使用的下拉刷新组件是原生封装 JS 层调用，这些能力是 H5 无法做到的。
5 总结
通过大管家 APP 项目中的 React Native 部分模块改造，我们成功实现了 Bundle 资源文件的后台管理，优化了功能的迭代更新运维过程。这一改造不仅完美落地了 React Native 这一移动跨平台技术，同时也充分发挥了 JavaScript 框架的极/致性能，从而实现了用户体验、资源整合和研发效能的完美兼容。
- 通过实时动态更新 Bundle，用户无需更新 APP 即可获得最新功能和优化，极大地提升了 APP 终端用户体验；
- 使用 React 进行开发，实现 iOS、Android 及前端资源的整合，统一项目大前端技术栈，有效减少开发资源的浪费；
- 两端开发变成单一前端开发，理论节省一半开发时间，提高研发效能。
未来，随着业务需求的快速增长和变化，移动端跨平台技术在支持公司的敏捷交付将发挥越来越重要的作用。
本文作者：
范志荣：碧桂园服务前端开发高/级工程师
王焯斌：碧桂园服务前端开发高/级工程师
指导人：
余俭：碧桂园服务技术总监
肖群虎：碧桂园服务技术专家
