仅从渲染速度上看，我个人理解目前看还是原生渲染比较有优势。

原生的渲染方式：

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/answer/283408594
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。