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

github.com/JakeWharton…

咱們能夠利用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的優化

1. 佈局優化 咱們的啓動頁Activity包含有啓動圖控件、閃屏廣告圖控件、閃屏廣告視頻控件、首次安裝介紹圖控件。對於佈局優化而言，除了啓動圖控件外，其餘都不是App啓動時都要初始化的控件，這時咱們可使用ViewStub。針對指定的業務場景，初始化指定的控件。
2. 避免I/O操做 咱們知道I/O操做不是實時的，例如數據庫的讀寫、SharedPreferences#apply()。咱們要注意這些操做有沒阻塞主線程地執行，同時咱們能夠利用StrictMode嚴格模式,利用它能夠檢測咱們在啓動的時候有沒正確進行磁盤讀寫操做。
3. 注意圖片bitmap的加載速度和編碼格式 咱們能夠知道，啓動頁大部分的狀況下都是圖片的顯示，那麼咱們在圖片這方面怎麼摳細節呢，那就是對各類第三方圖片加載庫的選用了Glide、Picasso、Fresco等，還有是PREFER_ARGB_888八、PREFER_RGB_565的選取問題，你們能夠針對屬於本身項目狀況進行選取。
4. 對矢量圖VectorDrawable對象的使用 矢量圖的核心是省時間、省空間。而對於某些用戶，它的啓動圖可能不是一張圖片，它十分簡約，就一個logo，這個時候咱們能夠考慮一下矢量圖的用法。
5. 注意Activity中的啓動生命週期的回調 咱們在Application#onCreate()優化，將某些不是很必要的網絡請求，搬到了歡迎頁中，可是咱們也不能直接將這個網絡請求操做直接拷貝到啓動頁的onCreate()中，咱們能夠巧妙地利用Activity生命週期中的Activity#onWindowFocusChanged(boolean hasFocus) ,這個是全部控件初始化完的真正回調，咱們能夠將網絡操做放在這裏，固然咱們還可使用Service。

冷啓動優化總結

對於冷啓動優化，須要咱們一步步去分析，不像佈局優化那般照搬套路，因此在官方文檔中也屢次出現bottleneck瓶頸這個詞彙，說明了咱們的冷啓動優化之路不會一馬平川，你們要善用Android Studio‘s CPU profiler（有機會咱們詳細分析一下該功能的使用）,由於網上不少的總結是經過Traceview和Systrace，可是這二者在AS3.0版本的升級已經捨棄，側面反映到咱們要勤看官方文檔，用本身的第一角度去思考Android的變化，而不是經過別人的翻譯分析。最後你們互相勉勵一下，在如今的Android市場競爭愈發激烈，如何在競品對比中勝出，還須要咱們一步步地把一個個的細節作好作完美。