http://blog.csdn.net/guojin08/article/details/60773120

屏幕顯示圖像的原理

ios_screen_scan

首先從過去的 CRT 顯示器原理說起。CRT 的電子槍按照上面方式叛复，從上到下一行行掃描胳嘲，掃描完成后顯示器就呈現(xiàn)一幀畫面丙号，隨后電子槍回到初始位置繼續(xù)下一次掃描。為了把顯示器的顯示過程和系統(tǒng)的視頻控制器進行同步寺旺，顯示器（或者其他硬件）會用硬件時鐘產生一系列的定時信號缘屹。當電子槍換到新的一行，準備進行掃描時洪燥，顯示器會發(fā)出一個水平同步信號（horizonal synchronization）磕秤，簡稱 HSync；而當一幀畫面繪制完成后捧韵，電子槍回復到原位市咆，準備畫下一幀前，顯示器會發(fā)出一個垂直同步信號（vertical synchronization）再来，簡稱 VSync蒙兰。顯示器通常以固定頻率進行刷新，這個刷新率就是 VSync 信號產生的頻率芒篷。盡管現(xiàn)在的設備大都是液晶顯示屏了搜变，但原理仍然沒有變。

ios_screen_display

通常來說针炉，計算機系統(tǒng)中 CPU挠他、GPU、顯示器是以上面這種方式協(xié)同工作的篡帕。CPU 計算好顯示內容提交到 GPU殖侵，GPU 渲染完成后將渲染結果放入幀緩沖區(qū)，隨后視頻控制器會按照 VSync 信號逐行讀取幀緩沖區(qū)的數(shù)據(jù)镰烧，經過可能的數(shù)模轉換傳遞給顯示器顯示拢军。

在最簡單的情況下，幀緩沖區(qū)只有一個怔鳖，這時幀緩沖區(qū)的讀取和刷新都都會有比較大的效率問題朴沿。為了解決效率問題，顯示系統(tǒng)通常會引入兩個緩沖區(qū)败砂，即雙緩沖機制。在這種情況下魏铅，GPU 會預先渲染好一幀放入一個緩沖區(qū)內昌犹，讓視頻控制器讀取，當下一幀渲染好后览芳，GPU 會直接把視頻控制器的指針指向第二個緩沖器斜姥。如此一來效率會有很大的提升。

雙緩沖雖然能解決效率問題沧竟，但會引入一個新的問題铸敏。當視頻控制器還未讀取完成時，即屏幕內容剛顯示一半時悟泵，GPU 將新的一幀內容提交到幀緩沖區(qū)并把兩個緩沖區(qū)進行交換后杈笔，視頻控制器就會把新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成畫面撕裂現(xiàn)象糕非，如下圖：

ios_vsync_off

為了解決這個問題蒙具，GPU 通常有一個機制叫做垂直同步（簡寫也是 V-Sync）球榆，當開啟垂直同步后，GPU 會等待顯示器的 VSync 信號發(fā)出后禁筏，才進行新的一幀渲染和緩沖區(qū)更新持钉。這樣能解決畫面撕裂現(xiàn)象，也增加了畫面流暢度篱昔，但需要消費更多的計算資源每强，也會帶來部分延遲。

那么目前主流的移動設備是什么情況呢州刽？從網(wǎng)上查到的資料可以知道空执，iOS 設備會始終使用雙緩存，并開啟垂直同步怀伦。而安卓設備直到 4.1 版本脆烟，Google 才開始引入這種機制，目前安卓系統(tǒng)是三緩存+垂直同步房待。

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

ios_frame_drop

