① 分享：android屏幕刷新機制下頁面性能統計及優化
一、Android屏幕刷指首余新機制芹拿
1、三級緩存
2、surfaceflinger surface
二、頁面性能統計實現
指標
1、首次內唯滾容渲染時間（FCP）
2、首次有效渲染時間（FMP）
3、可交互時間（TTI）
4、應用冷啟動時間
5、每幀處理時間
三、app應該如何去優化
② 如何檢測App啟動時間
對於app的性能測試，啟動時間是個重要指標，啟動時間分為兩種情況，一種是冷啟動時間（通常是系統重啟，即在啟動前沒有該app進程的情況），另一種是熱啟動，即app從被切換到前台（點back退出後再點擊圖標啟動）。
從Android4.4（API 19）開始，可以從logcat獲取activity的啟動信息，如下我用應用寶做實驗，可以看到如下的輸出，從這里我們可以看到應用的這個activity啟動用了639ms。
12-13 00:10:41.331 855-957/? I/ActivityManager: [AppLaunch] Displayed Displayed com.tencent.android.qqdownloader/com.tencent.assistantv2.activity.MainActivity: +639ms (total +751ms)
12-13 00:10:41.331 855-957/? D/ActivityManager: AP_PROF:AppLaunch_LaunchTime:com.tencent.android.qqdownloader/com.tencent.assistantv2.activity.MainActivity:639:50307447
這個log信息會在activity首次被繪制時輸出，也就是如果activity棧里有這個activity，再啟動不會輸出該信息，典型的場景是通過recent task列表切換到其他activity再立即切換回來時。
log中的時間包括系統從開始處理啟動activity的時間到完成運行layout和draw函數的時間，不包括點擊icon到系統接收到消息的時間。顯然，這個時間也不包括啟動中非同步UI繪制的時間。但是我們在測試中關注的其實是用戶體驗的啟動時間，那麼上面log中的時間就不能滿足我們的需求了。
不過還好，既然是用戶體驗我們可以用更直觀的方式，使用screenrecord進行屏幕錄制然後分析視頻。使用如下命令錄制視頻。
adb shell screenrecord –bugreport /sdcard/launch.mp4
–bugreport參數會使視頻輸出一些時間信息和幀信息便於我們分析啟動時間。activity啟動後，使用ctrl+c結束視頻錄制，使用
adb shell pull /sdcard/launch.mp4 /Users/xxx/Downloads/launch.mp4
導出視頻到電腦，使用可以按幀播放的視頻軟體打開（mac上quicktime就可以，win下可以用kmplayer），並按幀播放。
按幀播放視頻，視頻左上角會顯示每一幀的時間（精確到ms）和幀數。在視頻中會看到icon會變暗然後高亮，高亮時就是系統開始處理本次icon點擊事件了。可以把這里作為點擊時間，然後根據體驗要求，看到app啟動頁完全繪制完作為終止時間，這個時間減去點擊時間就是app的啟動時間。
在進行app啟動時間測試時，系統中運行的其他app會對啟動時間有干擾，如果需要進行版本對比及競品對比，最好要盡量保持環境一致，並反復執行多次取平均值。最後，不要忘了分別測試冷啟動和熱啟動哦~
③ Android性能優化第（八）篇---App啟動速度優化之耗時檢測處理
應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash界面，但是這並沒有從根本上解決這個問題。那麼如何從根本上解決這個問題或者做到一定程度的緩解？
1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會首先會創建一個新的進程分配給該應用，這種啟動方式就是冷啟動。
2、熱啟動：當啟動應用時，後台已有該應用的進程，比如按下home鍵，這種在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這種啟動方式叫熱啟動。
3、溫啟動 ：當啟動應用時，後台已有該應用的進程，但是啟動的入口Activity被幹掉了，比如按了back鍵，應用雖然退出了，但是該應用的進程是依然會保留在後台，這種啟動方式叫溫啟動。
adb shell am start -W [PackageName]/[PackageName.MainActivity]
執行成功後將返回三個測量到的時間：
這裡面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的調用耗時，ThisTime 是指調用過程中最後一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 調用結束。TotalTime 是指調用過程中第一個 Activity 的啟動時間到最後一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等於 ThisTime。
總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。
從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什麼，將這個過程細分一下，會有下面的時間點需要注意。
Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量、布局、繪制顯示在界面上。
因為上面這些階段全部都是在主線程中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以我們不應在Application以及Activity的生命周期回調中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，否則用戶在桌面點擊你的應用圖標後，將感覺到明顯的卡頓。但是有些 不得以的任務 又必須在UI顯示之前執行。所以我們要將 任務 劃分優先順序。
對於首頁渲染完成後，開始載入，或者延遲載入，延遲載入的目的就是界面先顯示出來，然後載入，但是你覺得要延遲多久呢？在 Android 的高端機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那麼快了,而且現在應用為了兼容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是很明顯的。延遲載入有一種方式。
極力推薦用第二種，在窗口完成以後進行載入，這裡面的run方法是在onResume之後運行的。關於這種懶載入機制，參考 Android應用啟動優化:一種DelayLoad的實現和原理(上篇) ，給出了詳細的解釋。
通過上面我們知道一種懶載入機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢後載入。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優化第（六）篇---TraceView 分析圖怎麼看？
比如在首頁的onCreate中我們進行了用戶啟動上報，這個進行懶載入是不是分分鍾減少139毫秒呢？
在比如在Application裡面用到了GSON，將String轉化成json,我將這個移動到懶載入裡面，是不是又減少了100毫秒呢？
在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中載入幹嘛？
此處我們這里舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測保存一個boolean變數耗時120+毫秒以上。
利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。
五、優化思路總結
1、UI渲染優化，去除重復繪制，減少UI重復繪制時間，打開設置中的GPU過度繪制開關，各界面過度繪制不應超過2.5x；也就是打開此調試開關後，界面整體呈現淺色，特別復雜的界面，紅色區域也不應該超過全屏幕的四分之一；
2、根據優先順序的劃分，KoMobileApplication的一些初始化工作能否將任務優先順序劃分成3,在首頁渲染完成後進行載入，比如：PaySDKManager。
3、主線程中的所有SharedPreference能否在非UI線程中進行，SharedPreferences的apply函數需要注意，因為Commit函數會阻塞IO，這個函數雖然執行很快，但是系統會有另外一個線程來負責寫操作，當apply頻率高的時候，該線程就會比較佔用CPU資源。類似的還有統計埋點等，在主線程埋點但非同步線程提交，頻率高的情況也會出現這樣的問題。
4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。
5、對於首次啟動的黑屏問題，對於「黑屏」是否可以設計一個.9圖片替換掉，間接減少用戶等待時間。
6、對於網路錯誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。
7、任務優先順序為2，3的，通過下面這種方式進行懶載入的方式
8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。後面有空專門寫一篇Multidex。
相關鏈接：
Android應用啟動優化:一種DelayLoad的實現和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html
Android性能優化之加快應用啟動速度http://www.open-open.com/lib/view/open1452821612355.html
手機淘寶性能優化全記錄http://www.open-open.com/lib/view/open1452488209370.html
Android客戶端性能優化（魅族資深工程師毫無保留奉獻）http://blog.tingyun.com/web/article/detail/155#rd
Please accept mybest wishes for your happiness and success !
④ android APP冷啟動時間過長，怎麼解決
這個可不好說了，具體關閉程序是由攔銷Framework決定的。 一般按照如下規律。 1、內存緊張、先關閉沒有SERVICE、ACTIVITY堆棧時間最長的。 2、內存緊張、有SERVICE，不活動時間最長的。佔用內存比較大的。 3、內存緊張、有大內存程序切換到前台，釋放內存依舊不夠的。依次殺死不活動時間最長的。 4、內存緊張、有大內存程序切換到前台叢輪，釋放內存依舊不夠的。殺死帶有android:persistent="true"標記的。（備注Phone模塊有此標記，所以最難殺） 這個簡鄭游是我的經驗。
⑤ Android啟動優化概述
Android啟動應用, 按 官方說法 分為冷啟動, 溫啟動和熱啟動.
具體的定義可以看官方文檔, 簡單地說
一般我們只需要關注冷啟動即可.
要想啟動快, 硬體性能必然有影響, 在硬體一定的前提下, 我們要盡量 降低啟動應用時CPU的負載 , 讓CPU有更多的算力投入到啟動流程中:
在做好一些基本原則後, 接著看具體的流程優化點
在應用進程創建後, 首先必然是載入類, 此時一些靜態變數就會初始化了, 因此我們應該
類載入完畢後就是創建 Application 實例了, 因此我們應該
之後會先創建 ContentProvider 和執行 ContentProvider.onCreate() , 因此我們應該
跟接著就會執行 Application.onCreate() 等方法, 因此我們應該
接著就進入 Activity 環節.
同樣第一步會是創建實例, 因此我們應該
在 Activity 進程生命周期後, 第一步就是渲染(inflate)布局, 我們應該
在應用啟動的瞬間, 系統服納虧務會先展示一個空白窗口哪茄殲, 等待應用第一幀繪制完畢後, 再從該窗口切換到應用, 如果啟動耗時較長, 就會明顯看到白屏, 對於這一點, 常見的操作有
可以使用IdleHandler, 在主線程空閑時再執行某些不重要的操作
實際上非同步初始化只是不阻塞主線程, 但是子線程一樣會佔用CPU資源, 讓主線程的執行時間變少, 所以不應該盲目地將所有工作放到子線程.
優化做到最後, 就是在系統流程上做文章了
原理是將啟動時載入的類放到主dex，提升了這些類的內聚，讓更多的類滿足pre-verify的條件，在安裝時就做了校驗和優化，以減少首次載入的耗時，從而優化冷啟動耗時。
Redex 初探與 Interdex：Andorid 冷啟動優化
應用啟動過程中會從apk壓縮包中讀取文件, 該優化的原理是利用Linux中的Pagecache機制, 讓啟動過程會用到的文件盡可能進入緩存中, 減少磁碟IO次數
支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動性能
在Dalvik VM(Android5.0以前)載入類的時候會有一個類校驗過程, 它需要校驗方李沖法的每一個指令, 是一個比較耗時的過程, 可以通過Hook去掉類載入過程中的類驗證過程. 不過對於ART(Android5.0之後)來說, 這個過程在安裝時已經做了, 所以用處不大.
不進入冷啟動, 就不用優化了~
這個Android Studio自帶的工具, 可以看到啟動過程中詳細的方法執行流程, 但是採集數據本身會影響方法執行, 所以不能准確判斷每個方法的耗時, 但是仍可以判斷哪個方法相對來說耗時.
這個工具的好處是可以自定義事件, 可以指定需要採集的數據集, 可以看到線程間的狀態等.
啟動優化的一個關鍵點在於定義啟動結束的點, 以及如何測量啟動時間.
在Android4.4以上, 系統進程會提供一個類似 ActivityManager: Displayed ***: +3s534ms 的日誌, 表示從啟動進程到首次繪制完畢所用的時間.
應用可以在任何時候調用該方法, 觸發系統列印類似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日誌
應用可以通過 ViewTreeObserver 來監聽繪制前回調來判斷第一幀的繪制時機, 或者直接在控制項樹的末尾加一個簡單的View, 它 onDraw 調用時即表示頁面(差不多)繪制完畢.
應用啟動過程可以參考 Android Vitals Series' Articles 系列文章
⑥ android APP冷啟動時間過長，怎麼解決
找到在啟動的時候做的耗時操作，該去局告掉的去掉，該延時載入的延時載入
其他幾個思路，
1、Application中不要做任何業務相關的操作
2、有些耗時的操作可以桐橘明在真正使用到的時候去創建或者執行
3、添加過渡頁，顯得更自然些，大伍鏈多數App都是這么做的
4、首頁的界面可以優化下，不要過度繪制
⑦ Android 5.0、6.0、7.0、8.0、9.0、10.0特性
1.扁平化，設計理念（Material Design）；
2.新設計風格（Material Design材料設計，參考文檔： https://materialdoc.cn/ ）；
3.全新的通知中心設計，優先顯示對用戶來說比較重要的信息，把不太緊要的隱藏起來，向下滑動就可以查看所有通知。通知功能的另一個炫酷新功能是在鎖屏的時候就可以直接查看通知消息，還可以在鎖屏下直接回復或進入應用。另外在操作手機的過程中有電話進入，也不會進行全畫面切換，而是同樣以彈出的當時告知用戶；
4.開始支持多種設備（智能手機、平板電腦、筆記本電腦、智能電視、汽車等）；
5.性能上放棄Dalvik虛擬機，改用ART模式，實現跨平台編譯，程序載入時間大幅度提升，未來Android智能手機支持4GB以上的內存；
6.增加了Battery Saver模式進行省電處理；
7.全新的最近應用程序；
8.改進安全性，當用戶的藍牙耳機連接到手機或平板電腦時，設備可以基於當前的位置和用戶的聲音自動解鎖，繞過鎖屏界面；
9.不同數據獨立保存；
10.改進搜索
11.支持藍牙4.1、USB audio、多人分享等其他特性。
1.為用戶提供了兩套相互獨立的解決方案，即數據存儲方案（1.一套存儲工作資料，2.存儲個人信息）；
2.Android M系統層面加入了指紋識別（廠商自行開發的改為原生的，提升了指紋支付安全性）；
3.APP關聯（APP links）,在微信打開京東鏈接，會提醒跳轉到京東APP;
4.Android pay，Android支付唯一標准，簡潔、安全、可選性；
5..運行時許可權（危險許可權和正常許可權）；
6.電源管理，APP standby（應用待機），Doze（瞌睡），Exemptions(豁免)，生命周期等模式來加強電源管理。
提升性能、生產效率和安全性，無縫更新
1.對文件數據加密，更加安全；旦悶
2.添加了分屏多任務；
3.全新下拉快捷開關頁，例如WiFi的開關；
4.重新設計了通知，消息歸攏，通知消息快捷回復，如視頻全屏下，屏幕頂部出現兩個按鈕（接聽、掛掉）；
5.夜間模式；
6.流量保護；
7.全新設置樣式；
8.改進Doze休眠機制；
9.系統級電話黑名單功能；
10.菜單鍵快速應用切換；
一、Fluid Experiences概念，提高生產力，日常使用中可以使用多個任務工具
1.畫中畫，懸浮小窗口，與分屏不相同；
2.TensorFlow Lite,谷歌將人工智慧應用在應用程序中的嘗試，並進一步將機器學習的優勢擴展到Android生態系統;
3.Notification Dots,桌面程序未讀消缺陵息小圖標提示;
4.Smart Text Seletion(智能文本選擇)，導航應用，電話號碼，郵件等應用；
5.auto-fill（自動填寫），例如記住密碼；
6.自適應圖標（adapter icons）模扮彎;
7.固定快捷方式和小部件（pinning shortcuts）,長按應用桌面圖標彈出提示；
二、Vitals,新概念，對於設備電池續航、安全、應用啟動時間和穩定性的優化
1.Google Play Project，Android應用的病毒掃描程序;
2.系統、應用啟動程序加速，為原來系統的一半時間；
3.Play Console Dashbard，新的開發人員工具，可提供應用在設備上使用情況分析，開發人員 可以深入了解如何調整應用程序，以減少電池消耗並提高在各個設備上的運行速度；
4.其他特性：字體、WiFi感知
1.adaptive battery自適應電池，如果在Android 6中使用了休眠模式，它會讓所有的程序都休眠，而自適應電池功能是它的一個進階版，默認情況下是啟用的；
2.Actions和Slices，為你的手機提供一些建議，如插入耳機會顯示最近播放列表或者建議你打個電話；
3.切片，跳出執行信息對話中列出的操作；
4.shush,屏幕朝下時進入完全勿擾模式；
5,通知欄的多種通知；
6.通過WiFi rtt 進行室內導航；
7.改進dnd模式；
8.所有應用都是用HTTPS；
9.後台程序無法訪問相機和麥克風；
10.wind down，夜間模式；
11.Android Dashboard，應用使用時間提醒；
12.網路還有神經網路，節省流量和網速優化；
13.多攝像頭的更多畫面；
14.全面屏支持。
1.可折疊設備（更改了resizeableActivity) 清單屬性的工作方式）；
2.5G網路，提速降延遲；
3.通知中的智能回復（提供建議和操作，並支持自定義回復和操作；使用 setAllowGeneratedReplies()和()即可精確選擇停用）；
4.系統級深色主題；
5.全手勢導航；
6.新的設備面板；
7.共享快捷方式；
8.保護用戶隱私，給予用戶更多許可權控制權；
9.安全性等。
⑧ 怎麼計算android app啟動時間
事實上 Android 中一個 App 的啟動時間可以准確計算的.但是要分場景.也就是說要分開游戲和應用. 大家都知道,在Android中,游戲開發和應用開發是兩碼事.所以我們需要分開來說.
1.1 應用啟動
我們平時在寫應用的時候,一般會指定一個 mainActivity ,用戶在桌面上點擊這個 Activity 的時候,系統會直接起這個 Activity. 我們知道 Activity 在啟動的時候會走 onCreate/onStart/onResume .這幾個回調函數.
許多書里講過,當執行完 onResume 函數之後,應用就顯示出來了…其實這是一種不準確的說法,因為從系統層面來看,一個 Activity 走完 onCreate/onStart/onResume 這幾個生命周期之後,只是完成了應用自身的一些配置,比如 window 的一些屬性的設置/ View 樹的建立(只是建立,並沒有顯示,也就是說只是調用了 inflate 而已) . 後面 ViewRootImpl 還會調用兩次performTraversals ,初始化 Egl 以及 measure/layout/draw. 等.所以我們定義一個 Android 應用的啟動時間, 肯定不能在 Activity 的回調函數上下手.而是以用戶在手機屏幕上看到你在 onCreate 的 setContentView 中設置的 layout 完全顯示為准,也就是我們常說的應用第一幀.
上面扯得有點遠,不感興趣的話可以不看,下面直接說方法.題主說的 adb shell am start -w packagename/activity,是可以完全應用的啟動時間的.不過也要分場景.
1.2 應用第一次啟動
也就是我們常說的冷啟動,這時候你的應用程序的進程是沒有創建的. 這也是大部分應用的使用場景.用戶在桌面上點擊你應用的 icon 之後,首先要創建進程,然後才啟動 MainActivity.這時候adb shell am start -w packagename/MainActivity 返回的結果,就是標準的應用程序的啟動時間（注意 Android 5.0 之前的手機是沒有 WaitTime 這個值的）:
➜ adb shell am start -W com.meizu.media.painter/com.meizu.media.painter.PainterMainActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.meizu.media.painter/.PainterMainActivity }
Status: ok
Activity: com.meizu.media.painter/.PainterMainActivity
ThisTime: 355
TotalTime: 355
WaitTime: 365
Complete
總共返回了三個結果,我們以 WaitTime 為准.
關於ThisTime/TotalTime/WaitTime的區別,下面是其解釋：
「adb shell am start -W 」的實現在 frameworks\base\cmds\am\src\com\android\commands\am\Am.java 文件中。其實就是跨Binder調用ActivityManagerService.startActivityAndWait() 介面（後面將ActivityManagerService簡稱為AMS），這個介面返回的結果包含上面列印的ThisTime、TotalTime時間.
startTime記錄的剛准備調用startActivityAndWait()的時間點
endTime記錄的是startActivityAndWait()函數調用返回的時間點
WaitTime = startActivityAndWait()調用耗時。
ThisTime、TotalTime 的計算在 frameworks\base\services\core\java\com\android\server\am\ActivityRecord.java 文件的 reportLaunchTimeLocked() 函數中。
我們來解釋下代碼里curTime、displayStartTime、mLaunchStartTime三個時間變數.
curTime表示該函數調用的時間點.
displayStartTime表示一連串啟動Activity中的最後一個Activity的啟動時間點.
mLaunchStartTime表示一連串啟動Activity中第一個Activity的啟動時間點.
正常情況下點擊桌面圖標只啟動一個有界面的 Activity，此時 displayStartTime 與mLaunchStartTime 便指向同一時間點，此時 ThisTime=TotalTime。另一種情況是點擊桌面圖標應用會先啟動一個無界面的 Activity 做邏輯處理，接著又啟動一個有界面的Activity，在這種啟動一連串 Activity 的情況下（知乎的啟動就是屬於這種情況），displayStartTime 便指向最後一個 Activity 的開始啟動時間點，mLaunchStartTime 指向第一個無界面Activity的開始啟動時間點，此時 ThisTime！=TotalTime。
看到這里應該清楚 ThisTime、TotalTime、WaitTime 三個時間的關系了吧。WaitTime 就是總的耗時，包括前一個應用 Activity pause 的時間和新應用啟動的時間；ThisTime 表示一連串啟動 Activity 的最後一個 Activity 的啟動耗時；TotalTime 表示新應用啟動的耗時，包括新進程的啟動和 Activity 的啟動，但不包括前一個應用 Activity pause 的耗時。也就是說，開發者一般只要關心 TotalTime 即可，這個時間才是自己應用真正啟動的耗時。
Event log中 TAG=am_activity_launch_time 中的兩個值分表表示 ThisTime、TotalTime，跟通過 「adb shell am start -W 」 得到的值是一致的。
最後再說下系統根據什麼來判斷應用啟動結束。我們知道應用啟動包括進程啟動、走 Activity生命周期 onCreate/onResume 等。在第一次 onResume 時添加窗口到WMS中，然後measure/layout/draw，窗口繪制完成後通知 WMS，WMS 在合適的時機控制界面開始顯示(夾雜了界面切換動畫邏輯)。記住是窗口界面顯示出來後，WMS 才調用reportLaunchTimeLocked() 通知 AMS Activity 啟動完成。
最後總結一下，如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。
1.2 應用非第一次啟動
如果是你按Back鍵，並沒有將應用進程殺掉的話，那麼執行上述命令就會快一些，因為不用創建進程了，只需要啟動一個Activity即可。這也就是我們說的應用熱啟動。
2 游戲啟動場景
游戲啟動的話，就不適用用命令行的方法來啟動了，因為從用戶點擊桌面圖標到登錄界面，既有系統的部分也有游戲自己的部分。
2.1 系統部分
游戲也有一個Activity，所以啟動的時候還是會去啟動這個Activity，所以系統啟動部分也就是用戶點擊桌面桌面響應到這個Activity啟動。
2.2 游戲部分
一般游戲的主Activity啟動後，還會做一些比較耗時的事情，這時候你看到的界面是不能操作的，比如：載入游戲數據、聯網更新數據、讀取和更新配置文件、游戲引擎初始化等操作。從游戲開發的角度來看，到了真正用戶能操作的界面才算是一個游戲真正載入完成的時間。那麼這個時間，就得使用Log來記錄了，因為載入游戲數據、聯網更新數據、讀取和更新配置文件、游戲引擎初始化這些操作，都是游戲自己的邏輯，與系統無關，所以得由游戲自己定義載入完成的點。
對於游戲的啟動時間，我們更傾向於計算從 點擊桌面圖標 到 用戶可以與游戲進行交互 這個時間段作為一個游戲的啟動時間。
3 總結
計算機最讓人著迷的一點就是其准確性，1+1永遠等於2，啟動耗時多久就是多久，每一次可能不一樣，但每一次的時間都是這一次的准確時間。
不過每個公司由於對應用的定位不同，所以對應用啟動的要求也不一樣。比如有的做 ROM 的公司，其內置應用的啟動時間一定是要非常快的，這樣給用戶的第一感覺就是快、流暢；互聯網公司的 App 則不是很關心啟動速度，大部分互聯網公司的應用都有一個啟動頁，用來展示廣告或者功能介紹之類的，然後才會進入到主界面。需求不一樣，這么做也無可厚非，不過從消費者的角度來看，越早見到主界面當然越好。
所以在做一個 Android App 的時候，一定要記得將應用的啟動時間作為一個性能指標，畢竟
天下武功，唯快不破！
⑨ Android App啟動時間測試方法總結
查看當前界面Activity的方法：
1）運行命令：adb shell mpsys window | findstr "mCurrentFocus"
mCurrentFocus=Window{227cb04 u0 com.oppo.music/com.oppo.music.MainListActivity}
從結果中可知：
當前應用包名：com.oppo.music
當前界面Activity：com.oppo.music.MainListActivity
2）查看應用的PID
adb shell ps | findstr 「com.oppo.music」，找到PID對應的列
1、「高速攝像機或Iphone慢動作」查看應用的啟動時間
1）使用高速相機或Iphone的慢動作（240ps）錄制應用的啟動視頻
2）使用QucikTime的幀分析功能，確定好起始幀（手指按下抬起時）和結束幀（應用完全顯示）
3）根據幀數計算啟動時間：=1000*幀數量/240
備註：最接近真實用戶使用場景，但是操作復雜，成本高
2、「ActivityManager」查看應用的啟動時間
備註：系統main log中也會鍵世空有對應的顯示（或adb shell logcat -b main | findstr ActivityManager）更佳
1）運行結果：
04-19 15:13:25.919 1181 1216 I ActivityManager: Displayed com.oppo.music/.MainListActivity: +677ms
04-19 15:13:33.556 1181 1216 I ActivityManager: Displayed com.oppo.music/.MainListActivity: +660ms
677ms和660ms就是music應用的啟動時間
3、「WaitTime」查看應用的啟動時間
測試方法：adb shell am start -W –S packagename/MainActivity命令
1）結果時間說明
ThisTime：一連串啟動Activity的最後一個Activity開始算起始時間
TotalTime：一連串啟動Activity的第一個Activity開始算起始時間
WaitTime：總的耗時，但是包括前一個應用 Activity pause 的時間和新應用啟動的時間
說明：例如有的應用啟動Activity的時候，會先顯示一個白色的Activity，然後在顯示正常Activity，這個時候TotalTime就是從第一個Activity啟動作為起始時間，如果只有稿瞎一個Activity則ThisTime和TotalTime相等
總結：
如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime
4、「am_activity_launch_time」查看應用啟返陸動時間
測試方法：
1）開啟系統的moblie log，例如mtk的moblie log，然後啟動應用（或者adb shell logcat -b events | findstr am_activity_launch_time）
2）從moblie log中找到類似如下的event log：events_log_3__2019_0418_152200
3）搜索關鍵詞：「am_activity_launch_time」，然後匹配對應的包名，如下：
04-18 15:21:28.365484 1181 1216 I am_activity_launch_time: [0,73476478,com.oppo.music/.MainListActivity,668,668]
04-18 15:21:37.295923 1181 1216 I am_activity_launch_time: [0,231925826,com.oppo.music/.MainListActivity,680,680]
4）應用的啟動時間為668ms、680ms
5、Systrace查看應用的啟動時間
1）抓取應用啟動的trace文件
a、開發給的python腳本抓取，需要安裝對應的python
b、打開android自帶的monitor工具抓取，需要安裝java環境和android sdk包
2）chrome瀏覽器輸入chrome://tracing/，然後load對應的trace文件
3）搜索iq，如果能搜到說明正確抓取了trace文件，否則沒有抓到啟動時間點
4）找到應用對應的PID或包名的那一行
5）找到UI Thread那一行，然後可以使用【W】放大，【S】縮小，【A】左移，【S】右移，注意界面上的操作導航，需要選取對應的項才能使用快捷鍵
放大並移動找到activityStart那一列，選中該項並點擊鍵盤【m】鍵可以查看階段時間如下：
6）在activityStart下一行對應的handleLaunchActivity找到第一個draw，按下【ctrl】然後選中activityStart在選中draw，在按下【m】鍵，如下圖：
7）從步驟5中可以看到，music的啟動時間為458.656ms
備註：界面快捷鍵操作
6、adb腳本錄屏方法(不一定有用，有的機器無該命令或–bugreport選項，且需要android API21+)
測試方法：
1）adb shell screenrecord –bugreport /sdcard/test.mp4
2）使用QuickTime分析視頻即可，同方法1
備註：查看是否支持-bugreport選項
使用 adb shell screencap –help查看是否支持—bugreport選項
7、各種方法測試數據比較
⑩ Android app啟動時間測試，使用ADB命令如何實現
直接寫一個腳本使用adb命令控制app啟動，然後使用截屏命令快速截屏最終將截屏結果的產生時間做分析即可