這些秘籍是基于，不正確的前提和對本地和網(wǎng)絡(luò)軟件棧之間關(guān)系的誤解，以及曲解數(shù)據(jù)的散點。 我們認為重要的是，要對這些秘籍進行驗證，使用用我們已經(jīng)收集了多年來關(guān)于性能的數(shù)據(jù)和我們自己的做的移動 Web 應(yīng)用程序性能的經(jīng)驗。

秘籍1：移動網(wǎng)絡(luò)性能主要是由運行在CPU上的JavaScript性能決定

現(xiàn)實：大多數(shù)網(wǎng)絡(luò)性能是由渲染管線的優(yōu)化程度，GPU加速程度，DOM交互速度三者制約。更快的JavaScript總是有用的，但它很少是決定因素。

秘籍2：因為硬件不停的升級，CPU越快，JavaScirpt執(zhí)行的也會越快(又稱摩爾定律)

事實上：在過去四年間，移動設(shè)備上的JavaScript的渲染提速都是通過軟件的優(yōu)化來實現(xiàn)的，而不是通過硬體的加速。盡管單線程渲染JavaScript的速度有所提升，但是大多數(shù)網(wǎng)絡(luò)程序還是盡可能采用多線程來提升JavaScript整體性能。

秘籍3：移動設(shè)備瀏覽器已經(jīng)優(yōu)化的相當(dāng)好了，沒有多少提升的空間了

事實上：每一個移動設(shè)備瀏覽器都有自己的優(yōu)勢，有時甚至?xí)^對手10-40倍。Surface在SVG方面比iPhone好30倍。iPhone在DOM交互方面勝過Surface10倍。看來，和對手優(yōu)點比較后還是有明顯提升空間的。

秘籍4: 未來的硬件提升不太可能轉(zhuǎn)變?yōu)閣eb app的性能增益

現(xiàn)實：過去三年中每一代硬件都帶來了顯著的JavaScript性能提升。手機上的單線程性能將會持續(xù)改進，瀏覽器開發(fā)人員也將會提升軟件平臺，通過減輕負載與多線程，充分利用增強的GPU速度，更快的內(nèi)存總線 與多核。許多瀏覽器已經(jīng)能利用并行的優(yōu)勢，以減輕主UI線程的負載，例如：Firefox 分離合成工作; Chrome 分離一些 HTML 解析; 以及 IE 分離 JavaScript JIT編譯。

秘籍 5: JavaScript 垃圾搜集對移動app是一個性能殺手

現(xiàn)實:這是真實的但有點過時。在2011年，Chrome已經(jīng)自Chrome 17開始具有一個增量的垃圾搜集器。Firefox是去年開始具有的 。這縮減了GC停頓約200ms到10ms —— 或者說從一個掉幀 到一個明顯的停頓。避免垃圾回收事件能對性能有顯著的改進，但如果你主要使用的是桌面web開發(fā)模式或者用的是老的瀏覽器，它通常會成為一個殺手。在Fastbook（傳享網(wǎng)），我們的移動HTML5版的Facebook克隆網(wǎng)站中，一個核心的技術(shù)就是循環(huán)利用一批DOM節(jié)點，以避免創(chuàng)建新節(jié)點的開支（以及對老節(jié)點GC回收的相關(guān)開支）。非常有可能寫出一個糟糕的垃圾搜集器（參看老的Internet Explorers），但是并沒有本質(zhì)上限制垃圾搜集的語言，像JavaScript (或 Java)。

總結(jié)一下：

首先，讓咱看看一些基本常識。總而言之，瀏覽器是個運行在OS上有著非常復(fù)雜抽象層的程序。是用HTML，JavaScript和CSS創(chuàng)造抽象層的混合體。不同的抽象層會有不同的效果。有些抽象層運行的很快是因為它潛在調(diào)用OS調(diào)用或是用接近系統(tǒng)庫的庫(在MacOS上又稱Canvas2D)。有些抽象層很慢因為他們很少用OS調(diào)用，而且他們本身太復(fù)雜(DOM樹，或是原型鏈)。

有關(guān)Sencha，我們知道，優(yōu)秀的程序員創(chuàng)造的程序會很快，甚至出乎我們意料之外，因為他們都用一些移動網(wǎng)絡(luò)技術(shù)和一些流行的框架如Sencha Touch。

