App性能分析数据监控
App性能分析數據監(jiān)控
APP的性能監(jiān)控包括： CPU 占用率、內存使用情況、網絡狀況監(jiān)控、啟動時閃退、卡頓、FPS、使用時崩潰、耗電量監(jiān)控、流量監(jiān)控等等。
文中所有代碼都已同步到github中，有興趣的可以clone 下來一起探討下。
環(huán)境
Xcode 10.0+
Swift 4.2
1 . CPU 占用率
CPU作為手機的中央處理器，可以說是手機最關鍵的組成部分，所有應用程序都需要它來調度運行，資源有限。所以當APP因設計不當，使 CPU 持續(xù)以高負載運行，將會出現APP卡頓、手機發(fā)熱發(fā)燙、電量消耗過快等等嚴重影響用戶體驗的現象。
因此對應用在CPU 中占用率的監(jiān)控，將變得尤為重要。那么應該如何來獲取CPU的占有率呢？！
都知道，APP在運行的時候，會對應一個Mach Task，而Task下可能有多條線程同時執(zhí)行任務，每個線程都是作為利用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 任務對象。
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 結構體，包含了用戶和系統的運行時間、運行狀態(tài)和調度優(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;}}
// 回收內存，防止內存泄漏
vm_deallocate(mach_task_self(), (vm_offset_t)threadList, threadCount * sizeof(thread_t));return cpuUsage / (double)TH_USAGE_SCALE * 100.0;
}
@end
- 內存
雖然現在的手機內存越來越大，但畢竟是有限的，如果因為應用設計不當造成內存過高，可能面臨被系統“干掉”的風險，這對用戶來說是毀滅性的體驗。
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_info API 根據指定的 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 才是正解，https://www.jianshu.com/u/b534ce5f8fae。測試后，基本和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.
*/
當然我也是贊同這點的>.<。
- 啟動時間
APP的啟動時間，直接影響用戶對你的APP的第一體驗和判斷。如果啟動時間過長，不單單體驗直線下降，而且可能會激發(fā)蘋果的watch dog機制kill掉你的APP，那就悲劇了，用戶會覺得APP怎么一啟動就卡死然后崩潰了，不能用，然后長按APP點擊刪除鍵。（Xcode在debug模式下是沒有開啟watch dog的，所以一定要連接真機測試APP）
在衡量APP的啟動時間之前先了解下，APP的啟動流程：
APP的啟動可以分為兩個階段，即main()執(zhí)行之前和main()執(zhí)行之后。總結如下：
t(App 總啟動時間) = t1( main()之前的加載時間 ) + t2( main()之后的加載時間 )。
? t1 = 系統的 dylib (動態(tài)鏈接庫)和 App 可執(zhí)行文件的加載時間；
? t2 = main()函數執(zhí)行之后到AppDelegate 類中的applicationDidFinishLaunching:withOptions:方法執(zhí)行結束前這段時間。
所以對APP啟動時間的獲取和優(yōu)化都是從這兩個階段著手，下面先看看main()函數執(zhí)行之前如何獲取啟動時間。
衡量main()函數執(zhí)行之前的耗時
對于衡量main()之前也就是time1的耗時，蘋果官方提供了一種方法，即在真機調試的時候，勾選DYLD_PRINT_STATISTICS 選項（如果想獲取更詳細的信息可以使用DYLD_PRINT_STATISTICS_DETAILS ），如下圖：
輸出結果如下：
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%)
系統級別的動態(tài)鏈接庫，因為蘋果做了優(yōu)化，所以耗時并不多，而大多數時候，t1的時間大部分會消耗在自身App中的代碼上和鏈接第三方庫上。
所以應如何減少main()調用之前的耗時呢，可以優(yōu)化的點有：
- 減少不必要的framework ，特別是第三方的，因為動態(tài)鏈接比較耗時；
- check framework 應設為optional 和required ，如果該framework 在當前App支持的所有iOS系統版本都存在，那么就設為required ，否則就設為optional ，因為optional 會有些額外的檢查；
- 合并或者刪減一些OC類，關于清理項目中沒用到的類，可以借助AppCode代碼檢查工具：
? 刪減一些無用的靜態(tài)變量
? 刪減沒有被調用到或者已經廢棄的方法
? 將不必須在+load方法中做的事情延遲到+initialize中
? 盡量不要用C++虛函數(創(chuàng)建虛函數表有開銷)
衡量main()函數執(zhí)行之后的耗時
第二階段的耗時統計，認為是從main ()執(zhí)行之后到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文件，官方給了如下解釋:
In Xcode, Mac templates default to including a “main.swift” file, but for iOS apps the default for new iOS project templates is to add @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函數中做一些其它操作的話，需要自己來創(chuàng)建main.swift文件，這個也是蘋果允許的。
i. 刪除AppDelegate類中的 @UIApplicationMain標志；
ii. 自行創(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)
)
iii. 在AppDelegate的didFinishLaunchingWithOptions :方法最后添加：
// APP啟動時間耗時，從mian函數開始到didFinishLaunchingWithOptions方法結束
DispatchQueue.main.async {
print(“APP啟動時間耗時，從mian函數開始到didFinishLaunchingWithOptions方法：(CFAbsoluteTimeGetCurrent() - appStartLaunchTime)。”)
}
main函數之后的優(yōu)化：
? 盡量使用純代碼編寫，減少xib的使用；
? 啟動階段的網絡請求，是否都放到異步請求；
? 一些耗時的操作是否可以放到后面去執(zhí)行，或異步執(zhí)行等。
4. FPS
通過維基百科知道，FPS 是Frames Per Second 的簡稱縮寫，意思是每秒傳輸幀數，也就是常說的“刷新率（單位為Hz）。
FPS 是測量用于保存、顯示動態(tài)視頻的信息數量。每秒鐘幀數愈多，所顯示的畫面就會愈流暢，FPS 值越低就越卡頓，所以這個值在一定程度上可以衡量應用在圖像繪制渲染處理時的性能。一般APP的FPS 只要保持在 50-60之間，用戶體驗都是比較流暢的。
蘋果手機屏幕的正常刷新頻率是每秒60次，即可以理解為FPS值為60。都知道CADisplayLink 是和屏幕刷新頻率保存一致，所以是否可以通過它來監(jiān)控FPS呢？！
首先CADisplayLink 是什么
CADisplayLink 是CoreAnimation 提供的另一個類似于NSTimer 的類，它總是在屏幕完成一次更新之前啟動，它的接口設計的和NSTimer 很類似，所以它實際上就是一個內置實現的替代，但是和timeInterval 以秒為單位不同，CADisplayLink 有一個整型的frameInterval 屬性，指定了間隔多少幀之后才執(zhí)行。默認值是1，意味著每次屏幕更新之前都會執(zhí)行一次。但是如果動畫的代碼執(zhí)行起來超過了六十分之一秒，你可以指定frameInterval 為2，就是說動畫每隔一幀執(zhí)行一次（一秒鐘30幀）。
使用CADisplayLink 監(jiān)控界面的FPS值，參考自YYFPSLabel：
// 詳情代碼可以clone demo查看
通過CADisplayLink 的實現方式，并真機測試之后，確實是可以在很大程度上滿足了監(jiān)控FPS的業(yè)務需求和為提高用戶體驗提供參考，但是和Instruments的值可能會有些出入。下面來討論下使用CADisplayLink 的方式，可能存在的問題。
? (1). 和Instruments值對比有出入，原因如下:
CADisplayLink 運行在被添加的那個RunLoop 之中（一般是在主線程中），因此它只能檢測出當前RunLoop 下的幀率。RunLoop 中所管理的任務的調度時機，受任務所處的RunLoopMode 和CPU的繁忙程度所影響。所以想要真正定位到準確的性能問題所在，最好還是通過Instrument來確認。
? (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 強引用，此時 timer持有 self，self 也持有 timer，循環(huán)引用導致頁面 dismiss 時，雙方都無法釋放，造成循環(huán)引用。此時使用 weak 也不能有效解決:
weak var weakSelf = self
let link = CADisplayLink.init(target: weakSelf, selector: #selector(tick))
那么應該怎樣解決這個問題，有人會說在deinit (或dealloc )中調用定時器的invalidate方法，但是這是無效的，因為已經造成循環(huán)引用了，不會走到這個方法的。
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 是一個為對象定義接口的抽象父類，并且為其它對象或者一些不存在的對象扮演了替身角色。具體的可以看下NSProxy的官方文檔 修改后代碼如下，親測定時器如愿釋放，LSLWeakProxy 的具體實現代碼已經同步到github中。
let link = CADisplayLink.init(target: LSLWeakProxy(target: self), selector: #selector(tick))
5. 卡頓
在了解卡頓產生的原因之前，先看下屏幕顯示圖像的原理。
屏幕顯示圖像的原理：
現在的手機設備基本都是采用雙緩存+垂直同步（即V-Sync）屏幕顯示技術。
如上圖所示，系統內CPU 、GPU 和顯示器是協同完成顯示工作的。其中CPU 負責計算顯示的內容，例如視圖創(chuàng)建、布局計算、圖片解碼、文本繪制等等。隨后CPU 將計算好的內容提交給GPU ，由GPU 進行變換、合成、渲染。GPU 會預先渲染好一幀放入一個緩沖區(qū)內，讓視頻控制器讀取，當下一幀渲染好后，GPU 會直接將視頻控制器的指針指向第二個容器（雙緩存原理）。這里，GPU 會等待顯示器的VSync （即垂直同步）信號發(fā)出后，才進行新的一幀渲染和緩沖區(qū)更新（這樣能解決畫面撕裂現象，也增加了畫面流暢度，但需要消費更多的計算資源，也會帶來部分延遲）。
卡頓的原因：
由上面屏幕顯示的原理，采用了垂直同步機制的手機設備。如果在一個VSync 時間內，CPU 或GPU 沒有完成內容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏會保留之前的內容不變。例如在主線程里添加了阻礙主線程去響應點擊、滑動事件、以及阻礙主線程的UI繪制等的代碼，都是造成卡頓的常見原因。
卡頓監(jiān)控：
卡頓監(jiān)控一般有兩種實現方案：
? (1). 主線程卡頓監(jiān)控。通過子線程監(jiān)測主線程的runLoop ，判斷兩個狀態(tài)區(qū)域之間的耗時是否達到一定閾值。
? (2). FPS監(jiān)控。要保持流暢的UI交互，App 刷新率應該當努力保持在 60fps。FPS的監(jiān)控實現原理，上面已經探討過這里略過。
在使用FPS 監(jiān)控性能的實踐過程中，發(fā)現 FPS 值抖動較大，造成偵測卡頓比較困難。為了解決這個問題，通過采用檢測主線程每次執(zhí)行消息循環(huán)的時間，當這一時間大于規(guī)定的閾值時，就記為發(fā)生了一次卡頓的方式來監(jiān)控。 這也是美團的移動端采用的性能監(jiān)控Hertz 方案，微信團隊也在實踐過程中提出來類似的方案–微信讀書 iOS 性能優(yōu)化總結。
方案的提出，是根據滾動引發(fā)的Sources事件或其它交互事件總是被快速的執(zhí)行完成，然后進入到kCFRunLoopBeforeWaiting狀態(tài)下；假如在滾動過程中發(fā)生了卡頓現象，那么RunLoop必然會保持kCFRunLoopAfterWaiting或者kCFRunLoopBeforeSources這兩個狀態(tài)之一。
所以監(jiān)控主線程卡頓的方案一：
開辟一個子線程，然后實時計算 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 兩個狀態(tài)區(qū)域之間的耗時是否超過某個閥值，來斷定主線程的卡頓情況。 但是由于主線程的RunLoop在閑置時基本處于Before Waiting狀態(tài)，這就導致了即便沒有發(fā)生任何卡頓，這種檢測方式也總能認定主線程處在卡頓狀態(tài)。
為了解決這個問題寒神(南梔傾寒)給出了自己的解決方案，Swift的卡頓檢測第三方ANREye。這套卡頓監(jiān)控方案大致思路為：創(chuàng)建一個子線程進行循環(huán)檢測，每次檢測時設置標記位為YES，然后派發(fā)任務到主線程中將標記位設置為NO。接著子線程沉睡超時闕值時長，判斷標志位是否成功設置成NO，如果沒有說明主線程發(fā)生了卡頓。
結合這套方案，當主線程處在Before Waiting狀態(tài)的時候，通過派發(fā)任務到主線程來設置標記位的方式處理常態(tài)下的卡頓檢測：
#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。
demo卡頓堆棧打印日志如下:
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值是否連續(xù)低于某個值開進行監(jiān)控。
參考鏈接：
https://github.com/SilongLi/AppPerformance
https://www.jianshu.com/p/95df83780c8f
總結
以上是生活随笔為你收集整理的App性能分析数据监控的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 日本半导体材料
- 下一篇： ONNX MLIR应用示例（含源码链接）