卡頓產生的原因和解決方案

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

從上面的圖中可以看到，CPU 和 GPU 不論哪個阻礙了顯示流程，都會造成掉幀現象。所以開發時，也需要分別對 CPU 和 GPU 壓力進行評估和優化。為了做到這一點，我們首先得了解 CPU 和 GPU 各自負責哪些內容。

上面的圖展示了 iOS 系統下各個模塊所處的位置，下面我們再具體看一下 CPU 和 GPU 對應了哪些操作。

一、CPU 消耗型任務

1.對象創建

對象創建過程伴隨著內存分配、屬性設置、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對象代替重量的對象，可以對性能有所優化。比如 CALayer 比 UIView 要輕量許多，如果視圖元素不需要響應觸摸事件，用 CALayer 會更加合適。

通過 Storyboard 創建視圖對象還會涉及到文件反序列化操作，其資源消耗會比直接通過代碼創建對象要大非常多，在性能敏感的界面裏，Storyboard 並不是一個好的技術選擇。

對於列表類型的頁面，還可以參考 UITableView 的復用機制。每次要初始化 View 對象時先根據 identifier 從緩存池裏取，能取到就復用這個 View 對象，取不到再真正執行初始化過程。滑動屏幕時，會將滑出屏幕外的 View 對象根據 identifier 放入緩存池，新進入屏幕可見範圍內的 View 又根據前面的規則來決定是否要真正初始化。

2.對象調整

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

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

3.對象銷毀

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

個人理解：tmp被 [tmp class]所在的block強引用，這個block會被追加到後臺隊列去執行，執行期間block一直對tmp強引用，block執行完畢後會被釋放，block引用的對象也會被釋放，所以達到了在後臺線程銷毀對象的目的。

4.布局計算

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

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

5.Autolayout

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

6.文本計算

如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源，並且不可避免。如果你對文本顯示沒有特殊要求，可以參考下 UILabel 內部的實現方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到後臺線程進行以避免阻塞主線程。

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

7.文本渲染

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

8.圖片的解碼

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

9.圖像的繪制

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

二、GPU消耗型任務

相對於 CPU 來說，GPU 能幹的事情比較單一：接收提交的紋理（Texture）和頂點描述（三角形），應用變換（transform）、混合並渲染，然後輸出到屏幕上。寬泛的說，大多數 CALayer 的屬性都是用 GPU 來繪制。

以下一些操作會降低 GPU 繪制的性能，

1.大量幾何結構

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

另外當圖片過大，超過 GPU 的最大紋理尺寸時，圖片需要先由 CPU 進行預處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。

2.視圖的混合

當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過於復雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當盡量減少視圖數量和層次，並且減少不必要的透明視圖。

3.離屏渲染

離屏渲染是指圖層在被顯示之前是在當前屏幕緩沖區以外開辟的一個緩沖區進行渲染操作。

離屏渲染需要多次切換上下文環境：先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結束以後，將離屏緩沖區的渲染結果顯示到屏幕上又需要將上下文環境從離屏切換到當前屏幕，而上下文環境的切換是一項高開銷的動作。

CPU的offscreen-render

使用CPU來完成渲染操縱，通常在你使用：

• drawRect (如果沒有自定義繪制的任務就不要在子類中寫一個空的drawRect方法，因為只要實現了該方法，就會為視圖分配一個寄宿圖，這個寄宿圖的像素尺寸等於視圖大小乘以 contentsScale的值，造成資源浪費)
• 使用Core Graphics
• 上面的兩種情況使用的就是CPU離屏渲染，首先分配一塊內存，然後進行渲染操作生成一份bitmap位圖，整個渲染過程會在你的應用中同步的進行，接著再將位圖打包發送到iOS裏一個單獨的進程--render server，理想情況下，render server將內容交給GPU直接顯示到屏幕上。

GPU的offscreen-render

• 陰影（UIView.layer.shadowOffset/shadowRadius/…）
• 圓角（當 UIView.layer.cornerRadius 和 UIView.layer.maskToBounds 一起使用時）
• 圖層蒙板
• 開啟光柵化（shouldRasterize = true）

使用陰影時同時設置 shadowPath 就能避免離屏渲染大大提升性能，後面會有一個 Demo 來演示；圓角觸發的離屏渲染可以用 CoreGraphics 將圖片處理成圓角來避免。

CALayer 有一個 shouldRasterize 屬性，將這個屬性設置成 true 後就開啟了光柵化。開啟光柵化後會將圖層繪制到一個屏幕外的圖像，然後這個圖像將會被緩存起來並繪制到實際圖層的 contents 和子圖層，對於有很多的子圖層或者有復雜的效果應用，這樣做就會比重繪所有事務的所有幀來更加高效。但是光柵化原始圖像需要時間，而且會消耗額外的內存。

光柵化也會帶來一定的性能損耗，是否要開啟就要根據實際的使用場景了，圖層內容頻繁變化時不建議使用。最好還是用 Instruments 比對開啟前後的 FPS 來看是否起到了優化效果。

註意：

shouldRasterize = true 時記得同時設置 rasterizationScale=[UIScreen mainScreen].scale

整理自：iOS 保持界面流暢的技巧

　　　　iOS app性能優化的那些事(二)

　　　　iOS進階之頁面性能優化

http://www.cnblogs.com/howdoudo/p/7002756.html

iOS--性能優化--保持界面流暢