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