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

啟動時間性能

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

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

啟動內部

應用程序啟動可以在三個狀態(tài)之一發(fā)生，每個狀態(tài)都會影響應用程序對用戶可見所需的時間：冷啟動，熱啟動和溫啟動。 在冷啟動，你的應用程序從頭開始。 在其他狀態(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)建應用程序對象創(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( ) ，應用程序將通過在你的應用程序對象上調用此方法來啟動。 之后，應用程序產(chǎn)生主線程，也稱為UI線程，并創(chuàng)建你的主activity的任務。

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

Activity創(chuàng)建

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

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

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

熱啟動

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

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

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

溫啟動

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

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

系統(tǒng)從內存中退出你的應用程序，然后用戶重新啟動它。進程和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)建的資源。 它排除了這些資源，因為加載它們是一個內聯(lián)過程，并且不會阻止應用程序的初始顯示。

完全顯示的時間

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

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

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

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

找到瓶頸

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

如果你無法訪問Method Tracer工具，或無法在正確的時間啟動該工具以獲取日志信息，則可以通過在應用程序和活動的 onCreate( ) 方法中內聯(lián)跟蹤獲得類似的洞察。 要了解內聯(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í)行垃圾回收，最小化操作的影響。

診斷問題

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

方法跟蹤

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

內聯(lián)跟蹤

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

你應用程序的初始 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)。

診斷問題

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

方法跟蹤

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

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

內聯(lián)跟蹤

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

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

解決問題

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

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

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

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

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

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

主題化啟動屏幕

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

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

診斷問題

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

解決問題

我們建議你不要禁用預覽窗口，而是遵循常見的 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://m.propowerdrill.cn/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