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

譯文

我們最近聽到了一些在不斷重復(fù)的關(guān)于移動(dòng)HTML性能的神話，但是這并不完全準(zhǔn)確。就像那些流傳已久的都市傳說(shuō)一樣，它們聽起來(lái)似乎有理有據(jù)，讓人 信服。但是這些神話是基于不正確的前提，對(duì)于原生應(yīng)用和Web應(yīng)用的軟件堆棧之間的關(guān)系的概念是錯(cuò)誤的，只是一些因?yàn)榍饬藬?shù)據(jù)而推導(dǎo)出的漫無(wú)目的的觀 點(diǎn)。

神話#1：移動(dòng)Web性能主要是由CPU主導(dǎo)的JavaScript性能所決定的

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

神話#2：依賴CPU的JavaScript性能僅僅因?yàn)橛布奶嵘抛兊酶欤╝ka 摩爾定律）

真相：在過(guò)去4年里面50%以上的JavsScript性能的提升是得益于軟件上的優(yōu)化，而不是硬件上的提升。甚至單線程的JavaScript性能還在不斷提升，更不用說(shuō)現(xiàn)在很多應(yīng)用開發(fā)者通過(guò)使用Web Workers來(lái)利用多線程提升性能。

神話 #3：移動(dòng)瀏覽器最近的性能優(yōu)化已經(jīng)基本停滯，未來(lái)也沒(méi)有更多上升的空間

真相：每一個(gè)移動(dòng)瀏覽器都在一些特定的領(lǐng)域比起其它瀏覽器在性能上有10倍-40倍的提高。Surface的SVG性能比iPhone高30倍。而 iPhone的DOM操作性能是Surface的10倍。所以對(duì)每個(gè)瀏覽器來(lái)說(shuō)，僅僅做到向其它瀏覽器表現(xiàn)優(yōu)秀的領(lǐng)域看齊，就有很多性能提升的空間。

神話 #4：移動(dòng)應(yīng)用很難再?gòu)奈磥?lái)的硬件性能提升中受益

真相：在過(guò)去三年里，每一次硬件更新?lián)Q代都會(huì)帶來(lái)JavaScript性能的飛躍。不但瀏覽器的單線程性能仍然在不斷提升，并且還會(huì)因?yàn)楦斓?GPU速度，更快的內(nèi)存帶寬，和通過(guò)多線程并行化處理更充分地利用多核CPU來(lái)不斷提升性能。越來(lái)越多的瀏覽器已經(jīng)開始更多地利用并行化來(lái)減輕主線程的負(fù) 擔(dān)，比如說(shuō)：Firefox使用了單獨(dú)的混合線程；Chrome并行化處理HTML解析；還有IE把JavaScript的JIT編譯放到了其它線程。

神話 #5：JavaScript的垃圾收集對(duì)移動(dòng)應(yīng)用來(lái)說(shuō)是性能殺手

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

OK：關(guān)鍵要素

首先，讓我們回顧一下最基本的概念。從5萬(wàn)英尺的高度往下看，瀏覽器本身是構(gòu)建于操作系統(tǒng)之上的一個(gè)豐富和復(fù)雜的抽象層。而Web應(yīng)用混合運(yùn)用標(biāo)記 語(yǔ)言，JavaScript腳本語(yǔ)言和樣式表，使用這個(gè)抽象層來(lái)創(chuàng)建應(yīng)用的體驗(yàn)。這個(gè)抽象層本身需要額外的性能開銷，而開銷的多少很大程度決定于你使用抽 象層的哪一部分。抽象層的某些部分更快是因?yàn)樗鼈冸x操作系統(tǒng)的系統(tǒng)調(diào)用或者某些系統(tǒng)庫(kù)的調(diào)用更近（比如說(shuō)Canvas2D on MacOS）。另外一些部分會(huì)比較慢是因?yàn)樗鼈儫o(wú)法直接映射到底層的操作系統(tǒng)，并且它們天生就十分復(fù)雜（DOM樹操作，JavaScript對(duì)象屬性訪問(wèn) 的原型鏈遍歷）。

