iOS開發(fā)--APP性能檢測方案匯總(一)

APP的性能監(jiān)控包括： CPU 占用率杰赛、 內(nèi)存使用情況、網(wǎng)絡(luò)狀況監(jiān)控矮台、啟動時閃退乏屯、卡頓、FPS瘦赫、使用時崩潰辰晕、耗電量監(jiān)控、流量監(jiān)控等等确虱。

文中所有代碼都已同步到github中含友，有興趣的可以clone下來一起探討下。

1 . CPU 占用率

CPU作為手機(jī)的中央處理器校辩，可以說是手機(jī)最關(guān)鍵的組成部分窘问，所有應(yīng)用程序都需要它來調(diào)度運行，資源有限宜咒。所以當(dāng)我們的APP因設(shè)計不當(dāng)惠赫，使 CPU 持續(xù)以高負(fù)載運行，將會出現(xiàn)APP卡頓故黑、手機(jī)發(fā)熱發(fā)燙汉形、電量消耗過快等等嚴(yán)重影響用戶體驗的現(xiàn)象。

因此我們對應(yīng)用在CPU中占用率的監(jiān)控倍阐，將變得尤為重要。那么我們應(yīng)該如何來獲取CPU的占有率呢逗威？峰搪！

我們都知道，我們的APP在運行的時候凯旭，會對應(yīng)一個Mach Task概耻，而Task下可能有多條線程同時執(zhí)行任務(wù)，每個線程都是作為利用CPU的基本單位罐呼。所以我們可以通過獲取當(dāng)前Mach Task下鞠柄，所有線程占用 CPU 的情況，來計算APP的 CPU 占用率嫉柴。

在《OS X and iOS Kernel Programming》是這樣描述 Mach task 的：

任務(wù)（task）是一種容器（container）對象厌杜，虛擬內(nèi)存空間和其他資源都是通過這個容器對象管理的，這些資源包括設(shè)備和其他句柄。嚴(yán)格地說夯尽，Mach 的任務(wù)并不是其他操作系統(tǒng)中所謂的進(jìn)程瞧壮，因為 Mach 作為一個微內(nèi)核的操作系統(tǒng)，并沒有提供“進(jìn)程”的邏輯匙握，而只是提供了最基本的實現(xiàn)咆槽。不過在 BSD 的模型中，這兩個概念有1：1的簡單映射圈纺，每一個 BSD 進(jìn)程（也就是 OS X 進(jìn)程）都在底層關(guān)聯(lián)了一個 Mach 任務(wù)對象秦忿。

Mac OS X 中進(jìn)程子系統(tǒng)組成的概念圖

iOS 是基于 Apple Darwin 內(nèi)核，由kernel蛾娶、XNU和Runtime 組成灯谣，而XNU 是Darwin 的內(nèi)核，它是“X is not UNIX”的縮寫茫叭，是一個混合內(nèi)核酬屉，由 Mach 微內(nèi)核和 BSD 組成。Mach 內(nèi)核是輕量級的平臺揍愁，只能完成操作系統(tǒng)最基本的職責(zé)呐萨，比如：進(jìn)程和線程、虛擬內(nèi)存管理莽囤、任務(wù)調(diào)度谬擦、進(jìn)程通信和消息傳遞機(jī)制等。其他的工作朽缎，例如文件操作和設(shè)備訪問惨远，都由 BSD 層實現(xiàn)。

iOS 的線程技術(shù)與Mac OS X類似话肖，也是基于 Mach 線程技術(shù)實現(xiàn)的北秽，在 Mach 層中thread_basic_info 結(jié)構(gòu)體封裝了單個線程的基本信息：

struct thread_basic_info {
    time_value_t  user_time;      /* user run time */
    time_value_t  system_time;    /* system run time */
    integer_t    cpu_usage;       /* scaled cpu usage percentage */
    policy_t     policy;          /* scheduling policy in effect */
    integer_t    run_state;       /* run state (see below) */
    integer_t    flags;           /* various flags (see below) */
    integer_t    suspend_count;   /* suspend count for thread */
    integer_t    sleep_time;      /* number of seconds that thread  has been sleeping */
}

一個Mach Task包含它的線程列表。內(nèi)核提供了task_threads API 調(diào)用獲取指定 task 的線程列表最筒，然后可以通過thread_info API調(diào)用來查詢指定線程的信息贺氓，在 thread_act.h 中有相關(guān)定義。

task_threads 將target_task 任務(wù)中的所有線程保存在act_list數(shù)組中床蜘，act_listCnt表示線程個數(shù)：

kern_return_t task_threads
(
    task_t target_task,
    thread_act_array_t *act_list,
    mach_msg_type_number_t *act_listCnt
);

thread_info結(jié)構(gòu)如下：

kern_return_t thread_info
(
    thread_act_t target_act,
    thread_flavor_t flavor,  // 傳入不同的宏定義獲取不同的線程信息
    thread_info_t thread_info_out,  // 查詢到的線程信息
    mach_msg_type_number_t *thread_info_outCnt  // 信息的大小
);

