React Native 迁移的阵痛

背景

由于我们的移动应用程序已经存在多年，经历了许多开发者的更替，因此变得越来越臃肿和难以维护。此外，我们团队中的 Android 开发人员一直很短缺，这导致我们在两个平台上的开发进度和质量存在巨大差异。因此，我们决定采用 React Native 技术，将原生工程迁移到该平台上，以提高应用程序的可维护性和整体性能。

我在《React Native 技术选型分析》中，阐述了对现有原生工程集成 React Native 的技术决策分析。

从开发者角度来说，我们当然倾向于 “绿地模式”, 也就是新建一个纯净的 React Native 工程，把现有 APP 中的功能重新开发一遍。这样开发体验更好，没有历史负担，更高效。

从企业角度来说，“棕地模式” 更符合企业利益。这样团队容易产生阶段性成果，在尝试中前进，整体风险小。

综合各方面因素，最终我们选用了相对安全保守的方案，采用 “棕地模式”。

“宗地模式” 意味着我们将会有很长一段时间工作在混合工程中，也意味着我们将要面临一段阵痛期。

一年之后的今天，我想有必要回顾一下我们遇到过的麻烦，希望能帮助到 “后来者”。

宏大的工程需要一个清晰的计划

由于我们项目的 Android 用户量比起 iOS 少很多，所以选择从安卓项目入手，作为试验点。这样即便出了什么问题，影响到的用户也会较少。
前期，集成 React Native 由一个独立的三人组小团队负责，主要工作分为五个阶段：

第一阶段：基础建设

此阶段为开启 React Native 迁移的第一步，为后续打好基础。其中包括：

1. 调研技术风险、可行性、重要技术组件支持度；
2. 向现有工程 Android app 集成 React Native 框架；
3. 制定技术标准和代码规范，使后续开发规范统一、有据可依、质量可控；
4. 工程基础建设，包括架构设计、基础工具建设、以及相关文档编写。

第二阶段：登录流程迁移

用一个相对独立的功能模块实验 React Native 技术应用，也是首次用 React Native 呈现业务功能。

1. 用 React Native 重构用户登录流程；
2. 重构过程中查漏补缺，持续优化工程基础和架构。
3. 发布上线

第三阶段：Onboarding other team

在经过基础建设和小试牛刀之后，第一次开放让其他功能团队参与，正式进入应用阶段。

1. Onboarding XXX team；
2. 协助 XXX team 开发某一个功能；
3. 持续改进优化工程基础，包括 Design System。

第四阶段：对齐 iOS 和 Android

React Native 在 Android 工程上的应用已经基本成熟，开始启动向 iOS 工程集成，并对齐 Android 工程。

第五阶段：全面过渡至 React Native，脱离 Native 代码

这是最终目标。
当前我们处于第四阶段中期。

革命道路上我们遇到过的困难

工程上的一些细节问题

1. 由于工程老旧，经常遇到一些不兼容问题，比如集成 e2e 测试框架 Detox，经过一段时间努力之后，最终被迫放弃，选择了 Appium.
2. 集成一些需要 Native 支持的第三方库时，不支持 Autolinking, 需要手动连接，这增加了很多工作量。但是后来经过长时间努力，最终支持了 Autolinking。
3. 中途从 Intel 换到了 M1 的电脑，出现了一些莫名的问题。
   第一次 onboarding 其他团队暴露问题
   我们的三人小团队在前期工程基础建设阶段，虽然遇到了一些问题，但大部分问题都已经得到了解决，并且我们已经对项目非常熟悉了，因此没有感受到任何特别痛苦的点。

然而，当我们要将其他 5 位团队成员引入项目时，许多问题都被集体暴露了出来。

