一 、?ASDK簡介
ASDK是AsyncDisplayKit的簡稱，?是最初由Facebook的Paper應用程序開發(fā)的UI框架，主要用來解決盡可能緩解主線程的壓力，提升應用程序的性能及使用流暢性。
ASDK 的作者是 Scott Goodson (Linkedin)，
他曾經(jīng)在蘋果工作，負責 iOS 的一些內置應用的開發(fā)，比如股票、計算器、地圖、鐘表、設置、Safari 等，當然他也參與了 UIKit framework 的開發(fā)。后來他加入 Facebook 后，負責 Paper 的開發(fā)，創(chuàng)建并開源了 AsyncDisplayKit。
二、影響應用程序卡頓的原因
通常來說，在顯示器發(fā)出的VSync 信號到來后（垂直同步信號），App 主線程開始在CPU 計算好顯示內容（比如視圖的創(chuàng)建、布局計算、圖片解碼、文本繪制等）提交到 GPU中，由 GPU 進行變換、合成、渲染，GPU 渲染完成后將渲染結果放入幀緩沖區(qū)，等待下一次 VSync 信號到來，隨后視頻控制器會按照 VSync?信號逐行讀取幀緩沖區(qū)的數(shù)據(jù)，經(jīng)過數(shù)模轉換傳遞給顯示器顯示。
由于垂直同步的機制，如果在一個 VSync 時間內，CPU 或者 GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留之前的內容不變。這就是界面卡頓的原因。
對于CPU：
1、對象創(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)建新對象要小，那么這類對象應當盡量放到一個緩存池里復用。
2、對象調整
對象的調整也經(jīng)常是消耗 CPU 資源的地方。這里特別說一下 CALayer：CALayer 內部并沒有屬性，當調用屬性方法時，它內部是通過運行時?resolveInstanceMethod 為對象臨時添加一個方法，并把對應屬性值保存到內部的一個 Dictionary 里，同時還會通知 delegate、創(chuàng)建動畫等等，非常消耗資源。UIView 的關于顯示相關的屬性（比如 frame/bounds/transform）等實際上都是 CALayer 屬性映射來的，所以對 UIView 的這些屬性進行調整時，消耗的資源要遠大于一般的屬性。對此你在應用中，應該盡量減少不必要的屬性修改。
當視圖層次調整時，UIView、CALayer 之間會出現(xiàn)很多方法調用與通知，所以在優(yōu)化性能時，應該盡量避免調整視圖層次、添加和移除視圖。
3、對象銷毀
對象的銷毀雖然消耗資源不多，但累積起來也是不容忽視的。通常當容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。同樣的，如果對象可以放到后臺線程去釋放，那就挪到后臺線程去。這里有個小 Tip：把對象捕獲到 block 中，然后扔到后臺隊列去隨便發(fā)送個消息以避免編譯器警告，就可以讓對象在后臺線程銷毀了。
4、布局計算
視圖布局的計算是 App 中最為常見的消耗 CPU 資源的地方。如果能在后臺線程提前計算好視圖布局、并且對視圖布局進行緩存，那么這個地方基本就不會產(chǎn)生性能問題了。
不論通過何種技術對視圖進行布局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調整上。上面也說過，對這些屬性的調整非常消耗資源，所以盡量提前計算好布局，在需要時一次性調整好對應屬性，而不要多次、頻繁的計算和調整這些屬性。
5、Autolayout
Autolayout 是蘋果本身提倡的技術，在大部分情況下也能很好的提升開發(fā)效率，但是 Autolayout 對于復雜視圖來說常常會產(chǎn)生嚴重的性能問題。隨著視圖數(shù)量的增長，Autolayout 帶來的 CPU 消耗會呈指數(shù)級上升。
6、文本計算
如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源，并且不可避免。如果你對文本顯示沒有特殊要求，可以參考下 UILabel 內部的實現(xiàn)方式：用 text.boundingRect(with: , options: , attributes: , context: ) 來計算文本寬高，用 ?text.draw(at: , withAttributes: ) 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到后臺線程進行以避免阻塞主線程。
7、文本渲染
屏幕上能看到的所有文本內容控件，包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的。常見的文本控件 （UILabel、UITextView 等），其排版和繪制都是在主線程進行的，當顯示大量文本時，CPU 的壓力會非常大。對此解決方案只有一個，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對文本異步繪制。盡管這實現(xiàn)起來非常麻煩，但其帶來的優(yōu)勢也非常大，CoreText 對象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計算（調整 UILabel 大小時算一遍、UILabel 繪制時內部再算一遍）；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)建圖片并顯示這樣一個過程。這個最常見的地方就是 drawRect(rect: CGRect)? 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺線程進行。
對于GPU：
相對于 CPU 來說，GPU 能干的事情比較單一：接收提交的紋理（Texture）和頂點描述（三角形），應用變換（transform）、混合并渲染，然后輸出到屏幕上。通常能看到的內容，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類。
1、紋理的渲染
所有的 Bitmap，包括圖片、文本、柵格化的內容，最終都要由內存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是 GPU 調整和渲染 Texture 的過程，都要消耗不少 GPU 資源。當在較短時間顯示大量圖片時（比如 TableView 存在非常多的圖片并且快速滑動時），CPU 占用率很低，GPU 占用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時間內大量圖片的顯示，盡可能將多張圖片合成為一張進行顯示。
當圖片過大，超過 GPU 的最大紋理尺寸時，圖片需要先由 CPU 進行預處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。
2、視圖的混合
當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過于復雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當盡量減少視圖數(shù)量和層次，并在不透明的視圖里標明 opaque 屬性以避免無用的 Alpha 通道合成。當然，這也可以用上面的方法，把多個視圖預先渲染為一張圖片來顯示。
3、圖形的生成
CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染（offscreen rendering），而離屏渲染通常發(fā)生在 GPU 中。當一個列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動時，可以觀察到 GPU 資源已經(jīng)占滿，而 CPU 資源消耗很少。這時界面仍然能正常滑動，但平均幀數(shù)會降到很低。為了避免這種情況，可以嘗試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉嫁到 CPU 上去。對于只需要圓角的某些場合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
三、ASDK 的基本原理
ASDK 認為，阻塞主線程的任務，主要分為三大類。文本和布局的計算、渲染、解碼、繪制都可以通過各種方式異步執(zhí)行，但 UIKit 和 Core Animation 相關操作必需在主線程進行。ASDK 的目標，就是盡量把這些任務從主線程挪走，而挪不走的，就盡量優(yōu)化性能。
傳統(tǒng)的CALayer(屬性改變/動畫產(chǎn)生)是通過delegate來通知UIView的，View 持有 Layer 用于顯示，View 中大部分顯示屬性實際是從 Layer 映射而來；Layer 的 delegate 在這里是 View，當其屬性改變、動畫產(chǎn)生時，View 能夠得到通知。UIView 和 CALayer 不是線程安全的，并且只能在主線程創(chuàng)建、訪問和銷毀。
ASDK 為此創(chuàng)建了 ASDisplayNode 類，嘗試對 UIKit 組件進行封，包裝了常見的視圖屬性（比如frame、bounds、alpha、transform、backgroundColor、superNode、subNodes等）
然后它用 UIView->CALayer 相同的方式，實現(xiàn)了 ASNode->UIView 這樣一個關系。
當不需要響應觸摸事件時，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，可以把代碼中的 UIView 替換為 ASNode，很大的降低了開發(fā)和學習成本，同時能獲得 ASDK 底層大量的性能優(yōu)化。為了方便使用， ASDK 把大量常用控件都封裝成了 ASNode 的子類，比如 Button、Control、Cell、Image、ImageView、Text、TableView、CollectionView 等。利用這些控件，可以盡量避免直接使用 UIKit 相關控件，以獲得更完整的性能提升。
四、ASDK的使用
1、ASDK的安裝
ASDK我們使用CocoaPods來管理，?pod'Texture'，'> = 2.0'??
2、ASDisplayNode介紹?
Texture的基本單位是node。?ASDisplayNode是一種抽象UIView，而這又是一種抽象CALayer。與只能在主線程上使用的視圖不同，節(jié)點是線程安全的，可以在后臺線程上并行實例化和配置它們的整個層次結構。
在 ASDK 中的渲染圍繞 ASDisplayNode 進行，其過程總共有四條主線：
初始化 ASDisplayNode 對應的 UIView 或者 CALayer
在當前視圖進入視圖層級時執(zhí)行 setNeedsDisplay
display 方法執(zhí)行時，向后臺線程派發(fā)繪制事務
注冊成為 RunLoop 觀察者，在每個 RunLoop 結束時回調
3、使用ASDisplayNode替換UIKit組件
以上我們可以看作是ASNode分別對基于UIKit的UILabel、UIView、UIButton、UIImageView的封裝，需要注意的是，如果加載的是網(wǎng)絡圖片要使用?ASNetworkImageNode，如果是本地圖片使用ASImageNode。
4、列表卡頓的優(yōu)化
在基于UIkit的TableView的cell中，常常會有大量的UI繪制、文本渲染、布局計算等。對于簡單的cell或者單一的cell，加上本身的cell的復用機制其實并不會出現(xiàn)很明顯的卡頓。但當List中有N種不同樣式的cell，而屏幕只能顯示四五條甚至更少的cll時候，卡頓就會比較明顯了。使用Node 創(chuàng)建時, 不會立即在其內部新建 UIView 和 CALayer, 直到主線程第一次訪問時才會生成對應的對象, 除此之外, 還通過圖層預合成和基于 Runloop 的異步并發(fā)。
ASTableNode異于TableView之處的是，TableNode沒有復用機制，只有緩存, 每個 CellNode 都是全新的。
CellNode 與數(shù)據(jù)源沒有綁定關系: 創(chuàng)建后就算把數(shù)據(jù)源刪除, TableNode 依然可以正常展示
TableViewCell 的展示大致為: 添加空假數(shù)據(jù)子視圖 -> 數(shù)據(jù)填充 -> 刷新, 涉及布局或圖文時會更復雜
CellNode 只有一步: 添加真數(shù)據(jù)的子視圖; 因此可以直接根據(jù)業(yè)務邏輯對控件和布局做出處理, 而不用一次或多次刷新
5、ASTableNode的核心機制? 智能預加載
ASDK 可以通過滾動的方向預加載不同數(shù)量的內容
如上圖所示 ASDK 把正在滾動的 ASTableView/ASCollectionView 劃分為三種狀態(tài)：
Fetch Data
Display
Visible
上面的這三種狀態(tài)都是由 ASDK 來管理的，而每一個 ASCellNode 的狀態(tài)都是由 ASRangeController 控制，所有的狀態(tài)都對應一個 ASInterfaceState：
ASInterfaceStatePreload 當前元素貌似要顯示到屏幕上，需要從磁盤或者網(wǎng)絡請求數(shù)據(jù)；
ASInterfaceStateDisplay 當前元素非常可能要變成可見的，需要進行異步繪制；
ASInterfaceStateVisible 當前元素最少在屏幕上顯示了 1px。
當用戶滾動當前視圖時，ASRangeController就會修改不同區(qū)域內元素的狀態(tài)：
在滾動方向（Leading）上 Fetch Data 區(qū)域會是非滾動方向（Trailing）的兩倍，ASDK 會根據(jù)滾動方向的變化實時改變緩沖區(qū)的位置；在向下滾動時，下面的 Fetch Data 區(qū)域就是上面的兩倍，向上滾動時，上面的 Fetch Data 區(qū)域就是下面的兩倍。
這里的兩倍并不是一個確定的數(shù)值，ASDK 會根據(jù)當前設備的不同狀態(tài)，改變不同區(qū)域的大小，但是滾動方向的區(qū)域總會比非滾動方向大一些。
智能預加載能夠根據(jù)當前的滾動方向，自動改變當前的工作區(qū)域，選擇合適的區(qū)域提前觸發(fā)請求資源、渲染視圖以及異步布局等操作，讓視圖的滾動達到真正的流暢。
