链接：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方案的发展历程也能印证这一点。
泻药！
不得不说一个事实，跟谁近，跟谁亲！
跟谁近？从源代码到渲染，经过了哪些环节。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
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。