iOS 和 Android 开发是否要采用 React Native?

作者：故胤道长，CMU硕士毕业，常年居住于美国的iOS开发者。Github累计4000星，前Uber核心架构组成员，现Amazon软件工程师。

本来发布在故胤道长的9元付费专栏《硅谷问道》，作者以一个iOS开发者角度分析开发是否要采用 React Native?我自己作为一个 Android 开发者也是受益匪浅，文章中很多观点都是对于 iOS 和 Android 开发者来说都是相通的。

前言

React Native 是 Facebook 2015年开源的 Javascript 框架，旨在使用 Javascript 高效开发手机端 App。配合着多个显而易见的优势和 Facebook 强大的宣传机器，它立刻成为国内外大小公司的明星开发框架。开源社区的参与激情、各方博客的宣传追捧，从其 Github 上 56000+ 星和 13000+ Fork 就可见一斑。

对于 React Native，iOS 开发者社区也是褒贬不一。有人认为 React Native 更快更好，苹果原生那套要完，不赶快学习就晚了；也有人认为 React Native 不过是 Facebook 的又一个玩具，以它现在的稚嫩还难以对原生的 Swift/Objective-C 造成足够威胁。

笔者希望就这几年亲身开发 React Native 和原生 iOS 的经验，以及在硅谷的所见所闻，对这个问题提出一点自己的看法。对于一门新技术，我个人认为，评判其是否值得采用有以下两个标准：

• 该技术本身是否具备足够的优点

• 该技术是否符合目前的开发需求

下面就将从技术和开发需求两个角度出发，谈一谈 React Native。

React Native 的技术特点

React Native 的优点很明显。官网的醒目位置有简单介绍，开发者们也在各种场合做了相关说明，总结如下：

• 跨平台开发。同一段 Javascript 代码可以被用于 iOS 和 Android 两个平台。相比于以前 iOS 和 Android App 各维护一套逻辑大同小异的代码，React Native 的开发、测试和维护成本要低很多。

• 快速编译。比起 Xcode 中漫长的编译，React Native 采用了热加载（Hot Reload）的即时编译机制，使得 App UI 的开发体验大幅改善，几乎到了和网页开发一样随改随变的效果。

  
  

• 快速发布。通过 JSBundle，React Native 可以即时更新 App。相比原来冗长的审核和上传过程，发布和测试新功能的效率大幅提高。

  
  

• 渲染和布局更加高效。React Native 可以直接套用网页开发的 CSS 和 flex 机制，摆脱了 autolayout 和 frame 布局中繁琐的数学计算，更加直接简便。

  
  

• 简单易学。相比于 iOS 和 Android 的一整套复杂的知识体系，React Native 从本质上来讲就是状态机，对于开发者来讲理解不难，且实际操作可谓入门容易、上手轻松。如果是前端开发者，那么对于 Javascript 本来就有相应了解，用 React Native 开发手机应用更是水到渠成。
  

React Native 的跨平台特性是最大卖点

当然，看上去很完美的 React Native 在技术上也有诸多风险，比如：

• 第三方依赖。React Native 严重依赖于 Facebook 的维护。苹果在 iOS 上每次技术的更新、政策的改变都会让原来使用了 React Native 代码库受到影响，等待 Facebook 和社区的修复会妨碍 App 的更新和用户体验。前段时间，百度和开发者们弃用 React Native 而迫使的 Facebook 修改开发者权限（License）事件，证明了开发依赖于第三方的风险确实存在。

  
  

• 逻辑上的额外开销。直到今天， React Native 依然只是0.49版本，仅仅支持简单的 UI 制作，其不成熟的 API 连复杂的动画都难以实现，更别提 iOS 的底层优化和兼容操作。同时因为操作系统和设备的不同，React Native 得分别进行针对性处理，这对代码库的维护又是一个挑战。

  
  

• 联调的困难。对于原生的 iOS 和 Android App 引入 React Native，会增加整个代码库的复杂度，在深入底层原生代码进行 debug 时也是困难重重，可以说是在开发和维护上的成本都有所增加。
  

另外，有很多人觉得 React Native 的性能不如原生的 Objective-C/Swift 好。笔者自己尝试过，觉得差别不大。与硅谷很多开发者的交流中得知，React Native 的性能与原生相比只有毫秒只差，根本不会对用户体验造成影响。对此感兴趣的朋友可以阅读此文Comparing the Performance between Native iOS (Swift) and React-Native（https://medium.com/the-react-native-log/comparing-the-performance-between-native-ios-swift-and-react-native-7b5490d363e2），文中在 CPU、GPU、内存3个维度上进行了多个 API 的比较，React Native 与原生的 Swift 相比真是不遑多让。

