前言

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

創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)整合營銷推廣、網(wǎng)站重做改版、臨泉網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁面制作、電子商務(wù)商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為臨泉等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

App的啟動流程

我們可以了解一下官方文檔《App startup time》對App啟動的描述。應(yīng)用啟動分為冷啟動、熱啟動、溫啟動。而冷啟動是應(yīng)用程序從零開始，里面涉及到更復(fù)雜的知識。我們這次主要是對應(yīng)用的冷啟動進(jìn)行分析和優(yōu)化。應(yīng)用在冷啟動的時候，需要執(zhí)行下面三個任務(wù):

• 加載和啟動應(yīng)用程序；

• App啟動之后立即展示出一個空白的啟動窗口；

• 創(chuàng)建App程序的進(jìn)程；

在這三個任務(wù)執(zhí)行后，系統(tǒng)創(chuàng)建了應(yīng)用進(jìn)程，那么應(yīng)用進(jìn)程會執(zhí)行下一步：

• 創(chuàng)建App對象；

• 啟動Main Thread；

• 創(chuàng)建啟動頁的Activity；

• 加載View；

• 布置屏幕；

• 進(jìn)行初始繪制；

當(dāng)應(yīng)用進(jìn)程完成初始繪制之后，系統(tǒng)進(jìn)程用啟動頁的Activity來替換當(dāng)前顯示的背景窗口，這個時刻用戶就可以使用App了。下圖顯示為系統(tǒng)和應(yīng)用程序的工作流程。

從上圖和上述的步驟我們可以知道，應(yīng)用進(jìn)程的創(chuàng)建，那么它肯定會執(zhí)行我們的Application的生命周期，當(dāng)創(chuàng)建完成App的應(yīng)用進(jìn)程之后，主線程會初始化我們第一個頁面MainActivity與執(zhí)行MainActivity的生命周期。我特意加粗了重點(diǎn)，這就是我們可以下手優(yōu)化的部分。在分析如何優(yōu)化前，我們可以先了解一下，我們的應(yīng)用是不是需要對冷啟動進(jìn)行優(yōu)化。

PS：其實(shí)這些都是我們表面看到的東西，如果我們需要完整地去深究，我們要去具體分析Zygote Fork進(jìn)程、ActivityManagerService源碼等，我們就不在該篇中詳述，給大家推薦相關(guān)書籍，有羅升陽的《Android系統(tǒng)源代碼情景分析》，劉望舒的《Android進(jìn)階解密》。

啟動時間檢測

那么啟動時間多少才是合適呢？在官方文檔中描述到當(dāng)冷啟動在5秒或者更長的時，Android vitals就會認(rèn)為你的應(yīng)用需要進(jìn)行冷啟動相關(guān)的優(yōu)化。不過Android vitals是針對Google Play的一款應(yīng)用質(zhì)量檢測工具，那大家都明白，不過你可以像我一樣使用阿里云的移動測試，阿里云提供的數(shù)據(jù)中，冷啟動的行業(yè)指標(biāo)中位數(shù)是4875.67ms，大家可以酌情對比一下。好了，下面我們就聊一下如果檢測出我們應(yīng)用的冷啟動時間。

Displayed Time

如上圖一顯示的Displayed Time，在Android 4.4（API級別19）及更高版本中，logcat包含一個名為Displayed的log信息，此值表示啟動過程和完成在屏幕上繪制相應(yīng)活動之間所經(jīng)過的時間量。

ADB命令

adb?shell?am?start?-W?[packageName]/[packageName.MainActivity]

在使用上一個方式Displayed Time的log打印臺，我們看到Displayed的log，后面跟著就是下面我們需要的[packageName]/[packageName.MainActivity]，我們可以直接復(fù)制使用，然后我 們在AS的Terminal中粘貼，接著打印的就是我們指定頁面的啟動時間數(shù)據(jù)。

