利用 Traceview 精準定位啓動時間測試的異常方法 (工具開源)

機智的防爬蟲標識
原創博客地址：http://www.cnblogs.com/alexkn/p/7095855.html
博客求關注： http://www.cnblogs.com/alexkn

1.啓動時間測試經常使用方案介紹

如何精確測試啓動時間，其實這個問題可大可小，主要須要看團隊對啓動時間的測試精度要求，當啓動時間測試偏差須要精確到小几十毫秒時，不少問題都會暴露，由於其實目前很難有一種方式去評估數據的有效性。當前設備狀態，CPU溫度，內存，系統GC，研發人員的代碼以及線程模式等，都有可能致使啓動時間波動增大。目前已知的啓動時間測試方案有幾種，能夠例舉一下：

• 插樁法：經過在整個啓動的生命週期打日誌，而後經過解析日誌來獲得本次啓動時間
• 錄屏分幀：包括高速攝像頭或者其餘客戶端錄屏/截圖，經過錄制啓動時間的整個過程，經過作分幀處理，來獲得起始結束位置

但其實這些方法都有各自的問題，插樁引入的測試偏差自己很小，但由於系統偏差的關係，會致使自己波動會很大，而錄屏分幀，雖然能夠用於競品分析，但測試偏差會比較大，目前工業級的攝像頭，也只能到8ms/幀率，通常高速攝像頭的也會引入33ms的系統偏差，此外，若是在android端錄屏，可能會致使啓動時間波動更加增大，所以若是單純從測試方法上來改善啓動時間測試，效果確定不會好。由於咱們須要明白，系統隨機偏差的引入，因此啓動時間的測試數據是一個機率問題，而不是一個能夠100%必定出如今某個區域的問題（有時間寫一篇統計學跟偏差分析的文章）。
其實天然而然這就引伸出兩個問題：

• 問題定位方法的改進
• 偏差須要用科學的方法去作估算

固然這篇文章只講第一個問題，也就是怎麼去定位啓動時間問題，下面進入正題。

2.啓動時間問題定位方案

在這裏要推薦的是Traceview。Traceview的介紹能夠看這篇文章：https://testerhome.com/topics/5049

由於系統隨機偏差比較大，所以單獨看某一個生命週期中的耗時，並不能幫助定位問題，而Traceview能夠幫咱們查看到每個線程的調用棧以及方法的CPU時間或者堆棧累加時間。每每能夠經過Traceview來作問題定位，但目前有一些限制：

• 操做不超過5s
• 在IDE上查看才比較方便
• 大部分方法都混淆了，很難有效定位到對應的方法

其實這些問題都不是問題

• Traceview能夠經過android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();來打點，生成這段啓動週期的Trace數據
• google提供了一個半成品dmtracedump，能夠解析Traceview文件，固然也只是半成品，但咱們能夠本身解析，可是是有辦法突破IDE限制的
• 混淆問題其實不算問題，通常都有本身的mapping文件去解混淆

3.方案應用

咱們在版本迭代中，每個小版本演進時，其實變更的方法並不會太多，那麼，Traceview既然能看到進程，方法佔用的CPU時間片，那我能夠把全部的方法耗時作統計並作耗時排序，過濾掉系統線程以及不須要關注的線程，着重對比新增的方法以及改動的方法，而後咱們逐一去過濾top異常的方法就好了。

實際應用上能夠發現，用反混淆後的包去作對比測試，是能夠很明顯看到一些異常的耗時方法的。

4.思路拓展

這塊其實還能夠繼續拓展一下，但我這塊沒有實踐，能夠把個人想法拋出來給你們。

• 反混淆操做
• 經過對比兩個版本的Traceview方法，能夠過濾出top方法
• 拿到兩個revision間的svnlog，過濾出改動的方法
• 對比svnlog跟top異常方法，自動將可疑方法郵件發給研發，實現監控問題到定位問題的閉環。

5.開源一個工具

目前工具已開源，項目地址：https://github.com/alexknight/TraceAnalysis ，歡迎star
代碼是一年半前寫的，原來也只是邊探索邊驗證效果，後面沒有作重構，因此代碼質量並不高。最近僅僅只是把功能抽了出來，若是可以幫到你，隨手star讓我更有動力輸出一些有用的東西。
目前工具實現的功能包括

• 支持反混淆
• 支持獲取Traceview文件的解析結果，json對象返回
• 提供默認模板，支持Traceview兩兩對比，生成csv的結果文件

6.效果展現

在這裏，展現一下traceview文件解析後獲取到的json數據內容。其中包括了

• call_times每一個方法的調用次數
• costs:總耗時時長
• exclusive:每一個方法的cpu時間片以及調用棧
• inclusive:包含了每一個方法及孩子方法的時間累加
• method_thread:包含了涉及到該trace涉及到的全部線程
• sorted_dic:對全部耗時方法作了排序以tuple方式存儲在list中
• threads_pid:各個線程對應的pid

展開exclusive，能夠看到不少細節都有存儲

另外若是使用默認的報表對比輸出格式，展現的結果則爲：