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仍會有相當可觀的比例。