本文主要介紹界面卡頓的原理以及優(yōu)化

界面卡頓

通常來說，計(jì)算機(jī)中的顯示過程是下面這樣的，通過CPU、GPU、顯示器協(xié)同工作來將圖片顯示到屏幕上

• 1、CPU計(jì)算好顯示內(nèi)容，提交至GPU

• 2、GPU經(jīng)過渲染完成后將渲染的結(jié)果放入FrameBuffer（幀緩存區(qū)）

• 3、隨后視頻控制器會(huì)按照VSync信號(hào)逐行讀取FrameBuffer的數(shù)據(jù)

• 4、經(jīng)過可能的數(shù)模轉(zhuǎn)換傳遞給顯示器進(jìn)行顯示

最開始時(shí)，F(xiàn)rameBuffer只有一個(gè)，這種情況下FrameBuffer的讀取和刷新有很大的效率問題，為了解決這個(gè)問題，引入了雙緩存區(qū)。即雙緩沖機(jī)制。在這種情況下，GPU會(huì)預(yù)先渲染好一幀放入FrameBuffer，讓視頻控制器讀取，當(dāng)下一幀渲染好后，GPU會(huì)直接將視頻控制器的指針指向第二個(gè)FrameBuffer。

雙緩存機(jī)制雖然解決了效率問題，但是隨之而言的是新的問題，當(dāng)視頻控制器還未讀取完成時(shí)，例如屏幕內(nèi)容剛顯示一半，GPU將新的一幀內(nèi)容提交到FrameBuffer，并將兩個(gè)FrameBuffer而進(jìn)行交換后，視頻控制器就會(huì)將新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成屏幕撕裂現(xiàn)象

為了解決這個(gè)問題，采用了垂直同步信號(hào)機(jī)制。當(dāng)開啟垂直同步后，GPU會(huì)等待顯示器的VSync信號(hào)發(fā)出后，才進(jìn)行新的一幀渲染和FrameBuffer更新。而目前iOS設(shè)備中采用的正是雙緩存區(qū)+VSync

更多的關(guān)于屏幕卡頓渲染流程，請(qǐng)查看屏幕卡頓 及 iOS中OpenGL渲染架構(gòu)分析文章

屏幕卡頓原因

下面我們來說說，屏幕卡頓的原因

在 VSync信號(hào)到來后，系統(tǒng)圖形服務(wù)會(huì)通過 CADisplayLink 等機(jī)制通知 App，App 主線程開始在CPU中計(jì)算顯示內(nèi)容。隨后 CPU 會(huì)將計(jì)算好的內(nèi)容提交到 GPU 去，由GPU進(jìn)行變換、合成、渲染。隨后 GPU 會(huì)把渲染結(jié)果提交到幀緩沖區(qū)去，等待下一次 VSync 信號(hào)到來時(shí)顯示到屏幕上。由于垂直同步的機(jī)制，如果在一個(gè) VSync 時(shí)間內(nèi)，CPU 或者 GPU 沒有完成內(nèi)容提交，則那一幀就會(huì)被丟棄，等待下一次機(jī)會(huì)再顯示，而這時(shí)顯示屏?xí)Ａ糁暗膬?nèi)容不變。所以可以簡單理解掉幀為過時(shí)不候

如下圖所示，是一個(gè)顯示過程，第1幀在VSync到來前，處理完成，正常顯示，第2幀在VSync到來后，因?yàn)镃PU耗時(shí)較多，來不及顯示，此時(shí)屏幕不刷新，依舊顯示第1幀，此時(shí)就出現(xiàn)了掉幀情況，渲染時(shí)就會(huì)出現(xiàn)明顯的卡頓現(xiàn)象

從圖中可以看出，CPU和GPU不論是哪個(gè)阻礙了顯示流程，都會(huì)造成掉幀現(xiàn)象，所以為了給用戶提供更好的體驗(yàn)，在開發(fā)中，我們需要進(jìn)行卡頓檢測以及相應(yīng)的優(yōu)化

卡頓監(jiān)控

卡頓監(jiān)控的方案一般有兩種：

• FPS監(jiān)控：為了保持流程的UI交互，App的刷新拼搏應(yīng)該保持在60fps左右，其原因是因?yàn)?code>iOS設(shè)備默認(rèn)的刷新頻率是60次/秒，而1次刷新（即VSync信號(hào)發(fā)出）的間隔是 1000ms/60 = 16.67ms，所以如果在16.67ms內(nèi)沒有準(zhǔn)備好下一幀數(shù)據(jù)，就會(huì)產(chǎn)生卡頓

• 主線程卡頓監(jiān)控：通過子線程監(jiān)測主線程的RunLoop，判斷兩個(gè)狀態(tài)（kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting）之間的耗時(shí)是否達(dá)到一定閾值

