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 在技术上也有诸多风险,比如:

  • 第三方依赖。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 上的表现确实惊艳
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 经典案例
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 开发的思路,它们才是进阶成长的关键所在。

关注下面的标签,发现更多相似文章
评论
说说你的看法