HTML5要如何達(dá)到原生性能
日期：2016-03-17點(diǎn)擊：2760
編者按：HTML5應(yīng)用被視為讓本地軟件云端化的利器，HTML5游戲也被視為一片新的藍(lán)海，然而，HTML5遠(yuǎn)遜于原生的性能讓眾多開發(fā)者望而卻步。本次InfoQ中文站便就此問題采訪了英特爾(中國)開源技術(shù)中心負(fù)責(zé)crosswalk runtime和H5優(yōu)化、硬件加速的兩位工程師。
InfoQ：請先做個簡單的自我介紹
余枝強(qiáng)：我是英特爾中國開源技術(shù)中心的軟件技術(shù)經(jīng)理余枝強(qiáng)，主要負(fù)責(zé)HTML5引擎 -Crosswalk在安卓平臺的開發(fā), 以及一些新興Web技術(shù)的研發(fā)
顧揚(yáng)：我是英特爾中國開源技術(shù)中心web研發(fā)經(jīng)理顧揚(yáng)，負(fù)責(zé)web圖形相關(guān)功能(CSS, Canvas2D和WebGL等)的實現(xiàn)和優(yōu)化
InfoQ:大家都很期待H5達(dá)到原生性能，那么從硬件層面和瀏覽器層面來說，H5能否達(dá)到原生性能呢?
余枝強(qiáng)：其實現(xiàn)在輕度、中度游戲/應(yīng)用如果能夠通過一些全棧式的優(yōu)化(包括應(yīng)用層，軟件庫，Web引擎層)，某些場景下可能還需要一些Hybrid實現(xiàn)， 這樣，HTML5應(yīng)用接近或達(dá)到類似原生應(yīng)用的性能應(yīng)該問題不大。但重度、計算量大的應(yīng)用(比如復(fù)雜的3D游戲，包括物理引擎等)目前確實還是有不少差距的。
我這里可以分享幾個例子，它們都是一開始性能有較大的差距，但通過相應(yīng)的優(yōu)化性能達(dá)到了質(zhì)的提升。
其中一個例子是和騰訊Alloy團(tuán)隊合作的，針對HTML5圖像處理庫的優(yōu)化。原先這個圖像處理庫在移動端性能不理想，比如說對一副圖像實現(xiàn)一個木雕效果需要十幾秒甚至幾十秒的時間(其中涉及到較為復(fù)雜的計算)，后來我們在應(yīng)用里引入并行 (WebCL, 它可以利用CPU 以及GPU中的多核的能力)，通過對圖像處理庫相應(yīng)的部分用WebCL重新實現(xiàn)，另外在Crosswalk引擎里加入WebCL的支持以及相應(yīng)優(yōu)化，最后這個圖像處理時間在安卓平臺上從幾十秒降低到2秒以內(nèi)。
另外一個例子是和觸控科技合作了， 針對一個游戲-“進(jìn)擊的小怪物”的 HTML5版本做優(yōu)化，其中涉及到比較酷炫的消除/爆炸效果，而這些效果在最新的Chrome里跑只有十幾的fps 。通過引入Crosswalk 的游戲模式，把上層相對耗時的API通過原生的實現(xiàn)再橋接到HTML5引擎中，使得酷炫效果的性能比Chrome好5倍左右。
另外最近我們在調(diào)研一種典型的用戶場景：大規(guī)模的圖片的加載和滑動的性能問題， 以及和原生應(yīng)用的性能區(qū)別。經(jīng)過初步的調(diào)研，我們發(fā)現(xiàn)性能的差距有幾個方面的原因：沒有做更好的緩存，沒有利用系統(tǒng)服務(wù)，不必要的事件處理，不必要數(shù)據(jù)轉(zhuǎn)換，以及大量的數(shù)據(jù)缺少高效的數(shù)據(jù)傳輸機(jī)制，這中間有很多開銷，會影響到用戶體驗。我們打算做一個參考實現(xiàn)來解決這種類型應(yīng)用的性能問題。
總結(jié)來說， HTML5的性能問題，可能是多重原因組成，比如應(yīng)用本身設(shè)計不合理，加了不必要的事件，沒有用更好的緩存等等，另一方面引擎也可能有問題，比如數(shù)據(jù)傳遞，比如沒有利用上更好的硬件特性。再加上Javascript語言的動態(tài)性，相對不容易寫出優(yōu)化的代碼。這些問題，如果能夠有全局的角度出發(fā)做相應(yīng)優(yōu)化，性能會有機(jī)會提升非常明顯。另外對應(yīng)用開發(fā)者來說，盡量用一些成熟的框架，最好也要對對底層引擎有一定的了解從而避開javacript 里的坑。成熟的框架相對來說已做了一些Javascript層面的優(yōu)化，再通過引擎本身針對應(yīng)用的場景做相應(yīng)優(yōu)化，同時讓W(xué)eb引擎更好的利用到底層的硬件能力，這些層面做好了，就容易有好的體驗。
顧揚(yáng)：從我的理解來說，native應(yīng)用直接跟硬件打交道，web應(yīng)用則是通過web引擎跟硬件打交道，多了web引擎這個中間層。正因為這個中間層，帶來了一些性能差異：
1， web引擎相對native發(fā)展來說還很年輕，對CPU，GPU這樣的計算資源還不能充分應(yīng)用。
2，web引擎是一種通用平臺，日益增強(qiáng)的能力也帶來了日益復(fù)雜的架構(gòu)和更多的overhead。當(dāng)然除卻web引擎帶來的性能損失，JS語言本身也有一些局限性，比如數(shù)據(jù)類型不明確，不支持多進(jìn)程等。我們的優(yōu)化主要針對web引擎的上述兩個短板：
1， 充分發(fā)揮硬件，主要是CPU和GPU的能力。比如充分利用Intel CPU的特殊指令集，GPU的特殊extension。
2， 因為我們熟悉web引擎的各個階段，通過對典型應(yīng)用場景的性能評估，了解瓶頸所在，從而優(yōu)化引擎邏輯。
InfoQ:顧揚(yáng)可否再詳細(xì)地介紹下你們所做的優(yōu)化?
顧揚(yáng)：目前的很多web引擎都是基于Chromium項目。我們的優(yōu)化工作基本都是直接提交到Chromium，而且跟圖形相關(guān)。具體涉及的軟件倉庫，主要是Skia和Chromium(Blink已經(jīng)跟它融合)。
Skia方面優(yōu)化 :
1，很多操作還是通過CPU進(jìn)行的，Intel CPU有特殊指令集，用好這些指令集會有很多性能提升。
2，我們會做圖形也是因為web的趨勢是越來越多地用GPU而不是CPU來渲染。移動平臺的GPU能力，近年來增長非常快，很多以前只有CPU能完成的任務(wù)，現(xiàn)在都能用GPU完成，而且性能更好。Skia代碼中有些GPU的邏輯，要么有bug，要么還不夠優(yōu)化，我們消除了很多這樣的正確性和性能問題，從而可以順利的從CPU切換到GPU。
3，對路徑渲染的一些優(yōu)化。
4， CSS的很多優(yōu)化，比如transform，box-shadow。
Chromium方面優(yōu)化:
1，針對特殊場景的優(yōu)化。比如Canvas2D被用在輕量級應(yīng)用時，一些overhead可以忽略。但當(dāng)用于一些heavy的游戲，比如一幀要畫成百上千的東西時，引擎的一些overhead就突然成了瓶頸。
2，針對WebGL的各種優(yōu)化，比如上傳canvas/video到WebGL，GPU到GPU的紋理拷貝等。
3，一些場景下DOM操作的優(yōu)化。
4，針對反鋸齒效果性能的優(yōu)化。
InfoQ:很多游戲廠商不使用現(xiàn)有的引擎，可能會選擇自己寫一個。對于這些開發(fā)者，有沒有什么可以分享給他們的性能優(yōu)化方法呢?
余枝強(qiáng)：的確有這個現(xiàn)象，有很多HTML5游戲引擎廠商都是自定義的一套 API，實現(xiàn)上其實是完全繞過了HTML5引擎，直接調(diào)到了底層的庫。開發(fā)者就圍繞這些API來開發(fā)，這在某些情況下的確有更好的性能，但也喪失了HTML5的一些優(yōu)勢，包括通用性，以及與HTML5 API的交互能力 (比如DOM)。不過這也是一種做法，但我覺得另一種可能更好的路是把HTML5 和 原生實現(xiàn)更高效的融合起來， 在把HTML5 本身的優(yōu)勢發(fā)揮出來，把標(biāo)準(zhǔn)的API以及豐富的HTML5 庫利用起來，同時也能有和原生實現(xiàn)類似的性能。
InfoQ:對于瀏覽器而言，有無什么可從Web 引擎借鑒過來的優(yōu)化理念?
余枝強(qiáng)：這個是有的。但首先我們要理解一下瀏覽器和獨(dú)立的Web 引擎之間的區(qū)別。比如對于瀏覽器，你不知會訪問哪個頁面，所以為了防止?jié)撛诘膼阂獯a，在安全方面需要做很多檢查，增加額外的開銷，不同的頁面也需要做相應(yīng)的隔離。同時，瀏覽器需要更通用一點(diǎn)，來滿足不同應(yīng)用的需求，而通用也就意味著不容易做一些特定的優(yōu)化。而作為一個獨(dú)立應(yīng)用，代碼是可控的，場景是特定的，相對容易做一些針對性的優(yōu)化。另外，在交互方面，比如瀏覽器里網(wǎng)頁前進(jìn)后退、手勢，這些對于獨(dú)立應(yīng)用是不需要甚至有沖突的，這方面也是不小的區(qū)別。
但對于基礎(chǔ)渲染，GPU加速等，瀏覽器和web引擎的基本是一致的. 還有，比如說把指令級的并行如SIMD帶入到Web平臺，這個也是通用的。SIMD.JS最先是在Crosswalk中有完整的實現(xiàn)，然后變成一個web標(biāo)準(zhǔn)，目前主流的瀏覽器廠商比如Google/Microsoft等都在加入相應(yīng)支持。
InfoQ：因為IOS上無法使用第三方runtime，所以有開發(fā)者覺得使用runtime會減少很多用戶。對于IOS這個問題，有沒有什么解決辦法?
余枝強(qiáng)：對于runtime會提供打包工具，可以將H5應(yīng)用可選地打包成Android或IOS應(yīng)用，所以不會減少用戶。 只是在IOS上實際使用的是它自身的WKview引擎，而不是我們的加速引擎。但是考慮到IOS硬件不錯，自帶引擎加速也還可以，所以其實IOS上的H5性能問題沒那么嚴(yán)重。
InfoQ:CSS和DOM操作算H5一個瓶頸吧?這方面的性能優(yōu)化可否再具體講講?
顧揚(yáng)：我們在這兩塊做的優(yōu)化不算多，主要針對一些特殊場景。比如上面提到CSS有個效果是box-shadow，計算非常耗資源。我們通過cache機(jī)制，把中間相對通用的計算結(jié)果保存下來，這樣很多后續(xù)運(yùn)算就不需要從頭來過，很好的提升了性能。當(dāng)然，做好這樣的優(yōu)化，需要做大量實驗，對數(shù)據(jù)的典型性有很好的把握，也要對Skia的cache機(jī)制有很好的了解，并做很多增強(qiáng)。DOM的一些優(yōu)化也是針對某些場景。比如在packaged app里，可以節(jié)省一些cache獲得很大的性能提升。
InfoQ：關(guān)于H5的優(yōu)化和硬件加速，還有什么需要補(bǔ)充的嗎?
顧揚(yáng)：優(yōu)化是很難做的，我們從12年開始做優(yōu)化，碰到的最大問題不是怎么修復(fù)瓶頸，而是壓根不知道哪是瓶頸。你想，H5有很多關(guān)于功能的標(biāo)準(zhǔn)，但卻沒有關(guān)于性能的。H5涉及的面很廣，包括JS，CSS，Canvas2D，WebGL，Web Audio， Web Video等。這些領(lǐng)域在不同的硬件配置，比如CPU，GPU，內(nèi)存，屏幕尺寸和分辨率上，表現(xiàn)都會有很大不同。怎么設(shè)計benchmark，既cover典型的應(yīng)用場景，又能充分測出每個領(lǐng)域的瓶頸所在，是最難的事。我們從一開始就做好了長期作戰(zhàn)的準(zhǔn)備，比較系統(tǒng)的為優(yōu)化做準(zhǔn)備。我們收集，開發(fā)和評估各種benchmark，不斷積累測試方法，自主開發(fā)一系列工具幫助我們自動化測試和明確問題。在這些benchmark幫我們明確了問題之后，就需要依賴我們對web引擎的了解，分析問題所在。有些問題是比較好解決的，比如有些局部代碼寫的不好，或者說有些regression，也就是說以前是好的，現(xiàn)在不好。另一些問題是比較系統(tǒng)性的，解決它們需要大量的改動，甚至改動底層架構(gòu)。我們通常會積極跟upstream討論，尋求最佳的解決方案。
這是我們整體做優(yōu)化的一個思路，一個過程。優(yōu)化不是一蹴而就的，需要長期的積累和很多很瑣碎的工作。
InfoQ：再問一下，對于耗電，該如何優(yōu)化?
顧揚(yáng)：耗電和性能，很多時候是一對矛盾，需要很好的權(quán)衡。
有的時候很少的性能損失或者不損失，就能省很多電。比如通常的web應(yīng)用，每幀的顯示通常要經(jīng)過CPU處理，然后交由GPU渲染。如果GPU是瓶頸，那么CPU再快也沒有用。這個時候可以通過一些聰明的調(diào)度算法，減少CPU端的操作。再比如有些video的解碼工作，交給GPU處理不僅快，還能大大節(jié)省整體耗電。
但決定并不是每次都這么容易。當(dāng)省電的代價是比較大的性能損失時，就需要很好衡量了。有時可以在web引擎里面設(shè)置一些啟發(fā)式規(guī)則，根據(jù)系統(tǒng)當(dāng)時的情況，作出合適的選擇。
InfoQ：對未來的展望?
顧揚(yáng)：web發(fā)展很快，越來越多的人貢獻(xiàn)idea和code。這些貢獻(xiàn)主要在兩方面，能力和性能。
能力方面，很多native的能力正在很快的加到web中，像藍(lán)牙，NFC，AR，VR等。我們想要打通native和web的界線，native能做的，web都要做到。之前web是在追趕native的能力，今后要慢慢lead這些能力。世界不斷發(fā)展，不斷有新技術(shù)出現(xiàn)，這些新技術(shù)以后先在web還是先在native落地，則看誰基礎(chǔ)更好，實現(xiàn)更經(jīng)濟(jì)了。哪邊發(fā)展快，哪邊就能引領(lǐng)行業(yè)發(fā)展。
第二類是性能。上面已經(jīng)談的比較多，主要是JS語言本身的性能，以及web引擎本身的性能。至于能不能達(dá)到native性能，坦白說很難，但可能有了足夠好的性能之后，這個問題就不那么重要了。比如說web有個常用的指標(biāo)FPS(一秒幾幀)，對人眼來說60FPS就已足夠好，再高人也不易察覺了。所以如果web可以達(dá)到60幀一秒，native可以到80幀，雖然web還是不如native，但已經(jīng)足夠好。這個時候，web在其他方面的優(yōu)勢，比如統(tǒng)一的標(biāo)準(zhǔn)，高效的開發(fā)，方便的更新等，將秒殺這些很小的劣勢。web就會變成一個很適宜開發(fā)的成熟平臺。所以性能發(fā)展的目標(biāo)，不一定是要達(dá)到native，而是足夠好。
InfoQ：有言論說，隨著從C/S到B/S的轉(zhuǎn)變，未來我們只需要瀏覽器就足夠了，客戶端軟件會被瀏覽器上的云端軟件取代，你怎么看?
顧揚(yáng)：我做web這么多年，非常熱愛web，也對它很有信心。但是我認(rèn)為世界上的統(tǒng)一是不可能的，也是不適合發(fā)展的。總有需要native存在的領(lǐng)域，比如有些對性能要求非常高的地方。做個類比，我們看一下計算機(jī)語言的發(fā)展歷史，高級語言在慢慢侵蝕低級語言的地盤，從匯編到C/C++，Java，以及很多的腳本語言，但低級語言并沒有消失。在很多底層庫中，還用了大量的匯編，C/C++有更多的領(lǐng)域在使用，更不用說Java之類了。
web的使命，不是徹底取代native，而是補(bǔ)充了多樣性，把應(yīng)用這個蛋糕做大了。以前的人，哪有這么多應(yīng)用可以用。可預(yù)測的是，在經(jīng)歷了高速發(fā)展期后，它跟native的在應(yīng)用中的比例會趨于一個穩(wěn)定的狀態(tài)，native仍會有相當(dāng)可觀的比例。
被訪者簡介
余枝強(qiáng)，目前是英特爾開源技術(shù)中心的軟件技術(shù)經(jīng)理。 主要負(fù)責(zé)HTML5 引擎 – Crosswalk 在安卓平臺的開發(fā)，以及一些其他和Web有關(guān)的新興技術(shù)的研發(fā)工作(如HTML5 并行技術(shù), HTML5 游戲優(yōu)化，3D Camera等)。他堅信Web是未來， 也非常希望和大家一起努力，讓這個未來能夠更快更好的到來。
顧揚(yáng)，英特爾中國開源技術(shù)中心web研發(fā)經(jīng)理，負(fù)責(zé)web圖形相關(guān)功能(CSS, Canvas2D和WebGL等)的實現(xiàn)和優(yōu)化。2013年碩士畢業(yè)于浙江大學(xué)，后加入Intel從事編譯器開發(fā)5年，轉(zhuǎn)而主攻web。在web領(lǐng)域，帶領(lǐng)團(tuán)隊完成Android Chrome 32位到64位的移植，負(fù)責(zé)英特爾移動平臺web支持，更是貢獻(xiàn)400多個patch到Chromium Upstream (包括Chromium, Blink, Skia等)和Khronos Github，實現(xiàn)和優(yōu)化圖形相關(guān)功能。業(yè)余愛好羽毛球，曾任上海英特爾羽毛球俱樂部主席7年，獲獎頗豐。