FPS監(jiān)控

FPS的監(jiān)控，參照YYKit中的YYFPSLabel，主要是通過CADisplayLink實(shí)現(xiàn)。借助link的時(shí)間差，來計(jì)算一次刷新刷新所需的時(shí)間，然后通過 刷新次數(shù) / 時(shí)間差 得到刷新頻次，并判斷是否其范圍，通過顯示不同的文字顏色來表示卡頓嚴(yán)重程度。代碼實(shí)現(xiàn)如下：

class CJLFPSLabel: UILabel {

    fileprivate var link: CADisplayLink = {
        let link = CADisplayLink.init()
        return link
    }()

    fileprivate var count: Int = 0
    fileprivate var lastTime: TimeInterval = 0.0
    fileprivate var fpsColor: UIColor = {
        return UIColor.green
    }()
    fileprivate var fps: Double = 0.0

    override init(frame: CGRect) {
        var f = frame
        if f.size == CGSize.zero {
            f.size = CGSize(width: 80.0, height: 22.0)
        }

        super.init(frame: f)

        self.textColor = UIColor.white
        self.textAlignment = .center
        self.font = UIFont.init(name: "Menlo", size: 12)
        self.backgroundColor = UIColor.lightGray
        //通過虛擬類
        link = CADisplayLink.init(target: CJLWeakProxy(target:self), selector: #selector(tick(_:)))
        link.add(to: RunLoop.current, forMode: RunLoop.Mode.common)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    deinit {
        link.invalidate()
    }

    @objc func tick(_ link: CADisplayLink){
        guard lastTime != 0 else {
            lastTime = link.timestamp
            return
        }

        count += 1
        //時(shí)間差
        let detla = link.timestamp - lastTime
        guard detla >= 1.0 else {
            return
        }

        lastTime = link.timestamp
        //刷新次數(shù) / 時(shí)間差 = 刷新頻次
        fps = Double(count) / detla
        let fpsText = "\(String.init(format: "%.2f", fps)) FPS"
        count = 0

        let attrMStr = NSMutableAttributedString(attributedString: NSAttributedString(string: fpsText))
        if fps > 55.0 {
            //流暢
            fpsColor = UIColor.green
        }else if (fps >= 50.0 && fps <= 55.0){
            //一般
            fpsColor = UIColor.yellow
        }else{
            //卡頓
            fpsColor = UIColor.red
        }

        attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: fpsColor], range: NSMakeRange(0, attrMStr.length - 3))
        attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: UIColor.white], range: NSMakeRange(attrMStr.length - 3, 3))

        DispatchQueue.main.async {
            self.attributedText = attrMStr
        }
    }

}

如果只是簡單的監(jiān)測，使用FPS足夠了。

主線程卡頓監(jiān)控

除了FPS，還可以通過RunLoop來監(jiān)控，因?yàn)榭D的是事務(wù)，而事務(wù)是交由主線程的RunLoop處理的。

我們知道iOS App基于RunLoop運(yùn)行，我們先來看看RunLoop簡化后的代碼。

// 1.進(jìn)入loop
__CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled)

// 2.RunLoop 即將觸發(fā) Timer 回調(diào)。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
// 3.RunLoop 即將觸發(fā) Source0 (非port) 回調(diào)。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
// 4.RunLoop 觸發(fā) Source0 (非port) 回調(diào)。
sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle)
// 5.執(zhí)行被加入的block
__CFRunLoopDoBlocks(runloop, currentMode);

// 6.RunLoop 的線程即將進(jìn)入休眠(sleep)。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);

// 7.調(diào)用 mach_msg 等待接受 mach_port 的消息。線程將進(jìn)入休眠, 直到被下面某一個(gè)事件喚醒。
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort)

// 進(jìn)入休眠

// 8.RunLoop 的線程剛剛被喚醒了。
__CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting

// 9.如果一個(gè) Timer 到時(shí)間了，觸發(fā)這個(gè)Timer的回調(diào)
__CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())

// 10.如果有dispatch到main_queue的block，執(zhí)行bloc
 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);

 // 11.如果一個(gè) Source1 (基于port) 發(fā)出事件了，處理這個(gè)事件
__CFRunLoopDoSource1(runloop, currentMode, source1, msg);

// 12.RunLoop 即將退出
__CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);

實(shí)現(xiàn)思路：理清楚Runloop的運(yùn)行機(jī)制，就很容易明白處理事件主要有兩個(gè)時(shí)間段 kCFRunLoopBeforeSources 發(fā)送之后和 kCFRunLoopAfterWaiting 發(fā)送之后。

