寫在前面的一些話：

　　在糾結了很久以后，我決定來寫寫 iOS 和 Android，也算是對自己近幾年來學習成果的一個總結。這個話題非常大，本人雖盡我所能查證來源，但也難免會有疏漏，有的話歡迎指出。我希望大家讀完后，是這樣的：

　　而不是：

　　我們應該為這個世界的多樣性而感到慶幸，不是么？

　　一、什么是流暢？什么是卡頓？

　　如果我們討論流暢和卡是建立在不同的標準上，一定會變成毫無意義的口水戰(zhàn)。在這里，流暢我們定義為運行程序時達到 60fps 或以上的繪制效率，且盡可能少丟幀。卡頓我們定義為程序運行時無法達到 60fps，丟幀頻繁。

　　二、Apple 和 Android陣營 比是不是能帶來更流暢的應用體驗？

　　不是。兩者都非常順滑，用久了也都不卡頓。

　　Android 定義為 帶有 GMS 推送的，帶有良好 Android 應用生態(tài)圈的（包括少數國內優(yōu)秀應用），具有 Google Play 服務的 Android 手機，擁有健康使用習慣的 Android。包括但不限于 Nexus，Moto，SONY，LG，htc，Samsung 在沒有封殺 Google 的市場的使用體驗。

　　三、Apple 和 安卓陣營 比是不是能帶來更流暢的應用體驗？

　　是。安卓（尤其是用久了）很可能會卡頓。

　　安卓 定義為 不帶GMS推送的，缺失良好 Android 應用生態(tài)的，不具有 Google Play 服務的，基于各種“深度優(yōu)化，深度定制，世界第一，跑分天王，etc.” 家，配合 “動不動就管家衛(wèi)士全家桶，清理內存釋放手機速度，打敗全國百分之XX” 的用戶的 安卓生態(tài)。

　　四、Apple 和 Android陣營 硬件對比

　　Apple 硬件處于一個什么樣的水平？足夠優(yōu)秀的水平，Apple 是著名的硬件狂魔，并不是大家想的 iPhone 硬件遠遠不及 Android 陣營。

　　1、 Android 陣營目前的旗艦 Soc 之一 是基于 高通810 的解決方案（MTK 和 三星，華為 的解決方案不是很了解，歡迎補充。當然業(yè)界一般認為是三星的 CPU 14nm 制程更先進，所以功耗發(fā)熱的表現較810更好。），它擁有 8 個 CPU 核心，20nm 制程，主頻高達 2 GHz。810 純 CPU 計算能力，并發(fā)計算能力優(yōu)于 A8。但它頻率高，核心多，功耗和發(fā)熱量在密集計算時也會遠高于 A8，發(fā)熱會限制 810 的發(fā)揮。

　　2、CPU Cache 方面。

　　A8 非常慷慨地配備了高達 64KB 64KB 的 L1 Cache，1MB L2 Cache 和 4MB L3 Cache，與上一代 A7 相同，810 數據不明。但實際應用來看，似乎 810 配備的 Cache 喂不飽 8個核心，存在 Cache Miss 的情況。（有硬件信息的朋友歡迎補充）但是，即使沒有準確數據的情況下，有一件事情也是可以確定的，那就是 Cache per Core數據 810 絕對不如 A8。如果要做到一樣的水平，那么 810 要配備 128kb L1 Cache，4MB L2 Cache，16MB L3 Cache。要知道的是，這么多的 Cache 即使是對于 Intel Core i7 也是很奢侈的。而如果假設 810 和 A8 配備了一樣的Cache，810 的 Cache per Core 數據就很難看了。要知道，CPU Cache 的速度遠高于 RAM 的速度，所以小 Cache 帶來的情況就是 外圍 I/O 經常處于等待狀態(tài)，延遲了 CPU 計算能力的發(fā)揮。打個比方，你拿跑車引擎配個 4 速變速箱，引擎的能力就無法發(fā)揮了。Cache 方面，A8 表現優(yōu)于 810。

