Android App 優化之提升你的 App 啟動速度之理論基礎

anly_jun發表於2016-11-16
AndroidAPP優化

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

這篇我們聊聊App啟動的事兒.

1, 欲善其事, 先利其器

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

前文提到了很多工具, 今天我們使用Traceview來分析我們的啟動過程.

1.1 Traceview介紹

Traceview是一個效能分析工具, 主要是分析當前執行緒情況, 各個方法執行時間等. 如下:

Android App 優化之提升你的 App 啟動速度之理論基礎

指標說明:

  • 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:

Android App 優化之提升你的 App 啟動速度之理論基礎

點選開始時會彈出一個選擇trace模式的框, 預設選中"Sample based profiling"即可:

Android App 優化之提升你的 App 啟動速度之理論基礎

  • 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完全啟動.

    下圖展示了冷啟動的時間線:

    Android App 優化之提升你的 App 啟動速度之理論基礎

  • 熱啟動
    熱啟動意味著你的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啟動優化該怎麼分析, 怎麼做.
請關注系列文~

相關文章