所以我們?nèi)缦聛慝@取CPU的占有率：

#import "LSLCpuUsage.h"
#import <mach/task.h>
#import <mach/vm_map.h>
#import <mach/mach_init.h>
#import <mach/thread_act.h>
#import <mach/thread_info.h>

@implementation LSLCpuUsage

+ (double)getCpuUsage {
    kern_return_t           kr;
    thread_array_t          threadList;         // 保存當(dāng)前Mach task的線程列表
    mach_msg_type_number_t  threadCount;        // 保存當(dāng)前Mach task的線程個數(shù)
    thread_info_data_t      threadInfo;         // 保存單個線程的信息列表
    mach_msg_type_number_t  threadInfoCount;    // 保存當(dāng)前線程的信息列表大小
    thread_basic_info_t     threadBasicInfo;    // 線程的基本信息
    
    // 通過“task_threads”API調(diào)用獲取指定 task 的線程列表
    //  mach_task_self_辙培，表示獲取當(dāng)前的 Mach task
    kr = task_threads(mach_task_self(), &threadList, &threadCount);
    if (kr != KERN_SUCCESS) {
        return -1;
    }
    double cpuUsage = 0;
    for (int i = 0; i < threadCount; i++) {
        threadInfoCount = THREAD_INFO_MAX;
        // 通過“thread_info”API調(diào)用來查詢指定線程的信息
        //  flavor參數(shù)傳的是THREAD_BASIC_INFO，使用這個類型會返回線程的基本信息邢锯，
        //  定義在 thread_basic_info_t 結(jié)構(gòu)體扬蕊，包含了用戶和系統(tǒng)的運行時間、運行狀態(tài)和調(diào)度優(yōu)先級等
        kr = thread_info(threadList[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount);
        if (kr != KERN_SUCCESS) {
            return -1;
        }
        
        threadBasicInfo = (thread_basic_info_t)threadInfo;
        if (!(threadBasicInfo->flags & TH_FLAGS_IDLE)) {
            cpuUsage += threadBasicInfo->cpu_usage;
        }
    }
    
    // 回收內(nèi)存丹擎，防止內(nèi)存泄漏
    vm_deallocate(mach_task_self(), (vm_offset_t)threadList, threadCount * sizeof(thread_t));

    return cpuUsage / (double)TH_USAGE_SCALE * 100.0;
}
@end

2. 內(nèi)存

雖然現(xiàn)在的手機(jī)內(nèi)存越來越大尾抑，但畢竟是有限的，如果因為我們的應(yīng)用設(shè)計不當(dāng)造成內(nèi)存過高，可能面臨被系統(tǒng)“干掉”的風(fēng)險蛮穿，這對用戶來說是毀滅性的體驗庶骄。

Mach task 的內(nèi)存使用信息存放在mach_task_basic_info結(jié)構(gòu)體中 ，其中resident_size 為應(yīng)用使用的物理內(nèi)存大小践磅，virtual_size為虛擬內(nèi)存大小单刁，在task_info.h中：

#define MACH_TASK_BASIC_INFO     20         /* always 64-bit basic info */
struct mach_task_basic_info {
        mach_vm_size_t  virtual_size;       /* virtual memory size (bytes) */
        mach_vm_size_t  resident_size;      /* resident memory size (bytes) */
        mach_vm_size_t  resident_size_max;  /* maximum resident memory size (bytes) */
        time_value_t    user_time;          /* total user run time for
                                               terminated threads */
        time_value_t    system_time;        /* total system run time for
                                               terminated threads */
        policy_t        policy;             /* default policy for new threads */
        integer_t       suspend_count;      /* suspend count for task */
};

獲取方式是通過task_infoAPI 根據(jù)指定的 flavor 類型，返回 target_task 的信息府适，在task.h中：

kern_return_t task_info
(
    task_name_t target_task,
    task_flavor_t flavor,
    task_info_t task_info_out,
    mach_msg_type_number_t *task_info_outCnt
);

筆者嘗試過使用如下方式獲取內(nèi)存情況羔飞，基本和騰訊的GT的相近，但是和Xcode和Instruments的值有較大差距：

// 獲取當(dāng)前應(yīng)用的內(nèi)存占用情況檐春，和Xcode數(shù)值相差較大
+ (double)getResidentMemory {
    struct mach_task_basic_info info;
    mach_msg_type_number_t count = MACH_TASK_BASIC_INFO_COUNT;
    if (task_info(mach_task_self(), MACH_TASK_BASIC_INFO, (task_info_t)&info, &count) == KERN_SUCCESS) {
        return info.resident_size / (1024 * 1024);
    } else {
        return -1.0;
    }
}

后來看了一篇博主討論了這個問題逻淌，說使用phys_footprint才是正解，博客地址疟暖。親測卡儒，基本和Xcode的數(shù)值相近。

// 獲取當(dāng)前應(yīng)用的內(nèi)存占用情況俐巴，和Xcode數(shù)值相近
+ (double)getMemoryUsage {
    task_vm_info_data_t vmInfo;
    mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
    if(task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count) == KERN_SUCCESS) {
        return (double)vmInfo.phys_footprint / (1024 * 1024);
    } else {
        return -1.0;
    }
}

