iPhone的良好體驗，給iPhone帶來了很多果粉，然而卻有一些果粉卻看不起使用安卓的用戶，覺得安卓又丑又慢，那麼，安卓真的沒有iOS流暢嗎？
一、什麼是流暢？什麼是卡頓？
如果我們討論流暢和卡是建立在不同的標準上，一定會變成毫無意義的口水戰。在這裡，流暢我們定義為運行程序時達到 60fps 或以上的繪製效率，且儘可能少丟幀。卡頓我們定義為程序運行時無法達到 60fps，丟幀頻繁。
二、Apple 和 Android陣營 硬體對比
Apple 硬體處於一個什麼樣的水平？足夠優秀的水平，Apple 是著名的硬體狂魔，並不是大家想的 iPhone 硬體遠遠不及 Android 陣營。
1、Android 陣營目前的旗艦 Soc 之一 是基於 高通810 的解決方案（MTK 和 三星，華為 的解決方案不是很了解，歡迎補充。當然業界一般認為是三星的 CPU 14nm 製程更先進，所以功耗發熱的表現較810更好。），它擁有 8 個 CPU 核心，20nm 製程，主頻高達 2 GHz。810 純 CPU 計算能力，並發計算能力優於 A8。但它頻率高，核心多，功耗和發熱量在密集計算時也會遠高於 A8，發熱會限制 810 的發揮。
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 經常處於等待狀態，延遲了 CPU 計算能力的發揮。打個比方，你拿跑車引擎配個 4 速變速箱，引擎的能力就無法發揮了。Cache 方面，A8 表現優於 810。
三、系統與運行機制層面
（一）內核
1、又要開始拿 Linux 和 Unix 說事了，但很不幸的是，流暢這件事跟系統內核一點關係都沒有。
2、說個老梗：
iOS 基於 Unix 所以是 Touch（響應觸摸操作）——Media——Service——Core 架構
Android 基於 Linux 所以是 Application——Framework——Library（包含了響應觸摸操作的顯示相關）——Kernal 架構
所以 iOS 要比 Android 響應的快，所以 iOS 更流暢 云云
然而這個東西是 2.x 時代的，Google 早就改掉了……我也不知道這種 Unix 內核性能優於 Linux 的論調為什麼時不時還會冒出來……反正兩者都不是實時作業系統（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 可以直接調用底層效率更高就對了。
四、應用方面
（1）QQ，節奏大師，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
發現什麼問題了沒有？引入黃油計劃的 Android 版本是 4.1，所以 60fps……
然後 QQ 和節奏大師你們這還抱著凍酸奶的態度令我感動……以及瀏覽器們都和薑餅曖昧不清……唉，連GPU加速都……
然後如果打開開發者選項裡面的 show GPU overdraw（雖然不一定是 GPU 繪製的），你們就會發現各種嚴重的 overdraw，尤其是阿里巴巴系列的應用，整個頁面濫用 Webview，導致了嚴重的重複繪製。
BAT 經常大量使用自製控制項進一步加劇了對資源的使用。
假如有第三方客戶端的話，其實往往有非常優秀的遵守 Design Guideline 的應用，比如新浪微博的第三方客戶端們，四次元，Fuubo，Smooth等等。
五、優化
很不幸的是，到現在，兩個平台都仍然有大量的應用跑在單核單線程上，對雙核，多核以及 64 位的利用非常之低，甚至沒有。這個時候 A8 較高的單核性能能帶來更好的體驗。但如果應用對多核做好了適配的話，在 Android 上流暢性是可以花樣吊打 iOS 的。（看清楚了沒有？現在安卓應用對多核心優化很爛，64位根本沒好好利用，ios出現64位，安卓已經亂了陣腳）
六、ROM
1、iOS 並不存在這個問題，不講。
2、Android 存在的問題是，有太多廠商太多版本的 ROM 了，每個廠商都對底層做些修改。所以簡而言之就是鬧心，負分優化大家見得多了我就不說了。
PS：知道為什麼國內定製越深度的 ROM 適配 Android L 越慢嗎？就是因為底層的東西改得太多 5.0 把運行時改了工程量很大難以在保證功能健全的情況下快速適配。
總之，對比下來我們會發現，兩種生態在健康的情況下其實軟硬技術實力都是處在同一水平線上的，互有長短。硬體 Apple 並沒有弱於 Android，更談不上軟體的神優化。但是，如果 Android 沒有 Google Services，就相當於失去了 Android 的靈魂，失去了 Google Play 的優秀資源，失去了 GCM 推送帶來的流暢省電，失去了 Google Cloud 在內的很多很多核心競爭力。Android 不卡，安卓會卡，本質不是系統的問題，而是什麼樣的環境，用戶著什麼樣的程序。