　　3、GPU 方面。

　　A8 配備的 PowerVR Series 6XT GX6450 運算能力是 136.4 Gflops（533MHz）/153.6 GFlops（600MHz），稍微優(yōu)于 801 配備的 Adreno 330 ，Adreno 430 則是 324~388.8 GHz（600MHz）【水冷……】。畢竟當時高通設計 810 的時候就是用來拖 4k 的，圖形性能 Adreno 430 數據上遠優(yōu)于 GX6450，但是 GX6450 帶 1334*750 相當于 801 帶 720p，帶 1920*1080 分辨率性能也足夠充裕。

　　4、晶體管數量。

　　喪心病狂的 A8 堆了 20 億個晶體管（包括 Cache，GPU，dsp），已經趕上 810 所有 8 個核的總晶體管數量了。帶來了 A8 極其兇殘的單核性能。810 單核性能弱于 A8。

　　五、系統(tǒng)與運行機制層面

　　（一）內核

　　1、又要開始拿 Linux 和 Unix 說事了，但很不幸的是，流暢這件事跟系統(tǒng)內核一點關系都沒有。

　　2、說個老梗：

　　● iOS 基于 Unix 所以是 Touch（響應觸摸操作）——Media——Service——Core 架構

　　● Android 基于 Linux 所以是 Application——Framework——Library（包含了響應觸摸操作的顯示相關）——Kernal 架構

　　● 所以 iOS 要比 Android 響應的快，所以 iOS 更流暢 云云

　　● 然而這個東西是 2.x 時代的，Google 早就改掉了……我也不知道這種 Unix 內核性能優(yōu)于 Linux 的論調為什么時不時還會冒出來……反正兩者都不是實時操作系統(tǒng)（RTOS）。

　　（二）運行時（Runtime）

　　1、 Android 基于 Java 虛擬機，前段時間還因為這個 Google 和甲骨文吵上了法庭。算了回歸正題，我們主要要說的運行時有 Dalvik 和 ART（Android Runtime）兩種，Dalvik 是 Android 于 Android 4.4 之前所使用的默認 Runtime，ART 則是 Android Runtime，是在 4.4 時引入的一種新的運行時，在 L 及以上版本取代 Dalvik 成為默認運行時，在 GC 機制、JNI 和 Stack size 上都與 dalvik 有著很大的不同。Dalvik 屬于 JIT（Jusi-in-time）編譯器，ART 屬于 AOT（Ahead-of-time）編譯器。反正說了這么多你們只需要知道 ART 可以直接調用底層效率更高就對了。

　　● 其實是我 《編譯原理》 還沒啃熟你們不要打我嚶嚶嚶，有興趣的自己去看這兩個鏈接

　　● http://tinyurl.com/maz6uaq

　　● http://tinyurl.com/nepu7vk

　　2、iOS 不開源，但是可以知道的是它的 Object-C 編譯器屬于 GCC 編譯套裝的一部分（感謝 @InflationAaron 指出：后期應該是轉向了蘋果主導的 LLVM 編譯器）。

　　（三）渲染流水線

　　1、 Android 3.0 引入了應用端繪圖的 GPU 加速（Hardware Canvas），Android 4.1 引入了黃油計劃（Project Butter），到 4.1 可以說 Android 的渲染機制已經足夠優(yōu)秀，只要按 Design Guideline 寫是輕松讓過渡動畫達到 60fps 的。黃油計劃包括了：

　　● 窗口三重緩沖機制（降低連續(xù)丟幀可能性）

　　● 垂直同步機制（減小應用端開始繪制到實際屏幕更新的延遲）

　　● GL 窗口緩存繪圖命令的異步執(zhí)行（減少應用主線程的阻塞）

