App啓動方式
冷啓動（Cold start）
冷啓動是指APP在手機啓動後第一次運行，或者APP進程被kill掉後在再次啓動。
可見冷啓動的必要條件是該APP進程不存在，這就意味着系統需要創建進程，APP需要初始化。在這三種啓動方式中，冷啓動耗時最長，對於冷啓動的優化也是最具挑戰的。因此本文重點談論的是對冷啓動相關的優化。
溫啓動(Warm start)
App進程存在，當時Activity可能因爲內存不足被回收。這時候啓動App不需要重新創建進程，但是Activity的onCrate還是需要重新執行的。場景類似打開淘寶逛了一圈然後切到微信去聊天去了，過了半小時再次回到淘寶。這時候淘寶的進程存在，但是Activity可能被回收，這時候只需要重新加載Activity即可。
熱啓動(Hot start)
App進程存在，並且Activity對象仍然存在內存中沒有被回收。可以重複避免對象初始化，佈局解析繪製。
場景就類似你打開微信聊了一會天這時候出去看了下日曆 在打開微信 微信這時候啓動就屬於熱啓動。
在最近任務給App加鎖和啓動方式有什麼關係
某些廠商爲了用戶體驗提供了給APP上鎖的功能，目的就是讓用戶自己做主是上鎖的APP不被殺，啓動的時候不會處於冷啓動方式，但是加鎖也不是萬能的,Low memory killer在內存極度吃緊的情況下也會殺死加鎖APP,在此啓動時也將以冷啓動方式運行。
AI和啓動方式有什麼關係
AI在進程管理方面可謂是大有可爲。MIUI10發佈了進程AI喚醒功能，使APP啓動速度遠超友商。這其中的道理簡單說就是學習用戶的使用習慣，提前將App進程創建好，當用戶打開APP時不會出現冷啓動。比如你是微信重度用戶你發現用了MIUI10就再也見不到微信啓動頁面的那個地球了，這就是AI喚醒的功勞。
從點擊APP圖標到主頁顯示出現需要經過的步驟
這裏我們來討論冷啓動的過程，進程啓動原則上有四種途徑，也就是通過其他進程對該APP的四大組件的調用來實現。
這裏我們重點討論用戶點擊桌面後的APP啓動，通過startActivity方式的啓動。
調用startActivity,該方法經過層層調用,最終會調用ActivityStackSupervisor.java中的startSpecificActivityLocked,當activity所屬進程還沒啓動的情況下,則需要創建相應的進程.
void startSpecificActivityLocked(...) {
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid, true);
if (app != null && app.thread != null) {
...//進程已創建
return
}
//創建進程
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
}
最終進程由 Zygote Fork進程:
進程啓動後系統還有一個工作就是：進程啓動後立即顯示應用程序的空白啓動窗口。
一旦系統創建應用程序進程，應用程序進程就會負責下一階段。這些階段是：
1.創建應用程序對象
2.啓動主線程
3.創建主要Activity
4.繪製視圖（View）
5.佈局屏幕
6.執行初始化繪製
而一旦App進程完成了第一次繪製，系統進程就會用Main Activity替換已經展示的Background Window，此時用戶就可以使用App了。
image.png
這裏很明顯有兩個優化點：
1.Application OnCrate()優化
當APP啓動時，空白的啓動窗口將保留在屏幕上，直到系統首次完成繪製應用程序。此時，系統進程會交換應用程序的啓動窗口，允許用戶開始與應用程序進行交互。如果應用程序中重載了Application.onCreate()，系統會調用onCreate()方法。之後，應用程序會生成主線程（也稱爲UI線程），並通過創建MainActivity來執行任務。
2.Activity onCreate()優化
onCreate()方法對加載時間的影響最大，因爲它以最高的開銷執行工作：加載並繪製視圖，以及初始化Activity運行所需的對象。
啓動速度優化
如何對啓動時間進行量化？
1.目前爲止見過最最牛逼的是使用機械手和高速相機測試，手機開機後使用機械手點擊應用桌面圖標，高速相機記錄啓動過程，後續通過程序分析視頻，從機械手點擊圖標到Activity顯示出來使用了多少時間。這種方式是最直觀和精確的，但是成本也很高。
2.通過shell 命令
adb shell am start -W [packageName]/[packageName.MainActivity]
執行成功後將返回三個測量到的時間：
ThisTime:一般和TotalTime時間一樣，除非在應用啓動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小。
TotalTime:應用的啓動時間，包括創建進程+Application初始化+Activity初始化到界面顯示。
WaitTime:一般比TotalTime大點，包括系統影響的耗時。
3.可以通過在代碼中增加log來計算啓動時間
4.使用systrace
Application OnCrate()優化
1.第三方SDK初始化的處理
Application是程序的主入口，很多三方SDK示例程序中都要求自己在Application OnCreate時做初始化操作。這就是增加Application OnCreate時間的主要元兇，所以需要儘量避免在Application onCreate時同步做初始化操作。比較好的解決方案就是對三方SDK就行懶加載，不在Application OnCreate()時初始化，在真正用到的時候再去加載。
下面實例對比下ImageLoader在採用懶加載後啓動速度優化。
一般我們在使用imageLoader時都會在Application onCreate()時在主線程加載：
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
ImageLoaderConfiguration.Builder config =
new ImageLoaderConfiguration.Builder(this);
ImageLoader.getInstance().init(config.build());
}
}
此時使用adb shell am start -W [packageName]/[packageName.MainActivity]檢測應用啓動時間，每次執行命令時需要殺死進程。
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.luozhanwei.myapplication/.MainActivity }
Status: ok
Activity: com.luozhanwei.myapplication/.MainActivity
ThisTime: 423
TotalTime: 423
WaitTime: 441
Total time在423ms之間，下面是封裝了一個懶加載ImageLoader的工具類示例：
public class ImageUtil {
private static boolean sInit;
private synchronized static void ensureInit() {
if (sInit) {
return;
}
ImageLoaderConfiguration.Builder config =
new ImageLoaderConfiguration.Builder(SecurityCoreApplication.getInstance());
....
// Initialize ImageLoader with configuration.
ImageLoader.getInstance().init(config.build());
sInit = true;
}
public static void display(String uri, ImageView imageView, boolean cacheOnDisk) {
imageView.setImageResource(R.drawable.icon_app_default);
ensureInit();
ImageLoader loader = ImageLoader.getInstance();
if (cacheOnDisk) {
loader.displayImage(uri, imageView);
} else {
loader.displayImage(uri, imageView, OPTIONS_NO_CACHE_DISK);
}
}
使用這種方案後的啓動時間：
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.luozhanwei.myapplication/.MainActivity }
Status: ok
Activity: com.luozhanwei.myapplication/.MainActivity
ThisTime: 389
TotalTime: 389
WaitTime: 405
看到TotalTime比之前減少了34ms（給出的數據爲10次檢測平均值）。
所以Application OnCreate 避免在主線程做大量耗時操作，例如和IO相關的邏輯，這樣都會影響到應用啓動速度。如果必須要做需要放到子線程中。
Activity onCreate（）優化
減少LaunchActivity的View層級，減少View測量繪製時間。
避免主線程做耗時操作
用戶體驗優化
消除啓動時的白屏/黑屏
冷啓動白屏.gif
爲什麼啓動時會出現短暫黑屏或白屏的現象？當用戶點擊你的app那一刻到系統調用Activity.onCreate()之間的這個時間段內，WindowManager會先加載app主題樣式中的windowBackground做爲app的預覽元素，然後再真正去加載activity的layout佈局。
很顯然，如果你的application或activity啓動的過程太慢，導致系統的BackgroundWindow沒有及時被替換，就會出現啓動時白屏或黑屏的情況（取決於你的主題是Dark還是Light）。
解決方案
1.甩鍋給系統
使用透明主題:
<item name="android:windowIsTranslucent">true</item>
Activity.onCreate()之前App不做顯示，這樣用戶誤以爲是手機慢了，這種瞞天過海的方案大家還是不要用了。
<resources>
<!-- Base application theme. -->
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
<!-- Customize your theme here. -->
<item name="colorPrimary">@color/colorPrimary</item>
<item name="colorPrimaryDark">@color/colorPrimaryDark</item>
<item name="colorAccent">@color/colorAccent</item>
<item name="android:windowIsTranslucent">true</item>
</style>
</resources>
效果如下：
甩鍋 .gif
2.主題替換
我們在style中自定義一個樣式Lancher，在其中放一張背景圖片，或是廣告圖片之類的
<style name="AppTheme.Launcher">
<item name="android:windowBackground">@drawable/bg</item>
</style>
把這個樣式設置給啓動的Activity
<activity
android:name=".activity.SplashActivity"
android:screenOrientation="portrait"
android:theme="@style/AppTheme.Launcher"
>
然後在Activity的onCreate方法，把Activity設置回原來的主題
@Override
protected void onCreate(Bundle savedInstanceState) {
//替換爲原來的主題，在onCreate之前調用
setTheme(R.style.AppTheme);
super.onCreate(savedInstanceState);
}
這樣在啓動時就通過給用戶看一張圖片或是廣告來防止黑白屏的尷尬。
增加啓動頁面.gif
— — — END — — —