為什麼安卓沒IOS快——iOS和安卓技術角度的深度對比

標籤：android   style   color   io   os   ar   使用   java   for   

首先說明一下，這裡面的解釋並非我自己寫的，而是我找到相關資料整理出來的，也算是為罈子做出點貢獻，文末也分析了Google三個兒子和三星 i9100，希望這篇文章能在技術層面上提供一個科學的評判 android 和 ios。 如果能解決大家心中的困惑的話， 不妨給小弟加幾分， 在此先謝謝大家了。 Andorid 更新了一個版本又一個版本，硬體從單核到雙核到四核，系統流暢度總算基本能和 iOS 持平了。

不過人們不禁會問，為什麼都是基於 Linux， 兩個系統會差別如此大？為什麼 iPhone 4 用單核處理器就能實現的流暢度，Android 要高端雙核才能保證？

近日，Android 開發小組工程師 Dianne Hackborn 算是半官方回答了其中的一個緣由。 Dianne Hackborn 表示，從介面 UI 本身的渲染而言，

首先，Android 從第一個版本就有使用圖形硬體加速，例如通知欄拖拉，對話方塊的顯示和切換等等。只不過在 3.0 之前的版本都不是採用完整的圖形硬體加速。由於 Android 不是一個統一平台，各終端存在硬體差異，系統會自動調節動畫的幀數。 一個典型的例子就是， Nexus S 可以實現 到 60fps 的渲染，所以會足夠流暢。但使用同樣解析度的裡程碑，由於硬體(GPU)效能問題，它就無法提供足夠的幀數來保證流暢了。這樣，它的介面渲染幀數要低於 60 幀，我們使用起來就會偶爾感覺到 “卡”。 而且，即使為 UI 開啟硬體加速，OpenGL 技術帶來的記憶體開銷會十分大，比如 PowerVR 的圖形晶片，此時要消耗掉 8MB 記憶體，而 UI 程式本身都只要 2MB 記憶體，這太划不來了。所以，為了保證不同機型順利運作，很多時候 Android 會採用 CPU 繪圖運算代替硬體加速——注意，CPU 還要幹別的事情， 讓 CPU 來繪圖只會拖慢速度。 在 Android 4.0 之前的版本，硬體加速是作為一個可選擇的參數而存在（考慮到部分 APP 不支援） 。但從 4.0 開始，這個選項將會被預設啟用，開發小組已針對進行最佳化，即使不支援硬體加速程式運行也不會出現問題。 Dianne Hackborn 最後表示，硬體加速不是提升流暢度的唯一手段。事實上 Android 開發小組已經使用很多技術例如改進渲染技術來提升流暢度，典型的例子就是 Android 3.0 的瀏覽器相比 2.2 有巨大進步。而隨著 4.0 鋪開，更多使用者可以感受到這點。 Dianne Hackborn 沒有評價 iOS 是如何達到流暢的。不過大家注意， 從 iPhone 3GS 開始，每一代 iPhone 的圖形晶片（GPU）都相當強大 （iPhone 3GS、iPhone 4、iPhone 4S 的圖形處理晶片均為同代手機最高水平） ，而且蘋果 iOS 是封閉系統，我們猜測，蘋果在這一方面並 沒有碰到 Android 那麼多煩心事兒。 蘋果 A5 處理器整合的 PowerVR SGX543MP2 圖形處理器效能相當強 大，幾乎秒殺了 Android 陣營各類對手而另一位軟體工程師和前 Google 實習生 Andrew Munn 解釋說是因為 Android 系統 UI 的架構設計的問題。 在 iOS 中 UI 渲染過程具有絕對的優先等級， 當使用者接觸到 iPhone 的 觸控螢幕後，iOS 中所有的進程都將停止，系統會將所有資源用於渲染 UI 過程。 而在 Android 系統中 UI 渲染過程的優先順序別卻沒有那麼高， 也就是說當你觸摸 Android 手機螢幕的時候，系統背景程式並沒有停止，仍然在繼續運行之中，比如下載和查收簡訊，這樣系統 UI 獲得的資源就不夠，這就是 Android 系統不流暢的原因。 由於這個原因，新發布的 Galaxy Nexus，甚至配備四核處理器的話說 EeePad Transformer Prime 平板電腦都無法保證順滑的操作體驗， 這些裝置只能與 3 年前的 iPhone 順滑程度相比， 那麼 Android 團隊為什麼不從根本解決這個問題呢? 實際上， Android 的開發工作在第一代 iPhone 發布之前就已經開始了， 原始 Android 原型體被設計成為使用鍵盤手機的裝置，也就是黑莓手機的競爭者。UI 渲染優先順序別在有鍵盤的手機上並沒有那麼重要。但是在 iPhone 發布之後，Android 小組為了快速推出能與 iPhone 競爭的產品， 迅速將 Android 改成觸控螢幕手機系統，但那時重寫 使用者介面架構已經不可能了。因為如果這樣 Android 應用市場中的所有程式將 變得不可用，這種關係將一直處於惡性迴圈之中。難怪喬布斯在傳記中表示 Android 是偷來的產品，哪怕蘋果傾家蕩產也要將其消滅。 自蘋果收購了喬布斯的 NeXT 之後， 花了六年把它打磨成了 Mac OS X; 又在 2005 年左右花了兩年半時間，基於它製造了 iOS。從各種意義上來說， 是一個傳統技術的作業系統。 iOS 它有一個基於微核心 Mach 的 Darwin 內 核 ， 有一個 叫做 Cocoa Touch 的運行時 ， 用的是 Objective-C 這個 C 語言的超集。而 Android 在 Linux 核心之上，整合 了一個 JAVA 虛擬機器 Dalvik，整個應用程式層跑在虛擬機器之上，而開發語言用的是 Java。 事實上雙方的選擇都是很有道理的。蘋果有 Mac OS X 十年基礎，當然會選擇自己最精通的技術， iOS 打造成一個傳統系統，也可以無把縫連結 Mac OS X 的開發人員資源。而Google沒有任何作業系統經驗，為了要爭取最大的開發人員資源，他們選擇了世界上最大的 Java 社區。 雖然起點相同，但走出的第一步方向就已經截然相反。 究其根底，只在於 Java 只有自動記憶體回收，而 Objective-C 自動與手動記憶體回收均可(注意 iOS 只有手動記憶體回收)。這小小的區別導致， Google只能做一個 JAVA 虛擬機器，而蘋果可以繼續他們在 Mac OS X 上的經驗。而這個行為導致了兩者在系統流暢性上的最大區別。Java 由於只有自動記憶體回收， 系統會在任意時間停掉所有進程開始回收記憶體，這個過程是人類可以感受到的數百毫秒。而 iOS 由於可以手動管理記憶體，可以在使用者操作的間歇由程式員進行回收，使用者不會在頻繁使用過程中感受到停頓。 在日常使用中這個停 頓其實是可以忍的， 但是在遊戲過程中這個停頓是不可以忍的， 比如想像一下一隻憤怒的小鳥在空中停頓了零點幾秒再繼續飛行。 Google事實上意識到了這個問題，於是它在 Android 2.3 版本中大修了這個問題並將之作為一個特性大書特書。且拋開 2.3 的普及性不談， 單說這個大修的行為，也並沒有修好這個問題。於是Google拋出了第二個在開發上的修補： 引入 C/C++ NDK。 可以說到了這一步， Android 整個核心往上的應用程式層才有了與 iOS 抗衡的實力， 可惜時間已經過去了近四年，iOS 積累了十五年，Android 剛剛起步。 而在核心之下呢?基於微核心 Mach 的 Darwin 對比當今伺服器主流 Linux 又如何?當年 Linux 創始人曾經與某位牛人吵過一場著名的架， 正是關於微核心與核心對比， Linus 一直到現在都認為微核心只是紙上談兵而在現實中解決不了實際問題。在這場吵架之後的歲月，堅持 核心的主流系統只剩下 Linux 一家， 而微核心系統已經延展到了基於 SVR4 的 IBM AIX/HP-UX， GNU/Hurd， Mac OS X， Blackberry QNX， Windows(是的，你沒有看錯)。Time will tell，這句話從來都沒有錯。 Android 三方 ROM 所困擾的驅動問題，正是 Linux 核心的最大局限， 植根於骨子的病是治不好的。

 

 

 

