視圖渲染、CPU和GPU卡頓原因及其優化方案

視圖渲染過程：

1、CPU 計算好顯示內容提交到 GPU

2、GPU 渲染完成後將渲染結果放入幀緩衝區

3、視頻控制器會按照 VSync 信號逐行讀取幀緩衝區的數據，經過可能的數模轉換傳遞給顯示器顯示

在最簡單的情況下，幀緩衝區只有一個，這時幀緩衝區的讀取和刷新都都會有比較大的效率問題。為了解決效率問題，顯示系統通常會引入兩個緩衝區，即雙緩衝機制。在這種情況下，GPU 會預先渲染好一幀放入一個緩衝區內，讓視頻控制器讀取，當下一幀渲染好後，GPU 會直接把視頻控制器的指針指向第二個緩衝器。如此一來效率會有很大的提升。

為了解決這個問題，GPU 通常有一個機制叫做垂直同步（簡寫也是 V-Sync），當開啟垂直同步後，GPU 會等待顯示器的 VSync 信號發出後，才進行新的一幀渲染和緩衝區更新。這樣能解決畫面撕裂現象，也增加了畫面流暢度，但需要消費更多的計算資源，也會帶來部分延遲。

那麼目前主流的移動設備是什麼情況呢？從網上查到的資料可以知道，iOS 設備會始終使用雙緩存，並開啟垂直同步。而安卓設備直到 4.1 版本，Google 才開始引入這種機制，目前安卓系統是三緩存+垂直同步。

卡頓產生的原因

在 VSync 信號到來後，系統圖形服務會通過 CADisplayLink 等機制通知 App，App 主線程開始在 CPU 中計算顯示內容，比如視圖的創建、布局計算、圖片解碼、文本繪製等。隨後 CPU 會將計算好的內容提交到 GPU 去，由 GPU 進行變換、合成、渲染。隨後 GPU 會把渲染結果提交到幀緩衝區去，等待下一次 VSync 信號到來時顯示到屏幕上。由於垂直同步的機制，如果在一個 VSync 時間內，CPU 或者 GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留之前的內容不變。這就是界面卡頓的原因。

從上面的圖中可以看到，CPU 和 GPU 不論哪個阻礙了顯示流程，都會造成掉幀現象。所以開發時，也需要分別對 CPU 和 GPU 壓力進行評估和優化。

CPU和GPU卡頓原因、優化方案：

一、CPU

1、對象操作

1)、對象創建

對象的創建會分配內存、調整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對象代替重量的對象，可以對性能有所優化。比如 CALayer 比 UIView 要輕量許多，那麼不需要響應觸摸事件的控制項，用 CALayer 顯示會更加合適。如果對象不涉及 UI 操作，則盡量放到後台線程去創建，但可惜的是包含有 CALayer 的控制項，都只能在主線程創建和操作。通過 Storyboard 創建視圖對象時，其資源消耗會比直接通過代碼創建對象要大非常多，在性能敏感的界面里，Storyboard 並不是一個好的技術選擇。

盡量推遲對象創建的時間，並把對象的創建分散到多個任務中去。儘管這實現起來比較麻煩，並且帶來的優勢並不多，但如果有能力做，還是要盡量嘗試一下。如果對象可以復用，並且復用的代價比釋放、創建新對象要小，那麼這類對象應當盡量放到一個緩存池裡復用。

2)、對象調整

對象的調整也經常是消耗 CPU 資源的地方。這裡特別說一下 CALayer：CALayer 內部並沒有屬性，當調用屬性方法時，它內部是通過運行時 resolveInstanceMethod 為對象臨時添加一個方法，並把對應屬性值保存到內部的一個 Dictionary 里，同時還會通知 delegate、創建動畫等等，非常消耗資源。UIView 的關於顯示相關的屬性（比如 frame/bounds/transform）等實際上都是 CALayer 屬性映射來的，所以對 UIView 的這些屬性進行調整時，消耗的資源要遠大於一般的屬性。對此你在應用中，應該盡量減少不必要的屬性修改。

當視圖層次調整時，UIView、CALayer 之間會出現很多方法調用與通知，所以在優化性能時，應該盡量避免調整視圖層次、添加和移除視圖。

3）、對象銷毀

對象的銷毀雖然消耗資源不多，但累積起來也是不容忽視的。通常當容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。同樣的，如果對象可以放到後台線程去釋放，那就挪到後台線程去。這裡有個小 Tip：把對象捕獲到 block 中，然後扔到後台隊列去隨便發送個消息以避免編譯器警告，就可以讓對象在後台線程銷毀了。

2、排版

1）、布局計算

視圖布局的計算是 App 中最為常見的消耗 CPU 資源的地方。如果能在後台線程提前計算好視圖布局、並且對視圖布局進行緩存，那麼這個地方基本就不會產生性能問題了。

不論通過何種技術對視圖進行布局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調整上。上面也說過，對這些屬性的調整非常消耗資源，所以盡量提前計算好布局，在需要時一次性調整好對應屬性，而不要多次、頻繁的計算和調整這些屬性。

2）、Autolayout

