app開發(fā)項(xiàng)目中怎樣進(jìn)行app性能檢測？

apppark.cn" target="_blank">app開發(fā)中關(guān)于app性能的檢測方式有哪些？

     1 . CPU 占用率 CPU作為手機(jī)的中央處理器，可以說是手機(jī)關(guān)鍵的組成部分，所有應(yīng)用程序都需要它來調(diào)度運(yùn)行，資源有限。所以當(dāng)我們的APP因設(shè)計(jì)不當(dāng)，使 CPU 持續(xù)以高負(fù)載運(yùn)行，將會出現(xiàn)APP卡頓、手機(jī)發(fā)熱發(fā)燙、電量消耗過快等等嚴(yán)重影響用戶體驗(yàn)的現(xiàn)象。 因此我們對應(yīng)用在CPU中占用率的監(jiān)控，將變得尤為重要。那么我們應(yīng)該如何來獲取CPU的占有率呢？！ 我們都知道，我們的APP在運(yùn)行的時(shí)候，會對應(yīng)一個(gè)Mach Task，而Task下可能有多條線程同時(shí)執(zhí)行任務(wù)，每個(gè)線程都是作為利用CPU的基本單位。所以我們可以通過獲取當(dāng)前Mach Task下，所有線程占用 CPU 的情況，來計(jì)算APP的 CPU 占用率。

    在《OS X and iOS Kernel Programming》是這樣描述 Mach task 的： 任務(wù)（task）是一種容器（container）對象，虛擬內(nèi)存空間和其他資源都是通過這個(gè)容器對象管理的，這些資源包括設(shè)備和其他句柄。嚴(yán)格地說，Mach 的任務(wù)并不是其他操作系統(tǒng)中所謂的進(jìn)程，因?yàn)?Mach 作為一個(gè)微內(nèi)核的操作系統(tǒng)，并沒有提供“進(jìn)程”的邏輯，而只是提供了基本的實(shí)現(xiàn)。不過在 BSD 的模型中，這兩個(gè)概念有1：1的簡單映射，每一個(gè) BSD 進(jìn)程（也就是 OS X 進(jìn)程）都在底層關(guān)聯(lián)了一個(gè) 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”的縮寫，是一個(gè)混合內(nèi)核，由 Mach 微內(nèi)核和 BSD 組成。Mach 內(nèi)核是輕量級的平臺，只能完成操作系統(tǒng)基本的職責(zé)，比如：進(jìn)程和線程、虛擬內(nèi)存管理、任務(wù)調(diào)度、進(jìn)程通信和消息傳遞機(jī)制等。其他的工作，例如文件操作和設(shè)備訪問，都由 BSD 層實(shí)現(xiàn)。 iOS 的線程技術(shù)與Mac OS X類似，也是基于 Mach 線程技術(shù)實(shí)現(xiàn)的，在 Mach 層中thread_basic_info 結(jié)構(gòu)體封裝了單個(gè)線程的基本信息： 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;  }  一個(gè)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表示線程個(gè)數(shù)： kern_return_ttask_threads  (  task_ttarget_task,  thread_act_array_t*act_list,  mach_msg_type_number_t*act_listCnt  );  thread_info結(jié)構(gòu)如下：  kern_return_tthread_info  (  thread_act_ttarget_act,  thread_flavor_tflavor, // 傳入不同的宏定義獲取不同的線程信息 thread_info_tthread_info_out, // 查詢到的線程信息 mach_msg_type_number_t*thread_info_outCnt // 信息的大小 );  所以我們?nèi)缦聛慝@取CPU的占有率： #import "LSLCpuUsage.h" #import

#import #import #import #import @implementation LSLCpuUsage  + ( double)getCpuUsage {  kern_return_tkr;  thread_array_tthreadList; // 保存當(dāng)前Mach task的線程列表 mach_msg_type_number_tthreadCount; // 保存當(dāng)前Mach task的線程個(gè)數(shù) thread_info_data_tthreadInfo; // 保存單個(gè)線程的信息列表 mach_msg_type_number_tthreadInfoCount; // 保存當(dāng)前線程的信息列表大小 thread_basic_info_tthreadBasicInfo; // 線程的基本信息 // 通過“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;  }  doublecpuUsage=0;  for( inti=0; i < threadCount; i++) {  threadInfoCount=THREAD_INFO_MAX;  // 通過“thread_info”API調(diào)用來查詢指定線程的信息 // flavor參數(shù)傳的是THREAD_BASIC_INFO，使用這個(gè)類型會返回線程的基本信息， // 定義在 thread_basic_info_t 結(jié)構(gòu)體，包含了用戶和系統(tǒng)的運(yùn)行時(shí)間、運(yùn)行狀態(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));  returncpuUsage / ( double)TH_USAGE_SCALE * 100.0;  }  @end

    2. 內(nèi)存 雖然現(xiàn)在的手機(jī)內(nèi)存越來越大，但畢竟是有限的，如果因?yàn)槲覀兊膽?yīng)用設(shè)計(jì)不當(dāng)造成內(nèi)存過高，可能面臨被系統(tǒng)“干掉”的風(fēng)險(xiǎn)，這對用戶來說是毀滅性的體驗(yàn)。 Mach task 的內(nèi)存使用信息存放在mach_task_basic_info結(jié)構(gòu)體中 ，其中resident_size 為應(yīng)用使用的物理內(nèi)存大小，virtual_size為虛擬內(nèi)存大小，在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 根據(jù)指定的 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  );  筆者嘗試過使用如下方式獲取內(nèi)存情況，基本和騰訊的GT的相近，但是和Xcode和 Instruments的值有較大差距：  // 獲取當(dāng)前應(yīng)用的內(nèi)存占用情況，和Xcode數(shù)值相差較大 + ( 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;  }  }  后來看了一篇博主討論了這個(gè)問題，說使用phys_footprint才是正解，博客地址。親測，基本和Xcode的數(shù)值相近 // 獲取當(dāng)前應(yīng)用的內(nèi)存占用情況，和Xcode數(shù)值相近 + ( 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;  }  }  博主文中提到：關(guān)于 phys_footprint 的定義可以在 XNU 源碼中，找到 osfmk/kern/task.c 里對于 phys_footprint 的注釋，博主認(rèn)為注釋里提到的公式計(jì)算的應(yīng)該才是應(yīng)用實(shí)際使用的物理內(nèi)存。   當(dāng)然我也是贊同這點(diǎn)的>.<。

   3. 啟動(dòng)時(shí)間 APP的啟動(dòng)時(shí)間，直接影響用戶對你的APP的為數(shù)不多體驗(yàn)和判斷。如果啟動(dòng)時(shí)間過長，不單單體驗(yàn)直線下降，而且可能會激發(fā)蘋果的watch dog機(jī)制kill掉你的APP，那就悲劇了，用戶會覺得APP怎么一啟動(dòng)就卡死然后崩潰了，不能用，然后長按APP點(diǎn)擊刪除鍵。（Xcode在debug模式下是沒有開啟watch dog的，所以我們一定要連接真機(jī)測試我們的APP） 在衡量APP的啟動(dòng)時(shí)間之前我們先了解下，APP的啟動(dòng)流程：  APP啟動(dòng)過程 APP的啟動(dòng)可以分為兩個(gè)階段，即main()執(zhí)行之前和main()執(zhí)行之后?？偨Y(jié)如下   t(App 總啟動(dòng)時(shí)間)=t1( main()之前的加載時(shí)間 ) + t2( main()之后的加載時(shí)間 )。  t1=系統(tǒng)的 dylib (動(dòng)態(tài)鏈接庫)和 App 可執(zhí)行文件的加載時(shí)間；  t2=main()函數(shù)執(zhí)行之后到AppDelegate類中的applicationDidFinishLaunching:withOptions:方法執(zhí)行結(jié)束前這段時(shí)間。  所以我們對APP啟動(dòng)時(shí)間的獲取和優(yōu)化都是從這兩個(gè)階段著手，下面先看看main()函數(shù)執(zhí)行之前如何獲取啟動(dòng)時(shí)間。 衡量main()函數(shù)執(zhí)行之前的耗時(shí) 對于衡量main()之前也就是time1的耗時(shí)，蘋果官方提供了一種方法，即在真機(jī)調(diào)試的時(shí)候，勾選DYLD_PRINT_STATISTICS選項(xiàng)（如果想獲取更詳細(xì)的信息可以使用DYLD_PRINT_STATISTICS_DETAILS），如下圖：  main()函數(shù)之前 輸出結(jié)果如下： 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%)  系統(tǒng)級別的動(dòng)態(tài)鏈接庫，因?yàn)樘O果做了優(yōu)化，所以耗時(shí)并不多，而大多數(shù)時(shí)候，t1的時(shí)間大部分會消耗在我們自身App中的代碼上和鏈接第三方庫上。 所以我們應(yīng)如何減少main()調(diào)用之前的耗時(shí)呢，我們可以優(yōu)化的點(diǎn)有： 減少不必要的framework，特別是第三方的，因?yàn)閯?dòng)態(tài)鏈接比較耗時(shí)； check framework應(yīng)設(shè)為optional和required，如果該framework在當(dāng)前App支持的所有iOS系統(tǒng)版本都存在，那么就設(shè)為required，否則就設(shè)為optional，因?yàn)閛ptional會有些額外的檢查； 合并或者刪減一些OC類，關(guān)于清理項(xiàng)目中沒用到的類，可以借助AppCode代碼檢查工具： 刪減一些無用的靜態(tài)變量 刪減沒有被調(diào)用到或者已經(jīng)廢棄的方法 將不必須在+load方法中做的事情延遲到+initialize中 盡量不要用C++虛函數(shù)(創(chuàng)建虛函數(shù)表有開銷) 衡量main()函數(shù)執(zhí)行之后的耗時(shí) 第二階段的耗時(shí)統(tǒng)計(jì)，我們認(rèn)為是從main ()執(zhí)行之后到applicationDidFinishLaunching:withOptions:方法較后，那么我們可以通過打點(diǎn)的方式進(jìn)行統(tǒng)計(jì)。 Objective-C項(xiàng)目因?yàn)橛衜ain文件，所以我么直接可以通過添加代碼獲?。?// 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啟動(dòng)時(shí)間--%f",( CFAbsoluteTimeGetCurrent()-AppStartLaunchTime));  });  大家都知道Swift項(xiàng)目是沒有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標(biāo)志的方式，幫我們添加了mian函數(shù)了。所以如果是我們需要在mian函數(shù)中做一些其它操作的話，需要我們自己來創(chuàng)建main.swift文件，這個(gè)也是蘋果允許的。 刪除AppDelegate類中的 @UIApplicationMain標(biāo)志； 自行創(chuàng)建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啟動(dòng)時(shí)間耗時(shí)，從mian函數(shù)開始到didFinishLaunchingWithOptions方法結(jié)束 DispatchQueue.main. async{  print( "APP啟動(dòng)時(shí)間耗時(shí)，從mian函數(shù)開始到didFinishLaunchingWithOptions方法：(CFAbsoluteTimeGetCurrent() - appStartLaunchTime)。")  }  main函數(shù)之后的優(yōu)化：

   1.盡量使用純代碼編寫，減少xib的使用；

   2.啟動(dòng)階段的網(wǎng)絡(luò)請求，是否都放到異步請求；

    3.一些耗時(shí)的操作是否可以放到后面去執(zhí)行，或異步執(zhí)行等。

    4. FPS 通過維基百科我們知道，F(xiàn)PS是Frames Per Second 的簡稱縮寫，意思是每秒傳輸幀數(shù)，也就是我們常說的“刷新率（單位為Hz）。 FPS是測量用于保存、顯示動(dòng)態(tài)視頻的信息數(shù)量。每秒鐘幀數(shù)愈多，所顯示的畫面就會愈流暢，F(xiàn)PS值越低就越卡頓，所以這個(gè)值在一定程度上可以衡量應(yīng)用在圖像繪制渲染處理時(shí)的性能。一般我們的APP的FPS只要保持在 50-60之間，用戶體驗(yàn)都是比較流暢的。 蘋果手機(jī)屏幕的正常刷新頻率是每秒60次，即可以理解為FPS值為60。我們都知道CADisplayLink是和屏幕刷新頻率保存一致，所以我們是否可以通過它來監(jiān)控我們的FPS呢？！ 首先CADisplayLink是什么 CADisplayLink是CoreAnimation提供的另一個(gè)類似于NSTimer的類，它總是在屏幕完成一次更新之前啟動(dòng)，它的接口設(shè)計(jì)的和NSTimer很類似，所以它實(shí)際上就是一個(gè)內(nèi)置實(shí)現(xiàn)的替代，但是和timeInterval以秒為單位不同，CADisplayLink有一個(gè)整型的frameInterval屬性，指定了間隔多少幀之后才執(zhí)行。默認(rèn)值是1，意味著每次屏幕更新之前都會執(zhí)行一次。但是如果動(dòng)畫的代碼執(zhí)行起來超過了六十分之一秒，你可以指定frameInterval為2，就是說動(dòng)畫每隔一幀執(zhí)行一次（一秒鐘30幀）。 使用CADisplayLink監(jiān)控界面的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的實(shí)現(xiàn)方式，并真機(jī)測試之后，確實(shí)是可以在很大程度上滿足了監(jiān)控FPS的業(yè)務(wù)需求和為提高用戶體驗(yàn)提供參考，但是和Instruments的值可能會有些出入。

   下面我們來討論下使用CADisplayLink的方式，可能存在的問題。

    (1). 和Instruments值對比有出入，原因如下: CADisplayLink運(yùn)行在被添加的那個(gè)RunLoop之中（一般是在主線程中），因此它只能檢測出當(dāng)前RunLoop下的幀率。RunLoop中所管理的任務(wù)的調(diào)度時(shí)機(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)引用，此時(shí) timer持有 self，self 也持有 timer，循環(huán)引用導(dǎo)致頁面 dismiss 時(shí)，雙方都無法釋放，造成循環(huán)引用。此時(shí)使用 weak 也不能有效解決: weakvar weakSelf=self let link=CADisplayLink.init(target: weakSelf, selector: #selector(tick)) 那么我們應(yīng)該怎樣解決這個(gè)問題，有人會說在deinit(或dealloc)中調(diào)用定時(shí)器的invalidate方法，但是這是無效的，因?yàn)橐呀?jīng)造成循環(huán)引用了，不會走到這個(gè)方法的。 YYKit作者提供的解決方案是使用 YYWeakProxy，這個(gè)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是一個(gè)為對象定義接口的抽象父類，并且為其它對象或者一些不存在的對象扮演了替身角色。 修改后代碼如下，親測定時(shí)器如愿釋放，LSLWeakProxy的具體實(shí)現(xiàn)代碼已經(jīng)同步到github中。 let link=CADisplayLink.init(target: LSLWeakProxy(target: self), selector: #selector(tick))

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

   6.屏幕繪制原理 現(xiàn)在的手機(jī)設(shè)備基本都是采用雙緩存+垂直同步（即V-Sync）屏幕顯示技術(shù)。 如上圖所示，系統(tǒng)內(nèi)CPU、GPU和顯示器是協(xié)同完成顯示工作的。其中CPU負(fù)責(zé)計(jì)算顯示的內(nèi)容，例如視圖創(chuàng)建、布局計(jì)算、圖片解碼、文本繪制等等。隨后CPU將計(jì)算好的內(nèi)容提交給GPU，由GPU進(jìn)行變換、合成、渲染。GPU會預(yù)先渲染好一幀放入一個(gè)緩沖區(qū)內(nèi)，讓視頻控制器讀取，當(dāng)下一幀渲染好后，GPU會直接將視頻控制器的指針指向第二個(gè)容器（雙緩存原理）。這里，GPU會等待顯示器的VSync（即垂直同步）信號發(fā)出后，才進(jìn)行新的一幀渲染和緩沖區(qū)更新（這樣能解決畫面撕裂現(xiàn)象，也增加了畫面流暢度，但需要消費(fèi)更多的計(jì)算資源，也會帶來部分延遲）。 卡頓的原因：

    7.掉幀 由上面屏幕顯示的原理，采用了垂直同步機(jī)制的手機(jī)設(shè)備。如果在一個(gè)VSync 時(shí)間內(nèi)，CPU 或GPU 沒有完成內(nèi)容提交，則那一幀就會被丟棄，等待下一次機(jī)會再顯示，而這時(shí)顯示屏?xí)Ａ糁暗膬?nèi)容不變。例如在主線程里添加了阻礙主線程去響應(yīng)點(diǎn)擊、滑動(dòng)事件、以及阻礙主線程的UI繪制等的代碼，都是造成卡頓的常見原因。 卡頓監(jiān)控： 卡頓監(jiān)控一般有兩種實(shí)現(xiàn)方案： (1). 主線程卡頓監(jiān)控。通過子線程監(jiān)測主線程的runLoop，判斷兩個(gè)狀態(tài)區(qū)域之間的耗時(shí)是否達(dá)到一定閾值。 (2). FPS監(jiān)控。要保持流暢的UI交互，App 刷新率應(yīng)該當(dāng)努力保持在 60fps。FPS的監(jiān)控實(shí)現(xiàn)原理，上面已經(jīng)探討過這里略過。 在使用FPS監(jiān)控性能的實(shí)踐過程中，發(fā)現(xiàn) FPS 值抖動(dòng)較大，造成偵測卡頓比較困難。為了解決這個(gè)問題，通過采用檢測主線程每次執(zhí)行消息循環(huán)的時(shí)間，當(dāng)這一時(shí)間大于規(guī)定的閾值時(shí)，就記為發(fā)生了一次卡頓的方式來監(jiān)控。 這也是美團(tuán)的移動(dòng)端采用的性能監(jiān)控Hertz 方案，微信團(tuán)隊(duì)也在實(shí)踐過程中提出來類似的方案--微信讀書 iOS 性能優(yōu)化總結(jié)。  美團(tuán)Hertz方案流程圖 方案的提出，是根據(jù)滾動(dòng)引發(fā)的Sources事件或其它交互事件總是被快速的執(zhí)行完成，然后進(jìn)入到kCFRunLoopBeforeWaiting狀態(tài)下；假如在滾動(dòng)過程中發(fā)生了卡頓現(xiàn)象，那么RunLoop必然會保持kCFRunLoopAfterWaiting或者kCFRunLoopBeforeSources這兩個(gè)狀態(tài)之一。 所以監(jiān)控主線程卡頓的方案一： 開辟一個(gè)子線程，然后實(shí)時(shí)計(jì)算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 兩個(gè)狀態(tài)區(qū)域之間的耗時(shí)是否超過某個(gè)閥值，來斷定主線程的卡頓情況。 但是由于主線程的RunLoop在閑置時(shí)基本處于Before Waiting狀態(tài)，這就導(dǎo)致了即便沒有發(fā)生任何卡頓，這種檢測方式也總能認(rèn)定主線程處在卡頓狀態(tài)。 為了解決這個(gè)問題寒神(南梔傾寒)給出了自己的解決方案，Swift的卡頓檢測第三方ANREye。這套卡頓監(jiān)控方案大致思路為：創(chuàng)建一個(gè)子線程進(jìn)行循環(huán)檢測，每次檢測時(shí)設(shè)置標(biāo)記位為YES，然后派發(fā)任務(wù)到主線程中將標(biāo)記位設(shè)置為NO。接著子線程沉睡超時(shí)闕值時(shí)長，判斷標(biāo)志位是否成功設(shè)置成NO，如果沒有說明主線程發(fā)生了卡頓。 結(jié)合這套方案，當(dāng)主線程處在Before Waiting狀態(tài)的時(shí)候，通過派發(fā)任務(wù)到主線程來設(shè)置標(biāo)記位的方式處理常態(tài)下的卡頓檢測： #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]; // 打印主線程調(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-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 方案二是結(jié)合CADisplayLink的方式實(shí)現(xiàn) 在檢測FPS值的時(shí)候，我們就詳細(xì)介紹了CADisplayLink的使用方式，在這里也可以通過FPS值是否連續(xù)低于某個(gè)值開進(jìn)行監(jiān)控。