>

1、前言

App的啟動速度是使用者對於App的第一印象，如果App啟動的很慢那非常有可能導致使用者的流失，因此對於App的啟動速度可以說是我們必須要保障的一道關卡！接下來我給大家介紹一下App啟動速度最佳化的常用方案。

2、衡量啟動時間

要想最佳化啟動速度首先我們需要知道怎麼精確獲取App的啟動速度，只有先拿到了精確的啟動速度才好評估時間到底有多久以及後續的最佳化效果。對啟動速度最佳化有經驗的同學都知道使用 adb shell am start -W 首屏Activity 這個命令可以拿到App的啟動速度，一般App做啟動速度統計都是這麼做的。

那這麼做真的可以嗎？

答案肯定是No，首先這種adb 命令的方式只能線上下才能使用，這也就意味著如果使用了這種衡量方式，我們線上上根本無從知道使用者在實際情況下到底慢還是不慢以及慢的程度，這其實是不可接受的，因為線上使用者的實際優秀體驗才是我們追求的目標。其次對於這個命令拿到的值，它只是到了Activity的第一幀而已，也就是並不能夠代表使用者實際看到我們App這個介面了。舉個例子：當首頁是一個列表的時候，列表的資料需要網路傳輸回來，那Activity的第一幀早就繪製了，但是使用者看不到真實的資料，這樣的使用者體驗依然很糟糕。所以adb 這種方式拿到的啟動時間並不能夠真實的反映出來使用者實際真正看到首頁需要的時間。

總結一下這種常規方案的缺點：

1. 只能線上下使用
2. 不能準確的表現出使用者實際的體驗

因此更建議大家自己精確的埋點來統計啟動時間，關於如何判斷啟動的結束以及優雅獲取啟動時間的方法歡迎檢視

3、實際最佳化

啟東速度慢的話我們來進行最佳化，一般情況下必不可少的就是非同步初始化最佳化，也就是使用非同步的方式來分擔主執行緒的工作達到加快啟動速度的目的。這裡也就涉及到了多執行緒的使用，實際上這是啟動最佳化中非常重要的一種手段。

但是非同步初始化最佳化就可以解決啟動速度慢的所有問題嗎？Naive！非同步初始化雖然有效，但是我們來想想它可能遇到的問題：主執行緒中執行的任務如果需要非同步初始化中執行的任務配合（也就是有依賴關係），這種情況下怎麼處理？簡單的說就是要保證非同步初始化的某項任務一定要在主執行緒的某個時刻前執行完成，怎麼辦？如果你提前這個非同步任務也只能保證這個非同步任務提前開始而已，你無法保證在每個手機上這項任務一定會在主執行緒的某個時刻都提前執行完成！

再者：假設你在Application的onCreate中做了非同步，但是一些非同步的任務需要在onCreate執行完成之前就結束，因為Splash介面可能會直接使用到這些任務。這種情況該怎麼處理呢？萬一這種情況特別多，怎麼處理起來更加優雅呢？

4、延遲初始化

做過啟動最佳化的同學肯定都知道我們可以將部分不重要的任務挪到啟動結束之後再去執行，講道理這也是一種有效的減少啟動速度的方法。 但是如果我延遲執行的任務總共需要1000ms才能全部執行完成，那豈不是啟動完成之後主執行緒還要被卡頓1000ms，在這個過程中如果使用者有滑動螢幕或者是點選事件等操作呢肯定是執行不了的，使用者一定會感受到卡頓，也就是介面雖然開啟了但是使用者還是操作不了，體驗也是非常的差！

這個方案很常見，但是如果用的不好的話很有可能會導致使用者雖然看到了介面但是無法操作。因此需要一種特殊的機制來保障即便是使用了延遲初始化也不會影響使用者的任何操作。

5、後記

關於App的啟動速度最佳化我在這裡提出來幾個常見的最佳化誤區，很多時候常規的最佳化方案如果使用不正確反而會起負面作用，因此需要有更先進的方案來指導我們的最佳化工作。關於文中所介紹的方案以及問題解決途徑，歡迎檢視，讓我們一起成為高階工程師吧！