1, 欲善其事, 先利其器

論語(yǔ)有云: 工欲善其事，必先利其器. 要想提升App的啟動(dòng)速度, 我們需要先找到拖后腿的點(diǎn), 要想找到這些點(diǎn), 我們就需要借助我們的工具了。

前文提到了很多工具, 今天我們使用Traceview來(lái)分析我們的啟動(dòng)過(guò)程。

1.1 Traceview介紹

Traceview是一個(gè)性能分析工具, 主要是分析當(dāng)前線程情況, 各個(gè)方法執(zhí)行時(shí)間等。如下：

指標(biāo)說(shuō)明:

Incl(Inclusive) Cpu Time

方法本身和其調(diào)用的所有子方法占用CPU時(shí)間.

Excl(Exclusive) Cpu Time

方法本身占用CPU時(shí)間。

Incl Real Time

方法(包含子方法)開(kāi)始到結(jié)束用時(shí)。

Excl Real Time

方法本身開(kāi)始到結(jié)束用時(shí)。

Call + Recursion Calls/Total

方法被調(diào)用次數(shù) + 方法被遞歸調(diào)用次數(shù)。

Cpu Time/Call

方法調(diào)用一次占用CPU時(shí)間。

Real Time/Call

方法調(diào)用一次實(shí)際執(zhí)行時(shí)間。

一般來(lái)說(shuō), 我們使用Real Time/Call排序來(lái)找出耗時(shí)多的方法

有必要解釋下CPU Time和Real Time:

CPU Time 方法實(shí)際執(zhí)行時(shí)間(不包括io等待時(shí)間)Real Time 方法開(kāi)始結(jié)束時(shí)間差(包括等待時(shí)間)參考:http://stackoverflow.com/questions/15760447/what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re/17902682#17902682

1.2 Traceview使用

有兩種方式來(lái)使用Traceview:

a, 通過(guò)DDMS:

點(diǎn)擊開(kāi)始時(shí)會(huì)彈出一個(gè)選擇trace模式的框, 默認(rèn)選中”Sample based profiling”即可:

Sample based profiling(基于樣本分析)

根據(jù)采樣時(shí)間間隔來(lái)規(guī)律的打斷VM來(lái)記錄方法調(diào)用棧(Call Stack), 開(kāi)銷和采樣頻率成比例。

Trace based profiling(基于完整trace數(shù)據(jù)分析)

記錄每個(gè)方法的出入口, 每個(gè)方法執(zhí)行時(shí)都開(kāi)啟記錄, 無(wú)論多小的方法, 因此開(kāi)銷很大。

b, 使用代碼:

//在自己想要開(kāi)始調(diào)試的地方startDebug.startMethodTracing("GithubApp");//在合適的地方stopDebug.stopMethodTracing();注: 以上方法開(kāi)啟trace的方式相當(dāng)于”Trace based profiling”, 會(huì)記錄每個(gè)方法的執(zhí)行. Android 4.4及以上可以調(diào)用startMethodTracingSampling()來(lái)用代碼開(kāi)啟”Sample based profiling”的trace方式。

2, App啟動(dòng)流程分析

3, App啟動(dòng)方式

要想優(yōu)化App啟動(dòng)流程, 必先了解其啟動(dòng)過(guò)程。具體過(guò)程請(qǐng)參看這篇譯文: Android Application啟動(dòng)流程分析。

通常來(lái)說(shuō), 一個(gè)App啟動(dòng)也會(huì)分如下三中不同的狀態(tài):

冷啟動(dòng)

App沒(méi)有啟動(dòng)過(guò)或App進(jìn)程被killed, 系統(tǒng)中不存在該App進(jìn)程, 此時(shí)啟動(dòng)App即為冷啟動(dòng)。冷啟動(dòng)的流程即為第2節(jié)所描述的App啟動(dòng)流程的全過(guò)程, 需要?jiǎng)?chuàng)建App進(jìn)程, 加載相關(guān)資源, 啟動(dòng)Main Thread, 初始化首屏Activity等。在這個(gè)過(guò)程中, 屏幕會(huì)顯示一個(gè)空白的窗口(顏色基于主題), 直至首屏Activity完全啟動(dòng)。下圖展示了冷啟動(dòng)的時(shí)間線:

熱啟動(dòng)

溫啟動(dòng)

熱啟動(dòng)意味著你的App進(jìn)程只是處于后臺(tái), 系統(tǒng)只是將其從后臺(tái)帶到前臺(tái), 展示給用戶。類同與冷啟動(dòng), 在這個(gè)過(guò)程中, 屏幕會(huì)顯示一個(gè)空白的窗口(顏色基于主題), 直至activity渲染完畢。

介于冷啟動(dòng)和熱啟動(dòng)之間, 一般來(lái)說(shuō)在以下兩種情況下發(fā)生:

用戶back退出了App, 然后又啟動(dòng). App進(jìn)程可能還在運(yùn)行, 但是activity需要重建。用戶退出App后, 系統(tǒng)可能由于內(nèi)存原因?qū)pp殺死, 進(jìn)程和activity都需要重啟, 但是可以在onCreate中將被動(dòng)殺死鎖保存的狀態(tài)(saved instance state)恢復(fù)。通過(guò)三種啟動(dòng)狀態(tài)的相關(guān)描述, 可以看出我們要做的啟動(dòng)優(yōu)化其實(shí)就是針對(duì)冷啟動(dòng). 熱啟動(dòng)和溫啟動(dòng)都相對(duì)較快。

4, 哪些地方是App快速啟動(dòng)的敵人

根據(jù)冷啟動(dòng)的時(shí)間圖, 可以看出, 對(duì)于App來(lái)說(shuō), 我們可以控制的啟動(dòng)時(shí)間線的點(diǎn)無(wú)外乎:

Application的onCreate首屏Activity的渲染而我們現(xiàn)在的App動(dòng)不動(dòng)集成了很多第三方服務(wù), 啟動(dòng)時(shí)需要檢查廣告, 注冊(cè)狀態(tài)等等一系列接口都是在Application的onCreate或是首屏的onCreate中做的。

5, 結(jié)語(yǔ)

很多第三方平臺(tái)的SDK文檔也都是這么建議的。

明白了App的啟動(dòng)原理, 也知道了App啟動(dòng)過(guò)程中哪些地方容易阻塞, 還知道了用什么工具來(lái)分析每個(gè)方法的執(zhí)行時(shí)間, 那么接下來(lái)就很容易做了。

關(guān)鍵詞： App啟動(dòng)速度 理論基礎(chǔ)