app开发项目中怎样进行app性能检测？

app开发中关于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 结构体封装了单个线程的基本信息： structthread_basic_info{ time_value_tuser_time;  time_value_tsystem_time;  integer_tcpu_usage;  policy_tpolicy;  integer_trun_state;  integer_tflags;  integer_tsuspend_count;  integer_tsleep_time;  }  一个Mach Task包含它的线程列表。内核提供了task_threads API 调用获取指定 task 的线程列表，然后可以通过thread_info API调用来查询指定线程的信息，在 thread_act.h 中有相关定义。 task_threads 将target_task 任务中的所有线程保存在act_list数组中，act_listCnt表示线程个数： kern_return_ttask_threads  (  task_ttarget_task,  thread_act_array_t*act_list,  mach_msg_type_number_t*act_listCnt  );  thread_info结构如下：  kern_return_tthread_info  (  thread_act_ttarget_act,  thread_flavor_tflavor, // 传入不同的宏定义获取不同的线程信息 thread_info_tthread_info_out, // 查询到的线程信息 mach_msg_type_number_t*thread_info_outCnt // 信息的大小 );  所以我们如下来获取CPU的占有率： #import "LSLCpuUsage.h" #import

#import #import #import #import @implementation LSLCpuUsage  + ( double)getCpuUsage {  kern_return_tkr;  thread_array_tthreadList; // 保存当前Mach task的线程列表 mach_msg_type_number_tthreadCount; // 保存当前Mach task的线程个数 thread_info_data_tthreadInfo; // 保存单个线程的信息列表 mach_msg_type_number_tthreadInfoCount; // 保存当前线程的信息列表大小 thread_basic_info_tthreadBasicInfo; // 线程的基本信息 // 通过“task_threads”API调用获取指定 task 的线程列表 // mach_task_self_，表示获取当前的 Mach task kr=task_threads(mach_task_self(), &threadList, &threadCount);  if(kr !=KERN_SUCCESS) {  return-1;  }  doublecpuUsage=0;  for( inti=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));  returncpuUsage / ( double)TH_USAGE_SCALE * 100.0;  }  @end

    2. 内存 虽然现在的手机内存越来越大，但毕竟是有限的，如果因为我们的应用设计不当造成内存过高，可能面临被系统“干掉”的风险，这对用户来说是毁灭性的体验。 Mach task 的内存使用信息存放在mach_task_basic_info结构体中 ，其中resident_size 为应用使用的物理内存大小，virtual_size为虚拟内存大小，在task_info.h中： #defineMACH_TASK_BASIC_INFO 20  structmach_task_basic_info{ mach_vm_size_tvirtual_size;  mach_vm_size_tresident_size;  mach_vm_size_tresident_size_max;  time_value_tuser_time;  time_value_tsystem_time;  policy_tpolicy;  integer_tsuspend_count;  };  获取方式是通过task_infoAPI 根据指定的 flavor 类型，返回 target_task 的信息，在task.h中： kern_return_ttask_info  (  task_name_ttarget_task,  task_flavor_tflavor,  task_info_ttask_info_out,  mach_msg_type_number_t*task_info_outCnt  );  笔者尝试过使用如下方式获取内存情况，基本和腾讯的GT的相近，但是和Xcode和 Instruments的值有较大差距：  // 获取当前应用的内存占用情况，和Xcode数值相差较大 + ( double)getResidentMemory {  structmach_task_basic_infoinfo; mach_msg_type_number_tcount=MACH_TASK_BASIC_INFO_COUNT;  if(task_info(mach_task_self(), MACH_TASK_BASIC_INFO, ( task_info_t)&info, &count)==KERN_SUCCESS) {  returninfo.resident_size / ( 1024* 1024);  } else{  return-1.0;  }  }  后来看了一篇博主讨论了这个问题，说使用phys_footprint才是正解，博客地址。亲测，基本和Xcode的数值相近 // 获取当前应用的内存占用情况，和Xcode数值相近 + ( double)getMemoryUsage {  task_vm_info_data_tvmInfo;  mach_msg_type_number_tcount=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 的注释，博主认为注释里提到的公式计算的应该才是应用实际使用的物理内存。   当然我也是赞同这点的>.<。

   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.22milliseconds ( 100.0%)  dylib loading time: 14.43milliseconds ( 42.1%)  rebase/binding time: 1.82milliseconds ( 5.3%)  ObjC setup time: 3.89milliseconds ( 11.3%)  initializer time: 13.99milliseconds ( 40.9%)  slowest intializers :  libSystem.B.dylib : 2.20milliseconds ( 6.4%)  libBacktraceRecording.dylib : 2.90milliseconds ( 8.4%)  libMainThreadChecker.dylib : 6.55milliseconds ( 19.1%)  libswiftCoreImage.dylib : 0. 71milliseconds ( 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 添加如下代码: CFAbsoluteTimeAppStartLaunchTime;  intmain( intargc, char* argv[]) {  AppStartLaunchTime=CFAbsoluteTimeGetCurrent();  .....  }  // 2. 在 AppDelegate.m 的开头声明 externCFAbsoluteTimeAppStartLaunchTime;  // 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.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 classLSLFPSMonitor: 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  iff.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 !=0else{  lastTime=link.timestamp  return }  count +=1 let delta=link.timestamp - lastTime  guard delta >=1.0else{  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))  iffps > 55.0{  fpsColor=UIColor.green  } elseif(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 也不能有效解决: weakvar 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 staticBOOLlsl_is_monitoring=NO;  staticdispatch_semaphore_t lsl_semaphore;  staticNSTimeIntervallsl_time_out_interval=0.05;  @implementationLSLAppFluencyMonitor staticinlinedispatch_queue_t__lsl_fluecy_monitor_queue() {  staticdispatch_queue_tlsl_fluecy_monitor_queue;  staticdispatch_once_tonce;  dispatch_once(&once, ^{  lsl_fluecy_monitor_queue=dispatch_queue_create( "com.dream.lsl_monitor_queue", NULL);  });  returnlsl_fluecy_monitor_queue;  }  staticinlinevoid__lsl_monitor_init() {  staticdispatch_once_tonceToken;  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 BOOLtimeOut=YES;  dispatch_async(dispatch_get_main_queue(), ^{  timeOut=NO;  dispatch_semaphore_signal(lsl_semaphore);  });  [ NSThreadsleepForTimeInterval: 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-1612: 36: 33.910491+ 0800AppPerformance[ 4802: 171145] Backtrace of Thread 771:  ====================================================================================== libsystem_kernel.dylib 0x10d089bce__semwait_signal + 10 libsystem_c.dylib 0x10ce55d10usleep + 53 AppPerformance 0x108b8b478$S14AppPerformance25LSLFPSTableViewControllerC05tableD0_12cellForRowAtSo07UITableD4CellCSo0kD0C_10Foundation9IndexPathVtF + 1144 AppPerformance 0x108b8b60b$S14AppPerformance25LSLFPSTableViewControllerC05tableD0_12cellForRowAtSo07UITableD4CellCSo0kD0C_10Foundation9IndexPathVtFTo + 155 UIKitCore0x1135b104f-[_UIFilteredDataSource tableView:cellForRowAtIndexPath:] + 95 UIKitCore0x1131ed34d-[ UITableView_createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 765 UIKitCore0x1131ed8da-[ UITableView_createPreparedCellForGlobalRow:willDisplay:] + 73 UIKitCore0x1131b4b1e-[ UITableView_updateVisibleCellsNow:isRecursive:] + 2863 UIKitCore0x1131d57eb-[ UITableViewlayoutSubviews] + 165 UIKitCore0x1133921ee-[ UIView( CALayerDelegate) layoutSublayersOfLayer:] + 1501 QuartzCore 0x10ab72eb1-[ CALayerlayoutSublayers] + 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 0x109dbd931CFRunLoopRunSpecific+ 625 GraphicsServices 0x10f5981b5GSEventRunModal + 62 UIKitCore0x112c812ceUIApplicationMain+ 140 AppPerformance 0x108b8c1f0main + 224 libdyld.dylib 0x10cd4dc9dstart + 1 方案二是结合CADisplayLink的方式实现 在检测FPS值的时候，我们就详细介绍了CADisplayLink的使用方式，在这里也可以通过FPS值是否连续低于某个值开进行监控。