在 VSync 信號到來后邢羔，系統(tǒng)圖形服務會通過 CADisplayLink 等機制通知 App，App 主線程開始在 CPU 中計算顯示內容桑孩，比如視圖的創(chuàng)建拜鹤、布局計算、圖片解碼流椒、文本繪制等敏簿。隨后 CPU 會將計算好的內容提交到 GPU 去，由 GPU 進行變換宣虾、合成惯裕、渲染。隨后 GPU 會把渲染結果提交到幀緩沖區(qū)去绣硝，等待下一次 VSync 信號到來時顯示到屏幕上蜻势。由于垂直同步的機制，如果在一個 VSync 時間內鹉胖，CPU 或者 GPU 沒有完成內容提交握玛，則那一幀就會被丟棄，等待下一次機會再顯示甫菠，而這時顯示屏會保留之前的內容不變挠铲。這就是界面卡頓的原因。

從上面的圖中可以看到寂诱，CPU 和 GPU 不論哪個阻礙了顯示流程拂苹，都會造成掉幀現(xiàn)象。所以開發(fā)時痰洒，也需要分別對 CPU 和 GPU 壓力進行評估和優(yōu)化醋寝。

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

對象創(chuàng)建

對象的創(chuàng)建會分配內存搞挣、調整屬性、甚至還有讀取文件等操作音羞，比較消耗 CPU 資源囱桨。盡量用輕量的對象代替重量的對象，可以對性能有所優(yōu)化嗅绰。比如 CALayer 比 UIView 要輕量許多舍肠，那么不需要響應觸摸事件的控件，用 CALayer 顯示會更加合適窘面。如果對象不涉及 UI 操作翠语，則盡量放到后臺線程去創(chuàng)建，但可惜的是包含有 CALayer 的控件财边，都只能在主線程創(chuàng)建和操作肌括。通過 Storyboard 創(chuàng)建視圖對象時，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多酣难，在性能敏感的界面里谍夭，Storyboard 并不是一個好的技術選擇。

盡量推遲對象創(chuàng)建的時間憨募，并把對象的創(chuàng)建分散到多個任務中去紧索。盡管這實現(xiàn)起來比較麻煩，并且?guī)淼膬?yōu)勢并不多菜谣，但如果有能力做珠漂，還是要盡量嘗試一下。如果對象可以復用尾膊，并且復用的代價比釋放开泽、創(chuàng)建新對象要小肥隆，那么這類對象應當盡量放到一個緩存池里復用世杀。

對象調整

對象的調整也經常是消耗 CPU 資源的地方喷众。這里特別說一下 CALayer：CALayer 內部并沒有屬性，當調用屬性方法時莺债，它內部是通過運行時 resolveInstanceMethod 為對象臨時添加一個方法，并把對應屬性值保存到內部的一個 Dictionary 里签夭，同時還會通知 delegate齐邦、創(chuàng)建動畫等等，非常消耗資源第租。UIView 的關于顯示相關的屬性（比如 frame/bounds/transform）等實際上都是 CALayer 屬性映射來的措拇，所以對 UIView 的這些屬性進行調整時，消耗的資源要遠大于一般的屬性慎宾。對此你在應用中丐吓，應該盡量減少不必要的屬性修改浅悉。

當視圖層次調整時，UIView券犁、CALayer 之間會出現(xiàn)很多方法調用與通知术健，所以在優(yōu)化性能時，應該盡量避免調整視圖層次粘衬、添加和移除視圖荞估。

對象銷毀

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

1

2

3

4

5

NSArray *tmp = self.array;

self.array = nil;

dispatch_async(queue, ^{

[tmp class];

});

布局計算

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

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

Autolayout

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

文本計算

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

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

文本渲染

屏幕上能看到的所有文本內容控件洼滚，包括 UIWebView埂息，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的遥巴。常見的文本控件 （UILabel千康、UITextView 等），其排版和繪制都是在主線程進行的铲掐，當顯示大量文本時拾弃，CPU 的壓力會非常大。對此解決方案只有一個摆霉，那就是自定義文本控件豪椿，用 TextKit 或最底層的 CoreText 對文本異步繪制。盡管這實現(xiàn)起來非常麻煩携栋，但其帶來的優(yōu)勢也非常大搭盾，CoreText 對象創(chuàng)建好后，能直接獲取文本的寬高等信息婉支，避免了多次計算（調整 UILabel 大小時算一遍鸯隅、UILabel 繪制時內部再算一遍）；CoreText 對象占用內存較少向挖，可以緩存下來以備稍后多次渲染蝌以。