下面是第三位Google內部工程師的關於 Android 圖形系統的一些觀點。

1. Android 一直在使用硬體加速。實際上從 1.0 版本之後，所有的視窗元素的合成與顯示都是通過硬體完成的。

2.這意味著許多你所看見的動畫都是被加速過的：按鈕的顯示、通知 欄下拉的陰影、不同 Activity 之間的切換動畫、快顯視窗以及提示框 的顯示和隱藏等等等等。

3.Android 以前使用軟體方式(與硬體加速相對應)來控制各個視窗元素的渲染，例如的 UI，其中包括四個視窗組件：狀態條、壁紙、 案頭上的的啟 動器、以及菜單。如果其中一個元素更改了自身的內 容，例如高亮一個菜單條目，對於 3.0 之前的版本，系統使用軟體方式來繪製新的內容，然而並非所有的元素都需要被重新繪製，同時各個視窗元素的拼接也是通過硬體方式完成的。類似的，任何視窗的移動：例如菜單的上下運動是完全通過硬體方式渲染的。

4. 現在我們來關注視窗元素的內部渲染，實際上為了達到每秒 60 幀 的 FPS,你並不一定需要硬體加速。幀速取決於要顯示的像素的數量 以及 CPU 的速度。比如說，二兒子完全可以以 60FPS 的速度在它 800*480 解析度的螢幕上完成任何普通的原生 UI 動畫，例如列表的滾動等， 完全沒有問題。 而最初的 Droid 系列卻很難達到這樣的速度。

