一、淺談APP啟動效能最佳化原因
1、引起效能問題的原因
隨著專案不斷的快速迭代，往往會造成App啟動卡慢現象，因為可能在App主程序啟動階段或者在主介面啟動階段放了很多初始化其他業務的邏輯，而這些業務落地可能一開始並不需要用到；
2、為什麼要做啟動速度最佳化
App啟動卡慢會影響一個App的解除安裝率和使用率；
啟動速度快會給人一種輕快的感覺，減少使用者等待時間；
如果一個App從點選桌面圖示到看到主介面花了10秒，請問你能接受麼？忍耐不好的估計直接就解除安裝了，或者沒等開啟就直接Home鍵按出去，然後殺程序了；這樣一來App解除安裝率提升了，使用率下降了。所以對於有大量使用者的App來說，這些效能細節是很重要的；
APP啟動效能最佳化工具的選擇
作為APP的開發者，我使用的一直都是一款友盟+軟體，U-APM 是友盟+推出的App穩定性監控、效能監控和雲真機測試平臺。透過輕量級的整合接入即可擁有實時、可靠、全面的應用崩潰、ANR、自定義異常等捕獲能力，及卡頓、啟動分析等效能能力，支援多場景、多通道智慧告警監控，幫助開發者高效還原異常、卡頓使用者的訪問路徑和業務現場，縮短故障排查時間。
二、分析怎麼做啟動最佳化
1、啟動過程簡單分析
App從點選桌面圖示到我們看到App的主介面整個過程中經過了哪些步驟，哪些地方是我們可以最佳化的地方;
2、從啟動過程找出最佳化點
App啟動過程中我們最佳化的地方包括主程序啟動流程和主介面啟動流程，主程序啟動就是Application的建立過程，主介面啟動就是MainActivity的建立過程；
只需要分別對這兩個部分進行最佳化即可:
Application中attachBaseContext最早被呼叫，隨後是onCreate方法，儘量在這兩個方法中不要有耗時操作；
MainActivity中重點關注onCreate，onResume，onWindowFocusChange;
三、啟動最佳化步驟
1、Application中加入非同步執行緒
是把不必要提前做的操作放到非同步執行緒中去做，也就是我們經常做的非同步載入；
2、主頁面加入非同步執行緒和延遲載入功能
與Application的最佳化思路一樣，也是封裝onSyncLoad和onAsyncLoad方法對現有程式碼進行一個分類，但是這兩個方法的呼叫時機要晚一點，是在主介面首屏繪製完成的時候呼叫。這個步驟也需要new一個Thead，屬於額外的開銷，不過這不影響我們整體效能；
3、態載入佈局：主佈局檔案最佳化
把主介面中不需要第一次就用到的佈局全部使用動態載入的方式來處理，使用ViewStub或者直接在使用時動態addView的方式；
4、主佈局檔案深度最佳化
如果做了上面這些最佳化還是會發現進入主介面還是有些慢，那麼需要重點關注主佈局檔案了。主佈局檔案的複雜度直接影響到了Activity的載入速度，這個時候需要對主佈局檔案進行深度優化了；
Activity在載入佈局的時候，會對整個佈局檔案進行解析，測量（measure）,佈局（layout）和繪製（draw），所以設計簡單合理的佈局尤為重要。幾個重要的最佳化如下：
●減少佈局層級
●減少首次載入View的數量
●減少過度繪製
5、頁面功能的分模組化和懶載入
一個頁面上有很多功能模組，最好每個功能模組都單獨的分開，模組之間用介面進行資料溝通；
按需載入所需要的功能，不要開啟一個頁面都載入所有的功能；
載入完所需要的功能，如果是一次性載入不需要保持在記憶體中，儘快銷燬掉，形成良好的習慣。
APP啟動效能最佳化是一條持續之路，透過最佳化我們可以瞭解到影響啟動效能的因素有哪些，這樣我們平時在編碼的過程中就會多注意自己的程式碼效能。開發者可利用友盟+U-APM對APP啟動進行監控，另外友盟+U-APM還提供雲真機測試能力，助力開發者從研發測試質量驗收到線上問題復現排查，保障應用品質，提升測試效率。在雲真機測試期間自動採集崩潰資訊，提供詳盡的崩潰報告協助篩查，真正實現監控測試全流程深度打通。