圖片的解碼

當你用 UIImage 或 CGImageSource 的那幾個方法創(chuàng)建圖片時，圖片數(shù)據(jù)并不會立刻解碼何之。圖片設置到 UIImageView 或者 CALayer.contents 中去跟畅，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會得到解碼帝美。這一步是發(fā)生在主線程的，并且不可避免。如果想要繞開這個機制悼潭，常見的做法是在后臺線程先把圖片繪制到 CGBitmapContext 中庇忌，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡圖片庫都自帶這個功能舰褪。

圖像的繪制

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

1

2

3

4

5

6

7

8

9

10

11

-

(void)display

{

dispatch_async(backgroundQueue,

^{

CGContextRef

ctx

=

CGBitmapContextCreate(...);

//

draw in context...

CGImageRef

img

=

CGBitmapContextCreateImage(ctx);

CFRelease(ctx);

dispatch_async(mainQueue,

^{

layer.contents

=

img;

});

});

}

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

相對于 CPU 來說表牢，GPU 能干的事情比較單一：接收提交的紋理（Texture）和頂點描述（三角形），應用變換（transform）贝次、混合并渲染崔兴，然后輸出到屏幕上。通常你所能看到的內容蛔翅，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類敲茄。

紋理的渲染

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

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

視圖的混合 (Composing)

當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起钧嘶。如果視圖結構過于復雜棠众，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗有决，應用應當盡量減少視圖數(shù)量和層次闸拿，并在不透明的視圖里標明 opaque 屬性以避免無用的 Alpha 通道合成。當然书幕，這也可以用上面的方法新荤，把多個視圖預先渲染為一張圖片來顯示。

圖形的生成按咒。

CALayer 的 border迟隅、圓角、陰影励七、遮罩（mask）智袭，CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染（offscreen rendering）掠抬，而離屏渲染通常發(fā)生在 GPU 中吼野。當一個列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動時两波，可以觀察到 GPU 資源已經占滿瞳步，而 CPU 資源消耗很少。這時界面仍然能正逞埽滑動单起，但平均幀數(shù)會降到很低。為了避免這種情況劣坊，可以嘗試開啟 CALayer.shouldRasterize 屬性嘀倒，但這會把原本離屏渲染的操作轉嫁到 CPU 上去。對于只需要圓角的某些場合局冰，也可以用一張已經繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果测蘑。最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片康二，避免使用圓角碳胳、陰影、遮罩等屬性沫勿。

AsyncDisplayKit

AsyncDisplayKit 是 Facebook 開源的一個用于保持 iOS 界面流暢的庫挨约，我從中學到了很多東西味混，所以下面我會花較大的篇幅來對其進行介紹和分析。

ASDK 的由來

scott_goodson

ASDK 的作者是 Scott Goodson (Linkedin)诫惭，

他曾經在蘋果工作惜傲，負責 iOS 的一些內置應用的開發(fā)，比如股票贝攒、計算器、地圖时甚、鐘表隘弊、設置、Safari 等荒适，當然他也參與了 UIKit framework 的開發(fā)梨熙。后來他加入 Facebook 后，負責 Paper 的開發(fā)刀诬，創(chuàng)建并開源了 AsyncDisplayKit咽扇。目前他在 Pinterest 和 Instagram 負責 iOS 開發(fā)和用戶體驗的提升等工作。

asdk_history

ASDK 自 2014 年 6 月開源陕壹，10 月發(fā)布 1.0 版质欲。目前 ASDK 即將要發(fā)布 2.0 版。

V2.0 增加了更多布局相關的代碼糠馆，ComponentKit 團隊為此貢獻很多嘶伟。

