• 在探討iOS屏幕卡頓優化之前，首先我們來介紹屏幕成像的基本原理；

CPU與GPU

• CPU：是計算機設備的運算中心與控制中心，其主要負責對象的創建和銷毀、對象屬性的調整、布局計算、文本排版、圖片的格式轉換和解碼、圖像的繪制(Core Graphics)；
• GPU：專門用來進行圖像繪制與渲染的處理器，支持單元計算與高并發，處理效率非常高，其主要負責接收提交的紋理(Texture)和頂點描述(三角形)，應用變換(transform)、圖像的混合(合成)并渲染；

屏幕成像

• 目前計算機設備將圖像數據進行GPU渲染，采用的是光柵化技術；
• 光柵化是將一個圖元轉變為一個二維圖像的過程，二維圖像上每個點都包含了顏色、深度和紋理數據，二維圖像數據的本質就是一個二維像素矩陣；
• CRT的電子槍從上到下逐行掃描，掃描完成后顯示器就呈現一幀畫面，然后電子槍會回到初始位置準備進行下一次的掃描；
• 拿到圖像數據后，首先進行CPU的計算，完成之后將計算結果傳遞給GPU，GPU進行圖像的渲染，最后將渲染的結果放入幀緩沖區，接著視頻控制器從幀緩沖區中讀取數據，進行數模轉換，最后顯示到屏幕上；

image.png

圖像的相關概念

• 幀(Frame)：簡單理解就是視頻或者動畫中的每一張畫面；
• 幀數(Frames)：即幀的總數量，視頻或者動畫生成的總的靜態畫面數量；
• 幀率(Frame rate)：播放視頻或者動畫時，每秒顯示的幀數量稱之為幀率，其與GPU以及顯卡每秒能計算出的畫面數量有關，是根據硬件性能決定的；
• 屏幕的刷新率：指屏幕每秒刷新的次數，是固定的，一般為60HZ，也就是說每隔16.7毫秒會刷新一次屏幕；
• FPS：Frames Per Second，表示GPU每秒渲染的幀數，通過用于衡量畫面的流暢度，數值越高則表示畫面越流暢；
• 幀率與屏幕的刷新率在大多數情況下是不相等的，是造成圖像顯示異常的根本原因；
• 幀率與屏幕的刷新率可以看成是典型的生產者--消費者模式，幀率可看成生產者，快速生成圖像幀數，屏幕的刷新率可看成消費者，獲取圖像幀在屏幕上進行顯示；

畫面撕裂

• 由上述可知，圖像的顯示是視頻控制器從幀緩沖區中取出數據，顯示器經過掃描才會顯示到屏幕上，若CPU與顯卡硬件性能很強大，也就是說幀率 > 屏幕的刷新率，會出現屏幕在繪制一幀數據時，才繪制了一半，新的幀數已經產生，并且放入了幀緩沖區，此時視頻控制器從幀緩沖區取出的是新的幀數據，這就導致了在屏幕上的上半部分顯示的是上一幀的數據，下半部分顯示的是新的一幀數據，這種現象稱之為畫面撕裂；

image.png

畫面跳幀

• 若CPU與顯卡硬件性能極其強大，幀率 遠遠大于 屏幕的刷新率，會導致當前幀數據才開始繪制，下一幀的數據就已經生成放進了緩沖區，在屏幕上當前幀的數據就被下一幀數據覆蓋了，也就說當前幀被跳過了，這種現象稱之為畫面跳幀；

畫面閃爍

• 若CPU與顯卡硬件性能不高，幀率 小于 屏幕的刷新率，那么屏幕在繪制數據完一幀數據后，下一幀的數據還沒生成完畢，這就導致用戶每次在屏幕看到的是不完整的圖形，每次看到的圖形比上次要完整一些，在用戶看來整個畫面存在卡頓，閃爍，不順滑；

解決方案

