這篇文章由Sencha的CEO Michael Mullany所寫，主要是回應早前的一篇引起較多關于移動Web性能討論的文章“Why mobile web apps are slow”，作者的主要觀點是“Why mobile web apps are slow”文中給出的數據雖然基本正確，但是對數據的解讀卻存在誤導的成分，并且只考量了JavaScript的性能，而對移動應用來說更關鍵的 Graphics性能并沒有被考量在內。并且移動應用性能的提升不僅僅會得益于瀏覽器提升JavaScript的性能，還會得益于更高程度的GPU加速渲 染，多線程并行化處理等等。

譯文

我們最近聽到了一些在不斷重復的關于移動HTML性能的神話，但是這并不完全準確。就像那些流傳已久的都市傳說一樣，它們聽起來似乎有理有據，讓人 信服。但是這些神話是基于不正確的前提，對于原生應用和Web應用的軟件堆棧之間的關系的概念是錯誤的，只是一些因為曲解了數據而推導出的漫無目的的觀 點。

神話#1：移動Web性能主要是由CPU主導的JavaScript性能所決定的

真相：大部分Web性能是由瀏覽器對渲染流水線的優化，DOM操作的速度和使用GPU加速的程度來決定的。更快的JavaScript性能的確不錯，但它很少會成為性能的瓶頸。

神話#2：依賴CPU的JavaScript性能僅僅因為硬件的提升才變得更快（aka 摩爾定律）

真相：在過去4年里面50%以上的JavsScript性能的提升是得益于軟件上的優化，而不是硬件上的提升。甚至單線程的JavaScript性能還在不斷提升，更不用說現在很多應用開發者通過使用Web Workers來利用多線程提升性能。

神話 #3：移動瀏覽器最近的性能優化已經基本停滯，未來也沒有更多上升的空間

真相：每一個移動瀏覽器都在一些特定的領域比起其它瀏覽器在性能上有10倍-40倍的提高。Surface的SVG性能比iPhone高30倍。而 iPhone的DOM操作性能是Surface的10倍。所以對每個瀏覽器來說，僅僅做到向其它瀏覽器表現優秀的領域看齊，就有很多性能提升的空間。

神話 #4：移動應用很難再從未來的硬件性能提升中受益

真相：在過去三年里，每一次硬件更新換代都會帶來JavaScript性能的飛躍。不但瀏覽器的單線程性能仍然在不斷提升，并且還會因為更快的 GPU速度，更快的內存帶寬，和通過多線程并行化處理更充分地利用多核CPU來不斷提升性能。越來越多的瀏覽器已經開始更多地利用并行化來減輕主線程的負 擔，比如說：Firefox使用了單獨的混合線程；Chrome并行化處理HTML解析；還有IE把JavaScript的JIT編譯放到了其它線程。

神話 #5：JavaScript的垃圾收集對移動應用來說是性能殺手

真相：這種說法曾經是正確的，不過現在的狀況已經不太一樣。Chrome在2011年的Chrome 17引入了增量垃圾收集機制。Firefox去年也實現了同樣的特性。這個特性將每次GC暫停的時間從200ms降到了10ms —— 相當于丟掉一幀 vs 一個可以明顯感知的停頓。避免垃圾收集事件的確可以顯著提升性能，但是只有你還在使用桌面Web開發模式或者在一個老舊的瀏覽器上運行，垃圾收集才會成為 性能殺手。以我們在Fastbook（一個Facebook HTML5應用的克?。┦褂玫年P鍵技術為例，通過建立一個DOM節點的對象池來回收不再使用的DOM對象并循環使用，我們成功避免了創建新對象的開銷，同 時也避免了因為刪除舊對象而導致GC。瀏覽器的確很有可能提供了一個性能非常糟糕的垃圾收集器（比如說舊的IE），但這并不是支持垃圾收集的語言比如 JavaScript（或者Java）的天生的無法克服的缺陷。

OK：關鍵要素

