apppark.cn" target="_blank">app開發中關於app性能的檢測方式有哪些？
1 . CPU 占（zhàn）用率 CPU作為手機的中央處理器，可以說是手機關鍵的組（zǔ）成部分，所有（yǒu）應用程（chéng）序都需要它來調度運行，資源有限。所以當（dāng）我們（men）的APP因設計不當，使 CPU 持續以高（gāo）負載運行，將（jiāng）會出現APP卡頓、手機（jī）發熱發燙、電量（liàng）消耗過快等等嚴重（chóng）影響用戶（hù）體驗的現象。 因此我們對應用在CPU中占用率的監控，將變（biàn）得尤（yóu）為重要。那麽（me）我（wǒ）們應該如何來獲取CPU的占有率呢？！ 我們都（dōu）知道，我們的APP在運（yùn）行的時候（hòu），會對應一個Mach Task，而Task下可能有多條線程同時執行任務，每個線程都是作為利用（yòng）CPU的基本單（dān）位。所以我們可以通過獲取當前Mach Task下，所有線程占用 CPU 的情況，來計算APP的（de） CPU 占用率。
在《OS X and ioses Kernel Programming》是這樣描述 Mach task 的： 任務（task）是（shì）一種容器（container）對象，虛擬內存空間和其他資源都是通過這個容器對象管理的，這（zhè）些資源（yuán）包括設備和其他句柄。嚴格地說，Mach 的任（rèn）務並不是其他操作係統（tǒng）中所謂的進程，因為 Mach 作為一個微內核的操作係統，並沒有提供“進程”的邏輯（jí），而隻是提供了基本的（de）實現。不（bú）過在 BSD 的（de）模型（xíng）中（zhōng），這兩個概念有1：1的（de）簡（jiǎn）單映射，每一（yī）個（gè） BSD 進程（也就是 OS X 進程（chéng））都在底層（céng）關聯了一個 Mach 任務對象。
Mac OS X 中進程子係統組成的概念圖 ioses 是基於 Apple Darwin 內核，由kernel、XNU和Runtime 組成，而XNU是Darwin 的內核（hé），它是“X is not UNIX”的縮寫（xiě），是一（yī）個混合內核，由（yóu） Mach 微內核和 BSD 組成。Mach 內核是輕量級（jí）的平台，隻（zhī）能完成操作係統基本的職責，比如：進程和線程（chéng）、虛擬內存管理、任務調度、進程通信和消息傳遞（dì）機製等。其他的工作，例如文件操作和設備訪問，都由 BSD 層實現。 ioses 的線程技術與（yǔ）Mac OS X類似，也是基於 Mach 線程技術實現的，在 Mach 層中thread_basic_info 結構（gòu）體（tǐ）封裝（zhuāng）了單個線程的基（jī）本信息（xī）： 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包含它的（de）線程列表。內核提供了task_threads API 調用（yòng）獲（huò）取指（zhǐ）定 task 的（de）線程列表（biǎo），然後可以通過thread_info API調用來查詢指定線程的信（xìn）息，在 thread_act.h 中有（yǒu）相關（guān）定義。 task_threads 將（jiāng）target_task 任（rèn）務中的所有線程保存在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, // 查詢到的線程（chéng）信息 mach_msg_type_number_t*thread_info_outCnt // 信息的（de）大小 ); 所以我們如下來（lái）獲取CPU的占有率： #import "LSLCpuUsage.h" #import
#import #import #import #import @implementation LSLCpuUsage + ( double)getCpuUsage { kern_return_tkr; thread_array_tthreadList; // 保存當前（qián）Mach task的線程列表 mach_msg_type_number_tthreadCount; // 保存當前Mach task的（de）線程個數 thread_info_data_tthreadInfo; // 保存單個線程的信息列表 mach_msg_type_number_tthreadInfoCount; // 保存（cún）當前（qián）線程的信息列表大小 thread_basic_info_tthreadBasicInfo; // 線程的基本信息 // 通過“task_threads”API調用獲取（qǔ）指定 task 的線程（chéng）列（liè）表 // 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; // 通（tōng）過“thread_info”API調用來查詢指定線程的信息（xī） // flavor參數（shù）傳的是（shì）THREAD_BASIC_INFO，使用這個類型會返回（huí）線（xiàn）程（chéng）的基本信息， // 定義在 thread_basic_info_t 結構體，包含了用戶（hù）和係統的運行時間、運行狀態和調度優先（xiān）級等 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. 內（nèi）存 雖然現在的手機內（nèi）存越來越大，但畢竟是（shì）有限的，如果因（yīn）為我（wǒ）們的應用設計不當造成內存（cún）過高，可能麵臨被係（xì）統“幹掉”的風險，這對用戶來說是毀滅性的體驗。 Mach task 的內存（cún）使用信息存放在mach_task_basic_info結構體中 ，其中（zhōng）resident_size 為應用（yòng）使用的物理內存大小，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; }; 獲取方式是（shì）通過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 ); 筆者嚐試過使用（yòng）如下（xià）方式獲取內存情況，基本和騰訊的GT的相近，但是（shì）和Xcode和（hé） Instruments的值有（yǒu）較大差距： // 獲取當前應用的內存占用情況，和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才是（shì）正解（jiě），博（bó）客地址。親測，基本和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 源碼中（zhōng），找到 osfmk/kern/task.c 裏（lǐ）對於 phys_footprint 的注釋（shì），博主認為注釋裏提到（dào）的公式計算的應該才是應用實際使用的物（wù）理內存。 當然我也是讚同這點的>.<。
3. 啟動時間（jiān） APP的啟動時間，直接影（yǐng）響用戶對你（nǐ）的APP的為（wéi）數不多體驗和判斷。如果啟動時間（jiān）過長（zhǎng），不單單（dān）體驗直線下（xià）降，而且可能會激發蘋果的watch dog機製kill掉（diào）你的APP，那就悲劇了（le），用戶會覺得APP怎（zěn）麽一啟動就卡死然後崩潰了，不能用，然（rán）後長（zhǎng）按APP點擊刪除鍵（jiàn）。（Xcode在debug模式下是沒有開啟watch dog的，所以我（wǒ）們一定要連（lián）接真機測試我們的APP） 在衡量（liàng）APP的啟動時間之前我們先了解下，APP的啟動流程： APP啟動過程 APP的啟（qǐ）動可以分為兩個階段，即main()執行之前和main()執行之後。總（zǒng）結如下 t(App 總啟動時間)=t1( main()之前的加載時間 ) + t2( main()之後的（de）加載時間（jiān） )。 t1=係統（tǒng）的 dylib (動態鏈接庫)和 App 可執行（háng）文件的加（jiā）載時間； t2=main()函數執行之後到AppDelegate類中的applicationDidFinishLaunching:withOptions:方法執行結束前這段時間。 所以我們（men）對APP啟動時間（jiān）的獲取和優化（huà）都是（shì）從這兩個階段著手，下麵先（xiān）看（kàn）看main()函（hán）數執行之前如何獲取啟動時間。 衡量main()函數執行（háng）之前的耗時 對於衡量main()之（zhī）前也就是time1的耗時（shí），蘋果官方提供了一種方法，即在真（zhēn）機調試的時候，勾選DYLD_PRINT_STATISTICS選項（如果想獲取更詳細的信（xìn）息可以使用DYLD_PRINT_STATISTICS_DETAILS），如下圖： main()函數之（zhī）前（qián） 輸出結果如下： 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%) 係統級別的動態鏈接庫，因為蘋果做了（le）優化，所以耗時並不多，而大多數時候，t1的時間大部分會消耗在我們自身App中的（de）代碼上和鏈接第三方庫上。 所（suǒ）以我們應如何減少main()調用之前的耗時呢，我們可以優化的點有： 減少不必要的framework，特（tè）別是第三方的，因為動態鏈（liàn）接比較耗時； check framework應設為optional和required，如果該framework在當前App支持（chí）的所有ioses係統版本都存（cún）在，那麽就設為required，否則就設為optional，因為optional會有些（xiē）額外的檢查； 合並或者刪減一些OC類，關於清理項目中沒用到的類（lèi），可以借助AppCode代碼檢查工具（jù）： 刪減一些無用的靜態變量 刪減沒有被調用到（dào）或者已經廢棄的方法（fǎ） 將不必須在+load方法中（zhōng）做的事情延遲到+initialize中 盡量不要用C++虛函數(創建虛函數（shù）表有開銷) 衡量main()函數執行之後的耗時 第二階段的耗時統計，我們認為是從main ()執行之後到applicationDidFinishLaunching:withOptions:方法較後，那麽我們可以通過（guò）打點的（de）方式進行統（tǒng）計。 Objective-C項目因為（wéi）有main文件，所以我麽直接可以通過添加代碼獲取： // 1. 在 main.m 添加如下代碼: CFAbsoluteTimeAppStartLaunchTime; intmain( intargc, char* argv[]) { AppStartLaunchTime=CFAbsoluteTimeGetCurrent(); ..... } // 2. 在（zài） 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 ioses app, and eliminates the need for a “main.swift” file. 也就是說，通過添加@UIApplicationMain標誌的方式，幫我們添加了（le）mian函數了。所以（yǐ）如（rú）果是我們需要在mian函數中做一些其它（tā）操作的話，需（xū）要我們自己來創（chuàng）建main.swift文件，這個也是蘋果允許的。 刪除AppDelegate類中的（de） @UIApplicationMain標誌； 自（zì）行（háng）創建main.swift文件，並添加程序入口（kǒu） 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的（de）didFinishLaunchingWithOptions :方法較後添加： // APP啟動時間耗時，從mian函數開始到didFinishLaunchingWithOptions方法結束 DispatchQueue.main. async{ print( "APP啟動時間耗時，從mian函（hán）數開始到didFinishLaunchingWithOptions方法：(CFAbsoluteTimeGetCurrent() - appStartLaunchTime)。") } main函數之（zhī）後的優化：
1.盡量使（shǐ）用（yòng）純代碼編寫，減少xib的使用；
2.啟動階段的網絡請求，是否都放（fàng）到異步請求；
3.一些耗時的操作是否可以放到後麵去執行，或異步執行等。
4. FPS 通過維（wéi）基百科我（wǒ）們（men）知道，FPS是Frames Per Second 的簡稱縮寫，意思是每秒傳輸幀數，也就是我們常說的“刷新率（單位為Hz）。 FPS是測量用於保存、顯示動態視頻的（de）信息數量。每秒鍾幀數愈多，所顯示（shì）的畫麵就會愈流暢，FPS值越低就越（yuè）卡（kǎ）頓，所以這個值在一（yī）定程度上可以衡（héng）量應用在圖（tú）像繪製渲染處理時的性能。一般我們（men）的（de）APP的FPS隻要保持在 50-60之間，用戶體驗都是比較流暢的。 蘋（píng）果手機屏（píng）幕的正常（cháng）刷新頻率是每秒60次，即可以理解為FPS值（zhí）為60。我們都知道CADisplayLink是和屏幕刷新頻率保存一（yī）致，所以（yǐ）我們是否可以通過它來監控我（wǒ）們的FPS呢？！ 首先CADisplayLink是什麽 CADisplayLink是CoreAnimation提（tí）供的另一個類似於NSTimer的類，它總是在屏幕完成一（yī）次更新之前啟動，它的接口設計的和NSTimer很類似，所以它實際上就是一（yī）個內置實現的替代，但是和timeInterval以秒為單位不同，CADisplayLink有一個整（zhěng）型的frameInterval屬性，指定了間隔（gé）多少幀之後才執（zhí）行。默認值是1，意味著每次屏幕更新之前都會執（zhí）行一次。但是（shì）如（rú）果（guǒ）動畫（huà）的代（dài）碼執行起來超過了六十分之（zhī）一秒，你可以指定（dìng）frameInterval為2，就是說動畫每隔一幀執行一次（一秒鍾30幀）。 使用CADisplayLink監控界麵的FPS值（zhí），參考自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í）是可以在很大程度（dù）上（shàng）滿足了監控（kòng）FPS的業務需（xū）求和為提高用戶體驗提供參考，但是和Instruments的值可能會（huì）有些出入。
下麵我們來討（tǎo）論下使用CADisplayLink的方式，可能（néng）存在的問題。
(1). 和Instruments值對比有出入，原因（yīn）如下: CADisplayLink運（yùn）行在被（bèi）添加的那個RunLoop之中（一般是在主線程中），因此它隻能檢測出當前RunLoop下的（de）幀率。RunLoop中（zhōng）所管理的任務的調度時機（jī），受任（rèn）務所處的RunLoopMode和（hé）CPU的繁忙程（chéng）度所影響。所以想要真正定（dìng）位到準確的性能問（wèn）題所在，較好還是通過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 也（yě）持有（yǒu） timer，循環引用導致頁麵 dismiss 時，雙方都無法釋放，造成循環引用。此時使用 weak 也不（bú）能有效解決: weakvar weakSelf=self let link=CADisplayLink.init(target: weakSelf, selector: #selector(tick)) 那麽我們（men）應該怎樣解決這個問題，有人會說在（zài）deinit(或dealloc)中調用定時器的（de）invalidate方法，但是這是無效的，因為已（yǐ）經造成循環引用了，不會走到這個方法的。 YYKit作者提（tí）供的解決方案是使用 YYWeakProxy，這個YYWeakProxy不（bú）是繼承自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是一（yī）個為對（duì）象定義接口的抽象（xiàng）父類（lèi），並且為其它對象或者一些不存在的對象扮演了替身（shēn）角色。 修改後代碼如下，親（qīn）測定時（shí）器（qì）如願釋（shì）放，LSLWeakProxy的具體實現代碼已經同步到github中。 let link=CADisplayLink.init(target: LSLWeakProxy(target: self), selector: #selector(tick))
5. 卡頓 在了解卡頓產生的原因（yīn）之前，先看（kàn）下屏幕顯示圖像的（de）原理。 屏幕顯示圖像的原理：
6.屏幕繪製原理 現在的手機設備基本都是采用雙緩存+垂直同步（即V-Sync）屏幕顯示（shì）技術。 如（rú）上圖所示，係統內CPU、GPU和顯示器是協同完成顯示工作的。其中（zhōng）CPU負責計算（suàn）顯示的內容（róng），例如視圖創建、布局計算、圖片解碼、文本繪製等（děng）等。隨後CPU將計算好的內容提交給GPU，由GPU進行變換、合成、渲染。GPU會預先（xiān）渲染好一幀放入一個緩衝區內，讓視頻控製器讀取，當下一幀渲染好後，GPU會直接將視頻控製器的指針指向第二個容器（雙緩存原理）。這裏，GPU會等待顯示器的VSync（即垂直同步）信（xìn）號發出後，才進行新的一幀（zhēn）渲染和緩衝區更新（這樣能解決畫麵（miàn）撕裂現象，也增加了（le）畫麵流（liú）暢度，但需要消費更多的計算資源（yuán），也會帶（dài）來部分延遲）。 卡（kǎ）頓的原因：
7.掉幀 由上麵屏幕（mù）顯示的原理，采用了垂（chuí）直同步機製的手機設備。如果在（zài）一個VSync 時間內，CPU 或GPU 沒有完（wán）成內容提交，則那一（yī）幀（zhēn）就會被丟棄，等待下一次（cì）機會再顯示，而這時顯示屏會保留之前的內容不變。例如在主線程裏添加了阻（zǔ）礙主線（xiàn）程去響（xiǎng）應點擊（jī）、滑動事件、以及阻礙主線程（chéng）的UI繪製（zhì）等的代碼，都是造成卡頓的常見原因。 卡頓監控： 卡頓（dùn）監控一般有兩種實現方案： (1). 主（zhǔ）線程卡頓監控。通過子線程（chéng）監測主（zhǔ）線程的runLoop，判斷兩個狀態區域之間的（de）耗時是否達（dá）到一定閾值。 (2). FPS監控。要保持流暢（chàng）的UI交互，App 刷（shuā）新率應（yīng）該當努力保持在 60fps。FPS的監控實現原理，上麵已經探討過這（zhè）裏略過（guò）。 在使（shǐ）用（yòng）FPS監控性能的實踐過程中，發現 FPS 值（zhí）抖動較大（dà），造成偵測卡頓比較（jiào）困難。為了解決這個問題（tí），通過采用檢測主線程每次執行消息循（xún）環（huán）的時間，當這一時間（jiān）大（dà）於規定的閾值時，就記為發生了一次（cì）卡（kǎ）頓的方式來監控。 這也是美團（tuán）的移動（dòng）端采用的性能監控Hertz 方案，微信團隊也在實踐過程中提出來（lái）類（lèi）似的方案--微信讀書 ioses 性能（néng）優化總結。 美團Hertz方案流程（chéng）圖 方案的提出，是根據滾動引發的Sources事件或其它交互事（shì）件總是被快速的執行完成，然後進入到kCFRunLoopBeforeWaiting狀態下；假如在滾動過程中發生了卡頓（dùn）現象，那（nà）麽RunLoop必然會保持kCFRunLoopAfterWaiting或者（zhě）kCFRunLoopBeforeSources這兩（liǎng）個狀態之（zhī）一。 所以（yǐ）監控主（zhǔ）線程卡（kǎ）頓的方案一： 開辟一個子線程，然後實時計算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 兩個狀態區域之間的（de）耗時是否超過某個閥值，來斷定主線程的卡頓情（qíng）況。 但是由（yóu）於主線程的RunLoop在閑置時基本處於（yú）Before Waiting狀態，這就導致了即便沒有發生任何卡（kǎ）頓，這種檢測方式也總能認定主線程處在卡頓狀態。 為（wéi）了解決這個問題寒神(南梔傾寒（hán）)給出了自己（jǐ）的解決方案，Swift的卡頓檢測第三方ANREye。這套（tào）卡頓監控方案大致（zhì）思路為：創建一個子線程進行循環檢測，每次檢測（cè）時設置標記位為YES，然後派發任務到主線程中將標（biāo）記位設置為NO。接著子線程沉睡超時闕值時長，判斷標誌位是否成（chéng）功設置成NO，如果沒有說明（míng）主線程（chéng）發生了（le）卡頓。 結合這（zhè）套方案，當主線程處在Before Waiting狀態的（de）時候，通過（guò）派發任務到主線程來設置標記（jì）位的方式處（chù）理常（cháng）態下的卡頓檢測： #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]; // 打印主（zhǔ）線程（chéng）調用棧 // [LSLBacktraceLogger lsl_logCurrent]; // 打印當前線程的調用棧（zhàn） // [LSLBacktraceLogger lsl_logAllThread]; // 打印所有線程的調用棧 } dispatch_wait(lsl_semaphore, DISPATCH_TIME_FOREVER); } }); } - ( void)stopMonitoring { if(!lsl_is_monitoring) { return; } lsl_is_monitoring=NO; } @end 其中LSLBacktraceLogger是獲取堆棧信息的類，詳（xiáng）情見代碼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的方（fāng）式實現 在檢測FPS值的時候，我們就詳細介紹了CADisplayLink的使用方式，在這裏也可以通過FPS值是否連（lián）續低於某個值開進行監控。
0755-27805158
粵公網安備 44030602002171號