React Native 在 UI 上的表现确实惊艳

App 所面对的开发需求

作为 iOS 开发者，脱离了应用谈技术，好比镜中花、水中月——空谈而已。实际 App 开发中，有以下几种情况。我们来一一分析适不适合引入 React Native。

第一种情况，从零开始开发一款简单的 App。它很有可能是独立开发者的小试牛刀，或是初创公司的第一代产品。我个人认为这种情况下是非常适合用 React Native 的。此时，App 的UI 和业务逻辑都比较简单，React Native 可以满足绝大多数情况。而且，开发者时间有限，没时间系统学习两大平台的知识体系；初创公司的成本有限，需要在 iOS 和 Android 两个平台上发布产品，以便用最短时间、最小成本迅速积累第一波用户，拿到投资。React Native 的技术特点非常符合这些要求。

符合这种的产品就如 Facebook 的 F8 App，这是一款专为其年度开发者大会打造的 App。因为它只有日历、地图、推送等简单功能，React Native 再适合不过——1个工程师花了2周就完成了全部的开发，现已开源在 Github 上。

第二种情况，从零开始开发一款比较复杂的 App。这有可能是一个公司新的产品线，也有可能是一个成熟 App 的重构。在这种情况下，质量、口碑、以及日后的维护就是首要考虑因素，原生的 Swift/Objective-C 在面对实际问题时解决方案更加成熟多样，React Native 发挥不了其技术优势，故而原生开发是更为稳妥的选择。

举个例子，Uber 在去年推出了他们新的 App。内部也尝试了 React Native，但因为无法满足 App 对于复杂动画的需求、与底层系统的兼容不够、性能上的优化不足等多个原因，最终决定放弃使用。

Facebook F8 App，React Native 经典案例

第三种情况，在原有的 App 中引入新的功能。这种情况比较复杂，它又分为以下几种情况：

1、原来的 App 代码库是 100% 的 Objective-C/Swift。这种情况下我个人不推荐引入 React Native。因为技术团队已经稳定在 iOS 和 Android 两个技术栈上了，引入第三个技术栈，技术上增加复杂度和维护成本，人员上要组建一个新的 React Native 团队，开支和组织架构上都有负面影响。除非有足够的预算，或是后期有大幅采用 React Native 的计划，否则不推荐引入 React Native。

2、验证新功能该不该引入。验证过程中公司有时间成本，高层希望的是短期内就能做出决策。React Native 正是这种情况的银色子弹。据我所知 Tesla 的 App 就采用了这种机制。

3、新功能确定引入，不是核心功能，并不复杂。这种情况下当然可以尝试 React Native。如果是网页端类型的 App 或是功能，比如淘宝、携程、京东之类，他们本身就有大量的网页端开发经验，不如直接让负责的前端工程师来处理相关的移动端业务。即使不成功也不会影响主要业务，同时可以为公司的技术积累提供宝贵经验。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了类似的循序渐进得采用 React Native 的策略。

4、新功能确定引入，是重要功能，有严格的发布要求和日期。这个同上文说的第二种情况相同，保险和稳妥起见不推荐采用 React Native。

总结

单纯从技术角度来讲，React Native 绝对是移动端不可多得的优秀框架。它状态机的思路可以被借鉴用来写原生的 View Controller，其 UI 布局上的机制也对我们平日在性能上的优化提供了灵感。

目前硅谷对于 React Native 也普遍持保守态度，采用 React Native 的科技巨头也只有 Facebook，Amazon，Uber，Airbnb 四家，而且都是局部小功能、小App采用。好消息是，Facebook 对于 React Native 的投入不遗余力，圈内开发者也是对此颇为积极。更多细节可以阅读官方的开发日程表：React Native Scheduling（https://www.facebook.com/notes/andy-street/react-native-scheduling/10153916310914590）

笔者认为，只有在快速开发、节约成本的考虑之下，React Native 才能发挥出巨大的优势。对于 iOS 开发者，React Native 只可作为适当补充，我们还是应该多多钻研 Swift / Objective-C 以及 App 开发的思路，它们才是进阶成长的关键所在。

只分享精品文章的 iOS 成长之路，欢迎大家关注