網上已經有不少相關 Instruments
的介紹,今天從另外的角度再罩一個輪子。主要內容來自 WWDC&Using Time Profiler in Instruments,接下來僅簡單的介紹一下開發中忽略的點(即便是你看過了 WWDC, 可能也會忽略的)。
先看這張圖:
git
Time Profiler
的功能原理:
Time Profiler
會檢測當前的調用棧,而後以調用棧的形式記錄於詳細視圖中(如上圖的底部顯示)。
初略
作核心的解釋)的統計。
說到這裏、再來看另外一張圖:
github
Time Profiler
原本就是用來檢測一個函數/方法的執行效率(時間)的。這一句怎麼理解????
Time Profiler
僅僅是一個
初略 的統計。在 WWDC 視頻中也有提到,並不是是簡單的:結束時間減去開始時間,其中也有一些優化(具體什麼樣的優化,沒有發現)。
// touch
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
// 調用開始
os_log_t osObj = os_log_create("hg-cubsystem", "hg-category");
os_signpost_interval_begin(osObj, 6666, "hg-name");
// 調用測試代碼
[self testSleep];
// 調用結束
os_signpost_interval_end(osObj, 6666, "hg-name");
}
// 測試代碼
- (void)testSleep {
for (NSInteger j=0; j<5; j++) {
for (NSInteger i=0; i<10000; i++) {
NSLog(@"%zd", i);
}
}
}
複製代碼
想經過 Time Profiler
來檢測一下 testSleep 方法的執行效率(時間),最終的結果以下:
api
Instruments
是看不出來的,我主要是依賴
標註 2 的信息,
標註 2
是我使用
os_signpost_interval_begin
與
os_signpost_interval_end
在項目代碼中埋的點,從上面的代碼能夠看到。關於這兩個
api,主要是經過
Instruments
的
os_signpost
進行查看的。是蘋果 在 2018 年
Xcode
提供的
自定義 Instruments 的核心 api。之後有時間會介紹
Xcode 自定義 Instruments 相關的技術實現。
Timer Profiler
來檢測項目中卡頓等一系列的問題仍是頗有幫助的。雖然是不許確的效率(時間)統計,可是在必定程度上能體現出那些執行相對較高的函數/方法。
Time Profiler
是不許確的?
Time Profiler
來作自動化性能分析的,初步設想是經過
TraceUtility 這個工具來進行
Instruments.trace
文件解析、找出感興趣的函數/方法的執行時間。後來通過一段時間的研究以及在 WWDC 上的學習,發現這個方案是不可行的。其次也是由於近期本身在研究
Xcode 自定義 Instruments 相關的學習。
最後提醒: 雖然 Time Profiler
並不是百分百準確,可是其用途是毋庸置疑的,別被當前文檔產生誤解。bash