本文从技术决策讲起，聊聊我们为什么要使用 React Native、如何使用、以及其他维度的思考。
文中将用 「RN」 代表 「React Native」。
1. 技术选型决策
技术选型是一个复杂的过程，必须谨慎并保持敬畏，需要根据项目的实际情况而定。这关系到项目的命运。
1.1 了解 React Native
简单介绍一下 RN。大家都知道 Android 和 iOS 两大移动操作系统，他们各自为营，互不相通。Android 的开发语言是 Java 和 Kotlin，iOS 的开发语言是 OC 和 Swift 。开发一款应用需要两支开发队伍。然后就有人思考，能否通过一种技术手段将 Android 和 iOS 统一起来？先后有多种解决方案诞生，最终 RN 以绝对优势脱颖而出。它是一个由 Facebook 于 2015 年 9 月发布的一款开源的 JavaScript 框架，它可以让开发者使用 JavaScript 和 React 来开发跨平台的移动应用。它既保留了 React 的开发效率，又同时拥有 Native 应用的良好体验，加上 Virtual DOM 跨平台的优势，实现了真正意义上的：Learn Once,Write Anywhere. React Native · Learn once, write anywhere
我在2017年第一次接触 RN，那时候还是 0.41 的版本。前前后后用它构建过四五个项目，和它打交道也三四年了。现在的最新版本已经是0.67了，亲眼见证它越来越完善的过程。
RN 的优势很明显，跨平台、热更新、调试方便等等，这里就不展开了。
但也有一些劣势值得注意，比如功能相比原生不够完善，文档相对粗略，用户体验略输原生等。
大多数情况下，对于中小型项目和创业公司来说，RN 会带来很好的收益。
更多分析请看这里。
1.2 项目背景
我们现在有两款应用，好比打车软件的司机端和乘客端，支持Android 和 iOS 两个平台，所以线上总共有 4 个 App。这四个 App 属于中型偏小规模，但已经有 6 岁了，期间经历过很多届开发者，现在已经变得不太好维护了。而且团队中 Android 开发人数长期不足，导致两个平台的进度和质量都存在巨大差异。
1.3 RN 能给我们带来什么收益？
如果引入 RN，会给项目带来几点明显的收益：
- 跨平台开发，降低开发成本，提高开发效率；
- 解决 Android 和 iOS 进度和质量不统一的问题；
- 抛弃老旧的 Native 代码，新代码会有更好的设计；
- 可以支持热更新；
- 对于招聘移动端开发者困难的客户来说，前端开发人员很容易参与移动开发。
这些收益点，是建立在一个核心出上的：我们的 app 适合用 RN 吗？
首先我们知道，我们的 app 规模属于中小型，没那么复杂。
其次，app 类型以数据展示为主，加上有 IM 功能的一个订单平台，它没有巨额的性能消耗和复杂的交互逻辑。
而且，app 没有和外设交互。
最后的结论，我们的工程是适合用 RN 的。
1.4 有什么风险？
做技术选型时，风险是架构师或者技术决策者的必须仔细考虑的事情。
技术角度的风险：
- 如果我们选择逐步迁移的方案，那么久意味着有很长一段时间 RN 和 Native 共存，进行混合开发。混合开发模式会使事情变得复杂，影响交付效率；
- 如果前期没有做好规划，或者中间遇到意想不到的困难，可能会导致 RN 迁移进退两难，导致失败；
- 使用 RN 会不会导致 app 性能下降？
- 使用 RN 会不会导致 app 体量增大太多（包大小）？
- 目前工程中使用重要第三方库，RN 是否支持？例如 数据统计、Crash 统计、Sendbird 等等；
- app 中是否有 RN 不支持的功能点？
公司角度的风险：
- 公司需要分配一定的人力和时间去做这件事，如果失败，会造成资源浪费；
- 如果采用了 RN，后续是否容易招聘到相应的开发者？
经过对上面提到的风险的分析，以及和公司高层的沟通。所有的顾虑一一被消灭，并得到了公司层面的大力支持。
1.5 为什么不用Flutter
关于 RN 和 Flutter 的讨论非常多，这里有一篇比较全面的对比 这里
对于我们来说，有四点足以让我们选择 RN:
- RN 基于 React，使用 JS 语言。而 Flutter 使用了一门新的语言 Dart 。这会使RN入门门槛相对较低，移动端开发者和前端开发者都容易加入；
- 社区更为成熟，RN 2015年发布的，经过了六七年的积累，社区很活跃，第三方库比较齐全。而 Dart 相对比较年轻；
- RN 开发人员更容易招聘；
- 团队中有现成的 RN 开发人员。
2. 项目实践方案决策
2.1 方案选项
我们现有的项目已经持续了六年了，现在要引入 RN。我们应该如何引入？有两个选择：
- 绿地：新建项目，从头构建，然后做成和现有 app 一样的新 app 。
- 棕地：现有原生工程集成 React Native，逐步替换。
2.2 多角度思考
技术视角
从开发者视角来看，绿地模式开发体验更好，没有历史负担，更高效。
如果采用棕地模式，会增加很多额外工作和困难。
公司视角
如果采用绿地模式，那么在对齐现有功能之前，团队没有直观的阶段性输出。并且这个周期很长。如果失败，造成的损失很大。风险和短期成本较高。
如果采用宗地模式，团队容易产生阶段性成果，在尝试中前进，整体风险小。
项目现状
项目经历了六年的迭代，开发人员以及产品经历轮换了好几拨，很多功能细节没有详细记录，测试代码不全。一个 app 包含了多个产品团队。
如果采用绿地模式，不确定因素太多，沟通成本大，开发周期很难预估。
2.3 最终决策
经过上面的分析，最终我们选用了相对安全保守的方案，采用棕地模式。
先从 app 的登录流程做起，毕竟它是相对独立的模块，且复杂度低。
3. 总结
本文基于真实项目案例，讲述了在选择使用 RN 框架之前的选型抉择过程。其中包括技术选型分析和项目实践方案分析过程，从不同角度分析其中的利弊。
本项目中在做技术选型分析的时候，省略了很多细节因素分析，例如， 社区活跃度、商业应用案例、成熟度分析、技术原理分析等。那是因为 RN 已经家喻户晓，并且结合我们现有的 RN 经验，可以省略部分繁琐的分析过程。
文末寄语：
所有的技术选型和框架选择，都应该基于项目的实际情况，从多方面去权衡利弊，而不仅仅是看哪个框架或语言更火、更酷炫。 -- 我说的。