iOS響應順序是優先響應顯示任務，後響應實際操作，所以會感覺觸控以後的響應非常快。Android是先響應操作的，顯示任務會在操作處理完成後顯示出來，會多少有些延遲。不過現在Android已經處理得和iOS十分接近了，當然是指新機，使用一段時間後還是iOS的流暢性更高一些，因為iOS的設計對移動裝置更友好，長時間使用也不會產生過多的垃圾來阻礙系統執行。

先說答案:即使是同樣的功能(包括廣告啊通知訊息等等)旗艦Android會比同時期旗艦iOS要慢，那到底要慢多少呢？emmmm……大部分情況下你感受不到的。

你要問那旗艦機對普通機呢？對前一代機型呢？這我就不知道了……下面說原因

原因: Android是使用位元組碼寫App，iOS是使用機器碼寫App。就好像Android是用筷子夾著勺子在吃東西，而iOS是直接用勺子吃東西，效率你說哪個高嘛。

當然實際差別在谷歌大量優秀工程師的最佳化下沒有那麼大，而且以現在裝置的效能你甚至可能感受不到差別。畢竟現在一個App很少會需要一臺裝置全效能執行，這也是為什麼有些App你感受不到執行在兩種裝置上的區別。

看到這裡你可能覺得我是一名果粉，但實際上我是Android開發人員。

光說沒幹貨那就是吹牛逼，下面是乾貨。

今年最新的Android版本已經是10了，其實在這兩年關於Android手機卡頓的聲音已經慢慢低了下去，取而代之的是流暢如iOS之類的聲音。但是諸如超過iOS的話，還比較少，其實是因為Android有卡頓有三大歷史原因。起步就比iOS低。

1.虛擬機器——解釋過程慢

iOS之所以不卡是因為他一步到位，省略了中間解釋的步驟，直接跟硬體層進行通訊。而Android由於沒有一步到位，每次執行都需要實時解釋成機器碼，所以效能較iOS明顯低下。

位元組碼（中間商）是造成卡頓的主要元兇之一，Android可否像iOS那樣扔掉位元組碼，直接一步到位呢？

明顯不能，因為iOS搞來搞去就那麼幾個機型。

反觀Android方面，光手機就有無數種機型，無數種CPU架構/型號，更別提什麼平板，車載等其他裝置了。有那麼多型別的硬體裝置代表著就有非常多不同的硬體架構，每種架構都有自己對應的機器碼解釋規則。顯然像iOS那樣一步到位是不現實的。

2.JNI——Java和C互相呼叫慢

JNI又稱為 Java Native Interface，翻譯過來就是Java原生介面，就是用來跟C/C++程式碼互動的。

如果不做Android開發的可能不知道，Android專案裡的程式碼除了Java,很有可能還有部分C語言的程式碼。

這個時候有個嚴重的問題，在開發階段Java原始碼在開發階段打包成.dex檔案，C語言直接就是.so庫，因為C語言本身就是編譯語言。

在使用者手機中，APK中的.dex檔案（位元組碼）會被解釋為.oat檔案（機器碼）執行在ART虛擬機器中，.so庫則為計算機可以直接執行的二進位制程式碼（機器碼），兩份機器碼要互相呼叫肯定是有開銷的。

（此處參考知乎@張鐸在華為公佈的方舟編譯器到底對安卓軟體生態會有多大影響？中的回答）

3. 位元組碼的編譯模板——未針對具體APP進行最佳化

位元組碼可以透過不同的編譯模版被編譯為機器碼，而編譯模版的不同將直接導致編譯完後的機器碼效能大相徑庭。

在安卓中，ART有一套規定的，統一的編譯模版，暫且稱為VM模版，這套模版雖算不上差勁，但也算不上優秀。

因為它是谷歌爸爸搞出來的，肯定算不上差勁，但由於沒有針對每一個APP進行特定的最佳化，所以也算不上優秀。(參考百度Android大神鴻洋“9102年了，還不知道Android為什麼卡？”)