這篇文章從干貨總量方面不如第一篇，而且一連發(fā)了兩篇類似文檔，總感覺沒有進步與新意。但是后來琢磨了一下，這篇質(zhì)量也不差，APP啟動時間也是此次項目我新碰到的一個點，估計也有相當多的同學碰到這個問題。之前并沒有太在意這個點，網(wǎng)上也已經(jīng)有比較好的文章來解決這個問題。但是還是跟第一篇的原因類似，官方的文章還是從原理上分析的比較好， 不僅授之以魚，還授之以漁 。所以還是想翻過來分享給大家，希望多指教，后面會豐富文章的類型，分享更多更好的文章。

啟動時間性能

用戶期望應用程序響應速度快，加載速度快。 啟動時間較慢的應用程序不滿足此預期，可能會令用戶失望。 這種糟糕的體驗可能會導致用戶在應用商店上差評你的應用，甚至完全放棄你的應用。

本文檔提供了有助于你優(yōu)化應用程序啟動時間的信息。 它首先解釋啟動過程的內(nèi)部。 接下來，它討論如何配置啟動性能。 最后，它描述了一些常見的啟動時間問題，并提供了一些提示如何解決。

啟動內(nèi)部

應用程序啟動可以在三個狀態(tài)之一發(fā)生，每個狀態(tài)都會影響應用程序?qū)τ脩艨梢娝璧臅r間：冷啟動，熱啟動和溫啟動。 在冷啟動，你的應用程序從頭開始。 在其他狀態(tài)下，系統(tǒng)需要將應用程序從后臺運行到前臺。 我們建議你總是基于冷啟動的假設進行優(yōu)化。 這樣做可以提高熱啟動和溫啟動的性能。

為了優(yōu)化你的應用程序以便快速啟動，有必要了解系統(tǒng)和應用程序級別上發(fā)生的情況，以及這些狀態(tài)和在這些狀態(tài)中的交互方式。

冷啟動

冷啟動指的是應用程序從頭開始：系統(tǒng)中沒有你的應用程序進程，直到此開始，才創(chuàng)建了你的應用程序進程。 在應用程序自啟動以來第一次啟動或系統(tǒng)終止應用程序等情況下會發(fā)生冷啟動。 這種類型的啟動在最小化啟動時間方面是最大的挑戰(zhàn)，因為系統(tǒng)和應用程序比其他啟動狀態(tài)要做更多的工作。

在冷啟動的開始，系統(tǒng)有三個任務。這些任務是：

加載和啟動應用程序。在啟動后立即顯示應用程序的空白開始窗口。創(chuàng)建 應用程序進程 。

一旦系統(tǒng)創(chuàng)建應用程序進程，應用程序進程將負責下一階段。 這些階段是：

創(chuàng)建應用程序?qū)ο髣?chuàng)建主Activity填充視圖放置屏幕執(zhí)行初始繪制

一旦應用進程完成了第一次繪制，系統(tǒng)進程就會替換當前顯示的背景窗口，將其替換為主Activity。此時，用戶可以開始使用應用程序。

圖1顯示了系統(tǒng)和應用程序進程如何在彼此之間移交工作。

圖1.冷應用程序啟動的重要部分的可視化表示。

在創(chuàng)建應用程序和創(chuàng)建activity時可能會出現(xiàn)性能問題。

應用程序創(chuàng)建

當應用程序啟動時，空白的開始窗口保留在屏幕上，直到系統(tǒng)第一次完成繪制應用程序。 此時，系統(tǒng)過程將切換應用程序的開始窗口，允許用戶開始與應用程序交互。

