我寫過不少文章來討論為什么移動Web應用程序很慢，這也引起了不少的討論。但是不幸的是，這些討論沒有像我喜歡的那樣的基于事實。

所以我這篇文章的目地就是給這些問題帶來一些真正的證據，而不是僅僅過來對罵。在這篇文章的中，你可以看到基準測試（benchmark），可以看到專家的觀點，你甚至可以看到非常誠實（honest-to-God）的期刊文章。這篇文章有超過100個引用（不是開玩笑）。我不保證這篇文章能使你信服，甚至不保證這篇文章中的所有內容都是正確的（在這樣大規模的文章中做到這一點幾乎是不可能的），但是我可以保證這是一篇關于許多iOS開發者都抱有的想法——移動Web應用很慢并且會在可預計的未來繼續如此——分析最完備和全面的文章。

現在我要警告你：這是一篇長得嚇人的文章，差不多10000字。當然，這是我故意的。我更喜歡好文章，而不是流行的文章。我嘗試使得這篇文章成為前者，同時宣揚我認同的風氣：我們應該鼓勵那些優秀的、基于證據的、有趣的討論，不鼓勵那些詼諧、嘩眾取寵的評論。

我寫這篇的文章，在某種程度上是因為這是話題已經到了一種爭論不休的地步。這不是另一篇爭論的文章，如果你想看到30秒左右的對罵：“真的！Web應用很渣！”和“誰說的？Web程序挺好！”，那么這篇文章不適合你。另一方面，據我所知，到現在為止還沒有一個關于這個話題全面的、正式的、理性的討論。這篇文章中我嘗試去理性地討論這個激起千層浪的話題，盡管這可能是一個非常愚蠢的想法。這里我給自己辯護一下，我相信這個問題與那些本來可以更好地去討論卻沒有這樣做的人更有關系，而不是主題本身。

如果你想知道你那些原生代碼（native code）程序員朋友為什么在如今開放的網絡革命時期還在寫著萬惡的原生代碼，那就把本頁面加入書簽吧，給自己倒杯咖啡，找出一個下午的時間，找到一個舒服的椅子，然后我們就正式開始吧！

簡單回顧

我上一篇博客中寫道：基于SunSpider的benchmark給出的數據可以看出當今的移動Web應用很慢。

如果你認為“Web應用程序”就是“一個網頁加上一兩個按鈕”，那么你就可以讓那些花哨的benchmark——比如SunSpider——滾一邊去。但是如果你認為“Web應用程序”是指“簡單的文字處理，簡單的照片編輯，本地存儲和屏幕之間的切換動畫”，那么除非你有想死的心，否則你永遠不會愿意在ARM上寫Web應用程序。

你應該先讀一下那篇文章，但是我還是在這邊給你看下benchmark：

關于這個benchmark，主要三種主要的批評：

1. JS比原生代碼要慢并不是什么新鮮事了，每個人在上第一學期的計算機基礎課時討論編譯型語言、JIT語言和解釋型語言是時候就知道了。問題是JS是不是慢到已經成為你現在所寫軟件的大問題了，但是像這樣的benchmark并不能說明這個問題。

2. JS是很慢，這也的確是個問題，但是它在變得越來越快，所以在不久的未來，我們可以發現它不會那么慢了。所以大家一起學JS吧。

3. 我是Python/PHP/Ruby的服務器端的開發者，我不知道你們在說什么。我知道我的服務器比你們的移動設備快，但是如果我可以自信地保證使用真正的解釋型語言寫出支持上千個用戶的代碼，你們難道不能用一個帶有高性能JIT的語言寫出一個支持單個用戶的代碼嗎？真的有那么難嗎？

我有一個相當高的目標，那就是反駁以上所有觀點：是的，JS的確是慢到一定程度了；不，它在不久的未來不會變得有多快；不，你在服務器端的編程經驗不能正確地映射到移動應用中。

但是真正的問題在于，在所有討論這個話題的文章里面，基本上沒有人真正量化JS到底有多慢，或者提供某種真正有用的比較標準（相對于什么來說慢）。為了糾正這樣的情況，我在這篇文章中提出了三種（不僅僅是一種）比較JavaScript性能的辦法。我不會說“JS在什么情況下都慢”，而是真正量化它慢的程度，并且將它跟我們再平常編程經驗中的事情做對比，這樣你就可以根據這個結果結合自己的編程平臺做出決定，你也可以自己計算下看看是否JavaScript適合你自己的特定問題。

OK，但是JS的性能相比于原生代碼到底如何？

這是一個好問題。為了回答這個問題，我從Benchmark Game中隨意抓取了一個基準測試。然后我找到了一個做同樣benchmark的較老的C程序（老到不像很多新程序有一些x86特性）。我在自己的iPhone 4S上分別測試Nitro和LLVM。所有的代碼已經傳到了Github。

這是一個隨機的測試，正如日常生活中運行的代碼一樣。如果你想要一個更好的實驗，可以自己運行。我運行這個實驗還有另外一個原因，就是因為其它的實驗都不存在LLVM和Nitro的對比。

在這個綜合的基準測試中，LLVM一致地比Nitro快4.5倍：

如果你在想“如果是計算密集型（CPU-bound）的功能，本地代碼比Nitro JS快多少呢”，那么答案是差不多5倍。這個結果大致上和Benchmark Game在x86/GCC/V8上面的結果一致，那里面的GCC/x86通常比V8/x86快2到9倍。所以結果大致上是正確的，無論是ARM還是x86。

但是1/5的性能對每個人來說還不夠好嗎？

在x86上是足夠好了。當渲染一個電子表格的時候，CPU的計算能有多密集呢？其實并不是那么難。問題是，ARM不是x86。

根據GeekBench的結果，最新的MacBook Pro的性能是最新的iPhone性能的10倍。這其實不算太大問題——電子表格沒那么復雜。我們可以忍受10%的性能。但是我還要把它除以5？好家伙！我們現在只有桌面性能的2%了。

OK，但是文字處理到底有多難？我們可不可以用一個m68k芯片加上一個協處理器來搞定呢？這是一個可以回答的問題。你可能記不起來，Google Doc的實時協作之前事實上還不是一個正式的功能，后來他們進行了大規模的重寫并且在2010年4月份加入到Google Doc里面。我們來看一下2010年瀏覽器的性能：

從圖中可以清晰地看到，iPhone 4S在Google Docs的實時協作方面完全不是桌面網頁瀏覽器的對手。當然了，它還是可以跟IE8比上一比的。恭喜iPhone 4S，可喜可賀。

我們再看看另外一個正經的JavaScript應用：Google Wave。Wave從來沒有支持IE8，因為它實在是太慢了。

看到這些瀏覽器比iPhone 4S快多少了嗎？

注意，所有支持的瀏覽器的得分都低于1000，其中那個得分3800的因為太慢了而被忽略了。iPhone得分為2400。差不多和IE8一樣，太慢幾乎無法運行。

這邊要說明的是，在移動設備上實現實時協作是可能的，只是不太可能用JavaScript來實現。原生代碼和Web應用的性能差距基本上和Firefox與IE8的性能差距差不多，這么大的差距足以影響正常的工作。

