問題
- 有的時候界面很卡争群，我們該如何定位哄褒？
現(xiàn)狀
面試過很多人藏否，對于這個問題鞭衩，大部分都是這樣回答的：
分情況：
1. 啟動卡頓门驾，應(yīng)該看下都有哪些耗時操作射赛，嘗試延后執(zhí)行
2. 滑動卡頓，考慮優(yōu)化view復(fù)用
3. 交互優(yōu)化奶是，有些是等待IO
另外從 內(nèi)存泄露 界面布局層次 界面重復(fù)渲染方面找問題
雖然不能說是錯誤的楣责，但是整體的來說都是依靠經(jīng)驗和審代碼，很少涉及工具使用聂沙，很難做到問題的準(zhǔn)確定位秆麸，更不用說優(yōu)化了
實踐記錄
現(xiàn)象描述
我們有一個界面，打開之后會根據(jù)狀態(tài)自動滑動到第二個tab頁及汉，但是在滑動過程中比較卡沮趣，期望優(yōu)化
分析
整個操作涉及兩部分：頁面啟動，tab滑動豁生，
第一部分因為是原位置從無到有兔毒，而且有l(wèi)oading，所以用戶感知不大甸箱，第二部分因為涉及頁面內(nèi)容滑動育叁，所以特別明顯。
所謂的卡頓芍殖，其實對技術(shù)而言就是掉幀豪嗽，簡單說就是界面的渲染流程沒能在16ms內(nèi)完成，所以我們需要知道渲染流程每個階段大致用了多少時間，哪個過程耗時較多
工具上場
GPU呈現(xiàn)模式分析
打開設(shè)置-開發(fā)者選項-GPU呈現(xiàn)模式分析龟梦，選擇在屏幕上顯示為條形圖隐锭。
此時我們可以看到屏幕上多出了很多柱條，條形圖含義請參考下面的鏈接說明计贰。
進(jìn)行復(fù)現(xiàn)操作钦睡，我們發(fā)現(xiàn)柱條很少，每一個都超出了16ms的準(zhǔn)線躁倒，而且深綠色偏長荞怒，說明我們在主線程做了很多和UI無關(guān)的耗時操作。
CPU Profiler
設(shè)備連上studio秧秉， 打開Android Profiler褐桌， 選擇CPU，使用說明請參考下面鏈接象迎。
點擊record荧嵌，進(jìn)行復(fù)現(xiàn)操作，停止record砾淌。
檢查記錄啦撮，此時可能有朋友會問這個結(jié)果怎么看，我簡單說下
因為我們分析的是卡頓汪厨，主要看主線程逻族，所以首先選擇主線程，然后通過Call chart我們可以看到主線程的方法執(zhí)行骄崩，
一般是loop對事件分發(fā)然后各種處理聘鳞，我在實際操作時就可以看到onCreate執(zhí)行了多長時間，而其中onCreate里的每個方法執(zhí)行了多長時間要拂，還有一些切換到主線程的回調(diào)執(zhí)行了多長時間抠璃，還有onResume執(zhí)行了多少時間。
通過這個結(jié)果我大概發(fā)現(xiàn)了一些造成卡頓的問題：
- 部分工具類的實際耗時比想象的長
- 網(wǎng)絡(luò)請求的回調(diào)在主線程執(zhí)行脱惰，而其中涉及一些大數(shù)據(jù)json的解析耗時較長
- 部分view是根據(jù)數(shù)據(jù)動態(tài)生成的搏嗡，創(chuàng)建一個自定義view耗時較長，主要原因是view的xml較復(fù)雜
- Presentation的show方法執(zhí)行耗時特別長
Systrace
這個工具我也有嘗試拉一，但是效果不好采盒，使用說明請參考下面鏈接。
好處是它會直接告訴你一些程序的問題蔚润，比如主線程調(diào)度delay磅氨、draw方法執(zhí)行過程、measure時間過長嫡纠，
壞處或者說不好用的地方烦租，在我的電腦上 Ubuntu 16.04, 這個工具無法指定檢測時長無論是否指定-t參數(shù)延赌，而且有時會記錄其他app而不記錄我想檢測的app，即使添加-a參數(shù)叉橱，另外有一些時候生成的報告無法打開挫以，好像是時間設(shè)置問題，但是網(wǎng)上沒有搜索到相關(guān)解決方案窃祝。大家有空可以嘗試下掐松。
解決方案
將耗時操作移入子線程，并且注意子線程的優(yōu)先級要低于主線程粪小。
