iOS开发--APP性能检测方案汇总

1 . CPU 占用率

CPU做为手机的中央处理器，能够说是手机最关键的组成部分，全部应用程序都须要它来调度运行，资源有限。因此当咱们的APP因设计不当，使 CPU 持续以高负载运行，将会出现APP卡顿、手机发热发烫、电量消耗过快等等严重影响用户体验的现象。git

所以咱们对应用在CPU中占用率的监控，将变得尤其重要。那么咱们应该如何来获取CPU的占有率呢？！github

咱们都知道，咱们的APP在运行的时候，会对应一个Mach Task，而Task下可能有多条线程同时执行任务，每一个线程都是做为利用CPU的基本单位。因此咱们能够经过获取当前Mach Task下，全部线程占用 CPU 的状况，来计算APP的 CPU 占用率。swift

在《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 层实现。bash

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 中有相关定义。markdown

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值是否连续低于某个值开进行监控。