<轉>Android App性能評測分析-啓動時間篇

時間 2019-12-09

標籤 android app 性能評測分析啓動時間欄目 Android 简体版

原文原文鏈接

一、前言

隨着項目版本的迭代，App的性能問題會逐漸暴露出來，而好的用戶體驗與性能表現緊密相關，性能問題從應用的啓動優化開始，下面會根據實際app性能測試案例，進行app性能評測之啓動時間的分析和總結。html

二、App啓動方式瞭解

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

冷啓動
當啓動應用時，後臺沒有該應用的進程，這時系統會從新建立一個新的進程分配給該應用，這個啓動方式就是冷啓動，也就是先實例化Applicationandroid

冷啓動的流程即爲App啓動流程的全過程, 須要建立App進程, 加載相關資源, 啓動Main Thread, 初始化首屏Activity等.數據庫

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

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

冷啓動流程.png

熱啓動
當啓動應用時，後臺已有該應用的進程，這時會從已有的進程來啓動Activity（不須要從新建立Application）微信

類同與冷啓動, 在這個過程當中, 屏幕會顯示一個空白的窗口(顏色基於主題), 直至activity渲染完畢.網絡
溫啓動
介於冷啓動和熱啓動之間, 通常來講在如下兩種狀況下發生:架構
- 用戶back退出了App, 而後又啓動. App進程可能還在運行, 可是activity須要重建.app
- 用戶退出App後, 系統可能因爲內存緣由將App殺死, 進程和activity都須要重啓, 可是能夠在onCreate中將被動殺死鎖保存的狀態(saved instance state)恢復.

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

三、性能評測結果案例分析

3.1 XX銀行 APP啓動時間評測結果分析

3.1.1 啓動時間測試結果

統計的時間爲APP的冷啓動時間，4G網絡狀況下，平均冷啓動時間爲14.1S，平均熱啓動時間爲6.7S,無網絡時平均啓動時間爲5.2S。因爲APP的啓動時間耗時遠遠超過行業標準水平3S，當app啓動時，任何一個地方有耗時操做都會拖慢咱們應用的啓動速度，因此針對APP啓動時間作了具體分析

3.1.2評測結果分析

首先來看App從點擊桌面圖標到咱們看到App的主界面整個過程當中通過了哪些步驟：
啓動虛擬機—>啓動AMS —>經過Zygote建立ApplicationProcess進程–>Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量佈局繪製顯示在界面上。

1）初始化Application

【初始化Application】應用程序初始化總共耗費了3.26S，耗時已超過行業APP啓動標準基線時間3S。具體看下耗時詳情分析：
（1）應用Application.attach的時間較長。應用存在多個dex文件，請控制應用方法數量。
（2）onCreate方法耗時長，主要體現BaseApplication建立上。

長耗時方法排名以下:
1.com.pingan.fstandard.framework.base.BaseApplication.onCreate(BaseApplication.java)

com.pingan.fstandard.common.c.a(InitManager.java)