現(xiàn)在 Github 的 master 分支上的版本是 V1.9.1，已經包含了 V2.0 的全部內容又碌。

ASDK 的資料

想要了解 ASDK 的原理和細節(jié)九昧，最好從下面幾個視頻開始：

2014.10.15 NSLondon - Scott Goodson - Behind AsyncDisplayKit

2015.03.02 MCE 2015 - Scott Goodson - Effortless Responsiveness with AsyncDisplayKit

2015.10.25 AsyncDisplayKit 2.0: Intelligent User Interfaces - NSSpain 2015

前兩個視頻內容大同小異，都是介紹 ASDK 的基本原理毕匀，附帶介紹 POP 等其他項目铸鹰。

后一個視頻增加了 ASDK 2.0 的新特性的介紹。

除此之外皂岔，還可以到 Github Issues 里看一下 ASDK 相關的討論蹋笼，下面是幾個比較重要的內容：

關于 Runloop Dispatch

關于 ComponentKit 和 ASDK 的區(qū)別

為什么不支持 Storyboard 和 Autolayout

如何評測界面的流暢度

之后，還可以到 Google Groups 來查看和討論更多內容：

https://groups.google.com/forum/#!forum/asyncdisplaykit

ASDK 的基本原理

asdk_design

ASDK 認為凤薛，阻塞主線程的任務姓建，主要分為上面這三大類。文本和布局的計算缤苫、渲染速兔、解碼、繪制都可以通過各種方式異步執(zhí)行活玲，但 UIKit 和 Core Animation 相關操作必需在主線程進行涣狗。ASDK 的目標谍婉，就是盡量把這些任務從主線程挪走，而挪不走的镀钓，就盡量優(yōu)化性能穗熬。

為了達成這一目標，ASDK 嘗試對 UIKit 組件進行封裝：

asdk_layer_backed_view

這是常見的 UIView 和 CALayer 的關系：View 持有 Layer 用于顯示丁溅，View 中大部分顯示屬性實際是從 Layer 映射而來唤蔗；Layer 的 delegate 在這里是 View，當其屬性改變窟赏、動畫產生時妓柜，View 能夠得到通知。UIView 和 CALayer 不是線程安全的涯穷，并且只能在主線程創(chuàng)建棍掐、訪問和銷毀。

asdk_view_backed_node

ASDK 為此創(chuàng)建了 ASDisplayNode 類拷况，包裝了常見的視圖屬性（比如 frame/bounds/alpha/transform/backgroundColor/superNode/subNodes 等）作煌，然后它用 UIView->CALayer 相同的方式，實現(xiàn)了 ASNode->UIView 這樣一個關系赚瘦。

asdk_layer_backed_node

當不需要響應觸摸事件時粟誓，ASDisplayNode 可以被設置為 layer backed，即 ASDisplayNode 充當了原來 UIView 的功能起意，節(jié)省了更多資源努酸。

與 UIView 和 CALayer 不同，ASDisplayNode 是線程安全的杜恰，它可以在后臺線程創(chuàng)建和修改获诈。Node 剛創(chuàng)建時，并不會在內部新建 UIView 和 CALayer心褐，直到第一次在主線程訪問 view 或 layer 屬性時舔涎，它才會在內部生成對應的對象。當它的屬性（比如frame/transform）改變后逗爹，它并不會立刻同步到其持有的 view 或 layer 去亡嫌，而是把被改變的屬性保存到內部的一個中間變量，稍后在需要時掘而，再通過某個機制一次性設置到內部的 view 或 layer挟冠。

通過模擬和封裝 UIView/CALayer，開發(fā)者可以把代碼中的 UIView 替換為 ASNode袍睡，很大的降低了開發(fā)和學習成本知染，同時能獲得 ASDK 底層大量的性能優(yōu)化。為了方便使用斑胜， ASDK 把大量常用控件都封裝成了 ASNode 的子類控淡，比如 Button嫌吠、Control、Cell掺炭、Image辫诅、ImageView、Text涧狮、TableView炕矮、CollectionView 等。利用這些控件者冤，開發(fā)者可以盡量避免直接使用 UIKit 相關控件吧享，以獲得更完整的性能提升。

