App體系化優化之啟動優化（二工具的使用）

traceview是android平台配備乙個很好的效能分析工具，它可以通過圖形化的方式讓我們了解我們要跟蹤的程式的效能，並且能具體到方法。關於它的介紹，配置，使用相信網上有大篇幅的文章介紹，我就不贅言了。

既然是啟動的優化那麼我們就直接對啟動的部分進行效能的檢測

@override
public void oncreate() 
arouter.init(this);
umconfigure.init(this, "***x", "umeng", umconfigure.device_type_phone, "***x");
/*** 引數: boolean 預設為false，如需檢視log設定為true
*/umconfigure.setlogenabled(true);
/*** 引數：boolean 預設為false（不加密）
*/umconfigure.setencryptenabled(true);
umshareapi.get(this);
umengpushmanager.getinstance().initumpush();
//地圖初始化，解決第一次進採集介面沒有定位資料
locationcitymanager locationcitymanager = new locationcitymanager(this);
locationcitymanager.initlocation();
//未知異常捕獲，日誌記錄 郵件通知研發人員
//        uniexception.getinstance().init();
//initdb
litepal.initialize(this);
//初始化錄音工具
idealrecorder.getinstance().init(this);
debug.startmethodtracing();
}

在oncreat方法啟動的時候呼叫

在啟動結束的時候關閉

根據這些執行緒的消耗cpu的情況，**執行的耗時，已經函式的呼叫和被呼叫情況，我們可以分析出啟動慢，卡頓等的耗時原因，已經優化方向。

接下來我們區分兩個指標：cputime和walltime

很多人會認為walltime**執行時間就是用來考量效能決定優化方向的指標，其實不然，我認為cputime才是真正的衡量指標，cputime**消耗cpu的時間即cpu占用時間。

原因：假設優先呼叫乙個函式出現了死鎖的情況，函式由於死鎖無法分配到cpu而處於等待的狀態，這個時候函式的walltime就會變得特別長，但是cputime卻是非常短，因為函式a非常簡單，甚至乎不怎麼消耗cpu。

假設我們發現啟動速度過慢，但是cpu的使用率又非常低，每乙個執行緒占用cpu的時間很短的時候，這個時候我們就可以考慮開闢多執行緒來解決問題。

其他工具：systrace

App體系化優化之啟動優化（二工具的使用）

筆記 APP啟動優化

App啟動優化 Podfile

App效能之優化

App體系化優化之啟動優化（二工具的使用）

筆記 APP啟動優化

App啟動優化 Podfile

App效能之優化

相關推薦