• iOS官方，采用垂直同步信號+雙緩沖區來解決以上三種問題，其中垂直同步信號是用來解決畫面撕裂與畫面跳幀，雙緩沖區是用來解決畫面閃爍的；
• 垂直同步信號：垂直同步信號開啟后，CPU與GPU會等待顯示器的VSync信號發出后再進行新的一幀數據的CPU計算和GPU渲染以及緩沖區的更新；
• 雙緩沖區：采用兩個幀緩沖區來存儲GPU的處理結果，分別為Back Buffer(后緩沖區--主要用于后臺的繪制渲染)與Frame Buffer(顯示緩沖區)，GPU向Back Buffer寫入數據，一個非常重要的注意點在于Back Buffer是一個不斷寫入的過程，里面存儲的圖像數據是逐漸趨向于完整的圖像，也就說如果直接從Back Buffer取出圖像數據給視頻控制器，那么屏幕上顯示的是不完整的圖像，當Back Buffer數據寫完了之后，會將完整的圖像幀數據復制拷貝一份到Frame Buffer中，也就是說Frame Buffer中存儲的是完整的圖像幀數據，然后視圖控制器指向Frame Buffer；
• 注意??：這里說的復制拷貝，底層是通過交換兩個緩沖區的內存地址來實現的；
• 緩沖區工作流程的總結：
  • 顯示器在發出垂直同步信號之后，Back Buffer會將數據復制到Frame Buffer(緩沖區的交換)，并通知CPU/GPU計算渲染下一幀的圖像；
  • 視頻控制器讀取Frame Buffer中當前幀的圖像數據，將其顯示到屏幕上；

畫面(屏幕)卡頓

• 上述采用垂直同步信號 + 雙緩沖區機制解決了畫面撕裂，畫面跳幀和畫面閃爍的問題，但依然存在一個問題，那就是畫面的掉幀；
• 當顯示器發出垂直信號時，正常情況下GPU會將渲染完成的幀數據從Back Buffer復制到Frame Buffer，但如果圖像數據過于復雜，計算量很大，GPU仍然處于渲染處理(寫入Back Buffer)數據中，也就是說GPU處理數據的時間超過了16.7ms，即在一個屏幕刷新周期內還沒渲染完成，那么兩個緩沖區的數據不會發生交換；
• 當屏幕進入下一個刷新周期時，視頻控制器從Frame Buffer取出的數據，仍然是上一幀的數據，也就是說在兩個屏幕刷新周期內顯示的是同一幀數據，也就是所謂的掉幀(Jank)，給用戶的體驗就是畫面屏幕的卡頓，如下圖所示：

image.png

• B幀數據的CPU+GPU的處理時間超過了屏幕刷新周期時間(16.7ms)，導致A幀數據在屏幕上顯示了兩次；
• 解決方案：可采用三重緩沖區，減少畫面的掉幀頻率，但不能從根本上解決問題，且增加了CPU與GPU的計算，原理圖如下所示：

image.png

• 在第二個A展示，VSync信號發出后，直接繪制C幀數據到Back Buffer1中；
• 在第一個B展示，VSync信號發出后，繪制A幀數據到Back Buffer2中；
• 當B顯示完成，接收到VSync信號后，因為C幀數據已經在Back Buffer1中了，復制給Frame Buffer，然后直接顯示在屏幕上，
• 當C顯示完成，接收到VSync信號后，因為A幀數據已經在Back Buffer2中了，復制給Frame Buffer，然后直接顯示在屏幕上，以此類推；
• 三重緩沖區的本質是在每次發出VSync信號后，多了一個Back Buffer(后緩沖區)來緩存幀數據；

iOS中卡頓的監測

• iOS手機默認的屏幕刷新率為60HZ，所以GPU的渲染幀率只要達到60FPS就不會產生卡頓，若低于60FPS，出現掉幀，給用戶的體驗就是有屏幕的卡頓；

卡頓監測的第一種方案：利用CADisplayLink計算GPU的幀率是否達到60FPS

