iOS開發--APP性能檢測方案彙總

1 . CPU 佔用率

CPU做爲手機的中央處理器，能夠說是手機最關鍵的組成部分，全部應用程序都須要它來調度運行，資源有限。因此當咱們的APP因設計不當，使 CPU 持續以高負載運行，將會出現APP卡頓、手機發熱發燙、電量消耗過快等等嚴重影響用戶體驗的現象。

所以咱們對應用在CPU中佔用率的監控，將變得尤其重要。那麼咱們應該如何來獲取CPU的佔有率呢？！

咱們都知道，咱們的APP在運行的時候，會對應一個Mach Task，而Task下可能有多條線程同時執行任務，每一個線程都是做爲利用CPU的基本單位。因此咱們能夠經過獲取當前Mach Task下，全部線程佔用 CPU 的狀況，來計算APP的 CPU 佔用率。

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

任務（task）是一種容器（container）對象，虛擬內存空間和其餘資源都是經過這個容器對象管理的，這些資源包括設備和其餘句柄。嚴格地說，Mach 的任務並非其餘操做系統中所謂的進程，由於 Mach 做爲一個微內核的操做系統，並無提供「進程」的邏輯，而只是提供了最基本的實現。不過在 BSD 的模型中，這兩個概念有1：1的簡單映射，每個 BSD 進程（也就是 OS X 進程）都在底層關聯了一個 Mach 任務對象。

Mac OS X 中進程子系統組成的概念圖

iOS 是基於Apple Darwin 內核，由kernel、XNU和Runtime 組成，而XNU是Darwin 的內核，它是「X is not UNIX」的縮寫，是一個混合內核，由 Mach 微內核和 BSD 組成。Mach 內核是輕量級的平臺，只能完成操做系統最基本的職責，好比：進程和線程、虛擬內存管理、任務調度、進程通訊和消息傳遞機制等。其餘的工做，例如文件操做和設備訪問，都由 BSD 層實現。

iOS 的線程技術與Mac OS X相似，也是基於 Mach 線程技術實現的，在 Mach 層中thread_basic_info 結構體封裝了單個線程的基本信息：

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包含它的線程列表。內核提供了task_threads API 調用獲取指定task 的線程列表，而後能夠經過thread_info API調用來查詢指定線程的信息，在 thread_act.h 中有相關定義。

task_threads 將target_task 任務中的全部線程保存在act_list數組中，act_listCnt表示線程個數：

kern_return_t task_threads
(
    task_t target_task,
    thread_act_array_t *act_list,
    mach_msg_type_number_t *act_listCnt
);
thread_info結構以下：
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  // 信息的大小
);
複製代碼

因此咱們以下來獲取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;         // 保存當前Mach task的線程列表
    mach_msg_type_number_t  threadCount;        // 保存當前Mach task的線程個數
    thread_info_data_t      threadInfo;         // 保存單個線程的信息列表
    mach_msg_type_number_t  threadInfoCount;    // 保存當前線程的信息列表大小
    thread_basic_info_t     threadBasicInfo;    // 線程的基本信息

    // 經過「task_threads」API調用獲取指定 task 的線程列表
    //  mach_task_self_，表示獲取當前的 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調用來查詢指定線程的信息
        //  flavor參數傳的是THREAD_BASIC_INFO，使用這個類型會返回線程的基本信息，
        //  定義在 thread_basic_info_t 結構體，包含了用戶和系統的運行時間、運行狀態和調度優先級等
        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;
        }
    }

    // 回收內存，防止內存泄漏
    vm_deallocate(mach_task_self(), (vm_offset_t)threadList, threadCount * sizeof(thread_t));

    return cpuUsage / (double)TH_USAGE_SCALE * 100.0;
}
@end
複製代碼

2. 內存

雖然如今的手機內存愈來愈大，但畢竟是有限的，若是由於咱們的應用設計不當形成內存太高，可能面臨被系統「幹掉」的風險，這對用戶來講是毀滅性的體驗。

