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
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
posted @ 2019-05-22 17:23  zzfx  阅读(1931)  评论(0编辑  收藏  举报