本文參考以下文章再芋，做了一點優(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è)認(rèn)為掉了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所寫
改進(jìn)的地方有：
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.reibang.com/p/1f8e36285539
4.監(jiān)控線程只獲取調(diào)用棧笙什，另起一個線程進(jìn)行符號化飘哨，相當(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個。
