專訪英特爾（中國）開源技術中心：HTML5要如何達到原生效能

編者按：HTML5應用被視為讓本地軟體雲端化的利器，HTML5遊戲也被視為一片新的藍海，然而，HTML5遠遜於原生的效能讓眾多開發者望而卻步。本次InfoQ中文站便就此問題採訪了英特爾（中國）開源技術中心負責crosswalk runtime和H5優化、硬體加速的兩位工程師。

\\

InfoQ：請先做個簡單的自我介紹

\\

\

餘枝強：我是英特爾中國開源技術中心的軟體技術經理餘枝強，主要負責HTML5引擎 -Crosswalk在安卓平臺的開發, 以及一些新興Web技術的研發
顧揚：我是英特爾中國開源技術中心web研發經理顧揚，負責web圖形相關功能(CSS, Canvas2D和WebGL等)的實現和優化

\

\\

InfoQ:大家都很期待H5達到原生效能，那麼從硬體層面和瀏覽器層面來說，H5能否達到原生效能呢？

\\

\

餘枝強：其實現在輕度、中度遊戲/應用如果能夠通過一些全棧式的優化(包括應用層，軟體庫，Web引擎層)，某些場景下可能還需要一些Hybrid實現， 這樣，HTML5應用接近或達到類似原生應用的效能應該問題不大。但重度、計算量大的應用（比如複雜的3D遊戲，包括物理引擎等）目前確實還是有不少差距的。

\\

我這裡可以分享幾個例子，它們都是一開始效能有較大的差距，但通過相應的優化效能達到了質的提升。
\其中一個例子是和騰訊Alloy團隊合作的，針對HTML5影像處理庫的優化。原先這個影像處理庫在移動端效能不理想，比如說對一副影像實現一個木雕效果需要十幾秒甚至幾十秒的時間（其中涉及到較為複雜的計算），後來我們在應用裡引入並行 （WebCL, 它可以利用CPU 以及GPU中的多核的能力），通過對影像處理庫相應的部分用WebCL重新實現，另外在Crosswalk引擎里加入WebCL的支援以及相應優化，最後這個影像處理時間在安卓平臺上從幾十秒降低到2秒以內。
\另外一個例子是和觸控科技合作了， 針對一個遊戲-“進擊的小怪物”的 HTML5版本做優化，其中涉及到比較酷炫的消除/爆炸效果，而這些效果在最新的Chrome裡跑只有十幾的fps 。通過引入Crosswalk 的遊戲模式，把上層相對耗時的API通過原生的實現再橋接到HTML5引擎中，使得酷炫效果的效能比Chrome好5倍左右。

\\

另外最近我們在調研一種典型的使用者場景：大規模的圖片的載入和滑動的效能問題， 以及和原生應用的效能區別。經過初步的調研，我們發現效能的差距有幾個方面的原因：沒有做更好的快取，沒有利用系統服務，不必要的事件處理，不必要資料轉換，以及大量的資料缺少高效的資料傳輸機制，這中間有很多開銷，會影響到使用者體驗。我們打算做一個參考實現來解決這種型別應用的效能問題。

\\

總結來說， HTML5的效能問題，可能是多重原因組成，比如應用本身設計不合理，加了不必要的事件，沒有用更好的快取等等，另一方面引擎也可能有問題，比如資料傳遞，比如沒有利用上更好的硬體特性。再加上Javascript語言的動態性，相對不容易寫出優化的程式碼。這些問題，如果能夠有全域性的角度出發做相應優化，效能會有機會提升非常明顯。
\另外對應用開發者來說，儘量用一些成熟的框架，最好也要對對底層引擎有一定的瞭解從而避開javacript 裡的坑。成熟的框架相對來說已做了一些Javascript層面的優化，再通過引擎本身針對應用的場景做相應優化，同時讓Web引擎更好的利用到底層的硬體能力，這些層面做好了，就容易有好的體驗。

\\

顧揚：從我的理解來說，native應用直接跟硬體打交道，web應用則是通過web引擎跟硬體打交道，多了web引擎這個中間層。正因為這個中間層，帶來了一些效能差異：
\1， web引擎相對native發展來說還很年輕，對CPU，GPU這樣的計算資源還不能充分應用。
\2，web引擎是一種通用平臺，日益增強的能力也帶來了日益複雜的架構和更多的overhead。當然除卻web引擎帶來的效能損失，JS語言本身也有一些侷限性，比如資料型別不明確，不支援多程式等。我們的優化主要針對web引擎的上述兩個短板：
\1， 充分發揮硬體，主要是CPU和GPU的能力。比如充分利用Intel CPU的特殊指令集，GPU的特殊extension。
\2， 因為我們熟悉web引擎的各個階段，通過對典型應用場景的效能評估，瞭解瓶頸所在，從而優化引擎邏輯。

\

\\

InfoQ:顧揚可否再詳細地介紹下你們所做的優化？

\\

\

顧揚：目前的很多web引擎都是基於Chromium專案。我們的優化工作基本都是直接提交到Chromium，而且跟圖形相關。具體涉及的軟體倉庫，主要是Skia和Chromium(Blink已經跟它融合)。

