享學課堂誠邀作者：周周
轉載請宣告出處！
#前言
手把手講解系列文章，是我寫給各位看官，也是寫給我自己的，
文章可能過分詳細，但是這是為了幫助到盡量多的人，畢竟作業5,6年，不能老吸血，也到了回饋開源的時候.
這個系列的文章：
1、用通俗易懂的講解方式，講解一門技術的實用價值
2、詳細書寫原始碼的追蹤，原始碼截圖，繪制類的結構圖，盡量詳細地解釋原理的探索程序
3、提供Github 的 可運行的Demo工程,但是我所提供代碼，更多是提供思路，拋磚引玉，請酌情cv
4、集合整理原理探索程序中的一些坑，或者demo的運行程序中的注意事項
5、用gif圖，最直觀地展示demo運行效果**
如果覺得細節太細，直接跳過看結論即可，
本人能力有限，如若發現描述不當之處，歡迎留言批評指正，
學到老活到老，路漫漫其修遠兮，與眾君共勉 !
本文接上一篇
#正文大綱
- DDMS
- systrace
- TraceView
- 關于過度繪制
#正文
#DDMS
DDMS 的全稱是Dalvik Debug Monitor Service，是 Android 開發環境中的Dalvik[虛擬機]除錯監控服務
以前用eclipse的時候，有個直接的入口可以打開DDMS,但是自從用了AndroidStudio，入口沒了…但是其實在SDK目錄內部還是有的.
打開DDMS之后：
具體有啥用，稍后再說，
#systrace
systrace是sdk的一個命令，它是用python語言寫的，當時用的是python2.7，但是后來python更新了3.0 谷歌卻沒有更新這個命令，導致我們現在要使用systrace命令，只能用python的2.7版本，正常情況下，用2.7的最新版2.7.16就行了，官網有下載的，
那么systrace命令在哪里?
##前提
要使用它，首先我們要安裝好python2.7.16，然后配置環境變數，直到我們能夠正常使用python命令（這個沒必要詳述吧，囧- -！，但是我還是給出本人驗證過的攻略地址：https://www.jianshu.com/p/e73768e66b8d）.
##正戲
systrace是我們用來抓取一段時間之內的android設備上的資料指標的工具，我理解為: 設備運行日志，只不過這不是文本日志，而是一個html檔案，需要使用谷歌瀏覽器的 chrome://tracing/插件打開，具體步驟如下：
1、打開CMD，進入systrace目錄：
2、輸入 python systrace.py -b 32768 -t 5 -o mytrace.html wm gfx input view sched freq，然后回車
解釋一下這一串命令（本文不做systrace命令的詳解，這些東西都是死命令，百度即可）：
python將要執行python腳本systrace.py腳本名稱-b設定快取區大小-t抓取5秒日志-omytrace.html 輸出到這個檔案內wmWindowManager 日志內包含windowManager資訊gfxGraphics 日志中包含圖形繪制的資訊inputInput 日志中包含設備輸入的資訊viewView System 日志中包含View系統的資訊schedCPU Scheduling 日志中包含CPU調度資訊freq日志中包含CPU頻率資訊
這里有個坑：
在某些真機上，比如
vivo X7，它會生成html檔案失敗，莫名其妙，我換成模擬器，就好了，尚未試驗其它真機機型，
我使用網易mumu模擬器做實驗的時候，得到如下結果：
3、得到檔案之后，打開谷歌瀏覽器：在地址欄輸入 chrome://tracing/ 然后load剛才的檔案：( 或者你雙擊該html檔案)
4、這里我們得到了非常多的性能指標，包括上圖中紅色字體標記的CPU用量，多核CPU調度情況，UI主執行緒，渲染執行緒等，但是我們應用層開發，解決的主要是app卡頓問題，一般只需要 去關注 **UI主執行緒的掉幀情況**即可. 按照下圖：
詳解一下這個帶圈的F：
- 整個坐標，橫軸為時間，從左到右時間刻度增加，代表各項指標隨著時間的變化
帶圈的F: 有綠色，黃色和紅色，其中綠色表示繪制正常，無需我們去關心，需要關注的是 黃色和紅色，特別是紅色，- 滑鼠點擊其中一個紅色的F，然后按鍵盤
G鍵，就會出現紅色的豎線，每兩根紅線之間代表一幀的時長(大部分手機的螢屏重繪頻率還是60幀，所以每次繪制大概是16.67MS)，這個F之所以是紅色，是因為這一次的UI繪制時長遠遠超過了1幀，如果UI在1幀時間之內無法完成，便會造成掉幀，一旦掉幀，在用戶的感知下，就是卡頓.- 看下圖：
使用滑鼠拖拽，可以通過圖形界面看到這一次繪制所花費的時長：為116.868ms- 在下面的Alert欄中發現了疑似
掉幀元兇
這里反映出，是我們的bitmap圖上傳導致了掉幀，
我們繼續把下面兩個箭頭展開，能夠看到：
這里的英文描述，則是 谷歌工程師給我們的建議.我來大概翻譯一下這段話：
第一段的description意思是：修改/新繪制的位圖必須上傳到GPU，因為如果上傳的總像素量很大，這是很昂貴的，所以每幀減少這個影片/背景關系中位圖的波動量，
第二段description的意思是：生成這個幀的作業被重新調度了幾毫秒，這是jank的功勞，確保UI執行緒上的代碼不會阻塞其他執行緒上的作業，并且后臺執行緒(例如網路或位圖加載)在android.os上運行，行程#THREAD_PRIORITY_BACKGROUND或更低，因此它們不太可能中斷UI執行緒，這些后臺執行緒應該在內核行程的調度部分以130或更高的優先級出現，
總的來說，就是Bitmap的使用不當導致掉幀，解決方法大概是：bitmap太大了 要裁剪成合適的大小 或者在背景執行緒去加載
至于更加具體的其他掉幀情況的解決方法，就要根據具體遇到的情況去查資料了，
##關于Trace.beginSection 和 Trace.endSection
這兩個api是androidSdk自帶的，作用是給systrace加上tag，加了tag，就會在systrace圖形上反映出我們這兩個api之間囊括的一段代碼的執行情況，
簡單來說，就是你在 一段代碼的前后，加上 Trace.beginSection 和 Trace.endSection ，像這樣：那么，你在 systrace圖形上就會發現這個，
可見，我們代碼的執行耗時等情況可以 反映在systrace圖形上，點擊上面紅框的區域，就會在systrace界面底部發現：，如果加了tag的代碼的執行耗時超過了一幀時長（16.67MS），則說明這一段代碼造成了UI主執行緒掉幀，用戶就有可能感覺到卡頓，
##這里有個坑
如果你上面加了trace.beginSection和endSection，你在圖形中還是沒有看到 你自己設定的tag，那么檢查一下你的 systrace命令，是不是沒有加 -a [app包名]
##做個結論
上述例子，我使用的是app冷啟動時抓的systrace，所以這里的掉幀，就是反映出冷啟動程序中代碼寫的有問題，注意，抓systrace的時間不要太長，必須在systrace開始執行之后再操作app，
在發現掉幀的情況之后，看alert就能看出谷歌給我們的app優化方向建議，雖然還沒有完全解決問題，但是至少確定了一個大方向,知道了大概哪一段代碼出了問題，
#TraceView
在app代碼中加入
Debug.startMethodTracing("/sdCard/zhouzhou");和Debug.stopMethodTracing();然后運行app，確保能夠執行上面兩個代碼包含的代碼片段 ，比如像這樣：
##坑坑
上面的代碼，如果你加了之后運行直接拋了例外，檢查一下你有沒有加這個權限：
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
接下來，找到這個檔案，匯出到電腦上:
然后就要用到我們最先說道的DDMS，先打開DDMS，File- openFile 打開剛才的.trace檔案
這里包含了這段代碼中所有的方法呼叫，
##表格說明
上方有一張表格，每一列的說明如下：
這么多東西，我們不可能全都關注，只需要關注兩個：
Cpu Time/Call函式平均執行時間較長的函式；(耗時較長的函式)Call+Recur Calls/Total，呼叫次數非常頻繁的函式，
如果發現，上面兩個指標超乎尋常，比如呼叫次數特別多，每一次呼叫耗費時間特別長的，而且又能夠是我們自己寫的方法，那么基本上就能確定優化點了，
#關于過度繪制
概念：
如果螢屏的一片區域，在渲染的程序中，被繪制了太多次，則稱為過度繪制，
如何檢查:
上圖是mumu模擬器的設定界面，我們點擊顯示過度繪制區域,就會發現界面顏色發生了變化：
顏色由淺到深，越深，表示過渡繪制會越嚴重，大致有以下幾種顏色:
- 白色：沒有過度繪制，
- 藍色：Overdraw 一倍，像素繪制了兩次，能夠接受，但是如果整個界面都是藍色的，那么說明還是有繪制的浪費，可以節約一層繪制，
- 綠色：Overdraw 兩倍，嘗試優化，
- 淺紅：Overdraw 三倍，
- 暗紅：Overdraw 四倍，非常嚴重，必須優化，
##如何優化過渡繪制？
- 如果你的代碼中，通過過度繪制的檢查，發現復雜布局顯示出大量的過度繪制，那么必須要考慮
用自定義View自己去繪制，- 如果你的布局xml中，有大量的嵌套，考慮
去掉某些 background，因為沒有了background，UI執行緒就不會去做這一次繪制- 如果非要用到有background的layout，那么在滿足業務需求的情況下考慮
減少一定的層級，
#結語
上述3個工具的使用，是我們app性能優化中必須用到的，大概思路如下
1.用systrace 抓取 .html檔案，觀察圖形，找出掉幀的大概位置
2. 用 Trace.beginSection 和 Trace.endSection 反復推測，確定確切代碼塊
3. 用traceView抓取.trace日志，用DDMS打開它，尋找耗時較長的函式 或 次數非常多的函式，確定確切掉幀原因
三個工具需要結合使用，才能具體確定我們的
app哪里出了問題，
#話題拓展
本文只給出了大致思路，并沒有給出Demo，這是因為 性能優化可能出現的情況太多了，無法一一列舉，具體發生了什么，只有到發生之后，自行根據工具檢測出的結果去推斷，去論證，去解決，
性能優化是無止境的，永遠有能夠優化的空間，本文只給出了大致指導方向，具體能夠優化到何種程度，全看各位的自我修為，
上面的3個工具，可以用來做性能優化， 但是他們的作用不僅僅是性能優化，千萬不要一葉障目，比如systrace這個東西，上述文章我只用來檢查了卡頓掉幀的情況，但是它其實還可以 查看CPU調度情況和CPU多核分配情況，還可以檢查主執行緒的執行緒狀態切換情況等，
##下一篇預告：記憶體抖動和泄漏的優化
如果你的技術提升遇到瓶頸了，或者缺高級Android進階視頻學習提升自己，這有大量大廠面試題為你面試做準備！
點擊Android 學習，面試檔案，視頻收集大整理獲取
結語
小編也是很有感觸，如果一直都是在中小公司，沒有接觸過大型的互聯網架構設計的話，只靠自己看書去提升可能一輩子都很難達到高級架構師的技術和認知高度，向厲害的人去學習是最有效減少時間摸索、精力浪費的方式，
我們選擇的這個行業就一直要持續的學習，又很吃青春飯，
雖然大家可能經常見到說程式員年薪幾十萬，但這樣的人畢竟不是大部份，要么是有名校光環，要么是在阿里華為這樣的大企業，年齡一大，更有可能被裁，
小編整理的學習資料分享一波！
送給每一位想學習Java小伙伴，用來提升自己，想要資料的可以點擊這里免費獲取
里華為這樣的大企業，年齡一大，更有可能被裁，
小編整理的學習資料分享一波！
送給每一位想學習Java小伙伴，用來提升自己，想要資料的可以點擊這里免費獲取
[外鏈圖片轉存中…(img-1UtqxxLA-1623619967496)]
本文到這里就結束了，喜歡的朋友可以幫忙點贊和評論一下，感謝支持！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/287617.html
標籤：python