如果你在自己的應用程序中重載了 Application.oncreate( ) ，應用程序?qū)⑼ㄟ^在你的應用程序?qū)ο笊险{(diào)用此方法來啟動。 之后，應用程序產(chǎn)生主線程，也稱為UI線程，并創(chuàng)建你的主activity的任務。

從此刻開始，系統(tǒng)級和應用級進程將根據(jù)應用程序生命周期階段進行。

Activity創(chuàng)建

應用程序進程創(chuàng)建你的activity后，該activity將執(zhí)行以下操作：

初始化值。調(diào)用構(gòu)造函數(shù)。調(diào)用適用于activity的當前生命周期狀態(tài)的回調(diào)方法，例如 Activity.onCreate( ) 。

通常， onCreate( ) 方法對加載時間的影響最大，因為它以最高的開銷執(zhí)行工作：加載和擴充視圖，并初始化活動運行所需的對象。

熱啟動

與冷啟動相比，熱啟動應用程序要簡單得多，開銷更低。 在熱啟動，所有的系統(tǒng)都是把你的activity推到前臺。 如果所有應用程序的activity仍駐留在內(nèi)存中，那么應用程序可以避免重復對象初始化，布局膨脹和呈現(xiàn)。

但是，如果某些內(nèi)存已經(jīng)響應內(nèi)存調(diào)整事件(例如 onTrimMemory( ) )而被清除，那么將需要根據(jù)熱啟動事件重新創(chuàng)建這些對象。

熱啟動顯示與冷啟動場景相同的屏幕行為：系統(tǒng)進程顯示空白屏幕，直到應用程序完成呈現(xiàn)活動。

溫啟動

溫啟動包括在冷啟動期間發(fā)生的操作的一些子集；同時，它表示比熱啟動少的開銷。有許多潛在的狀態(tài)可以被認為是溫暖的開始。例如：

用戶退出你的應用，但隨后重新啟動它。該過程可能已繼續(xù)運行，但應用程序必須通過調(diào)用 onCreate( ) 從頭開始重新創(chuàng)建活動。

系統(tǒng)從內(nèi)存中退出你的應用程序，然后用戶重新啟動它。進程和Activity需要重新啟動，但任務可以從保存的實例狀態(tài)包傳遞到 onCreate( ) 中受益。

分析啟動性能

為了正確診斷開始時間性能，你可以跟蹤顯示應用程序啟動所需時間的指標。

初始顯示時間

從Android 4.4（API級別19），logcat包括一個輸出行，包含一個名為 Displayed 的值。 此值表示在啟動過程和完成在屏幕上繪制相應活動之間經(jīng)過的時間量。 經(jīng)過的時間包括以下事件序列：

啟動過程。初始化對象。創(chuàng)建并初始化活動。膨脹布局。第一次繪制你的應用程序。

報告的日志行看起來類似于以下示例：

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

如果你正在從命令行或終端中跟蹤logcat輸出，則查找已用時間很簡單。 要在Android Studio中查找耗用時間，必須在logcat視圖中禁用過濾器。 禁用過濾器是必要的，因為系統(tǒng)服務器會（而不是應用程序本身）提供此日志。

完成相應設置后，你可以輕松搜索正確的字詞以查看時間。圖2顯示了如何禁用過濾器，并在底部的第二行輸出中顯示了顯示時間的logcat輸出示例。

圖2.禁用過濾器，并在logcat中查找顯示的值。

logcat輸出中 Displayed 指標不一定捕獲所有資源加載和顯示之前的時間量：它不包括布局文件中未引用的資源，或者應用程序作為對象初始化的一部分創(chuàng)建的資源。 它排除了這些資源，因為加載它們是一個內(nèi)聯(lián)過程，并且不會阻止應用程序的初始顯示。

完全顯示的時間

你可以使用 reportFullyDrawn( ) 方法來測量應用程序啟動和完成顯示所有資源和查看層次結(jié)構(gòu)之間的經(jīng)過時間。 這在應用程序執(zhí)行延遲加載的情況下可能是有價值的。 在延遲加載中，應用程序不會阻止窗口的初始繪制，而是異步加載資源并更新視圖層次結(jié)構(gòu)。

如果由于延遲加載，應用程序的初始顯示不包括所有資源，那么你可能會將所有資源和視圖的完成加載和顯示視為單獨的指標：例如，你的UI可能已完全加載， 但尚未顯示應用程序必須從網(wǎng)絡獲取的圖片。

為了解決這個問題，你可以手動調(diào)用 reportFullyDrawn( ) ，讓系統(tǒng)知道你的活動已完成延遲加載。 當你使用此方法時，logcat顯示的值是自應用程序?qū)ο髣?chuàng)建以來所經(jīng)過的時間，以及調(diào)用 reportFullyDrawn( ) 的時刻。

如果你發(fā)現(xiàn)你的顯示時間比你想要的慢，你可以繼續(xù)嘗試找出啟動過程中的瓶頸

找到瓶頸

找到瓶頸的兩個好方法是Android Studio的Method Tracer工具和內(nèi)聯(lián)跟蹤。要了解Method Tracer，請參閱該工具的 documentation 。

如果你無法訪問Method Tracer工具，或無法在正確的時間啟動該工具以獲取日志信息，則可以通過在應用程序和活動的 onCreate( ) 方法中內(nèi)聯(lián)跟蹤獲得類似的洞察。 要了解內(nèi)聯(lián)跟蹤，請參閱 Trace 函數(shù)的參考文檔以及 Systrace 工具。

常見問題

本節(jié)討論了經(jīng)常影響應用程序啟動性能的幾個問題。這些問題主要涉及初始化應用程序和activity對象，以及加載屏幕。

繁重的應用程序初始化

當代碼覆蓋 Application 對象時，啟動性能可能會受到影響，并且在初始化該對象時執(zhí)行繁重的工作或復雜的邏輯。 如果你的應用程序子類執(zhí)行不需要完成的初始化，你的應用程序可能會在啟動期間浪費時間。 一些初始化可能是完全不必要的：例如，當應用實際上響應于intent而啟動時，初始化主activity的狀態(tài)信息。 根據(jù)intent，應用程序僅使用之前初始化的狀態(tài)數(shù)據(jù)的子集。