dispatch_semaphore_t 是一個(gè)信號(hào)量機(jī)制，信號(hào)量到達(dá)會(huì)繼續(xù)向下進(jìn)行，否則等待，利用這個(gè)特性我們判斷卡頓出現(xiàn)的條件為 在信號(hào)量發(fā)送 kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting后進(jìn)行了大量的操作，在一段時(shí)間內(nèi)沒有再發(fā)送信號(hào)量，導(dǎo)致超時(shí)。也就是說主線程通知狀態(tài)長時(shí)間的停留在這兩個(gè)狀態(tài)上了。轉(zhuǎn)換為代碼就是判斷有沒有超時(shí)，超時(shí)了，判斷當(dāng)前停留的狀態(tài)是不是這兩個(gè)狀態(tài)，如果是，就判定為卡頓。

這樣就能解釋通為什么要用這兩個(gè)信號(hào)量判斷卡頓。這個(gè)也是微信卡頓三方matrix的原理

以下是一個(gè)簡易版RunLoop監(jiān)控的實(shí)現(xiàn)

@interface AKStuckMonitor ()
{
    int timeoutCount;
    CFRunLoopObserverRef observer;

@public
    dispatch_semaphore_t semaphore;
    CFRunLoopActivity activity;
}

@end

@implementation FQLAPMStuckMonitor

+ (instancetype)sharedInstance{

    static id instance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc] init];
    });
    return instance;
}

static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){

    AKStuckMonitor *moniotr = (__bridge AKStuckMonitor*)info;

    moniotr->activity = activity;

    dispatch_semaphore_t semaphore = moniotr->semaphore;
    dispatch_semaphore_signal(semaphore);
}

- (void)stop{

    if (!observer)
        return;

    CFRunLoopRemoveObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
    CFRelease(observer);
    observer = NULL;
}

- (void)start{

    if (observer)
        return;

    // 信號(hào)
    semaphore = dispatch_semaphore_create(0);

    // 注冊RunLoop狀態(tài)觀察
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                       kCFRunLoopAllActivities,
                                       YES,
                                       0,
                                       &runLoopObserverCallBack,
                                       &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

    // 在子線程監(jiān)控時(shí)長
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        float time = 50;
        while (YES)
        {
            long st = dispatch_semaphore_wait(self->semaphore, dispatch_time(DISPATCH_TIME_NOW, time * NSEC_PER_MSEC));
            if (st != 0)
            {
                if (!self->observer)
                {
                    self->timeoutCount = 0;
                    self->semaphore = 0;
                    self->activity = 0;
                    return;
                }

                if (self->activity==kCFRunLoopBeforeSources || self->activity==kCFRunLoopAfterWaiting)
                {
                    if (++self->timeoutCount < 5)
                        continue;
                    NSlog(@"檢測到卡頓");

                }
            }
            self->timeoutCount = 0;
        }
    });
}

@end

也可以直接使用三方庫

• Swift的卡頓檢測第三方ANREye，其主要思路是：創(chuàng)建子線程進(jìn)行循環(huán)監(jiān)測，每次檢測時(shí)設(shè)置標(biāo)記置為true，然后派發(fā)任務(wù)到主線程，標(biāo)記置為false，接著子線程睡眠超過閾值時(shí)，判斷標(biāo)記是否為false，如果沒有，說明主線程發(fā)生了卡頓

• OC可以使用 微信matrix、滴滴DoraemonKit

界面優(yōu)化

CPU層面的優(yōu)化

• 1、盡量提前計(jì)算視圖布局，即預(yù)排版，例如cell的行高,提前計(jì)算保存視圖的Rect

• 2、盡量用輕量級(jí)的對(duì)象代替重量級(jí)的對(duì)象，可以對(duì)性能有所優(yōu)化，例如 不需要相應(yīng)觸摸事件的控件，用CALayer代替UIView

• 3、盡量減少對(duì)UIView和CALayer的屬性修改

  • CALayer內(nèi)部并沒有屬性，當(dāng)調(diào)用屬性方法時(shí)，其內(nèi)部是通過運(yùn)行時(shí)resolveInstanceMethod為對(duì)象臨時(shí)添加一個(gè)方法，并將對(duì)應(yīng)屬性值保存在內(nèi)部的一個(gè)Dictionary中，同時(shí)還會(huì)通知delegate、創(chuàng)建動(dòng)畫等，非常耗時(shí)

  • UIView相關(guān)的顯示屬性，例如frame、bounds、transform等，實(shí)際上都是從CALayer映射來的，對(duì)其進(jìn)行調(diào)整時(shí)，消耗的資源比一般屬性要大

• 4、當(dāng)有大量對(duì)象釋放時(shí)，也是非常耗時(shí)的，盡量挪到后臺(tái)線程去釋放