博主文中提到：關(guān)于 phys_footprint 的定義可以在 XNU 源碼中骨望，找到 osfmk/kern/task.c 里對于 phys_footprint 的注釋，博主認(rèn)為注釋里提到的公式計算的應(yīng)該才是應(yīng)用實際使用的物理內(nèi)存欣舵。

/*
 * phys_footprint
 *   Physical footprint: This is the sum of:
 *     + (internal - alternate_accounting)
 *     + (internal_compressed - alternate_accounting_compressed)
 *     + iokit_mapped
 *     + purgeable_nonvolatile
 *     + purgeable_nonvolatile_compressed
 *     + page_table
 *
 * internal
 *   The task's anonymous memory, which on iOS is always resident.
 *
 * internal_compressed
 *   Amount of this task's internal memory which is held by the compressor.
 *   Such memory is no longer actually resident for the task [i.e., resident in its pmap],
 *   and could be either decompressed back into memory, or paged out to storage, depending
 *   on our implementation.
 *
 * iokit_mapped
 *   IOKit mappings: The total size of all IOKit mappings in this task, regardless of
     clean/dirty or internal/external state].
 *
 * alternate_accounting
 *   The number of internal dirty pages which are part of IOKit mappings. By definition, these pages
 *   are counted in both internal *and* iokit_mapped, so we must subtract them from the total to avoid
 *   double counting.
 */

當(dāng)然我也是贊同這點的>.<擎鸠。

3. 啟動時間

APP的啟動時間，直接影響用戶對你的APP的第一體驗和判斷缘圈。如果啟動時間過長劣光，不單單體驗直線下降，而且可能會激發(fā)蘋果的watch dog機(jī)制kill掉你的APP糟把，那就悲劇了绢涡，用戶會覺得APP怎么一啟動就卡死然后崩潰了，不能用遣疯，然后長按APP點擊刪除鍵雄可。（Xcode在debug模式下是沒有開啟watch dog的，所以我們一定要連接真機(jī)測試我們的APP）

在衡量APP的啟動時間之前我們先了解下另锋，APP的啟動流程：

APP啟動過程

APP的啟動可以分為兩個階段，即main()執(zhí)行之前和main()執(zhí)行之后狭归∝财海總結(jié)如下：

t(App 總啟動時間) = t1( main()之前的加載時間 ) + t2( main()之后的加載時間 )。

  • t1 = 系統(tǒng)的 dylib (動態(tài)鏈接庫)和 App 可執(zhí)行文件的加載時間过椎；
  • t2 = main()函數(shù)執(zhí)行之后到AppDelegate類中的applicationDidFinishLaunching:withOptions:方法執(zhí)行結(jié)束前這段時間室梅。

所以我們對APP啟動時間的獲取和優(yōu)化都是從這兩個階段著手，下面先看看main()函數(shù)執(zhí)行之前如何獲取啟動時間。

衡量main()函數(shù)執(zhí)行之前的耗時

對于衡量main()之前也就是time1的耗時亡鼠，蘋果官方提供了一種方法赏殃，即在真機(jī)調(diào)試的時候，勾選DYLD_PRINT_STATISTICS選項（如果想獲取更詳細(xì)的信息可以使用DYLD_PRINT_STATISTICS_DETAILS）间涵，如下圖：

main()函數(shù)之前

輸出結(jié)果如下：

Total pre-main time:  34.22 milliseconds (100.0%)
         dylib loading time:  14.43 milliseconds (42.1%)
        rebase/binding time:   1.82 milliseconds (5.3%)
            ObjC setup time:   3.89 milliseconds (11.3%)
           initializer time:  13.99 milliseconds (40.9%)
           slowest intializers :
             libSystem.B.dylib :   2.20 milliseconds (6.4%)
   libBacktraceRecording.dylib :   2.90 milliseconds (8.4%)
    libMainThreadChecker.dylib :   6.55 milliseconds (19.1%)
       libswiftCoreImage.dylib :   0.71 milliseconds (2.0%)

系統(tǒng)級別的動態(tài)鏈接庫仁热，因為蘋果做了優(yōu)化，所以耗時并不多勾哩，而大多數(shù)時候抗蠢，t1的時間大部分會消耗在我們自身App中的代碼上和鏈接第三方庫上。