5.在 Android3.0 中可以實現視窗的”完全”的硬體加速繪製。而在 Android 4.0 中也沒有引入更多的功能。 從 3.0 開始，如果在你的應 用中設定了一個標誌允許硬體加速， 那麼此時所有的視窗的繪製都會 交給 GPU 來完成。在 Android 4.0 中最主要的改變就是：在面向 Android4.0 或更高版本的應用中，硬體加速是被預設開啟的，再也不需要在設定檔中設定 android:handwareAccelerated=”true”.(而我們 不允許之前的應用預設開啟硬體加速，是因為光靠硬體加速，無法很 好的完 成某些特殊的繪製操作； 同時在應用需要其中一部分 UI 更新 的時候，會影響其的一些表現。對於目前現有的很多應用，強制開啟硬體加速，會明顯的中斷應用的運行)

6.硬體加速並不如大家所認為的那樣完美。例如在基於 PVR 驅動的裝置上(比如二兒子跟三兒子)，光是在進程中開啟 OpenGL 就得佔用 8M 的 RAM。 比一般進程的 2M 的開銷實在是巨大。 對 RAM 是有限的，一大部分被拿去繪製，那麼其他正在啟動並執行進程就會因為缺少內 存而出問題，比如降低應用間切換的速度。

7.由於 OpenGL 的額外開銷，我們最好不要過多的使用其進行繪製。 比如我們現在在做的一些工作，就是為了讓 Android 4.0 能在不使用 硬體加速的情況下流暢的在二兒子上使用： 這樣我們就不需要在系統進程中浪費 8MB 的記憶體用，也不需要在手機進程中浪費額外的 8M 記憶體，或 者是在系統 UI 進程中的 8MB 記憶體等等等等。相信我，你不會注意到用 OpenGL 來繪製一些類似狀態列或是華麗的動畫是完全沒有好處的。

8.硬體加速並非流暢 UI 的“解藥”。我們為了 UI 的流暢嘗試了很多不同的方法，比如說在 1.6 中引入的對前台/後台進程的調度策略，在 2.3 中的對輸入系統的重寫，”嚴厲模式”的使用，並發的記憶體回收機制，載入器等等。如果你想達到 60fps 的幀速，你只有 20 毫秒的時間來處理每幀的內容。這時間實在不長，光是在 UI 進程中讀取儲存卡的操作產生的延時就會大於這個時限，尤其是在寫操作的時候。

9.舉些最近發現的一些影響 UI 流暢度的例子：我們注意到在二兒子上，使用 4.0 時列表的滾動就不如使用 2.3 時流暢。而導致這個現象的原因則是計時器的輕微漂移：有些時候應用正在接收觸摸事件並在螢幕上繪製，而在上一個動作還沒完成的的時候，就接受到下一個事件並開始繪製，導致它丟失了當前這幀。儘管發生這種現象的時候，幀速能達到穩定的 60FPS.(當然，這個問題已經修正)

