React Native Changed the World? or Nothing.

RN是一个awesome的技术, facebook颇有想法的团队创造出一项新的技术改变了native开发界. 可是RN自己又疑点重重, RN是为了解决什么问题而存在的? 在诞生了一年后, RN又解决了什么问题? 本文经过分析RN的思想, 试图透过技术, 理解动态方案.

RN(React Native)是Facebook推出的mobile开发框架, 使用javascript做为开发的主要语言, 逻辑和样式的处理由javascript完成, 渲染则使用native渲染, 支持Android和iOS两个平台. 对于native开发者, RN经过配置下发可以作到即时生效的上线. 对于web开发者, 可以使用本身熟悉的技术体系作native开发.

一年前, RN推出的时候, 惊艳移动开发业界, 你们都惊呼原来native开发还能这样作 – 跨平台, 动态发布, 简洁的JSX语法, 各类开发工具和调试工具. 我当时也是RN的狂热推崇者, 里面不少思路在当时看来的确是引领了一代创新. 而如今, 在作了一年多native动态性的工做以后, 发现RN的背后问题重重.

问题1 RN是为了解决什么问题而存在的?

观点1 解决跨平台问题

“React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about — learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native.”

摘自RN官网, 从这里咱们能够看出, 官方是把RN做为一套跨平台的技术方案的, learn once, write anywhere, 也就是说RN解决了Android, iOS跨平台开发的问题. 可是别忘了, web自己就是跨平台的, HTML, CSS, javascript这些都是universal W3C standards.

观点2 解决web体验问题

有人会说, RN是为了解决web开发者在mobile上的性能体验问题. 的确, RN经过使用大量native组件作渲染, 优化了WebKit DOM渲染的性能, 经过batch update和专用线程的设计, 下降javascript和native通讯带来的性能开销, 保证主线程的流畅执行. RN的组件loadtime的确比web的好, 所以体验上面, 页面加载更快, 滑动时候局部留白的时间更短, 对用户而言体验效果更好. 但也带来了不少问题.

一般web的开发是创建在W3C完备标准之上, 不管是浏览器中, 仍是app中的webview中, 都遵循W3C的一套标准实现. 也就是说web开发不须要关心具体的浏览器是怎样实现的, 只要按照规范开发, 就能跑在各类各样的容器上面, 也是在此基础上, 各类各样的javascript技术蓬勃发展. 反观RN, 官方提供了一套javascript API, 可是和W3C相比, 还不成熟完备. 对于web开发很难说把native这层看为透明的. 或者说, 不改变native彻底使用javascript的开发局限性很大. 极可能某个native组件的性能或者功能不知足现有业务需求, 这时就很尴尬, 须要咱们深刻native的组件. 一旦涉及native组件, 伴随而来的还有版本和兼容等问题. 做为开发而言, 须要熟悉web native和RN框架, 这带来的是开发效率的问题. 但随着官方不断吸纳标准的组件, 这个问题会逐渐变小, 但站在如今, 这个问题的确存在.

站在这个角度上, 若是web开发者也掌握了native开发的技能或者有app开发的支持, 那为何不直接作成native app? RN的性能和体验和native为主的app仍是有差距的. 这里总结下来, RN会提高web体验, 但有必定局限性, 可能成为后面业务发展的瓶颈.

观点3 解决native开发和发布效率问题

有人又会说, native app不能作动态发布, 开发效率低, 而RN能够. 在发布问题上面, AppStore是严禁热部署动态code的, 所以每次发布都须要经过AppStore审核, 而近期AppStore的审核时间已经缩短到24h之内. Android平台上面, 须要解决的是更新率的问题, 目前业界一些插件化动态发布的方案能够完成动态更新, 如手淘的Atlas, 点评的DynamicAPK.

开发效率上面若是Android和iOS可以用同一套javascript实现, 在熟悉了RN环境后, 的确能够大幅提高开发效率. 但对于native开发而言, 仍是有必定起步成本, 并且仍是前面提到的瓶颈问题, 依赖现有native组件的完备程度.

问题2 RN如今解决了什么问题?

按常理讲, 推出技术方案大多基于自身遇到的问题. 但RN并无在Facebook的主流产品中使用, 并且使用RN的App也大可能是小众的App.

相比之下, Facebook的Instant Article更为抢眼, native端将pageLoad, 交互体验做为最终目标, 提升内容体验. 同时解决内容发布的几个问题, 下降发布门槛, 增长广告收益, 提供数据分析.

RN技术自己并无什么问题, 问题是各方面都比较好的方案, 在真实业务场景下反而更难用好.

问题3 RN的尴尬源自哪里?

最开始看到javascript+native这种技术, 想到的是端游开发界. 不少端游开发也是使用lua+游戏引擎的技术, lua写逻辑更快, 引擎性能更好. 不一样的游戏用多套脚本, 引擎能够持续复用. 这个很像RN解决问题的思路, 但为何在RN上行不大通呢?

反复的思考后, 以为根源是在mobile这里. mobile有什么特色? 用户时间碎片化, 单任务. 碎片化怎么理解, 根据友盟+的数据分析报告, 除了主流的资讯, SNS, 游戏类之外, 一我的使用app次数是分钟级别的, 而使用次数却会有10+次. 单任务怎么理解, 用户在使用手机的时候更难作app切换, 不会像pc中同时开启多个任务去作. 这两个核心的特色决定了, 用户较难以等待, 更容易流失. 因此pageLoad time是很重要的一个指标, 尤为是内容型的页面. 而RN同native相比在pageLoad time上是有很大差距的.

在另外一边, 相比web, RN性能虽然比web好, 但灵活程度, 成熟程度远远不如web技术. 而是有web技术开发的业务通常来讲对体验的要求有必定容忍. 同时还有Google等在作的专一mobile web page性能的Accelerate Web Page这类项目, 这样RN和web的性能很难拉开大的差距.

这样RN处在了一个不上不下的尴尬位置.

看清问题, 找到解法.

“再 NB 的想法和假设，真正到了实现层面，也必需要落实到具体的用户、需求和场景这三要素上面.”

前面一直在说问题, 不是说不承认RN的技术, 只是不想让你们跟着热潮去入坑, 而关键是要把相关的技术放在一块儿比较, 看哪一个方案适合本身的业务场景.

举个例子, 在有强运营需求的基础功能上, 很是适合用RN来作运营模块. 由于运营的特性是时效性, 到达率, 而基础功能又须要保证稳定的体验. 过去的一年个人团队都在使用native为主+动态模块这种技术, native上提早作好动态模块的支持, 当营销活动点到来时, 能够用RN这种动态技术, 快速响应, 动态上线.

再举个例子, 像作Instant Article这种内容页面, 会有大量的内容, 以几种排版布局展现. 这类的业务的核心是对内容的承载能力, 体验. 像这类的业务应该针对业务的现状和近期发展, 肯定适合业务的方案, 并保持对将来的可扩展性. 若是没有运营类的需求场景, pure native的实现能够彻底知足需求, 设计后台接口时考虑到布局和组件的扩展性, native上能保证无痛的后续新增和修改布局, 就能够了. 简单的架构也方便后面针对性能瓶颈作持续优化.

总之, 对新技术要保持敏感, 在实际业务的技术选型上仍是要保持警戒, 慎重权衡.