首先，讓我們回顧一下最基本的概念。從5萬英尺的高度往下看，瀏覽器本身是構建于操作系統之上的一個豐富和復雜的抽象層。而Web應用混合運用標記 語言，JavaScript腳本語言和樣式表，使用這個抽象層來創建應用的體驗。這個抽象層本身需要額外的性能開銷，而開銷的多少很大程度決定于你使用抽 象層的哪一部分。抽象層的某些部分更快是因為它們離操作系統的系統調用或者某些系統庫的調用更近（比如說Canvas2D on MacOS）。另外一些部分會比較慢是因為它們無法直接映射到底層的操作系統，并且它們天生就十分復雜（DOM樹操作，JavaScript對象屬性訪問 的原型鏈遍歷）。

很少有移動應用是計算密集型的：沒有誰會試圖在iPhone上計算DNA序列。大多數應用有著一個合理的響應模型。用戶執行一個操作，然后應用會馬 上回應一個30fps或者更高幀率的視覺動畫，然后在幾百毫秒之內完成任務。只要應用滿足上面的要求，沒有人會在乎應用基于的抽象層距離最底層的硅晶圓之 間到底有多遠。從這點來說，單純地比較原生應用的抽象層和Web應用的抽象層意義并不大。

對于Sencha來說，我們知道一個優秀的開發者使用移動Web技術和基于一個現代的Web框架比如Sencha Touch，是可以創建出優秀的應用體驗的，它運行的足夠快，滿足用戶的期待。并且過去3年的移動性能飛速提升的趨勢也使我們深受鼓舞。我們很樂意跟您在 接下來的文章里分享一些相關的數據。

但是我們的本意并不是說移動Web應用能夠運行的和原生應用一樣快，或者它們能夠在性能上能夠與桌面Web應用相媲美。這不是真實的。移動設備的硬 件性能比起桌面設備要慢5倍到10倍：CPU性能比較低，緩存層次結構過于扁平，缺少多級緩存的支持，網絡鏈接的延遲也很高。并且任何軟件抽象層本身（比 如瀏覽器）都需要付出額外的開銷。其實這不僅僅是Web應用開發者的問題。iOS原生應用的開發者一樣可以告訴你，當iOS CoreGraphics在第一款視網膜iPad上性能很低的時候，這使得他們相當一部分人不得不拋棄CoreGraphics而直接使用OpenGL。

進一步追溯神話的真相

通過過去三年持續對Sencha Touch在數據驅動應用中的使用進行性能優化的經歷，我們可以很自信的說，我們很少會被最原始的JavaScript性能所困擾。僅僅是在構建 Sencha Touch布局系統時，因為Android 2.x的JavaScript性能太差，使得我們改用了Flexbox。

更多時候，我們碰到的問題是DOM操作太慢，瀏覽器渲染引擎性能比較差和垃圾事件堆積過多無法及時處理。而這些局限基本上都是因為瀏覽器的架構設計 者和開發者造成的，跟JavaScript語言和JavaScript引擎本身并沒有本質的聯系。舉個例子來說，有一次我們和瀏覽器開發者一起優化瀏覽器 性能，我們最終在某個特定操作上（顏色屬性的改變）獲得了40倍的性能提高，而這之前是我們的滾動列表實現的性能瓶頸，而類似的例子還有很多。

在iOS和Android上的JavaScript性能

雖然我們說過JavaScript性能其實對于移動設備來說并不是那么重要，但是我們還是希望可以推翻它并沒有得到改善的神話。下圖是 SunSpider測試（越低越好）在iOS上過去4年的得分（按照硬件版本和OS版本劃分）。（很幸運，SunSpider是一個廣泛被應用的測試，所 以我們很容易就在網上找到舊的iOS設備的測試成績）。2009年的時候，當時運行iOS3的iPhone 3GS得分是15,000 —— 非常的糟糕，跟當時的桌面瀏覽器的300-600的得分相差30倍左右。

然而，如果你把iPhone 3GS升級到iOS 4，5和6，你就可以在同樣的硬件上面體驗到4倍的性能提升。（在iOS4到iOS5之間性能的巨大的飛躍主要得益于新的Nitro引擎。）實際上 SunSpider成績在iOS7上仍然會有所提高，只是基于保密協議我們這里就不再多說了。跟今天的桌面瀏覽器相比，最先進的移動瀏覽器大概還有5倍左 右的性能差距 —— 比起09年的30倍已經是相當大的改進。