Autolayout 是蘋果本身提倡的技術，在大部分情況下也能很好的提升開發效率，但是 Autolayout 對於複雜視圖來說常常會產生嚴重的性能問題。隨著視圖數量的增長，Autolayout 帶來的 CPU 消耗會呈指數級上升。具體數據可以看這個文章：http://pilky.me/36/。 如果你不想手動調整 frame 等屬性，你可以用一些工具方法替代（比如常見的 left/right/top/bottom/width/height 快捷屬性），或者使用 ComponentKit、AsyncDisplayKit 等框架。

3）、文本計算

如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會佔用很大一部分資源，並且不可避免。

如果你對文本顯示沒有特殊要求，可以參考下 UILabel 內部的實現方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪製文本。儘管這兩個方法性能不錯，但仍舊需要放到後台線程進行以避免阻塞主線程。

如果你用 CoreText 繪製文本，那就可以先生成 CoreText 排版對象，然後自己計算了，並且 CoreText 對象還能保留以供稍後繪製使用。

4）、太多的layer或者幾何形狀

3、繪製

1）、文本繪製

屏幕上能看到的所有文本內容控制項，包括 UIWebView，在底層都是通過 CoreText 排版、繪製為 Bitmap 顯示的。常見的文本控制項 （UILabel、UITextView 等），其排版和繪製都是在主線程進行的，當顯示大量文本時，CPU 的壓力會非常大。對此解決方案只有一個，那就是自定義文本控制項，用 TextKit 或最底層的 CoreText 對文本非同步繪製。儘管這實現起來非常麻煩，但其帶來的優勢也非常大，CoreText 對象創建好後，能直接獲取文本的寬高等信息，避免了多次計算（調整 UILabel 大小時算一遍、UILabel 繪製時內部再算一遍）；CoreText 對象佔用內存較少，可以緩存下來以備稍後多次渲染。

2）、圖片的解碼

當你用 UIImage 或 CGImageSource 的那幾個方法創建圖片時，圖片數據並不會立刻解碼。圖片設置到 UIImageView 或者 CALayer.contents 中去，並且 CALayer 被提交到 GPU 前，CGImage 中的數據才會得到解碼。這一步是發生在主線程的，並且不可避免。如果想要繞開這個機制，常見的做法是在後台線程先把圖片繪製到 CGBitmapContext 中，然後從 Bitmap 直接創建圖片。目前常見的網路圖片庫都自帶這個功能。

3）、圖像的繪製

圖像的繪製通常是指用那些以 CG 開頭的方法把圖像繪製到畫布中，然後從畫布創建圖片並顯示這樣一個過程。這個最常見的地方就是 [UIView drawRect:] 裡面了。由於 CoreGraphic 方法通常都是線程安全的，所以圖像的繪製可以很容易的放到後台線程進行。一個簡單非同步繪製的過程大致如下（實際情況會比這個複雜得多，但原理基本一致）：

二、GPU

1、接收提交的紋理（Texture）和頂點描述（三角形）

2、應用變換（transform）、混合併渲染

1）、紋理的渲染

所有的 Bitmap，包括圖片、文本、柵格化的內容，最終都要由內存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是 GPU 調整和渲染 Texture 的過程，都要消耗不少 GPU 資源。當在較短時間顯示大量圖片時（比如 TableView 存在非常多的圖片並且快速滑動時），CPU 佔用率很低，GPU 佔用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時間內大量圖片的顯示，儘可能將多張圖片合成為一張進行顯示。

當圖片過大，超過 GPU 的最大紋理尺寸時，圖片需要先由 CPU 進行預處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。目前來說，iPhone 4S 以上機型，紋理尺寸上限都是 4096x4096，更詳細的資料可以看這裡：iosres.com。所以，盡量不要讓圖片和視圖的大小超過這個值。

2）、視圖的混合 (Composing)

當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過於複雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當盡量減少視圖數量和層次，並在不透明的視圖裡標明 opaque 屬性以避免無用的 Alpha 通道合成。當然，這也可以用上面的方法，把多個視圖預先渲染為一張圖片來顯示。

3）、圖形的生成

CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發離屏渲染（offscreen rendering），而離屏渲染通常發生在 GPU 中。當一個列表視圖中出現大量圓角的 CALayer，並且快速滑動時，可以觀察到 GPU 資源已經佔滿，而 CPU 資源消耗很少。這時界面仍然能正常滑動，但平均幀數會降到很低。為了避免這種情況，可以嘗試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉嫁到 CPU 上去。對於只需要圓角的某些場合，也可以用一張已經繪製好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。最徹底的解決辦法，就是把需要顯示的圖形在後台線程繪製為圖片，避免使用圓角、陰影、遮罩等屬性。

3、輸出到屏幕上

通常你所能看到的內容，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類。

CPU GPU相關知識

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。

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

但是這些僅僅階段僅僅發生在你的應用程序之內，在動畫在屏幕上顯示之前仍然有更多的工作。一旦打包的圖層和動畫到達渲染服務進程，他們會被反序列化來形成另一個叫做渲染樹的圖層樹。

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

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

CPU相關的操作

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

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

GPU相關的操作

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

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

轉自： 何人之名-博客園

權威發布有關Imagination公司CPU,GPU以及連接IP、無線IP最新資訊，提供有關物聯網、可穿戴、通信、汽車電子、醫療電子等應用信息，每日更新大量信息，讓你緊跟技術發展，歡迎關注！伸出小手按一下二維碼我們就是好朋友！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！