安卓如何優化app的啟動速度

㈠ Android性能優化第（八）篇---App啟動速度優化之耗時檢測處理

應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash界面，但是這並沒有從根本上解磨絕決這個問題。那麼如何從根本上解決這個問題或者做到一定程度的緩解？

1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會首先會創建一個新的進程分配給該應用，這種啟動方式就是冷啟動。

2、熱啟動：當啟動應用時，後台已有該應用的進程，比如按下home鍵，這種在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這種啟動方式叫熱啟動。

3、溫啟動 ：當啟動應用時，後台已有該應用的進程，但是啟動的入口Activity被幹掉了，比如按了back鍵，應用雖然退出了，但是該應用的進程是依然會保留在後台，這種啟動方式叫溫啟動。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執行成功後將返回三個測量到的時間：

這裡面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的調用耗時，ThisTime 是指調用過程中最後一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 調用結束。TotalTime 是指調用過程中第一個 Activity 的啟動時間到最後一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等於 ThisTime。

總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。

從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什麼，將這個過程細分一下，會有下面的時間點需要注意。

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量、布局、繪制顯示在界面上。

因為上面這些階段全部都是在主線程中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以飢游攔我們不應在Application以及Activity的生命周期回調中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，否則用戶在桌面點擊你的應用圖標後，將感覺到明顯的卡頓。但是有些 不得以的任務 又必須在UI顯示之前執行。所以我們要將 任務 劃分優先順序。

對於首頁渲染完成後，開始載入，或者延遲載入，延遲載入的目的就是界面先顯示出來，然後載入，但是你覺得要延遲多久呢？在 Android 的高端機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那麼快了,而且現在應用為了兼容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是爛胡很明顯的。延遲載入有一種方式。

極力推薦用第二種，在窗口完成以後進行載入，這裡面的run方法是在onResume之後運行的。關於這種懶載入機制，參考 Android應用啟動優化:一種DelayLoad的實現和原理(上篇) ，給出了詳細的解釋。

通過上面我們知道一種懶載入機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢後載入。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優化第（六）篇---TraceView 分析圖怎麼看？

比如在首頁的onCreate中我們進行了用戶啟動上報，這個進行懶載入是不是分分鍾減少139毫秒呢？

在比如在Application裡面用到了GSON，將String轉化成json,我將這個移動到懶載入裡面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中載入幹嘛？

此處我們這里舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測保存一個boolean變數耗時120+毫秒以上。

利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。

五、優化思路總結
1、UI渲染優化，去除重復繪制，減少UI重復繪制時間，打開設置中的GPU過度繪制開關，各界面過度繪制不應超過2.5x；也就是打開此調試開關後，界面整體呈現淺色，特別復雜的界面，紅色區域也不應該超過全屏幕的四分之一；
2、根據優先順序的劃分，KoMobileApplication的一些初始化工作能否將任務優先順序劃分成3,在首頁渲染完成後進行載入，比如：PaySDKManager。
3、主線程中的所有SharedPreference能否在非UI線程中進行，SharedPreferences的apply函數需要注意，因為Commit函數會阻塞IO，這個函數雖然執行很快，但是系統會有另外一個線程來負責寫操作，當apply頻率高的時候，該線程就會比較佔用CPU資源。類似的還有統計埋點等，在主線程埋點但非同步線程提交，頻率高的情況也會出現這樣的問題。
4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。
5、對於首次啟動的黑屏問題，對於「黑屏」是否可以設計一個.9圖片替換掉，間接減少用戶等待時間。
6、對於網路錯誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。
7、任務優先順序為2，3的，通過下面這種方式進行懶載入的方式

8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。後面有空專門寫一篇Multidex。

相關鏈接：

Android應用啟動優化:一種DelayLoad的實現和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

Android性能優化之加快應用啟動速度http://www.open-open.com/lib/view/open1452821612355.html

手機淘寶性能優化全記錄http://www.open-open.com/lib/view/open1452488209370.html

Android客戶端性能優化（魅族資深工程師毫無保留奉獻）http://blog.tingyun.com/web/article/detail/155#rd

Please accept mybest wishes for your happiness and success !

