抓出卡頓元兇，從分析掉幀開始

此次咱們依舊來談談有關性能優化的話題，此次咱們會用到Google給咱們提供的分析工具——Systrace。若是你還不瞭解這個工具，最好先了解一下。Google 官方文檔：
https://developer.android.com/studio/command-line/systrace
咱們還會用到一個Demo，用來對比卡頓和不卡頓的情況。

問題重現

Demo運行起來會是這樣的：
流暢運行

模擬卡頓

這裏解釋一下，GIF動畫表現得不是很完善，流暢運行的效果實際上是每秒60幀，實際運行效果很是順暢。模擬卡頓的效果在每秒60幀的基礎上加了隨機時長的線程sleep時間。具體實驗代碼片以下所示：

流暢運行的代碼片

threadRun = true;
        pbCurrent = 0;
        demoPb.setProgress(pbCurrent);
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (threadRun) {
                    try {
                        Thread.sleep(1000 / 60);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    if (pbCurrent > PB_MAX) {
                        pbCurrent = 0;
                    } else {
                        pbCurrent++;
                    }
                    Message msg = new Message();
                    msg.what = UPDATE_HANDLER_KEY;
                    mUiHandler.sendMessage(msg);
                }
            }
        }).start();

模擬卡頓的代碼片

thread2Run = true;
        pbCurrent = 0;
        demoPb.setProgress(pbCurrent);
        new Thread(new Runnable() {
            @Override
            public void run() {
                while (thread2Run) {
                    try {
                        Thread.sleep(1000 / 60);
                        Thread.sleep(new Random().nextInt(200));
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    if (pbCurrent > PB_MAX) {
                        pbCurrent = 0;
                    } else {
                        pbCurrent++;
                    }
                    Message msg = new Message();
                    msg.what = UPDATE_HANDLER_KEY;
                    mUiHandler.sendMessage(msg);
                }
            }
        }).start();

更新UI部分代碼片

@Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            switch (msg.what) {
                case UPDATE_HANDLER_KEY:
                    demoPb.setProgress(pbCurrent);
                    break;
            }
        }

兩個按鈕分別對應上述兩個線程的使能，另外請注意：咱們只是模擬卡頓，並不是真的發生了卡頓。所以，在Systrace的圖表中，沒有出現紅色或橙色的告警。
分別對上述兩種狀況取Systrace圖表，獲得以下結果：

流暢運行的圖表

模擬卡頓運行的圖表

經過對比，咱們能夠看到上面兩者之間的差異。流暢運行的圖表中，每一幀的繪製很均勻。差很少16.6ms一幀，也就是1000毫秒除以60幀，獲得的16.6ms一幀。而模擬卡頓的圖表中，每一幀的繪製則不均勻，有的長達將近200ms。但因爲是咱們自身模擬的結果，並不是實際卡頓，因此圖表中均爲綠色的顯示。下面咱們來看一個真實的案例：

真實案例

上圖中，一幀原本應該是16ms完成的，然而卻花費了近60ms，用1000ms/60ms，咱們獲得近似16幀。而16幀的幀率已是肉眼可見的卡頓了。

揪出兇手

咱們聚焦到上面真實的案例，放大看發生卡頓的位置：

咱們發現，Record View 的draw()方法花費了一些時間。

此外，還有一堆瑣碎的小片斷，咱們進一步放大觀察，會發現：

這裏竟然還加載了一堆貼圖。
至此，咱們就抓到了致使掉幀的「元兇」，下一步就是結合源代碼進行優化了。

一些疑問和技巧

爲何16ms一幀？
16ms是1000ms/60幀獲得的結果，60幀對於人眼而言已是很流暢的體驗了。而最低的限度是33ms一幀，也就是1000ms/30幀獲得的結果。若是時間再長一點的話，就有可能發生人眼可見的卡頓了。
延伸一點，也就是說，若是嚴格要求60幀，可是中間掉了1幀，就至關於33ms畫一幀，此時，雖然掉幀，可是人眼仍是可接受的。

如何快速定位卡頓位置
首先是確保發生了卡頓。通常而言，沒有發生卡頓的圖表，網頁的圖表會是綠色的，發生卡頓的則是紅色的。

而後咱們使用鍵盤+鼠標的組合來找位置，鍵盤的快捷鍵對應W、S、A、D。AD至關於拖拽時間滑塊，WS至關於縮放。
最後咱們用鼠標來選取相應的時間範圍便可。

今天的分享到此，但願對你有幫助。