Status:?ok
Activity:?com.xx.xxx/com.xx.xxxx.welcome.view.WelcomeActivity
ThisTime:?242
TotalTime:?242
WaitTime:?288
Complete

• ThisTime:是指調(diào)用過程中最后一個Activity啟動時間到這個Activity的 startActivityAndWait調(diào)用結(jié)束;

• TotalTime:是指調(diào)用過程中第一個Activity的啟動時間到最后一個Activity的 startActivityAndWait結(jié)束。

• WaitTime:是startActivityAndWait這個方法的調(diào)用耗時;

reportFullyDrawn

在某些特殊場景，我們可能不單單啟動頁的繪制完成回調(diào)時間就足夠了，我們需要連啟動頁的閃屏廣告接口數(shù)據(jù)成功回調(diào)之后才算一個完整的時間，這時我們可以使用reportFullyDrawn

public?class?WelcomeActivity?extends?MvpActivity?implements?WelcomeMvp.View?{?@Override
?protected?void?onCreate(@Nullable?Bundle?savedInstanceState)?{?super.onCreate(savedInstanceState);
?setContentView(R.layout.activity_welcome);?//?請求數(shù)據(jù)
?mvpPresenter.config();

?}?@Override
?public?void?finishRequest()?{?//?數(shù)據(jù)回調(diào)
?reportFullyDrawn();
?}
}

PS:這個方式minSdkVersion需要API19+，所以要對SDK版本進(jìn)行設(shè)置或判斷。

Traceview

Traceview是Android設(shè)備的一個非常好用的性能分析工具，它可以通過詳細(xì)的界面，讓我們跟蹤程序的性能，并且能清晰地查看到每一個函數(shù)的耗時和調(diào)用次數(shù)。

Systrace

Systrace非常直觀地展示每個線程上面的API的調(diào)用順序和耗時情況。

Traceview和Systrace都是DDMS面板的工具，但是現(xiàn)在AS3.0以上的版本不再建議使用了，所以這里就不詳述，如果有興趣的同學(xué)，可以看我上一篇文章《Android應(yīng)用優(yōu)化之流暢度實(shí)操》，里面有詳細(xì)地說明這兩個工具的用法。

hugo

github.com/JakeWharton…

我們可以利用JakeWharton的hugo，通過注解的方式獲取對應(yīng)的類或者函數(shù)所消耗的時間。我們可以利用它對啟動頁Activity的生命周期來摳細(xì)節(jié)。

啟動優(yōu)化實(shí)操

用戶體驗(yàn)優(yōu)化

在冷啟動優(yōu)化的主要體驗(yàn)個人認(rèn)為就是消除啟動時的白屏/黑屏，因?yàn)榘灼?黑屏對于用戶使用的第一印象就是慢、卡頓。我們可以設(shè)置啟動頁的主題來達(dá)到目的。

?@drawable/shape_welcome
?false

windowDrawsSystemBarBackgrounds是對部分有系統(tǒng)操作欄的設(shè)置。接著是這個窗口背景色的布局；

?
?
?
?

啟動頁的廣告展示完跳轉(zhuǎn)到首頁，然后我們設(shè)置回我們的通用樣式，可以在清單文件，也可以在代碼中設(shè)置；

通過對啟動頁的主題設(shè)置后，就會將白屏/黑屏抹去，用戶點(diǎn)擊App的圖標(biāo)就展示啟動圖，讓用戶先產(chǎn)生啟動很快的“錯覺”。同時這里可以通過動畫，讓啟動頁與首頁之間的過渡更加自然。

Application啟動優(yōu)化

從上圖一的分析總結(jié)中，我對優(yōu)化點(diǎn)Application的生命周期進(jìn)行了加粗提示，接著我們回來對這部分進(jìn)行優(yōu)化實(shí)操。

Application#attachBaseContext()

