【杂谈】RN的一点回顾与将来的展望

　　从开始到如今，笔者接触RN已经接近半年，适逢各类变化的发生，因而，简单的遐想了一下RN的将来。

　　Airbnb在今年早些时候，宣布了放弃继续使用RN，而且发布了一篇“React Native at Airbnb: The Technology”的长篇博客，详细的讲了在airbnb中，使用RN的过程当中，本身的总结的一些经验和一些痛点，鉴于国内网络环境的缘由，笔者也简单的转载一下（限于笔者的英文水平，翻译不确切之处还请批评指正）：

　　作得好的地方：

　　跨平台、统一的设计语言系统（DLS）、React（特别是组件体系、简单的生命周期和声明式的写法）、迭代速度、基础设施上的额外开销（如网络、设备信息、i18n等）、性能、Redux、以native为支撑（更强大的native能力）、静态分析、动画、js/React的开源、伸缩盒模型（基于yoga）、web端的合做。

　　作得不是那么好的地方：

　　React Native的不成熟：虽然rn发展得很快，可是有欠成熟的它在某些具体的方面作得并很差，并且这种不成熟，没法避免；

　　维护React Native的分支：因为rn的不成熟，须要咱们去fork本身并维护rn的代码，可是这对于升级RN版原本说是很是恐怖的；

　　js的可用性：因为js是一门弱类型语言，这致使在其余工程师在学习和使用的时候很不便利，虽然咱们尝试使用了flow和ts，可是效果并不理想（咱们将会继续在web中使用ts）；

　　重构：js的弱类型特性致使了再项目重构时很是困难；

　　JSC（javascriptCore）的不一致性：ios会使用统一的jsc，这并无什么问题，可是在android上，因为各厂商使用的jsc都不同，你颇有可能会使用默认的jsc（版本很是古老），

　　并且，在调试的时候咱们一般都会使用chrome开发者工具，虽然这在99%的状况下都是没问题的，因为在调试时js是跑在chrome的v8引擎中的，这致使了android调试时，其实运行的环境与咱们所指望的并不相同，这很大程度上增长了调试的难度；（笔者也曾碰到过Date对象的实现不一致的问题）；

　　RN的开源库：由于RN须要对各个平台的熟悉，可是一般的用户仅了解一到两个平台，这也致使了RN的开源库在实际使用时，总会或多或少的碰到一些问题；（笔者也在切换打包工具时碰到了依赖库模块规范不规范的问题）；

　　平行的基础设施和功能：咱们积累大量的native基础设施，可是在RN，这一切都须要从零开始，在很长的一段时间内，这其实对于咱们的工程师的开发效率是有很大的影响的；

　　crash监控：由于RN在行业中的特殊性，咱们不得不开发不少上报的基础设施（如上传sourcemap）等工具去帮助本来已经成熟的工具（如Bugsnag）来进行crash报告统计;

　　native bridge：因为js的弱类型特性，致使在与native通讯时，本来的整形会被转换为字符串，而这些操做颇有可能会引发某个平台的调用失败或者崩溃，但在上层却没法得知；

　　初始化时间：在RN开始渲染前，你必须先初始化运行时，但这会花费至少几秒的时间，这也使得RN APP的初始化时间很长；

　　初始化渲染时间：不像native的渲染，RN的渲染须要从主线程->js->yoga layout线程->主线程，才能完成渲染，而这一般又会消耗（P90 280ms in iOS 440ms in Android），

致使咱们须要采起一些hack手段来避免出现意料以外（显示白屏）的状况

　　app包大小：RN在包大小上也有一些无法忽略的影响，在Android上，整个RN的包大小（Java + js + native库 + js runtime）已经接近8mb，再加上x86和arm，就已经12mb了；

　　64位：因为这个issue,咱们至今未能在android上完成；

　　手势：咱们一般都会避免在RN的应用里使用复杂的手势，由于iOS和Android对不一样手势是的实现和识别都有差别，且没办法统一；

　　长列表：虽然RN已经对长列表作了一些优化，好比FlatList，可是仍然有许多由于线程的缘由带来的限制没法解决；（好比快速滚动时view没办法同步刷新，Text元素无法预先计算高度等）

　　升级RN：RN升级过程当中，新版的RN有时候会依赖React的beta或者alpha版本，可是大部分的第三方库并不会去支持这些“预发布”的版本，这个升级也带来了很大的麻烦；

　　无障碍访问：RN无障碍访问的API存在的很多问题，使得咱们不得不为了一个很小的改动而须要fork一个独立的RN版原本进行修改；

　　难以修复的crash：在使用中，咱们还碰到了一些没法修复的crash;

　　跨进程保存实例状态：在android上，因为Android本身的机制它会根据设备的内存状态结束位于后台的进程（好比你的RN应用），当从新唤起的时候，你的app使用状态将得不到保存，这一特性虽然能够用redux的技术来fix，可是他并不能彻底结局问题，并且在某些状况，甚至会引发崩溃。

　　其实Airbnb碰到的问题笔者大部分也碰到了，以前的文章也有说起《rn踩坑实践——从输入框“们”开始》、《RN持续踩坑实践》、《RN心路历程》，这里就再也不赘述了。

　　总的来讲，对笔者而言，RN更适合用在那种内嵌H5的且交互不会太复杂，并且并不要求全平台一致的场景，而整个APP都要推RN，其实就笔者的经历而言，并不算是一个很好的选择。

　　另外，近几个月flutter也进入了你们的视野，并且它所推崇的全平台一致性也是一个很吸引人的特性。不过它是基于Dart的，固然对于native的同窗不用再写js的也是件好事情，不过也因为不在依赖js，也就摒弃了RN一直使用的jsc的一整套架构，而取而代之使用了基于google本身实现的渲染层api，来达到一致性的效果。甚至令笔者产生了一种“flutter才是将来”的错觉。

　　固然一切在没有实践以前都是雾里看花，毕竟生态才是一门技术是否可以持续发展的关键，如今谈这些也许，还有点早。

　　其实整个前端圈子发展得愈来愈好，新事物层出不穷，将来，说不定Firefox OS相似的技术方案也会成为主流也说不定。