很少有移動設(shè)備作為計算中心，就像沒人會在iPhone上計算DNA序列。大多數(shù)移動應(yīng)用程序都會合理響應(yīng)用戶操作。當(dāng)用戶有所操作時，移動應(yīng)用程序會以每秒30幀或者更快的速度來予以響應(yīng)，大概用數(shù)百毫秒來完成。只要程序達到用戶的目標，不是說用更多的硅片就能達到的。這就像是我們突然轉(zhuǎn)移話題說我們烹飪和飲食。

有關(guān)Sencha，我們知道，優(yōu)秀的程序員創(chuàng)造的程序會很快，甚至出乎我們意料之外，因為他們都用一些移動網(wǎng)絡(luò)技術(shù)和一些流行的框架如Sencha Touch。在過去的3年間我們以此而受到鼓舞。我們喜歡在此分享這些數(shù)據(jù)。

我們的意思不是說移動網(wǎng)絡(luò)應(yīng)用程序 總比本地程序快，或是總和桌面網(wǎng)絡(luò)應(yīng)用程序做比較。這是不切實際的，移動設(shè)備的硬件要比桌面硬件設(shè)備慢5-10倍：CPU更弱，緩存等級更低，網(wǎng)絡(luò)鏈接延遲更大。而且任何層次的程序(如瀏覽器)都有很大的消耗。這不是程序員的問題(我喜歡這一句，譯者注)。iOS開發(fā)程序員會給你說iOS CoreGrapics在Retina iPad跑會很慢，因為他們都得直接用OpenGL進行開發(fā)。

深入探討秘籍

在多年為Sencha Touch的數(shù)據(jù)驅(qū)動的應(yīng)用程序的性能優(yōu)化工作中，我們可以滿懷信心地說，我們很少有人被JavaScript性能優(yōu)化所困擾。唯一的重大案件迄今為止是Sencha觸摸布局系統(tǒng),我們在發(fā)現(xiàn)界面切換到Flexbox后，JavaScript在Android 2. X運行過于緩慢。更多的時候，我們碰到的問題是與DOM交互，瀏覽器渲染引擎和垃圾事件有關(guān)。所有這些問題都是每個瀏覽器的架構(gòu)師和開發(fā)人員創(chuàng)建的，與 Javascript或Javascript引擎的固有特性無關(guān)。作為一個例子，當(dāng)我們與瀏覽器廠商在性能優(yōu)化方面合作時，我們已經(jīng)看到了在一個40倍的改善在瀏覽器一個操作（顏色屬性變化操作），這個操作是我們的滾動列表實現(xiàn)的速度瓶頸，這只是其中的一例。

JavaScript 在IOS和android上的性能

盡管我們說JavaScript在移動設(shè)備上的性能不是那么的重要，但是我們要反駁這段始終沒有得到改善的神話。以下是通過IOS的模型和版本展示出了歷史四年來SunSpider在IOS的數(shù)據(jù)得分（分數(shù)越低越好）。（幸運的是，SunSpider是一個用的非常廣泛的測試工具，它記錄了所有的IOS版本的網(wǎng)絡(luò)數(shù)據(jù)）。在2009年， 最初運行IOS3的IPhone 3GS有得到一個已經(jīng)超過了15000的分值——是如此低的性能，與2009年的桌面瀏覽器有20倍的差距。

然而，如果你把Iphone 3GS升級到了IOS4,5或者6，你將會在相同的硬件設(shè)備上提升4倍的JavaScript性能。（性能提高***的是使用Nitro引擎的IOS4 和IOS5之間）SunSpider繼續(xù)在性能不斷提升的SunSpider上測試，但我們?nèi)蔚陀谀切㎞DA。與當(dāng)今的桌面瀏覽器相比，邊緣的移動瀏覽器的約慢5倍——與2009年相比卻有30倍的提升

想了解更多ISO軟硬件方面的改進，參見去年十月AnandTech的評論。

Android平臺也有類似層次的改進。在我們的實驗室里，我們組建了一個過去的三年里Android平臺的集合，我們認為它們代表了典型的高端配置。我們測試了四部手機：

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

正如你在下面看到的，這是一張過去的四年里SunSpider得分曲線，一個戲劇性的改善。從Android 2.x到Android 4.x性能有3倍的改善。

在這兩種情況下，改進都比我們依據(jù)摩爾定律預(yù)測的好得多。在過去的3年里，我們期待一個4倍的提升（2倍每18個月），所以軟件肯定是導(dǎo)致性能的改善的要因。

測試關(guān)鍵因素