• 原理：CADisplayLink是一個類似于NSTimer的定時器，但它比較特殊與GPU的繪制渲染機制有關，默認每秒執行60次回調方法，其必須加入RunLoop中才能正常運行(這里我們讓它加入主RunLoop)，我們可利用它來統計在1秒內執行 回調的次數 是否達到60次，來判定主線程是否卡頓，代碼實現如下：

#import "ViewController.h"

@interface ViewController ()

@property(nonatomic,strong)UILabel *FPSLabel;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    //主線程 注意有內存泄漏
    [[CADisplayLink displayLinkWithTarget:self selector:@selector(displayLinkAction:)] addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
    
    [self.view addSubview:self.FPSLabel];
}

- (void)displayLinkAction:(CADisplayLink *)link {
    //靜態變量記錄上次執行回調方法的時間戳
    static NSTimeInterval lastTime = 0;
    //靜態變量記錄回調方法執行的次數
    static NSInteger frameCount = 0;
    if (lastTime == 0) {
        lastTime = link.timestamp;
        return;
    }
    frameCount ++;
    //當CADisplayLink的時間間隔累積到1秒時 計算回調方法執行的次數
    //計算得到 每秒鐘 回調執行的次數 作為GPU的渲染幀率 看是否能達到60幀/s 由此可判定主線程是否卡頓；
    NSTimeInterval paseTime = link.timestamp - lastTime;
    if (paseTime >= 1) {
        NSInteger fps = frameCount / paseTime;
        lastTime = link.timestamp;
        frameCount = 0;
        NSLog(@"fps = %ld",fps);
        self.FPSLabel.text = [NSString stringWithFormat:@"%ldFPS",fps];
    }
}

- (UILabel *)FPSLabel{
    if (!_FPSLabel) {
        _FPSLabel = [[UILabel alloc]init];
        _FPSLabel.font = [UIFont systemFontOfSize:16];
        _FPSLabel.textColor = [UIColor whiteColor];
        _FPSLabel.backgroundColor = [UIColor grayColor];
        _FPSLabel.textAlignment = NSTextAlignmentCenter;
        _FPSLabel.frame = CGRectMake([UIScreen mainScreen].bounds.size.width - 100 - 30, [UIScreen mainScreen].bounds.size.height - 100, 100, 30);
    }
    return _FPSLabel;
}
@end

• 優缺點：可以實時監測GPU的渲染幀率，但是無法精確采集到卡頓時函數調用堆棧信息，給開發者定位問題，優化代碼帶來困難，可以在開發階段作為輔助手段使用；

卡頓監測的第二種方案：RunLoop監聽應用程序卡頓

• 在 iOS內存管理10 -- RunLoop運行循環 這篇文章中對RunLoop有著非常詳細的介紹，RunLoop的運行流程如下所示：
  
  Snip20211229_78.png
• 從圖中可以看出RunLoop在處理事件時主要集中在以下兩個階段：
  • 在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting之間；
  • 在kCFRunLoopAfterWaiting之后；
• 為了監聽應用程序是否存在卡頓，只要查看主線程RunLoop在處理事件時是否存在耗時即可，那么我們必須要知曉主RunLoop的運行狀態，邏輯步驟如下：
  • 第一步：通過創建RunLoop的觀察者即CFRunLoopObserverRef類型的實例對象，在觀察者的監聽回調中獲取主RunLoop的狀態；
  • 第二步：在每次獲取到RunLoop的狀態之后，(在主線程中)通過dispatch_semphore_t發送一個信號量(dispatch_semaphore_signal)，然后創建一個子線程，在子線程內部接收信號量(dispatch_semaphore_wait)，并設置一個延遲時間，若在設置的延遲時間之內，子線程沒有接收到信號量，則表明主線程可能正在執行耗時任務，可能引起應用的卡頓，主要是監聽RunLoop的kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting這兩個狀態；
• 主要代碼實現如下：