ASDK 的圖層預合成

asdk_comoose_1 asdk_compose_2

有時一個 layer 會包含很多 sub-layer譬嚣，而這些 sub-layer 并不需要響應觸摸事件，也不需要進行動畫和位置調整钞它。ASDK 為此實現(xiàn)了一個被稱為 pre-composing 的技術拜银，可以把這些 sub-layer 合成渲染為一張圖片。開發(fā)時遭垛，ASNode 已經替代了 UIView 和 CALayer尼桶；直接使用各種 Node 控件并設置為 layer backed 后，ASNode 甚至可以通過預合成來避免創(chuàng)建內部的 UIView 和 CALayer锯仪。

通過這種方式泵督，把一個大的層級，通過一個大的繪制方法繪制到一張圖上庶喜，性能會獲得很大提升小腊。CPU 避免了創(chuàng)建 UIKit 對象的資源消耗，GPU 避免了多張 texture 合成和渲染的消耗久窟，更少的 bitmap 也意味著更少的內存占用秩冈。

ASDK 異步并發(fā)操作

asdk_a9_chip

自 iPhone 4S 起，iDevice 已經都是雙核 CPU 了斥扛，現(xiàn)在的 iPad 甚至已經更新到 3 核了入问。充分利用多核的優(yōu)勢、并發(fā)執(zhí)行任務對保持界面流暢有很大作用稀颁。ASDK 把布局計算芬失、文本排版、圖片/文本/圖形渲染等操作都封裝成較小的任務匾灶，并利用 GCD 異步并發(fā)執(zhí)行棱烂。如果開發(fā)者使用了 ASNode 相關的控件，那么這些并發(fā)操作會自動在后臺進行阶女，無需進行過多配置垢啼。

Runloop 任務分發(fā)

Runloop work distribution 是 ASDK 比較核心的一個技術窜锯，ASDK 的介紹視頻和文檔中都沒有詳細展開介紹，所以這里我會多做一些分析芭析。如果你對 Runloop 還不太了解锚扎，可以看一下我之前的文章 深入理解RunLoop，里面對 ASDK 也有所提及馁启。

ios_vsync_runloop

iOS 的顯示系統(tǒng)是由 VSync 信號驅動的驾孔，VSync 信號由硬件時鐘生成，每秒鐘發(fā)出 60 次（這個值取決設備硬件惯疙，比如 iPhone 真機上通常是 59.97）翠勉。iOS 圖形服務接收到 VSync 信號后，會通過 IPC 通知到 App 內霉颠。App 的 Runloop 在啟動后會注冊對應的 CFRunLoopSource 通過 mach_port 接收傳過來的時鐘信號通知对碌，隨后 Source 的回調會驅動整個 App 的動畫與顯示。

Core Animation 在 RunLoop 中注冊了一個 Observer蒿偎，監(jiān)聽了 BeforeWaiting 和 Exit 事件朽们。這個 Observer 的優(yōu)先級是 2000000，低于常見的其他 Observer诉位。當一個觸摸事件到來時骑脱，RunLoop 被喚醒，App 中的代碼會執(zhí)行一些操作苍糠，比如創(chuàng)建和調整視圖層級叁丧、設置 UIView 的 frame、修改 CALayer 的透明度岳瞭、為視圖添加一個動畫拥娄；這些操作最終都會被 CALayer 捕獲，并通過 CATransaction 提交到一個中間狀態(tài)去（CATransaction 的文檔略有提到這些內容瞳筏，但并不完整）条舔。當上面所有操作結束后，RunLoop 即將進入休眠（或者退出）時乏矾，關注該事件的 Observer 都會得到通知孟抗。這時 CA 注冊的那個 Observer 就會在回調中，把所有的中間狀態(tài)合并提交到 GPU 去顯示钻心；如果此處有動畫凄硼，CA 會通過 DisplayLink 等機制多次觸發(fā)相關流程。