所以我們應(yīng)如何減少main()調(diào)用之前的耗時呢思劳，我們可以優(yōu)化的點有：

  1. 減少不必要的framework迅矛，特別是第三方的，因為動態(tài)鏈接比較耗時潜叛；
  2. check framework應(yīng)設(shè)為optional和required秽褒，如果該framework在當(dāng)前App支持的所有iOS系統(tǒng)版本都存在，那么就設(shè)為required威兜，否則就設(shè)為optional销斟，因為optional會有些額外的檢查；
  3. 合并或者刪減一些OC類牡属，關(guān)于清理項目中沒用到的類票堵，可以借助AppCode代碼檢查工具：
  • 刪減一些無用的靜態(tài)變量
  • 刪減沒有被調(diào)用到或者已經(jīng)廢棄的方法
  • 將不必須在+load方法中做的事情延遲到+initialize中
  • 盡量不要用C++虛函數(shù)(創(chuàng)建虛函數(shù)表有開銷)

衡量main()函數(shù)執(zhí)行之后的耗時

第二階段的耗時統(tǒng)計，我們認(rèn)為是從main ()執(zhí)行之后到applicationDidFinishLaunching:withOptions:方法最后逮栅，那么我們可以通過打點的方式進(jìn)行統(tǒng)計悴势。
Objective-C項目因為有main文件，所以我么直接可以通過添加代碼獲却敕ァ：

// 1. 在 main.m 添加如下代碼:
CFAbsoluteTime AppStartLaunchTime;

int main(int argc, char * argv[]) {
    AppStartLaunchTime = CFAbsoluteTimeGetCurrent();
  .....
}

// 2. 在 AppDelegate.m 的開頭聲明
extern CFAbsoluteTime AppStartLaunchTime;

// 3. 最后在AppDelegate.m 的 didFinishLaunchingWithOptions 中添加
dispatch_async(dispatch_get_main_queue(), ^{
  NSLog(@"App啟動時間--%f",(CFAbsoluteTimeGetCurrent()-AppStartLaunchTime));
});

大家都知道Swift項目是沒有main文件特纤，官方給了如下解釋:

In Xcode, Mac templates default to including a “main.swift” file, but for iOS apps the default for new iOS project templates is to add @UIApplicationMain to a regular Swift file. This causes the compiler to synthesize a mainentry point for your iOS app, and eliminates the need for a “main.swift” file.

也就是說，通過添加@UIApplicationMain標(biāo)志的方式侥加，幫我們添加了mian函數(shù)了捧存。所以如果是我們需要在mian函數(shù)中做一些其它操作的話，需要我們自己來創(chuàng)建main.swift文件担败，這個也是蘋果允許的昔穴。

    1. 刪除AppDelegate類中的 @UIApplicationMain標(biāo)志；
    1. 自行創(chuàng)建main.swift文件提前，并添加程序入口：
import UIKit

var appStartLaunchTime: CFAbsoluteTime = CFAbsoluteTimeGetCurrent()

UIApplicationMain(
    CommandLine.argc,
    UnsafeMutableRawPointer(CommandLine.unsafeArgv)
        .bindMemory(
            to: UnsafeMutablePointer<Int8>.self,
            capacity: Int(CommandLine.argc)),
    nil,
    NSStringFromClass(AppDelegate.self)
)
    1. 在AppDelegate的didFinishLaunchingWithOptions :方法最后添加：
// APP啟動時間耗時吗货，從mian函數(shù)開始到didFinishLaunchingWithOptions方法結(jié)束
DispatchQueue.main.async {
  print("APP啟動時間耗時，從mian函數(shù)開始到didFinishLaunchingWithOptions方法：\(CFAbsoluteTimeGetCurrent() - appStartLaunchTime)狈网。")
}

main函數(shù)之后的優(yōu)化：

    1. 盡量使用純代碼編寫宙搬，減少xib的使用笨腥；
    1. 啟動階段的網(wǎng)絡(luò)請求，是否都放到異步請求勇垛；
    1. 一些耗時的操作是否可以放到后面去執(zhí)行脖母，或異步執(zhí)行等。

4. FPS

通過維基百科我們知道闲孤，FPS是Frames Per Second 的簡稱縮寫谆级，意思是每秒傳輸幀數(shù)，也就是我們常說的“刷新率（單位為Hz）崭放。

FPS是測量用于保存哨苛、顯示動態(tài)視頻的信息數(shù)量。每秒鐘幀數(shù)愈多币砂，所顯示的畫面就會愈流暢建峭，FPS值越低就越卡頓，所以這個值在一定程度上可以衡量應(yīng)用在圖像繪制渲染處理時的性能决摧。一般我們的APP的FPS只要保持在 50-60之間亿蒸，用戶體驗都是比較流暢的。

蘋果手機(jī)屏幕的正常刷新頻率是每秒60次掌桩，即可以理解為FPS值為60边锁。我們都知道CADisplayLink是和屏幕刷新頻率保存一致，所以我們是否可以通過它來監(jiān)控我們的FPS呢波岛？茅坛！

首先CADisplayLink是什么