Mach task 的內存使用信息存放在mach_task_basic_info結構體中 ，其中resident_size 爲應用使用的物理內存大小，virtual_size爲虛擬內存大小，在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 根據指定的 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
);
複製代碼

筆者嘗試過使用以下方式獲取內存狀況，基本和騰訊的GT的相近，可是和Xcode和Instruments的值有較大差距：

// 獲取當前應用的內存佔用狀況，和Xcode數值相差較大
+ (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的數值相近

// 獲取當前應用的內存佔用狀況，和Xcode數值相近
+ (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;
    }
}
複製代碼

博主文中提到：關於 phys_footprint 的定義能夠在 XNU 源碼中，找到 osfmk/kern/task.c 裏對於 phys_footprint 的註釋，博主認爲註釋裏提到的公式計算的應該纔是應用實際使用的物理內存。

/*
 * 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.
 */
複製代碼

固然我也是贊同這點的>.<。

3. 啓動時間

APP的啓動時間，直接影響用戶對你的APP的第一體驗和判斷。若是啓動時間過長，不僅僅體驗直線降低，並且可能會激發蘋果的watch dog機制kill掉你的APP，那就悲劇了，用戶會以爲APP怎麼一啓動就卡死而後崩潰了，不能用，而後長按APP點擊刪除鍵。（Xcode在debug模式下是沒有開啓watch dog的，因此咱們必定要鏈接真機測試咱們的APP）

在衡量APP的啓動時間以前咱們先了解下，APP的啓動流程：

APP啓動過程

APP的啓動能夠分爲兩個階段，即main()執行以前和main()執行以後。總結以下

t(App 總啓動時間) = t1( main()以前的加載時間 ) + t2( main()以後的加載時間 )。

t1 = 系統的 dylib (動態連接庫)和 App 可執行文件的加載時間；

t2 = main()函數執行以後到AppDelegate類中的applicationDidFinishLaunching:withOptions:方法執行結束前這段時間。

因此咱們對APP啓動時間的獲取和優化都是從這兩個階段着手，下面先看看main()函數執行以前如何獲取啓動時間。

衡量main()函數執行以前的耗時

對於衡量main()以前也就是time1的耗時，蘋果官方提供了一種方法，即在真機調試的時候，勾選DYLD_PRINT_STATISTICS選項（若是想獲取更詳細的信息可使用DYLD_PRINT_STATISTICS_DETAILS），以下圖：

main()函數以前

輸出結果以下：

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%)
複製代碼

系統級別的動態連接庫，由於蘋果作了優化，因此耗時並很少，而大多數時候，t1的時間大部分會消耗在咱們自身App中的代碼上和連接第三方庫上。

因此咱們應如何減小main()調用以前的耗時呢，咱們能夠優化的點有：

減小沒必要要的framework，特別是第三方的，由於動態連接比較耗時；

check framework應設爲optional和required，若是該framework在當前App支持的全部iOS系統版本都存在，那麼就設爲required，不然就設爲optional，由於optional會有些額外的檢查；

合併或者刪減一些OC類，關於清理項目中沒用到的類，能夠藉助AppCode代碼檢查工具：

刪減一些無用的靜態變量

刪減沒有被調用到或者已經廢棄的方法

將沒必要須在+load方法中作的事情延遲到+initialize中

儘可能不要用C++虛函數(建立虛函數表有開銷)

衡量main()函數執行以後的耗時

第二階段的耗時統計，咱們認爲是從main ()執行以後到applicationDidFinishLaunching:withOptions:方法最後，那麼咱們能夠經過打點的方式進行統計。

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文件，官方給了以下解釋:

@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標誌的方式，幫咱們添加了mian函數了。因此若是是咱們須要在mian函數中作一些其它操做的話，須要咱們本身來建立main.swift文件，這個也是蘋果容許的。