ASDK 在此處模擬了 Core Animation 的這個機制：所有針對 ASNode 的修改和提交捷沸，總有些任務是必需放入主線程執(zhí)行的摊沉。當出現(xiàn)這種任務時，ASNode 會把任務用 ASAsyncTransaction(Group) 封裝并提交到一個全局的容器去痒给。ASDK 也在 RunLoop 中注冊了一個 Observer说墨，監(jiān)視的事件和 CA 一樣骏全，但優(yōu)先級比 CA 要低。當 RunLoop 進入休眠前尼斧、CA 處理完事件后姜贡，ASDK 就會執(zhí)行該 loop 內提交的所有任務。具體代碼見這個文件：ASAsyncTransactionGroup棺棵。

通過這種機制楼咳，ASDK 可以在合適的機會把異步、并發(fā)的操作同步到主線程去烛恤，并且能獲得不錯的性能母怜。

其他

ASDK 中還有封裝很多高級的功能，比如滑動列表的預加載缚柏、V2.0添加的新的布局模式等苹熏。ASDK 是一個很龐大的庫，它本身并不推薦你把整個 App 全部都改為 ASDK 驅動币喧，把最需要提升交互性能的地方用 ASDK 進行優(yōu)化就足夠了轨域。

微博 Demo 性能優(yōu)化技巧

我為了演示 YYKit 的功能，實現(xiàn)了微博和 Twitter 的 Demo粱锐，并為它們做了不少性能優(yōu)化，下面就是優(yōu)化時用到的一些技巧扛邑。

預排版

當獲取到 API JSON 數(shù)據(jù)后怜浅，我會把每條 Cell 需要的數(shù)據(jù)都在后臺線程計算并封裝為一個布局對象 CellLayout。CellLayout 包含所有文本的 CoreText 排版結果蔬崩、Cell 內部每個控件的高度恶座、Cell 的整體高度。每個 CellLayout 的內存占用并不多沥阳，所以當生成后跨琳，可以全部緩存到內存，以供稍后使用桐罕。這樣脉让，TableView 在請求各個高度函數(shù)時，不會消耗任何多余計算量功炮；當把 CellLayout 設置到 Cell 內部時溅潜，Cell 內部也不用再計算布局了。

對于通常的 TableView 來說薪伏，提前在后臺計算好布局結果是非常重要的一個性能優(yōu)化點滚澜。為了達到最高性能，你可能需要犧牲一些開發(fā)速度嫁怀，不要用 Autolayout 等技術设捐，少用 UILabel 等文本控件借浊。但如果你對性能的要求并不那么高，可以嘗試用 TableView 的預估高度的功能萝招，并把每個 Cell 高度緩存下來蚂斤。這里有個來自百度知道團隊的開源項目可以很方便的幫你實現(xiàn)這一點：FDTemplateLayoutCell。

預渲染

微博的頭像在某次改版中換成了圓形即寒，所以我也跟進了一下橡淆。當頭像下載下來后，我會在后臺線程將頭像預先渲染為圓形并單獨保存到一個 ImageCache 中去母赵。

對于 TableView 來說逸爵，Cell 內容的離屏渲染會帶來較大的 GPU 消耗。在 Twitter Demo 中凹嘲，我為了圖省事兒用到了不少 layer 的圓角屬性师倔，你可以在低性能的設備（比如 iPad 3）上快速滑動一下這個列表，能感受到雖然列表并沒有較大的卡頓周蹭，但是整體的平均幀數(shù)降了下來趋艘。用 Instument 查看時能夠看到 GPU 已經滿負荷運轉，而 CPU 卻比較清閑凶朗。為了避免離屏渲染瓷胧，你應當盡量避免使用 layer 的 border、corner棚愤、shadow搓萧、mask 等技術，而盡量在后臺線程預先繪制好對應內容宛畦。

