這篇文章主要為大家展示了“如何提升App啟動速度”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“如何提升App啟動速度”這篇文章吧。

公司主營業(yè)務(wù)：成都做網(wǎng)站、成都網(wǎng)站設(shè)計、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出樺甸免費做網(wǎng)站回饋大家。

1, 欲善其事, 先利其器

使用Traceview來分析我們的啟動過程。

1.1 Traceview介紹

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

指標(biāo)說明:

Incl(Inclusive) Cpu Time

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

Excl(Exclusive) Cpu Time

方法本身占用CPU時間。

Incl Real Time

方法(包含子方法)開始到結(jié)束用時。

Excl Real Time

方法本身開始到結(jié)束用時。

Call + Recursion Calls/Total

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

Cpu Time/Call

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

Real Time/Call

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

一般來說, 我們使用Real Time/Call排序來找出耗時多的方法

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

• CPU Time 方法實際執(zhí)行時間(不包括io等待時間)

• Real Time 方法開始結(jié)束時間差(包括等待時間)

參考: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使用

有兩種方式來使用Traceview:

a, 通過DDMS:

點擊開始時會彈出一個選擇trace模式的框, 默認(rèn)選中”Sample based profiling”即可:

Sample based profiling(基于樣本分析)

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

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

記錄每個方法的出入口, 每個方法執(zhí)行時都開啟記錄, 無論多小的方法, 因此開銷很大。

b, 使用代碼:

// 在自己想要開始調(diào)試的地方start Debug.startMethodTracing("GithubApp"); // 在合適的地方stop Debug.stopMethodTracing();

注: 以上方法開啟trace的方式相當(dāng)于”Trace based profiling”, 會記錄每個方法的執(zhí)行. Android  4.4及以上可以調(diào)用startMethodTracingSampling()來用代碼開啟”Sample based  profiling”的trace方式。

2, App啟動流程分析

• 要想優(yōu)化App啟動流程, 必先了解其啟動過程。

• 具體過程請參看這篇譯文: Android Application啟動流程分析。

3, App啟動方式

通常來說, 一個App啟動也會分如下三中不同的狀態(tài):

冷啟動

• App沒有啟動過或App進(jìn)程被killed, 系統(tǒng)中不存在該App進(jìn)程, 此時啟動App即為冷啟動。

• 冷啟動的流程即為第2節(jié)所描述的App啟動流程的全過程, 需要創(chuàng)建App進(jìn)程, 加載相關(guān)資源, 啟動Main Thread,  初始化首屏Activity等。

• 在這個過程中, 屏幕會顯示一個空白的窗口(顏色基于主題), 直至首屏Activity完全啟動。

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

熱啟動

• 熱啟動意味著你的App進(jìn)程只是處于后臺, 系統(tǒng)只是將其從后臺帶到前臺, 展示給用戶。

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

溫啟動

介于冷啟動和熱啟動之間, 一般來說在以下兩種情況下發(fā)生:

• 用戶back退出了App, 然后又啟動. App進(jìn)程可能還在運行, 但是activity需要重建。

• 用戶退出App后, 系統(tǒng)可能由于內(nèi)存原因?qū)pp殺死, 進(jìn)程和activity都需要重啟, 但是可以在onCreate中將被動殺死鎖保存的狀態(tài)(saved  instance state)恢復(fù)。

通過三種啟動狀態(tài)的相關(guān)描述, 可以看出我們要做的啟動優(yōu)化其實就是針對冷啟動. 熱啟動和溫啟動都相對較快。

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

根據(jù)冷啟動的時間圖, 可以看出, 對于App來說, 我們可以控制的啟動時間線的點無外乎:

• Application的onCreate

• 首屏Activity的渲染

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

• 很多第三方平臺的SDK文檔也都是這么建議的。

以上是“如何提升App啟動速度”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！