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