很少有移動(dòng)應(yīng)用是計(jì)算密集型的：沒(méi)有誰(shuí)會(huì)試圖在iPhone上計(jì)算DNA序列。大多數(shù)應(yīng)用有著一個(gè)合理的響應(yīng)模型。用戶執(zhí)行一個(gè)操作，然后應(yīng)用會(huì)馬 上回應(yīng)一個(gè)30fps或者更高幀率的視覺(jué)動(dòng)畫，然后在幾百毫秒之內(nèi)完成任務(wù)。只要應(yīng)用滿足上面的要求，沒(méi)有人會(huì)在乎應(yīng)用基于的抽象層距離最底層的硅晶圓之 間到底有多遠(yuǎn)。從這點(diǎn)來(lái)說(shuō)，單純地比較原生應(yīng)用的抽象層和Web應(yīng)用的抽象層意義并不大。

對(duì)于Sencha來(lái)說(shuō)，我們知道一個(gè)優(yōu)秀的開發(fā)者使用移動(dòng)Web技術(shù)和基于一個(gè)現(xiàn)代的Web框架比如Sencha Touch，是可以創(chuàng)建出優(yōu)秀的應(yīng)用體驗(yàn)的，它運(yùn)行的足夠快，滿足用戶的期待。并且過(guò)去3年的移動(dòng)性能飛速提升的趨勢(shì)也使我們深受鼓舞。我們很樂(lè)意跟您在 接下來(lái)的文章里分享一些相關(guān)的數(shù)據(jù)。

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

進(jìn)一步追溯神話的真相

通過(guò)過(guò)去三年持續(xù)對(duì)Sencha Touch在數(shù)據(jù)驅(qū)動(dòng)應(yīng)用中的使用進(jìn)行性能優(yōu)化的經(jīng)歷，我們可以很自信的說(shuō)，我們很少會(huì)被最原始的JavaScript性能所困擾。僅僅是在構(gòu)建 Sencha Touch布局系統(tǒng)時(shí)，因?yàn)锳ndroid 2.x的JavaScript性能太差，使得我們改用了Flexbox。

更多時(shí)候，我們碰到的問(wèn)題是DOM操作太慢，瀏覽器渲染引擎性能比較差和垃圾事件堆積過(guò)多無(wú)法及時(shí)處理。而這些局限基本上都是因?yàn)闉g覽器的架構(gòu)設(shè)計(jì) 者和開發(fā)者造成的，跟JavaScript語(yǔ)言和JavaScript引擎本身并沒(méi)有本質(zhì)的聯(lián)系。舉個(gè)例子來(lái)說(shuō)，有一次我們和瀏覽器開發(fā)者一起優(yōu)化瀏覽器 性能，我們最終在某個(gè)特定操作上（顏色屬性的改變）獲得了40倍的性能提高，而這之前是我們的滾動(dòng)列表實(shí)現(xiàn)的性能瓶頸，而類似的例子還有很多。

在iOS和Android上的JavaScript性能

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

#p#

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

如果需要了解更多關(guān)于iOS硬件和軟件性能改進(jìn)的信息，可以參考Anandtech去年10月份的評(píng)測(cè)。

在Android平臺(tái)上也差不多有相當(dāng)?shù)燃?jí)的改進(jìn)。從我們的測(cè)試實(shí)驗(yàn)室，我們找到了一些可以認(rèn)為是過(guò)去3年里面在當(dāng)時(shí)比較有代表性的高性能機(jī)器。我們測(cè)試了下面4款手機(jī)：

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

如下圖所示，SunSpider的成績(jī)?cè)谶^(guò)去4年的提升非常明顯。從Android 2.x到Android4.x就帶來(lái)了接近3倍的提升。

無(wú)論是iOS還是Android，這些性能提升都不僅僅是由于摩爾定律本身帶來(lái)的。過(guò)去3年，如果按照摩爾定律，我們期望獲得的性能提升大概是4倍左右（18個(gè)月提升一倍），但實(shí)際上卻遠(yuǎn)遠(yuǎn)不止，所以軟件上的優(yōu)化的確起了相當(dāng)大的作用。

