作為Android開發，你必須要掌握的冷啟動優化知識-有解無憂

我們搞Android開發這一行，很多時候都在追求新技術，但是實際上，要想在Android領域有長遠的發展，還有很多東西要去了解，雖然不是最前沿的，但卻是最基礎的最需要的，

今天要和大家分享的就是作為Android開發必須掌握的Android冷啟動優化，

原文地址：https://www.jianshu.com/p/0d2a093a6d48

前言

事件發生在發包上線的前兩天，在某某云進行移動測驗時，提示冷啟動速度低于平均值的問題，之前自己也曾嘗試過優化，但是發現效果并不是很明顯，作為一個有追求的開發者，趁著有點空閑時間，要好好研究一下冷啟動優化問題，

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的優化

布局優化我們的啟動頁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市場競爭愈發激烈，如何在競品對比中勝出，還需要我們一步步地把一個個的細節做好做完美，

Android學習視頻推薦

Android實戰之性能優化
Android高級UI實戰
Android 的 FrameWork層原始碼分析

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/256405.html

標籤：其他

上一篇：學習Makefile的記錄

下一篇：Android播放音樂時,在設定中調節鈴聲大小或者設定鈴聲的時候提示音與音樂一起播放