#import <Foundation/Foundation.h>
#define SHAREDMONITOR [LXDAppFluecyMonitor sharedMonitor]
/*!
 *  @brief  監聽UI線程卡頓
 */
@interface LXDAppFluecyMonitor : NSObject
+ (instancetype)sharedMonitor;
- (void)startMonitoring;
- (void)stopMonitoring;
@end

#import "LXDAppFluecyMonitor.h"

#define LXD_DEPRECATED_POLLUTE_MAIN_QUEUE

@interface LXDAppFluecyMonitor ()
@property (nonatomic, assign) int timeOut;
@property (nonatomic, assign) BOOL isMonitoring;
@property (nonatomic, assign) CFRunLoopObserverRef observer;
@property (nonatomic, assign) CFRunLoopActivity currentActivity;
@property (nonatomic, strong) dispatch_semaphore_t semphore;
@property (nonatomic, strong) dispatch_semaphore_t eventSemphore;
@end

#define LXD_SEMPHORE_SUCCESS 0
static NSTimeInterval lxd_restore_interval = 5;
static NSTimeInterval lxd_time_out_interval = 1;
static int64_t lxd_wait_interval = 200 * NSEC_PER_MSEC;

/*!
 *  @brief  監聽runloop狀態在after waiting和before sources之間
 */
static inline dispatch_queue_t lxd_fluecy_monitor_queue() {
    static dispatch_queue_t lxd_fluecy_monitor_queue;
    static dispatch_once_t once;
    dispatch_once(&once, ^{
        lxd_fluecy_monitor_queue = dispatch_queue_create("com.sindrilin.lxd_monitor_queue", NULL);
    });
    return lxd_fluecy_monitor_queue;
}

#define LOG_RUNLOOP_ACTIVITY 0
static void lxdRunLoopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void * info) {
    SHAREDMONITOR.currentActivity = activity;
    dispatch_semaphore_signal(SHAREDMONITOR.semphore);
#if LOG_RUNLOOP_ACTIVITY
    switch (activity) {
        case kCFRunLoopEntry:
            NSLog(@"runloop entry");
            break;
        case kCFRunLoopExit:
            NSLog(@"runloop exit");
            break;
        case kCFRunLoopAfterWaiting:
            NSLog(@"runloop after waiting");
            break;
        case kCFRunLoopBeforeTimers:
            NSLog(@"runloop before timers");
            break;
        case kCFRunLoopBeforeSources:
            NSLog(@"runloop before sources");
            break;
        case kCFRunLoopBeforeWaiting:
            NSLog(@"runloop before waiting");
            break;
        default:
            break;
    }
#endif
};

@implementation LXDAppFluecyMonitor

#pragma mark - Singleton override
+ (instancetype)sharedMonitor {
    static LXDAppFluecyMonitor * sharedMonitor;
    static dispatch_once_t once;
    dispatch_once(&once, ^{
        sharedMonitor = [[super allocWithZone: NSDefaultMallocZone()] init];
        [sharedMonitor commonInit];
    });
    return sharedMonitor;
}

+ (instancetype)allocWithZone: (struct _NSZone *)zone {
    return [self sharedMonitor];
}

- (void)dealloc {
    [self stopMonitoring];
}

- (void)commonInit {
    self.semphore = dispatch_semaphore_create(0);
}