但是我感覺V8或者是現代JS已經有了接近C的性能了？

這取決于你怎么理解“接近”了。如果你的C程序運行了10ms，那么一個運行50ms的JavaScript程序差不多是接近C的速度了。如果你的C程序運行了10s，那么一個運行了50s的JavaScript程序對于大多數正常人來說很可能就不是接近C的速度了。

硬件角度

1/5的速度在x86上是沒問題的，畢竟x86起點就比ARM快10倍，你還有很多上升空間。解決方案顯然是讓ARM變成10倍快，這樣就可以跟x86競爭了，然后我們就可以不用做任何工作就可以得到桌面環境的JS性能了。

這個方法行不行得通取決于你是否相信摩爾定律，以及給每個芯片配置一個3盎司的電池是否可行。我不是一個硬件工程師，但是我曾經為一家大型半導體公司工作過，那里的人告訴我說當今硬件的性能基本上是制作工藝（process）起的作用。iPhone 5令人印象深刻的性能主要是因為其芯片工藝從45nm做到了32nm，減少了差不多1/3。但是如果想繼續這么做，蘋果就要達到22nm的工藝。

順便提一下，Intel22nm工藝的Atom處理器現在還沒上市。而且Intel不得不重新發明全新的半導體，畢竟原來的半導體在22nm級別已經不適用了。他們會把工藝授權給ARM？再好好想想吧。如今22nm的產品少之又少，而且大部分被Intel掌控著。

事實上，ARM似乎已經在著手在明年嘗試28nm了（看看A7），同時Intel正在嘗試22nm甚至在稍微晚些時候嘗試20nm。從純硬件的角度，我感覺具有x86級別性能的x86芯片很可能遠遠比具有x86性能的ARM芯片更早登錄智能手機市場。

看一個前Intel工程師給我發的郵件：

我是一個前Intel工程師，剛開始從事于移動微處理器的工作，后來工作轉向了Atom處理器。無論如何，我有一個很偏激的觀點，即x86從較大的核心轉向手機市場的難度遠比ARM從頭開始設計技術細節以達到x86的性能級別的難度要低很多。

再看一個機器人領域的工程師給我發的郵件：

你說得非常對，這些（譯注：指的是ARM的發展）不會帶來多大的性能提升，Intel可能在近幾年之內就會有更高性能的移動處理器。事實上，移動處理器當前和桌面處理器面臨著同樣的問題，即工作頻率達到3GHz左右的時候，再提高時鐘速度就不可避免地使得功耗大大增加。這種情況同樣會發生在下一代工藝上，盡管IPC（Instruction per Clock，即CPU每一時鐘周期內所執行的指令多少）會得到一些提高（差不多10%-20%）。在面臨這種限制的情況下，桌面處理器開始向雙核和四核方向變化，但是移動處理器現在已經是雙核和四核了，所以想提高性能不是那么容易。

摩爾定律無論怎么說都可能是正確的，但是這需要整個移動生態環境向x86環境轉變。這并非完全不可能，畢竟曾經有人做過這樣的事。但那是在移動處理器一年才賣出去100萬個的時候做的，不像現在，每個季度就可以賣出62萬個芯片。那個時候現成的虛擬化環境可以模擬出老架構的60%的速度，而按照現在的研究來看，虛擬化系統上運行優化過的（O3）ARM代碼的速度已經接近27%了。

如果你堅信JavaScript的性能最終會到達一個合理的水平，那么硬件性能的提升絕對是最好的方式。要么Intel會在5年之內開發出可行的iPhone芯片（這是有可能的），并且蘋果迅速轉向x86架構（這是不太可能的），或者ARM能夠在未來的10年之內得到性能的飛躍。但是在我看來，10年是一個很長的時間，長到足夠使某件事情可能成功。

恐怕我的硬件的知識只能分析到這里了。我可以告訴你的是，如果你相信ARM可以在未來的5年之內填補與x86之間的性能差距，那么第一步就是找到一個在ARM或者x86上工作的人（也就是真正懂硬件的人），讓他同意你的看法。我寫這篇文章之前，曾近咨詢過很多有很高資質的硬件工程師，他們所有人都拒絕公開發表這個觀點，這讓我感覺這個觀點不是很靠譜。

軟件角度

這是一個很多優秀軟件工程師犯錯誤的地方。他們的思路是這樣的：JavaScript已經變得更快了，并且它會變得更快。

這個觀點的前一部分是正確的，JavaScript的確變得快很多。但是我們現在已經達到了JavaScript性能的頂點了，它不可能變得更快多少。

為什么？其實前一部分JavaScript的性能提升從某種程度上是硬件的原因，正如Jeff Atwood寫道：

我感覺從1996到2006之間JavaScript的性能變快了100倍。如果Web 2.0主要建立在JavaScript上的話，這很可能主要是因為摩爾定律所帶來的硬件性能提升。

如果我們把JS的性能提升總結為硬件性能提升的話，那么JS的已有的硬件性能提升不能預測未來的軟件性能提升。這就是為什么如果你相信JS會變得更快的話，最有可能的方式就是硬件變得更快，因為歷史趨勢就是如此。

那么JIT如何呢？V8，Nitro/SFX，TraceMonkey/IonMonkey，Chakra等等？當然，當他們剛剛問世的時候，的確是很了不起的（但或許不像你認為的那么了不起）。V8在2008年9月發布，我找到了一份差不多那個時候同期的Firefox 3.0.3，看看它的性能：

不要誤解我的意思，9倍的性能提升的確值得稱贊，畢竟這差不多是ARM和x86之間的性能差距了。即便如此，Chrome 8和Chrome 26之間的性能卻呈現出了水平線，因為自從2008開始，幾乎沒有什么重大的事情發生。其他瀏覽器廠商都已經趕上來了，有些快有些慢，但是沒人真正提高過JavaScript的性能了。

JavaScript性能在提升嗎？

這是我Mac上的Chrome 8（可運行的最早版本，2010年12月份的版本）和Chrome 26。

看不出差別？因為根本沒有差別。JavaScript的性能最近根本沒有得到大的提升。

如果你感覺現在的瀏覽器比2010年的瀏覽器跑的快的話，那很可能是因為你有了一臺更快的電腦，但是這與Chrome的性能提升沒什么關系。

更新：有些聰明的人指出SunSpider現在不是一個好的benchmark（并且拒絕提供任何實際的數字或其它什么）。為了能夠可以理性地討論，我在一些舊版本的Chrome上面運行Octane（一個Google的benchmark），的確顯示出了一些性能提升：

在我看來，在這個期間的性能提升還是太小，不足以支撐JS馬上就會足夠快這樣的論調。然而，要說我過分強調這個情況也沒錯，畢竟JavaScript的計算密集型操作的確在發生變化。但是推我來說，這些數字可以得出更大的推斷：這些性能提升的幅度還不足以在一定時間之內使得JavaScript的速度趕上原生代碼。你需要性能達到2-9倍才能跟LLVM競爭。這些提升是好的，但還不足夠好。更新結束。