　　但很明顯 Google 還不滿足，于是在 Android L 引入了獨立的 GPU 線程，并允許主線程和 GPU 線程并發(fā)。也就是說GPU線程在繪制第 N 幀的 Display List 時，主線程已經可以同時生成第 N 1 幀的 Display List，并且允許 GPU 調用不同參數繪制同一個 Display List，簡單的說就是提高了繪制過渡動畫的效率。

　　這里說一個 Google 的黑科技，Project Sky - Dart on Android，完全脫離 Java 的一套東西，他們的目標是把渲染時間壓縮到 8ms 以內，也就是等效 120fps。但他們現在做出的 Demo 里每幀平均渲染時間是 1.2ms/f，也就是等效驚人的 833fps……

　　2、iOS 不開源……（又來了）但是，我們仍然可以推測他的渲染流水線和 WebKit 類似，因為 WebKit 存在大量 Apple 的參與代碼。

　　3、總而言之，你們只需要知道 Android 和 iOS 是 different but not better than each other 就行了。只是在實現路線上有所不同，但實際上到最后都異曲同工。Google 的 Project Sky 性能驚人，實際應用有待觀查。

　　六、應用，ROM（Android）以及其它

　　（一）This might be the most tedious part.

　　（二）應用，講到這里就不想講了，算了，還是講一下吧：

　　1、BAT

　　● Baidu，alibaba，tencent，號稱 Android 流暢度三大殺手

　　● 這些大公司用戶太多太多了，導致他們必須兼容低版本的 Android，無法利用新的 API，導致卡頓：

　　（1）QQ，節(jié)奏大師，Android 2.2，API level 8

　　（2）QQ瀏覽器，UC瀏覽器，Android 2.3，API level 9

　　（3）閑魚，支付寶，淘寶，百度，Android 4.0，API level 14

　　（4）微信，Android 4.0.3，API level 15

　　● 發(fā)現什么問題了沒有？引入黃油計劃的 Android 版本是 4.1，所以 60fps……

　　● 然后 QQ 和節(jié)奏大師你們這還抱著凍酸奶的態(tài)度令我感動……以及瀏覽器們都和姜餅曖昧不清……唉，連GPU加速都……

　　● 然后如果打開開發(fā)者選項里面的 show GPU overdraw（雖然不一定是 GPU 繪制的），你們就會發(fā)現各種嚴重的 overdraw，尤其是阿里巴巴系列的應用，整個頁面濫用 Webview，導致了嚴重的重復繪制。

　　● BAT 經常大量使用自制控件進一步加劇了對資源的使用。

　　● 假如有第三方客戶端的話，其實往往有非常優(yōu)秀的遵守 Design Guideline 的應用，比如新浪微博的第三方客戶端們，四次元，Fuubo，Smooth等等。

　　2、GCM，與那些推送的事情

　　● GCM 就是 Google Cloud Messaging，是 Google 自家的推送服務，也是絕大多數 Android 應用的推送服務。使用這個服務，利用的是 Google 服務器統(tǒng)一推送，可以帶來及時，省電，后臺不喚醒的推送體驗。

　　● APNs 就是 Apple Push Notification Service，Apple 的推送服務，與 GCM 類似，可以帶來良好的體驗，且是 iOS 上唯一的推送機制。

　　● 然而由于某堵墻的存在，國內并沒有辦法體驗到 GCM 推送帶來的推送體驗。所以部分手機廠商就開始做自己的推送機制，比如小米做的對齊喚醒和 MiPush，但是只對 MIUI 及兼容的部分應用有用。

　　● 剩下的就是其它諸多推送了，BAT 自家的推送機制，極光，蝴蝶云，智游，個推等等。假如很不幸的，你的手機上安裝了 BAT 全套，又安裝了帶各種不同推送提供商的應用，那就等著感人的耗電，內存占用與無數的后臺喚醒吧……

　　3、優(yōu)化