#pragma mark - Public
- (void)startMonitoring {
    if (_isMonitoring) { return; }
    _isMonitoring = YES;
    CFRunLoopObserverContext context = {
        0,
        (__bridge void *)self,
        NULL,
        NULL
    };
    //創建監聽者
    _observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &lxdRunLoopObserverCallback, &context);
    //監聽主RunLoop
    CFRunLoopAddObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);
    
    //創建子線程
    dispatch_async(lxd_fluecy_monitor_queue(), ^{
        NSLog(@"%@",[NSThread currentThread]);
        while (SHAREDMONITOR.isMonitoring) {
            //成功為0,表示在指定時間內接收到主線程發出的信號
            //不成功非0，表示在指定時間內沒有接收到主線程發出的信號，主線程可能在執行耗時任務，有可能造成應用程序的卡頓
            long waitTime = dispatch_semaphore_wait(self.semphore, dispatch_time(DISPATCH_TIME_NOW, lxd_wait_interval));
            if (waitTime != LXD_SEMPHORE_SUCCESS) {
                if (!SHAREDMONITOR.observer) {
                    SHAREDMONITOR.timeOut = 0;
                    [SHAREDMONITOR stopMonitoring];
                    continue;
                }
                //kCFRunLoopBeforeSources 主RunLoop開始處理事件
                //kCFRunLoopAfterWaiting  主RunLoop結束休眠
                //狀態判斷 即在kCFRunLoopBeforeSources或kCFRunLoopAfterWaiting這兩個狀態區間內出現耗時
                if (SHAREDMONITOR.currentActivity == kCFRunLoopBeforeSources || SHAREDMONITOR.currentActivity == kCFRunLoopAfterWaiting) {
                    //出現5次耗時 則上傳主線程的函數調用棧
                    if (++SHAREDMONITOR.timeOut < 5) {
                        continue;
                    }
                    [LXDBacktraceLogger lxd_logMain];
                    [NSThread sleepForTimeInterval: lxd_restore_interval];
                }
            }
            SHAREDMONITOR.timeOut = 0;
        }
    });
}

- (void)stopMonitoring {
    if (!_isMonitoring) { return; }
    _isMonitoring = NO;
    
    CFRunLoopRemoveObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);
    CFRelease(_observer);
    _observer = nil;
}
@end

• 新建測試類代碼如下：

#import "ViewController.h"
#import "LXDAppFluecyMonitor.h"

@interface ViewController ()<UITableViewDelegate, UITableViewDataSource>

@property (weak, nonatomic) IBOutlet UITableView *tableView;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    [[LXDAppFluecyMonitor sharedMonitor] startMonitoring];
    [self.tableView registerClass: [UITableViewCell class] forCellReuseIdentifier: @"cell"];
}

- (void)viewDidAppear: (BOOL)animated {
    [super viewDidAppear: animated];
}

- (NSInteger)tableView: (UITableView *)tableView numberOfRowsInSection: (NSInteger)section {
    return 1000;
}

- (UITableViewCell *)tableView: (UITableView *)tableView cellForRowAtIndexPath: (NSIndexPath *)indexPath {
    UITableViewCell * cell = [tableView dequeueReusableCellWithIdentifier: @"cell"];
    cell.textLabel.text = [NSString stringWithFormat: @"%lu", indexPath.row];
    if (indexPath.row > 0 && indexPath.row % 30 == 0) {
       //等價于sleep(2)
        usleep(2 * 1000 * 1000);
    }
    return cell;
}

- (void)tableView: (UITableView *)tableView didSelectRowAtIndexPath: (NSIndexPath *)indexPath {
    usleep(2 * 1000 * 1000);
}
@end

• 在點擊cell與設置cell的代碼中添加了耗時操作usleep(2 * 1000 * 1000)，發現并不能監聽到卡頓；
• 于是繼續探索，借鑒了他人一種新的方案：創建一個子線程進行循環檢測，每次檢測時設置標記位為YES，然后派發任務到主線程中(切換到主線程)將標記位設置為NO，接著子線程沉睡超時闕值時長，判斷標志位是否成功設置成NO，如果沒有設置成功為NO，說明主線程發生了卡頓，無法處理派發任務，代碼實現如下：