CADisplayLink是CoreAnimation提供的另一個類似于NSTimer的類，它總是在屏幕完成一次更新之前啟動则拷，它的接口設(shè)計的和NSTimer很類似贡蓖，所以它實際上就是一個內(nèi)置實現(xiàn)的替代，但是和timeInterval以秒為單位不同煌茬，CADisplayLink有一個整型的frameInterval屬性斥铺，指定了間隔多少幀之后才執(zhí)行。默認(rèn)值是1坛善，意味著每次屏幕更新之前都會執(zhí)行一次晾蜘。但是如果動畫的代碼執(zhí)行起來超過了六十分之一秒，你可以指定frameInterval為2眠屎，就是說動畫每隔一幀執(zhí)行一次（一秒鐘30幀）剔交。

使用CADisplayLink監(jiān)控界面的FPS值，參考自YYFPSLabel：

import UIKit

class LSLFPSMonitor: UILabel {

    private var link: CADisplayLink = CADisplayLink.init()
    private var count: NSInteger = 0
    private var lastTime: TimeInterval = 0.0
    private var fpsColor: UIColor = UIColor.green
    public var fps: Double = 0.0
    
    // MARK: - init
    
    override init(frame: CGRect) {
        var f = frame
        if f.size == CGSize.zero {
            f.size = CGSize(width: 55.0, height: 22.0)
        }
        super.init(frame: f)
        
        self.textColor = UIColor.white
        self.textAlignment = .center
        self.font = UIFont.init(name: "Menlo", size: 12.0)
        self.backgroundColor = UIColor.black
        
        link = CADisplayLink.init(target: LSLWeakProxy(target: self), selector: #selector(tick))
        link.add(to: RunLoop.current, forMode: RunLoopMode.commonModes)
    }
    
    deinit {
        link.invalidate()
    }
    
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: - actions
    
    @objc func tick(link: CADisplayLink) {
        guard lastTime != 0 else {
            lastTime = link.timestamp
            return
        }
        
        count += 1
        let delta = link.timestamp - lastTime
        guard delta >= 1.0 else {
            return
        }
        
        lastTime = link.timestamp
        fps = Double(count) / delta
        let fpsText = "\(String.init(format: "%.3f", 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([NSAttributedStringKey.foregroundColor:fpsColor], range: NSMakeRange(0, attrMStr.length - 3))
        attrMStr.setAttributes([NSAttributedStringKey.foregroundColor:UIColor.white], range: NSMakeRange(attrMStr.length - 3, 3))
        DispatchQueue.main.async {
            self.attributedText = attrMStr
        }
    }
}

通過CADisplayLink的實現(xiàn)方式改衩，并真機(jī)測試之后岖常，確實是可以在很大程度上滿足了監(jiān)控FPS的業(yè)務(wù)需求和為提高用戶體驗提供參考，但是和Instruments的值可能會有些出入燎字。下面我們來討論下使用CADisplayLink的方式腥椒，可能存在的問題。

  • (1). 和Instruments值對比有出入候衍，原因如下:

CADisplayLink運行在被添加的那個RunLoop之中（一般是在主線程中）笼蛛，因此它只能檢測出當(dāng)前RunLoop下的幀率。RunLoop中所管理的任務(wù)的調(diào)度時機(jī)蛉鹿，受任務(wù)所處的RunLoopMode和CPU的繁忙程度所影響滨砍。所以想要真正定位到準(zhǔn)確的性能問題所在，最好還是通過Instrument來確認(rèn)妖异。