應用程序初始化期間的其他挑戰(zhàn)包括影響大或數(shù)量眾多的垃圾收集事件，或磁盤I / O與初始化同時發(fā)生，進一步阻止初始化過程。 垃圾收集是Dalvik運行時特別考慮的問題; Art運行時同時執(zhí)行垃圾回收，最小化操作的影響。

診斷問題

你可以使用方法跟蹤或內(nèi)聯(lián)跟蹤來嘗試診斷問題。

方法跟蹤

運行Method Tracer工具會顯示 callApplicationOnCreate( ) 方法最終調(diào)用 com.example.customApplication.onCreate 方法。 如果工具顯示這些方法需要很長時間才能完成執(zhí)行，那么您應該進一步探索以了解正在發(fā)生的工作。

內(nèi)聯(lián)跟蹤

使用內(nèi)聯(lián)跟蹤來調(diào)查可能的罪魁禍首，包括：

你應用程序的初始 onCreate( ) 函數(shù)。你的應用程序初始化的任何全局單例對象。任何磁盤I / O，反序列化或在瓶頸期間可能發(fā)生的緊密循環(huán)。

解決問題

無論問題是不必要的初始化還是磁盤I / O，解決方案都需要延遲初始化對象：只初始化那些立即需要的對象。 例如，而不是創(chuàng)建全局靜態(tài)對象，而是移動到單例模式，應用程序只在首次訪問它們時才會初始化對象。

繁重的Activity初始化

Activity創(chuàng)建通常需要很多高開銷的工作。通常，有機會優(yōu)化這項工作以實現(xiàn)性能提高。這些常見問題包括：

填充大的或復雜的布局。阻止在磁盤或網(wǎng)絡I / O上繪制屏幕。加載和解碼位圖。柵格化 VectorDrawable 對象。初始化activity的其他子系統(tǒng)。

診斷問題

在這種情況下，同樣，方法跟蹤和內(nèi)聯(lián)跟蹤都可以證明是有用的。

方法跟蹤

當運行Method Tracer工具時，特定區(qū)域?qū)Ｗ⒂谀愕膽贸绦虻?Application 子類構(gòu)造函數(shù)和 com.example.customApplication.onCreate（） 方法。

如果工具顯示這些方法需要很長時間才能完成執(zhí)行，那么你應該進一步探索以了解正在發(fā)生的工作。

內(nèi)聯(lián)跟蹤

使用內(nèi)聯(lián)跟蹤來調(diào)查可能的罪魁禍首，包括：

你應用程式的初始 onCreate( ) 函數(shù)。它初始化的任何全局單例對象。任何磁盤I / O，反序列化或在瓶頸期間可能發(fā)生的緊密循環(huán)。

解決問題

有許多潛在的瓶頸，但兩個常見的問題和補救措施如下：

你的視圖層次結(jié)構(gòu)越大，應用程序填充的時間就越長。 你可以采取兩個步驟來解決此問題：

通過減少冗余或嵌套布局來展開視圖層次結(jié)構(gòu)。

不要對UI的不需要在啟動過程中可見的部分進行填充。相反，使用 ViewStub 對象作為子層次結(jié)構(gòu)的占位符，應用程序可以在更適當?shù)臅r間填充。

將所有的資源初始化在主線程上也可以減慢啟動速度。 你可以解決這個問題，如下所示：

移動所有資源初始化，以便應用程序可以在不同的線程上懶惰地執(zhí)行它。允許應用加載和顯示你的視圖，然后更新依賴于位圖和其他資源的可視屬性。

主題化啟動屏幕

你可能希望為應用程序的加載體驗設計主題，以便應用程序的啟動屏幕與應用程序的其他部分保持一致，而不是與系統(tǒng)主題一致。這樣做可以隱藏緩慢的活動啟動。

實現(xiàn)主題啟動屏幕的常見方法是使用 windowDisablePreview 屬性關(guān)閉系統(tǒng)進程在啟動應用程序時繪制的初始空白屏幕。 但是，此方法可能會導致啟動時間比不抑制預覽窗口的應用程序更長。 此外，它強制用戶在activity啟動時等待而不反饋，會使他們懷疑應用程序是否正常工作。

診斷問題

你可以通過觀察用戶啟動應用時的慢響應來診斷此問題。在這種情況下，屏幕可能看起來已凍結(jié)，或已停止響應輸入。

解決問題

我們建議你不要禁用預覽窗口，而是遵循常見的 Material Design 。你可以使用activity的 windowBackground 主題屬性為起始activity提供一個簡單的自定義drawable。

例如，你可以創(chuàng)建一個新的可繪制文件，并從布局XML和應用程序清單文件中引用它，如下所示：

Layout XML 文件:

<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.gepszalag.com/bcjs/@drawable/product_logo_144dp' android:gravity='center'/> </item></layer-list>

Manifest 文件:

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

轉(zhuǎn)換回正常主題的最簡單方法是在調(diào)用 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.jianshu.com/p/42aea2335019