iOS CPU VS GPU

   關於繪圖和動畫有兩種處理的方式：CPU（中央處理器）和GPU（圖形處理器）。在現代iOS裝置中，都有可以執行不同軟體的可程式設計晶片，但是由於歷史原因，我們可以說CPU所做的工作都在軟體層面，而GPU在硬體層面。

    總的來說，我們可以用軟體（使用CPU）做任何事情，但是對於影象處理，通常用硬體會更快，因為GPU使用影象對高度並行浮點運算做了優化。由於某些原因，我們想盡可能把螢幕渲染的工作交給硬體去處理。問題在於GPU並沒有無限制處理效能，而且一旦資源用完的話，效能就會開始下降了（即使CPU並沒有完全佔用）

    大多數動畫效能優化都是關於智慧利用GPU和CPU，使得它們都不會超出負荷。於是我們首先需要知道Core Animation是如何在這兩個處理器之間分配工作的。

動畫的舞臺

    Core Animation處在iOS的核心地位：應用內和應用間都會用到它。一個簡單的動畫可能同步顯示多個app的內容，例如當在iPad上多個程式之間使用手勢切換，會使得多個程式同時顯示在螢幕上。在一個特定的應用中用程式碼實現它是沒有意義的，因為在iOS中不可能實現這種效果（App都是被沙箱管理，不能訪問別的檢視）。

    動畫和螢幕上組合的圖層實際上被一個單獨的程式管理，而不是你的應用程式。這個程式就是所謂的渲染服務。在iOS5和之前的版本是SpringBoard程式（同時管理著iOS的主屏）。在iOS6之後的版本中叫做BackBoard。

    當執行一段動畫時候，這個過程會被四個分離的階段被打破：

• 佈局 - 這是準備你的檢視/圖層的層級關係，以及設定圖層屬性（位置，背景色，邊框等等）的階段。

• 顯示 - 這是圖層的寄宿圖片被繪製的階段。繪製有可能涉及你的-drawRect:和-drawLayer:inContext:方法的呼叫路徑。

• 準備 - 這是Core Animation準備傳送動畫資料到渲染服務的階段。這同時也是Core Animation將要執行一些別的事務例如解碼動畫過程中將要顯示的圖片的時間點。

• 提交 - 這是最後的階段，Core Animation打包所有圖層和動畫屬性，然後通過IPC（內部處理通訊）傳送到渲染服務進行顯示。

    但是這些僅僅階段僅僅發生在你的應用程式之內，在動畫在螢幕上顯示之前仍然有更多的工作。一旦打包的圖層和動畫到達渲染服務程式，他們會被反序列化來形成另一個叫做渲染樹的圖層樹（在第一章“圖層樹”中提到過）。使用這個樹狀結構，渲染服務對動畫的每一幀做出如下工作：

• 對所有的圖層屬性計算中間值，設定OpenGL幾何形狀（紋理化的三角形）來執行渲染

• 在螢幕上渲染可見的三角形

    所以一共有六個階段；最後兩個階段在動畫過程中不停地重複。前五個階段都在軟體層面處理（通過CPU），只有最後一個被GPU執行。而且，你真正只能控制前兩個階段：佈局和顯示。Core Animation框架在內部處理剩下的事務，你也控制不了它。

    這並不是個問題，因為在佈局和顯示階段，你可以決定哪些由CPU執行，哪些交給GPU去做。那麼改如何判斷呢？

GPU相關的操作

    GPU為一個具體的任務做了優化：它用來採集圖片和形狀（三角形），執行變換，應用紋理和混合然後把它們輸送到螢幕上。現代iOS裝置上可程式設計的GPU在這些操作的執行上又很大的靈活性，但是Core Animation並沒有暴露出直接的介面。除非你想繞開Core Animation並編寫你自己的OpenGL著色器，從根本上解決硬體加速的問題，那麼剩下的所有都還是需要在CPU的軟體層面上完成。

    寬泛的說，大多數CALayer的屬性都是用GPU來繪製。比如如果你設定圖層背景或者邊框的顏色，那麼這些可以通過著色的三角板實時繪製出來。如果對一個contents屬性設定一張圖片，然後裁剪它 - 它就會被紋理的三角形繪製出來，而不需要軟體層面做任何繪製。

    但是有一些事情會降低（基於GPU）圖層繪製，比如：

• 太多的幾何結構 - 這發生在需要太多的三角板來做變換，以應對處理器的柵格化的時候。現代iOS裝置的圖形晶片可以處理幾百萬個三角板，所以在Core Animation中幾何結構並不是GPU的瓶頸所在。但由於圖層在顯示之前通過IPC傳送到渲染伺服器的時候（圖層實際上是由很多小物體組成的特別重量級的物件），太多的圖層就會引起CPU的瓶頸。這就限制了一次展示的圖層個數（見本章後續“CPU相關操作”）。

