你告诉我太卡了，那是你不晓得性能优化之app卡顿优化

前言

手把手讲解系列文章，是我写给各位看官，也是写给我本身的。文章可能过度详细，可是这是为了帮助到尽可能多的人，毕竟工做5,6年，不能老吸血，也到了回馈开源的时候

(更多完整项目下载。未完待续。源码。图文知识后续上传github。)
能够点击关于我联系我获取983页完整PDF
(VX：mm14525201314)

这个系列的文章：

一、用通俗易懂的讲解方式，讲解一门技术的实用价值
二、详细书写源码的追踪，源码截图，绘制类的结构图，尽可能详细地解释原理的探索过程
三、提供Github 的 可运行的Demo工程,可是我所提供代码，更可能是提供思路，抛砖引玉，请酌情cv
四、集合整理原理探索过程当中的一些坑，或者demo的运行过程当中的注意事项
五、用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/插件打开。具体步骤以下：

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

二、输入 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模拟器作实验的时候，获得以下结果：

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

四、这里咱们获得了很是多的性能指标，包括上图中红色字体标记的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文件

这里包含了这段代码中全部的方法调用。

表格说明

上方有一张表格，每一列的说明以下：

这么多东西，咱们不可能全都关注，只须要关注两个：

• CpuTime/Call 函数平均执行时间较长的函数；(耗时较长的函数)
• Call+RecurCalls/Total，调用次数很是频繁的函数。若是发现，上面两个指标超乎寻常，好比调用次数特别多，每一次调用耗费时间特别长的，并且又可以是咱们本身写的方法，那么基本上就能肯定优化点了。

关于过分绘制

概念：若是屏幕的一片区域，在渲染的过程当中，被绘制了太屡次，则称为过分绘制。如何检查:

上图是mumu模拟器的设置界面，咱们点击 显示过分绘制区域,就会发现界面颜色发生了变化：

颜色由浅到深，越深，表示过渡绘制会越严重。大体有如下几种颜色:

1. 白色：没有过分绘制。
2. 蓝色：Overdraw 一倍。像素绘制了两次，可以接受，可是若是整个界面都是蓝色的，那么说明仍是有绘制的浪费，能够节约一层绘制。
3. 绿色：Overdraw 两倍。尝试优化。
4. 浅红：Overdraw 三倍。
5. 暗红：Overdraw 四倍。很是严重，必须优化。

如何优化过渡绘制？

1. 若是你的代码中，经过过分绘制的检查，发现复杂布局显示出大量的过分绘制，那么必需要考虑 用自定义View本身去绘制。
2. 若是你的布局xml中，有大量的嵌套，考虑 去掉某些background ，由于没有了background，UI线程就不会去作这一次绘制
3. 若是非要用到有background的layout，那么在知足业务需求的状况下考虑 减小必定的层级。

结语

上述3个工具的使用，是咱们app性能优化中必须用到的。大概思路以下

1.用systrace 抓取 .html文件，观察图形，找出掉帧的大概位置

2. 用 Trace.beginSection 和 Trace.endSection 反复推测，肯定确切代码块

3. 用traceView抓取.trace日志，用DDMS打开它，寻找耗时较长的函数 或 次数很是多的函数，肯定确切掉帧缘由

三个工具须要结合使用，才能具体肯定咱们的 app哪里出了问题。

话题拓展

本文只给出了大体思路，并无给出Demo，这是由于 性能优化可能出现的状况太多了，没法一一列举，具体发生了什么，只有到发生以后，自行根据工具检测出的结果去推断，去论证，去解决。

性能优化是无止境的，永远有可以优化的空间。本文只给出了大体指导方向，具体可以优化到何种程度，全看各位的自我修为。**

上面的3个工具，能够用来作性能优化， 可是他们的做用不只仅是性能优化，千万不要一叶障目。好比systrace这个东西，上述文章我只用来检查了卡顿掉帧的状况，可是它其实还能够 查看CPU调度状况和CPU多核分配状况，还能够检查主线程的线程状态切换状况等。

请查看完整的PDF版
(更多完整项目下载。未完待续。源码。图文知识后续上传github。)
能够点击关于我联系我获取983页完整PDF
(VX：mm14525201314)