Android性能優(yōu)化
1.啟動優(yōu)化
概述：啟動速度往往是由一個input事件（以Message的形式）觸發(fā)（比如點擊、長按、電源鍵），由一個或者多個Message的執(zhí)行結束為結尾溯职，而這些Message中一般都有關鍵的界面繪制相關的Message黔夭，應用啟動時間介紹見官網：https://developer.android.com/topic/performance/vitals/launch-time?hl=zh-cn
冷啟動：
在冷啟動開始時，系統(tǒng)有三個任務溯祸，它們是：
1肢专、加載并啟動應用
2舞肆、在啟動后立即顯示應用的空白啟動窗口
3、創(chuàng)建應用進程
系統(tǒng)一創(chuàng)建應用進程博杖，應用進程就負責后續(xù)階段：
1椿胯、創(chuàng)建應用對象。
2剃根、啟動主線程哩盲。
3、創(chuàng)建主 Activity狈醉。
4廉油、擴充視圖。
5苗傅、布局屏幕抒线。
6、執(zhí)行初始繪制金吗。
-->Launcher--(啟動應用)
-->SystemServer--(加載并啟動應用-->創(chuàng)建空白啟動窗口-->創(chuàng)建應用進程-->)
-->APP--(創(chuàng)建ActivityThread-->執(zhí)行main函數(shù)--創(chuàng)建主Activity--測量十兢、布局、繪制）
界面切換
Activity切換主要是弄清activity的生命周期過程摇庙，A跳轉到B Activity的過程：
A.onPause-->B.onCreate-->B.onStart-->B.onResume-->A.onStop
Fragment切換主要是弄清fragment的生命周期過程旱物，F(xiàn)ragment概述見官網：https://developer.android.com/guide/components/fragments?hl=zh-cn，生命周期可參考這篇文章：https://juejin.cn/post/6844903752114126855
1.1 測試啟動速度：
A.使用高速攝像機或者iphone測試時間卫袒；
B.通過打印ActivityManager中Displayed的log查看啟動時間（Activity第一幀顯示的時間）
C.adb shell am start -S -W (Displayed 對應TotalTime宵呛，即Activity第一幀顯示的時間)
1.2 啟動速度分析工具：
A.HierarchyView分析布局層次
B.systrace定位問題點 和traceView定位耗時函數(shù)分析性能
C.Run->Edit Configurations-->Profiling-->check start recording CPU activity on startup
https://developer.android.com/studio/profile/cpu-profiler
1.3 startingWindow機制
通過startActivity啟動應用時，把Options等信息傳給AMS夕凝，AMS創(chuàng)建相應的ActivityRecord宝穗，改變其狀態(tài)、可見性码秉，WMS創(chuàng)建相應的窗口逮矛，改變其可見性、大小转砖、位置等须鼎，等到APP頁面繪制完成，動畫加載完成府蔗，開始執(zhí)行動畫晋控，這個時候用戶才看到應用起來了。
當應用界面繪制比較慢時姓赤，系統(tǒng)一直處于等待狀態(tài)赡译，直到應用告訴系統(tǒng)繪制完成，啟動動畫才開始執(zhí)行不铆，這也是啟動慢的直接原因蝌焚。
原生為了解決上面的問題裹唆，引入了startingWindow的機制，即應用啟動不依賴于應用界面繪制只洒，只要startingWindow繪制完成并且動畫設置完畢品腹，就展開頁面。
流程如下：
***startActivity ---> 創(chuàng)建ActivityRecord/改變其可見性--->添加StartingWindow---> StartingWindow 繪制完成--->頁面展開
***startActivity--->解析theme屬性--->加載預覽圖--->窗口繪制完成（校驗theme屬性红碑、更新緩存圖）--->應用退出（校驗theme屬性、更新緩存圖）
1.3 檢查初始化代碼
1.4 減少布局復雜度泡垃，使用viewstub析珊，預加載
1.5 view耗時：
A.使用overdraw分析界面是否存在過繪制；
B.使用profiling GPU render分析view繪制邏輯是否過于復雜蔑穴；
C.使用HierachyView分析布局層次忠寻；
D.lint找出ui線程中耗時操作
https://developer.android.com/topic/performance/vitals/launch-time
啟動高級性能剖析
https://developer.android.com/studio/profile/android-profiler?hl=zh-cn#advanced-profiling
1.6 啟動速度優(yōu)化分析思路
1、打開binder調試存和，方便在trace中顯示binder信息
adb shell am trace-ipc start
抓取結束后奕剃，可以執(zhí)行下面的命令關閉
adb shell am trace-ipc stop
2、trace命令加入irq tag捐腿，默認的命令不包含irq纵朋，需要自己加irq的TAG，這樣打開Trace之后茄袖，就可以看到irq相關的內容操软，最后的抓trace命令如下:
python /mnt/d/Android/platform-tools/systrace/systrace.py gfx input view webview wm am sm rs bionic power pm ss database network adb idle pdx sched irq freq idle disk workq binder_driver binder_lock -a com.xxx.xxx
3、在APP代碼的每個函數(shù)中插入trace宪祥，在分析的時候可以看到更詳細的信息
2.內存優(yōu)化
Log分析聂薪，命令分析，工具分析
2.1 adb shell dumpsys meminfo查看內存情況
2.2 DDMS heap查看
2.3 APT工具查看是否有內存泄露蝗羊，配合重復操作某個路徑
2.4 MAT工具查看Leak Suspects, Histogram分析內存最大類的內部引用
2.5 基于MAT分析藏澳，屏蔽代碼，反復測試
2.6 內存抖動導致卡頓：
1.查看虛擬機GC的log
2.使用systrace查看繪制過程線程的執(zhí)行情況
補充說明：不設置背景>使用顏色值>.9圖片>大像素圖片
https://cs.android.com/android/platform/superproject/+/master:development/scripts/native_heapdump_viewer.py?q=native_heapdump_viewer.py
https://cs.android.com/android/platform/superproject/+/master:bionic/libc/malloc_debug/README.md?q=native_heapdump_viewer.py
2.7 使用LeakCanary檢測內存泄露：
（1）build.gradle添加依賴
（2）application中初始化 LeakCanary.install(this); 在應用內點擊并退出耀找，如果有內存泄露翔悠，一小段時間后會在通知欄生成一條通知，點擊可查看內存泄露的引用路徑涯呻。
3.卡頓優(yōu)化
3.1 啟動卡頓凉驻，運行卡頓，滑動卡頓复罐；
3.2 log分析：
A.log是否打印頻繁涝登；
B.虛擬機是否有執(zhí)行GC操作；
3.3 命令分析：
A.adb shell top -m 10 -t -n 5 top命令查看是否有進程占用大量CPU時間效诅，導致主線程無法執(zhí)行胀滚；
B.dumpsys SurfaceFlinger查看刷新率是否正常趟济；
C.dumpsys SurfaceFlinger查看疊加層信息，是否有多余層咽笼；
D.dumpsys gfxinfo packagename 查看硬件加速是否開啟顷编；
3.4 工具分析：
A.TraceView使用DDMS采集數(shù)據(jù)
3.4.1 打開debug屬性，application配置debuggable剑刑，系統(tǒng)應用還需配置ro.debuggable=1,persist.service.adb.enable=1;
3.4.2 打開eclipse->DDMS媳纬，選擇應用；點擊start method profiling,執(zhí)行相應過程施掏，點擊stop method profiling
B.TraceView 加代碼采集數(shù)據(jù)
3.4.3 manifest加入寫入SD卡的權限
3.4.4 在性能關注起始位置钮惠，調用方法啟動追蹤，開始創(chuàng)建trace log文件七芭；調用stopMethodTracing方法停止trace過程
3.4.5 執(zhí)行trace文件進行分析traceview ***demo.trace
3.5 分析時間線面板（選擇線程）和分析面板（所選線程各函數(shù)的調用情況）
3.6選擇Incl Cpu Time進行降序排列素挽，得到最耗時的方法
3.7 Systrace
https://developer.android.com/topic/performance/tracing/navigate-report?hl=zh-cn
Systrace會生成包含多個部分的輸出HTML文件。該報告列出了每個進程的線程狸驳。如果給定線程會渲染界面幀预明，該報告還會沿時間軸指明所渲染的幀，當您在報告中從左向右移動時耙箍，時間會向前推移撰糠。
報告從上到下包含以下幾個部分：
用戶互動
第一部分包含表示應用或游戲中的具體用戶活動的條形圖。這些互動可用作有用的事件標記究西。
CPU活動
下一部分顯示了表示每個CPU中的線程活動的條形圖窗慎。這些條形圖會顯示所有應用中的CPU活動。CPU活動部分可以展開卤材，展開后您就可以查看每個CPU的時鐘頻率遮斥。【點擊kernel展開】
系統(tǒng)事件
此部分中的直方圖會顯示特定的系統(tǒng)級事件扇丛，例如特定對象的紋理計數(shù)和總大小术吗。
值得仔細檢查的直方圖是標記為 SurfaceView 的直方圖。計數(shù)表示已傳遞到顯示管道并等待顯示在設備屏幕上的組合幀緩沖區(qū)的數(shù)量帆精。由于大多數(shù)設備都會進行雙重或三重緩沖较屿，因此該計數(shù)幾乎總為 0、1 或 2卓练。
顯示幀
這一部分通常是報告中最頂部的部分隘蝎，描繪了一條多色線條，后面是成堆的條形襟企。這些形狀表示已創(chuàng)建的特定線程的狀態(tài)和幀堆棧嘱么。堆棧的每個層級代表對 beginSection() 的一次調用，或您為應用或游戲定義的[自定義跟蹤事件]的開頭顽悼。
注意：界面線程（即通常運行您的應用或游戲的主線程）始終會顯示為第一個線程曼振。
每個條形堆上方的多色線條表示特定線程隨時間變化的一組狀態(tài)几迄。每段線條可以包含以下顏色之一：
綠色：正在運行
線程正在完成與某個進程相關的工作或正在響應中斷。
藍色：可運行
線程可以運行但目前未進行調度冰评。
白色：休眠
線程沒有可執(zhí)行的任務映胁，可能是因為線程在遇到斥鎖定時被阻止。
橙色：不可中斷的休眠
線程在遇到 I/O 操作時被阻止或正在等待磁盤操作完成甲雅。
紫色：可中斷的休眠
線程在遇到另一項內核操作（通常是內存管理）時被阻止解孙。
鍵盤快捷鍵
| 鍵 | 說明 |
|---|---|
| W | 放大跟蹤時間軸 |
| A | 在跟蹤時間軸上向左平移 |
| S | 縮小跟蹤時間軸。 |
| D | 在跟蹤時間軸上向右平移抛人。 |
| E | 以當前鼠標位置為中定位跟蹤時間軸 |
| M | 高亮當前選區(qū) |
| 1 | 將當前正在使用中的選擇模型更改為“選擇”模式妆距。對應于鼠標選擇器工具欄中顯示的第 1 個按鈕（請參見右圖）。 |
| 2 | 將當前正在使用中的選擇模型更改為“平移”模式函匕。對應于鼠標選擇器工具欄中顯示的第 2 個按鈕（請參見右圖）。 |
| 3 | 將當前正在使用中的選擇模型更改為“縮放”模式蚪黑。對應于鼠標選擇器工具欄中顯示的第 3 個按鈕（請參見右圖）盅惜。 |
| 4 | 將當前正在使用中的選擇模型更改為“計時”模式。對應于鼠標選擇器工具欄中顯示的第 4 個按鈕（請參見右圖）忌穿。 |
| G | 在當前所選任務的開頭顯示網格抒寂。 |
| Shift + G | 在當前所選任務的末尾顯示網格 |
| 向左箭頭 | 在當前選定的時間軸上選擇上一個事件 |
| 向右箭頭 | 在當前選定的時間軸上選擇下一個事件。 |
識別性能問題
瀏覽 Systrace 報告時掠剑，您可以通過執(zhí)行以下一項或多項操作來更輕松地識別性能問題：
1.通過在時間間隔周圍繪制一個矩形來選擇所需的時間間隔屈芜。
2.使用標尺工具標記或突出顯示問題區(qū)域。
3.依次點擊 View Options > Highlight VSync朴译，以顯示每項顯示屏刷新操作井佑。
檢查界面幀和提醒
1.Systrace 報告列出了渲染界面幀的每個進程，并指明了沿時間軸渲染的每個幀眠寿。在 16.6 毫秒內渲染的必須保持每秒 60 幀穩(wěn)定幀速率的幀會以綠色圓圈表示躬翁。渲染時間超過 16.6 毫秒的幀會以黃色或紅色幀圓圈表示。
2.點擊某個幀圓圈可將其突出顯示盯拱，并提供有關系統(tǒng)為渲染該幀所做工作的其他信息盒发，包括提醒。此報告還會顯示系統(tǒng)在渲染該幀時執(zhí)行的方法狡逢。您可以調查這些方法以確定界面卡頓的可能原因宁舰。
選擇運行速度慢的幀后，您可能會在報告的底部窗格中看到一條提醒奢浑。圖 5 中顯示的提醒指明幀的主要問題是在 [ListView]回收和重新綁定上花費了太多時間蛮艰。指向跟蹤記錄中相關事件的鏈接可詳細說明系統(tǒng)在此期間執(zhí)行的操作。
如需查看此工具在您的跟蹤記錄中發(fā)現(xiàn)的每條提醒以及設備觸發(fā)每條提醒的次數(shù)殷费，請點擊窗口最右側的 Alerts 標簽頁印荔，如圖 6 所示低葫。Alerts 面板可幫助您了解跟蹤記錄中出現(xiàn)的問題以及這些問題導致出現(xiàn)卡頓的頻率。您可以將此面板視為要修正的錯誤列表仍律。通常情況下嘿悬，只需對一個區(qū)域進行細微改動或改進即可移除整組提醒。
如果您發(fā)現(xiàn)在界面線程上執(zhí)行的工作太多水泉，請使用以下方法之一來幫助確定哪些方法占用了過多的 CPU 時間：
- 如果您想了解哪些方法可能會導致瓶頸善涨，請在這些方法中添加跟蹤標記。如需了解詳情草则，請參閱有關如何在代碼中定義自定義事件的指南钢拧。
- 如果您不確定界面瓶頸的來源，請使用 Android Studio 中提供的 CPU 分析器炕横。您可以生成跟蹤日志源内，然后使用 CPU 分析器導入和檢查這些日志。
4.數(shù)據(jù)庫優(yōu)化
4.1 使用SQLiteSpy工具進行數(shù)據(jù)庫優(yōu)化：
A.抽取SQL語句份殿，在此工具上進行調試膜钓，分析SQL效率，查看執(zhí)行速度卿嘲。
4.2 常用優(yōu)化方向：
A.數(shù)據(jù)庫讀取優(yōu)化（索引讀取颂斜，按需索取，查詢語句優(yōu)化拾枣，JOIN優(yōu)化）;
B.寫入優(yōu)化（批量處理沃疮，使用觸發(fā)器）
4.3 數(shù)據(jù)庫調試：
A.adb shell content query；
B.contentprovider的query/update/insert方法中打印出調用者進程id（分析死鎖梅肤，分析ANR司蔬，分析性能；UserId：android.os.Binder.getCallingUid(),Pid:android.os.Binder.getCallingPid()）姨蝴；
C.編寫測試apk進行單元測試
4.4 數(shù)據(jù)庫性能分析：
SQLite benchmarking測試了下數(shù)據(jù)庫性能
5.廣播優(yōu)化
5.1 cpu開銷分析葱她，查看cpu使用情況
5.2 借助trace堆棧和log分析
獲取系統(tǒng)服務的堆棧(adb shell bugreport -t > allTrace.txt)，查看系統(tǒng)服務16個Binder線程占用情況
5.3 代碼排查
5.4 獲取當前廣播信息
adb shell dumpsys activity broadcasts
5.5 應用內部使用廣播通信似扔，使用LocalBraodcastManager
5.6 執(zhí)行效率要求高的消息傳遞不使用廣播
6.ANR問題分析
6.1 ANR分類
6.1.1 應用ANR：
(1)按鍵響應超時事件5s
Input dispatching timed out
主線程對輸入事件在5秒內沒有處理完畢發(fā)生ANR：當應用程序的Window處于Active狀態(tài)并且能夠接收輸入事件（例如按鍵更新吨些、觸摸事件）時，系統(tǒng)底層上報的事件就會被InputDispatcher分發(fā)給這個應用程序炒辉，應用程序的主線程通過InputChannel讀取輸入事件并交給界面視圖處理豪墅。通常會注冊一個監(jiān)聽器來接收并處理事件，或者創(chuàng)建自定義的試圖控件來處理事件黔寇。InputDispatcher運行在系統(tǒng)進程system_server的一個單獨線程中偶器，應用程序的主線程在處理事件的過程中，InputDispatcher會不斷的檢測處理過程是否超時，一旦超時屏轰，會通過一系列的回調通知WMS的notifyANR函數(shù)颊郎，最終會調用到AMS中mHandler對象里的SHOW_NOT_RESPONDING_MSG這個case
(2)廣播處理超時10s
Timeout of broadcast /Receiver during timeout:
**可能原因：1、binder霎苗；2姆吭、消息隊列；3唁盏、onReceive内狸；4、靜態(tài)接收者寫入磁盤未完成**
主線程在執(zhí)行BroadcastReceiver的onReceive函數(shù)時10秒內沒有執(zhí)行完畢發(fā)生ANR：ContextImpl發(fā)送廣播（sendBroadcast\sendOrderBroadcast\sendStickyBroadcast）APP進程---->broadcastIntent--(binder_1)-->AMS----->processNextBroadcast--->BroadcastQueue(BroadcastHandler埋定時炸彈)----->scheduleReceiver(binder_3)---->handleReceive--->ActivityThread---->BroadcastReceiver(onReceive)--->finishReceiver(binder_2)--->AMS
靜態(tài)注冊的接收者超時檢測過程會考慮QueuedWork是否工作尚未完成（SharedPreferences寫入磁盤操作）
(3)服務處理超時20s
Timeout executing service：
**可能原因：1厘擂、binder昆淡；2、消息隊列刽严；3昂灵、onCreate、onStartCommand**
主線程在執(zhí)行Service的各個生命周期函數(shù)時20秒內沒有執(zhí)行完畢發(fā)生ANR：ContextImpl（startService）APP進程---->startService（binder_1)---->AMS---->realStartServiceLocked----->ActiveServices(AMS.MainHandler)----->scheduleCreateService----->binder_3---->handleCreateService---->ActivityThread--->new/attach/onCreate（Service進程）---->serviceDoneExecuting(binder_2)
6.1.2系統(tǒng)ANR:
(1)Watchdog超時60s
6.2 ANR的原因
1舞萄、 應用本身：耗時操作倔既，死循環(huán)，線程阻塞鹏氧，線程掛起；
2\ 其他進程：cpu被搶占
6.3 ANR問題分析思路：
1佩谣、 event log看具體的ANR時間（關鍵字：am_anr)把还，看看是否跟ANR log能夠對上，以確定ANR Log是否有效
2茸俭、 如果應用ANR log有效吊履，則分析應用ANR現(xiàn)場：
(1)根據(jù)apps/android.txt獲取出錯進程、出錯原因调鬓、CPU占用率艇炎、tid、死鎖等信息;
(2)根據(jù)anr/traces.txt查看堆棧信息腾窝、分析代碼
3缀踪、 trace中字段的含義
| 字段 | 含義 |
|---|---|
| tid | 線程號 |
| sysTid | 線程號 |
| Native | 線程狀態(tài)，其中 state 也是線程狀態(tài)虹脯，state=S 代表 Sleeping |
| nice | nice 值越小驴娃，則優(yōu)先級越高。因為是主線程此處 nice=-10, 可以看到優(yōu)先級很高了 |
| schedstat | 括號中的 3 個數(shù)字循集，依次是 Running, Runnable, Switch Running 時間：CPU 運行的時間唇敞，單位 ns Runable 時間：RQ 隊列的等待時間，單位 ns Switch 次數(shù)：CPU 調度切換次數(shù) |
| utm | 該線程在用戶態(tài)所執(zhí)行的時間，單位是 jiffies |
| stm | 該線程在內核態(tài)所執(zhí)行的時間疆柔，單位是 jiffies |
| sCount | 此線程被掛起的次數(shù) |
| dsCount | 線程被調試器掛起的次數(shù)咒精，當一個進程被調試后，sCount 會重置為 0旷档，調試完畢后 sCount 會根據(jù)是否被正常掛起增長模叙，但是 dsCount 不會被重置為 0，所以 dsCount 也可以用來判斷這個線程是否被調試過 |
| self | 線程本身的地址 |
| 字段 | 含義 |
|---|---|
| TERMINATED | Thread.run has returned, but Thread* still around |
| RUNNABLE | runnable/running in a JNI native method/suspended by GC or debugger |
| TIMED_WAITING | in Object.wait() Thread.sleep() with a timeout |
| BLOCKED | blocked on a monitor |
| WAITING | in Object.wait()/checking other threads are not run on abort |
| NEW | native thread started, not yet ready to run managed code |
4彬犯、 如果沒有l(wèi)og向楼，分析代碼(zygote的堆棧dump kill -3 <pid>，輸出的trace會保存在data/anr/trace.txt文件中谐区，分析堆棧log湖蜕，結合堆棧log確認是當前報錯進程的異常還是其他進程的異常。如果是其他進程的異常宋列，則跟蹤其他進程處理昭抒，如果是當前進程的異常，則查看當前進程的主線程狀態(tài)是Native炼杖，Block或者Waiting灭返。
1）如果是Native，則查看主線程的堆棧信息坤邪，分析線程耗時的原因
2）如果是Block熙含，則查看
3）如果是Waiting(掛起狀態(tài))，
6.4 系統(tǒng)ANR分析方法
1艇纺、查找WATCHDOG信息
2怎静、 查看調用堆棧、分析代碼
3黔衡、 分析思路：
（1）分析關鍵操作：比如解鎖蚓聘、安裝應用、亮滅屏盟劫、應用啟動
（2）分析系統(tǒng)關鍵log：A：系統(tǒng)變慢：Slow operation夜牡、Slow dispatch、Slow delivery侣签、dvm_lock_sample塘装；B：進程變化：am_kill、lowmemorykiller影所、ANR氢哮；C：cpu info、binder info（是否滿了）型檀、iowait（是否過高）
（3）分析關鍵線程的運行情況
7.兼容性問題分析
7.1 常用分析策略：
A.無法安裝（log分析冗尤，apktool）；
B.定屏分析（dumpsys input，getevent）裂七；
C.界面異常(dumpsys SurfaceFlinger,dumpsys window）;
8.apk大小優(yōu)化
8.1 assets目錄篩查皆看，lint工具清除本地冗余資源（命令行執(zhí)行）
8.2 findbugs查找冗余代碼，系統(tǒng)使用資源反色排查背零，使用工具排查應用中多余圖片和未使用資源
8.3 tinypng壓縮圖片
減少程序圖片資源的大小
1 確保在build.gradle文件中開啟了minifEnabled與shrinkResources的屬性腰吟，這兩個屬性可以幫助移除那些在程序中使用不到的代碼與資源，幫助減少APP的安裝包大小徙瓶。
2 有選擇性的提供對應分辨率的圖片資源毛雇，系統(tǒng)會自動匹配最合適分辨率的圖片并執(zhí)行拉伸或者壓縮的處理。
3 在符合條件的情況下侦镇，使用Vertor Drawable替代傳統(tǒng)的PNG/JPEG圖片灵疮，能夠極大的減少圖片資源的大小。傳統(tǒng)模式下壳繁，針對不同dpi的手機都需要提供一套PNG/JPEG的圖片震捣，而如果使用Vector Drawable的話，只需要一個XML文件即可闹炉。
使用VectorDrawable還可以避免因為使用幀動畫導致的圖片資源過多的情況蒿赢，如下圖所示
4 盡量復用已經存在的資源圖片，使用代碼的方式對已有的資源進行復用渣触，如下圖所示：
5羡棵、針對啟動速度不影響的應用，不編譯odex文件
6嗅钻、互聯(lián)網的應用放老的版本
7皂冰、不重要的應用從system分區(qū)摞到data分區(qū)，并確保不可卸載
8啊犬、OS版本裁剪功能
9.功耗優(yōu)化
9.1 常見耗電原因：
1.通過wakelock鎖定；
2.alarm頻繁喚醒異常壁查；
3.頻繁通過網絡設備喚醒觉至；
4.異常持有外設耗電，（LCD睡腿、MODEM语御、AP、GPU對功耗影響）界面顏色偏白席怪，持有亮屏鎖不釋放应闯；
5.后臺消耗cpu資源
9.2 常見應用原因：
1.log過多，頻繁啟動挂捻，文件解析碉纺，大數(shù)據(jù)量傳輸，復雜算法運算；
2.寫存儲骨田，申請連續(xù)內存時等待耿导；
3.多核調度，調頻策略變化态贤；
4.運營商網絡影響舱呻，NV參數(shù)設置不合理；
5.刷新頻率悠汽，過度繪制箱吕，圖層成熟，圖片形狀柿冲，裁剪圖片茬高，動畫曲線，字體陰影
9.3 優(yōu)化方向：
界面顏色風格選擇:
9.4 分析思路
9.4.1. 確認現(xiàn)象：1.確認問題點 姻采，2.熄屏/亮屏查看 events log查看 screen_toggled雅采，3.電量查看 events log中查看battery_level，電量下降是否平滑
9.4.2 分析cpu耗電：1.wakelock是否常時間持有慨亲，kernel log中搜索UTC婚瓜，確認熄屏后kernel是否很快待機，cpu時間是否有跳變刑棵，是否有多個watchdog打影涂獭；2.定位wakelock蛉签，查看應用持鎖和系統(tǒng)持鎖胡陪，分析長時間未休眠原因，kernel log中搜索aborted碍舍，分析是否進程凍結失敗柠座，kernel log中搜索failed看是否設備suspend失敗片橡；3.統(tǒng)計喚醒源
9.4.3.分析網絡數(shù)據(jù)妈经，4.分析外設耗電，5.電量檢測是否有誤差
9.4.4.OLED屏捧书，不同顏色界面對功耗影響非常大
9.5 應用電流分析思路：
9.5.1 top命令查看CPU占有率(adb shell top -t -m 10)
9.5.2 ftrace查看線程的運行情況
9.6 應用界面對功耗的影響
9.6.1 1.圖片資源（圖片色值明暗程度）2.view數(shù)量吹泡，圖層數(shù)量，view區(qū)域重疊经瓷，運算復雜度爆哑，字體陰影
9.6.2 聯(lián)系人頭像方形變圓形，裁剪算法更復雜舆吮；item行高變低揭朝，單頁view數(shù)量更多队贱。
9.6.3 減少不必要的刷新，通過開發(fā)者選項查看是否仍在刷新
打開systrace 網站
1.chrome://tracing
systrace工作原理
http://www.reibang.com/p/6f528e862d31
10.網絡優(yōu)化
思路：緩存
1.讓應用可離線使用——應用開發(fā)者行為（如：電子郵件客戶端撰寫萝勤、發(fā)送露筒、閱讀、移動敌卓、刪除郵件）
2.使用GcmNetworkManager和ContentProvider——網絡數(shù)據(jù)緩存慎式，應用開發(fā)者行為
3.網絡請求去重——應用開發(fā)者行為（如：不會變化的數(shù)據(jù)只網絡請求一次，緩存起來）
思路：根據(jù)網絡狀態(tài)決定行為
4.網絡請求劃分優(yōu)先級——應用開發(fā)者行為（如：文本請求高于富媒體請求）
5.低速網絡下減少網絡請求——應用開發(fā)者行為（如：網速慢趟径，只下載低分辨率媒體）
6.檢測網絡變化瘪吏，然后更改應用行為——應用開發(fā)者行為(如：新聞閱讀器應用2G網絡時一次獲取3篇文章，使用WLAN時一次獲取20篇文章）
