通常用戶期望app響應(yīng)和加載速度越快越好。一個啟動速度慢的app很可能會給用戶留下不好的印象，除了導(dǎo)致用戶在應(yīng)用市場上的打分低之外，很有可能導(dǎo)致致用戶直接卸載。

這篇文章提供了優(yōu)化app啟動時間的方法。先解釋了app進程啟動的內(nèi)部流程。然后討論如何優(yōu)化啟動的性能。最后列出幾個常見的啟動問題和解決方案。

一 啟動內(nèi)幕

App啟動可能發(fā)生在以下三種狀態(tài) 之一，每一種都會影響到展現(xiàn)給用戶的時間：冷啟動、熱啟動和溫啟動（翻譯的有點怪，介于冷和熱之間吧）。

冷啟動下，app所做的事情不較多，其它兩種情況，系統(tǒng)只需要將app從后臺切到前臺。建議你在冷啟動的基礎(chǔ)上做優(yōu)化，這樣也會提升熱啟動和溫啟動的性能。

為了更好地優(yōu)化app的啟動，了解系統(tǒng)和app層做了什么以及如何相互影響很有必要。

1.1 冷啟動

冷啟動指：在app啟動之前，系統(tǒng)的進程還沒有，直到app啟動創(chuàng)建app的進程。冷啟動會發(fā)生在device重啟或者app被殺死的情況下。這種啟動在優(yōu)化啟動時間上，有更大的挑戰(zhàn)，因為相比其它兩種啟動方式，系統(tǒng)和app有更多的工作需要處理。

冷啟動之前，系統(tǒng)會執(zhí)行以下三個task：

1、加載并啟動app

2、在app啟動后，立即展示空白的window

3、創(chuàng)建app進程

一旦系統(tǒng)創(chuàng)建了app進程，那么app進程就會執(zhí)行以下步驟

1、創(chuàng)建app對象

2、啟動main thread

3、創(chuàng)建MainActivity

4、Inflate view

5、布置屏幕

6、進行首次繪制

一旦app進程完成了第一次繪制，系統(tǒng)進程就會用main activity替換已經(jīng)展示的background window。之后用戶才可以使用app。

下圖展示了系統(tǒng)和app進程互相如何工作的，展示了app啟動時期的幾個重要部分，在創(chuàng)建app和main activity之間，我們可以提升性能問題

Application的創(chuàng)建

當應(yīng)用啟動的時候，空白的window在app第一次完成繪制之前都會存在。在那之后，系統(tǒng)進程才會替換啟動窗口，允許用戶開始和app交互。

如果你復(fù)寫了 Application.oncreate() 方法，app啟動的時候，會調(diào)用該方法。之后，app會孵化主線程（UI線程），并通過它來創(chuàng)建main activity。

從這之后，系統(tǒng)和app級別的進程將會按照 app lifecycle stages 執(zhí)行。

Activity的創(chuàng)建

在app進程創(chuàng)建了Activity之后，Activity將會執(zhí)行以下操作

1、初始化值

2、調(diào)用構(gòu)造函數(shù)

3、調(diào)用毀掉方法，比如Activity.onCreate()。

通常，onCreate方法會對加載時間有比較大的影響。因為它將執(zhí)行繁重的工作：加載和填充view，并初始化Activity運行期間需要用的對象。

1.2熱啟動

相對于冷啟動，熱啟動會簡單的多。如果app的所有Activities還存在內(nèi)存中，那么系統(tǒng)需要做的就是將activity切換到前臺。這樣app會避免進行的對象初始化，布局填充和渲染。

但是，如果一些內(nèi)存在觸發(fā)內(nèi)存回調(diào)方法的時候被回收了，比如onTrimMemory()，那么這些對象就需要重新創(chuàng)建。

熱啟動會和冷啟動有相同的行為。系統(tǒng)也會展示一個空白的window，知道app完成Activity的渲染。

1.3 溫啟動

