鏈接：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
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。