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 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。