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

CPU與GPU

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

屏幕成像

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

image.png

圖像的相關(guān)概念

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

畫面撕裂

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

image.png

畫面跳幀

• 若CPU與顯卡硬件性能極其強(qiáng)大，幀率 遠(yuǎn)遠(yuǎn)大于 屏幕的刷新率，會導(dǎo)致當(dāng)前幀數(shù)據(jù)才開始繪制，下一幀的數(shù)據(jù)就已經(jīng)生成放進(jìn)了緩沖區(qū)，在屏幕上當(dāng)前幀的數(shù)據(jù)就被下一幀數(shù)據(jù)覆蓋了，也就說當(dāng)前幀被跳過了，這種現(xiàn)象稱之為畫面跳幀；

畫面閃爍

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

解決方案

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

畫面(屏幕)卡頓

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

image.png

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

image.png

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

iOS中卡頓的監(jiān)測

• iOS手機(jī)默認(rèn)的屏幕刷新率為60HZ，所以GPU的渲染幀率只要達(dá)到60FPS就不會產(chǎn)生卡頓，若低于60FPS，出現(xiàn)掉幀，給用戶的體驗就是有屏幕的卡頓；

卡頓監(jiān)測的第一種方案：利用CADisplayLink計算GPU的幀率是否達(dá)到60FPS

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

#import "ViewController.h"

@interface ViewController ()

@property(nonatomic,strong)UILabel *FPSLabel;

@end

@implementation ViewController

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

- (void)displayLinkAction:(CADisplayLink *)link {
    //靜態(tài)變量記錄上次執(zhí)行回調(diào)方法的時間戳
    static NSTimeInterval lastTime = 0;
    //靜態(tài)變量記錄回調(diào)方法執(zhí)行的次數(shù)
    static NSInteger frameCount = 0;
    if (lastTime == 0) {
        lastTime = link.timestamp;
        return;
    }
    frameCount ++;
    //當(dāng)CADisplayLink的時間間隔累積到1秒時 計算回調(diào)方法執(zhí)行的次數(shù)
    //計算得到 每秒鐘 回調(diào)執(zhí)行的次數(shù) 作為GPU的渲染幀率 看是否能達(dá)到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

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

卡頓監(jiān)測的第二種方案：RunLoop監(jiān)聽?wèi)?yīng)用程序卡頓

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

#import <Foundation/Foundation.h>
#define SHAREDMONITOR [LXDAppFluecyMonitor sharedMonitor]
/*!
 *  @brief  監(jiān)聽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  監(jiān)聽runloop狀態(tài)在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
    };
    //創(chuàng)建監(jiān)聽者
    _observer = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &lxdRunLoopObserverCallback, &context);
    //監(jiān)聽主RunLoop
    CFRunLoopAddObserver(CFRunLoopGetMain(), _observer, kCFRunLoopCommonModes);
    
    //創(chuàng)建子線程
    dispatch_async(lxd_fluecy_monitor_queue(), ^{
        NSLog(@"%@",[NSThread currentThread]);
        while (SHAREDMONITOR.isMonitoring) {
            //成功為0,表示在指定時間內(nèi)接收到主線程發(fā)出的信號
            //不成功非0，表示在指定時間內(nèi)沒有接收到主線程發(fā)出的信號，主線程可能在執(zhí)行耗時任務(wù)，有可能造成應(yīng)用程序的卡頓
            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結(jié)束休眠
                //狀態(tài)判斷 即在kCFRunLoopBeforeSources或kCFRunLoopAfterWaiting這兩個狀態(tài)區(qū)間內(nèi)出現(xiàn)耗時
                if (SHAREDMONITOR.currentActivity == kCFRunLoopBeforeSources || SHAREDMONITOR.currentActivity == kCFRunLoopAfterWaiting) {
                    //出現(xiàn)5次耗時 則上傳主線程的函數(shù)調(diào)用棧
                    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與設(shè)置cell的代碼中添加了耗時操作usleep(2 * 1000 * 1000)，發(fā)現(xiàn)并不能監(jiān)聽到卡頓；
• 于是繼續(xù)探索，借鑒了他人一種新的方案：創(chuàng)建一個子線程進(jìn)行循環(huán)檢測，每次檢測時設(shè)置標(biāo)記位為YES，然后派發(fā)任務(wù)到主線程中(切換到主線程)將標(biāo)記位設(shè)置為NO，接著子線程沉睡超時闕值時長，判斷標(biāo)志位是否成功設(shè)置成NO，如果沒有設(shè)置成功為NO，說明主線程發(fā)生了卡頓，無法處理派發(fā)任務(wù)，代碼實現(xiàn)如下：

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

• 再次測試，發(fā)現(xiàn)能監(jiān)聽到點擊時的卡頓，且能監(jiān)聽到滾動時的卡頓了，完整的代碼工程請參考LXDAppFluecyMonitor
• 卡頓時的函數(shù)調(diào)用堆棧如下所示：

image.png

卡頓監(jiān)測的第三種方案：使用Instrument工具實時監(jiān)測App

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

image.png

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

image.png

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

image.png

image.png

image.png

卡頓的優(yōu)化

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

CPU的資源消耗與解決方案

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

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

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

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

離屏渲染

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

圓角圖片引發(fā)離屏渲染的探索

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

image.png

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

image.png

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

image.png

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

• iOS官方針對UIImageView關(guān)于離屏有如下優(yōu)化：

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

毛玻璃效果會引發(fā)離屏渲染

image.png

陰影效果會引發(fā)離屏渲染

image.png

遮罩效果會引發(fā)離屏渲染

image.png

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