抓出卡顿元凶，从分析掉帧开始

此次咱们依旧来谈谈有关性能优化的话题，此次咱们会用到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至关于缩放。
最后咱们用鼠标来选取相应的时间范围便可。

今天的分享到此，但愿对你有帮助。