如果需要了解更多關于iOS硬件和軟件性能改進的信息，可以參考Anandtech去年10月份的評測。

在Android平臺上也差不多有相當等級的改進。從我們的測試實驗室，我們找到了一些可以認為是過去3年里面在當時比較有代表性的高性能機器。我們測試了下面4款手機：

• 三星Captivate Android 2.2（2010年7月發布）
• Droid Bionic Android 2.3.4（2011年9月發布）
• 三星Galaxy Note 2 Android 4.1.2（2012年9月發布）
• 三星Galaxy S4 Android 4.2.2（2013年4月發布）

如下圖所示，SunSpider的成績在過去4年的提升非常明顯。從Android 2.x到Android4.x就帶來了接近3倍的提升。

無論是iOS還是Android，這些性能提升都不僅僅是由于摩爾定律本身帶來的。過去3年，如果按照摩爾定律，我們期望獲得的性能提升大概是4倍左右（18個月提升一倍），但實際上卻遠遠不止，所以軟件上的優化的確起了相當大的作用。

更多有意義的測試

如之前我們已經提過的，SunSpider的測試成績其實越來越不重要，因為它跟應用本身的性能要求關系其實并不大。相反，DOM操作的測試，還有 Canvas和SVG的測試成績對應用的用戶體驗關系更密切。（理想狀態下，我們應該還要去測量改變CSS屬性的速度，還有CSS動畫，過渡動畫和幾何變 換動畫的幀率 —— 因為它們在Web應用中使用的更頻繁 —— 不過由于缺少瀏覽器的支持，仍然無法準確地獲取這些測試數據）

第一個DOM操作測試：我們使用了Dromaeo Core DOM測試。下圖是之前的4臺Android設備上得到的測試成績，我們把Captivates上的4項Core DOM測試成績（Attributes，Modifications，Query，Traversal）作為1分，其它設備的測試成績就是相對于 Captivates的得分，然后取4項得分的平均值作為最終結果。

如你所見，Android從2.x到4.x帶來了3.5倍的性能提升，雖然S4比起Note2的提升幅度比較小。我們在iOS設備上也進行了 Dromaeo測試。不幸的是，由于iOS無法降級，我們沒法得到老的iOS版本的測試成績，不過我們仍然可以看到隨著硬件的升級，Dromaeo測試性 能一樣是穩步上升。并且有趣的是，不同的iOS6設備之間的Dromaeo性能提升幅度要大于它們的CPU速度提升幅度，這說明了內存帶寬或者緩存的速度 提升肯定帶來了更大的幫助，所以才能比單純依靠摩爾定律所能獲得的結果更好。

為了顯示瀏覽器還有多少潛在的性能提升空間（僅僅是為了趕上其它瀏覽器表現優異的領域），我們還測試了Surface RT。IE槽糕的DOM操作性能一直困擾著我們，但這說明了Surface RT上的IE10在DOM操作上還有很大的改善空間。這也是我們之前打破的一個神話 —— “移動設備的軟件堆棧本身已經足夠好，未來沒有太多的優化空間”。起碼對于Windows RT來說，在DOM操作上還有10倍的差距需要去填補。（我們后面還會展現在哪些測試上，iOS表現不佳）

圖形性能

除了展現JavaScript和DOM操作性能的巨大提升外，我們還想為您展現瀏覽器在Canvas和SVG上的性能提升。我們之前就發現了 Canvas2D性能在同樣硬件上iOS5比iOS4提升了5-8倍。甚至當iPad 2升級到iOS5后，一些局部測試提升了80倍。并且因為Canvas實際上是對iPhone上的CoreGraphics API的直接調用，所以當原生圖形性能獲得提升時，Canvas性能也獲得了同樣的提升。在下面的測試中，我們使用了mindcat Canvas2D benchmark來測試性能。這里，我們看到了隨著iPhone硬件的提升（都運行iOS6），Canvas性能也在不斷提升。

