一、屏幕顯示圖像原理

首先明確兩個概念：水平同步信號、垂直同步信號。

CRT的電子槍按照上圖中的方式，從上到下一行行掃描掃描完成后顯示器就呈現(xiàn)一幀畫面，隨后電子槍回到初始位置繼續(xù)下一次的掃描。當電子槍切換到新的一行準備掃描時，顯示器會發(fā)送一個水平同步信號(Horizonal Synchronization)，簡稱HSync;完成一幀畫面繪制后，電子槍會回到原位，顯示器會發(fā)送一個垂直同步信號(Vertical Synchronization)，簡稱VSync。

CUP計算好顯示內容提交到GPU，GPU渲染完成后將渲染結果放入幀緩沖區(qū)，之后視頻控制器按照VSync 信號逐行讀取幀緩沖區(qū)中的數(shù)據(jù)，***經過各種數(shù)模轉換傳遞給顯示器顯示。

二、卡頓產生的原因

如果在一個 VSync 時間內，CPU 或者 GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次再顯示，而這時顯示屏會保留之前的內容不變，這就是卡頓的原因。

三、CPU資源消耗的原因和解決方案

1.對象的創(chuàng)建

對象的創(chuàng)建會分配內存、調整屬性、甚至還有讀取文件的操作，比較消耗CPU資源。因此可以：

• (1) 盡量用輕量的對象代替重量的對象，如CALayer比UIView輕量的多，在不需要響應觸摸事件時，用CALayer顯示更合適;
• (2) 如果對象不涉及 UI 操作，盡量放到后臺線程去創(chuàng)建;
• (3) 通過 storyboard 創(chuàng)建視圖對象時，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多，所以盡量避免使用;
• (4) 盡量推遲對象創(chuàng)建的時間，并把對象的創(chuàng)建分散到多個任務中去;
• (5) 如果對象可以復用，并且復用的代價比釋放、創(chuàng)建新對象要小，那么這類對象應當盡量放到一個緩存池里復用。

對象調整

對象的調整也是經常消耗CPU資源的地方。尤其是CALayer：

• (1) CALayer 內部沒有屬性，當調用屬性方法時，它內部是通過運行時 resolveInstanceMethod 為對象臨時添加一個方法，并把對應屬性值保存到內部的一個 Dictionary 中，同時還會告知 delegate、創(chuàng)建動畫等等，非常消耗資源;
• (2) UIView 關于顯示相關的屬性 (比如 frame/bouds/transform等)實際上都是CALayer 屬性映射出來的，所以對UIView 的這些屬性進行調整時，消耗的資源要遠大于一般的屬性，因此應該盡量減少類似的不必要的屬性的修改;
• (3) 當視圖層次調整時，UIView、CALayer 之間會出現(xiàn)很多調用與通知，所以在優(yōu)化性能時，應該盡量避免調整視圖層次、添加和移除視圖。

3.對象銷毀

當容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。所以，盡量去后臺線程釋放對象?？梢赃@么做：把對象捕獲到 block 中，然后扔到后臺隊列去隨便發(fā)送個消息以避免編譯警告，就可以讓對象在后臺線程銷毀了：

NSArray *tmp = self.arr_data; 
self.arr_data = nil; 
dispatch_async(queue, ^{ 
    [tmp class]; 
 }); 

4.對象布局

在后臺線程提前計算好試圖布局、并對視圖的布局進行緩存。

不論通過何種技術對視圖進行布局，最終都會落到對 UIView.frame/bounds/center 等屬性的調整上

5.Autolayout

這是蘋果本身提倡的技術，在大部分情況下能很好的提升開發(fā)效率，但對于復雜視圖來說常會產生嚴重的性能問題。隨著視圖數(shù)量的增長，Autolayout 帶來的CPU消耗會呈指數(shù)級增長

6.文本計算

如果一個界面中包含大量的文本，文本的寬高計算會占用很大一部分資源，并且不可避免。

7.文本渲染

屏幕上能看到的所有的文本內容控件包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的，并且該排版、繪制都是在主線程進行的。

顯示大量文本時，CPU 的壓力非常大，可以通過自定義文本控件，用TextKit 或***層的 CoreText 對文本異步繪制，盡管麻煩但優(yōu)勢強大：

• (1) CoreText 對象能直接獲取文本的寬高等信息，避免了多次計算(調整 UILabel 大小時算一遍、UILabel 繪制時內部再算一遍);
• (2) CoreText 對象占用內存較小，可以緩存下來以備稍后多次渲染。

8.圖片解碼

用 UIImage 或者 CGImageSource 的方法創(chuàng)建圖片時，圖片數(shù)據(jù)并不會立刻解碼。圖片設置到UIImageView 或者 CALayer.contents 中，并且CALayer 被提到 GPU前，CGImage 中的數(shù)據(jù)才會得到解碼。

該步是發(fā)生在主線程，并且不可避免。如果想繞開這個機制，常見的方法是在后天線程先把圖片繪制到 CGBitmapContext中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡圖片庫都自帶這個功能。

9.圖像的繪制

是指用那些以CG開頭的方法把圖像繪制到畫布中，然后從畫布創(chuàng)建圖片并顯示。常見的就是 [ UIView drawRect: ]。CoreGraphic 方法通常是線程安全的，所以圖像的繪制可以放到后臺線程運行。如下：(實際情況比這個復雜，但原理基本一致)

- (void)display { 
    dispatch_async(backgroundQueue, ^{ 
        CGContextRef ctx = CGBitmapContextCreate(...); 
        // draw in context... 
        CGImageRef img = CGBitmapContextCreateImage(ctx); 
        CFRelease(ctx); 
        dispatch_async(mainQueue, ^{ 
            layer.contents = img; 
        }); 
    }); 
} 

四、GPU資源消耗原因和解決方案

GPU 能干的事情比較單一：接受提交的紋理(Texture)和頂點描述(三角形)、應用變換(transform)、混合并渲染，然后輸出到屏幕上?？吹降膬热萃ǔＶ饕羌y理(圖片)和形狀(三角模擬的矢量圖形)兩類。

1.紋理的渲染

所有的 Bitmap，包括圖片、文字、柵格化的內容，最終都要由內存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是 GPU 調整和渲染 Texture 的過程，都要消耗不少 GPU 資源。

當在短時間內顯示大量圖片時(如TableView)，CPU占用率很低，GPU 占用非常高，界面會掉幀。

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

2.視圖的混合(Composing)

當多個視圖(或者 CALayer)重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過于復雜，混合的過程也會消耗很多的 GPU 資源。

所以應當盡量減少視圖數(shù)量和層次，并在不透明的視圖里標明 opaque 屬性以避免無用的Alpha 通道合成。

也可以把多個視圖預先渲染為一張圖片來顯示

3.圖形的生成

CALayer 的 border、圓角、陰影、遮罩(mask)，CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染(offscreen rendering)，而離屏渲染通常發(fā)生在 GPU 中。

當列表中出現(xiàn)大量圓角的 CALayer并且快速滑動時，GPU 資源可能幾近占滿，而 CPU 資源消耗很少，這時候界面仍能正?；瑒拥骄鶐瑪?shù)降到很低。這時候可以嘗試開啟CALayer.shouldRaster 屬性，但這會離屏渲染操作轉嫁到 CPU上。

對于只需要圓角的某些場合，可以用一張已經繪制好的圓角圖片覆蓋到原視圖上來模擬出相同的視覺效果

最徹底的做法：把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。