dispatch_async(lxd_event_monitor_queue(), ^{
    NSLog(@"%@",[NSThread currentThread]);
    while (SHAREDMONITOR.isMonitoring) {
        //主線程的RunLoop 即將進入休眠
        if (SHAREDMONITOR.currentActivity == kCFRunLoopBeforeWaiting) {
            //默認超時
            __block BOOL timeOut = YES;
            NSLog(@"0");
            
            dispatch_async(dispatch_get_main_queue(), ^{
                //切換到主線程 執行任務
                //若主線程沒有出現卡頓 能正常執行任務 將timeOut設置為NO
                //若主線程出現卡頓 不能能正常執行任務
               timeOut = NO;
                //發送信號量 +1
               dispatch_semaphore_signal(SHAREDMONITOR.eventSemphore);
               NSLog(@"1");
            });
            
            NSLog(@"2");
            //當前子線程休眠1秒鐘
            [NSThread sleepForTimeInterval: lxd_time_out_interval];
            NSLog(@"3");
            //超時打印函數調用棧
            if (timeOut) {
               NSLog(@"4");
               [LXDBacktraceLogger lxd_logMain];
            }
            NSLog(@"5");
            //釋放信號量 -1 此時的信號量為-1<0 下面的邏輯不會執行 循環依然執行
            dispatch_wait(SHAREDMONITOR.eventSemphore, DISPATCH_TIME_FOREVER);
            NSLog(@"6");
        }
    }
});

• 再次測試，發現能監聽到點擊時的卡頓，且能監聽到滾動時的卡頓了，完整的代碼工程請參考LXDAppFluecyMonitor
• 卡頓時的函數調用堆棧如下所示：

image.png

卡頓監測的第三種方案：使用Instrument工具實時監測App

• 可利用Time Profiler，查看App的CPU的使用情況，定位方法耗時，具體操作步驟如下：
• 首先配置項目的Scheme，如下所示：

image.png

• 其次配置項目，如下所示：

image.png

• 做如上的配置主要是為了，在定位耗時方法時，能看到方法名，否則全是內存地址；
• 啟動Instrument，打開Time Profiler工具，操作如下：

image.png

image.png

image.png

卡頓的優化

• 從上文易知導致屏幕卡頓的根本原因在于CPU/GPU的負擔過重(資源消耗過大)，沒能在指定的時間內生成渲染數據，導致顯示器上仍然顯示的是上一幀的數據，即掉幀現象，所以卡頓的優化主要在于如何減輕CPU與GPU的資源消耗；

CPU的資源消耗與解決方案

• 對象的創建：對象的創建會分配內存、調整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對象代替重量的對象，可以對性能有所優化。比如 CALayer 比 UIView 要輕量許多，那么不需要響應觸摸事件的控件，用 CALayer 顯示會更加合適。如果對象不涉及 UI 操作，則盡量放到后臺線程去創建，但可惜的是包含有 CALayer 的控件，都只能在主線程創建和操作。通過 Storyboard 創建視圖對象時，其資源消耗會比直接通過代碼創建對象要大非常多，在性能敏感的界面里，Storyboard 并不是一個好的技術選擇，盡量推遲對象創建的時間，并把對象的創建分散到多個任務中去。盡管這實現起來比較麻煩，并且帶來的優勢并不多，但如果有能力做，還是要盡量嘗試一下。如果對象可以復用，并且復用的代價比釋放、創建新對象要小，那么這類對象應當盡量放到一個緩存池里復用；
• 對象的調整：對象的調整也經常是消耗 CPU 資源的地方。這里特別說一下 CALayer：CALayer 內部并沒有屬性，當調用屬性方法時，它內部是通過運行時 resolveInstanceMethod 為對象臨時添加一個方法，并把對應屬性值保存到內部的一個 Dictionary 里，同時還會通知 delegate、創建動畫等等，非常消耗資源。UIView 的關于顯示相關的屬性（比如 frame/bounds/transform）等實際上都是 CALayer 屬性映射來的，所以對 UIView 的這些屬性進行調整時，消耗的資源要遠大于一般的屬性。對此你在應用中，應該盡量減少不必要的屬性修改。當視圖層次調整時，UIView、CALayer 之間會出現很多方法調用與通知，所以在優化性能時，應該盡量避免調整視圖層次、添加和移除視圖；
• 對象的銷毀：對象的銷毀雖然消耗資源不多，但累積起來也是不容忽視的。通常當容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。同樣的，如果對象可以放到后臺線程去釋放，那就挪到后臺線程去。這里有個小 Tip：把對象捕獲到 block 中，然后扔到后臺隊列去隨便發送個消息以避免編譯器警告，就可以讓對象在后臺線程銷毀了；

NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
    [tmp class];
});

• 布局計算：視圖布局的計算是 App 中最為常見的消耗 CPU 資源的地方。如果能在后臺線程提前計算好視圖布局、并且對視圖布局進行緩存，那么這個地方基本就不會產生性能問題了。不論通過何種技術對視圖進行布局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調整上。上面也說過，對這些屬性的調整非常消耗資源，所以盡量提前計算好布局，在需要時一次性調整好對應屬性，而不要多次、頻繁的計算和調整這些屬性；
• Autolayout：Autolayout 是蘋果本身提倡的技術，在大部分情況下也能很好的提升開發效率，但是 Autolayout 對于復雜視圖來說常常會產生嚴重的性能問題。隨著視圖數量的增長，Autolayout 帶來的 CPU 消耗會呈指數級上升。如果你不想手動調整 frame 等屬性，你可以用一些工具方法替代（比如常見的 left/right/top/bottom/width/height 快捷屬性），或者使用 ComponentKit、AsyncDisplayKit 等框架；
• 文本計算：如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源，并且不可避免。如果你對文本顯示沒有特殊要求，可以參考下 UILabel 內部的實現方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到后臺線程進行以避免阻塞主線程，如果你用 CoreText 繪制文本，那就可以先生成 CoreText 排版對象，然后自己計算了，并且 CoreText 對象還能保留以供稍后繪制使用；
• 文本渲染：屏幕上能看到的所有文本內容控件，包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的。常見的文本控件 （UILabel、UITextView 等），其排版和繪制都是在主線程進行的，當顯示大量文本時，CPU 的壓力會非常大。對此解決方案只有一個，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對文本異步繪制。盡管這實現起來非常麻煩，但其帶來的優勢也非常大，CoreText 對象創建好后，能直接獲取文本的寬高等信息，避免了多次計算（調整 UILabel 大小時算一遍、UILabel 繪制時內部再算一遍）；CoreText 對象占用內存較少，可以緩存下來以備稍后多次渲染；
• 圖片的解碼：當你用 UIImage 或 CGImageSource 的那幾個方法創建圖片時，圖片數據并不會立刻解碼。圖片設置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數據才會得到解碼。這一步是發生在主線程的，并且不可避免。如果想要繞開這個機制，常見的做法是在后臺線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創建圖片。目前常見的網絡圖片庫都自帶這個功能；
• 圖像的繪制：圖像的繪制通常是指用那些以 CG 開頭的方法把圖像繪制到畫布中，然后從畫布創建圖片并顯示這樣一個過程。這個最常見的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺線程進行。一個簡單異步繪制的過程大致如下（實際情況會比這個復雜得多，但原理基本一致）：

