iOS 开发是否要采用 React Native?

前言

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，文中在 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

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