問題是，讓JavaScript采用JIT技術是一個60年前就有的想法，并且這60年來一直有人在研究。數以千計的你可能想到的編程語言對JIT的實現都證明這是一個好主意。但是既然我們已經做到了，我們已經用完了這個60年前的想法。伙計們，就是這樣的，表演結束了。或許我們可以在未來的60年之內想到另一個好辦法。

但是Safari恐怕比以前要快吧？

Safari 7 是不是比其它的瀏覽器快3.8倍？

這個結論或許對蘋果來說很容易得到，但是這個版本的Safari在NDA協議之下，所以沒有人能夠公開關于Safari性能的獨立參數。但是我可以僅僅根據現在已經得到的信息來做一些分析。

我發現一些現象很有意思。第一、蘋果官方在公開的JSBench上的數據要比在他們在較老的benchmark（如SunSpider）上給出的數據高出不少。現在JSBench背后有一些非常酷的名字，包括JavaScript之父Brenden Eich。但是和傳統的benchmark不一樣，JSBench的工作方式不會考慮整數和其它重要因素，它反而自動為Amazon、Facebook和Twitter提供的內容進行優化，而且根據它們提供的內容來建立benchmark。

如果你在寫一個多數人用來瀏覽Facebook的瀏覽器，我可以理解用一個只測試Facebook性能的benchmark是很有用的。但是從另外的角度講，如果你在寫一個電子表格的程序，或者游戲，或是一個圖片過濾應用，在我看來傳統的benchmark（注重整數運算和md5哈希）會更能夠準確地幫你預測出Facebook的分析代碼有多快。

另一個重要的事實是，蘋果聲稱的在SunSpider上性能的提升并不能代表其它東西的提升，Eich et al在這篇提到蘋果所偏愛的benchmark的文章中寫道：

圖中清楚地顯示出了Firefox的3.6版本比1.5版本在SunSpider的benchmark上性能提高了13倍。但是當我們看它在amazon的benchmark上的性能表現時，發現只有較謙虛的3倍的提升。更有意思的是，在過去的兩年時間，在amazon的benchmark上的性能提升其實是被夸大了。這意味著在SunSpider上做的一些優化幾乎對amazon沒有太大作用。

在這篇文章中，JavaScript之父和Mozilla的首席架構師之一曾公開承認在過去的兩年之內Amazon的JavaScript性能幾乎沒有提升，沒有發生過什么特別重要的事情。從這一點你也可以看出來，那些營銷人員這些年都在過分夸大自己產品的性能。

他們繼續爭辯道：對于那些人們用來瀏覽Amazon網頁的瀏覽器來說，運行Amazon的benchmark比運行其它benchmark要更能準確地預測出瀏覽器的性能（這是當然了……），但是這些手段不會幫助你更好地寫出一個照片處理程序。

但是無論怎么說，從我可以看到的公開信息來看，蘋果聲稱的3.8倍的性能提升對你來說幾乎沒有什么太有用的東西。我可以告訴你，如果我有一些能夠反駁蘋果聲稱擊敗Chrome的benchmark的話，我將不被允許發布它們。

所以，我們總結一下這一節，如果有一些人拿出一個柱狀圖來顯示網頁瀏覽器變得更快了，那并不能真正說明整個JS變得更快了。

但是還有一個更大的問題。

并非為性能而設計

下面這段話出自于Herb Sutter，現代C++中最著名的人物之一：

在過去的20年里，有一種很難根除的文化基因——只要的等下一代的（包括JIT和靜態）編譯器出來，托管語言就會變得和原生語言一樣高效。是的，我完全希望C#和Java編譯器能夠不斷提高，包括JIT和類NGEN的靜態編譯器。但是，它們永遠不會消除與原生代碼之間的效率差距，有兩個原因：一、JIT編譯不是主要問題。根本原因更為基本：托管語言在編程人員的開發效率（當時的確是個問題）和程序的運行效率之間從設計上做了故意的妥協。特別的，托管語言選擇選擇在所有的程序上添加額外的性能開銷，盡管你根本沒有用到一個特性，你都會受到這個特性帶來的額外的性能開銷。主要的例子是assumption/reliance、垃圾回收、虛擬運行環境和元數據等功能在托管語言中是默認打開。當然還有其它的例子，比如托管代碼中函數默認是virtual的，而C++代碼中的函數是默認inline的。1盎司（譯注：12盎司=1磅）的內聯阻止（inlining prevention）抵得上1磅的去虛擬化優化（devirtualization optimization cure）。

下面這段話出自于Mono項目組的Miguel de Icaza，他是為數不多的“維護著一個主流JIT編譯器的人”。他說道：

關于主流托管語言（.NET、Java和JavaScript）的虛擬機之間的差異，有一個比較準確的說法。托管語言的設計者在他們設計一門語言的過程中更傾向于安全性，而不是性能。

或者你可以找Alex Gaynor談一談，他負責維護和優化Ruby的JIT編譯器，并且也為Python的JIT的優化工作做出了貢獻：

這是加在這些具有高生產力的動態語言身上的詛咒。它們使得創建一個哈希表十分容易。這是一件非常好的事情。我認為C程序員多數不太會使用哈希表，因為對他們來說用哈希表實在是是一件痛苦的事情。原因有二：第一，你沒有一個內置的哈希表；第二、當你嘗試去使用的時候，你會左右碰壁。對比來看，Python、Ruby和JavaScript程序員都過度使用哈希表了，因為使用它們實在太容易了……所以大家都不在乎。

Google似乎意識到了JavaScript正面臨著性能的瓶頸：

復雜的Web應用（這是Google比較擅長的）在某些平臺上正在面臨著不小的掙扎，主要是因為這些應用用到了一些不能被性能調優的語言，這些語言有內在的性能問題。

最后，我們聽聽權威人士的意見。我的一個讀者向我指出這段Brenden Eich的評論。正如你所知，他是JavaScript之父。

有一點Mike沒有強調：得到一個更簡單的語言。Lua比JS簡單得多。這意味著你可以寫出一個簡單的解釋器使得它跑得足夠快，同時能夠保持對trace-JIT代碼的尊重（這和JS不同）。

稍微下面一點又提到：

關于JS和Lua之間的差別，你可以說這完全是正確的設計和工程上的問題，但是內在的復雜性區別還是很大。你當然可以把較難的案例從熱路徑中刪除，但是他們也會因此付出代價。JS比Lua有更多的更難的案例。一個例子是：Lua（沒有顯式的元表使用）沒有像JS中的原型對象鏈（prototype object chain）的東西。

在這些真正從事相關工作的人當中，持有JS或者是其它動態語言能夠趕上C語言性能這個觀點的，只占極少數（very much the minority）。到處都有和主流想法不同的人，所以根本無法沒有什么辦法能夠達到真正的一致。但是，從語言的角度說到JIT語言是否能夠趕上原生語言的效率，他們給出的答案都是“不，不可能，除非修改語言本身或者API”。

但是還有一個更更大的問題。

都是因為垃圾回收