更多有意義的測(cè)試

如之前我們已經(jīng)提過(guò)的，SunSpider的測(cè)試成績(jī)其實(shí)越來(lái)越不重要，因?yàn)樗鷳?yīng)用本身的性能要求關(guān)系其實(shí)并不大。相反，DOM操作的測(cè)試，還有 Canvas和SVG的測(cè)試成績(jī)對(duì)應(yīng)用的用戶體驗(yàn)關(guān)系更密切。（理想狀態(tài)下，我們應(yīng)該還要去測(cè)量改變CSS屬性的速度，還有CSS動(dòng)畫，過(guò)渡動(dòng)畫和幾何變 換動(dòng)畫的幀率 —— 因?yàn)樗鼈冊(cè)赪eb應(yīng)用中使用的更頻繁 —— 不過(guò)由于缺少瀏覽器的支持，仍然無(wú)法準(zhǔn)確地獲取這些測(cè)試數(shù)據(jù)）

第一個(gè)DOM操作測(cè)試：我們使用了Dromaeo Core DOM測(cè)試。下圖是之前的4臺(tái)Android設(shè)備上得到的測(cè)試成績(jī)，我們把Captivates上的4項(xiàng)Core DOM測(cè)試成績(jī)（Attributes，Modifications，Query，Traversal）作為1分，其它設(shè)備的測(cè)試成績(jī)就是相對(duì)于 Captivates的得分，然后取4項(xiàng)得分的平均值作為最終結(jié)果。

如你所見，Android從2.x到4.x帶來(lái)了3.5倍的性能提升，雖然S4比起Note2的提升幅度比較小。我們?cè)趇OS設(shè)備上也進(jìn)行了 Dromaeo測(cè)試。不幸的是，由于iOS無(wú)法降級(jí)，我們沒(méi)法得到老的iOS版本的測(cè)試成績(jī)，不過(guò)我們?nèi)匀豢梢钥吹诫S著硬件的升級(jí)，Dromaeo測(cè)試性 能一樣是穩(wěn)步上升。并且有趣的是，不同的iOS6設(shè)備之間的Dromaeo性能提升幅度要大于它們的CPU速度提升幅度，這說(shuō)明了內(nèi)存帶寬或者緩存的速度 提升肯定帶來(lái)了更大的幫助，所以才能比單純依靠摩爾定律所能獲得的結(jié)果更好。

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

#p#

圖形性能

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

http://cdn.sencha.io/img/20130730-5-myths-html5/5-html5-myths-5.png

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

http://cdn.sencha.io/img/20130730-5-myths-html5/5-html5-myths-6.png

我們?cè)賮?lái)看看在Android上運(yùn)行同樣的測(cè)試，我們看到一些有趣的數(shù)據(jù)顯示Android上Canvas性能跟CPU性能之間并沒(méi)有必然的聯(lián)系。 從Android 2.x到Android 4.x上的性能飛躍主要是因?yàn)?.x的Canvas完全沒(méi)有使用GPU加速。這再次說(shuō)明了，僅僅是瀏覽器充分利用GPU加速就能夠帶來(lái)巨大的性能提升。

SVG測(cè)試

SVG是另外一個(gè)可以展現(xiàn)Web性能的廣闊的領(lǐng)域。雖然不如Canvas流行（很大程度是因?yàn)镃anvas已經(jīng)足夠快），SVG的性能隨著硬件提升 仍然在穩(wěn)步提升。下圖是來(lái)自Stephen Bannasch的一個(gè)測(cè)試，測(cè)試了繪制10,000線段構(gòu)成的一個(gè)SVG路徑所需的時(shí)間。再一次，測(cè)試結(jié)果顯示了各代iPhone CPU/GPU性能提升帶來(lái)的穩(wěn)定的SVG性能提升（所有的iPhone都運(yùn)行iOS6）。

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