  • (2). 使用CADisplayLink可能存在的循環(huán)引用問題惋戏。

例如以下寫法：

let link = CADisplayLink.init(target: self, selector: #selector(tick))

let timer = Timer.init(timeInterval: 1.0, target: self, selector: #selector(tick), userInfo: nil, repeats: true)

原因：以上兩種用法，都會對 self 強(qiáng)引用他膳，此時 timer持有 self响逢，self 也持有 timer，循環(huán)引用導(dǎo)致頁面 dismiss 時棕孙，雙方都無法釋放舔亭，造成循環(huán)引用。此時使用 weak 也不能有效解決:

weak var weakSelf = self
let link = CADisplayLink.init(target: weakSelf, selector: #selector(tick))

那么我們應(yīng)該怎樣解決這個問題蟀俊，有人會說在deinit(或dealloc)中調(diào)用定時器的invalidate方法钦铺，但是這是無效的，因為已經(jīng)造成循環(huán)引用了肢预，不會走到這個方法的矛洞。

YYKit作者提供的解決方案是使用 YYWeakProxy，這個YYWeakProxy不是繼承自NSObject而是繼承NSProxy烫映。

NSProxy

An abstract superclass defining an API for objects that act as stand-ins for other objects or for objects that don’t exist yet.

NSProxy是一個為對象定義接口的抽象父類沼本，并且為其它對象或者一些不存在的對象扮演了替身角色。具體的可以看下NSProxy的官方文檔
修改后代碼如下窑邦，親測定時器如愿釋放擅威，LSLWeakProxy的具體實現(xiàn)代碼已經(jīng)同步到github中。

let link = CADisplayLink.init(target: LSLWeakProxy(target: self), selector: #selector(tick))

5. 卡頓

在了解卡頓產(chǎn)生的原因之前冈钦，先看下屏幕顯示圖像的原理屎鳍。

屏幕顯示圖像的原理：

屏幕繪制原理

現(xiàn)在的手機(jī)設(shè)備基本都是采用雙緩存+垂直同步（即V-Sync）屏幕顯示技術(shù)。

如上圖所示辫封，系統(tǒng)內(nèi)CPU息拜、GPU和顯示器是協(xié)同完成顯示工作的。其中CPU負(fù)責(zé)計算顯示的內(nèi)容较幌，例如視圖創(chuàng)建揍瑟、布局計算、圖片解碼乍炉、文本繪制等等绢片。隨后CPU將計算好的內(nèi)容提交給GPU滤馍，由GPU進(jìn)行變換、合成底循、渲染巢株。GPU會預(yù)先渲染好一幀放入一個緩沖區(qū)內(nèi)，讓視頻控制器讀取熙涤，當(dāng)下一幀渲染好后阁苞，GPU會直接將視頻控制器的指針指向第二個容器（雙緩存原理）。這里祠挫，GPU會等待顯示器的VSync（即垂直同步）信號發(fā)出后那槽，才進(jìn)行新的一幀渲染和緩沖區(qū)更新（這樣能解決畫面撕裂現(xiàn)象，也增加了畫面流暢度等舔，但需要消費更多的計算資源骚灸，也會帶來部分延遲）。

卡頓的原因：

掉幀

由上面屏幕顯示的原理慌植，采用了垂直同步機(jī)制的手機(jī)設(shè)備逢唤。如果在一個VSync 時間內(nèi)，CPU 或GPU 沒有完成內(nèi)容提交涤浇，則那一幀就會被丟棄鳖藕，等待下一次機(jī)會再顯示，而這時顯示屏?xí)Ａ糁暗膬?nèi)容不變只锭。例如在主線程里添加了阻礙主線程去響應(yīng)點擊著恩、滑動事件、以及阻礙主線程的UI繪制等的代碼蜻展，都是造成卡頓的常見原因喉誊。

卡頓監(jiān)控：

卡頓監(jiān)控一般有兩種實現(xiàn)方案：

  • (1). 主線程卡頓監(jiān)控。通過子線程監(jiān)測主線程的runLoop纵顾，判斷兩個狀態(tài)區(qū)域之間的耗時是否達(dá)到一定閾值伍茄。

  • (2). FPS監(jiān)控。要保持流暢的UI交互施逾，App 刷新率應(yīng)該當(dāng)努力保持在 60fps敷矫。FPS的監(jiān)控實現(xiàn)原理，上面已經(jīng)探討過這里略過汉额。

在使用FPS監(jiān)控性能的實踐過程中曹仗，發(fā)現(xiàn) FPS 值抖動較大，造成偵測卡頓比較困難蠕搜。為了解決這個問題怎茫，通過采用檢測主線程每次執(zhí)行消息循環(huán)的時間，當(dāng)這一時間大于規(guī)定的閾值時妓灌，就記為發(fā)生了一次卡頓的方式來監(jiān)控轨蛤。
這也是美團(tuán)的移動端采用的性能監(jiān)控Hertz 方案蜜宪，微信團(tuán)隊也在實踐過程中提出來類似的方案--微信讀書 iOS 性能優(yōu)化總結(jié)。

美團(tuán)Hertz方案流程圖

方案的提出祥山，是根據(jù)滾動引發(fā)的Sources事件或其它交互事件總是被快速的執(zhí)行完成端壳，然后進(jìn)入到kCFRunLoopBeforeWaiting狀態(tài)下；假如在滾動過程中發(fā)生了卡頓現(xiàn)象枪蘑，那么RunLoop必然會保持kCFRunLoopAfterWaiting或者kCFRunLoopBeforeSources這兩個狀態(tài)之一。

所以監(jiān)控主線程卡頓的方案一：

開辟一個子線程岖免，然后實時計算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 兩個狀態(tài)區(qū)域之間的耗時是否超過某個閥值岳颇，來斷定主線程的卡頓情況。
但是由于主線程的RunLoop在閑置時基本處于Before Waiting狀態(tài)颅湘，這就導(dǎo)致了即便沒有發(fā)生任何卡頓话侧，這種檢測方式也總能認(rèn)定主線程處在卡頓狀態(tài)。

為了解決這個問題寒神(南梔傾寒)給出了自己的解決方案闯参，Swift的卡頓檢測第三方ANREye瞻鹏。這套卡頓監(jiān)控方案大致思路為：創(chuàng)建一個子線程進(jìn)行循環(huán)檢測，每次檢測時設(shè)置標(biāo)記位為YES鹿寨，然后派發(fā)任務(wù)到主線程中將標(biāo)記位設(shè)置為NO新博。接著子線程沉睡超時闕值時長，判斷標(biāo)志位是否成功設(shè)置成NO脚草，如果沒有說明主線程發(fā)生了卡頓赫悄。

結(jié)合這套方案，當(dāng)主線程處在Before Waiting狀態(tài)的時候馏慨，通過派發(fā)任務(wù)到主線程來設(shè)置標(biāo)記位的方式處理常態(tài)下的卡頓檢測：

#define lsl_SEMAPHORE_SUCCESS 0
static BOOL lsl_is_monitoring = NO;
static dispatch_semaphore_t lsl_semaphore;
static NSTimeInterval lsl_time_out_interval = 0.05;


@implementation LSLAppFluencyMonitor

static inline dispatch_queue_t __lsl_fluecy_monitor_queue() {
    static dispatch_queue_t lsl_fluecy_monitor_queue;
    static dispatch_once_t once;
    dispatch_once(&once, ^{
        lsl_fluecy_monitor_queue = dispatch_queue_create("com.dream.lsl_monitor_queue", NULL);
    });
    return lsl_fluecy_monitor_queue;
}

static inline void __lsl_monitor_init() {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        lsl_semaphore = dispatch_semaphore_create(0);
    });
}

#pragma mark - Public
+ (instancetype)monitor {
    return [LSLAppFluencyMonitor new];
}

- (void)startMonitoring {
    if (lsl_is_monitoring) { return; }
    lsl_is_monitoring = YES;
    __lsl_monitor_init();
    dispatch_async(__lsl_fluecy_monitor_queue(), ^{
        while (lsl_is_monitoring) {
            __block BOOL timeOut = YES;
            dispatch_async(dispatch_get_main_queue(), ^{
                timeOut = NO;
                dispatch_semaphore_signal(lsl_semaphore);
            });
            [NSThread sleepForTimeInterval: lsl_time_out_interval];
            if (timeOut) {
                [LSLBacktraceLogger lsl_logMain];       // 打印主線程調(diào)用棧
//                [LSLBacktraceLogger lsl_logCurrent];    // 打印當(dāng)前線程的調(diào)用棧
//                [LSLBacktraceLogger lsl_logAllThread];  // 打印所有線程的調(diào)用棧
            }
            dispatch_wait(lsl_semaphore, DISPATCH_TIME_FOREVER);
        }
    });
}

- (void)stopMonitoring {
    if (!lsl_is_monitoring) { return; }
    lsl_is_monitoring = NO;
}

@end

其中LSLBacktraceLogger是獲取堆棧信息的類埂淮，詳情見代碼Github。

打印日志如下:

2018-08-16 12:36:33.910491+0800 AppPerformance[4802:171145] Backtrace of Thread 771:
======================================================================================
libsystem_kernel.dylib         0x10d089bce __semwait_signal + 10
libsystem_c.dylib              0x10ce55d10 usleep + 53
AppPerformance                 0x108b8b478 $S14AppPerformance25LSLFPSTableViewControllerC05tableD0_12cellForRowAtSo07UITableD4CellCSo0kD0C_10Foundation9IndexPathVtF + 1144
AppPerformance                 0x108b8b60b $S14AppPerformance25LSLFPSTableViewControllerC05tableD0_12cellForRowAtSo07UITableD4CellCSo0kD0C_10Foundation9IndexPathVtFTo + 155
UIKitCore                      0x1135b104f -[_UIFilteredDataSource tableView:cellForRowAtIndexPath:] + 95
UIKitCore                      0x1131ed34d -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 765
UIKitCore                      0x1131ed8da -[UITableView _createPreparedCellForGlobalRow:willDisplay:] + 73
UIKitCore                      0x1131b4b1e -[UITableView _updateVisibleCellsNow:isRecursive:] + 2863
UIKitCore                      0x1131d57eb -[UITableView layoutSubviews] + 165
UIKitCore                      0x1133921ee -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1501
QuartzCore                     0x10ab72eb1 -[CALayer layoutSublayers] + 175
QuartzCore                     0x10ab77d8b _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 395
QuartzCore                     0x10aaf3b45 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 349
QuartzCore                     0x10ab285b0 _ZN2CA11Transaction6commitEv + 576
QuartzCore                     0x10ab29374 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 76
CoreFoundation                 0x109dc3757 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
CoreFoundation                 0x109dbdbde __CFRunLoopDoObservers + 430
CoreFoundation                 0x109dbe271 __CFRunLoopRun + 1537
CoreFoundation                 0x109dbd931 CFRunLoopRunSpecific + 625
GraphicsServices               0x10f5981b5 GSEventRunModal + 62
UIKitCore                      0x112c812ce UIApplicationMain + 140
AppPerformance                 0x108b8c1f0 main + 224
libdyld.dylib                  0x10cd4dc9d start + 1

======================================================================================

方案二是結(jié)合CADisplayLink的方式實現(xiàn)

在檢測FPS值的時候写隶，我們就詳細(xì)介紹了CADisplayLink的使用方式倔撞，在這里也可以通過FPS值是否連續(xù)低于某個值開進(jìn)行監(jiān)控。

后續(xù)

關(guān)于更多APP性能監(jiān)控的內(nèi)容慕趴，包括網(wǎng)絡(luò)狀況監(jiān)控痪蝇、啟動時閃退、使用時崩潰冕房、耗電量監(jiān)控霹俺、流量監(jiān)控等等，由于篇幅太長毒费，將作為第二篇文中發(fā)出丙唧，歡迎交流探討。

文中所提的所以實例代碼：

Github

相關(guān)文章：

今日頭條iOS客戶端啟動速度優(yōu)化
騰訊--iOS APP 性能檢測
iOS查看屏幕幀數(shù)工具--YYFPSLabel
YYKit
美團(tuán)--移動端性能監(jiān)控方案Hertz
YYKit 作者--iOS 保持界面流暢的技巧
“sindri的小巢”的（iOS監(jiān)控-卡頓檢測）

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末觅玻，一起剝皮案震驚了整個濱河市想际，隨后出現(xiàn)的幾起案子培漏，更是在濱河造成了極大的恐慌，老刑警劉巖胡本，帶你破解...
    沈念sama閱讀 206,968評論 6贊 482
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件牌柄，死亡現(xiàn)場離奇詭異，居然都是意外死亡侧甫，警方通過查閱死者的電腦和手機(jī)珊佣，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來披粟，“玉大人咒锻，你說我怎么就攤上這事∈靥耄” “怎么了惑艇？”我有些...
    開封第一講書人閱讀 153,220評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長拇泛。 經(jīng)常有香客問我滨巴，道長，這世上最難降的妖魔是什么俺叭？ 我笑而不...
    開封第一講書人閱讀 55,416評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任恭取，我火速辦了婚禮，結(jié)果婚禮上熄守，老公的妹妹穿的比我還像新娘秽荤。我一直安慰自己，他們只是感情好柠横，可當(dāng)我...
    茶點故事閱讀 64,425評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布窃款。 她就那樣靜靜地躺著，像睡著了一般牍氛。 火紅的嫁衣襯著肌膚如雪晨继。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,144評論 1贊 285
  • 城市分裂傳說
    那天搬俊，我揣著相機(jī)與錄音紊扬，去河邊找鬼。 笑死唉擂，一個胖子當(dāng)著我的面吹牛餐屎，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播玩祟，決...
    沈念sama閱讀 38,432評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼腹缩，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起藏鹊，我...
    開封第一講書人閱讀 37,088評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤润讥，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后盘寡，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體楚殿，經(jīng)...
    沈念sama閱讀 43,586評論 1贊 300
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,028評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年竿痰，在試婚紗的時候發(fā)現(xiàn)自己被綠了脆粥。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,137評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡影涉，死狀恐怖变隔，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情常潮，我是刑警寧澤，帶...
    沈念sama閱讀 33,783評論 4贊 324
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布楷力，位于F島的核電站喊式，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏萧朝。R本人自食惡果不足惜岔留，卻給世界環(huán)境...
    茶點故事閱讀 39,343評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望检柬。 院中可真熱鬧献联，春花似錦、人聲如沸何址。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽用爪。三九已至原押，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間偎血，已是汗流浹背诸衔。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留颇玷，地道東北人笨农。 一個月前我還...
    沈念sama閱讀 45,595評論 2贊 355
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像帖渠，于是被迫代替她去往敵國和親谒亦。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,901評論 2贊 345

推薦閱讀更多精彩內(nèi)容