溫啟動做的工作介于冷熱啟動之間。這里列舉幾種可能被認為是溫啟動的狀態(tài)：

1、用戶離開了app，然后重新啟動它。這時進程還在繼續(xù)運行，但是Activity被回收了，app需要重新創(chuàng)建activity。

2、系統(tǒng)將你的app回收了，然后用戶重新啟動app。進程和Activity都需要重新啟動，但它們可以從onCreate方法保存的bundle中恢復(fù)。

二優(yōu)化啟動性能

為了確定啟動時間的性能問題，我們需要先確定app啟動花費了多少時間。

2.1 Time to initial display

從4.4（API 19）開始，logcat會輸出帶有Displayed的log。該值代表從app啟動進程到完成Activity第一次繪制的時間。該時間內(nèi)完成了一下流程：

啟動進程初始化對象創(chuàng)建和初始化Activity填充布局第一次繪制app

打出的log如下：

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

如果你從命令行或者終端跟蹤log的話，可以比較直接的定位到該log。如果在AndroidStudio中，別忘記關(guān)閉filter。

Displayed值并沒有捕獲所有資源都被加載和展示的總時間。那些不在layout文件中或者創(chuàng)建app初始化所需要對象的時間不包含在內(nèi)。因為這些資源是在一個內(nèi)部進程中加載的，并且不會阻塞app的初始化展示。

2.2 Time to full display

你可以調(diào)用 reportFullyDrawn() )方法去測量從應(yīng)用啟動到所有資源和view層級都被繪制出來的時間。這對于app執(zhí)行懶加載的情況很有用。在懶加載中，app不會阻塞window的初始化繪制，但同步進行資源加載和view的更新會阻塞。

由于懶加載，app的初始化展示不會包含所有的資源。你可以考慮完全加載并展示所有資源和view的時候作為一個考量。比如，UI可能完全加載了，包括一些text的繪制，但是由于圖片需要從網(wǎng)絡(luò)獲取，這時還沒有展示。

為了處理這種情況，你可以手動地調(diào)用reportFullyDrawn方法讓系統(tǒng)知道你的activity已經(jīng)通過懶加載完成了。但你是用該方法的時候，logcat展示的時間就包含從應(yīng)用被創(chuàng)建到reportFullyDrawn方法被調(diào)用的時間。

定位瓶頸

兩種方式可以幫助你定位問題：AndroidStudio中的Method Tracer和內(nèi)嵌tracing代碼的方式。更多可以參考 documentation .

如果無法使用Method Tracer Tool ，或者覺得trace的時機不夠準確，那么你可以通過在app和Activity的onCreate方法中嵌入代碼進行追蹤，比如寫下追蹤代碼。更多信息，可以參考 Trace 、Systrace

三常見的問題3.1 繁重的App初始化

當你繼承了Application對象，又在Application對象進行初始化的時候執(zhí)行繁重的工作或者復(fù)雜的邏輯，那么就可能導(dǎo)致啟動的性能問題。在啟動的時候花一些時間去初始化一些子類可能完全沒必要。

在app初始化的時候，其它的挑戰(zhàn)包括垃圾回收事件，繁重的操作，比如I/O，都有可能會阻塞進程的初始化。對于Dalvik運行環(huán)境來說，垃圾回收是一個需要特別考慮的點，Art運行環(huán)境會并發(fā)的執(zhí)行垃圾回收，以便最小化垃圾回收產(chǎn)生的影響。

3.1.1定位為題

使用method tracing或者內(nèi)嵌代碼來定位這個問題

Method tracing

Running the Method Tracer tool reveals that the callApplicationOnCreate() method eventually calls your com.example.customApplication.onCreate method. If the tool shows that these methods are taking a long time to finish executing, you should explore further to see what work is occurring there.

內(nèi)嵌代碼的方式

可以對以下代碼進行追蹤

1、App的onCreate方法

2、onCreate中初始化的所有全局單例對象

