Android App 優化之提高你的 App 啓動速度之理論基礎

爲了便於閱讀, 應邀將Android App性能優化系列, 轉移到掘金原創上來.
掘金的新出的"收藏集"功能能夠用來作系列文集了.

這篇咱們聊聊App啓動的事兒.

1, 欲善其事, 先利其器

論語有云: 工欲善其事，必先利其器. 要想提高App的啓動速度, 咱們須要先找到拖後腿的點, 要想找到這些點, 咱們就須要藉助咱們的工具了.

前文提到了不少工具, 今天咱們使用Traceview來分析咱們的啓動過程.

1.1 Traceview介紹

Traceview是一個性能分析工具, 主要是分析當前線程狀況, 各個方法執行時間等. 以下:

指標說明:

• Incl(Inclusive) Cpu Time
  方法自己和其調用的全部子方法佔用CPU時間.
• Excl(Exclusive) Cpu Time
  方法自己佔用CPU時間.
• Incl Real Time
  方法(包含子方法)開始到結束用時.
• Excl Real Time
  方法自己開始到結束用時.
• Call + Recursion Calls/Total
  方法被調用次數 + 方法被遞歸調用次數.
• Cpu Time/Call
  方法調用一次佔用CPU時間.
• Real Time/Call
  方法調用一次實際執行時間.

通常來講, 咱們使用Real Time/Call排序來找出耗時多的方法

有必要解釋下CPU Time和Real Time:
CPU Time 方法實際執行時間(不包括io等待時間)
Real Time 方法開始結束時間差(包括等待時間)
參考:stackoverflow.com/questions/1…

1.2 Traceview使用

有兩種方式來使用Traceview:
1, 經過DDMS:

點擊開始時會彈出一個選擇trace模式的框, 默認選中"Sample based profiling"便可:

• Sample based profiling(基於樣本分析)
  根據採樣時間間隔來規律的打斷VM來記錄方法調用棧(Call Stack), 開銷和採樣頻率成比例.

• Trace based profiling(基於完整trace數據分析)
  記錄每一個方法的出入口, 每一個方法執行時都開啓記錄, 不管多小的方法, 所以開銷很大.

2, 使用代碼:

// 在本身想要開始調試的地方start
Debug.startMethodTracing("GithubApp");

// 在合適的地方stop
Debug.stopMethodTracing();複製代碼

注: 以上方法開啓trace的方式至關於"Trace based profiling", 會記錄每一個方法的執行. Android 4.4及以上能夠調用startMethodTracingSampling()來用代碼開啓"Sample based profiling"的trace方式.

2, App啓動流程分析

要想優化App啓動流程, 必先了解其啓動過程.
具體過程請參看這篇譯文: Android Application啓動流程分析.

3, App啓動方式

一般來講, 一個App啓動也會分以下三中不一樣的狀態:

• 冷啓動
  App沒有啓動過或App進程被killed, 系統中不存在該App進程, 此時啓動App即爲冷啓動.
  冷啓動的流程即爲第2節所描述的App啓動流程的全過程, 須要建立App進程, 加載相關資源, 啓動Main Thread, 初始化首屏Activity等.

  在這個過程當中, 屏幕會顯示一個空白的窗口(顏色基於主題), 直至首屏Activity徹底啓動.

  下圖展現了冷啓動的時間線:
  

  

• 熱啓動
  熱啓動意味着你的App進程只是處於後臺, 系統只是將其從後臺帶到前臺, 展現給用戶.

  類同與冷啓動, 在這個過程當中, 屏幕會顯示一個空白的窗口(顏色基於主題), 直至activity渲染完畢.

• 溫啓動
  介於冷啓動和熱啓動之間, 通常來講在如下兩種狀況下發生:

  • 用戶back退出了App, 而後又啓動. App進程可能還在運行, 可是activity須要重建.
  • 用戶退出App後, 系統可能因爲內存緣由將App殺死, 進程和activity都須要重啓, 可是能夠在onCreate中將被動殺死鎖保存的狀態(saved instance state)恢復.

經過三種啓動狀態的相關描述, 能夠看出咱們要作的啓動優化其實就是針對冷啓動. 熱啓動和溫啓動都相對較快.

4, 哪些地方是App快速啓動的敵人

根據冷啓動的時間圖, 能夠看出, 對於App來講, 咱們能夠控制的啓動時間線的點無外乎:

• Application的onCreate
• 首屏Activity的渲染

而咱們如今的App動不動集成了不少第三方服務, 啓動時須要檢查廣告, 註冊狀態等等一系列接口都是在Application的onCreate或是首屏的onCreate中作的.

不少第三方平臺的SDK文檔也都是這麼建議的.

5, 結語

明白了App的啓動原理, 也知道了App啓動過程當中哪些地方容易阻塞, 還知道了用什麼工具來分析每一個方法的執行時間, 那麼接下來就很容易作了.

下一篇將徹底以實例的方式來講明App啓動優化該怎麼分析, 怎麼作.請關注系列文~