iOS性能優化系列篇之“清單流暢度優化”

原文作者：Hello_Vincent

原文位址：

https://juejin.im/post/5b72aaf46fb9a009764bbb6a#heading-1

這一篇文章是iOS性能優化系列文章的的第二篇，主要内容是關于清單流暢度的優化。在具體内容的闡述過程中會結合性能優化的總體原則進行闡述，是以建議大家在閱讀這篇文章前先閱讀一下上一篇文章：

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 消耗會呈指數級上升。具體資料可以看這個文章： pilky.me/36/。在WWDC20…
• 資料， 網絡拉取的資料或者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優化和圖檔優化

• 首選使用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的性能有着十分關鍵的作用。

談談iOS中圖檔的解壓縮

在之前将的優化總體原則的時候，我們說過需要了解優化對象的運作機制，我們先了解下圖檔顯示原理：

• 從磁盤或者網絡加載一張圖檔，此時圖檔未解碼
• 圖檔指派給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](https://link.juejin.im?target=http%3A%2F%2Fiosres.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優化的常用技巧和工具，大家在優化的時候可以作為參考。但不要把優化手段局限在這些方面，不同的應用有各自不同的特點，一定要具體問題具體分析。甚至可以跳出技術範疇，在互動方面做一些文章，比如在減少清單每次從伺服器擷取的資料數量、采用使用者手動點選觸發擷取更多資料而不是滑動過程中自動擷取、使用互動動畫等都可以極大改善使用者的滑動體驗。

最後還是要強調一下我上一篇文章講的優化時候需要注意的幾大原則，這樣才能在優化過程中有更好的全局觀，盡量少走彎路，希望大家能夠在優化過程中時刻牢記。