你可以發現，CPU問題、CPU相關的benchmark以及所有有關CPU的設計決定，都只是故事的一半。故事的另一半是內存。內存問題現在看來是如此的巨大，大到使整個CPU的問題看上去都僅僅是冰山一角。實際上可以討論的是，所有關于CPU的討論都是轉移注意力的話題（red herring）。你接下來要閱讀的應該會完全改變你對移動設備軟件開發的理解。

2012年，蘋果做了一件非常奇怪的事情（當然了，除非你是John Gruber，能夠看到它的到來）。他們把垃圾回收從OSX中除去了。真的，你可以去看看程序員指南。標題右邊有一個大大的“不推薦（Not Recommended）”。如果你之前是Ruby、Python、JavaScript、Java、C#或是其它任何1990年代之后誕生的語言的開發者，這應該會讓你感覺很奇怪。但是這很可能不會影響到你，因為你很可能不在Mac下面使用ObjC，在HN點擊下一個鏈接。但是這仍然看上去很奇怪，畢竟GC一直被大家使用著，而且它的價值也得到了證明。為什么你要反對它呢？蘋果是這么說的：

我們十分堅信ARC才是內存管理的正確方式，所以我們決定使OSX上的垃圾回收變成過時的（deprecate）。——ession 101, Platforms Kickoff, 2012, ~01:13:50

這段話沒有告訴你的是，當聽到這句話的時候，臺下的觀眾爆發出了熱烈的掌聲。OK，這就變得真的非常奇怪了。你是不是在告訴我有那么一個屋子里的程序員在為了垃圾回收之前的那種混亂的回歸而鼓掌？你可以想象下如果Matz在RubyConf上宣布GC過時的時候整個會場的寂靜，幾乎一顆針掉在地上都聽得到聲音。而這群人卻因此而高興？太古怪了吧？

你應該根據這些古怪的反應發現一些你現在看不到但是卻是在真正發生的事情，而不是僅僅把這些事情歸結于這群人對于蘋果的狂熱。這些正在發生的事情就是我們下面就要討論的主題。

思維過程是這樣的：把一個工作得好好的垃圾回收器從一個語言中拿出來簡直是瘋了吧？一個簡答的解釋可能是ARC可能僅僅是蘋果為了給垃圾回收披上一層美麗新裝而創造的一個營銷詞匯，所以這些開發者是為了這種升級而不是降級而鼓掌的。事實上，這就是很多iOS簇擁們的抱有的想法。

ARC不是一個垃圾收集器

所有的那些認為ARC是某種垃圾回收器的人，我想通過下面這個蘋果的幻燈片給你迎頭一擊（beat your face）：

這與和垃圾回收有類似名字的算法無關。它不是垃圾回收，他不是什么像垃圾回收的東西，它表現得一點都不像垃圾回收，它不會打亂任何保留周期，它沒有去回收任何東西，它甚至沒有去做掃描。OK，故事結束，它絕對不是垃圾回收。

因為正式的文檔還在NDA協議下，所以有很多傳言認為這并不是真的（但是細則已經可以看得到了，沒有任何借口了），而且很多博客都紛紛說這些不是真的。它是真的。不要再討論了。

垃圾回收不像你的經驗讓你感覺的那樣可行

這是蘋果在壓力之下給出的關于ARC和GC的說法：

在愿望清單的頂端上我們能為你們做的最重要的事情就是把垃圾回收帶到了iOS中，而這恰恰是我們最不應該做的。不幸的是，垃圾回收給性能帶來了很多次優的影響。你程序中的垃圾回收會使得你的內存使用率變得很高，而且垃圾回收器經常在不確定的時間點上被觸發而導致非常高的CPU使用率，從而打斷用戶正在做的事情。這就是為什么GC不適合在我們的移動平臺上使用的原因。對比來看，帶有獲取和釋放（retain/release）的手動內存管理學起來比較難，坦率的講有些像痔瘡（譯注：這個翻譯可能不準確，原文是pain in the ass）。但是它產生了更好更可預測的性能，這也是為什么我們選擇手動內存管理作為我們內存管理策略的基礎的原因。因為在外面真實的世界，高性能以及用戶體驗的連續性是我們的用戶最看重的。（譯注：在蘋果看來，用戶體驗要比開發者體驗重要。）~Session 300, Developer Tools Kickoff, 2011, 00:47:49

但是這還是完全瘋狂了，不是嗎？這只是開始：

1. 這可能會直接影響你整個職業生涯對于垃圾回收語言給桌面和服務器上帶來影響的理解；

2. Windows Mobile、Andriod、Mono Touch以及所有其它移動平臺上的GC似乎都可以挺好地工作。

所以讓我們反過來看這個問題。

移動平臺上的GC和桌面平臺上的GC不是同一回事

我知道你在想什么，你是一個有了N年開發經驗的Python程序員。現在是2013年了，垃圾回收完全可以解決問題。

這是一篇你想看到的文章，似乎問題并沒有解決：

如果你在這篇文章中其它什么都記不得，那么請記住這張圖。Y軸是垃圾回收所用的時間，X軸是“相對的內存足跡”，相對于什么？相對于所需的最小內存。

這張圖想說明的是，“如果你有6倍以上你實際需要的內存，那么使用垃圾回收是沒有問題的。但是如果你只有小于4倍你實際需要的內存，那么災難就要降臨了。”。但是不要相信我的話：

特別的，如果垃圾回收時系統擁有5倍于所需的內存時，它的運行時性能差不多甚至是超過顯式內存管理。但是，垃圾回收的性能在必須使用小堆（small heap）的情況下會出現急劇下降。如果有3倍于所需的內存的話，它會跑得慢17%；如果只有2倍于所需的內存的話，會慢70%。垃圾回收比物理內存的換頁更容易受到內存不足的影響。在這種情況下，我們所測試的所有垃圾回收器相對于手動內存管理都出現指數級的性能下降。

現在我們再來比較一下顯式內存管理的策略：

這些圖顯示，如果可用內存在合理的范圍的情況下（但不足以容得下整個應用），顯式內存管理器都要比垃圾回收器快太多。比如說，pesudoJBB以63M的可用內存運行，Lea allocator在25s的時間內完成運行。在相同可用的內存下運行GenMS，花了超過10倍的時間來運行（255s）。我們可以看到其它benchmark套件的相同趨勢。最值得一提的例子是213 javac和Lea allocator一起在36M的內存下運行，總體運行時間是14s，而與GenMS一起運行的情況下，運行時間為211s，用了超過15倍的時間。

基本的事實是，在內存受限的環境下垃圾回收性能的下降是指數級的。如果你在桌面電腦上寫Python或者JS程序的話，你整個的體驗可能是這幅圖的右邊部分，你可以一輩子都體會不到垃圾回收帶來的性能問題。花點時間想想這幅圖的左邊部分，并且想想我們該如何應對。

iOS上有多少可用內存？

