移動 Web 應用性能的 5 個秘籍
英文原文：5 Myths About Mobile Web Performance
最近我們聽到一些關于移動 HTML 性能的一些誤傳，實際上它們并不是很準確。和好的“城市誤傳”一樣，它們聽起來令人信服的和可信。但是這些誤傳是基于，不正確的前提和對本地和網絡軟件棧 之間關系的誤解，以及曲解數據的散點。我們認為重要的是，要對這些誤傳進行驗證，使用用我們已經收集了多年來關于性能的數據和我們自己的做的移動 Web 應用程序性能的經驗。
誤傳1：移動網絡性能主要是由運行在 CPU 上的 JavaScript 性能決定
現實：大多數網絡性能是由渲染管線的優化程度，GPU 加速程度，DOM 交互速度三者制約。更快的 JavaScript 總是有用的，但它很少是決定因素。
誤傳2：因為硬件不停的升級，CPU 越快，JavaScirpt 執行的也會越快(又稱摩爾定律)
事實上：在過去四年間，移動設備上的 JavaScript 的渲染提速都是通過軟件的優化來實現的，而不是通過硬體的加速。盡管單線程渲染 JavaScript 的速度有所提升，但是大多數網絡程序還是盡可能采用多線程來提升 JavaScript 整體性能。
誤傳3：移動設備瀏覽器已經優化的相當好了，沒有多少提升的空間了
事實上：每一個移動設備瀏覽器都有自己的優勢，有時甚至會超過對手 10-40 倍。Surface 在 SVG 方面比 iPhone 好 30 倍。iPhone 在 DOM 交互方面勝過 Surface10 倍。看來，和對手優點比較后還是有明顯提升空間的。
誤傳4: 未來的硬件提升不太可能轉變為 web app 的性能增益
現實：過去三年中每一代硬件都帶來了顯著的 JavaScript 性能提升。手機上的單線程性能將會持續改進，瀏覽器開發人員也將會提升軟件平臺，通過減輕負載與多線程，充分利用增強的 GPU 速度，更快的內存總線 與多核。許多瀏覽器已經能利用并行的優勢，以減輕主 UI 線程的負載，例如：Firefox 分離合成工作; Chrome 分離一些 HTML 解析; 以及 IE 分離 JavaScript JIT 編譯。
誤傳 5: JavaScript 垃圾搜集對移動 app 是一個性能殺手
現實:這是真實的但有點過時。在 2011 年，Chrome 已經自 Chrome 17 開始具有一個增量的垃圾搜集器。Firefox 是去年開始具有的 。這縮減了 GC 停頓約 200ms 到 10ms —— 或者說從一個掉幀到一個明顯的停頓。避免垃圾回收事件能對性能有顯著的改進，但如果你主要使用的是桌面 web 開發模式或者用的是老的瀏覽器，它通常會成為一個殺手。在 Fastbook（傳享網），我們的移動 HTML5 版的 非死book 克隆網站中，一個核心的技術就是循環利用一批 DOM 節點，以避免創建新節點的開支（以及對老節點 GC 回收的相關開支）。非常有可能寫出一個糟糕的垃圾搜集器（參看老的 Internet Explorers），但是并沒有本質上限制垃圾搜集的語言，像 JavaScript (或 Java)。
總結一下：
首先，讓咱看看一些基本常識。總而言之，瀏覽器是個運行在 OS 上有著非常復雜抽象層的程序。是用 HTML，JavaScript 和 CSS 創造抽象層的混合體。不同的抽象層會有不同的效果。有些抽象層運行的很快是因為它潛在調用 OS 調用或是用接近系統庫的庫(在 MacOS 上又稱 Canvas2D)。有些抽象層很慢因為他們很少用 OS 調用，而且他們本身太復雜(DOM 樹，或是原型鏈)。
有關 Sencha，我們知道，優秀的程序員創造的程序會很快，甚至出乎我們意料之外，因為他們都用一些移動網絡技術和一些流行的框架如 Sencha Touch。
很少有移動設備作為計算中心，就像沒人會在 iPhone 上計算 DNA 序列。大多數移動應用程序都會合理響應用戶操作。當用戶有所操作時，移動應用程序會以每秒 30 幀或者更快的速度來予以響應，大概用數百毫秒來完成。只要程序達到用戶的目標，不是說用更多的硅片就能達到的。這就像是我們突然轉移話題說我們烹飪和飲 食。
有關 Sencha，我們知道，優秀的程序員創造的程序會很快，甚至出乎我們意料之外，因為他們都用一些移動網絡技術和一些流行的框架如 Sencha Touch。在過去的 3 年間我們以此而受到鼓舞。我們喜歡在此分享這些數據。
我們的意思不是說移動網絡應用程序 總比本地程序快，或是總和桌面網絡應用程序做比較。這是不切實際的，移 動設備的硬件要比桌面硬件設備慢5-10 倍：CPU 更弱，緩存等級更低，網絡鏈接延遲更大。而且任何層次的程序(如瀏覽器)都有很大的消耗。這不是程序員的問題(我喜歡這一句，譯者注)。iOS 開發程序員會給你說 iOS CoreGrapics 在 Retina iPad 跑會很慢，因為他們都得直接用 OpenGL 進行開發。
深入探討誤傳
在多年為 Sencha Touch 的數據驅動的應用程序的性能優化工作中，我們可以滿懷信心地說，我們很少有人被 JavaScript 性能優化所困擾。唯一的重大案件迄今為止是 Sencha 觸摸布局系統，我們在發現界面切換到 Flexbox 后，JavaScript 在 Android 2. X 運行過于緩慢。更多的時候，我們碰到的問題是與 DOM 交互，瀏覽器渲染引擎和垃圾事件有關。所有這些問題都是每個瀏覽器的架構師和開發人員創建的，與 Javascript 或 Javascript 引擎的固有特性無關。作為一個例子，當我們與瀏覽器廠商在性能優化方面合作時，我們已經看到了在一個 40 倍的改善在瀏覽器一個操作（顏色屬性變化操作），這個操作是我們的滾動列表實現的速度瓶頸，這只是其中的一例。
JavaScript 在 IOS 和 android 上的性能
盡管我們說 JavaScript 在移動設備上的性能不是那么的重要，但是我們要反駁這段始終沒有得到改善的神話。以下是通過 IOS 的模型和版本展示出了歷史四年來 SunSpider 在 IOS 的數據得分（分數越低越好）。（幸運的是，SunSpider 是一個用的非常廣泛的測試工具，它記錄了所有的 IOS 版本的網絡數據）。在 2009 年， 最初運行 IOS3 的 IPhone 3GS 有得到一個已經超過了 15000 的分值——是如此低的性能，與 2009 年的桌面瀏覽器有 20 倍的差距。
然而，如果你把 Iphone 3GS 升級到了 IOS4,5 或者6，你將會在相同的硬件設備上提升 4 倍的 JavaScript 性能。（性能提高最大的是使用 Nitro 引擎的 IOS4 和 IOS5 之間）SunSpider 繼續在性能不斷提升的 SunSpider 上測試，但我們任低于那些 NDA。與當今的桌面瀏覽器相比，邊緣的移動瀏覽器的約慢 5 倍——與 2009 年相比卻有 30 倍的提升
想了解更多 ISO 軟硬件方面的改進，參見去年十月 AnandTech 的評論。
Android 平臺也有類似層次的改進。在我們的實驗室里，我們組建了一個過去的三年里 Android 平臺的集合，我們認為它們代表了典型的高端配置。我們測試了四部手機：
- Samsung Captivate Android 2.2 (2010 年 7 月發布)
- Droid Bionic Android 2.3.4 (2011 年 9 月發布)
- Samsung Galaxy Note 2 Android 4.1.2 (2012 年 9 月發布)
- Samsung Galaxy S4 Android 4.2.2 (2013 年 4 月發布) </ul>
- JavaScript 性能持續快速增長，勝似某國 GDP
- JavaScript 性能的提升是通過軟、硬件的同時優化
- 性能提升是件“大好事”，但是 Javascript 的 CPU 性能對很多移動 Web 應用的性能無能為力、可有可無。
- 好消息是其它影響移動 Web 應用的部分也得到了大幅提升，包括 DOM 的操作速度、Canvas 和 SVG. </ul>
- 移動平臺的速度不及電腦的1/5 — 較慢的 CPU，還有內存和圖形處理方面的限制。這些都是無法改變的事實。
- 移動端的 JavaScript+DOM 的存儲速度逐步加快，但是你始終對待 iPhone5 就像 08 年的 1.0 版本的谷歌瀏覽器一樣 (即比電腦平臺的 IE8 快5-10 倍)。
- 隨著 GPU 的加速和軟件的優化，圖形處理方面也得到了飛速的發展。已經能夠實現 30 幀每秒的動畫。
- 垃圾回收機制和平臺渲染的問題仍然困擾著你，基本上是用一個抽象的框架像 Sencha Touch 來達到最佳性能。
- 利用遠程調試和性能監控可以看出移動網絡平臺： 谷歌瀏覽器對安卓提供了一個幀數計數的支持，而且這個邊界會告訴你什么時候計數器溢出，還有移交 GPU 和計算結構被加載的次數等功能。 </ul>
正如你在下面看到的，這是一張過去的四年里 SunSpider 得分曲線，一個戲劇性的改善。從 Android 2.x 到 Android 4.x 性能有 3 倍的改善。
在這兩種情況下，改進都比我們依據摩爾定律預測的好得多。在過去的 3 年里，我們期待一個 4 倍的提升（2 倍每 18 個月），所以軟件肯定是導致性能的改善的要因。
測試關鍵因素
正如我們前面所提到的，SunSpider 已成為一個不那么吸引人的基準因為它與應用程序的性能的聯系微弱。相反，DOM 交互基準以及 Canvas 和 SVG 基準可以在用戶體驗方面告訴我們更多。（理想情況下，我們還會像開到 CSS 動畫幀頻一樣看到 CSS 屬性的變化，過渡和轉換-因為這是經常在 Web 應用中使用的-但現在仍沒有在手機上方便測量這些量的方法。）
首先試一下 DOM 交互測試：我們使用 Dromaeo Core DOM 作為基準測試。下面是我們四部手機的測試結果，我們對 Captivate 性能索引所有的核心 DOM（屬性，修改，查詢，遍歷），然后取 4 個核心 DOM 指數的平均值。
可以看出，盡管 S4 在 Note2 上只有一點小的提升，但是從 Android 2.x 到 4.x 性能卻得到了 3.5 倍的提升。 我們可以看看在 iOS 上的 Dromaeo 結果，遺憾的是，我們不能去和老版本的 IOS 去比較性能，但是我們能夠通過幾代 Iphone 硬件看到顯著的提升，有趣的是，這些設備在性能的改善卻優于 CPU 速度的加速，這就意味著在內存帶寬或者緩存上的提升會優于摩爾定律性能提升。
為了展現在瀏覽器之間仍然有很大的潛能去匹配相互間的性能，我們和 Surface RT 進行了比較。在 IE 上具有低性能交互的 DOM 一直是性能得不到改善的來源，但是值得指出的是 Iphone 跟 DOM 進行交互與運行 IE10 的 Microsoft Surface RT 存在的巨大的性能差距。我們想摧毀的神話之一就是手機軟件堆棧是完美的。Windows RT - 10 倍的性能差距，這不是真的需要等著被填充（我們將以后面的 IOS 為基準）。
圖像渲染能力
除過加快 JavaScript 和 DOM 響應外，我們也關心瀏覽器在 Canvas 和 SVG 方面的處理能力。同樣的硬件，我們發現 iOS5 在 Canvas2D 的處理能力要比 iOS4 高5-8 倍，在升級的 ios5 中甚至比 iPad2 快 80 倍。因為 Canvas 是通過 CoreGraphics 來渲染的，所以當本地程序渲染速度提高后，Canvas 也會提高。在我們的測試中，我們用 mincast Canvas2D 來做例子。下面我們看一下在不同代 iPhone 用同一個 iOS 測量的數據：
記住，這是 iOS4 到 iOS5 一個很大的性能提升。我們可以看出，在同一時期，iPhone CPU 性能提升了 4 倍，但 Canvas2D 渲染能力提升了 7 倍，這都歸功于 GPU 加速和 GPU 軟件的發展。
同樣的測試，我們再來看看 Android，我們來看一組在缺少 CPU 加速和 Canvas 之間有意思的數據。一個大的變化是 Android 2 沒有 GPU 加速。同時我們可以看出純軟件的 GPU 加速是改善性能的主要原因。
SVG 基準測試
SVG（譯著：可縮放矢量圖形）能夠從另外一個方面來體現 web 性能這一神話。盡管 SVG 并不如 Canvas 那樣被眾所周知（很有可能是應為 Canvas 已經變得很快了吧），但是 SVG 也可以反映出性能隨著硬件的改進而改善。如下是 Stephen Bannasch 在不同機器上做的一個繪制 10000 段 SVG 路徑所花費的時間的測試。 試結果再次表明硬件持續穩定的提高改善了 CPU 和 GPU 性能（因為這些都是在 ios6 上進行測試的）。
這種性能之間的差別主要來自于軟件：Surface RT 比 iphone 5(或者說 Ipad 4-我們同樣測試了 ipad 4 但測試數據并沒在上面的到體現)要快 30 倍。實際上，Surface RT 的性能比起在我用了一年的蘋果電腦的桌面瀏覽器 Safari 6 要好 10 倍。Windows 8/IE10 已經完全由 GPU 來加載 SVG,這對結果產生了巨大的影響。隨著瀏覽器制造商逐步的將由 GPU 來加載 SVG，我們有理由期待在 IOS 和 Android 上同樣看到 web 性能出現階躍函數的變化。
除了長路徑繪制，我們還運行了來自 Cameron Adams 的另一項 SVG 測試，500 個彈跳小球的每秒幀數。再一次的，我們看到了跨越最近四代硬件的持續的性能提升。
比性能提升更有趣的是每秒幀數 fps 的絕對值。一旦動畫超越了每秒 30 幀，你就越過了模擬電影的每秒幀數(24fps)，可以獲得視覺性能的期望值。到達 60fps 時，你的 GPU 加速質量就到達了黃油曲線部分。
真實的性能：垃圾回收機制、動態語言及其它
我們希望通過前文關于移動 Web 應用性能的鋪陳來說明一些（性能）問題，以及揭示幾個“神話”。詳述如下：
盡管咱們可以借助高速攝像頭來觀察（這些性能變化），但所有移動 Web 開發者都清楚的了解，自 Android 2.1 以降，動畫、過場切換以及屬性的修改等性能都得到了極大的提升，而且在此后的每次升版中，均有超越前作的表現。
至此我們已經糾正了一些錯誤的觀點，現在我們匯集到一起并真正的駁斥一下。最近一次我們聽到周圍有人斷言，移動 web app 將總是很慢，因為 JavaScript 這種動態語言的垃圾回收會傷及性能。這其中有一定的實情。使用類似 Sencha Touch 之類的框架， 將 DOM 內容動態生成的一個好處，就是我們可以管理對象的創建與析構，就像在某個層面，在一個瀏覽器上的特定的 UI 組件上下文之內，我們管理事件一樣。例如，這使得我們可以能夠通過回收 DOM 內容，調節事件和優化行動等等，提供 60fps 的性能體驗給那些以數據為中心的無窮內容（網格、列表、旋轉木馬）。
如果沒有這種程度的迂回方法，將會很容易制造出很差的移動 web app 性能體驗——就像 非死book 的第一代移動 web app。我們覺得寫在 UI 框架基礎之上的應用，如 jQuery Mobile，與潛在的 DOM 聯系的過于緊密，在可預見的未來將會持續承受性能問題。
整體歸納
文中提到了大量的信息和不同的觀點，在這里為大家總結一下。如果您是一位開發者，希望從中獲得一些啟發：
我們希望在查看性能數據的時候始終能夠找到一些除此之外的有用誤傳。我要感謝在 Sencha 的每一個人促就了這部誤傳，包括審查和發起大量連接到瀏覽器做性能優化的 Ariya Hidayat 和在 Sencha Touch 上作出詳細關于抽象和性能優化的 Nguyen
Michael Mullany著
Michael Mullany 是 Sencha 的 CEO。他在非常有影響力的硅谷公司 Netscape, Loudcloud 和 VMware 擔當過各種產品總監和市場總監的角色。他拿到了斯坦福大學工商管理碩士學位和哈佛大學經濟學學士學位。