正如我們前面所提到的，SunSpider已成為一個不那么吸引人的基準因為它與應(yīng)用程序的性能的聯(lián)系微弱。相反，DOM交互基準以及Canvas和SVG基準可以在用戶體驗方面告訴我們更多。（理想情況下，我們還會像開到CSS動畫幀頻一樣看到CSS屬性的變化，過渡和轉(zhuǎn)換-因為這是經(jīng)常在Web應(yīng)用中使用的-但現(xiàn)在仍沒有在手機上方便測量這些量的方法。）

首先試一下DOM交互測試：我們使用Dromaeo Core DOM作為基準測試。下面是我們四部手機的測試結(jié)果，我們對Captivate性能索引所有的核心DOM（屬性，修改，查詢，遍歷），然后取4個核心DOM指數(shù)的平均值。

可以看出，盡管S4在Note2上只有一點小的提升,但是從Android 2.x 到4.x性能卻得到了3.5倍的提升。 我們可以看看在iOS上的Dromaeo結(jié)果，遺憾的是，我們不能去和老版本的IOS去比較性能，但是我們能夠通過幾代Iphone硬件看到顯著的提升，有趣的是，這些設(shè)備在性能的改善卻優(yōu)于CPU速度的加速，這就意味著在內(nèi)存帶寬或者緩存上的提升會優(yōu)于摩爾定律性能提升。

為了展現(xiàn)在瀏覽器之間仍然有很大的潛能去匹配相互間的性能，我們和Surface RT進行了比較。在IE上具有低性能交互的DOM一直是性能得不到改善的來源，但是值得指出的是Iphone跟DOM進行交互與運行IE10的Microsoft Surface RT存在的巨大的性能差距。我們想摧毀的神話之一就是手機軟件堆棧是***的。Windows RT - 10倍的性能差距，這不是真的需要等著被填充（我們將以后面的IOS為基準）。

圖像渲染能力

除過加快JavaScript和DOM響應(yīng)外，我們也關(guān)心瀏覽器在Canvas和SVG方面的處理能力。同樣的硬件，我們發(fā)現(xiàn)iOS5在Canvas2D的處理能力要比iOS4高5-8倍，在升級的ios5中甚至比iPad2快80倍。因為Canvas是通過CoreGraphics來渲染的，所以當(dāng)本地程序渲染速度提高后，Canvas也會提高。在我們的測試中，我們用mincast Canvas2D來做例子。下面我們看一下在不同代iPhone用同一個iOS測量的數(shù)據(jù)：

記住，這是iOS4到iOS5一個很大的性能提升。我們可以看出，在同一時期，iPhone CPU性能提升了4倍，但Canvas2D渲染能力提升了7倍，這都歸功于GPU加速和GPU軟件的發(fā)展。

同樣的測試，我們再來看看Android，我們來看一組在缺少CPU加速和Canvas之間有意思的數(shù)據(jù)。一個大的變化是Android 2沒有GPU加速。同時我們可以看出純軟件的GPU加速是改善性能的主要原因。

SVG 基準測試

SVG（譯著：可縮放矢量圖形）能夠從另外一個方面來體現(xiàn)web性能這一神話。盡管SVG并不如Canvas那樣被眾所周知（很有可能是應(yīng)為Canvas已經(jīng)變得很快了吧），但是SVG也可以反映出性能隨著硬件的改進而改善。如下是Stephen Bannasch在不同機器上做的一個繪制10000段SVG路徑所花費的時間的測試。 試結(jié)果再次表明硬件持續(xù)穩(wěn)定的提高改善了CPU和GPU性能（因為這些都是在ios6上進行測試的）。

這種性能之間的差別主要來自于軟件：Surface RT比iphone 5(或者說Ipad 4-我們同樣測試了ipad 4但測試數(shù)據(jù)并沒在上面的到體現(xiàn))要快30倍。實際上，Surface RT的性能比起在我用了一年的蘋果電腦的桌面瀏覽器Safari 6要好10倍。Windows 8/IE10 已經(jīng)完全由GPU來加載SVG,這對結(jié)果產(chǎn)生了巨大的影響。隨著瀏覽器制造商逐步的將由GPU來加載SVG，我們有理由期待在IOS和Android上同樣看到web性能出現(xiàn)階躍函數(shù)的變化。

除了長路徑繪制，我們還運行了來自Cameron Adams的另一項SVG測試，500個彈跳小球的每秒幀數(shù)。再一次的，我們看到了跨越最近四代硬件的持續(xù)的性能提升。