㈡ Android啟動優化概述

Android啟動應用, 按 官方說法 分為冷啟動, 溫啟動和熱啟動.
具體的定義可以看官方文檔, 簡單地說

一般我們只需要關注冷啟動即可.

要想啟動快, 硬體性能必然有影響, 在硬體一定的前提下, 我們要盡量 降低啟動應用時CPU的負載 , 讓CPU有更多的算力投入到啟動流程中:

在做好一些基本原則後, 接著看具體的流程優化點

在應用進程創建後, 首先必然是載入類, 此時一些靜態變數就會初始化了, 因此我們應該

類載入完畢後就是創建 Application 實例了, 因此我們應該

之後會先創建 ContentProvider 和執行 ContentProvider.onCreate() , 因此我們應該

跟接著就會執行 Application.onCreate() 等方法, 因此我們應該

接著就進入 Activity 環節.
同樣第一步會是創建實例, 因此我們應該

在 Activity 進程生命周期後, 第一步就是渲染(inflate)布局, 我們應該

在應用啟動的瞬間, 系統服務會先展示一個空白窗口, 等待應用第一幀繪制完畢後, 再從該窗口切換到應用, 如果啟動耗時較長, 就會明顯看到白屏, 對於這一點, 常見的操作有

可以使用IdleHandler, 在主線程空閑時再執行某些不重要的操作

實際上非同步初始化只是不阻塞主線程, 但是子線程一樣會佔用CPU資源, 讓主線程的執行時間變少, 所以不應該盲目地將所有工作放到子線程.

優化做到最後, 就是在系統流程上做文章了

原理是將啟動時載入的類放到主dex，提升了這些類的內聚，讓更多的類滿足pre-verify的條件，在安裝時就做了校驗和優化，以減少首次載入的耗時，從而優化冷啟動耗時。
Redex 初探與 Interdex：Andorid 冷啟動優化

應用啟動過程中會從apk壓縮包中讀取文件, 該優化的原理是利用Linux中的Pagecache機制, 讓啟動過程會用到的文件盡可能進入緩存中, 減少磁碟IO次數
支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動性能

在Dalvik VM(Android5.0以前)載入類的時候會有一個類校驗過程, 它需要校驗方法的每一個指令, 是一個比較耗時的過程, 可以通過Hook去掉類載入過程中的類驗證過程. 不過對於ART(Android5.0之後)來說, 這個過程在安裝時已經做了, 所以用處不大.

不進入冷啟動, 就不用優化了~

這個Android Studio自帶的工具, 可以看到啟動過程中詳細的方法執行流程, 但是採集數據本身會影響方法執行, 所以不能准確判斷每個方法的耗時, 但是仍可以判斷哪個方法相對來說耗時.

這個工具的好處是可以自定義事件, 可以指定需要採集的數據集, 可以看到線程間的狀態等.

啟動優化的一個關鍵點在於定義啟動結束的點, 以及如何測量啟動時間.

在Android4.4以上, 系統進程會提供一個類似 ActivityManager: Displayed ***: +3s534ms 的日誌, 表示從啟動進程到首次繪制完畢所用的時間.

應用可以在任何時候調用該方法, 觸發系統列印類似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日誌

應用可以通過 ViewTreeObserver 來監聽繪制前回調來判斷第一幀的繪制時機, 或者直接在控制項樹的末尾加一個簡單的View, 它 onDraw 調用時即表示頁面(差不多)繪制完畢.

應用啟動過程可以參考 Android Vitals Series' Articles 系列文章

㈢ 怎麼提升安卓手機App的流暢度

平時大家在使用安卓手機的時候，有沒有遇到過某些APP使用起來不是很順暢，那麼我們該怎麼辦呢，接下來，我將向大家介紹一個方法，歡迎大家速來圍觀我的經驗啦。

首先，請大家進入安卓手機中的設置選項，然後在設置選項中找到「開發者選項」。

如果你找不到安卓手機的開發者選項的話，那麼一直點擊安卓系統中顯示的版本號，就會開啟這個功能，然後點擊開啟開發者選項。

