前言
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, 文中在 CPUGPU 内存 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
image
总结
单纯从技术角度来讲, 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 开发的思路, 它们才是进阶成长的关键所在
来源: http://www.jianshu.com/p/135270a8c65c