除了上面的長(zhǎng)路徑繪制外，我們還運(yùn)行了另外一個(gè)來(lái)自Cameron Adams的SVG測(cè)試，測(cè)試了500個(gè)不斷反彈的小球的動(dòng)畫幀率。再一次，我們可以看到由硬件提升所帶來(lái)的SVG性能的穩(wěn)步提升。

比起單純的性能數(shù)據(jù)，最終的fps值更讓人感興趣。一旦動(dòng)畫超過(guò)了30幀，你就可以得到一個(gè)跟電影動(dòng)畫（24fps）相似的結(jié)果，這樣的流暢度已經(jīng)基本上可以讓觀看者滿意。如果能夠達(dá)到60幀，那你就會(huì)獲得由GPU加速帶來(lái)的極致流暢的體驗(yàn)。

#p#

真實(shí)世界的性能：垃圾收集，動(dòng)態(tài)語(yǔ)言和更多

我們希望之前的移動(dòng)性能探索之旅已經(jīng)說(shuō)明了一些事情，也打破了一些神話。我們希望為您展現(xiàn)下列真相：

• JavaScript的性能持續(xù)地快速提升
• 性能的提升由硬件提升和軟件優(yōu)化同時(shí)驅(qū)動(dòng)
• 雖然高性能的JavaScript是一件好事，但實(shí)際上大部分Web應(yīng)用的性能跟JavaScript性能的關(guān)系甚少
• 幸運(yùn)的是，其它影響Web應(yīng)用性能的領(lǐng)域，像DOM操作，Canvas，SVG的性能也在飛速提升

雖然我們可以展現(xiàn)一些高速攝影機(jī)下的動(dòng)畫測(cè)試，不過(guò)實(shí)際上所有移動(dòng)Web應(yīng)用的開發(fā)者都清楚，CSS動(dòng)畫，過(guò)渡動(dòng)畫和屬性修改的性能從Android 2.1開始已經(jīng)得到極大的提高，并且它們還在不斷提高。

之前我們已經(jīng)澄清了一些不真實(shí)的論斷，現(xiàn)在再讓我們做一個(gè)最終的說(shuō)明。我們不斷聽到的各種傳言匯總而成的最終結(jié)論是“移動(dòng)Web應(yīng)用總是很慢，這是 因?yàn)镴avaScript是一種低性能的動(dòng)態(tài)語(yǔ)言，并且垃圾收集機(jī)制對(duì)性能是一個(gè)極大的傷害”。應(yīng)該說(shuō)這個(gè)結(jié)論本身并不是完全錯(cuò)誤的。不過(guò)如果你的Web 應(yīng)用使用類似Sencha Touch這樣的框架來(lái)動(dòng)態(tài)產(chǎn)生DOM內(nèi)容，一個(gè)很大的優(yōu)勢(shì)在于，我們會(huì)在瀏覽器之上，在特定的應(yīng)用上下文下，合理地去管理對(duì)象的創(chuàng)建和銷毀，包括事件對(duì) 象。這樣即使你的應(yīng)用需要展現(xiàn)無(wú)窮盡的數(shù)據(jù)內(nèi)容（通過(guò)表格，列表或者轉(zhuǎn)盤），我們通過(guò)回收DOM對(duì)象，過(guò)濾多余的事件，對(duì)要執(zhí)行的動(dòng)作進(jìn)行優(yōu)先級(jí)排序等優(yōu) 化，可以幫助您的應(yīng)用獲得60fps的視覺(jué)動(dòng)畫體驗(yàn)。

如果沒(méi)有一個(gè)中間層進(jìn)行類似的間接處理，的確很容易得到非常糟糕的移動(dòng)Web應(yīng)用體驗(yàn) —— 就像Facebook移動(dòng)Web應(yīng)用的第一個(gè)版本一樣。我們相信如果應(yīng)用直接使用類似jQuery Mobile這樣直接操作底層DOM模型的UI框架時(shí)，在可見的未來(lái)的確會(huì)持續(xù)受到性能相關(guān)問(wèn)題的困擾。