異步繪制

我只在顯示文本的控件上用到了異步繪制的功能瘸洛，但效果很不錯。我參考 ASDK 的原理次和，實現(xiàn)了一個簡單的異步繪制控件反肋。這塊代碼我單獨提取出來，放到了這里：YYAsyncLayer踏施。YYAsyncLayer 是 CALayer 的子類石蔗，當它需要顯示內容（比如調用了 [layer setNeedDisplay]）時，它會向 delegate畅形，也就是 UIView 請求一個異步繪制的任務抓督。在異步繪制時，Layer 會傳遞一個 BOOL(^isCancelled)() 這樣的 block束亏，繪制代碼可以隨時調用該 block 判斷繪制任務是否已經被取消铃在。

當 TableView 快速滑動時，會有大量異步繪制任務提交到后臺線程去執(zhí)行。但是有時滑動速度過快時定铜，繪制任務還沒有完成就可能已經被取消了阳液。如果這時仍然繼續(xù)繪制，就會造成大量的 CPU 資源浪費揣炕，甚至阻塞線程并造成后續(xù)的繪制任務遲遲無法完成帘皿。我的做法是盡量快速、提前判斷當前繪制任務是否已經被取消畸陡；在繪制每一行文本前鹰溜，我都會調用 isCancelled() 來進行判斷，保證被取消的任務能及時退出丁恭，不至于影響后續(xù)操作曹动。

目前有些第三方微博客戶端（比如 VVebo、墨客等）牲览，使用了一種方式來避免高速滑動時 Cell 的繪制過程墓陈，相關實現(xiàn)見這個項目：VVeboTableViewDemo。它的原理是第献，當滑動時贡必，松開手指后，立刻計算出滑動停止時 Cell 的位置庸毫，并預先繪制那個位置附近的幾個 Cell仔拟，而忽略當前滑動中的 Cell。這個方法比較有技巧性飒赃，并且對于滑動性能來說提升也很大利花，唯一的缺點就是快速滑動中會出現(xiàn)大量空白內容。如果你不想實現(xiàn)比較麻煩的異步繪制但又想保證滑動的流暢性盒揉，這個技巧是個不錯的選擇晋被。

全局并發(fā)控制

當我用 concurrent queue 來執(zhí)行大量繪制任務時兑徘，偶爾會遇到這種問題：

ios_dispatch_blocked_1 ios_dispatch_blocked_2

大量的任務提交到后臺隊列時刚盈，某些任務會因為某些原因（此處是 CGFont 鎖）被鎖住導致線程休眠，或者被阻塞挂脑，concurrent queue 隨后會創(chuàng)建新的線程來執(zhí)行其他任務藕漱。當這種情況變多時，或者 App 中使用了大量 concurrent queue 來執(zhí)行較多任務時崭闲，App 在同一時刻就會存在幾十個線程同時運行肋联、創(chuàng)建、銷毀刁俭。CPU 是用時間片輪轉來實現(xiàn)線程并發(fā)的橄仍，盡管 concurrent queue 能控制線程的優(yōu)先級，但當大量線程同時創(chuàng)建運行銷毀時，這些操作仍然會擠占掉主線程的 CPU 資源侮繁。ASDK 有個 Feed 列表的 Demo：SocialAppLayout虑粥，當列表內 Cell 過多，并且非诚芰ǎ快速的滑動時娩贷，界面仍然會出現(xiàn)少量卡頓，我謹慎的猜測可能與這個問題有關。

使用 concurrent queue 時不可避免會遇到這種問題，但使用 serial queue 又不能充分利用多核 CPU 的資源储矩。我寫了一個簡單的工具 YYDispatchQueuePool遵湖，為不同優(yōu)先級創(chuàng)建和 CPU 數(shù)量相同的 serial queue，每次從 pool 中獲取 queue 時罗侯，會輪詢返回其中一個 queue。我把 App 內所有異步操作，包括圖像解碼南蓬、對象釋放、異步繪制等哑了，都按優(yōu)先級不同放入了全局的 serial queue 中執(zhí)行赘方，這樣盡量避免了過多線程導致的性能問題。