Application啟動會經(jīng)過attachBaseContext()-->onCreate()；這時大家從attachBaseContext的生命周期聯(lián)想到什么？沒錯就是MultiDex分包機(jī)制。想必大家都會發(fā)現(xiàn)，自從我們方法數(shù)超出了65535處理了分包之后，啟動白屏/黑屏的問題就出現(xiàn)了，分包機(jī)制是導(dǎo)致冷啟動緩慢的重要原因，而現(xiàn)在部分應(yīng)用采用插件化的方式來避免MultiDex帶來的白屏問題，這雖然是一種方法，但是開發(fā)成本實(shí)在高，對于不少應(yīng)用來說是不必要的。我們來聊一下MultiDex優(yōu)化，首先MultiDex可分成運(yùn)行時和編譯時兩個部分：

• 編譯期：將App中的class以某種策略拆分在多個dex中，為了減少第一個dex也就主dex中包含的class數(shù)；

• 運(yùn)行期： App啟動時，虛擬機(jī)只加載主dex中的class。app啟動以后，使用Multidex.install，通過反射機(jī)制修改ClassLoader中的dexElements來加載其他dex；

從網(wǎng)上的多篇實(shí)踐分析中，他們主要采用的是異步方式。因?yàn)锳pp起始會先加載主dex包，那么我們可以自主去處理分包的工作，我們將啟動頁和首頁需要的庫、組件等主要class分在主dex中，從而達(dá)到精分主dex包的大小，具體的操作寫法，大家可以參考網(wǎng)上MultiDex啟動優(yōu)化文章，但是大家要注意在主dex的分包過程中，主dex經(jīng)過我們一系列的優(yōu)化操作減少了主dex的大小，因此也增大了NoClassDefFoundError的異常的可能，此時會導(dǎo)致我們的應(yīng)用啟動失敗的風(fēng)險，所以在優(yōu)化后我們一定做好測試工作。

Application#onCreate()

經(jīng)過attachBaseContext()后就到onCreate()生命周期，想必我們大部分的應(yīng)用，會在這里對我們使用到的第三方庫和組件進(jìn)行初始化工作。由于版本不斷迭代，第三方庫的初始化都是直接寫在onCreate()中，大量的初始化工作導(dǎo)致該生命周期過于沉重，我們應(yīng)該對這些第三方庫進(jìn)行分類。下面是我整理我司App啟動的工作分類：

看著上圖，各種第三方工具初始化和業(yè)務(wù)邏輯初始化，影響啟動時間。我們先對它們拆分成四部分。

• 必須在onCreate()且是主進(jìn)程中初始化

• 可以延遲，但是需要在Application中初始化

• 可以延遲到啟動頁的生命周期回調(diào)中初始化

• 延遲到用的時候再初始化

大家可以根據(jù)自身項(xiàng)目先列出自己項(xiàng)目的每一個初始化，然后進(jìn)行分類。這里雖然我沒有貼具體的操作代碼，不是我認(rèn)為new一個線程或者創(chuàng)建一個IntentService太簡單了就不說了，而是這里需要注意的東西是整個冷啟動優(yōu)化最多的，因?yàn)樽约阂苍谶@里踩過坑。 舉一個GrowingIO的例子，當(dāng)時項(xiàng)目用的是很舊版本的GIO，當(dāng)時對GIO的初始化是放在子線程操作的，忽然發(fā)包前，運(yùn)營部門提出升級GIO的SDK版本需求，升完之后編譯運(yùn)行覺得沒什么事情就直接打包了，到線上之后運(yùn)營反饋新版本沒了圈選數(shù)據(jù)，經(jīng)過檢查發(fā)現(xiàn)新版本的GIO是不能在子線程初始化的。從這個教訓(xùn)中，我認(rèn)為既然同學(xué)你都對冷啟動優(yōu)化感興趣，所以一定不會差那幾句復(fù)制粘貼的代碼，這些都是要具體情況具體分析。我來總結(jié)一下重點(diǎn)