請牢記，上圖的顯示的數據已經計入了iOS4到iOS5的性能飛躍。如你所見，上圖顯示出歷代iPhone在Canvas2D上的性能提升達到了7 倍之多，遠比它們的CPU速度提升幅度要大（按照摩爾定律CPU最多也就提升了4倍），這也反映了iPhone的軟件堆棧充分利用了CPU/GPU來提升 自身的性能。移動Web性能的提升實際上有很大一部分是受益于GPU性能的提升和瀏覽器更多使用GPU進行圖形加速。

我們再來看看在Android上運行同樣的測試，我們看到一些有趣的數據顯示Android上Canvas性能跟CPU性能之間并沒有必然的聯系。 從Android 2.x到Android 4.x上的性能飛躍主要是因為2.x的Canvas完全沒有使用GPU加速。這再次說明了，僅僅是瀏覽器充分利用GPU加速就能夠帶來巨大的性能提升。

SVG測試

SVG是另外一個可以展現Web性能的廣闊的領域。雖然不如Canvas流行（很大程度是因為Canvas已經足夠快），SVG的性能隨著硬件提升 仍然在穩步提升。下圖是來自Stephen Bannasch的一個測試，測試了繪制10,000線段構成的一個SVG路徑所需的時間。再一次，測試結果顯示了各代iPhone CPU/GPU性能提升帶來的穩定的SVG性能提升（所有的iPhone都運行iOS6）。

但是最大的差距還是源于軟件本身：Surface RT比iPhone 5快了30倍（對比iPad4也是如此，雖然這里我們沒有列出來）。實際上，Surface RT比起運行在我一年前買的Macbook上的Safari仍然快了10倍！這個差距是是否使用了GPU加速造成的，Window 8/IE10在SVG上充分利用了GPU進行加速，才獲得了如此驚人的成果。只要瀏覽器開發者把更多原來由CPU完成的工作轉移到GPU上面去，我們就有 可能在iOS和Android上也看到同樣的性能提升。

除了上面的長路徑繪制外，我們還運行了另外一個來自Cameron Adams的SVG測試，測試了500個不斷反彈的小球的動畫幀率。再一次，我們可以看到由硬件提升所帶來的SVG性能的穩步提升。

比起單純的性能數據，最終的fps值更讓人感興趣。一旦動畫超過了30幀，你就可以得到一個跟電影動畫（24fps）相似的結果，這樣的流暢度已經基本上可以讓觀看者滿意。如果能夠達到60幀，那你就會獲得由GPU加速帶來的極致流暢的體驗。

真實世界的性能：垃圾收集，動態語言和更多

我們希望之前的移動性能探索之旅已經說明了一些事情，也打破了一些神話。我們希望為您展現下列真相：

• JavaScript的性能持續地快速提升
• 性能的提升由硬件提升和軟件優化同時驅動
• 雖然高性能的JavaScript是一件好事，但實際上大部分Web應用的性能跟JavaScript性能的關系甚少
• 幸運的是，其它影響Web應用性能的領域，像DOM操作，Canvas，SVG的性能也在飛速提升

雖然我們可以展現一些高速攝影機下的動畫測試，不過實際上所有移動Web應用的開發者都清楚，CSS動畫，過渡動畫和屬性修改的性能從Android 2.1開始已經得到極大的提高，并且它們還在不斷提高。

之前我們已經澄清了一些不真實的論斷，現在再讓我們做一個最終的說明。我們不斷聽到的各種傳言匯總而成的最終結論是“移動Web應用總是很慢，這是 因為JavaScript是一種低性能的動態語言，并且垃圾收集機制對性能是一個極大的傷害”。應該說這個結論本身并不是完全錯誤的。不過如果你的Web 應用使用類似Sencha Touch這樣的框架來動態產生DOM內容，一個很大的優勢在于，我們會在瀏覽器之上，在特定的應用上下文下，合理地去管理對象的創建和銷毀，包括事件對 象。這樣即使你的應用需要展現無窮盡的數據內容（通過表格，列表或者轉盤），我們通過回收DOM對象，過濾多余的事件，對要執行的動作進行優先級排序等優 化，可以幫助您的應用獲得60fps的視覺動畫體驗。

