你告诉我太卡了，那是你不晓得性能优化之 app 卡顿优化，销售应届毕业生的面试题

这个系列的文章：

1、用通俗易懂的讲解方式，讲解一门技术的实用价值 2、详细书写源码的追踪，源码截图，绘制类的结构图，尽量详细地解释原理的探索过程 3、提供 Github 的 可运行的 Demo 工程,但是我所提供代码，更多是提供思路，抛砖引玉，请酌情 cv4、集合整理原理探索过程中的一些坑，或者 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 命令（这个没必要详述吧，囧- -！

正戏

systrace是我们用来抓取一段时间之内的 android 设备上的数据指标的工具，我理解为: 设备运行日志，只不过这不是文本日志，而是一个 html 文件，需要使用谷歌浏览器的 chrome://tracing/插件打开。具体步骤如下：

1、打开 CMD，进入 systrace目录：

2、输入 python systrace.py-b32768-t5-o mytrace.html wm gfx input view sched freq，然后回车 解释一下这一串命令（ 本文不做systrace命令的详解，这些东西都是死命令，百度即可）：

• python 将要执行 python 脚本

• systrace.py 脚本名称

• b 设置缓存区大小

• t 抓取 5 秒日志

• o mytrace.html 输出到这个文件内

• wm WindowManager 日志内包含windowManager信息

• gfx Graphics 日志中包含图形绘制的信息- input Input 日志中包含设备输入的信息

• view View System 日志中包含 View 系统的信息

• sched CPU Scheduling 日志中包含 CPU 调度信息

• freq 日志中包含 CPU 频率信息

这里有个坑：

在某些真机上，比如 vivo X7，它会生成 html 文件失败，莫名其妙，我换成模拟器，就好了，尚未试验其它真机机型。

我使用网易 mumu 模拟器做实验的时候，得到如下结果：

3、得到文件之后，打开谷歌浏览器：在地址栏输入 chrome://tracing/ 然后 load 刚才的文件：( 或者你双击该 html 文件)

4、这里我们

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

得到了非常多的性能指标，包括上图中红色字体标记的 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-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

接下来，找到这个文件，导出到电脑上:

然后就要用到我们最先说道的 DDMS，先打开 DDMS，File- openFile 打开刚才的.trace 文件