• 啟動慢，不是無腦開線程，然后塞代碼就完事，需要對癥下藥；

• 開線程也是一門學(xué)問，Thread、ThreadPoolExecutor、AsyncTask、IntentService，究竟選取哪個；

• 假設(shè)你new好了Thread，但是有沒考慮好內(nèi)存泄漏問題，不要一邊補(bǔ)坑一邊挖坑；

• 注意有些第三方SDK需要在主線程初始化的；

• 如果是應(yīng)用是多進(jìn)程的，注意有些第三方SDK，需要你在跟同包名進(jìn)程下進(jìn)行初始化；

• 其實(shí)有好多項(xiàng)目，經(jīng)過多年的版本迭代都是沒有整理過代碼的，那些舊代碼、無用代碼都是需要?dú)w類整理的；

啟動頁Activity的優(yōu)化

1. 布局優(yōu)化 我們的啟動頁Activity包含有啟動圖控件、閃屏廣告圖控件、閃屏廣告視頻控件、首次安裝介紹圖控件。對于布局優(yōu)化而言，除了啟動圖控件外，其他都不是App啟動時都要初始化的控件，這時我們可以使用ViewStub。針對指定的業(yè)務(wù)場景，初始化指定的控件。

2. 避免I/O操作 我們知道I/O操作不是實(shí)時的，例如數(shù)據(jù)庫的讀寫、SharedPreferences#apply()。我們要注意這些操作有沒阻塞主線程地執(zhí)行，同時我們可以利用StrictMode嚴(yán)格模式,利用它可以檢測我們在啟動的時候有沒正確進(jìn)行磁盤讀寫操作。

3. 注意圖片bitmap的加載速度和編碼格式 我們可以知道，啟動頁大部分的情況下都是圖片的顯示，那么我們在圖片這方面怎么摳細(xì)節(jié)呢，那就是對各種第三方圖片加載庫的選用了Glide、Picasso、Fresco等，還有是PREFER_ARGB_8888、PREFER_RGB_565的選取問題，大家可以針對屬于自己項(xiàng)目情況進(jìn)行選取。

4. 對矢量圖VectorDrawable對象的使用 矢量圖的核心是省時間、省空間。而對于某些用戶，它的啟動圖可能不是一張圖片，它十分簡約，就一個logo，這個時候我們可以考慮一下矢量圖的用法。

5. 注意Activity中的啟動生命周期的回調(diào) 我們在Application#onCreate()優(yōu)化，將某些不是很必要的網(wǎng)絡(luò)請求，搬到了歡迎頁中，但是我們也不能直接將這個網(wǎng)絡(luò)請求操作直接拷貝到啟動頁的onCreate()中，我們可以巧妙地利用Activity生命周期中的Activity#onWindowFocusChanged(boolean hasFocus) ,這個是所有控件初始化完的真正回調(diào)，我們可以將網(wǎng)絡(luò)操作放在這里，當(dāng)然我們還可以使用Service。

冷啟動優(yōu)化總結(jié)

對于冷啟動優(yōu)化，需要我們一步步去分析，不像布局優(yōu)化那般照搬套路，所以在官方文檔中也多次出現(xiàn)bottleneck瓶頸這個詞匯，說明了我們的冷啟動優(yōu)化之路不會一馬平川，大家要善用Android Studio‘s CPU profiler（有機(jī)會我們詳細(xì)分析一下該功能的使用）,因?yàn)榫W(wǎng)上很多的總結(jié)是通過Traceview和Systrace，但是這兩者在AS3.0版本的升級已經(jīng)舍棄，側(cè)面反映到我們要勤看官方文檔，用自己的第一角度去思考Android的變化，而不是通過別人的翻譯分析。最后大家互相勉勵一下，在現(xiàn)在的Android市場競爭愈發(fā)激烈，如何在競品對比中勝出，還需要我們一步步地把一個個的細(xì)節(jié)做好做完美。