如果沒有一個中間層進行類似的間接處理，的確很容易得到非常糟糕的移動Web應用體驗 —— 就像Facebook移動Web應用的第一個版本一樣。我們相信如果應用直接使用類似jQuery Mobile這樣直接操作底層DOM模型的UI框架時，在可見的未來的確會持續受到性能相關問題的困擾。

匯總

文中包含了大量的數據和覆蓋了不同的主題，最后在這里讓我們再總結一下。如果您是一位開發者，您應該可以從這篇文章了解到：

• 移動平臺的速度不及桌面平臺的1/5 — 較慢的CPU，還有受限的內存大小和速度和較慢的GPU等等。這些都是無法改變的事實。
• 移動平臺的JavaScript + DOM的訪問速度越來越快，但是你始終應該把iPhone 5看作跟2008年在桌面電腦上運行的Chrome 1.0一樣 (即比桌面版的IE8快5-10倍)。
• 移動Web應用的圖形性能隨著瀏覽器更多使用GPU進行圖形加速和其它通用軟件優化，已經基本可以實現30幀每秒的動畫。
• 垃圾收集和平臺渲染性能有限的問題仍然會使你困擾，所以使用一個類似Sencha Touch這樣的抽象框架來獲得更佳性能是十分有必要的。
• 充分利用移動Web平臺提供的遠程調試器和性能監控能力：像Chrome for Android現在已經提供了一個不錯的fps計數器，還可以顯示需要混合的圖層邊界，這可以告訴你哪些網頁內容實際上已經生成了貼圖并由GPU負責繪制，還有貼圖被加載的次數。

我們希望對這些性能數據的回顧能夠幫助我們打破一些虛假的神話。我需要感謝在Sencha的所有人對這篇文章的貢獻，包括Ariya Hidayat 的審閱和提供了大量關于瀏覽器性能優化的文章鏈接，還有 Jacky Nguyen關于Sencha Touch的抽象層如何進行性能優化的一些實現細節。

翻譯后記

喔，終于翻譯完了，以前還沒有翻譯過這么長的文章，沒想到還真是一件累死人的事情。每一句話都需要斟字酌句細細體會字面下的意思，再用較為通順的中文表述出來，無論是腦力還是體力都是相當大的摧殘，說多了都是淚啊 =_=

應該說要翻譯這篇文章，甚至要讀懂這篇文章，譯者和讀者都需要對瀏覽器內核的一些工作原理有所了解。

• 比如文中多處強調JavaScript RAW performance和DOM Interaction的區別，這是因為雖然DOM Interaction雖然也是由JS去調用，但是對瀏覽器來說，實際上JS只是調用瀏覽器內核提供的JS Binding API，整個Interaction是由瀏覽器本身去執行的，所以不應該當作JavaScript本身的性能來考量。
• 又如瀏覽器所構建的抽象層的不同部分直接或者間接映射到OS的系統調用或者系統庫調用對性能的不同影響的說法要怎么理解？舉個例子來說，Web應 用開發者可以用DOM+CSS或者用Canvas實現同樣的動畫效果，下面分別是基于QuarkJS實現的兩個同樣的動畫，一個基于DOM，一個基于 Canvas，對于Canvas繪制直接使用OS本身的2D繪圖庫去實現，并且支持GPU加速的瀏覽器來說，Canvas動畫的效率會比使用DOM要高的 多，這是因為基于DOM和CSS的動畫，瀏覽器通常需要進行重新計算樣式，重新排版，重新光柵化，重新上傳貼圖，重新混合等這樣一個復雜的流程，效率自然 高不起來。再舉一個例子，對于支持圖層混合加速（Accelerated Compositing）和硬件加速的瀏覽器來說，對付CSS Transform這樣的動畫就是小菜一碟，因為對它來說這個動畫就是不斷改變元素所屬圖層的Transform屬性，然后使用GPU重新混合的過程。而 支持硬件加速的瀏覽器所謂的圖層混合其實就是通過OpenGL進行貼圖的這樣一個過程。

最后要說的是，文中的一些觀點還是需要在一定的條件下才能成立的，并不是放之四海而皆準，這是讀者需要留意的地方：