• 5、Autolayout在簡單頁面情況下們可以很好的提升開發(fā)效率，但是對(duì)于復(fù)雜視圖而言，會(huì)產(chǎn)生嚴(yán)重的性能問題，隨著視圖數(shù)量的增長，Autolayout帶來的CPU消耗是呈指數(shù)上升的。所以盡量使用代碼布局。如果不想手動(dòng)調(diào)整frame等，也可以借助三方庫，例如Masonry（OC）、SnapKit（Swift）、ComponentKit、AsyncDisplayKit等

• 6、文本處理的優(yōu)化：當(dāng)一個(gè)界面有大量文本時(shí)，其行高的計(jì)算、繪制也是非常耗時(shí)的

  • 1）如果對(duì)文本沒有特殊要求，可以使用UILabel內(nèi)部的實(shí)現(xiàn)方式，且需要放到子線程中進(jìn)行，避免阻塞主線程

    • 計(jì)算文本寬高：[NSAttributedString boundingRectWithSize:options:context:]

    • 文本繪制：[NSAttributedString drawWithRect:options:context:]

  • 2）自定義文本控件，利用TextKit 或最底層的 CoreText 對(duì)文本異步繪制。并且CoreText 對(duì)象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計(jì)算（調(diào)整和繪制都需要計(jì)算一次）。CoreText直接使用了CoreGraphics占用內(nèi)存小，效率高

• 7、圖片處理（解碼 + 繪制）

  • 1）當(dāng)使用UIImage 或 CGImageSource 的方法創(chuàng)建圖片時(shí)，圖片的數(shù)據(jù)不會(huì)立即解碼，而是在設(shè)置時(shí)解碼（即圖片設(shè)置到UIImageView/CALayer.contents中，然后在CALayer提交至GPU渲染前，CGImage中的數(shù)據(jù)才進(jìn)行解碼）。這一步是無可避免的，且是發(fā)生在主線程中的。想要繞開這個(gè)機(jī)制，常見的做法是在子線程中先將圖片繪制到CGBitmapContext，然后從Bitmap 直接創(chuàng)建圖片，例如SDWebImage三方框架中對(duì)圖片編解碼的處理。這就是Image的預(yù)解碼

  • 當(dāng)使用CG開頭的方法繪制圖像到畫布中，然后從畫布中創(chuàng)建圖片時(shí)，可以將圖像的繪制在子線程中進(jìn)行

• 8、圖片優(yōu)化

  • 1）盡量使用PNG圖片，不使用JPGE圖片

  • 2）通過子線程預(yù)解碼，主線程渲染，即通過Bitmap創(chuàng)建圖片，在子線程賦值image

  • 3）優(yōu)化圖片大小，盡量避免動(dòng)態(tài)縮放

• 9、盡量避免使用透明view，因?yàn)槭褂猛该鱲iew，會(huì)導(dǎo)致在GPU中計(jì)算像素時(shí)，會(huì)將透明view下層圖層的像素也計(jì)算進(jìn)來，即顏色混合處理，可以參考六、OpenGL 渲染技巧：深度測試、多邊形偏移、 混合這篇文章中提及的混合

• 10、按需加載，例如在TableView中滑動(dòng)時(shí)不加載圖片，使用默認(rèn)占位圖，而是在滑動(dòng)停止時(shí)加載

• 11、少使用addView 給cell動(dòng)態(tài)添加view

GPU層面優(yōu)化

相對(duì)于CPU而言，GPU主要是接收CPU提交的紋理+頂點(diǎn)，經(jīng)過一系列transform，最終混合并渲染，輸出到屏幕上。

• 1、盡量減少在短時(shí)間內(nèi)大量圖片的顯示，主要是因?yàn)楫?dāng)有大量圖片進(jìn)行顯示時(shí)，無論是CPU的計(jì)算還是GPU的渲染，都是非常耗時(shí)的，很可能出現(xiàn)掉幀的情況

• 2、盡量避免圖片的尺寸超過4096×4096，因?yàn)楫?dāng)圖片超過這個(gè)尺寸時(shí)，會(huì)先由CPU進(jìn)行預(yù)處理，然后再提交給GPU處理，導(dǎo)致額外CPU資源消耗

• 3、盡量減少視圖數(shù)量和層次，主要是因?yàn)橐晥D過多且重疊時(shí)，GPU會(huì)將其混合，混合的過程也是非常耗時(shí)的

• 4、盡量避免離屏渲染，可以查看這篇文章四、深入剖析【離屏渲染】原理

• 5、異步渲染，例如可以將cell中的所有控件、視圖合成一張圖片進(jìn)行顯示。可以參考Graver三方框架

注：上述這些優(yōu)化方式的落地實(shí)現(xiàn)，需要根據(jù)自身項(xiàng)目進(jìn)行評(píng)估，合理的使用進(jìn)行優(yōu)化