電量
統計耗電本身也是一件耗電行爲，所以軟件統計方式其實都不是很精確
統計方法/工具
功耗儀：統計整機的耗電
騰訊GT工具
Battery Historian(Google 官方提供的工具，5.0及以後系統適用)
https://github.com/google/battery-historian
手機投屏軟件
windows：apowermirror
Battery Historian
從手機中導出bugreport文件上傳至頁面，在網頁中生成詳細的圖表數據來展示手機各模塊電量消耗過程，然後通過App數據的分析制定出相關的電量優化的方法
安裝GO python Java
使用Docker
$ docker run -p 9999:9999 registry.cn-beijing.aliyuncs.com/center1/google_battery
獲取方式
記錄喚醒鎖的信息
$ adb shell dumpsys batterystats --enable full-wake-history
重置電量數據
$ adb shell dumpsys batterystats --reset
採集電量數據
# Android7.0之後
$ adb bugreport bugreport.zip
# Android7.0之前
$ adb bugreport > bugreport.txt
流暢度
幀率 & 刷新頻率
RefreshRate屏幕在一秒內刷新屏幕的次數，取決於硬件的固定參數，如60Hz
FrameRateGPU在一秒內繪製操作的幀數，例如30fps，60fps
卡頓root cause
大多數用戶感受到卡頓等性能問題的主要根源都是因爲渲染性能，android系統無法及時完成那些複雜的界面渲染操作，就產生了卡頓/不流暢的想象
FPS指標
fps低，但是不覺得App卡
因爲本來就用不到那麼高的fps，屏幕沒有繪製要求，那麼fps就爲0
app停止操作後，fps還是一直變化
屏幕每一幀的合成都是針對手機裏面所有的進程，當前app停止後其他進程可能還在繪製
計算流暢度
系統合成幀率
數據形式最爲直觀，遊戲/視頻等連續繪製的應用可以考慮選用，但不適用於絕大多數非連續繪製的應用
流暢度(SM:SMoothness)
數據形式和FPS類似，可以很好的彌補FPS無法準確刻畫非連續繪製的應用顯示性能的缺陷
原理：在VSync機制中1s內Loop運行的次數
當流暢度越小的時候說明當前程序越卡頓
指標獲取
FPS獲取
$ adb shell dumpsys gfxinfo 包名
# 例如
$ adb shell dumpsys gfxinfo com.sankuai.meituan
Draw+Prepare+Process+Execute=完整顯示一幀的時間
這個時間需要小於16.67ms才能保證不丟幀
計算總數據的行數(跳過第一行)
frameCount = rowNum
計算每幀的渲染時間
renderTime = Draw + Prepare + Process + Execute
當渲染時間renderTime大於16.67ms，該幀渲染超時,算一次丟幀，需要用掉額外的Vsync個數爲(多需要同步的信號)
16.67整數倍
vsyncOverNum=int(renderTime/16.67)-1
非16.67整數倍
vsyncOverNum=int(renderTime/16.67)-1
fps計算公式
fps=frameCount*60/(frameCount+vsyncOverNum=int)
SM獲取
騰訊GT
流暢度影響因素
UI渲染
界面過度渲染
佈局邊界合理性
UI線程複雜運算
頻繁GC垃圾回收
UI渲染
UI渲染由CPU和GPU兩個部分協同完成
CPU負責UI佈局元素的Measure，Layout，Draw等相關運算執行。如果佈局邊界不合理，會導致卡頓
GPU負責柵格化，將UI元素繪製到屏幕上，如果界面過度繪製，也可能導致卡頓
頁面的過度繪製
一個像素點繪製次數超過1次
開發者選項->調試GPU過度繪製
沒顏色：沒有過度繪製
藍色：1倍過度繪製，1個像素點繪製2次
綠色：2倍 3次
淺紅色：3倍 4次
深紅色：4倍以上 5次以上
藍色和綠色可以接受
UI線程複雜運算
當android應用啓動時，系統會爲應用創建一個主線程，負責和UI組件進行交互
如果主線程裏面進行復雜運算就會造成界面無響應/卡頓/不流暢(ANR已經是卡頓的極致了)
TraceView
分析方法執行時間
StrictMode(嚴苛模式)
在代碼裏或者開發者選項中開啓，查看應用哪些操作在主線程上執行時間過長
當一些操作違背了嚴格模式時，屏幕四周會閃爍紅色，同時輸出StrictMode的相關信息到LOGCAT日誌中