選擇哪種工具誉帅，需要看具體的場景。我來匯總一下氧卧，
如果需要分析Native代碼的耗時桃笙，可以選SimplePerf；
如果想分析系統(tǒng)調(diào)用假抄，可以選擇Systrace怎栽；
如果想分析整個程序執(zhí)行流程的耗時丽猬，可以選擇Traceview或者插樁版本的Systrace。
卡頓監(jiān)控
消息隊(duì)列
通過一個監(jiān)控線程熏瞄，每隔1秒向主線程消息隊(duì)列的頭部插入一條空消息脚祟。假設(shè)1秒后這個消息并沒有被主線程消費(fèi)掉，說明阻塞消息運(yùn)行的時間在0~1秒之間强饮。換句話說由桌，如果我們需要監(jiān)控3秒卡頓，那在第四次輪詢中頭部消息依然沒有被消費(fèi)的話邮丰，就可以確定主線程出現(xiàn)了一次3秒以上的卡頓行您。
替換Looper的Printer實(shí)現(xiàn)
基于消息隊(duì)列的卡頓并不準(zhǔn)確，正在運(yùn)行的函數(shù)可能不是真正耗時的函數(shù)剪廉。
解釋一下娃循，我們假設(shè)消息循環(huán)里面順序執(zhí)行了A、B斗蒋、C三個函數(shù)捌斧，當(dāng)整個函數(shù)執(zhí)行超過3秒時，因?yàn)楹瘮?shù)A和B已經(jīng)執(zhí)行完畢泉沾，我們只能得到正在執(zhí)行的函數(shù)C的堆棧捞蚂，事實(shí)上它可能并不耗時。
不過對于線上大數(shù)據(jù)來說跷究，因?yàn)楹瘮?shù)A和B相對比較耗時姓迅，所以抓取到它們的概率會更大一些。
插樁方案
在編譯過程中插樁俊马，在函數(shù)的入口和出口出插樁丁存，兼容性沒有問題。需要考慮：
1.避免方法數(shù)暴增潭袱。 在函數(shù)的入口和出口應(yīng)該插入相同的函數(shù)柱嫌，在編譯時提前給每一個方法分配一個獨(dú)立的ID作為參數(shù)。
2.過濾簡單的函數(shù)屯换。 過濾一些類似return、i++這樣的簡單函數(shù)与学，并且支持黑名單配置彤悔。對一些調(diào)用非常頻繁的函數(shù)，需要添加到黑名單中來降低整個方案對性能的損耗索守。
基于性能的考慮晕窑，線上只會監(jiān)控主線程的耗時，微信的Matrix使用的就是這個方案卵佛，并且只在灰度包中使用
插樁方案的短板是杨赤，因?yàn)樗荒鼙O(jiān)控應(yīng)用內(nèi)自身的函數(shù)耗時敞斋，無法監(jiān)控到系統(tǒng)函數(shù)調(diào)用，整個堆椉采看起來好像缺失了一部分植捎。
監(jiān)控幀率、組件的生命周期阳柔、線程
幀率在發(fā)生繪制時監(jiān)控焰枢，ViewTreeObserver.addOnDrawListener
卡頓分析
Java實(shí)現(xiàn)
- Thread.getState方法獲取線程狀態(tài)
WAITIING、TIME_WAITING和BLOCKED都是需要特別注意的狀態(tài)舌剂。
synchronized (object) { //在這里卡住 -> BLOCKED
object.wait(); //在這里卡住 -> WAITIING
}
當(dāng)一個線程進(jìn)入WAITIING狀態(tài)時济锄，它不僅會釋放CPU資源，還會將持有的object鎖同時釋放
2.通過Thread.getAllStackTraces()進(jìn)一步拿所有線程的堆棧
需要注意在Android7.0 , getAllStackTraces是不會返回主線程的堆棧的
SIGQUIT信號實(shí)現(xiàn)
利用系統(tǒng)ANR的生成機(jī)制霍转，步驟：
1.當(dāng)監(jiān)控到主線程卡頓時荐绝，主動向系統(tǒng)發(fā)送SIGQUIT信號。
2.等待/data/anr/traces.txt文件生成
3.文件生成后進(jìn)行上報(bào)
Hook實(shí)現(xiàn)
用SIGQUIT信號量獲取ANR日志避消，從而拿到所有線程的信息很泊，這套方案看起來很美好，實(shí)際上它存在以下問題：
- 可行性沾谓。在很多高版本系統(tǒng)已經(jīng)沒有權(quán)限讀取/data/anr/traces.txt文件
- 性能委造。獲取所有線程堆棧及各種信息非常耗時，可能進(jìn)一步加劇用戶的卡頓
通過以下方式實(shí)現(xiàn)均驶，模擬系統(tǒng)打印ANR日志的流程
- 通過libart.so昏兆、dlsym調(diào)用ThreadList::ForEach方法，拿到所有的Native線程對象
- 遍歷線程對象列表妇穴，調(diào)用Thread::DumpState方法考慮到兼容性爬虱，通過fork子進(jìn)程方式實(shí)現(xiàn)，這樣子進(jìn)程崩潰不會影響主進(jìn)程運(yùn)行
為了降低上報(bào)數(shù)據(jù)量腾它，只關(guān)心主線程的Java線程狀態(tài)是WAITING跑筝、TIME_WAITING 或者 BLOCKED 幾種
卡頓日志分析
推薦使用卡頓樹的方式，對于超過3秒的卡頓瞒滴，具體是多少秒曲梗，這涉及到手機(jī)性能和當(dāng)時環(huán)境。我們決定拋棄具體的耗時妓忍，只按照相同堆棧出現(xiàn)的比例來聚合虏两。這樣，我們從一顆樹上面世剖，就可以看出哪些堆棧出現(xiàn)的卡頓問題更多定罢，它下面又存在哪些分支
