冷啟動、溫啟動、熱啟動

首先了解下啟動的這三個概念，也是面試常被問到的：

• 冷啟動。冷啟動指的是該應用程序在此之前沒有被創建，發生在應用程序首次啟動或者自上次被終止后的再次啟動。簡單的說就是app進程還沒有，需要創建app的進程并啟動app。

比如開機后，點擊屏幕的app圖標啟動應用。

冷啟動的過程主要分為兩步：

1）系統任務。加載并啟動應用程序；顯示應用程序的空白啟動窗口；創建APP進程 

2）APP進程任務。啟動主線程；創建Activity；加載布局；屏幕布局；繪制屏幕

其實這不就是APP的啟動流程嘛？所以冷啟動是會完整走完一個啟動流程的，從系統到進程。

• 溫啟動。溫啟動指的是App進程存在，但Activity可能因為內存不足被回收，這時候啟動App不需要重新創建進程，只需要執行APP進程中的一些任務，比如創建Activity。

比如返回Home后，又繼續使用其他的APP，時間久了或者打開的應用多了，之前應用的Activity有可能被回收了，但是進程還在。

所以溫啟動過程相當于執行了冷啟動的第二過程，也就是APP進程任務，需要重新啟動線程，Activity等。

• 熱啟動。熱啟動就是指App進程存在，并且Activity對象仍然存在內存中沒有被回收。

比如app被切到后臺，再次啟動app的過程。

所以熱啟動的開銷最少，這個過程只會把Activity從后臺展示到前臺，無需初始化，布局繪制等工作。 

優化點

三種啟動方式中，冷啟動經歷的時間最長，也是走完了最完整的啟動流程，所以我們再次分析下冷啟動的啟動流程，看看有哪些可以優化的點：

• Launcher startActivity
• AMS startActivity
• Zygote fork 進程
• ActivityThread main()
• ActivityThread attach
• handleBindApplication
• attachBaseContext
• Application attach
• installContentProviders
• Application onCreate
• Looper.loop
• Activity onCreate，onResume

縱觀整個流程，其實我們能動的地方不多，無非就是Application的attach，onCreate方法，Activity的onCreate，onResume方法，這些方法也就是我們的優化點。 

優化方案 

1）消除啟動時的白屏/黑屏

App啟動的時候會有一個白屏/黑屏時間，我們可以通過設置windowBackground屬性來給啟動的Activity提供一個drawable，這樣就給用戶一個快遞啟動的假象了。

<activity ...
android:theme="@style/MyAppTheme" />

<style name="MyAppTheme" parent="Theme.AppCompat.NoActionBar">
    <item name="android:windowBackground">@drawable/logo</item> 
</style>
  

2）第三方庫懶加載/異步加載

Application的onCreate方法中，總會有很多初始化操作，比如友盟，數據庫，網絡請求庫，廣告SDK等等。

對此，我們能做的有哪些呢？

• 異步加載。有些庫不需要在主線程進行初始化，那么我們就可以在子線程中進行初始化，進行異步加載。
• 延遲加載。有些庫不必要一開始就初始化，我們可以按需初始化，將一些庫放到用它的時候再初始化，或者放到啟動頁去進行初始化。

所以需要我們對這些初始化操作進行分析，哪些需要在主線程進行，哪些可以延遲加載，哪些初始化任務有先后關系等等。這里涉及到一個啟動器的概念，啟動器的用處就是可以充分利用CPU多核，自動梳理任務順序。有空的朋友可以去了解下。

這里還需要注意一點就是線程的使用：

• 即不要頻繁創建線程，線程的頻繁創建是耗性能的，所以需要用到     線程池去執行異步任務。 

3）預創建Activity

Java中的對象第一次創建的時候，java虛擬機首先檢查類對應的Class對象是否已經加載。如果沒有加載，jvm會根據類名查找.class文件，將其Class對象載入。同一個類第二次new的時候就不需要加載類對象，而是直接實例化，創建時間就縮短了。

今日頭條中就有這種做法，先創建一個Activity的實例。 

4）預加載數據

在我們的啟動頁或者主頁可以將一些要用到的數據保存到內存或者數據庫，那么其他頁面要用到這些數據的時候就可以直接使用并顯示了。 

5）Multidex預加載優化

由于65536方法限制，所以一般class文件要生成多個dex文件，Android5.0以下，ClassLoader加載類的時候只會從class.dex（主dex）里加載，所以要執行MultiDex.install(context)方法才能正常讀取所有的dex類。

而這個install方法就是耗時大戶，會解壓apk，遍歷dex文件，壓縮dex、將dex文件通過反射轉換成DexFile對象、反射替換數組。

這里需要的方案就是今日頭條方案：

• 在Application的attachBaseContext方法里，啟動另一個進程的LoadDexActivity去異步執行MultiDex邏輯，顯示Loading。

• 然后主進程Application進入while循環，不斷檢測MultiDex操作是否完成 ，MultiDex執行完之后主進程Application繼續執行ContentProvider初始化和Application onCreate方法，也就是主進程正常的邏輯。

所以重點就是單開進程去執行MultiDex邏輯，這樣就不影響APP的啟動了。

當然，這僅僅針對5.0以下加載Multidex情況，5.0以上默認使用ART加載類，安裝時候就已經轉換dex文件為oat文件了，所以無需優化Multidex情況了。 

6）Webview啟動優化

如果我們的主頁涉及到Webview，那我們還要處理WebView的優化。因為Webview的創建很耗時，所以我們采取以下方案進行Webview的優化：

• 預先創建WebView，提前將其內核初始化。
• 使用WebView緩存池，從緩存池中拿到Webview實例。
• 本地提供靜態頁面資源。 

7）避免布局嵌套

如果啟動頁和主頁的布局比較復雜，也會影響我們的啟動時間，所以注意我們的布局，多用merge，include，constraintlayout等，特別是多層嵌套問題。