3、所有I/O，反序列化，或者可能導(dǎo)致性能問題的循環(huán)

3.1.2 解決方案

如果是由于不必要的初始化或者硬盤I/O操作導(dǎo)致的問題，解決方案就是懶初始化對象：只初始化立即需要的。而不是在一開始就創(chuàng)建全局的靜態(tài)對象，可以將它們的初始化放在一個單例中，當app首次訪問它們的時候再初始化對象。

3.2繁重的Activity初始化

Activity的創(chuàng)建有時會承擔大量的復(fù)雜操作。通常這里存在可以優(yōu)化的點。常見的問題有：

1、填充大量復(fù)雜的布局

2、硬盤操作或者網(wǎng)絡(luò)操作阻塞了繪制

3、加載或者編碼bitmap

4、柵欄化VectorDrawable對象

5、Activity中其它子系統(tǒng)的初始化

3.2.1定位問題

和定位App啟動問題類似，也是通過method tracing或者嵌入代碼來定位。

Method tracing

當執(zhí)行Method Tracer tool的時候，你應(yīng)該關(guān)注繼承于Application的子類的構(gòu)造函數(shù)和onCreate方法。

如果該工具表明代碼中花了很長時間去執(zhí)行，那么你就應(yīng)該進一步查看這里的具體操作。

嵌入代碼的方式

追蹤的部分可能是以下代碼塊（和App初始化一樣）

1、App的onCreate方法

2、啟動時初始化的所有全局單例對象

3、所有I/O，反序列化，或者可能導(dǎo)致性能問題的循環(huán)

3.2.2 解決方案

上面可能有很多潛在的問題，這列舉兩種通用的問題和解決方案：

view的層級越龐大，app就會花越多的時間去填充它

減少多余的或者嵌套的布局

不填充哪些不需要在啟動時就需要展示的view。可通過ViewStub來實現(xiàn)，在需要的時候再填充

在main thread中做資源的初始化也會減慢啟動速度。可以通過下面來解決

延遲所有的資源初始化或者放在其它線程中去做

允許app先加載和展示view，那些依賴于bitmap或者其它資源之后再去更新

三 主題化的啟動屏幕

我們可以通過主題化app的啟動屏幕來改善啟動體驗。這樣整個app的啟動和接下來的操作會顯得更加連貫。但這樣只是將Activity的慢啟動問題隱藏了。

一種常用的方式實現(xiàn)主題啟動屏幕的方式是使用 windowDisablePreview 主題屬性關(guān)閉系統(tǒng)進程在app啟動時繪制的初始化空白屏幕。但是，這種方式會導(dǎo)致更長時間。同樣的，這樣也會迫使用戶等到Activity啟動后才會得到反饋，會讓用戶產(chǎn)生app本身是否有問題的困惑。

解決方案

建議你不應(yīng)該禁止預(yù)覽窗口，你應(yīng)該遵循 Material Design 標準。使用Activity的windowBackground主題屬性來為啟動的Activity提供一個簡單的drawable。

布局文件

<layer-list xmlns:android='http://schemas.android.com/apk/res/android' android:opacity='opaque'> <!-- The background color, preferably the same as your normal theme --> <item android:drawable='@android:color/white'/> <!-- Your product logo - 144dp color version of your app icon --> <item> <bitmap android:src='http://www.cgvv.com.cn/bcjs/@drawable/product_logo_144dp' android:gravity='center'/> </item> </layer-list>

Manifest file:

<activity ... android:theme='@style/AppTheme.Launcher' />

然后在代碼中將主題切換回app的主題，最簡單的方式是在 super.onCreate() 和 setContentView()方法之前 調(diào)用 setTheme(R.style.AppTheme)

public class MyMainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { // Make sure this is before calling super.onCreate setTheme(R.style.Theme_MyApp); super.onCreate(savedInstanceState); // ... }}

來自：http://www.lightskystreet.com/2016/10/15/android-optimize-start/