React Native 分析（番外篇之一) 前端面临的包袱

PS:不知道怎么归类，属于一些想说但是又不知道说哪里的内容，于是单独出个番外篇系列吧。

如果要设计一个如React Native前端框架，需要知道前端面临了哪些包袱，才能针对这些包袱造轮子，或者避免重复造轮子。

包袱一
由于WebView作为一个通用的浏览器内核，本身要求具备向前兼容性，比如虽然用flexbox布局浏览器可以更高效地layout，但为了兼容它仍然必须得能认得浮动布局、相对定位布局甚至表格布局。这些逻辑交织在一起非常复杂，牵一发而动全身。假设我现在fork一个新的WebView出来，裁减掉flexbox之外的支持，就大大降低了layout逻辑的复杂度，即使不做优化就已经能快不少了，更何况情况变简单以后还能够针对flexbox布局做专门的优化，获得更大的性能提升。

包袱二
浏览器的内部机制以及js语言在设计上，其实也有一些历史包袱。比如浏览器从一开始设计，js engine和dom engine就是两块独立的黑盒，js调用dom时相当于一次rpc调用，每次调用都会涉及上下文的保存和恢复。同时，js excute和dom render是跑在一个线程里的，即使两者没有调用关系，dom也必须等js执行完毕才能render。这两件事的结果就是网页在运行过程中会在这两个黑盒之间来回切换，各种上下文切换，各种互相等待，这样一来掉帧就在所难免了。所以，如果我们能够让js engine和dom engine在执行层面能够打通，变rpc调用为本地调用，就能加快不少。更进一步来说，如果能够有效利用多核，把js excute和render在一定条件下并行起来，或者把style resolving和layout并行起来，也能提升新性能。
涉及到 hrybird，rpc不只存在于js与dom之间，还存在于js环境与native环境两个环境的协议沟通。
既然是hybrid，那离不开na的工作，na的运行环境与js的运行环境是完全独立的两个环境，都依赖于一个“桥”的概念

a.基于webview hybrid依赖于webview的JSbridge设计
b.基于JavaScriptCore的桥接API的JSbridge设计

桥的设计与调用方案各不相同，但走过这个桥也是有开销和成本的，并不是随便调用的，JSCore在app环境内是一个JS虚拟机+不同上下文，而Na的环境也会有安卓的java虚拟机，iOS/C/C++的直接内存环境，不同的环境之间，通信传递数据，面临的都是rpc的切换开销。如果想减少这个包袱，那就应该尽可能的减少web-native通信次数，可能的布局运算，逻辑运算，都先放在web这个环境的内部。

拿JSPatch对比react-native来说，JSPatch确实是以脚本驱动native实现了动态更新的目标，但是缺失的确是一整套UI描述语言的布局能力，没有第一个包袱，但也就不能跨平台。

React Native和阿里的Weex，主要在甩第一项包袱，优化了第二项。

iOS的Auto Layout会把父view，子view之间的坐标关系，样式信息，转化成一个N元一次方程组，子view越多，方程组的元数越多，方程组求解起来越耗时，因此运算性能也会越来越底下，这一点其实被广泛吐槽。
关于 flexbox 布局，有篇挺好的文章