\\

Skia方面優化 :
\1，很多操作還是通過CPU進行的，Intel CPU有特殊指令集，用好這些指令集會有很多效能提升。
\2，我們會做圖形也是因為web的趨勢是越來越多地用GPU而不是CPU來渲染。移動平臺的GPU能力，近年來增長非常快，很多以前只有CPU能完成的任務，現在都能用GPU完成，而且效能更好。Skia程式碼中有些GPU的邏輯，要麼有bug，要麼還不夠優化，我們消除了很多這樣的正確性和效能問題，從而可以順利的從CPU切換到GPU。
\3，對路徑渲染的一些優化。
\4， CSS的很多優化，比如transform，box-shadow。

\\

Chromium方面優化:
\1，針對特殊場景的優化。比如Canvas2D被用在輕量級應用時，一些overhead可以忽略。但當用於一些heavy的遊戲，比如一幀要畫成百上千的東西時，引擎的一些overhead就突然成了瓶頸。
\2，針對WebGL的各種優化，比如上傳canvas/video到WebGL，GPU到GPU的紋理拷貝等。
\3，一些場景下DOM操作的優化。
\4，針對反鋸齒效果效能的優化。

\

\\

InfoQ:很多遊戲廠商不使用現有的引擎，可能會選擇自己寫一個。對於這些開發者，有沒有什麼可以分享給他們的效能優化方法呢？

\\

\

餘枝強：的確有這個現象，有很多HTML5遊戲引擎廠商都是自定義的一套 API，實現上其實是完全繞過了HTML5引擎，直接調到了底層的庫。開發者就圍繞這些API來開發，這在某些情況下的確有更好的效能，但也喪失了HTML5的一些優勢，包括通用性，以及與HTML5 API的互動能力　（比如DOM）。不過這也是一種做法，但我覺得另一種可能更好的路是把HTML5 和 原生實現更高效的融合起來， 在把HTML5 本身的優勢發揮出來，把標準的API以及豐富的HTML5 庫利用起來，同時也能有和原生實現類似的效能。

\

\\

InfoQ:對於瀏覽器而言，有無什麼可從Web 引擎借鑑過來的優化理念？

\\

\

餘枝強：這個是有的。但首先我們要理解一下瀏覽器和獨立的Web 引擎之間的區別。比如對於瀏覽器，你不知會訪問哪個頁面，所以為了防止潛在的惡意程式碼，在安全方面需要做很多檢查，增加額外的開銷，不同的頁面也需要做相應的隔離。同時，瀏覽器需要更通用一點，來滿足不同應用的需求，而通用也就意味著不容易做一些特定的優化。而作為一個獨立應用，程式碼是可控的，場景是特定的，相對容易做一些針對性的優化。另外，在互動方面，比如瀏覽器裡網頁前進後退、手勢，這些對於獨立應用是不需要甚至有衝突的，這方面也是不小的區別。
\但對於基礎渲染，GPU加速等，瀏覽器和web引擎的基本是一致的. 還有，比如說把指令級的並行如SIMD帶入到Web平臺，這個也是通用的。SIMD.JS最先是在Crosswalk中有完整的實現，然後變成一個web標準，目前主流的瀏覽器廠商比如Google/Microsoft等都在加入相應支援。

\

\\

InfoQ：因為IOS上無法使用第三方runtime，所以有開發者覺得使用runtime會減少很多使用者。對於IOS這個問題，有沒有什麼解決辦法？

\\

\

餘枝強：對於runtime會提供打包工具，可以將H5應用可選地打包成Android或IOS應用，所以不會減少使用者。 只是在IOS上實際使用的是它自身的WKview引擎，而不是我們的加速引擎。但是考慮到IOS硬體不錯，自帶引擎加速也還可以，所以其實IOS上的H5效能問題沒那麼嚴重。

\

\\

InfoQ:CSS和DOM操作算H5一個瓶頸吧？這方面的效能優化可否再具體講講？

\\

\

顧揚：我們在這兩塊做的優化不算多，主要針對一些特殊場景。比如上面提到CSS有個效果是box-shadow，計算非常耗資源。我們通過cache機制，把中間相對通用的計算結果儲存下來，這樣很多後續運算就不需要從頭來過，很好的提升了效能。當然，做好這樣的優化，需要做大量實驗，對資料的典型性有很好的把握，也要對Skia的cache機制有很好的瞭解，並做很多增強。DOM的一些優化也是針對某些場景。比如在packaged app裡，可以節省一些cache獲得很大的效能提升。

\

\\

InfoQ：關於H5的優化和硬體加速，還有什麼需要補充的嗎？

\\

\

