前言
最近因為工作原因遷移到了北京，大致有兩週時間。入職也大概有一週時間，工作內容與APM相關，包括改進與攻克新監控方案。雖然入職時間善短，但是龐大的使用者量下，即便是不到百分之一的卡頓率仍然影響到了巨大的使用者。如何改進現有的卡頓監控方案是目前我在思考的問題。
ANR
回顧市面上大多數的開源監控方案，大多采用ANR這種機制下的做法去實現卡頓的監控，進而進行堆疊資訊的追溯採集等。ANR這種方案最大的優點在於採集資料的準確率很高，基本可以說一旦發現主執行緒被block住了，那是一抓一個準的。但是同樣也有著自己的缺陷，即ping的週期閾值的問題。
目前多數的做法是在子執行緒中週期性的ping主執行緒判斷主執行緒是否被堵塞。如果不能在閾值內ping成功，說明主執行緒已經發生了卡頓
因此，此方案的問題在於這個ping週期應該是多長。本身在實現一套效能監控體系時，我們必須去衡量匯入這個工具會帶來怎樣的損耗，因此這個週期不能太短。同樣的，太長的週期也必然會漏掉可能發生的卡頓現象，而且這個概率不低。
平滑度
最近出現了一個稱作平滑度的概念，通過應用使用前後的平滑對比來判斷是否產生了卡頓問題。目前筆者沒有看到相關的處置程式碼，但是並不妨礙筆者對這種方案的猜測。通過所謂的平滑度對比應該是通過FPS檢視應用執行過程中的幀數變化。我們都知道通常情況下，螢幕會保持60幀/秒的重新整理頻率，如果在某一幀發生了大量計算導致跳幀，也可以稱作掉幀現象，具體表現就是我們感受到的卡頓。
這種卡頓採用ANR其實是很難檢測到的，這是視覺上的卡頓而非Not Response。因此除了CADisplayLink和人工測試之外，還是相當難的去捕獲到這種卡頓。
所以，一種改進的方案是放棄現有的純ANR方式的卡頓監控方案，結合CADisplayLink來實現另一種方式的監控。大致為主執行緒監聽螢幕重新整理訊號，子執行緒迴圈獲取FPS，並判斷是否發生下滑現象。如果發生下滑，此時再嘗試去ping主執行緒判斷是否被block住。相比起純ANR方案，這種方式的ping目的性更強，但是由於監控FPS的變化也是有時間的消耗的。這意味著短時的主執行緒block可能在ping出去沒多久時就已經恢復，實際發生的卡頓卻沒有被監控到，也算是這種方案的缺陷了。
最後
上面的方案屬於個人猜測的方案，具體效果如何還需要去實踐得真知。對於卡頓監控來說，有兩個相當重要的指標。準確率與捕獲率，這兩者在一定意義上是互相矛盾的，我們所做的工作無非是儘量在兩者之間權衡比較，得出當下最有利的方案。不過如果非要二選一的話，個人還是選擇準確率。畢竟只要有足夠的時間和樣本採集，捕獲率即便低了一些也總歸有機會採集的到。