- (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主要負責將數據轉成位圖，完成圖形的渲染，最后提交到幀緩沖區，其詳細步驟有：頂點數據存儲->頂點著色器處理(將頂點轉成圖元)->圖元裝配->光柵化(圖元轉換為像素)->處理像素，得到位圖->片段著色器(給每一個像素 Pixel 賦予正確的顏色) -> 測試與混合(處理片段的前后位置以及透明度)->圖像幀；
• 紋理的渲染：若設置了CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發離屏渲染（offscreen rendering），而離屏渲染通常發生在 GPU 中，當一個列表視圖中出現大量圓角的 CALayer，并且快速滑動時，可以觀察到 GPU 資源已經占滿，而 CPU 資源消耗很少。這時界面仍然能正常滑動，但平均幀數會降到很低。為了避免這種情況，可以嘗試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉嫁到 CPU 上去。對于只需要圓角的某些場合，也可以用一張已經繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。
• 視圖的混合：當多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結構過于復雜，混合的過程也會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應用應當盡量減少視圖數量和層次，并在不透明的視圖里標明 opaque 屬性以避免無用的 Alpha 通道合成。當然，這也可以用上面的方法，把多個視圖預先渲染為一張圖片來顯示；

離屏渲染

• 在默認的幀緩沖區中渲染對象，這叫做當前屏幕渲染(On-screen Rendering)；
• 將渲染計算結果放在非默認幀緩沖區中，這叫做離屏渲染(Off-screen Rendering)；
• 也就是說在進行當前屏幕渲染的時候，若觸發了離屏渲染，會額外的開辟一個離屏緩沖區，與當前的雙幀緩沖區沒有關系，互不影響；
• 離屏渲染是比較消耗GPU性能的，具體表現在以下兩個方面：
  • 離屏渲染會開辟一個單獨的離屏緩沖區，其擁有自己的一套渲染通道(渲染管線--渲染流水線)；
  • 當前幀緩沖區與離屏緩沖區的渲染通道之間的環境切換，是比較耗時的；
• 在iOS中，模擬器提供了一個檢測頁面是否產生離屏渲染的工具，開啟如下：選中模擬器->Debug->Color Off-screen Rendered，若頁面出現黃色區域，說明有離屏渲染，下面來探索哪些情況下有可能導致離屏渲染；

圓角圖片引發離屏渲染的探索

• 使用Xcode12.4，iOS14.4模擬器，研究結果如下：

image.png

• 當設置圖片的圓角+裁剪時，不會觸發離屏渲染；
• 當設置圖片的圓角+邊框+裁剪時，會觸發離屏渲染；
• 當設置圖片的圓角+背景顏色+裁剪時，會觸發離屏渲染；
• 當設置無圖片內容+背景+邊框+裁剪時，不會觸發離屏渲染；
• 上述情況，觸發離屏渲染的真正原因究竟是什么？？？
• 首先我們來介紹一下油畫算法：繪制多個圖層時，會先繪制場景中的離觀察者較遠的物體，再繪制較近的物體，也就是按照由遠及近的順序進行繪制，如下所示：

image.png

• 圓角圖片中的子圖層有背景圖層，圖片內容圖層以及邊框，如下所示：

image.png

• 按照正常的繪制流程，依次繪制背景圖層，圖片內容，邊框，每繪制完一個子圖層，就會將其丟棄銷毀，為的是節約內存，但是現在要對所有子圖層就行圓角的裁剪處理，那么子圖層不能直接丟棄，所以就觸發了離屏渲染，新開辟了一個離屏緩沖區，用來保存所有繪制的子圖層，進行所有子圖層的圓角裁剪，最后進行合并，生成最終的圖層；

• iOS官方針對UIImageView關于離屏有如下優化：

  • 在iOS9之前，UIImageView和UIButton通過cornerRadius+masksToBounds設置圓角都會觸發離屏渲染；
  • 在UIImageView在iOS9以后，針對UIImageView中的image設置圓角并不會觸發離屏渲染，如果加上了背景色或者陰影等其他效果還是會觸發離屏渲染的；

毛玻璃效果會引發離屏渲染

image.png

陰影效果會引發離屏渲染

image.png

遮罩效果會引發離屏渲染

image.png

參考文章如下：
iOS開發優化篇之卡頓檢測
iOS卡頓監測方案總結
iOS 保持界面流暢的技巧
iOS應用千萬級架構：性能優化與卡頓監控
iOS 性能優化總結
IOS面試考察(九)：性能優化相關問題
iOS圓角的離屏渲染，你真的弄明白了嗎
iOS 渲染原理解析
iOS-底層原理39-離屏渲染
深入剖析【離屏渲染】原理