比性能提升更有趣的是每秒幀數(shù)fps的絕對值。一旦動畫超越了每秒30幀，你就越過了模擬電影的每秒幀數(shù)(24fps)，可以獲得視覺性能的期望值。到達60fps時，你的GPU加速質(zhì)量就到達了黃油曲線部分。

真實的性能：垃圾回收機制、動態(tài)語言及其它

我們希望通過前文關(guān)于移動Web應(yīng)用性能的鋪陳來說明一些（性能）問題，以及揭示幾個“神話”。詳述如下：

• JavaScript性能持續(xù)快速增長，勝似某國GDP
• JavaScript性能的提升是通過軟、硬件的同時優(yōu)化
• 性能提升是件“大好事”，但是Javascript 的CPU性能對很多移動Web應(yīng)用的性能無能為力、可有可無。
• 好消息是其它影響移動Web應(yīng)用的部分也得到了大幅提升，包括DOM的操作速度、Canvas和SVG.

盡管咱們可以借助高速攝像頭來觀察（這些性能變化），但所有移動Web開發(fā)者都清楚的了解，自Android 2.1以降，動畫、過場切換以及屬性的修改等性能都得到了極大的提升，而且在此后的每次升版中，均有超越前作的表現(xiàn)。

至此我們已經(jīng)糾正了一些錯誤的觀點，現(xiàn)在我們匯集到一起并真正的駁斥一下。最近一次我們聽到周圍有人斷言，移動web app將總是很慢，因為JavaScript這種動態(tài)語言的垃圾回收會傷及性能。這其中有一定的實情。使用類似Sencha Touch之類的框架， 將DOM內(nèi)容動態(tài)生成的一個好處，就是我們可以管理對象的創(chuàng)建與析構(gòu)，就像在某個層面，在一個瀏覽器上的特定的UI組件上下文之內(nèi)，我們管理事件一樣。例如，這使得我們可以能夠通過回收DOM內(nèi)容，調(diào)節(jié)事件和優(yōu)化行動等等，提供60fps 的性能體驗給那些以數(shù)據(jù)為中心的無窮內(nèi)容（網(wǎng)格、列表、旋轉(zhuǎn)木馬）。

如果沒有這種程度的迂回方法，將會很容易制造出很差的移動web app性能體驗——就像Facebook的***代移動web app。我們覺得寫在UI框架基礎(chǔ)之上的應(yīng)用，如jQuery Mobile，與潛在的DOM聯(lián)系的過于緊密，在可預(yù)見的未來將會持續(xù)承受性能問題。

整體歸納

文中提到了大量的信息和不同的觀點，在這里為大家總結(jié)一下。如果您是一位開發(fā)者，希望從中獲得一些啟發(fā)：

• 移動平臺的速度不及電腦的1/5 — 較慢的CPU，還有內(nèi)存和圖形處理方面的限制。這些都是無法改變的事實。
• 移動端的JavaScript+DOM的存儲速度逐步加快，但是你始終對待iPhone5就像08年的1.0版本的谷歌瀏覽器一樣 (即比電腦平臺的IE8快5-10倍)。
• 隨著GPU的加速和軟件的優(yōu)化，圖形處理方面也得到了飛速的發(fā)展。已經(jīng)能夠?qū)崿F(xiàn)30幀每秒的動畫。
• 垃圾回收機制和平臺渲染的問題仍然困擾著你，基本上是用一個抽象的框架像Sencha Touch來達到***性能。
• 利用遠程調(diào)試和性能監(jiān)控可以看出移動網(wǎng)絡(luò)平臺： 谷歌瀏覽器對安卓提供了一個幀數(shù)計數(shù)的支持，而且這個邊界會告訴你什么時候計數(shù)器溢出，還有移交GPU和計算結(jié)構(gòu)被加載的次數(shù)等功能。

我們希望在查看性能數(shù)據(jù)的時候始終能夠找到一些除此之外的有用秘籍。我要感謝在Sencha的每一個人促就了這部秘籍，包括審查和發(fā)起大量連接到瀏覽器做性能優(yōu)化的Ariya Hidayat 和在Sencha Touch上作出詳細關(guān)于抽象和性能優(yōu)化的Nguyen

Michael Mullany著

Michael Mullany是Sencha的CEO。他在非常有影響力的硅谷公司Netscape, Loudcloud和 VMware擔(dān)當(dāng)過各種產(chǎn)品總監(jiān)和市場總監(jiān)的角色。他拿到了斯坦福大學(xué)工商管理碩士學(xué)位和哈佛大學(xué)經(jīng)濟學(xué)學(xué)士學(xué)位