看到一篇關于講列表優化，講的很好，特轉摘過來。原文鏈接
這一篇文章是iOS性能優化系列文章的的第二篇，主要內容是關于列表流暢度的優化。在具體內容的闡述過程中會結合性能優化的總體原則進行分析，所以建議大家在閱讀這篇文章前先閱讀一下上一篇文章：iOS性能優化系列篇之“優化總體原則”。 希望后面有時間把這個系列更新下去，包括內存等其他方面的專項優化內容。希望這篇文章能夠給大家在列表流暢度優化方面帶來一點點啟示。
和上一篇綜述性質的文章不同，這一篇文章工程實用性更強一些，更多的是一些優化技術細節。文中討論了許多可能影響列表流暢度的因素，由于2018 WWDC里面講述了大量的關于性能優化相關的內容，因此本文也在相關的內容里面加入2018 WWDC的性能優化部分。
讀者可將本體提及的優化手段或者原理應用到自己的項目中去。但是希望大家在優化過程中，要結合自己的項目具體問題具體分析，因為本文討論的影響流暢度的因素，可能并不是你的應用流暢性不佳的瓶頸，根據我的經驗，大部分流暢的問題都是業務邏輯導致的，反倒什么離屏渲染啊之類大家耳熟能詳的流暢度的影響因素在實際項目中并沒有想象的那么大。如果不經實地測量就盲目應用一些優化手段，可能會導致過度優化，事倍功半。
卡頓產生的原因
在總體原則篇中提到，五大原則中的其中一個就是要理解優化任務的底層運行機制，因為只有深入了解底層機制才能更好的有針對性的提出更優的解決方案，所以在進行列表流暢度優化前，我們一定要弄清楚一個view從創建到顯示到屏幕上都經歷了那些過程，在這些過程中那些方面可能會導致性能瓶頸，以及造成卡頓的底層原因是什么。
我們知道iOS設備大部分情況下，屏幕刷新頻率是60hz(ProMotion下是120hz)，也就是每隔16.67ms會進行一次屏幕刷新。每次刷新時，需要CPU和GPU配合完成一次圖像顯示。其主要流程如下：
應用內：
布局。CPU創建view，設置其屬性（frame、background color等等）
創建backing images。setContents將一個image傳給layer或者通過 drawRect：或 drawLayer:inContext繪制
準備。Core Animation將layer發送到render server前的一些準備工作，比如圖片解碼等。
提交。Core animation將layers打包通過 IPC (Inter-Process Communication) 發送到render server
應用外（render server）:
設置用來渲染的OpenGL triangles（如果是有動畫，還需計算動畫layer的屬性的中間值）。
渲染這些可見的triangles，將結果提交到視頻緩沖區
視頻控制器以60hz頻率讀取緩沖區內容顯示到顯示器，如果在16.67ms內沒有完成提交，則會被丟棄。
從上面的圖中可以看到，在view顯示的過程中，CPU和GPU都各自承擔了不同的任務，CPU和GPU不論哪個阻礙了顯示流程，都會造成掉幀現象。所以優化方法也需要分別對CPU和GPU壓力進行評估和優化，在CPU和GPU壓力之間找到性能最優的平衡點， 無論過度優化哪一方導致另一方壓力過大都會造成整體FPS性能的下降。而尋找平衡點的過程則因項目特點不同而不同，并沒有一套通用的方法，需要我們用instrument等性能評測工具，根據實際app的性能度量結果去做優化，不能憑空亂猜。
CPU優化
我們先看table view在滑動過程中CPU占用的情況。
從上圖可以看出，在滑動過程中CPU占用特點是：
滑動時CPU占用率高、空閑時CPU占用率底
主線程CPU占用高、子線程CPU占底
根據上述特點我們可以做如下優化：
預加載，空間換時間
為什么要預加載：
滑動時CPU占用過高，16.67ms內無法完成內容提交—>導致卡頓
滑動時CPU占用率高，但空閑時CPU占用率底—>CPU占用分布特點
利用CPU空閑時間預加載，降低滑動時CPU占用峰值—>解決卡頓
通過預加載我們希望達到的CPU理想占用效果如下：
預加載內容：
靜態資源預加載
如何預加載：創建列表前找時機加載。如啟動時、viewDidLoad、runloop空閑時等等
加載內容：緩存在磁盤的網絡數據、圖片、其他滑動時需要的耗時的資源
注意事項：在預加載帶來的滑動性能提升和內存占用增加之間權衡
動態資源預加載
如何預加載：
在iOS10以后，UITableView和UICollectionView提供了預加載機制，iOS12開始prefeatching做了優化，不再與cell的加載同時并發進行，而是cell加載完成之后串行開始prefeatch，從而優化了流暢度
iOS10以前，也可以自己實現類似機制，主要利用的機制有：
UIScrollViewDelegate 提供滑動開始、結束、速度時機回調
indexPathsForRowsInRect 和layoutAttributesForElementsInRect 提供預加載的indexPath
可根據滑動速度動態調整加載的量
加載內容：
Cell的高度、subView的布局計算
拉取網絡數據
網絡圖片
其他耗時的資源
注意事項：
在預加載帶來的滑動性能提升和內存占用增加之間權衡
注意數據過期的問題
WWDC 2018中講到了一個iOS12的底層優化點，蘋果工程師在性能調優的時候發現一個導致丟幀的奇怪case，在沒有其他后臺線程運行、只有滑動的情況下，會比有少量的后臺線程的情況更容易掉幀。通過調研CPU的調度算法發現，在僅有滑動的情況下，為了省電，CPU占用會保持比較底，但是這樣CPU會花更多的時間來計算，就會導致可能錯過這一幀。所以iOS12中，會把UIKit框架上所有的信息（滑動信息以及滑動frame的關鍵時間點）傳遞給底層CPU性能控制器，這樣CPU可以更智能調度以在frame截止的時機內完成CPU計算。這部分屬于系統底層的優化，對于應用開發者只要應用運行在iOS12就可以獲得這部分優化。
多線程
為什么要多線程：
UIKit 大部分API只能在主線程調用, 特別是一些耗時的操作，如view的創建，布局和渲染默認都是在主線程上完成
主線程任務過多，16.67ms內無法完成，導致卡頓
將非主線程必須的任務，移到子線程中，減輕主線程負擔
多核處理器，多線程可以發揮多核并發優勢，提高性能
最終通過多線程，我們希望CPU占用達到如下效果：
使用多線程注意事項：
主線程最大程度上減少非主線程必須的任務
控制子線程數量在合理的范圍內，防止線程爆炸，一定要根據項目實際CPU占用特點，有針對的使用多線程。
可在子線程中進行的任務
圖片解碼
文本渲染，UILabel和UITextview都是在主線程渲染的，當顯示大量文本時，CPU的壓力會非常大。特別是對于一些資訊類應用，這部分耗時相當大，對流暢度的影響也十分明顯。對此可以自定義文本控件，用TextKit或最底層的CoreText對文本異步繪制。盡管這實現起來非常麻煩，但其帶來的優勢也非常大，CoreText對象創建好后，能直接獲取文本的寬高等信息，避免了多次計算（調整 UILabel 大小時算一遍、UILabel 繪制時內部再算一遍）；CoreText對象占用內存較少，可以緩存下來以備稍后多次渲染。用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到后臺線程進行以避免阻塞主線程。
UIView的drawRect, 由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺線程進行
耗時的業務邏輯
緩存
緩存的內容可以是
UIView。 view的創建代價很大，一些可以復用的view可以cache。例如UITableView為我們實現的了cell的復用。
圖片。 圖片涉及磁盤IO和解碼，十分耗時，可以考慮緩存。
布局。其實不僅僅是cell的高度可以緩存，如果cell里面有大量的文字圖片等復雜元素，cell的subView的布局也可以在第一次計算好，用Model的key來緩存。避免頻繁多次的調整布局屬性。在滑動列表（UITableView和UICollectionView）中強烈不建議使用Autolayout。隨著視圖數量的增長，Autolayout帶來的 CPU 消耗會呈指數級上升。
數據， 網絡拉取的數據或者db中的數據
其他創建耗時，可重復利用的資源。 如NSDateFormatter等
更優的實現方式
這里說的更優的實現方式，主要是指為了實現同一功能或者效果，CPU占用更小的實現方式。這部分包括的內容其實非常多，也很雜。受限于篇幅和水平有限，這里筆者僅羅列一些比較常見的點，并針對其中比較重要的drawRect優化和圖片優化內容做進一步的講解。
drawRect優化
圖片優化
算法的時間復雜度優化。我們知道算法的時間復雜 O(1) < O(log n) < O (n) < O(n^2)... 大家可能覺得iOS開發過程中使用的算法并不多，算法對性能影響并不明顯。其實不然，舉iOS中的一個例子：IGListDiff采用空間換時間的方式，使得比較的算法復雜度從 O(n^2) 變成 O(n)。IGListKit-diff-實現簡析 。還比如不同容器的選擇，會帶來不同的查找、插入、刪除的時間復雜度，在大的數據量下也會帶來不同的性能表現。
storyboard VS 代碼創建view
frame VS autolayout autolayout性能度量，iOS12優化了autolayout的性能，耗時由指數變為線性耗時，
UIView VS CAlayer 后者更輕量，在不需要處理觸摸事件的場景可以考慮使用CAlayer。UIView層級太多，會導致創建、布局等較耗時，可以盡量扁平化，甚至可以異步在子線程畫到一個Image上。
UIImageView animationImages VS CAAnimation
NSDateFormatter dateFromString VS NSDate dateWithTimeIntervalSince1970:
更優的業務邏輯。大家平時在性能優化的時候，已經要優先去排查業務邏輯這塊，仔細梳理。個人經驗很多性能問題都是由不合理的業務邏輯導致的。使用Instruments的time profiler工具仔細觀察耗時的業務邏輯，做好梳理和優化工作。
其他
下面詳細講下drawRect優化和圖片優化
drawRect優化
首選使用CAShapeLayer替代drawRect，在大多數場景下，都可以使用CAShapeLayer替代drawRect。二者對比：
CAShapeLayer使用GPU硬件加速，更快。GPU對高度并行的浮點運算做了優化。而drawRect使用CPU繪圖，相比之下會很慢，而且十分耗CPU
CAShapeLayer占用內存更少。因為不會創建寄宿圖，因此無論多大都不會占用太多內存。而drawRect圖層每次重繪的時候都需要重新抹掉內存然后重新分配，十分占用內存。詳見內存惡鬼drawRect
CAShapeLayer不會被圖層邊界剪裁掉
CAShapeLayer不會出現像素化，通過矢量圖繪制而不是bitmap
CAShapeLayer有很多屬性可以方便的做動畫，比如使用strokeStart和strokeEnd可以做出了很漂亮的動畫
異步繪制。可以使用異步繪制的方式，在子線程繪制好獲得image，然后交給主線程。
Dirty Rectangles: 可以使用setNeedsDisplayInRect標記Dirty Rectangles，僅重繪指定區域，也會極大提升性能。
圖片優化
在大多數app中，圖片絕對是使用最頻繁的資源之一，我們知道磁盤和網絡的加載速度和內存比要慢很多，而一般圖片都比較大，I/O十分耗時。而且圖片還涉及解碼，也是一項十分消耗CPU的工作，因此圖片的優化對app的性能有著十分關鍵的作用。
在之前將的優化總體原則的時候，我們說過需要理解優化對象的運行機制，我們先了解下圖片顯示原理：
從磁盤或者網絡加載一張圖片，此時圖片未解碼
圖片賦值給UIImageView
在主線程中解碼，非常耗時的 CPU 操作
CATransaction捕捉到layer tree的變化
在main run loop, 提交transaction：
如果圖片數據沒對齊，Core Animation會拷貝一份數據，進行字節對齊
GPU處理位圖數據，進行渲染
針對上面的過程，我們的優化手段主要有：
異步下載/讀取圖片，這樣可以防止這項十分耗時的操作阻塞主線程。
預處理圖片大小。如果UIImage大小和UIImageview的size不同的話，CPU需要提前預處理，這是一項十分消耗CPU的工作，特別是在一些縮略圖的場景下，如果使用了十分大的圖片，不僅會帶來很大的CPU性能問題，還會導致內存問題。我們可以用instruments Core Animation 的Misaligned Image debug選項來發現此問題。這里可以使用ImageIO中的CGImageSourceCreateThumbnailAtIndex等相關方法進行后臺異步downsample，可以在CPU和內存上獲得很好的性能。
UIImageView frame取整。視圖或圖片的點數(point)，不能換算成整數的像素值（pixel），導致顯示視圖的時候需要對沒對齊的邊緣進行額外混合計算，影響性能。借助ceilf()、floorf()、CGRectIntegral()等將小數點后數據除去即可。我們可以用instruments Core Animation 的Misaligned Image debug選項來發現此問題
使用mmap，避免mmcpy。解碼圖片 iOS從磁盤加載一張圖片，使用UIImageVIew顯示在屏幕上，需要經過以下步驟：從磁盤拷貝數據到內核緩沖區、從內核緩沖區復制數據到用戶空間。使用mmap內存映射，省去了上述第2步數據從內核空間拷貝到用戶空間的操作，具體可以參考FastImageCache的實現
子線程解碼。如果我們使用imgView.image = img; 如果圖片沒有解碼，則會在主線程進行解碼等操作，會極大影響滑動的流暢性。
字節對齊，如果數據沒有字節對齊，Core Animation會再拷貝一份數據，進行字節對齊，也是十分消耗CPU。
iOS 12引入了Automatic Backing Store這項技術。通過在保證色彩不失真的基礎上，使用更少的數據量，去表達一個像素的顏色。在UIView.draw()、UIGraphicsImageRenderer、UIGraphicsImageRenderer.Range中是默認開啟的。其實我們自己可以針對圖片的特點，采用更少的byte來標示一個像素占用的空間，FastImageCache就是使用這種優化手段，有興趣的讀者可以去了解一下。
我們日常開發中可以使用一些比較經典的圖片緩存庫，比如SDWebImage、 FastImageCache、YYImage等。這些第三方庫替我們完成的大部分優化的工作，而且接口也十分友好。我們可也使用這些第三方庫幫助我們獲得更好的性能體驗。
GPU優化
CPU和GPU之所以大不相同，是由于其設計目標的不同，它們分別針對了兩種不同的應用場景。CPU需要很強的通用性來處理各種不同的數據類型，同時又要邏輯判斷又會引入大量的分支跳轉和中斷的處理。這些都使得CPU的內部結構異常復雜。而GPU面對的則是類型高度統一的、相互無依賴的大規模數據和不需要被打斷的純凈的計算環境。所以CPU擅長邏輯控制，串行的運算。和通用類型數據運算不同，GPU擅長的是大規模并發計算，這也正是密碼破解等所需要的。所以GPU除了圖像處理，也越來越多的參與到計算當中來。
iOS中GPU在顯示方面的工作主要是：接收提交的紋理（Texture）和頂點描述（三角形），進行變換（transform）、混合并渲染，然后輸出到屏幕上。屏幕上的內容，主要也就是紋理（圖片）和形狀（三角模擬的矢量圖形）兩類。一般來說，CALayer的大多數屬性都是使用GPU來繪制的。雖然GPU在處理圖像等渲染是速度很快，但如果開發過程中使用不當，仍會導致GPU占用過高，渲染速度跟不上屏幕刷新導致卡頓。
對GPU消耗比較高的操作有：
紋理的渲染
所有的 Bitmap，包括圖片、文本、柵格化的內容，最終都要由內存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是 GPU 調整和渲染 Texture 的過程，都要消耗不少 GPU 資源。當在較短時間顯示大量圖片時（比如 TableView 存在非常多的圖片并且快速滑動時），CPU 占用率很低，GPU 占用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時間內大量圖片的顯示，盡可能將多張圖片合成為一張進行顯示。
當圖片過大，超過 GPU 的最大紋理尺寸時，圖片需要先由 CPU 進行預處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。目前來說，iPhone 4S 以上機型，紋理尺寸上限都是 4096x4096，更詳細的資料可以看這里：iosres.com。所以，盡量不要讓圖片和視圖的大小超過這個值。
視圖的混合 (Composing)
當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過于復雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當盡量減少視圖數量和層次，并在不透明的視圖里標明 opaque 屬性以避免無用的 Alpha 通道合成。當然，這也可以用上面的方法，把多個視圖預先渲染為一張圖片來顯示。
圖形的生成
CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發離屏渲染（offscreen rendering），而離屏渲染通常發生在 GPU 中。當一個列表視圖中出現大量圓角的 CALayer，并且快速滑動時，可以觀察到 GPU 資源已經占滿，而 CPU 資源消耗很少。這時界面仍然能正常滑動，但平均幀數會降到很低。為了避免這種情況，可以嘗試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉嫁到 CPU 上去。對于只需要圓角的某些場合，也可以用一張已經繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
常用優化手段
減少視圖數量和層次，可把多個視圖預先渲染為一張圖片
不要讓圖片和視圖超過GPU可渲染的最大尺寸
視圖不透明
防止離屏渲染 OpenGL 中，GPU 屏幕渲染有以下兩種方式：
On-Screen Rendering 意為當前屏幕渲染，指的是 GPU 的渲染操作是在當前用于顯示的屏幕緩沖區中進行。
Off-Screen Rendering 意為離屏渲染，指的是 GPU 在當前屏幕緩沖區以外新開辟一個緩沖區進行渲染操作。
相比于當前屏幕渲染，離屏渲染的代價是很高的，主要體現在兩個方面：
創建新緩沖區 要想進行離屏渲染，首先要創建一個新的緩沖區。
上下文切換 離屏渲染的整個過程，需要多次切換上下文環境：先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結束以后，將離屏緩沖區的渲染結果顯示到屏幕上有需要將上下文環境從離屏切換到當前屏幕。而上下文環境的切換是要付出很大代價的。
所以在圖形生成的步驟我們要盡可能的避免離屏渲染
優化工具
iOS開發中，在GPU優化上，我們一般使用instruments中的Core Animation工具來進行滑動流暢度優化，在Core Animation中我們可也看到列表滑動過程中的FPS，其中有一些很有用的debug選項，幫助我們找到代碼中有性能問題的代碼。下面是一些常用的選項：
Color Blended Layers
Color Blended Layers是用來檢測個半透明圖層的混合區，渲染程度對屏幕中的混合區域進行綠到紅的高亮。因為計算混合區的顏色時，導致overdraw，消耗一定的GPU資源，是導致滑動性能的一個因素。所以盡量要盡量避免
在開發過程中，避免Blended Layers的手段有
設置opaque屬性YES
View背景顏色不透明
Image不含有透明通道
需要特別注意的是，在iOS8之后，UILabel使用的是CALayer作為底圖層，而在iOS8開始，UILabel的底圖層變成了_UILabelLayer，繪制文本也有所改變。UILabel顯示中文時，還需masksToBounds = YES。
Color Hits Green and Misses Red Color Hits Green and Misses Red用來檢測是否正確使用shouldRasterize，當緩存需要重新生成時，紅色高亮rasterized layers，當設置shouldRasterize=YES，會將layer預先渲染成位圖，并緩存。以提高性能。但是如果cache頻繁重復地生成，表示shouldRasterize可能帶來的是負面的性能影響。因此shouldRasterize適用于渲染耗時、圖像內容不變的情況，在列表中由于內容要頻繁變化，因此不推薦使用此屬性
Color Copied Images
大多數時，Core Animation只需要提交原始圖片的指針到render server，不涉及內存copy。但是一些情況下，Core Animation不得不copy一份圖片發送到render server。蘋果的GPU只解析32bit的顏色格式，如果圖片顏色格式不對，CPU會預先格式轉換。copy images是非常耗CPU的操作，一定要避免。
Color Misaligned Images 被拉伸縮放的圖片、無法正確對齊到像素的圖片（可能有不是整數的的坐標）。是耗CPU的操作
Color Offscreen-Rendered Yellow
GPU在當前屏幕緩沖區外開辟新的緩沖區進行渲染, 屏幕外緩沖區和當前屏幕緩沖區上下文切換是十分耗時的操作
引起Offscreen-Rendered的操作有：
- 圓角 cornerRadius masksToBounds同時設置
- 設置shadow
- 開啟光柵化 shouldRasterize=YES.CALayer 有一個 shouldRasterize 屬性，將這個屬性設置成 true 后就開啟了光柵化。開啟光柵化后會將圖層繪制到一個屏幕外的圖像，然后這個圖像將會被緩存起來并繪制到實際圖層的 contents 和子圖層，對于有很多的子圖層或者有復雜的效果應用，這樣做就會比重繪所有事務的所有幀來更加高效。但是光柵化原始圖像需要時間，而且會消耗額外的內存。光柵化也會帶來一定的性能損耗，是否要開啟就要根據實際的使用場景了，圖層內容頻繁變化時不建議使用。最好還是用 Instruments 比對開啟前后的 FPS 來看是否起到了優化效果。
- 圖層蒙板
避免Offscreen-Rendered的方式可以其他方式實現圓角、shadow + shadowPath等。
總結
本文的講了一些造成卡頓的原因，以及CPU和GPU優化的常用技巧和工具，大家在優化的時候可以作為參考。但不要把優化手段局限在這些方面，不同的應用有各自不同的特點，一定要具體問題具體分析。甚至可以跳出技術范疇，在交互方面做一些文章，比如在減少列表每次從服務器獲取的數據數量、采用用戶手動點擊觸發獲取更多數據而不是滑動過程中自動獲取、使用交互動畫等都可以極大改善用戶的滑動體驗。
最后還是要強調一下我上一篇文章講的優化時候需要注意的幾大原則，這樣才能在優化過程中有更好的全局觀，盡量少走彎路，希望大家能夠在優化過程中時刻牢記。
其他耗時的資源
注意事項：
在預加載帶來的滑動性能提升和內存占用增加之間權衡
注意數據過期的問題
WWDC 2018中講到了一個iOS12的底層優化點，蘋果工程師在性能調優的時候發現一個導致丟幀的奇怪case，在沒有其他后臺線程運行、只有滑動的情況下，會比有少量的后臺線程的情況更容易掉幀。通過調研CPU的調度算法發現，在僅有滑動的情況下，為了省電，CPU占用會保持比較底，但是這樣CPU會花更多的時間來計算，就會導致可能錯過這一幀。所以iOS12中，會把UIKit框架上所有的信息（滑動信息以及滑動frame的關鍵時間點）傳遞給底層CPU性能控制器，這樣CPU可以更智能調度以在frame截止的時機內完成CPU計算。這部分屬于系統底層的優化，對于應用開發者只要應用運行在iOS12就可以獲得這部分優化。