這一點很難準確地描述。從iPhone 4到iPhone 5，這些設備上的物理內存從512M到1G不等。但是其中很大一部分為系統預留了，還有更大的一部分為多任務處理預留了。所以唯一真正的方法是在不同的情況下進行嘗試。Jan Ilavsky寫了一個非常有用的工具來完成這個任務，但是貌似沒有人公開任何數據。但這一點現在已經改變了。

現在，在一種“正常”的情況下（這一點很難具體說清楚是什么意思）進行測試是非常重要的，因為如果你在一臺剛剛啟動的機器上測試的話，你會得到更好的數據，畢竟你的系統里面沒有Safari所打開的頁面。所以我就在“真實世界”的情況下拿出一些我公寓里的設備進行本次benchmark。

你可以點擊進去看看詳細的結果，大體上來說，在iPhone 4S上，當你的程序使用了40M內存的時候就會得到警告，而使用了213M內存的時候，程序就會被殺死；在iPad 3上，使用400M左右時獲得警告，而使用550M左右的時候，程序被殺死。當然了，這些也僅僅是數字而已，如果你的用戶在聽音樂或者在后臺跑一些程序，你可用的內存會比我測試里面可用的內存更少，這只是給你一個思路而已。這么多內存看上去不少（213M應該對每個人來說都足夠了，是吧？），但實際上這還不夠。舉個例子，iPhone 4S拍照時的分辨率為3264*2448，每張照片有超過30M的位圖數據。如果你在內存里加載了2張照片你就會獲得警告，而如果加載了7張照片，程序就會被殺死。哦，你打算給你寫個循環在你的相冊中逐個處理？程序會被殺死。

還有一點需要十分注意：實際的情況下，一張照片可能存在于內存的多個位置。比如說，如果你在拍照片，那么你在以下位置都有數據：1) 你通過屏幕看到的攝像頭中的數據，2) 攝像頭實際上拍到的照片數據，3) 你嘗試寫到存儲卡中的壓縮JPEG緩沖數據；4) 你準備在下一個屏中顯示的數據；5) 你準備上傳到某個服務器中的數據。

在一些點上你會發現，保留30M的緩沖區去顯示照片縮略圖是一個非常不好的想法，因為這樣你會引入更多的數據：6) 用來保留下一屏顯示合適大小照片的緩存；7) 用于在后臺重新調整照片大小的緩存（在前臺做實在太慢了）。然后你發現你可能真正需要5個不同的大小，然后你的程序就不是一般的慢了，而是慢到讓人抓狂。在實際的應用程序中，僅僅是處理一個照片就會遇到內存的瓶頸并非罕見的事情。但是不要相信我說的話：

你能做的最糟糕的事情就是在內存不充足的情況下在內存中緩存圖片。當一張圖片被畫成位圖或者顯示到屏幕上時，我們就不得不把照片解碼為位圖。位圖的每個像素點為4字節，無論原始圖片多大都是如此。每當我們將它解碼一次，位圖就會綁定到圖片本身并且一直維持到這個對象生命周期結束之時。所以如果你把圖片加載到內存而且曾經顯示過一次，那你現在就會在內存中保留整個位圖，直到你釋放它為止。所以永遠不要把UIImage或者CGImage放到緩存中，除非你有一個非常明確（但愿是非常短期的）的目標。- Session 318, iOS Performance In Depth, 2011

你甚至不要相信上面的話！你給自己分配的內存其實只是冰山一角。下圖是蘋果一張幻燈片中給出的冰山的全圖。Session 242, iOS App Performance – Memory, 2012:

你可以從兩方面考慮這個問題。第一、在213M可用內存的情況下，在iOS上寫一個照片處理程序比在桌面上寫一個要困難許多。第二，你在iOS上寫一個照片處理程序時，你對內存的需要會更多，因為你的桌面程序沒有一個可以放進你口袋的攝像頭。

我們可以看看另外一個例子：在iPad 3上，你要顯示一個視頻，這種照片的大小很可能比你電腦上的視頻要大不少（后面的高分辨率攝像頭，差不多2000-4000像素）。每一幀要顯示的就是一個12M的位圖。如果你對內存的使用很節省的話，每一時刻你可以在內存中保留45幀的未壓縮視頻或動畫緩存，也就是在30fps的情況下每1.5s，在60fps的情況下0.75s。你想為一個全屏的動畫預留緩存？應用被殺死。值得指出的是，AirPlay的延遲是2s，所以對于任何多媒體類型的應用，你幾乎是保證沒有足夠的內存。

這種情況下我們同樣面臨著和照片的多個數據拷貝差不多的問題。比如說，蘋果指出，“每一個UIView背后都有一個CALayer，而且只要CALayer存在于在這個層次中，對應的圖片數據會一直保存在內存中”。這意味著，很可能有許多中間的渲染數據的拷貝存在于內存中。

還有剪切矩形和備份存儲這些可能會占用內存的事情。這樣的數據處理架構事實上是非常高效的，但是這帶來的代價是程序會盡可能地占用內存。iOS不是為低內存使用而設計的，它是為了快速運行而設計的。這沒有和垃圾回收扯在一起。

我們同樣需要從兩個方面考慮問題。第一，你在一種內存非常緊缺的情況下做出動畫效果；第二、做出這樣超級高質量的視頻和動畫是需要極大的內存的。而為了使得普通消費者買得起消費級別的、具有高攝像頭分辨率的產品，這種糟糕的、內存受限的環境幾乎是必然的選擇。如果你想寫一個軟件來毫無壓力地播放視頻，那么你就得說服別人為了屏幕多花700美元，或者花500美元買一個iPad，它實際上已經包含了一個內置的電腦。

我們會獲得更多內存嗎？（更新）

一些聰明的人說：“OK，你說了很多關于我們不會有更快的CPU。但是我們應該回有更多的內存吧？這正是桌面環境上發生的事情。”

這種理論的一個問題是，ARM平臺上的內存就在處理器本身上，這被稱為package on package。所以在ARM上獲得更多的內存幾乎和提高CPU性能是同一個問題，因為它們歸根結底是同一件事情：在CPU上集成更多的晶體管。內存晶體管處理起來稍微容易一些，因為它們是統一的，所以不是那么難，但實際上也不是那么簡單。

如果你看看iFixit的A6的照片，你會發現在CPU模具最表面的硅幾乎100%都是內存。這意味著，如果你想擁有更多的內存，你要么使得制作工藝更精細，要么提高模具的大小。事實上，如果你把工藝的大小做歸一化處理，那么其實伴隨著每次內存升級，你的模具都在變得更大。

硅其實是一種不完美的材料，為了獲得更大的尺寸所付出的的代價是指數級增長的。它們也很難維持較低的溫度，也很難放進小設備中。它們和制作出更好的CPU的目標是重復的，因為內存也面臨同樣的問題：CPU最上層的硅中需要放進更多的晶體管。

我搞不懂的是，面臨著PoP的這些問題，CPU廠商們繼續使用PoP的方式為系統提供內存。我還沒有遇到任何ARM工程師能夠解釋這一點。或許以下的評論可能會幫助我們理解。我們有可能從PoP架構轉向電腦中采用的分離內存模塊，而且我感覺這比較可行。原因很簡單，將內存分為單獨的模塊比制造出更大的芯片和進一步減小制作工藝對廠商來說毫無疑問成本是更低的。但是現在所有的廠商都在不停地嘗試提高制作工藝或者制作出更大的芯片，而不是把內存模塊獨立出來。