更高效的異步圖片加載

SDWebImage 在這個 Demo 里仍然會產生少量性能問題弱左，并且有些地方不能滿足我的需求窄陡，所以我自己實現(xiàn)了一個性能更高的圖片加載庫。在顯示簡單的單張圖片時拆火，利用 UIView.layer.contents 就足夠了跳夭，沒必要使用 UIImageView 帶來額外的資源消耗，為此我在 CALayer 上添加了 setImageWithURL 等方法们镜。除此之外币叹，我還把圖片解碼等操作通過 YYDispatchQueuePool 進行管理，控制了 App 總線程數(shù)量模狭。

其他可以改進的地方

上面這些優(yōu)化做完后颈抚，微博 Demo 已經非常流暢了，但在我的設想中嚼鹉，仍然有一些進一步優(yōu)化的技巧贩汉，但限于時間和精力我并沒有實現(xiàn)，下面簡單列一下：

列表中有不少視覺元素并不需要觸摸事件锚赤，這些元素可以用 ASDK 的圖層合成技術預先繪制為一張圖匹舞。

再進一步減少每個 Cell 內圖層的數(shù)量，用 CALayer 替換掉 UIView线脚。

目前每個 Cell 的類型都是相同的赐稽，但顯示的內容卻各部一樣叫榕，比如有的 Cell 有圖片，有的 Cell 里是卡片姊舵。把 Cell 按類型劃分翠霍，進一步減少 Cell 內不必要的視圖對象和操作，應該能有一些效果蠢莺。

把需要放到主線程執(zhí)行的任務劃分為足夠小的塊寒匙，并通過 Runloop 來進行調度，在每個 Loop 里判斷下一次 VSync 的時間躏将，并在下次 VSync 到來前锄弱，把當前未執(zhí)行完的任務延遲到下一個機會去。這個只是我的一個設想祸憋，并不一定能實現(xiàn)或起作用会宪。

如何評測界面的流暢度

最后還是要提一下，“過早的優(yōu)化是萬惡之源”蚯窥，在需求未定掸鹅，性能問題不明顯時，沒必要嘗試做優(yōu)化拦赠，而要盡量正確的實現(xiàn)功能巍沙。做性能優(yōu)化時，也最好是走修改代碼 -> Profile -> 修改代碼這樣一個流程荷鼠，優(yōu)先解決最值得優(yōu)化的地方句携。

如果你需要一個明確的 FPS 指示器，可以嘗試一下 KMCGeigerCounter允乐。對于 CPU 的卡頓矮嫉，它可以通過內置的 CADisplayLink 檢測出來；對于 GPU 帶來的卡頓牍疏，它用了一個 1x1 的 SKView 來進行監(jiān)視蠢笋。這個項目有兩個小問題：SKView 雖然能監(jiān)視到 GPU 的卡頓，但引入 SKView 本身就會對 CPU/GPU 帶來額外的一點的資源消耗鳞陨；這個項目在 iOS 9 下有一些兼容問題昨寞，需要稍作調整。

我自己也寫了個簡單的 FPS 指示器：FPSLabel 只有幾十行代碼炊邦，僅用到了 CADisplayLink 來監(jiān)視 CPU 的卡頓問題编矾。雖然不如上面這個工具完善熟史，但日常使用沒有太大問題馁害。

最后，用 Instuments 的 GPU Driver 預設蹂匹，能夠實時查看到 CPU 和 GPU 的資源消耗碘菜。在這個預設內，你能查看到幾乎所有與顯示有關的數(shù)據(jù)，比如 Texture 數(shù)量忍啸、CA 提交的頻率仰坦、GPU 消耗等，在定位界面卡頓的問題時计雌，這是最好的工具悄晃。