這些秘籍是基于，不正確的前提和對本地和網絡軟件棧之間關系的誤解，以及曲解數據的散點。 我們認為重要的是，要對這些秘籍進行驗證，使用用我們已經收集了多年來關于性能的數據和我們自己的做的移動 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版的Facebook克隆網站中，一個核心的技術就是循環利用一批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月發布)

正如你在下面看到的，這是一張過去的四年里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應用性能的鋪陳來說明一些（性能）問題，以及揭示幾個“神話”。詳述如下：

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

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

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

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

整體歸納

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

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

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

Michael Mullany著

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