然而，一些聰明的工程師曾經給我發了郵件讓我填補了這方面的空白。

一個前Intel工程師說道：

PoP內存模型可以大量減少內存延遲，也可以減輕路由問題。但是我不是ARM工程師，也不確定這是否是全部的原因。

一個機器人學的工程師提到：

當PoP內存不夠用時，“3D”內存會提供足夠大的內存：內存芯片在生產的時候堆疊在一起，1G的RAM在同一層堆成10層向上，就像現在的硬件模型一樣。但是，這樣的開銷會很大，頻率和電壓都要相應地降低使得電力消耗處于一個合理的水平。

移動RAM的帶寬不會像最近提高得這么快了。帶寬被連接SoC和RAM包的總線的數量所限制。當前RAM的總線多數使用的是高性能SoC的圓柱體表面。SoC的中間部分不能用來加入RAM總線，因為這些RAM包是層疊的。接下來的重大改變應該回來自于將SoC和內存放在一個單獨的、高度集成的包中，允許更小、更密集和大量的RAM總線（更大的帶寬），并給SoC設計和更低的RAM電壓帶來更多自由。根據這樣的設計，更大的緩存也就可能成為現實，因為RAM可能用更高的帶寬放在SoC模具中。

但是Mono/Andriod/Windows Mobile平臺怎么解決這個問題呢？

這個問題事實上有兩個答案。第一個答案我們可以從圖中看出。如果你發現你有6倍于所需的內存，垃圾回收其實是非常快的。舉個例子來說，如果你在寫一個文本編輯器，你可能可以用35M的內存完成自己要做的所有事情，這是我的iPhone 4S會崩潰內存上界的1/6。你可能在Mono上寫個文本編輯器，看到非常不錯的性能，然后從這個例子中得出如下結論：垃圾回收十分適合這個任務。你是對的。

然而Xamarin框架在案例中有一個飛行器模擬器。很顯然的是，垃圾回收對于現實生活中的較大的應用程序來說是不適合的。難道不是嗎？

你在開發和維護這個游戲時一定會遇到什么樣的問題？“性能一直是一個大問題，而且將持續是我們再跨平臺中會遇到的最大的問題之一。最初的Windows Phone設備是非常慢的，我們不得不花很多時間來優化程序，使得它達到一個體面的幀率。我們不僅僅在飛行模擬代碼上進行優化，而且在3D引擎上優化。垃圾回收和GPU的弱點是最大的瓶頸。

程序員不約而同地聲稱垃圾回收是最大的瓶頸。當你的案例中的人在抱怨的時候，那應該是一個足夠引起你重視的線索了。但是Xamarin可能是一個局外人，我們還是來看看Andriod開發者怎么說的吧：

請記住下面是我在我的Galaxy Nexus上運行的情況：無論怎么說都是性能非常不錯的設備。但是看看渲染的時間！我在電腦上只要花幾百毫秒就可以渲染出這些圖片，可是在這臺手機上卻花了超過兩個數量級的時間。渲染“inferno”圖片超過6s？這簡直是瘋了吧！要生成一副圖片，需要10-15倍的時間來運行垃圾回收器。

另一個開發者：

如果你想在Andriod手機上為實時物體識別或者基于內容的現實增強進行對照相機圖片的處理，那么你很可能聽說過照相機預覽回調（Camera Preview Callback）的內存問題。每次Java程序嘗試從系統獲取預覽圖片時，系統就會創建一大塊新的內存。當垃圾回收器釋放這塊內存時，系統會卡住（freezes）100ms到200ms。如果系統在高負載的情況下，事情可能會變得非常糟糕（我曾經在手機上做過物體識別——天吶，它幾乎把整個CPU都占用了）。如果你看過Andriod 1.6的源代碼你就會知道，這只是因為這個功能的包裝類（wrapper，用來包裝原生代碼）每次在一個新的幀可用時都會申請一個新的字節數組。當然，內置的原生代碼可以避免這個問題。

或者，我還可以去看看Stack Overflow：

我負責在Andriod平臺上為Java寫的交互式游戲進行性能調優。很多時候，當候垃圾回收開始工作會讓使得游戲的畫圖和交互功能發生打嗝。通常情況下這種打嗝持續不到1/10s，但有的時候在比較慢的設備上會長達200ms。如果我在一個內部循環中使用樹或者哈希表，我就就知道我要很小心，或者甚至不用Java標準的Collections框架，而是自己重新實現一個，因為我承擔不起垃圾回收帶來的額外開銷。

這是一個“接受的答案（accepted answer）”，有27個人贊同：

我也是Java手機游戲的開發者……避免垃圾回收（垃圾回收可能在某個點被出發從而大幅降低你游戲的性能）的最好方法就是不要再游戲的主循環中創建對象。實在沒有什么“簡潔”的方式來處理這種問題，或許只有手動追蹤這些對象了，真悲哀。這地也是目前大部分當前移動設備上性能優良的Java游戲所采取的的方式。

我們來看看Facebook的Jon Perlow怎么看待這個問題：

對于開發流暢的安卓應用來說，GC是一個非常大的性能問題。在Facebook，我們遇到的最大問題之一是GC會使得UI線程暫停。當我們處理很多位圖數據時，GC被觸發的頻率很高，而且難以避免。GC經常導致掉幀的問題。即使GC只會阻塞UI線程幾毫秒，但這卻會嚴重影響原本需要16毫秒的幀渲染。

OK，我們再聽聽一個微軟MVP的說法：

通常情況下，你的代碼在33.33ms之內就會完成執行，從而使得30fps的幀率變得很不錯。但是當GC運行的時候，它會占用那個時間。如果你的堆比較整潔和簡單，那么GC一般可以運行得不錯，不會對程序產生什么影響。但是讓一個簡單的堆處于一個使GC可以快速運行的情形是一件困難的編程任務，它要求大量的計劃和/或程序重寫，即使是這樣也不是完全安全的（有時在一個復雜的、有很多玩意的游戲中你的堆里面有很多內容）。更簡單的方法是（假設你能這么做），在游戲過程中限制甚至是禁用內存分配。

在有垃圾回收的情況下，在游戲中保證一定會贏的方法就是不要玩（作者的幽默，原文：the winning move is not play）。比這種哲理稍弱的一種形式如Andriod官方文檔中所說的：

對象創建永遠不是免費的。帶有線程級別內存池的垃圾回收器使得內存分配的成本變得稍微低一些，但是分配內存永遠比不分配內存開銷大。因為當你在程序中分配對象時，你會強制垃圾回收周期性地工作，從而使得用戶體驗不是那么流暢。Andriod 2.3當前引入的垃圾回收器有一些作用，但是要是應該避免不必要的工作。因此，你應該避免創建你不需要的對象實例。一般而言，盡可能不要創建短期臨時對象。越少的對象創建就意味著越低頻率的垃圾回收，從而提高用戶體驗。

