前言
React Native 是 Facebook 2015年开源的 Javascript 框架，旨在使用 Javascript 高效开发手机端 App。配合着多个显而易见的优势和 Facebook 强大的宣传机器，它立刻成为国内外大小公司的明星开发框架。开源社区的参与激情、各方博客的宣传追捧，从其 Github 上 56000+ 星和 13000+ Fork 就可见一斑。
对于 React Native，iOS 开发者社区也是褒贬不一。有人认为 React Native 更快更好，苹果原生那套要完，不赶快学习就晚了；也有人认为 React Native 不过是 Facebook 的又一个玩具，以它现在的稚嫩还难以对原生的 Swift/Objective-C 造成足够威胁。
在这里我还是要推荐下我自己建的iOS开发学习群：680565220，群里都是学ios开发的，如果你正在学习ios ，小编欢迎你加入，今天分享的这个案例已经上传到群文件，大家都是软件开发党，不定期分享干货（只有iOS软件开发相关的），包括我自己整理的一份2018最新的iOS进阶资料和高级开发教程
笔者希望就这几年亲身开发 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 中引入新的功能。这种情况比较复杂，它又分为以下几种情况：
原来的 App 代码库是 100% 的 Objective-C/Swift。这种情况下我个人不推荐引入 React Native。因为技术团队已经稳定在 iOS 和 Android 两个技术栈上了，引入第三个技术栈，技术上增加复杂度和维护成本，人员上要组建一个新的 React Native 团队，开支和组织架构上都有负面影响。除非有足够的预算，或是后期有大幅采用 React Native 的计划，否则不推荐引入 React Native。
验证新功能该不该引入。验证过程中公司有时间成本，高层希望的是短期内就能做出决策。React Native 正是这种情况的银色子弹。据我所知 Tesla 的 App 就采用了这种机制。
新功能确定引入，不是核心功能，并不复杂。这种情况下当然可以尝试 React Native。如果是网页端类型的 App 或是功能，比如淘宝、携程、京东之类，他们本身就有大量的网页端开发经验，不如直接让负责的前端工程师来处理相关的移动端业务。即使不成功也不会影响主要业务，同时可以为公司的技术积累提供宝贵经验。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了类似的循序渐进得采用 React Native 的策略。
新功能确定引入，是重要功能，有严格的发布要求和日期。这个同上文说的第二种情况相同，保险和稳妥起见不推荐采用 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 开发的思路，它们才是进阶成长的关键所在。