首先，环境搭建是一个主要的问题。其他 5 位成员在 React Native 方面几乎没有任何基础，因此在搭建环境方面遇到了很多麻烦。尽管我们的文档已经很详细了，但是想要成功地运行一个已经集成了 React Native 的 Android 工程并不容易，而且会遇到各种各样的问题。我们三个像消防队员一样，花了一周时间解决了这些问题，最终成功让所有 5 位新成员加入了项目。

与纯 iOS 或 Android 开发环境相比，这使得其他 5 位队员认为 React Native 很麻烦。

学习成本略高

iOS 开发，只需要安装 XCode 并掌握一门语言，就可以开始开发了。 React Native 更像是组装起来的技术，需要掌握的技术和工具较多。例如 JS/TS, React, CSS, Hook, Jest, CLI, 等等。其实这也不能完全算是一个劣势，如果一个前端开发人员开始接触 React Native，那他一定不会觉得陌生。只是相比保姆式的 iOS 生态，这个略显麻烦。再加上 Android 工程是个老旧的项目，这使得一些同学觉得学习成本高昂。
混合开发挑战多
事实上，大多数开发人员并不喜欢混合开发模式，因为这种模式会增加很多麻烦。

首先，Git 管理是一个问题。我们新建了一个 React Native 工程仓库，并将Android原生工程仓库作为一个 Git 子模块引入到 React Native 工程中。这意味着需要同时管理“子模块 + 分支”。

其次，JS 和 Native 之间的通信也是一个问题。有时要实现一个功能需要修改两端的代码，而且还需要让两端的逻辑互相交互。这使得开发难度增加。

另外，新功能应该使用 React Native 还是 Native 开发也是个问题。尽管大家都知道，新功能应该尽可能地用 React Native 开发，但是有些时候，不得不用 Native 开发，因为很多模块还没有被迁移。那么当前要用 Native 开发的新功能，将来一定得用 React Native 再重新开发一遍。

最后，混合开发模式下的开发体验也存在问题，它比纯净开发模式更加麻烦，这会降低开发效率，甚至让一些开发人员感到痛苦。

对齐 iOS 和 Android 路且长

经过近一年的磨合，我们在安卓工程中逐渐将 React Native 应用得更广泛，同时各方面条件也趋于成熟。现在是时候考虑将其迁移到 iOS 工程中了。同样，我们先由“三人小组”先行，直到基础设施建设完成并且之前的 React Native 登录流程可以被复用，然后再让功能团队在其上进行功能开发。尽管我们已经有了在 Android 平台迁移的经验，但在 iOS 上也需要花费三四个月的时间。目前为止，我们的功能团队已经可以在 React Native 项目上为 iOS 开发功能了。
接下来需要做的事情分为两个大步骤。
第一步：iOS 端赶上 Android 的功能迁移；
第二步：完成双平台的 React Native 迁移，正式步入 React Native 跨平台开发时代。
至此，React Native 技术迁移才算彻底完成。但这是一段很长的旅程。

总结

做技术迁移，是一项高风险、高难度、长周期的事情。
高风险体现在，如果实施过程中困难超出预期，或遇到难以逾越的技术难关，很容易陷入进退两难的境地，对企业来说，这算是一场灾难。
高难度体现在，它前期需要良好的规划能力和风险预估能力，中期需要较强的技术实施能力。这中间必定会经历一段“阵痛期”，通过就成功，不通过就夭折。
长周期，做一次完整的技术迁移，一般以年为时间度量单位，最简单的技术迁移也得以季度为单位，当然这也取决于项目的规模。
最重要的一点，是企业有做技术迁移的决心，能够给与人力和财力的支持。

写这么多不是为了说明 React Native 这个框架不好用，其实纯 React Native 应用开发体验还是挺好的，尤其有 Expo 助力，更是无限接近前端开发。只是对现有工程集成 React Native 时，多了不少麻烦。做技术嘛，遇到问题-解决问题 不就是我们的日常吗？很多时候我们可以借助丰富的经验和科学的分析，可以提前避免一些麻烦。但有时候明知道前路崎岖不平，但我们依然勇敢前行。