還不信？那讓我來問問一位真正從事垃圾回收工作的工程師，他為移動設備實現垃圾回收器。

然而，WP7系統的手機CPU和內存性能正在大幅度地提升。游戲和大型Silverlight應用越來越多，這些程序會占用100M左右的內存。隨著內存的變得越來越大，很多對象擁有的引用會指數級地變多。在上面解釋的模式中，GC不得不去遍歷每個對象以及他們的引用，標記它們，然后清理沒喲引用指向的內存。所有GC的時間也大幅增加，并且成為這個應用的工作集（workingset）的一個函數。這會在大型XN游戲中和SL應用中導致程序卡住，體現在很長的啟動時間（因為GC有可能在游戲啟動的時候運行）或者游戲過程中的小問題。

還是不信？Chrome有一個測量GC性能的benchmark。我們來看看它都干嘛了：

你可以看到很多GC導致的卡頓。當然了，這是一個壓力測試，但還是能說明問題的。你真的愿意花幾秒時間來渲染一幀？你瘋了吧。

這么多引用，我才不會挨個看呢，直接告訴我結論就行了。

結論是：移動設備上的內存管理很難。iOS平臺的開發者已經形成了一種文化，即手動做大部分事情，讓編譯器做其它容易的部分。Andriod平臺形成的文化是，提高垃圾收集器的性能，但事實上開發者在實際開發中盡量避免使用它。這兩者的共同點是，大家在開發移動應用時，開始越來越多地考慮內存管理問題了。

當JavaScript、Ruby或是Python開發者聽到“垃圾收集器”這個詞時，他們習慣將它理解為“銀彈（silver bullet）垃圾收集器”，也就是“讓我不要讓我再考慮內存問題的垃圾收集器”。但是移動設備上根被沒有銀彈可言，每個人寫移動應用時都在考慮內存問題，不管他們是否使用了垃圾收集器。獲得“銀彈”內存管理方式的唯一方式就像我們在桌面環境上一樣，擁有10倍于程序實際需要內存。

JavaScript的整個設計基于一個思想，即不要擔心內存。看看Chromium開發者們怎么說：

有沒有任何一種方式強制chrome的js引擎進行垃圾回收？一般意義而言，沒有，這是從設計的角度就已經確定了的。

ECMAScript規范沒有提到“分配（allocation）”這個詞，唯一與“內存”相關的話題本質上就是說整個主題都是“實現相關的（host-defined）”。

ECMA 6的維基頁面上有幾頁提案的草稿，歸根結底是說（不是開玩笑）：

“垃圾回收器不可以回收那些程序需要繼續使用來完成正確執行的內存。所有不能從根節點傳遞遍歷到的對象都應該最終被銷毀，防止程序因為內存耗盡而發生錯誤。”

是的，他們的確在思考將這個需求規約：垃圾回收器不應該回收那些不應該被回收的東西，但是應該回收那些需要被回收的。歡迎來到tautology club。但是下面這段話可能與我們的話題更相關：

然而，并沒有規范說明單個對象占用多少內存，也不太可能會有。因此當任何程序在內存耗盡的情況下，我們永遠不會得到任何保證，所以任何準確的、可觀察的下界。

用英語來說就是，JavaScript的思想（如果這算是一種思想的話）是你不應該能夠觀察到系統內存中的情況，想都不要想。這種思想和人們在寫實際的程序時候的想法簡直是令人難以置信的背道而馳（so unbelievably out of touch），我甚至找不到正確的詞語來向你形容。我的意思是，在iOS的世界里，我們并不相信垃圾回收器，我們感覺Andriod開發者都瘋了（nuts）。我懷疑Andriod開發者會這么認為：iOS開發者竟然會用手動內存管理，簡直是瘋子。但是你知道這兩個水火不容的陣營的人可以在哪件事情上達成共識嗎？那就是JavaScript開發者是真正的瘋子。你在移動平臺上寫出一個有點意思的程序，而從來不關心系統內存的分配和釋放，是絕對不可能的（absolutely zero chance）。絕對不可能。暫時把SunSpider的benchmark上的問題和CPU計算密集型的問題都拋開，我們可以得出這樣的結論：JavaScript，盡管現在存在著，是和移動平臺軟件開發過程中絕對重要的思想，即永遠要考慮內存問題，從根本上是背道而馳的。

只要人們想要人們想在移動設備上開發各種視頻和照片處理程序（不像桌面電腦），只要移動設備的內存不是那么充足，這個問題就是非常棘手的。你在移動設備上需要理性的、正式的內存管理保證。而JavaScript從設計上來說是拒絕提供這些的。

假設它能夠提供這些

現在你可能會問，“OK，桌面環境上的JS開發者不會移動設備上的開發者遇到的問題。假設他們相信你說的，或者假設有一些知道這些問題的移動開發者們根據JS重新設計一門語言。你感覺理論上他們可以做哪些事情？”

我不確定這是否是解決的，但是我可以在這個問題上放一些邊界。有另一群人曾經嘗試在JS的基礎上設計一門適合移動開發者的語言——RubyMotion。

這些人非常聰明，他們很了解Ruby。然后這些Ruby開發者認為垃圾回收對于他們的語言來說是一個糟糕的想法。（GC倡導者們，你們看到我說的了嗎？）所以他們用了一種非常類似ARC的技術然后嫁接到語言當中，然而卻沒有成功。

總結：很多人正經歷著由于RM-3或者其它難以辨別的問題所導致的內存相關議題，我們可以看看他們怎么說。

Ben Sheldon說：

不僅僅是你，我也面臨著內存相關的程序崩潰（比如SIGSEGV和SIGBUS）生產環境下有10-20%的用戶遇到過這種情況。

有一些人懷疑這個問題是否易于處理：

我在最近的一次Motion Meetup會上提出關于RM-3的問題，Laurent和Watson都對此提出了自己的看法。Watson提到說，RM-3是最難修復的bug；Laurent說他嘗試了很多方法，但最終都沒有很好地解決這個問題。他們兩個人都是非常聰明和厲害的程序員，所以我相信他們說的話。

還有一些人懷疑編譯器理論上是否能夠解決這個問題：

很長的一段時間內，我都認為編譯器可以簡單明確地處理程序塊，即靜態地分析程序塊內部的內容來判斷程序塊是否引用了這個程序塊外部的變量。我認為，對于所有這些變量，編譯器可以在程序塊創建時獲取，在程序塊銷毀時釋放。這個過程吧這些變量的生命周期綁定到程序塊上（當然，在某種情況下不是“完整的”生命周期）。有一個問題是instance_eval（譯注：Ruby中Object類的方法）。程序塊中的內容或許是按你提前知道的方式使用的，但也有可能并不是你能夠提前知道的。

RubyMotion還有一個對立的問題：內存泄露，而且它還有可能有其它問題。沒有人真正知道程序崩潰時內存泄露有2個原因還是有200個原因。