顧揚：優化是很難做的，我們從12年開始做優化，碰到的最大問題不是怎麼修復瓶頸，而是壓根不知道哪是瓶頸。你想，H5有很多關於功能的標準，但卻沒有關於效能的。H5涉及的面很廣，包括JS，CSS，Canvas2D，WebGL，Web Audio， Web Video等。這些領域在不同的硬體配置，比如CPU，GPU，記憶體，螢幕尺寸和解析度上，表現都會有很大不同。怎麼設計benchmark，既cover典型的應用場景，又能充分測出每個領域的瓶頸所在，是最難的事。我們從一開始就做好了長期作戰的準備，比較系統的為優化做準備。我們收集，開發和評估各種benchmark，不斷積累測試方法，自主開發一系列工具幫助我們自動化測試和明確問題。在這些benchmark幫我們明確了問題之後，就需要依賴我們對web引擎的瞭解，分析問題所在。有些問題是比較好解決的，比如有些區域性程式碼寫的不好，或者說有些regression，也就是說以前是好的，現在不好。另一些問題是比較系統性的，解決它們需要大量的改動，甚至改動底層架構。我們通常會積極跟upstream討論，尋求最佳的解決方案。
\這是我們整體做優化的一個思路，一個過程。優化不是一蹴而就的，需要長期的積累和很多很瑣碎的工作。

\

\\

InfoQ：再問一下，對於耗電，該如何優化？

\\

\

顧揚：耗電和效能，很多時候是一對矛盾，需要很好的權衡。
\有的時候很少的效能損失或者不損失，就能省很多電。比如通常的web應用，每幀的顯示通常要經過CPU處理，然後交由GPU渲染。如果GPU是瓶頸，那麼CPU再快也沒有用。這個時候可以通過一些聰明的排程演算法，減少CPU端的操作。再比如有些video的解碼工作，交給GPU處理不僅快，還能大大節省整體耗電。
\但決定並不是每次都這麼容易。當省電的代價是比較大的效能損失時，就需要很好衡量了。有時可以在web引擎裡面設定一些啟發式規則，根據系統當時的情況，作出合適的選擇。

\

\\

InfoQ：對未來的展望？

\\

\

顧揚：web發展很快，越來越多的人貢獻idea和code。這些貢獻主要在兩方面，能力和效能。
\能力方面，很多native的能力正在很快的加到web中，像藍芽，NFC，AR，VR等。我們想要打通native和web的界線，native能做的，web都要做到。之前web是在追趕native的能力，今後要慢慢lead這些能力。世界不斷髮展，不斷有新技術出現，這些新技術以後先在web還是先在native落地，則看誰基礎更好，實現更經濟了。哪邊發展快，哪邊就能引領行業發展。
\第二類是效能。上面已經談的比較多，主要是JS語言本身的效能，以及web引擎本身的效能。至於能不能達到native效能，坦白說很難，但可能有了足夠好的效能之後，這個問題就不那麼重要了。比如說web有個常用的指標FPS(一秒幾幀)，對人眼來說60FPS就已足夠好，再高人也不易察覺了。所以如果web可以達到60幀一秒，native可以到80幀，雖然web還是不如native，但已經足夠好。這個時候，web在其他方面的優勢，比如統一的標準，高效的開發，方便的更新等，將秒殺這些很小的劣勢。web就會變成一個很適宜開發的成熟平臺。所以效能發展的目標，不一定是要達到native，而是足夠好。

\

\\

InfoQ：有言論說，隨著從C/S到B/S的轉變，未來我們只需要瀏覽器就足夠了，客戶端軟體會被瀏覽器上的雲端軟體取代，你怎麼看？

\\

\

顧揚：我做web這麼多年，非常熱愛web，也對它很有信心。但是我認為世界上的統一是不可能的，也是不適合發展的。總有需要native存在的領域，比如有些對效能要求非常高的地方。做個類比，我們看一下計算機語言的發展歷史，高階語言在慢慢侵蝕低階語言的地盤，從彙編到C/C++，Java，以及很多的指令碼語言，但低階語言並沒有消失。在很多底層庫中，還用了大量的彙編，C/C++有更多的領域在使用，更不用說Java之類了。
\web的使命，不是徹底取代native，而是補充了多樣性，把應用這個蛋糕做大了。以前的人，哪有這麼多應用可以用。可預測的是，在經歷了高速發展期後，它跟native的在應用中的比例會趨於一個穩定的狀態，native仍會有相當可觀的比例。

\

\\

被訪者簡介

\\

餘枝強，目前是英特爾開源技術中心的軟體技術經理。 主要負責HTML5 引擎 – Crosswalk 在安卓平臺的開發，以及一些其他和Web有關的新興技術的研發工作（如HTML5 並行技術, HTML5 遊戲優化，3D Camera等）。他堅信Web是未來， 也非常希望和大家一起努力，讓這個未來能夠更快更好的到來。

\\

顧揚，英特爾中國開源技術中心web研發經理，負責web圖形相關功能(CSS, Canvas2D和WebGL等)的實現和優化。2003年碩士畢業於浙江大學，後加入Intel從事編譯器開發5年，轉而主攻web。在web領域，帶領團隊完成Android Chrome 32位到64位的移植，負責英特爾移動平臺web支援，更是貢獻400多個patch到Chromium Upstream (包括Chromium, Blink, Skia等)和Khronos Github，實現和優化圖形相關功能。業餘愛好羽毛球，曾任上海英特爾羽毛球俱樂部主席7年，獲獎頗豐。