刪除AppDelegate類中的 @UIApplicationMain標誌；

自行建立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)
)
複製代碼

在AppDelegate的didFinishLaunchingWithOptions :方法最後添加：

// APP啓動時間耗時，從mian函數開始到didFinishLaunchingWithOptions方法結束
DispatchQueue.main.async {
  print("APP啓動時間耗時，從mian函數開始到didFinishLaunchingWithOptions方法：(CFAbsoluteTimeGetCurrent() - appStartLaunchTime)。")
}
複製代碼

main函數以後的優化：

1.儘可能使用純代碼編寫，減小xib的使用；

2.啓動階段的網絡請求，是否都放到異步請求；

3.一些耗時的操做是否能夠放到後面去執行，或異步執行等。

4. FPS

經過維基百科咱們知道，FPS是Frames Per Second 的簡稱縮寫，意思是每秒傳輸幀數，也就是咱們常說的「刷新率（單位爲Hz）。

FPS是測量用於保存、顯示動態視頻的信息數量。每秒鐘幀數愈多，所顯示的畫面就會愈流暢，FPS值越低就越卡頓，因此這個值在必定程度上能夠衡量應用在圖像繪製渲染處理時的性能。通常咱們的APP的FPS只要保持在 50-60之間，用戶體驗都是比較流暢的。

蘋果手機屏幕的正常刷新頻率是每秒60次，便可以理解爲FPS值爲60。咱們都知道CADisplayLink是和屏幕刷新頻率保存一致，因此咱們是否能夠經過它來監控咱們的FPS呢？！

首先CADisplayLink是什麼

CADisplayLink是CoreAnimation提供的另外一個相似於NSTimer的類，它老是在屏幕完成一次更新以前啓動，它的接口設計的和NSTimer很相似，因此它實際上就是一個內置實現的替代，可是和timeInterval以秒爲單位不一樣，CADisplayLink有一個整型的frameInterval屬性，指定了間隔多少幀以後才執行。默認值是1，意味着每次屏幕更新以前都會執行一次。可是若是動畫的代碼執行起來超過了六十分之一秒，你能夠指定frameInterval爲2，就是說動畫每隔一幀執行一次（一秒鐘30幀）。

使用CADisplayLink監控界面的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的實現方式，並真機測試以後，確實是能夠在很大程度上知足了監控FPS的業務需求和爲提升用戶體驗提供參考，可是和Instruments的值可能會有些出入。下面咱們來討論下使用CADisplayLink的方式，可能存在的問題。

(1). 和Instruments值對比有出入，緣由以下:

CADisplayLink運行在被添加的那個RunLoop之中（通常是在主線程中），所以它只能檢測出當前RunLoop下的幀率。RunLoop中所管理的任務的調度時機，受任務所處的RunLoopMode和CPU的繁忙程度所影響。因此想要真正定位到準確的性能問題所在，最好仍是經過Instrument來確認。

(2). 使用CADisplayLink可能存在的循環引用問題。

例如如下寫法：

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 強引用，此時 timer持有 self，self 也持有 timer，循環引用致使頁面 dismiss 時，雙方都沒法釋放，形成循環引用。此時使用 weak 也不能有效解決:

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

那麼咱們應該怎樣解決這個問題，有人會說在deinit(或dealloc)中調用定時器的invalidate方法，可是這是無效的，由於已經形成循環引用了，不會走到這個方法的。

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是一個爲對象定義接口的抽象父類，而且爲其它對象或者一些不存在的對象扮演了替身角色。

修改後代碼以下，親測定時器如願釋放，LSLWeakProxy的具體實現代碼已經同步到github中。

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

5. 卡頓

在瞭解卡頓產生的緣由以前，先看下屏幕顯示圖像的原理。

屏幕顯示圖像的原理：

6.屏幕繪製原理