  • 作者：敖志敏本文為原創(chuàng)文章，轉(zhuǎn)載請注明作者及出處 為什么寫這篇文章诊霹？ 隨著移動互聯(lián)網(wǎng)向縱深發(fā)展羞延，用戶變得越來越關(guān)心...
    滬江技術(shù)學(xué)院閱讀 6,117評論 2贊 83
  • 前言 眾所周知，如今的用戶變得越來越關(guān)心app的體驗脾还，開發(fā)者必須關(guān)注應(yīng)用性能所帶來的用戶流失問題伴箩。目前危害較大的性...
    PerTerbin閱讀 9,637評論 5贊 32
  • 概述 RunLoop作為iOS中一個基礎(chǔ)組件和線程有著千絲萬縷的關(guān)系，同時也是很多常見技術(shù)的幕后功臣鄙漏。盡管在平時多...
    陽明先生_x閱讀 1,092評論 0贊 17
  • 最近看了很多RunLoop的文章嗤谚，看完很懵逼，決心整理一下怔蚌，文章中大部分內(nèi)容都是引用大神們的巩步，但好歹對自己有個交代...
    小涼介閱讀 6,680評論 12贊 79
  • 1.ios高性能編程 (1).內(nèi)層 最小的內(nèi)層平均值和峰值(2).耗電量 高效的算法和數(shù)據(jù)結(jié)構(gòu)(3).初始化時...
    歐辰_OSR閱讀 29,321評論 8贊 265