　　● 很不幸的是，到現在，兩個平臺都仍然有大量的應用跑在單核單線程上，對雙核，多核以及 64 位的利用非常之低，甚至沒有。這個時候 A8 較高的單核性能能帶來更好的體驗。但如果應用對多核做好了適配的話，在 Android 上流暢性是可以花樣吊打 iOS 的。

　　4、流媒體視頻

　　● Android 在這方面流暢度要好于 iOS

　　（1）Android 支持傳統(tǒng)流媒體格式，可以用已經成熟的 CDN

　　（2）iOS 需要使用TS流，需要額外準備 CDN 線路，部分線路支持還不佳

　　（3）Android 4.0 后使用 HLS 協(xié)議并且實現 P2P

　　（三）ROM

　　1、iOS 并不存在這個問題，不講。

　　2、Android 存在的問題是，有太多廠商太多版本的 ROM 了，每個廠商都對底層做些修改。所以簡而言之就是鬧心，負分優(yōu)化大家見得多了我就不說了。

　　PS：知道為什么國內定制越深度的 ROM 適配 Android L 越慢嗎？就是因為底層的東西改得太多 5.0 把運行時改了工程量很大難以在保證功能健全的情況下快速適配。

　　3、驅動（不是很懂，希望補充）

　　七、最后我們來說說設計

　　1、 iOS 的人機交互設計還是很值得稱道的，畢竟是帶領我們進入了 Multi Touch 時代，從 iOS 6 的擬物到 iOS 7/8/9 的扁平 高斯模糊毛玻璃為代表的設計路線，都可以說是一套非常值得令人尊重的設計方案。它是比較早把流暢的動畫引入設計語言的一個方案，也在長期的驗證中逐漸發(fā)展成熟。

　　2、以 Holo Theme 為代表的 Android Design，進化出了 Material Design，對整個 UI 的把控能力達到了一個非常高的水準。陰影，漣漪波紋，Z 軸等等，都顯示出 Google 對細節(jié)一絲不茍的把控，且這套 UI 比較好的解決了桌面，網頁，移動端的交互統(tǒng)一性。

　　八、總結

　　1、總之，對比下來我們會發(fā)現，兩種生態(tài)在健康的情況下其實軟硬技術實力都是處在同一水平線上的，互有長短。硬件 Apple 并沒有弱于 Android，更談不上軟件的神優(yōu)化。但是，如果 Android 沒有 Google Services，就相當于失去了 Android 的靈魂，失去了 Google Play 的優(yōu)秀資源，失去了 GCM 推送帶來的流暢省電，失去了 Google Cloud 在內的很多很多核心競爭力。不卡或會卡，本質不是系統(tǒng)的問題，而是什么樣的環(huán)境，用戶著什么樣的程序。

　　2、iPhone 就好像是一輛 F1 方程式賽車，里里外外都精心設計過。看起來只有 1.6L 的排量，但實際上卻是一顆上千馬力的心臟，但這也決定了他只能在專門設計的方程式賽道上跑，而且跑的很歡。一旦脫離賽道（越獄），就各種不安全。

　　3、 Android 則好像是各種其它跑車，硬件的定制化程度極高，既有入門級的現代 Coupe，尚酷 R，也有比肩 F1 的布加迪威航，法拉利，蘭博基尼，更有小眾的科林賽格，優(yōu)雅的瑪莎拉蒂等等……如果再適合他們的路況上跑，就算是入門級，輕松破 200km/h 也不是什么難事，即使無法比肩 F1，也足夠體驗駕駛樂趣，旗艦則可以和 F1 全面硬抗，彎道，直道，加速，都能爭個高下，甚至還可以玩一些 F1 做不到的事情，比如彈射起步，漂移等等。

　　4、安卓則是……則是幾個改裝廠把這些跑車們自行改裝，有的廠商改的好，有的改成渣，拉到了坑洼不平的土路上，還時不時來點路障，這就算起步跑得溜，但久了對整車肯定不好。