我們搞Android開發這一行，很多時候都在追求新技術，但是實際上，要想在Android領域有長遠的發展，還有很多東西要去了解，雖然不是最前沿的，但卻是最基礎的最需要的。
今天要和大家分享的就是作爲Android開發必須掌握的Android冷啓動優化。
前言
事件發生在發包上線的前兩天，在某某雲進行移動測試時，提示冷啓動速度低於平均值的問題，之前自己也曾嘗試過優化，但是發現效果並不是很明顯，作爲一個有追求的開發者，趁着有點空閒時間，要好好研究一下冷啓動優化問題。
App的啓動流程
我們可以瞭解一下官方文檔《App startup time》對App啓動的描述。應用啓動分爲冷啓動、熱啓動、溫啓動。而冷啓動是應用程序從零開始，裏面涉及到更復雜的知識。我們這次主要是對應用的冷啓動進行分析和優化。應用在冷啓動的時候，需要執行下面三個任務:
- 加載和啓動應用程序；
- App啓動之後立即展示出一個空白的啓動窗口；
- 創建App程序的進程；
在這三個任務執行後，系統創建了應用進程，那麼應用進程會執行下一步：
- 創建App對象；
- 啓動Main Thread；
- 創建啓動頁的Activity；
- 加載View；
- 佈置屏幕；
- 進行初始繪製；
當應用進程完成初始繪製之後，系統進程用啓動頁的Activity來替換當前顯示的背景窗口，這個時刻用戶就可以使用App了。下圖顯示爲系統和應用程序的工作流程。
從上圖和上述的步驟我們可以知道，應用進程的創建，那麼它肯定會執行我們的Application的生命週期，當創建完成App的應用進程之後，主線程會初始化我們第一個頁面MainActivity與執行MainActivity的生命週期。我特意加粗了重點，這就是我們可以下手優化的部分。在分析如何優化前，我們可以先了解一下，我們的應用是不是需要對冷啓動進行優化。
PS：其實這些都是我們表面看到的東西，如果我們需要完整地去深究，我們要去具體分析Zygote Fork進程、ActivityManagerService源碼等，我們就不在該篇中詳述，給大家推薦相關書籍，有羅昇陽的《Android系統源代碼情景分析》，劉望舒的《Android進階解密》。
啓動時間檢測
那麼啓動時間多少纔是合適呢？在官方文檔中描述到當冷啓動在5秒或者更長的時，Android vitals就會認爲你的應用需要進行冷啓動相關的優化。不過Android vitals是針對Google Play的一款應用質量檢測工具，那大家都明白，不過你可以像我一樣使用阿里雲的移動測試，阿里雲提供的數據中，冷啓動的行業指標中位數是4875.67ms，大家可以酌情對比一下。好了，下面我們就聊一下如果檢測出我們應用的冷啓動時間。
Displayed Time
如上圖一顯示的Displayed Time，在Android 4.4（API級別19）及更高版本中，logcat包含一個名爲Displayed的log信息，此值表示啓動過程和完成在屏幕上繪製相應活動之間所經過的時間量。
ADB命令
adb shell am start -W [packageName]/[packageName.MainActivity]
在使用上一個方式Displayed Time的log打印臺，我們看到Displayed的log，後面跟着就是下面我們需要的[packageName]/[packageName.MainActivity]，我們可以直接複製使用，然後我 們在AS的Terminal中粘貼，接着打印的就是我們指定頁面的啓動時間數據。
Status: ok
Activity: com.xx.xxx/com.xx.xxxx.welcome.view.WelcomeActivity
ThisTime: 242
TotalTime: 242
WaitTime: 288
Complete
- ThisTime:是指調用過程中最後一個Activity啓動時間到這個Activity的 startActivityAndWait調用結束;
- TotalTime:是指調用過程中第一個Activity的啓動時間到最後一個Activity的 startActivityAndWait結束。
- WaitTime:是startActivityAndWait這個方法的調用耗時;
reportFullyDrawn
在某些特殊場景，我們可能不單單啓動頁的繪製完成回調時間就足夠了，我們需要連啓動頁的閃屏廣告接口數據成功回調之後纔算一個完整的時間，這時我們可以使用reportFullyDrawn
public class WelcomeActivity extends MvpActivity<WelcomePresenter> implements WelcomeMvp.View {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_welcome);
// 請求數據
mvpPresenter.config();
}
@Override
public void finishRequest() {
// 數據回調
reportFullyDrawn();
}
}
PS:這個方式minSdkVersion需要API19+，所以要對SDK版本進行設置或判斷。
Traceview
Traceview是Android設備的一個非常好用的性能分析工具，它可以通過詳細的界面，讓我們跟蹤程序的性能，並且能清晰地查看到每一個函數的耗時和調用次數。
Systrace
Systrace非常直觀地展示每個線程上面的API的調用順序和耗時情況。
Traceview和Systrace都是DDMS面板的工具，但是現在AS3.0以上的版本不再建議使用了，所以這裏就不詳述，如果有興趣的同學，可以看我上一篇文章《Android應用優化之流暢度實操》，裏面有詳細地說明這兩個工具的用法。
hugo
我們可以利用JakeWharton的hugo，通過註解的方式獲取對應的類或者函數所消耗的時間。我們可以利用它對啓動頁Activity的生命週期來摳細節。
啓動優化實操
用戶體驗優化
在冷啓動優化的主要體驗個人認爲就是消除啓動時的白屏/黑屏，因爲白屏/黑屏對於用戶使用的第一印象就是慢、卡頓。我們可以設置啓動頁的主題來達到目的。
<style name="WelcomeTheme" parent="Theme.AppCompat.Light.NoActionBar.FullScreen">
<item name="android:windowBackground">@drawable/shape_welcome</item>
<item name="android:windowDrawsSystemBarBackgrounds">false</item>
</style>
windowDrawsSystemBarBackgrounds是對部分有系統操作欄的設置。接着是這個窗口背景色的佈局。
<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
<item android:drawable="@android:color/white"/>
<item>
<bitmap
android:src="@drawable/welcome_bg"
android:gravity="center"/>
</item>
</layer-list>
啓動頁的廣告展示完跳轉到首頁，然後我們設置回我們的通用樣式，可以在清單文件，也可以在代碼中設置。
<activity
···
android:theme="@style/AppBaseFrameTheme"/>
通過對啓動頁的主題設置後，就會將白屏/黑屏抹去，用戶點擊App的圖標就展示啓動圖，讓用戶先產生啓動很快的“錯覺”。同時這裏可以通過動畫，讓啓動頁與首頁之間的過渡更加自然。
Application啓動優化
從上圖一的分析總結中，我對優化點Application的生命週期進行了加粗提示，接着我們回來對這部分進行優化實操。
1. Application#attachBaseContext()
Application啓動會經過attachBaseContext()–>onCreate()；這時大家從attachBaseContext的生命週期聯想到什麼？沒錯就是MultiDex分包機制。想必大家都會發現，自從我們方法數超出了65535處理了分包之後，啓動白屏/黑屏的問題就出現了，分包機制是導致冷啓動緩慢的重要原因，而現在部分應用採用插件化的方式來避免MultiDex帶來的白屏問題，這雖然是一種方法，但是開發成本實在高，對於不少應用來說是不必要的。我們來聊一下MultiDex優化，首先MultiDex可分成運行時和編譯時兩個部分：
- 編譯期：將App中的class以某種策略拆分在多個dex中，爲了減少第一個dex也就主dex中包含的class數；
- 運行期： App啓動時，虛擬機只加載主dex中的class。app啓動以後，使用Multidex.install，通過反射機制修改ClassLoader中的dexElements來加載其他dex；
從網上的多篇實踐分析中，他們主要採用的是異步方式。因爲App起始會先加載主dex包，那麼我們可以自主去處理分包的工作，我們將啓動頁和首頁需要的庫、組件等主要class分在主dex中，從而達到精分主dex包的大小，具體的操作寫法，大家可以參考網上MultiDex啓動優化文章，但是大家要注意在主dex的分包過程中，主dex經過我們一系列的優化操作減少了主dex的大小，因此也增大了NoClassDefFoundError的異常的可能，此時會導致我們的應用啓動失敗的風險，所以在優化後我們一定做好測試工作。
2. Application#onCreate()
經過attachBaseContext()後就到onCreate()生命週期，想必我們大部分的應用，會在這裏對我們使用到的第三方庫和組件進行初始化工作。由於版本不斷迭代，第三方庫的初始化都是直接寫在onCreate()中，大量的初始化工作導致該生命週期過於沉重，我們應該對這些第三方庫進行分類。下面是我整理我司App啓動的工作分類：
看着上圖，各種第三方工具初始化和業務邏輯初始化，影響啓動時間。我們先對它們拆分成四部分。
- 必須在onCreate()且是主進程中初始化
- 可以延遲，但是需要在Application中初始化
- 可以延遲到啓動頁的生命週期回調中初始化
- 延遲到用的時候再初始化
大家可以根據自身項目先列出自己項目的每一個初始化，然後進行分類。這裏雖然我沒有貼具體的操作代碼，不是我認爲new一個線程或者創建一個IntentService太簡單了就不說了，而是這裏需要注意的東西是整個冷啓動優化最多的，因爲自己也在這裏踩過坑。
舉一個GrowingIO的例子，當時項目用的是很舊版本的GIO，當時對GIO的初始化是放在子線程操作的，忽然發包前，運營部門提出升級GIO的SDK版本需求，升完之後編譯運行覺得沒什麼事情就直接打包了，到線上之後運營反饋新版本沒了圈選數據，經過檢查發現新版本的GIO是不能在子線程初始化的。
從這個教訓中，我認爲既然同學你都對冷啓動優化感興趣，所以一定不會差那幾句複製粘貼的代碼，這些都是要具體情況具體分析。我來總結一下重點
- 啓動慢，不是無腦開線程，然後塞代碼就完事，需要對症下藥；
- 開線程也是一門學問，Thread、ThreadPoolExecutor、AsyncTask、IntentService，究竟選取哪個；
- 假設你new好了Thread，但是有沒考慮好內存泄漏問題，不要一邊補坑一邊挖坑；
- 注意有些第三方SDK需要在主線程初始化的；
- 如果是應用是多進程的，注意有些第三方SDK，需要你在跟同包名進程下進行初始化；
- 其實有好多項目，經過多年的版本迭代都是沒有整理過代碼的，那些舊代碼、無用代碼都是需要歸類整理的；
啓動頁Activity的優化
-
佈局優化 我們的啓動頁Activity包含有啓動圖控件、閃屏廣告圖控件、閃屏廣告視頻控件、首次安裝介紹圖控件。對於佈局優化而言，除了啓動圖控件外，其他都不是App啓動時都要初始化的控件，這時我們可以使用ViewStub。針對指定的業務場景，初始化指定的控件。
-
避免I/O操作 我們知道I/O操作不是實時的，例如數據庫的讀寫、SharedPreferences#apply()。我們要注意這些操作有沒阻塞主線程地執行，同時我們可以利用StrictMode嚴格模式,利用它可以檢測我們在啓動的時候有沒正確進行磁盤讀寫操作。
-
注意圖片bitmap的加載速度和編碼格式 我們可以知道，啓動頁大部分的情況下都是圖片的顯示，那麼我們在圖片這方面怎麼摳細節呢，那就是對各種第三方圖片加載庫的選用了Glide、Picasso、Fresco等，還有是PREFER_ARGB_8888、PREFER_RGB_565的選取問題，大家可以針對屬於自己項目情況進行選取。
-
對矢量圖VectorDrawable對象的使用 矢量圖的核心是省時間、省空間。而對於某些用戶，它的啓動圖可能不是一張圖片，它十分簡約，就一個logo，這個時候我們可以考慮一下矢量圖的用法。
-
注意Activity中的啓動生命週期的回調 我們在Application#onCreate()優化，將某些不是很必要的網絡請求，搬到了歡迎頁中，但是我們也不能直接將這個網絡請求操作直接拷貝到啓動頁的onCreate()中，我們可以巧妙地利用Activity生命週期中的Activity#onWindowFocusChanged(boolean hasFocus) ,這個是所有控件初始化完的真正回調，我們可以將網絡操作放在這裏，當然我們還可以使用Service。
冷啓動優化總結
對於冷啓動優化，需要我們一步步去分析，不像佈局優化那般照搬套路，所以在官方文檔中也多次出現bottleneck瓶頸這個詞彙，說明了我們的冷啓動優化之路不會一馬平川，大家要善用Android Studio‘s CPU profiler（有機會我們詳細分析一下該功能的使用）,因爲網上很多的總結是通過Traceview和Systrace，但是這兩者在AS3.0版本的升級已經捨棄，側面反映到我們要勤看官方文檔，用自己的第一角度去思考Android的變化，而不是通過別人的翻譯分析。
最後大家互相勉勵一下，在現在的Android市場競爭愈發激烈，如何在競品對比中勝出，還需要我們一步步地把一個個的細節做好做完美。