進入開發者選項之後，點擊找到「強制進行GPU渲染」選項，默認該派腔選項是處於關閉狀態鬧局，但是我們可以點擊開啟這個選項。

通過強制打開GPU對應用進行渲染，額可以在一定程度上提升應用的流暢度，但是如果你的手機CPU運算速度不是太快的話，可以考慮開這個選項。但是如果開啟了GPU渲染的話，勢必會造成GPU的負擔，同時加速電量的消耗，需要大家注意哦。

其實在安卓手機的開發者選項中有很多有用的選項，讓我們更好地使用手機，這里推薦液羨讓一個窗口動畫的縮放效果，如果你將過渡動畫的縮放調整的很大的話，那麼我們將會看到一個動畫的詳細過程，十分有趣呢，小夥伴們趕快試試吧。

㈣ Android 性能優化 05---App啟動優化

其實啟動框架就是一個任務調度系統，是手淘啟動的「大管家」。
管家要做的事情就是把它們的關系梳理得明明白白，有條不紊，合理安排位置、調度時間，襲嘩同時提升硬體資源的利用率。

總結下來無非就是兩點：

有向無環圖[拓撲排序]

可用方案
APT，位元組碼插樁，利用ContentProvider
面試題LeakCanary 為什麼不需要在Application中手動初始化？

①點擊桌面App圖標，Launcher進程採用Binder IPC向system_server進程發起 startActivity請求；
②system_server進程接收到請求後，向zygote進程發送創建進程的請求；
③Zygote進程fork出新的子進程，即App進程；
④App進程，通過Binder IPC向sytem_server進程發起attachApplication請求；
⑤system_server進程在收到請求後，進皮禪頃行一系列准備工作後，再通過binder IPC 向App進程發送scheleLaunchActivity請求；
⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主 線程發送LAUNCH_ACTIVITY消息；
⑦主線程在收到Message後，通過反射機制創建目標Activity，並回調 Activity.onCreate()等方法。
⑧到此，App便正式啟動，開始進入Activity生命周期，執行完 onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

應用有三種啟動狀態，每種狀態都會影響應用向用戶顯示所需的時間：冷啟動、溫啟動與熱啟動。

adb命令啟動應用，一般會輸入三個值：ThisTime、TotalTime與WaitTime。
1.WaitTime：包括前一個應用Activitypause的時間和新應用啟動的時間；
2.ThisTime：表示一連串啟動Activity的最後一個Activity的啟動耗時；
3.TotalTime：表示新應用啟動的耗時，包括新進程的啟動和Activity的啟動，但不包括前一個應用Activitypause
的耗時。

StrictMode是一個開發人員工具，它可以檢測出我們可能無意中做的事情，並將它們提請我們注意，以便我 們能夠修復它們。 StrictMode最常用於捕獲應用程序主線程上的意外磁碟或網路訪問。幫助我們讓磁碟和網路操作遠離主線程， 可以使應用程序更加平滑、響應更快

當系統載入並啟動 App 時，需要耗費相應的時間，這樣會造成用戶會感覺到當點擊 App 圖標時會有 「延遲」 現象，
為了解決這一問題，Google 的做法是燃陸在 App 創建的過程中，先展示一個空白頁面，讓用戶體會到點擊圖標之後立
馬就有響應。
如果你的application或activity啟動的過程太慢，導致系統的BackgroundWindow沒有及時被替換，就會出現啟動
時白屏或黑屏的情況（取決於Theme主題是Dark還是Light）。

消除啟動時的黑/白屏問題，大部分App都採用自己在Theme中設置背景圖的方式來解決。

然後在Activity的onCreate方法，把Activity設置回原來的主題。

這么做，只是提高啟動的用戶體驗。並不能做到真正的加快啟動速度。

㈤ 如何優化安卓系統，加快啟動速度

系統啟動過程中，會掃描系統指定目錄下的所有apk文件，這個過程也是非常耗時的，預裝的apk文件越少，系統啟動速度也就越快，因此，精簡預裝apk也是優化系統啟動速度最重要的手段之一。

要想減少預裝的apk文件，則需要分析系統的build文件，將不需要的apk編譯選項刪除掉