如今的手機設備基本都是採用雙緩存+垂直同步（即V-Sync）屏幕顯示技術。

如上圖所示，系統內CPU、GPU和顯示器是協同完成顯示工做的。其中CPU負責計算顯示的內容，例如視圖建立、佈局計算、圖片解碼、文本繪製等等。隨後CPU將計算好的內容提交給GPU，由GPU進行變換、合成、渲染。GPU會預先渲染好一幀放入一個緩衝區內，讓視頻控制器讀取，當下一幀渲染好後，GPU會直接將視頻控制器的指針指向第二個容器（雙緩存原理）。這裏，GPU會等待顯示器的VSync（即垂直同步）信號發出後，才進行新的一幀渲染和緩衝區更新（這樣能解決畫面撕裂現象，也增長了畫面流暢度，但須要消費更多的計算資源，也會帶來部分延遲）。

卡頓的緣由：

7.掉幀

由上面屏幕顯示的原理，採用了垂直同步機制的手機設備。若是在一個VSync 時間內，CPU 或GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留以前的內容不變。例如在主線程裏添加了阻礙主線程去響應點擊、滑動事件、以及阻礙主線程的UI繪製等的代碼，都是形成卡頓的常見緣由。

卡頓監控：

卡頓監控通常有兩種實現方案：

(1). 主線程卡頓監控。經過子線程監測主線程的runLoop，判斷兩個狀態區域之間的耗時是否達到必定閾值。

(2). FPS監控。要保持流暢的UI交互，App 刷新率應該當努力保持在 60fps。FPS的監控實現原理，上面已經探討過這裏略過。

在使用FPS監控性能的實踐過程當中，發現 FPS 值抖動較大，形成偵測卡頓比較困難。爲了解決這個問題，經過採用檢測主線程每次執行消息循環的時間，當這一時間大於規定的閾值時，就記爲發生了一次卡頓的方式來監控。

這也是美團的移動端採用的性能監控Hertz 方案，微信團隊也在實踐過程當中提出來相似的方案--微信讀書 iOS 性能優化總結。

美團Hertz方案流程圖

方案的提出，是根據滾動引起的Sources事件或其它交互事件老是被快速的執行完成，而後進入到kCFRunLoopBeforeWaiting狀態下；假如在滾動過程當中發生了卡頓現象，那麼RunLoop必然會保持kCFRunLoopAfterWaiting或者kCFRunLoopBeforeSources這兩個狀態之一。

因此監控主線程卡頓的方案一：

開闢一個子線程，而後實時計算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 兩個狀態區域之間的耗時是否超過某個閥值，來判定主線程的卡頓狀況。

可是因爲主線程的RunLoop在閒置時基本處於Before Waiting狀態，這就致使了即使沒有發生任何卡頓，這種檢測方式也總能認定主線程處在卡頓狀態。

爲了解決這個問題寒神(南梔傾寒)給出了本身的解決方案，Swift的卡頓檢測第三方ANREye。這套卡頓監控方案大體思路爲：建立一個子線程進行循環檢測，每次檢測時設置標記位爲YES，而後派發任務到主線程中將標記位設置爲NO。接着子線程沉睡超時闕值時長，判斷標誌位是否成功設置成NO，若是沒有說明主線程發生了卡頓。

結合這套方案，當主線程處在Before Waiting狀態的時候，經過派發任務到主線程來設置標記位的方式處理常態下的卡頓檢測：

#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];       // 打印主線程調用棧
//                [LSLBacktraceLogger lsl_logCurrent];    // 打印當前線程的調用棧
//                [LSLBacktraceLogger lsl_logAllThread];  // 打印全部線程的調用棧
            }
            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
複製代碼

方案二是結合CADisplayLink的方式實現

在檢測FPS值的時候，咱們就詳細介紹了CADisplayLink的使用方式，在這裏也能夠經過FPS值是否連續低於某個值開進行監控。