10.當人們比較 Android 跟 IOS 上瀏覽器的滾動流暢度的時候，他們 所看見的差別並非開沒開啟硬體加速所導致。 最初的時候，Android 使用了一種完全不同的渲染策略，並做了一些折中：網頁被轉換成一 個“顯示列表”， 持續的在螢幕上進行繪製， 而非使用塊 (Tiles)的形式。 它有一個優點： 就是在滾動或是縮放的時候不會發生有的塊還沒被渲 染出來的現象(譯者註：早期的 IOS 上這種現象非常明顯，快速滾動 到底部時要等一會網頁才會一塊一塊的繪製出來)。 而這個方法的不 給力之處就在於頁面複雜的時候， 幀速就明顯低了。 例如 Android3.0， 瀏覽器中現在開始使用塊的方式進行渲染，於是它可以在滾動或是 放大的時候保持一個穩定的幀速， 自然也會出現新的塊沒有被立即渲 染出來的情況。 而每個塊都是以軟體方式繪製的，我相信在 IOS 中 也是這樣的。(在 3.0 之前的版本中，沒有開啟硬體加速，基於塊的策略也可以使用。而且如我之前提到的， 二兒子可以很容易的達到 60FPS)

11.硬體加速不能如大家所想奇蹟般的讓繪製的問題統統消失。GPU 的效能就是一個很重要的限制。最近一個很有趣的例子：基於英偉達 的 Tegra2 的平板 可以很容易的以 60FPS 的速度訪問 2.5 次 1280*800 解析度的螢幕中的任何一個像素。現在考慮到在 Android 3.0 中切換 到所有應用列表的情形：你需要繪製背景(1x 所有的像素)、接著是 捷徑和案頭小工具(假設內容不多，花費 0.5x)，接著是所有應用 的黑色背景(1x)，接著是所有應用的 ICON(0.5x)。 顯然，我們已經 超過了原先的預算了， 而此時我們還沒完成各個獨立視窗元素的拼接 並做最後的顯示。想要取得 60FPS 的動畫，Android 3.0 以及後續版 本使用了一系列的小技巧。 其中主要的一個就是： 它將所有的視窗 元素平鋪在一個層中，而不是挨個拷貝到 CPU 的緩衝中。但即使是 這樣，我們已然超出預算，幸好我們使用另一個技巧：因為 Android 中的背景是一個獨立的視窗元素，我們可以將它設定的比螢幕更大來放置整幅位元影像，現在，使用者開始滑動，背景跟著運動，此時並不需要任何特殊的繪製，僅僅是移動窗 口即可，而由於這個視窗是在一 個平鋪層上，我們甚至不需要用 GPU 來將這個視窗元素組織到螢幕 中輸出。

12.隨著螢幕解析度的不斷升高， 能否達到 60FPS 跟 GPU 的速度尤其是記憶體匯流排頻寬息息相關。事實上，如果你想要提升硬體的效力，特別注意要提升記憶體匯流排的頻寬。很多時候 CPU(特別是帶有完美的 NEON 指令集的 CPU)會比記憶體匯流排塊的多。 有些人認為蓋世兔已經有了一個非常流暢的 UI 並指出他們已經超越 三兒子並做了很多改進。事實上，大家忽略了很多裝置的差異，蓋世 兔的螢幕是 480*800 而三兒子是 720*1280。 如果二兒子在它 480*800 的螢幕上都能達到 60FPS，擁有更 NB 的 CPU 的蓋世兔必須得同樣流暢嘛。 而兩者之間最大的差別就是三兒子需要同時繪製 2.4 倍於蓋世兔的像素。 這相當於在單核上提升到 2.4 倍的速度。 (需要指出在 UI 渲染的時候，多核是沒有意義的，因為渲染必須要在一個進程中完成，無法並行) 這就是為什麼硬體加速非常重要：隨著像素的提升，GPU 通常能更好的處理映像的運算。事實上，這是我們在 Android 中引入硬體加速 的最大動力。在 720*1280 的螢幕上，現有的 ARM CPU 達到 60FPS 很吃力，但是通過 GPU 渲染就不同了。同樣，在與蓋世兔的比較中， 同時開啟沒有硬體加速的應用，在三兒子中無法達到蓋世兔同樣的 60FPS，是因為它得渲染 2.4 倍於蓋世兔的像素。 在最後，還得提及 GPU 的另外一個優勢：許多繪製的效果變得更加 容易。比如你要以軟體形式繪製一個位元影像，你除了設定一個位移，不能做任何事。 僅僅是縮小就 得花上相當多的時間進行渲染。 而在 GPU 中，此類轉換則相當容易。這就是為神馬新的預設主題 Holo 使用硬體加速繪製背景。而在沒有開啟硬體加速的應用中，此類背景會自動去掉~

為什麼安卓沒IOS快——iOS和安卓技術角度的深度對比