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();
}
在啟動結束的時候關閉
根據這些執行緒的消耗cpu的情況，**執行的耗時，已經函式的呼叫和被呼叫情況，我們可以分析出啟動慢，卡頓等的耗時原因，已經優化方向。
接下來我們區分兩個指標：cputime和walltime
很多人會認為walltime**執行時間就是用來考量效能決定優化方向的指標，其實不然，我認為cputime才是真正的衡量指標，cputime**消耗cpu的時間即cpu占用時間。
原因：假設優先呼叫乙個函式出現了死鎖的情況，函式由於死鎖無法分配到cpu而處於等待的狀態，這個時候函式的walltime就會變得特別長，但是cputime卻是非常短，因為函式a非常簡單，甚至乎不怎麼消耗cpu。
假設我們發現啟動速度過慢，但是cpu的使用率又非常低，每乙個執行緒占用cpu的時間很短的時候，這個時候我們就可以考慮開闢多執行緒來解決問題。
其他工具：systrace
筆記 APP啟動優化
手機開機 開啟電源 引導晶元會啟動乙個引導程式bootloader，它負責把linux系統拉起來，系統又會做很多的設定，比如目錄的載入，網路的配置等等，其中它還會找乙個init.rc檔案。這個檔案會啟動乙個init程序，這個程序的程序號是1，也是系統啟動的第乙個程序。這個程序又會啟動乙個孵化器 zy...
App啟動優化 Podfile
新增pod,使用use frameworks 新增pod,不使用use frameworks 區別 靜態庫的優點 1.在啟動時靜態庫dylib loading time速度明顯提公升。2.通過ipa大小對比發現，靜態庫比動態庫ipa大小有所縮小。靜態庫 靜態鏈結庫 a 在編譯時會將庫copy乙份到目...
App效能之優化
本文暫不對工具的使用做過多的深入.在後續的具體例項中會具體說明怎麼用這些工具來達成分析目的和解決問題的.1,官方工具 1.1 strictmode 說明 顧名思義,嚴格模式 主要用來限制應用做一些不符合效能規範的事情.一般用來檢測主線程中的耗 時操作和阻塞.開啟strictmode後,如果執行緒中做...