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

啟動時間性能

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

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

啟動內部

應用程序啟動可以在三個狀態之一發生，每個狀態都會影響應用程序對用戶可見所需的時間：冷啟動，熱啟動和溫啟動。 在冷啟動，你的應用程序從頭開始。 在其他狀態下，系統需要將應用程序從后臺運行到前臺。 我們建議你總是基于冷啟動的假設進行優化。 這樣做可以提高熱啟動和溫啟動的性能。

為了優化你的應用程序以便快速啟動，有必要了解系統和應用程序級別上發生的情況，以及這些狀態和在這些狀態中的交互方式。

冷啟動

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

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

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

一旦系統創建應用程序進程，應用程序進程將負責下一階段。 這些階段是：

創建應用程序對象創建主Activity填充視圖放置屏幕執行初始繪制

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

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

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

在創建應用程序和創建activity時可能會出現性能問題。

應用程序創建

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

如果你在自己的應用程序中重載了 Application.oncreate( ) ，應用程序將通過在你的應用程序對象上調用此方法來啟動。 之后，應用程序產生主線程，也稱為UI線程，并創建你的主activity的任務。

從此刻開始，系統級和應用級進程將根據應用程序生命周期階段進行。

Activity創建

應用程序進程創建你的activity后，該activity將執行以下操作：

初始化值。調用構造函數。調用適用于activity的當前生命周期狀態的回調方法，例如 Activity.onCreate( ) 。

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

熱啟動

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

但是，如果某些內存已經響應內存調整事件(例如 onTrimMemory( ) )而被清除，那么將需要根據熱啟動事件重新創建這些對象。

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

溫啟動

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

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

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

分析啟動性能

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

初始顯示時間

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

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

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

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

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

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

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

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

完全顯示的時間

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

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

為了解決這個問題，你可以手動調用 reportFullyDrawn( ) ，讓系統知道你的活動已完成延遲加載。 當你使用此方法時，logcat顯示的值是自應用程序對象創建以來所經過的時間，以及調用 reportFullyDrawn( ) 的時刻。

如果你發現你的顯示時間比你想要的慢，你可以繼續嘗試找出啟動過程中的瓶頸

找到瓶頸

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

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

常見問題

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

繁重的應用程序初始化

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

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

診斷問題

你可以使用方法跟蹤或內聯跟蹤來嘗試診斷問題。

方法跟蹤

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

內聯跟蹤

使用內聯跟蹤來調查可能的罪魁禍首，包括：

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

解決問題

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

繁重的Activity初始化

Activity創建通常需要很多高開銷的工作。通常，有機會優化這項工作以實現性能提高。這些常見問題包括：

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

診斷問題

在這種情況下，同樣，方法跟蹤和內聯跟蹤都可以證明是有用的。

方法跟蹤

當運行Method Tracer工具時，特定區域將專注于你的應用程序的 Application 子類構造函數和 com.example.customApplication.onCreate（） 方法。

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

內聯跟蹤

使用內聯跟蹤來調查可能的罪魁禍首，包括：

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

解決問題

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

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

通過減少冗余或嵌套布局來展開視圖層次結構。

不要對UI的不需要在啟動過程中可見的部分進行填充。相反，使用 ViewStub 對象作為子層次結構的占位符，應用程序可以在更適當的時間填充。

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

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

主題化啟動屏幕

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

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

診斷問題

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

解決問題

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

例如，你可以創建一個新的可繪制文件，并從布局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' />

轉換回正常主題的最簡單方法是在調用 super.onCreate（） 和 setContentView（） 之前調用 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