所以不管怎么說，我們的結論是：一部分世界上最好的Ruby程序員專門為移動設備開發設計了一種語言，他們設計了一個系統，這個系統不僅會崩潰，而且還會內存泄露，這些問題都是你可能會面臨到的。至今為止他們并沒有能夠處理這個問題，盡管他們已經非常盡力了。對了，他們也表示他們“自己嘗試了不少次，但沒有能夠能夠找到一個好的并且能夠保持高性能的解決方案”。

我并不是說在JavaScript的基礎上創建一門具有較高內存性能的語言是不可能的，我只是想說很多證據顯示這個問題會非常難。

更新：一個Rust語言的貢獻者提到：

我為Rust項目工作，我的主要目標是實現零額外開銷的內存安全。我們通過“@-boxes”（@T聲明的類型是任何類型T）的方式來支持通過GC處理的對象，而我們最近遇到的比較麻煩的事情是，GC觸碰到語言中的所有內容。如果你想支持GC但卻不需要它，你就要非常仔細地設計你的怨言來支持零額外開銷的非GC指針。這不是一個簡單的問題，我不認為可以通過建立在JS的基礎上創建一門新語言來解決。

OK，但是ASM.JS如何呢？

asm.js就比較有趣了，因為它提供了一個JavaScript模型，但這個模型嚴格意義上不是建立在垃圾回收的基礎上的。所以從理論上講，使用正確的網頁瀏覽器，使用正確的API就可以了。問題是，“我們會得到正確的瀏覽器嗎？”

Mozilla顯然在這個概念上被出賣了，作為這個技術的作者，他們的實現今年晚些時候實現了它。Chrome的反應一直是含糊不清的，因為這個技術顯然和Google的其它提案，包括Dart和PNaC1有直接的競爭關系。關于它有一個開發的bug清單，但是一個V8的黑客對此不滿意。至于Apple陣營，按照我現在看來，WebKit那群人對比完全保持沉默。IE？我從來就沒有抱任何希望。

無論如何，現在還不能說asm.js就是真正解決JavaScript問題，且能夠擊敗所有其它提案的方法。另外，如果它能做到，它真的不可能是JavaScript，畢竟它能夠可行的原因就是拋開了麻煩的垃圾回收器。所以它有可能和C/C++或者其它手動管理內存的語言的前端一起工作，但肯定不和我們現在知道并且喜歡的動態語言一樣。

相對什么來說慢？

當一些文章里面說“X慢”和“X不慢”的時候，一個問題是，沒有人真正說的清楚它們的參照系是什么。對于一個網頁瀏覽器開發者，和對于一個高性能集群的開發者，以及對于一個嵌入式系統的開發者，等等，“慢”的含義是不一樣的。既然我們已經闖過了戰壕而且做了這么多benchmark，我可以給出你三個有用且大致正確的坐標系。

如果你是一個Web開發者，把iPhone 4S的Nitro當做IE8來看，因為它們的benchmark成績差不多。這就給了你寫代碼時的正確坐標系。寫代碼的時候應該謹慎地使用JS，否則你會面臨一大堆平臺相關的性能問題要處理。有些應用用JS來寫性價比是不高的，即使是流行的瀏覽器。

如果你是x86平臺上的C/C++開發者，把iPhone 4S的Web開發環境當成只有桌面開發環境性能的1/50。其中1/10來自于ARM相對于x86的性能差距，1/5來自于JavaScript相對于C/C++的性能差距。在非JavaScript、性能為桌面環境1/10的情況下，仔細考慮正反面的因素。

如果你是Java、Ruby、Python或者C#開發者，按照以下方式去理解iPhone 4S的Web開發環境：它的性能是你電腦的1/10（ARM的因素），并且如果你的內存使用超過35M，性能會指數級下降，這是由垃圾回收的工作方式決定的。還有，如果你的程序分配了超過213M的內存，程序就會崩潰。注意，沒有人“從設計的角度”在運行時刻給你這個信息。對了，人們都希望你在這種環境下寫出很耗內存的照片處理和視頻應用。

這是一篇非常長的文章

下面是你應該記得的內容：

• 2013年，用JavaScript寫的移動應用（如照片編輯等）實在是太慢了。
  • 比原生代碼慢5倍
  • 性能和IE差不多
  • 比x86平臺上的C/C++代碼慢50倍
  • 如果你的程序所有的內存不超過35M，比服務器端的Java/Ruby/Python/C#慢10倍；如果內存使用超過這個數，性能開始指數級下降
• 要使這個速度變得快一些，最可能的方式是讓硬件性能達到桌面水平的性能。從長遠來看這是可行的，但是看起來要等很長時間。
• 最近一段時間JavaScript語言本身并沒有變得更快，在JavaScript上工作的人認為，在現有的語言和API下，它永遠不會向原生代碼那么快。
• 垃圾回收在內存受限的環境下會呈現指數級的性能下降，這一點比桌面和服務器級別的情況差很多。
• 任何能干的移動開發者都花很多時間來為目標設備考慮內存性能問題，不管他們是否使用具有GC的環境。
• 當前的JavaScript，從本質上是和允許程序為目標設備考慮內存性能問題這一點背道而馳的。
• 如果JavaScript的工作者們意識到這問題并且做出改變，允許開發者考慮內存問題，經驗表明這是技術上的難題。
• asm.js讓人看到了一些希望，但是就算它能成功，它應該是用了C/C++或者類似的“過時的”語言的前端，而不是像JavaScript這樣的前端。

讓我們提高爭論的層次

毫無疑問的一點是，我不久就將收到上百封郵件，這些郵件圈出我說的某句話，然后在不提供任何實際的證據（或者根本不能算是證據）的情況下，指出我說得不對。或者說“我曾經用JavaScript寫過一個文本編輯器，挺好”，或者說“有些我從來沒見過的人寫了一個飛行模擬器，但是從來沒有給我寫郵件說明他們遇到性能問題”，這些郵件我會一律刪除。

如果我們想要在移動Web開發（或者是原生應用，或者是任何其它事情）上取得一些進展，我們都需要各種至少看上去有說服力（at least appear to have a plausible basis）的討論，包括benchmark、期刊以及編譯器作者們的引用等等。網上有很多HN關于“我曾經寫了一個Web應用，挺好”的評論，還有很多關于Facebook在知道他們將會知道現在應該知道的東西的情況下（譯注：原味knowing what they would have known then what they could have known now，不知這樣翻譯對不對？）是選擇HTML5還是原生應用是對是錯的爭論（譯注：原文為bikeshedding，這是一個比較有意思的詞，意思是在還沒完成自行車車架還沒弄好的情況下就去討論車的顏色，意指過于關心細節和邊緣的問題，而忽視主要問題）。

對于我們來說，剩下來的任務是，明確地量化如何使得移動Web和原生生態環境變得越來越好，接著為此做出一些事情。正如你所知，這也是一個軟件開發者應該做的事情。

轉載于:https://www.cnblogs.com/beesky520/p/4843631.html

總結

以上是生活随笔為你收集整理的201509281125_《为什么移动app会很慢的深度分析（摘自司徒正美博客园文章）》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。