本文參考以下文章，做了一點優(yōu)化，提升了卡頓監(jiān)測的準(zhǔn)確性，性能，符號化速度等等。
iOS實時卡頓監(jiān)控，深入理解RunLoop，iOS版微信界面卡頓監(jiān)測方案，深入剖析 iOS 性能優(yōu)化，BSBacktraceLogger
UI卡頓檢測
通過監(jiān)測主runloop循環(huán)次數(shù)來判斷是否發(fā)送卡頓。
什么是runloop?
runloop就是線程里的一個循環(huán)，退出該循環(huán)的條件是程序結(jié)束，程序什么時候結(jié)束自己定，類似MFC中消息循環(huán)。
為什么要有runloop？
線程保活，事件分發(fā)，線程頻繁創(chuàng)建銷毀耗資源，不希望線程頻繁創(chuàng)建銷毀。
怎么監(jiān)控主runloop循環(huán)次數(shù)？
runloop循環(huán)的過程中會拋通知出來，在異步線程中創(chuàng)建一個runloop觀察者監(jiān)聽這些通知即可。
怎么檢測UI發(fā)生了卡頓？
監(jiān)控主runloop循環(huán)次數(shù)，流暢情況下，一般循環(huán)60次，對應(yīng)60幀。
假設(shè)認為掉了10幀，人眼能明顯感受到卡頓，10 * 16.67 ms 約 166 ms，那么runloop超過166ms沒回調(diào)通知給我的觀察者，判定為卡頓，并且要“非常非常及時”獲取下主線程的調(diào)用棧，棧頂?shù)姆椒ň褪前l(fā)生卡頓的方法。
看下圖：這是網(wǎng)友根據(jù)runloop源碼畫的流程圖
起一個線程用信號量卡著，每166ms執(zhí)行一次，用個變量last記錄最后一次runloop拋出來通知，如果發(fā)生166ms超時，去看 last 是什么值，如果是 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting，表示自己的代碼發(fā)生卡頓，因為這兩個通知后面處理的是 source0系統(tǒng)代碼，source1用戶代碼，timer代碼事件。發(fā)生了卡頓就在監(jiān)控線程將其調(diào)用棧獲取下來。
另外頁面切換速度，F(xiàn)PS幀率，都跟主循環(huán)正相關(guān)，因為viewDidLoad等等事件都在主線程執(zhí)行，UI也在主線程繪制。監(jiān)測了主runloop，這兩個指標(biāo)其實可以不用在監(jiān)測。
符號化
符號化就是給一個內(nèi)存地址 0x00001234 找到其符號 -[ViewController viewDidLoad] 的過程，因為mach-o文件中包含了LC_SYMTAB段，該段中包含符號表。
注意，iOS系統(tǒng)做了優(yōu)化，系統(tǒng)庫的符號不在內(nèi)存中，會提示 <redacted>
符號化參考BSBacktraceLogger所寫
改進的地方有：
1.預(yù)處理所有image，記錄下image中所需要的各個segment基址，image內(nèi)存地址范圍等等，避免每次用個for循環(huán)來查找segment基址，預(yù)處理后查找基址從 O(N) 降到 O(1)，注意點：image可以動態(tài)加載，動態(tài)刪除，好在iOS中不會刪除，只會在APP啟動時會逐漸加載，加完后image數(shù)量不會變化，如果image數(shù)量有變，那么得重新預(yù)處理一次。
2.查找一個內(nèi)存地址 address 在哪一個 image 內(nèi)，返回該 image 索引
由于有預(yù)處理image地址范圍，并對地址排了序，qsort()排序，并且image地址不重疊，那么這里查找一個image直接用二分查找，從原來的兩個for循環(huán)的O(n^2)降到了O(log n)，為什么不用哈希查找是因為地址空間太大，64位下有2^64個地址，大約 16777216T，太大了存不下。
3.加緩存，緩存 (address, symbol) 地址到symbol符號結(jié)構(gòu)體的二元組
使用自己實現(xiàn)的LRU緩存，比NSCache快4倍，文章地址：http://www.lxweimin.com/p/1f8e36285539
4.監(jiān)控線程只獲取調(diào)用棧，另起一個線程進行符號化，相當(dāng)于監(jiān)控線程是生產(chǎn)者，其他線程是消費者，一對一生產(chǎn)消費模型。
優(yōu)化結(jié)果：1000次符號化調(diào)用
7個棧：
優(yōu)化后：50ms，，，優(yōu)化前：1800ms
70個棧：
優(yōu)化后：800ms，，，優(yōu)化前：11800ms
那么除以1000就是一次符號化的時間，大約是 0.05ms 到 0.8ms 之間能獲取到全部調(diào)用棧，提高了準(zhǔn)確性。因為在50ms發(fā)生了卡頓，該卡頓可能在51ms消失，調(diào)用棧變化十分快，必須要在最短時間內(nèi)捕捉到調(diào)用棧，才能準(zhǔn)確，如果要在幾毫秒后才捕捉到，那可能就不是發(fā)生卡頓的調(diào)用棧了，導(dǎo)致結(jié)果不準(zhǔn)。
優(yōu)化后的代碼暫時未貼出，以后會考慮開源的。
線上UI卡頓監(jiān)控結(jié)果
UI卡頓監(jiān)控SDK終于上線了，灰度范圍5萬個用戶，線上 0 崩潰。
后臺已捕捉到幾千處方法卡頓和卡頓調(diào)用棧（卡頓定義：UI線程超過500ms沒響應(yīng)判定為卡頓）
卡頓主要原因是：有代碼在主線程同步請求網(wǎng)絡(luò)，主線程讀寫數(shù)據(jù)庫，寫文件，加鎖，做數(shù)據(jù)解析，數(shù)據(jù)計算等等。
修復(fù)完這些卡頓，APP流暢性將得到提升，用戶體驗提升。
監(jiān)控SDK本身的性能消耗：（iPhone 6s, iOS 9.2 測得）
SDK啟動時間：0.05 ms
SDK啟動后：CPU 接近 0%，內(nèi)存大約幾十kb
包體積：72 kb
磁盤使用：3 kb，（一次啟動數(shù)據(jù)上報流量 2 kb）
常駐線程：啟動一分鐘內(nèi)有3個，收集完數(shù)據(jù)后，常駐線程僅1個，CPU 接近 0%
另外我還一個業(yè)務(wù)型的SDK在月活1.1億的APP上，崩潰數(shù)只有11個。
