UI系统的核心在于渲染机制：效率与生命--原生渲染为什么比webview渲染快？

做者：谷宝剑
连接：https://www.zhihu.com/question/264592475/answer/283852178
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

仅从渲染速度上看，我我的理解目前看仍是原生渲染比较有优点。

原生的渲染方式：

view->layout->renderNode ->合成->GPU渲染

webview目前渲染方式：

html->dom tree ->render tree ->render layer + 栅格化 ->合成->gpu渲染。

一个简单的例子，更新一个textview的内容，对于Native来讲，须要经历 layout->view->renderNode->合成->GPU，native layout算法比浏览器快，renderNode的更新只涉及textview。对于WebView须要经历：dom tree update->layout->render tree update ->render layer update ->render layer + 栅格化 ->合成->gpu渲染。经历的流程比较多，webview的layout相对原生也会慢一些，更新的节点就不止一个textview这么简单了，涉及更大的栅格化更新。 Native滚动和局部刷新上作的比浏览器好，长列表更是秒杀Webview。

 

从总体用户体验上看，react-native, weex 这些比webview机制上要有优点。

webview layout->render tree ->渲染是串行执行的，木有batch机制，频繁更新样式会卡顿。因此才有react这样的virtual-dom方案来解决这个batch问题，但串行的机制是木有变的。

react-native weex方案线程分为： JS Thread、DOM Thread、Native Main Thread. JS的执行在JSThread，Dom Layout在Dom Thread，渲染在 Main Thread，并行化作的很是好；自然的batch机制，频繁更新不会致使频繁layout。尤为是Weex，小巧玲珑，作的更好。来个真实的视频你们看区别：

正常List对比：普通长列表对比

压力测试：长列表压力测试

 

即便手机性能再提高十倍，只是WebView的应用场景更大一些，始终没法取代原生的高性能优点。从PC端看，QQ 百度网盘等采用duilib方案的发展历程也能印证这一点。

 

https://www.zhihu.com/question/264592475

 

泻药！

不得不说一个事实，跟谁近，跟谁亲！

跟谁近？从源代码到渲染，通过了哪些环节。webview自己其实更像一个容器或者盒子，它是装在在OS里面的一个套件而已，程序（HTML+js）要到OS必须走出这个盒子, 多走了几步，天然比人家慢一些，并且关键还不是多走一步。

跟其余比起来，前端技术栈的性能，简直不可直视。UI层，玩不过native；服务端，执行效率其实没优点（好比高运算量的），优点仅限于异步IO（go和py看了一眼node，跑本身的代码去了）。

RN不是很是熟悉，把 js 的数据结构 map 成 native 的数据结构吧（JNI & JSC?），执行逻辑仍是在js线程上。

不知道有一个问题解决了没：JS TO NATIVE 过程当中，须要花费大量的时间来作mapping，这点上，若是复杂一点的UI，首次渲染时间的问题怎么破~~~

在现有模式下，不论浏览器怎么优化，也不能跟native媲美，终于有人提出了大胆的假设，在浏览器上跑二进制吧：WebAssembly? 

emmmmmmmm, 如今谈这个是早是晚，不清楚。

做者：郑小松 连接：https://www.zhihu.com/question/264592475/answer/283408594 来源：知乎 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。