淺談iOS頁面流暢技巧
一、屏幕顯示圖像原理
首先明確兩個概念：水平同步信號、垂直同步信號。
CRT的電子槍按照上圖中的方式，從上到下一行行掃描掃描完成后顯示器就呈現(xiàn)一幀畫面，隨后電子槍回到初始位置繼續(xù)下一次的掃描。當(dāng)電子槍切換到新的一行準(zhǔn)備掃描時，顯示器會發(fā)送一個水平同步信號(Horizonal Synchronization)，簡稱HSync;完成一幀畫面繪制后，電子槍會回到原位，顯示器會發(fā)送一個垂直同步信號(Vertical Synchronization)，簡稱VSync。
CUP計算好顯示內(nèi)容提交到GPU，GPU渲染完成后將渲染結(jié)果放入幀緩沖區(qū)，之后視頻控制器按照VSync 信號逐行讀取幀緩沖區(qū)中的數(shù)據(jù)，***經(jīng)過各種數(shù)模轉(zhuǎn)換傳遞給顯示器顯示。
二、卡頓產(chǎn)生的原因
如果在一個 VSync 時間內(nèi)，CPU 或者 GPU 沒有完成內(nèi)容提交，則那一幀就會被丟棄，等待下一次再顯示，而這時顯示屏?xí)Ａ糁暗膬?nèi)容不變，這就是卡頓的原因。
三、CPU資源消耗的原因和解決方案
1.對象的創(chuàng)建
對象的創(chuàng)建會分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件的操作，比較消耗CPU資源。因此可以：
- (1) 盡量用輕量的對象代替重量的對象，如CALayer比UIView輕量的多，在不需要響應(yīng)觸摸事件時，用CALayer顯示更合適;
- (2) 如果對象不涉及 UI 操作，盡量放到后臺線程去創(chuàng)建;
- (3) 通過 storyboard 創(chuàng)建視圖對象時，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多，所以盡量避免使用;
- (4) 盡量推遲對象創(chuàng)建的時間，并把對象的創(chuàng)建分散到多個任務(wù)中去;
- (5) 如果對象可以復(fù)用，并且復(fù)用的代價比釋放、創(chuàng)建新對象要小，那么這類對象應(yīng)當(dāng)盡量放到一個緩存池里復(fù)用。
對象調(diào)整
對象的調(diào)整也是經(jīng)常消耗CPU資源的地方。尤其是CALayer：
- (1) CALayer 內(nèi)部沒有屬性，當(dāng)調(diào)用屬性方法時，它內(nèi)部是通過運(yùn)行時 resolveInstanceMethod 為對象臨時添加一個方法，并把對應(yīng)屬性值保存到內(nèi)部的一個 Dictionary 中，同時還會告知 delegate、創(chuàng)建動畫等等，非常消耗資源;
- (2) UIView 關(guān)于顯示相關(guān)的屬性 (比如 frame/bouds/transform等)實際上都是CALayer 屬性映射出來的，所以對UIView 的這些屬性進(jìn)行調(diào)整時，消耗的資源要遠(yuǎn)大于一般的屬性，因此應(yīng)該盡量減少類似的不必要的屬性的修改;
- (3) 當(dāng)視圖層次調(diào)整時，UIView、CALayer 之間會出現(xiàn)很多調(diào)用與通知，所以在優(yōu)化性能時，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。
3.對象銷毀
當(dāng)容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。所以，盡量去后臺線程釋放對象?？梢赃@么做：把對象捕獲到 block 中，然后扔到后臺隊列去隨便發(fā)送個消息以避免編譯警告，就可以讓對象在后臺線程銷毀了：
- NSArray *tmp = self.arr_data;
- self.arr_data = nil;
- dispatch_async(queue, ^{
- [tmp class];
- });
4.對象布局
在后臺線程提前計算好試圖布局、并對視圖的布局進(jìn)行緩存。
不論通過何種技術(shù)對視圖進(jìn)行布局，最終都會落到對 UIView.frame/bounds/center 等屬性的調(diào)整上
5.Autolayout
這是蘋果本身提倡的技術(shù)，在大部分情況下能很好的提升開發(fā)效率，但對于復(fù)雜視圖來說常會產(chǎn)生嚴(yán)重的性能問題。隨著視圖數(shù)量的增長，Autolayout 帶來的CPU消耗會呈指數(shù)級增長
6.文本計算
如果一個界面中包含大量的文本，文本的寬高計算會占用很大一部分資源，并且不可避免。
7.文本渲染
屏幕上能看到的所有的文本內(nèi)容控件包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的，并且該排版、繪制都是在主線程進(jìn)行的。
顯示大量文本時，CPU 的壓力非常大，可以通過自定義文本控件，用TextKit 或***層的 CoreText 對文本異步繪制，盡管麻煩但優(yōu)勢強(qiáng)大：
- (1) CoreText 對象能直接獲取文本的寬高等信息，避免了多次計算(調(diào)整 UILabel 大小時算一遍、UILabel 繪制時內(nèi)部再算一遍);
- (2) CoreText 對象占用內(nèi)存較小，可以緩存下來以備稍后多次渲染。
8.圖片解碼
用 UIImage 或者 CGImageSource 的方法創(chuàng)建圖片時，圖片數(shù)據(jù)并不會立刻解碼。圖片設(shè)置到UIImageView 或者 CALayer.contents 中，并且CALayer 被提到 GPU前，CGImage 中的數(shù)據(jù)才會得到解碼。
該步是發(fā)生在主線程，并且不可避免。如果想繞開這個機(jī)制，常見的方法是在后天線程先把圖片繪制到 CGBitmapContext中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡(luò)圖片庫都自帶這個功能。
9.圖像的繪制
是指用那些以CG開頭的方法把圖像繪制到畫布中，然后從畫布創(chuàng)建圖片并顯示。常見的就是 [ UIView drawRect: ]。CoreGraphic 方法通常是線程安全的，所以圖像的繪制可以放到后臺線程運(yùn)行。如下：(實際情況比這個復(fù)雜，但原理基本一致)
- - (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)和頂點(diǎn)描述(三角形)、應(yīng)用變換(transform)、混合并渲染，然后輸出到屏幕上。看到的內(nèi)容通常主要是紋理(圖片)和形狀(三角模擬的矢量圖形)兩類。
1.紋理的渲染
所有的 Bitmap，包括圖片、文字、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是 GPU 調(diào)整和渲染 Texture 的過程，都要消耗不少 GPU 資源。
當(dāng)在短時間內(nèi)顯示大量圖片時(如TableView)，CPU占用率很低，GPU 占用非常高，界面會掉幀。
當(dāng)圖片過大，超過 GPU 的***紋理尺寸時，圖片需要先由 CPU 進(jìn)行預(yù)處理，這對 CPU 跟 GPU 都會帶來額外的消耗。
2.視圖的混合(Composing)
當(dāng)多個視圖(或者 CALayer)重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結(jié)構(gòu)過于復(fù)雜，混合的過程也會消耗很多的 GPU 資源。
所以應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的Alpha 通道合成。
也可以把多個視圖預(yù)先渲染為一張圖片來顯示
3.圖形的生成
CALayer 的 border、圓角、陰影、遮罩(mask)，CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染(offscreen rendering)，而離屏渲染通常發(fā)生在 GPU 中。
當(dāng)列表中出現(xiàn)大量圓角的 CALayer并且快速滑動時，GPU 資源可能幾近占滿，而 CPU 資源消耗很少，這時候界面仍能正?；瑒拥骄鶐瑪?shù)降到很低。這時候可以嘗試開啟CALayer.shouldRaster 屬性，但這會離屏渲染操作轉(zhuǎn)嫁到 CPU上。
對于只需要圓角的某些場合，可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原視圖上來模擬出相同的視覺效果
最徹底的做法：把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