com.pafinancialtech.pafs.kitchendaddy.f.b(PAFFToast.java:83
4.com.pingan.fstandard.HomeApplication.d(HomeApplication.java:51

綜上分析，BaseApplication建立上耗費較長時間，須要開發進行更詳細的分析優化。另外，初始化Application時，也包含了任意門相關等非核心功能的程序，建議啓動時不建立該類程序。

2）初始化Activity

【初始化Activity】耗時也過長，耗時約1s左右
主要耗時的地方是在閃屏界面建立oncreate時com.pingan.fstandard.activity.SplashActivity.onCreate，建議開發優化

3）加載請求及響應

首先來一張流程圖瞭解一下咱們APP首頁加載的一個流程

頁面加載流程.png

冷啓動資源加載.png

【網絡請求及響應】整體來看，首頁加載耗時佔比最多，須要6s左右，對應的網絡消耗時間佔比45%左右。

根據抓包及代碼段分析顯示APP啓動到首頁加載完成是一個預加載和異步加載的過程。
(1) 項目中大部分第三方組件都搶佔先機，在Application主線程初始化。這樣的初始化方式確定是太重的，建議考慮異步初始化三方組件，不阻塞主線程；延遲部分三方組件（好比埋點統計、任意門、ImageLoader的初始化）。
(2) 啓動到首頁加載完成網絡請求密集，請求內容豐富,部分資源重複請求。
請求了相關配置信息、啓動頁廣告、個推、磁貼配置信息、商城理財產品列表，運營廣告Banner、F後端接口，廣告BANNER位、插件信息、任意門、百度地圖SDK（talkingdata、灰度升級）等林林總總加起來就有40+個網絡請求，加載的數據+廣告頁一共有1.7M左右，這說明了咱們的APP首頁設計的內容比較豐富，部分資源重複請求，部份內容須要調外部接口，因此耗時比較長，這是產品設計問題、信息未作緩存處理和部分外部關聯方接口響應慢的緣由致使，建議優化。
（3）非核心功能資源過早請求加載
另外其中相似百度地圖SDK、任意門、微信sdk相關插件只有在生活頁\分享時使用到的非主要業務功能啓動時也加載出來了，建議開發同窗和產品同窗調整APP啓動時網絡請求的加載策略，非核心/主要/高PV的功能相關的API,SDK、插件等沒有必要在啓動時作加載緩存，這是很是耗時且得不償失的。

3.1.3啓動時間優化建議

（1）應用Application.attach的時間較長。應用存在多個dex文件，請控制應用方法數量。
（2）onCreate方法耗時長，主要體現BaseApplication建立上，須要開發進行更詳細的分析優化，建議考慮異步初始化三方組件，不阻塞主線程；延遲或者和產品一塊兒梳理須要的去除的部分三方組件（好比統計、任意門、ImageLoader的初始化）。
（3）com.pingan.fstandard.activity.MainActivity存在過分繪製致使卡頓，首頁UI佈局層次過多，建議開發進一步分析優化
（4）建議產品調整優化app啓動時網絡請求的加載策略，非核心/主要/高PV的功能相關的API,SDK、插件等沒有必要在啓動時作加載緩存
（5）部分資源重複請求，建議信息緩存，經常使用信息只在第一次獲取，以後從緩存中取
（6）建議開發梳理無用但被執行的老代碼，去掉無用但被執行的老代碼

綜上，建議開發童鞋儘快投入作APP啓動時性能改善和優化，以提高行業相比競品的競爭力。

四、App端啓動耗時排查方法及思路

4.1 排查方法：使用Traceview分析

TraceView 是 Android SDK 中內置的1個工具，它能夠加載 trace 文件，用圖形的情勢展示代碼的履行時間、次數及調用棧，便於咱們分析。

（1）使用Android Studio工具DDMS

生成Traceview 進行分析查看具體Trace期間各方法調用關係，調用次數以及耗時比例

ddms.png

（2）使用代碼生成 trace 文件

Debug.startMethodTracing("shixintrace");   
 //開始 trace，保存文件到 "/sdcard/shixintrace.trace"
    // ...
    Debug.stopMethodTracing();    //結束

代碼很簡單，當你調用開始代碼的時候，系統會生產 trace 文件，而且產生追蹤數據，當你調用結束代碼時，會將追蹤數據寫入到 trace 文件中。
下1步使用 adb 命令將 trace 文件導出到電腦：

adb pull /sdcard/shixintrace.trace /tmp

使用代碼生成 trace 方式的好處是容易控制追蹤的開始和結束，缺點就是步驟略微多了一點。

（3）直接使用android studio生成trace文件

Android Studio 內置的 Android Monitor 能夠很方便的生成 trace 文件到電腦。
注意：此方法僅僅適用於下拉代碼到本地生成DEBUG測試包到手機進行調試

monitor1.png

monitor2.png

分析指標：

不該在Application以及Activity的生命週期回調中作任何費時操做，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，不然用戶在桌面點擊你的應用圖標後，將感受到明顯的卡頓。

4.2 開啓嚴苛模式（StrictMode）

檢查是否有主線程作了耗時操做：開啓嚴苛模式（StrictMode）

（1）StrictMode能夠用於捕捉髮生在應用程序主線程中耗時的磁盤、網絡訪問或函數調用，使主線程處理UI和動畫在磁盤讀寫和網絡操做時變得更平滑，避免主線程被阻塞，致使ANR窗口的發生。

下面是啓用StrictMode的實例，能夠在Application的OnCreate中添加，這樣就能在程序啓動的最初一刻進行監控了。

private void setStrictMode() {
        if (Integer.valueOf(Build.VERSION.SDK) > 3) {
            Log.d(LOG_TAG, "Enabling StrictMode policy over Sample application");
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectAll()    // 這裏能夠替換爲.detectDiskReads().detectDiskWrites().detectNetwork()。
                                    // detectAll() 包括了磁盤讀寫和網絡I/O
                    .penaltyLog()   //打印logcat，固然也能夠定位到dropbox，經過文件保存相應的log
                    .penaltyDeath()
                    .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectAll()
                    .penaltyLog()
                    .build());
        }
    }

（2）除了經過日誌查看以外，咱們也能夠在開發者選項中開啓嚴格模式，開啓以後，若是主線程中有執行時間長的操做，屏幕則會閃爍，這是一個更加直接的方法。

4.三、經過抓包工具分析

能夠經過抓包工具Charels、Fiddler等查看網絡請求加載了哪些資源，加載資源的順序、哪些資源重複加載、信息是否緩存

4.四、查看Logcat

經過adb輸出log信息，過濾日誌查看APP啓動時每一個方法的大體耗時。

4.五、啓動時間排查思路

對於App來講, 咱們能夠控制的啓動時間線的點無外乎:

Application的onCreate
首屏Activity的渲染

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

五、啓動時間耗時常見緣由及優化建議

5.一、常見主要問題（持續補充ing）

部分數據庫及IO的操做發生在首屏Activity主線程；
Application中建立了線程池；
啓動時作密集沉重的初始化（Heavy app initialization）；
Multidex的使用，也是拖慢啓動速度的元兇；
UI存在過分繪製；
首屏Activity網絡請求密集；
非核心功能資源過早請求加載
工做線程使用未設置優先級；
信息未緩存，重複獲取一樣信息；
流程問題：例如閃屏圖每次下載，當次使用；
執行無用老代碼；
執行開發階段使用的代碼；
執行重複邏輯；
調用三方SDK裏或者Demo裏的多餘代碼；

5.二、建議：

去掉無用但被執行的老代碼；
去掉開發階段使用但線上被執行的代碼；
去掉重複邏輯執行代碼；
UI渲染優化，去除重複繪製，減小UI重複繪製時間
去掉調用三方SDK裏或者Demo裏的多餘代碼；
信息緩存，經常使用信息只在第一次獲取，以後從緩存中取；
項目是多進程架構，只在主進程執行Application的onCreate()；
根據優先級的劃分，一些初始化工做可否將任務優先級劃分紅3個等級,任務優先級爲2，3的，經過懶加載的方式在首頁渲染完成後進行加載
避免I/O操做、反序列化、網絡操做、佈局嵌套等。

參考文獻:
學習地址：
https://www.cnblogs.com/sunzn/p/3192231.html
http://www.wfuyu.com/technology/27625.html
http://blog.csdn.net/qq_16131393/article/details/51172488

做者：蕭竹出處：https://www.jianshu.com/u/88caeb7696f5 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接。