匯總

文中包含了大量的數(shù)據(jù)和覆蓋了不同的主題，最后在這里讓我們?cè)倏偨Y(jié)一下。如果您是一位開發(fā)者，您應(yīng)該可以從這篇文章了解到：

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

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

翻譯后記

喔，終于翻譯完了，以前還沒(méi)有翻譯過(guò)這么長(zhǎng)的文章，沒(méi)想到還真是一件累死人的事情。每一句話都需要斟字酌句細(xì)細(xì)體會(huì)字面下的意思，再用較為通順的中文表述出來(lái)，無(wú)論是腦力還是體力都是相當(dāng)大的摧殘，說(shuō)多了都是淚啊 =_=

應(yīng)該說(shuō)要翻譯這篇文章，甚至要讀懂這篇文章，譯者和讀者都需要對(duì)瀏覽器內(nèi)核的一些工作原理有所了解。

• 比如文中多處強(qiáng)調(diào)JavaScript RAW performance和DOM Interaction的區(qū)別，這是因?yàn)殡m然DOM Interaction雖然也是由JS去調(diào)用，但是對(duì)瀏覽器來(lái)說(shuō)，實(shí)際上JS只是調(diào)用瀏覽器內(nèi)核提供的JS Binding API，整個(gè)Interaction是由瀏覽器本身去執(zhí)行的，所以不應(yīng)該當(dāng)作JavaScript本身的性能來(lái)考量。
• 又如瀏覽器所構(gòu)建的抽象層的不同部分直接或者間接映射到OS的系統(tǒng)調(diào)用或者系統(tǒng)庫(kù)調(diào)用對(duì)性能的不同影響的說(shuō)法要怎么理解？舉個(gè)例子來(lái)說(shuō)，Web應(yīng) 用開發(fā)者可以用DOM+CSS或者用Canvas實(shí)現(xiàn)同樣的動(dòng)畫效果，下面分別是基于QuarkJS實(shí)現(xiàn)的兩個(gè)同樣的動(dòng)畫，一個(gè)基于DOM，一個(gè)基于 Canvas，對(duì)于Canvas繪制直接使用OS本身的2D繪圖庫(kù)去實(shí)現(xiàn)，并且支持GPU加速的瀏覽器來(lái)說(shuō)，Canvas動(dòng)畫的效率會(huì)比使用DOM要高的 多，這是因?yàn)榛贒OM和CSS的動(dòng)畫，瀏覽器通常需要進(jìn)行重新計(jì)算樣式，重新排版，重新光柵化，重新上傳貼圖，重新混合等這樣一個(gè)復(fù)雜的流程，效率自然 高不起來(lái)。再舉一個(gè)例子，對(duì)于支持圖層混合加速（Accelerated Compositing）和硬件加速的瀏覽器來(lái)說(shuō)，對(duì)付CSS Transform這樣的動(dòng)畫就是小菜一碟，因?yàn)閷?duì)它來(lái)說(shuō)這個(gè)動(dòng)畫就是不斷改變?cè)厮鶎賵D層的Transform屬性，然后使用GPU重新混合的過(guò)程。而 支持硬件加速的瀏覽器所謂的圖層混合其實(shí)就是通過(guò)OpenGL進(jìn)行貼圖的這樣一個(gè)過(guò)程。

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

• 大部分Web應(yīng)用性能跟JavaScript性能關(guān)系不大，對(duì)它的要求不高

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

• 通過(guò)并行化處理是未來(lái)瀏覽器有效提升性能的一個(gè)有效手段

應(yīng)該說(shuō)，當(dāng)前通過(guò)并行化處理充分利用多核CPU/GPU提升性能是瀏覽器內(nèi)核技術(shù)研究發(fā)展的一個(gè)熱點(diǎn)。但是并行化并不是銀彈，指望它能夠短期內(nèi)戲劇性地大幅度提升瀏覽器的整體性能并不現(xiàn)實(shí)。

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

最后的話

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

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