標籤：
【轉】對於Android的效能這方面評估，大部分都是有超級兔子去比跑分的，還是不能反映全面的問題。就我知道的而言，應用啟動時間是很影響使用者體驗的一個效能方面問題。
最近的一個項目，別人都說應用啟動慢，我師傅看我沒什麼事，叫我看一下。以前也看過一次，但那次是當學習，只是看看整流程是怎麼走的，這次確不一樣了。開始的一天，按以前的方式再看了一下，感覺沒有什麼異常的地方，不過時間確實比對比機慢了很多，但不知道是時間是發哪塊了。從InputReader到ViewRootImpl，從ViewRootImpl到Lanucher startActivity，從Launcher到ActivityManagerService把Activity顯示出來，整個流程走了一遍，沒有發現異常的地方，小鬱悶了一下。
第二天想了一下，覺得不對，自己對比的方式有問題，沒有把慢的手機跟對比機都進行相同的操作，導致知道時間慢了，也不知道慢在什麼地方了，於是，兩款手機我都只進電話介面，並且在兩個手機上都打了LOG，發現慢的那款手機怎麼都比好的那款手機慢200~300ms，我對比了一下整個時間，發現在AMS的scheduler到displayed Activity 時間特別長，確定那段時間是那這段了。
其實這段流程還有好多步驟，要把原來的Activity OnPause掉,壓入Activity Stack,然後在新的Activity顯示出來,整個Activity的生命週期都走了一遍,這讓群我情何以堪呀！沒招，只好採用分的方式，繼續打LOG。
曆經了千難萬險，最後終於發現在ActivityThread.java的 mInstrumentation.callActivityOnPause(r.activity)耗時最長，正常那款機型是不要時間的，而慢的那個手機，確要200~300ms，剛好是整個周期所慢下來的時間，是Lanucher在OnPause的時候慢下來了，在負責Lanucher同事問了下，最近Launcher改什麼了，才發現，Launcher在OnPause的時候，做動態壁紙的同事，添加了截屏的代碼，要截屏Lancher的Item，以便顯示出來。
折騰了兩三天，就得到了個這樣的結果，幸虧把問題找出來了。做效能的都說，環境一定要一樣，我也知道，可惜做起來未必會實行的，要不然第一天就不會白忙乎了！還有一點是重要的，原來二分法真的是那麼的神，以前重來沒發現過，這次自己是用了一下，效果相當不錯呀！把有O(n)的問題變成O(lon)的，看來效率真的會提升很大！
最近對Android GUI很來勁，希望自己好好的學習，能弄明白，聽說是Android最複雜的一塊，管他呢，玩玩而已！ onCreate onStart onPause 需要去分析到底是在哪個生命週期中花掉了最多的時間
android啟動時間慢的問題
