導讀
在上一章的內容中，GT君爲大家介紹了CPU、內存、流量、流暢度等不同維度檢測的實現原理。在本章中GT君將繼續從頁面啓動時長維度、佈局的構建與繪製維度、數據庫操作維度爲大家講解這些功能的作用和實現原理。
1 頁面啓動時長檢測
1.1 頁面啓動時長
Activity啓動時長就是喚醒Activityy到Activity在前臺進行第一次繪製的時間，配合“繪幀檢測”中定位的掉幀區間，可以直觀的展示卡頓問題。
Fragment啓動時長就是喚醒Fragment到Fragment執行onResume的完成時間。
1.2 實現原理
對Activity和Fragment生命週期的監控： Android 4.0以上的版本可以利用ActivityLifecycleCallbacks來實現對生命週期的監聽，但此方法無法得到每個生命週期函數的執行時長。因此我們採用Hook的方式來監控Activity和Fragment的生命週期，這裏介紹一下最佳Hook節點：
Activity最佳Hook節點：
Fragment最佳Hook節點：
關於數據的整理：我們都知道，頁面分爲冷啓動和熱啓動（頁面從startActivity開始則是冷啓動，如果從onStart或onResume開始，則是熱啓動），我們可以維護一個頁面列表pageList,然後通過hashCode和生命週期函數的執行時間來歸類數據，並可以對頁面的冷熱啓動進行分析。
頁面開始啓動我們知道了，那麼什麼時候纔算是頁面啓動結束呢？
事實上頁面從開始到繪製完第一幀的這個時間，既是頁面從啓動開始到結束的所有時間。而對View繪製的監控，只需要Hook ViewGroup的dispatchDraw方法即可。
但由於ViewGroup的執行是遞歸的，所以我們發明了一種遞歸壓棧歸類法（將當前繪製節點進行壓棧和彈棧操作），而且通過最大棧深可以得知View的繪製深度。
直到dispatchDraw的棧深彈光，就說明一次繪製完成了。
2 佈局檢測
2.1 View構建時長
View構建是通過調用Inflate函數實現的，setContentView的原理也是通過Inflate函數構建View，這裏介紹一下最佳Hook節點：
Hook數據的結果：
2.2 View繪製深度
通過我們上文提到的遞歸壓棧歸類法（將當前繪製節點進行壓棧和彈棧操作），而且通過最大棧深就可以得知View的繪製深度：
其次是將viewDraw信息匹配給Activity：
3 DB檢測
對於數據庫的檢測方面，Hook的關鍵函數爲android.database.sqlite.SQLiteDatabase包下的方法：
DB檢測分析截圖如下：
結語
文章至此，GT3.1版本的大部分更新的功能及原理已經介紹完畢。總而言之，新版本的GT在測試移動應用的維度方面更加全面，統計分析的數據專業可靠，能夠讓大家完全瞭解自己的應用，鎖定優化範圍，進一步提升效率。在之後的版本更新中，我們團隊也將盡力爲大家帶來更好更便利的更新。
全文終！
項目開源地址：
https://github.com/Tencent/GT
版權所屬，禁止轉載！
掃描下方二維碼，關注微信公衆號：騰訊移動品質中心TMQ，獲取更多測試乾貨！