• 重繪 - 主要由重疊的半透明圖層引起。GPU的填充比率（用顏色填充畫素的比率）是有限的，所以需要避免重繪（每一幀用相同的畫素填充多次）的發生。在現代iOS裝置上，GPU都會應對重繪；即使是iPhone 3GS都可以處理高達2.5的重繪比率，並任然保持60幀率的渲染（這意味著你可以繪製一個半的整屏的冗餘資訊，而不影響效能），並且新裝置可以處理更多。

• 離屏繪製 - 這發生在當不能直接在螢幕上繪製，並且必須繪製到離屏圖片的上下文中的時候。離屏繪製發生在基於CPU或者是GPU的渲染，或者是為離屏圖片分配額外記憶體，以及切換繪製上下文，這些都會降低GPU效能。對於特定圖層效果的使用，比如圓角，圖層遮罩，陰影或者是圖層光柵化都會強制Core Animation提前渲染圖層的離屏繪製。但這不意味著你需要避免使用這些效果，只是要明白這會帶來效能的負面影響。

• 過大的圖片 - 如果檢視繪製超出GPU支援的2048x2048或者4096x4096尺寸的紋理，就必須要用CPU在圖層每次顯示之前對圖片預處理，同樣也會降低效能。

CPU相關的操作

    大多數工作在Core Animation的CPU都發生在動畫開始之前。這意味著它不會影響到幀率，所以很好，但是他會延遲動畫開始的時間，讓你的介面看起來會比較遲鈍。

    以下CPU的操作都會延遲動畫的開始時間：

• 佈局計算 - 如果你的檢視層級過於複雜，當檢視呈現或者修改的時候，計算圖層幀率就會消耗一部分時間。特別是使用iOS6的自動佈局機制尤為明顯，它應該是比老版的自動調整邏輯加強了CPU的工作。

• 檢視懶載入 - iOS只會當檢視控制器的檢視顯示到螢幕上時才會載入它。這對記憶體使用和程式啟動時間很有好處，但是當呈現到螢幕上之前，按下按鈕導致的許多工作都會不能被及時響應。比如控制器從資料庫中獲取資料，或者檢視從一個nib檔案中載入，或者涉及IO的圖片顯示（見後續“IO相關操作”），都會比CPU正常操作慢得多。

  +

• Core Graphics繪製 - 如果對檢視實現了-drawRect:方法，或者CALayerDelegate的-drawLayer:inContext:方法，那麼在繪製任何東西之前都會產生一個巨大的效能開銷。為了支援對圖層內容的任意繪製，Core Animation必須建立一個記憶體中等大小的寄宿圖片。然後一旦繪製結束之後，必須把圖片資料通過IPC傳到渲染伺服器。在此基礎上，Core Graphics繪製就會變得十分緩慢，所以在一個對效能十分挑剔的場景下這樣做十分不好。

• 解壓圖片 - PNG或者JPEG壓縮之後的圖片檔案會比同質量的點陣圖小得多。但是在圖片繪製到螢幕上之前，必須把它擴充套件成完整的未解壓的尺寸（通常等同於圖片寬 x 長 x 4個位元組）。為了節省記憶體，iOS通常直到真正繪製的時候才去解碼圖片（14章“圖片IO”會更詳細討論）。根據你載入圖片的方式，第一次對圖層內容賦值的時候（直接或者間接使用UIImageView）或者把它繪製到Core Graphics中，都需要對它解壓，這樣的話，對於一個較大的圖片，都會佔用一定的時間。

    當圖層被成功打包，傳送到渲染伺服器之後，CPU仍然要做如下工作：為了顯示螢幕上的圖層，Core Animation必須對渲染樹種的每個可見圖層通過OpenGL迴圈轉換成紋理三角板。由於GPU並不知曉Core Animation圖層的任何結構，所以必須要由CPU做這些事情。這裡CPU涉及的工作和圖層個數成正比，所以如果在你的層級關係中有太多的圖層，就會導致CPU沒一幀的渲染，即使這些事情不是你的應用程式可控的。

IO相關操作

    還有一項沒涉及的就是IO相關工作。上下文中的IO（輸入/輸出）指的是例如快閃記憶體或者網路介面的硬體訪問。一些動畫可能需要從山村（甚至是遠端URL）來載入。一個典型的例子就是兩個檢視控制器之間的過渡效果，這就需要從一個nib檔案或者是它的內容中懶載入，或者一個旋轉的圖片，可能在記憶體中尺寸太大，需要動態滾動來載入。

    IO比記憶體訪問更慢，所以如果動畫涉及到IO，就是一個大問題。總的來說，這就需要使用聰敏但尷尬的技術，也就是多執行緒，快取和投機載入（提前載入當前不需要的資源，但是之後可能需要用到）。這些技術將會在第14章中討論。