• 大部分Web應用性能跟JavaScript性能關系不大，對它的要求不高

是的，大部分是這樣的，但不見得你的Web應用就是這大部分之一。實際上，對于有一定復雜程度的基于Canvas的Web Game來說，JavaScript性能很有可能成為它的性能瓶頸。這些Web Game的場景通常比較復雜，包含成百甚至上千的繪圖對象（比如實現一個絢麗的粒子效果），需要在JavaScript里面構建一個成百上千個節點的 Scene Graph。每繪制一幀，都意味著需要對這個Scene Graph進行遍歷，訪問每一個節點，更新它的狀態，然后再調用Canvas API將它繪制出來。如果要達到30fps的速度，這意味著最多只有30ms左右的時間來完成每一幀（實際上應該沒有那么多），即使不算Canvas API本身的繪制開銷，單單是遍歷和狀態更新的操作就很有可能達到幾十毫秒的量級了，特別是狀態更新中包含大量的碰撞檢測和物理運動計算的時候。

• 通過并行化處理是未來瀏覽器有效提升性能的一個有效手段

應該說，當前通過并行化處理充分利用多核CPU/GPU提升性能是瀏覽器內核技術研究發展的一個熱點。但是并行化并不是銀彈，指望它能夠短期內戲劇性地大幅度提升瀏覽器的整體性能并不現實。

1. 首先對于移動設備來說，iOS還好，但是Android由于自身的開放性，硬件水平參差不齊，低端硬件還有相當大的保有量，它們缺乏足夠的資源去 支持并行化，并行化對它們來說反而更糟糕。不過得益于像MTK這樣的芯片廠商大力提升中低端設備的性能，現在的千元機性能已經跟幾年前不可同日而言，大概 再過多一兩年這個問題應該就不再成為問題了。
2. 其次并行化處理并不是想象中的那么容易，因為瀏覽器的大部分作業實際上都有某種程度的順序依賴和上下文依賴，需要很多額外的處理才有可能實現部分 并行化（畢竟不是數據處理，要做到完全并行化可能性極低）。這樣的并行化需要額外的開銷，并且只適應于部分場景，有一定的局限性。目前瀏覽器除了網絡鏈接 的部分，并行化程度最高的應該就是渲染了，除了圖層混合會運行在獨立線程并且主要使用GPU外，像Chrome，Android Browser都把光柵化從主線程剝出來，渲染性能的確從并行化中獲益極大，不過也付出了額外的CPU/內存開銷的代價。其它領域的并行化進展還是很慢， 并且也難見有可能使得性能大幅度提升，比如Chrome在做的HTML解析和樣式計算的并行化，最多也就能夠減少網頁從開始加載到第一次完整呈現的時間， 對于整體性能提升意義不大。至于JavaScript，除了IE所實現的JIT并行化外，垃圾收集也是一個有可能剝離出主線程的領域，只是我個人對 JavaScript引擎了解不多，不知道具體的技術難點在哪里。
3. 最后還需要前端開發者有意識地去使用并行化，或者為了更好地支持瀏覽器的并發作業對自己的應用進行專門優化，比如說Web Workers可以讓部分JavaScript代碼運行在獨立的線程，但在實際的網頁里面使用的應該很少。

最后的話

作為讀者，如果您能夠一直看到這里，說明您應該對Web App/Game開發是有著真愛的^_^ ，所以不妨再看完這最后一節。從我個人的開發經驗來看，一個經過充分優化的應用比起沒有經過優化的應用通常會有非常明顯的性能差別，如果您的Web App/Game對性能要求很高，并且主要運行在移動平臺，那么性能優化對您來說那就更加重要了（移動平臺可沒有那么多可以揮霍性能的空間）。而為了幫助 前端開發者更好地做好性能優化，Chrome提供了可稱為逆天的神器Dev Tools，學會使用這套工具（推薦Code School上面的視頻教程），然后使用它來對您的應用進行性能分析和優化，您會發現這才是真正能夠獲得戲劇性的性能飛躍的最大可能，這也是所謂的“求諸 人不如求諸己”。

原文鏈接：http://www.sencha.com/blog/5-myths-about-mobile-web-performance