Android应用开发性能优化完全分析 _android应用

赋料扬雄敌，诗看子建亲。这篇文章主要讲述Android应用开发性能优化完全分析相关的知识，希望能为你提供帮助。
1 背景其实有点不想写这篇文章的，但是又想写，有些矛盾。不想写的原因是随便上网一搜一堆关于性能的建议，感觉大家你一总结、我一总结的都说到了很多优化注意事项，但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用，啥啥啥该咋用等，却很少有较为系统的进行真正性能案例分析的，大多数都是嘴上喊喊或者死记住规则而已（当然了，这话我自己听着都有些刺耳，实在不好意思，其实关于性能优化的优质博文网上也还是有很多的，譬如Google官方都已经推出了优化专题，我这里只是总结下自的感悟而已，若有得罪欢迎拍砖，我愿挨打，因为我之前工作的一半时间都是负责性能优化）。
当然了，本文不会就此编辑这么一次，因为技术在发展，工具在强大（写着写着Android Studio 1.4版本都推送了），自己的经验也在增加，所以本文自然不会覆盖所有性能优化及分析；解决的办法就是该文章会长期维护更新，同时在评论区欢迎你关于性能优化点子的探讨。
android应用的性能问题其实可以划分为几个大的模块的，而且都具有相对不错的优化调试技巧，下面我们就会依据一个项目常规开发的大类型来进行一些分析讲解。
PS：之前呆过一家初创医疗互联网公司，别提性能优化了，老板立完新项目后一个月就要求见到上线成品，这种压迫下谈何性能优化，纯属扯蛋，所以不到三个月时间我主动选择撤了，这种现象后来我一打听发现在很多初创公司都很严重，都想速成却忽略了体验。
PPPS：本文只是达到抛砖引玉的作用，很多东西细究下去都是值得深入研究的，再加上性能优化本来就是一个需要综合考量的任务，不是说会了本文哪一点就能做性能分析了，需要面面俱到才可高效定位问题原因。
【工匠若水 http://blog.csdn.net/yanbober 转载请注明出处。点我开始Android技术交流】
2 应用UI性能问题分析 UI可谓是一个应用的脸，所以每一款应用在开发阶段我们的交互、视觉、动画工程师都拼命的想让它变得自然大方美丽，可是现实总是不尽人意，动画和交互总会觉得开发做出来的应用用上去感觉不自然，没有达到他们心目中的自然流畅细节；这种情况之下就更别提发布给终端用户使用了，用户要是能够感觉出来，少则影响心情，多则卸载应用；所以一个应用的UI显示性能问题就不得不被开发人员重视。
2-1 应用UI卡顿原理人类大脑与眼睛对一个画面的连贯性感知其实是有一个界限的，譬如我们看电影会觉得画面很自然连贯（帧率为24fps），用手机当然也需要感知屏幕操作的连贯性（尤其是动画过度），所以Android索性就把达到这种流畅的帧率规定为60fps。
有了上面的背景，我们开发App的帧率性能目标就是保持在60fps，也就是说我们在进行App性能优化时心中要有如下准则：

< code class= " hljs brainfuck has-numbering" > 换算关系： 60帧/秒 - - - - - - - - - - - 16ms/帧； 准则：尽量保证每次在16ms内处理完所有的CPU与GPU计算、绘制、渲染等操作，否则会造成丢帧卡顿问题。 < /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < /ul>

从上面可以看出来，所谓的卡顿其实是可以量化的，每次是否能够成功渲染是非常重要的问题， 16ms能否完整的做完一次操作直接决定了卡顿性能问题。
当然了，针对Android系统的设计我们还需要知道另一个常识；虚拟机在执行GC垃圾回收操作时所有线程（包括UI线程）都需要暂停，当GC垃圾回收完成之后所有线程才能够继续执行（这个细节下面小节会有详细介绍）。也就是说当在16ms内进行渲染等操作时如果刚好遇上大量GC操作则会导致渲染时间明显不足，也就从而导致了丢帧卡顿问题。
有了上面这两个简单的理论基础之后我们下面就会探讨一些UI卡顿的原因分析及解决方案。
2-2 应用UI卡顿常见原因我们在使用App时会发现有些界面启动卡顿、动画不流畅、列表等滑动时也会卡顿，究其原因，很多都是丢帧导致的；通过上面卡顿原理的简单说明我们从应用开发的角度往回推理可以得出常见卡顿原因，如下：

人为在UI线程中做轻微耗时操作，导致UI线程卡顿；
布局Layout过于复杂，无法在16ms内完成渲染；
同一时间动画执行的次数过多，导致CPU或GPU负载过重；
View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；
View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；
内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；
冗余资源及逻辑等导致加载和执行缓慢；
臭名昭著的ANR；

可以看见，上面这些导致卡顿的原因都是我们平时开发中非常常见的。有些人可能会觉得自己的应用用着还蛮OK的，其实那是因为你没进行一些瞬时测试和压力测试，一旦在这种环境下运行你的App你就会发现很多性能问题。
2-3 应用UI卡顿分析解决方法分析UI卡顿我们一般都借助工具，通过工具一般都可以直观的分析出问题原因，从而反推寻求优化方案，具体如下细说各种强大的工具。
2-3-1 使用HierarchyViewer分析UI性能
我们可以通过SDK提供的工具HierarchyViewer来进行UI布局复杂程度及冗余等分析，如下：

< code class= " hljs ruby has-numbering" > xxx @ ThinkPad :~ $ hierarchyviewer/ /通过命令启动HierarchyViewer < /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < /ul>

选中一个Window界面item，然后点击右上方Hierarchy window或者Pixel Perfect window（这里不介绍，主要用来检查像素属性的）即可操作。
先看下Hierarchy window，如下：

文章图片

一个Activity的View树，通过这个树可以分析出View嵌套的冗余层级，左下角可以输入View的id直接自动跳转到中间显示； Save as PNG用来把左侧树保存为一张图片； Capture Layers用来保存psd的PhotoShop分层素材；右侧剧中显示选中View的当前属性状态；右下角显示当前View在Activity中的位置等；左下角三个进行切换； Load View Hierarchy用来手动刷新变化（不会自动刷新的）。当我们选择一个View后会如下图所示：

文章图片

类似上图可以很方便的查看到当前View的许多信息；上图最底那三个彩色原点代表了当前View的性能指标，从左到右依次代表测量、布局、绘制的渲染时间，红色和黄色的点代表速度渲染较慢的View（当然了，有些时候较慢不代表有问题，譬如ViewGroup子节点越多、结构越复杂，性能就越差）。
当然了，在自定义View的性能调试时， HierarchyViewer上面的invalidate Layout和requestLayout按钮的功能更加强大，它可以帮助我们debug自定义View执行invalidate()和requestLayout()过程，我们只需要在代码的相关地方打上断点就行了，接下来通过它观察绘制即可。
可以发现，有了HierarchyViewer调试工具，我们的UI性能分析变得十分容易，这个工具也是我们开发中调试UI的利器，在平时写代码时会时常伴随我们左右。
2-3-2 使用GPU过度绘制分析UI性能
我们对于UI性能的优化还可以通过开发者选项中的GPU过度绘制工具来进行分析。在设置-> 开发者选项-> 调试GPU过度绘制（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面过度绘制进行分析）：

文章图片

可以发现，开启后在我们想要调试的应用界面中可以看到各种颜色的区域，具体含义如下：

颜色	含义
无色	WebView等的渲染区域
蓝色	1x过度绘制
绿色	2x过度绘制
淡红色	3x过度绘制
红色	4x(+ )过度绘制

由于过度绘制指在屏幕的一个像素上绘制多次（譬如一个设置了背景色的TextView就会被绘制两次，一次背景一次文本；这里需要强调的是Activity设置的Theme主题的背景不被算在过度绘制层级中），所以最理想的就是绘制一次，也就是蓝色（当然这在很多绚丽的界面是不现实的，所以大家有个度即可，我们的开发性能优化标准要求最极端界面下红色区域不能长期持续超过屏幕三分之一，可见还是比较宽松的规定），因此我们需要依据此颜色分布进行代码优化，譬如优化布局层级、减少没必要的背景、暂时不显示的View设置为GONE而不是INVISIBLE、自定义View的onDraw方法设置canvas.clipRect()指定绘制区域或通过canvas.quickreject()减少绘制区域等。
2-3-3 使用GPU呈现模式图及FPS考核UI性能
Android界面流畅度除过视觉感知以外是可以考核的（测试妹子专用），常见的方法就是通过GPU呈现模式图或者实时FPS显示进行考核，这里我们主要针对GPU呈现模式图进行下说明，因为FPS考核测试方法有很多（譬如自己写代码实现、第三方App测试、固件支持等），所以不做统一说明。
通过开发者选项中GPU呈现模式图工具来进行流畅度考量的流程是（注意：如果是在开启应用后才开启此功能，记得先把应用结束后重新启动）在设置-> 开发者选项-> GPU呈现模式（不同设备可能位置或者叫法不同）中打开调试后可以看见如下图（对settings当前界面上下滑动列表后的图表）：

文章图片

当然，也可以在执行完UI滑动操作后在命令行输入如下命令查看命令行打印的GPU渲染数据（分析依据： Draw + Process + Execute = 完整的显示一帧时间 < 16ms）：

< code class= " hljs css has-numbering" > adb shell dumpsys gfxinfo [应用包名] < /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < /ul>

打开上图可视化工具后，我们可以在手机画面上看到丰富的GPU绘制图形信息，分别展示了StatusBar、NavgationBar、Activity区域等的GPU渲染时间信息，随着界面的刷新，界面上会以实时柱状图来显示每帧的渲染时间，柱状图越高表示渲染时间越长，每个柱状图偏上都有一根代表16ms基准的绿色横线，每一条竖着的柱状线都包含三部分（蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，黄色代表CPU等待GPU处理的时间），只要我们每一帧的总时间低于基准线就不会发生UI卡顿问题（个别超出基准线其实也不算啥问题的）。
可以发现，这个工具是有局限性的，他虽然能够看出来有帧耗时超过基准线导致了丢帧卡顿，但却分析不到造成丢帧的具体原因。所以说为了配合解决分析UI丢帧卡顿问题我们还需要借助traceview和systrace来进行原因追踪，下面我们会介绍这两种工具的。
2-3-4 使用Lint进行资源及冗余UI布局等优化
上面说了，冗余资源及逻辑等也可能会导致加载和执行缓慢，所以我们就来看看Lint这个工具是如何发现优化这些问题的（当然了， Lint实际的功能是非常强大的，我们开发中也是经常使用它来发现一些问题的，这里主要有点针对UI性能的说明了，其他的雷同）。
在Android Studio 1.4版本中使用Lint最简单的办法就是将鼠标放在代码区点击右键-> Analyze-> Inspect Code–> 界面选择你要检测的模块-> 点击确认开始检测，等待一下后会发现如下结果：

文章图片

可以看见， Lint检测完后给了我们很多建议的，我们重点看一个关于UI性能的检测结果；上图中高亮的那一行明确说明了存在冗余的UI层级嵌套，所以我们是可以点击跳进去进行优化处理掉的。
当然了， Lint还有很多功能，大家可以自行探索发挥，这里只是达到抛砖引玉的作用。
2-3-5 使用Memory监测及GC打印与Allocation Tracker进行UI卡顿分析
关于Android的内存管理机制下面的一节会详细介绍，这里我们主要针对GC导致的UI卡顿问题进行详细说明。
Android系统会依据内存中不同的内存数据类型分别执行不同的GC操作，常见应用开发中导致GC频繁执行的原因主要可能是因为短时间内有大量频繁的对象创建与释放操作，也就是俗称的内存抖动现象，或者短时间内已经存在大量内存暂用介于阈值边缘，接着每当有新对象创建时都会导致超越阈值触发GC操作。
如下是我工作中一个项目的一次经历（我将代码回退特意抓取的），出现这个问题的场景是一次压力测试导致整个系统卡顿，瞬间杀掉应用就OK了，究其原因最终查到是一个API的调运位置写错了方式，导致一直被狂调，当普通使用时不会有问题，压力测试必现卡顿。具体内存参考图如下：

文章图片

与此抖动图对应的LogCat抓取如下：

< code class= " hljs asciidoc has-numbering" > //截取其中比较密集一段LogCat，与上图Memory检测到的抖动图对应，其中xxx为应用包名 ...... 10-06 00:59:45.619 xxx I/art: Explicit concurrent mark sweep GC freed 72515(3MB) AllocSpace objects, 65(2028KB) LOS objects, 80% free, 17MB/89MB, paused 3.505ms total 60.958ms 10-06 00:59:45.749 xxx I/art: Explicit concurrent mark sweep GC freed 5396(193KB) AllocSpace objects, 0(0B) LOS objects, 75% free, 23MB/95MB, paused 2.079ms total 100.522ms ...... 10-06 00:59:48.059 xxx I/art: Explicit concurrent mark sweep GC freed 4693(172KB) AllocSpace objects, 0(0B) LOS objects, 75% free, 23MB/95MB, paused 2.227ms total 101.692ms ......< /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < /ul>

我们知道，类似上面logcat打印一样，触发垃圾回收的主要原因有以下几种：

GC_MALLOC——内存分配失败时触发；
GC_CONCURRENT——当分配的对象大小超过一个限定值（不同系统）时触发；
GC_EXPLICIT——对垃圾收集的显式调用(System.gc()) ；
GC_EXTERNAL_ALLOC——外部内存分配失败时触发；

可以看见，这种不停的大面积打印GC导致所有线程暂停的操作必定会导致UI视觉的卡顿，所以我们要避免此类问题的出现，具体的常见优化方式如下：

检查代码，尽量避免有些频繁触发的逻辑方法中存在大量对象分配；
尽量避免在多次for循环中频繁分配对象；
避免在自定义View的onDraw()方法中执行复杂的操作及创建对象（譬如Paint的实例化操作不要写在onDraw()方法中等）；
对于并发下载等类似逻辑的实现尽量避免多次创建线程对象，而是交给线程池处理。

当然了，有了上面说明GC导致的性能后我们就该定位分析问题了，可以通过运行DDMS-> Allocation Tracker标签打开一个新窗口，然后点击Start Tracing按钮，接着运行你想分析的代码，运行完毕后点击Get Allocations按钮就能够看见一个已分配对象的列表，如下：

文章图片

点击上面第一个表格中的任何一项就能够在第二个表格中看见导致该内存分配的栈信息，通过这个工具我们可以很方便的知道代码分配了哪类对象、在哪个线程、哪个类、哪个文件的哪一行。譬如我们可以通过Allocation Tracker分别做一次Paint对象实例化在onDraw与构造方法的一个自定义View的内存跟踪，然后你就明白这个工具的强大了。
PS一句， Android Studio新版本除过DDMS以外在Memory视图的左侧已经集成了Allocation Tracker功能，只是用起来还是没有DDMS的方便实用，如下图：

文章图片

2-3-6 使用Traceview和dmtracedump进行分析优化
关于UI卡顿问题我们还可以通过运行Traceview工具进行分析，他是一个分析器，记录了应用程序中每个函数的执行时间；我们可以打开DDMS然后选择一个进程，接着点击上面的“Start Method Profiling”按钮（红色小点变为黑色即开始运行），然后操作我们的卡顿UI（小范围测试，所以操作最好不要超过5s），完事再点一下刚才按的那个按钮，稍等片刻即可出现下图，如下：

文章图片

花花绿绿的一幅图我们怎么分析呢？下面我们解释下如何通过该工具定位问题：
整个界面包括上下两部分，上面是你测试的进程中每个线程运行的时间线，下面是每个方法（包含parent及child）执行的各个指标的值。通过上图的时间面板可以直观发现，整个trace时间段main线程做的事情特别多，其他的做的相对较少。当我们选择上面的一个线程后可以发现下面的性能面板很复杂，其实这才是TraceView的核心图表，它主要展示了线程中各个方法的调用信息（ CPU使用时间、调用次数等），这些信息就是我们分析UI性能卡顿的核心关注点，所以我们先看几个重要的属性说明，如下：

属性名	含义
name	线程中调运的方法名；
Incl CPU Time	当前方法（包含内部调运的子方法）执行占用的CPU时间；
Excl CPU Time	当前方法（不包含内部调运的子方法）执行占用的CPU时间；
Incl Real Time	当前方法（包含内部调运的子方法）执行的真实时间， ms单位；
Excl Real Time	当前方法（不包含内部调运的子方法）执行的真实时间， ms单位；
Calls+ Recur Calls/Total	当前方法被调运的次数及递归调运占总调运次数百分比；
CPU Time/Call	当前方法调运CPU时间与调运次数比，即当前方法平均执行CPU耗时时间；
Real Time/Call	当前方法调运真实时间与调运次数比，即当前方法平均执行真实耗时时间；（重点关注）

有了对上面Traceview图表的一个认识之后我们就来看看具体导致UI性能后该如何切入分析，一般Traceview可以定位两类性能问题：

方法调运一次需要耗费很长时间导致卡顿；
方法调运一次耗时不长，但被频繁调运导致累计时长卡顿。

譬如我们来举个实例，有时候我们写完App在使用时不觉得有啥大的影响，但是当我们启动完App后静止在那却十分费电或者导致设备发热，这种情况我们就可以打开Traceview然后按照Cpu Time/Call或者Real Time/Call进行降序排列，然后打开可疑的方法及其child进行分析查看，然后再回到代码定位检查逻辑优化即可；当然了，我们也可以通过该工具来trace我们自定义View的一些方法来权衡性能问题，这里不再一一列举喽。
可以看见， Traceview能够帮助我们分析程序性能，已经很方便了，然而Traceview家族还有一个更加直观强大的小工具，那就是可以通过dmtracedump生成方法调用图。具体做法如下：

< code class= " hljs rsl has-numbering" > dmtracedump -g result.png target. trace //结果png文件目标trace文件 < /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < /ul>

通过这个生成的方法调运图我们可以更加直观的发现一些方法的调运异常现象。不过本人优化到现在还没怎么用到它，每次用到Traceview分析就已经搞定问题了，所以说dmtracedump自己酌情使用吧。
PS一句， Android Studio新版本除过DDMS以外在CPU视图的左侧已经集成了Traceview（ start Method Tracing）功能，只是用起来还是没有DDMS的方便实用（这里有一篇AS MT个人觉得不错的分析文章（引用自网络，链接属于原作者功劳）），如下图：

文章图片

2-3-7 使用Systrace进行分析优化
Systrace其实有些类似Traceview，它是对整个系统进行分析（同一时间轴包含应用及SurfaceFlinger、WindowManagerService等模块、服务运行信息），不过这个工具需要你的设备内核支持trace（命令行检查/sys/kernel/debug/tracing）且设备是eng或userdebug版本才可以，所以使用前麻烦自己确认一下。
我们在分析UI性能时一般只关注图形性能（所以必须选择Graphics和View，其他随意），同时一般对于卡顿的抓取都是5s，最多10s。启动Systrace进行数据抓取可以通过两种方式，命令行方式如下：

< code class= " hljs avrasm has-numbering" > python systrace .py --time= 10 -o mynewtrace .html sched gfx view wm< /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < /ul>

图形模式：
打开DDMS-> Capture system wide trace using Android systrace-> 设置时间与选项点击OK就开始了抓取，接着操作APP，完事生成一个trace.html文件，用Chrome打开即可如下图：

文章图片

在Chrome中浏览分析该文件我们可以通过键盘的W-A-S-D键来搞定，由于上面我们在进行trace时选择了一些选项，所以上图生成了左上方相关的CPU频率、负载、状态等信息，其中的CPU N代表了CPU核数，每个CPU行的柱状图表代表了当前时间段当前核上的运行信息；下面我们再来看看SurfaceFlinger的解释，如下：

文章图片

可以看见上面左边栏的SurfaceFlinger其实就是负责绘制Android程序UI的服务，所以SurfaceFlinger能反应出整体绘制情况，可以关注上图VSYNC-app一行可以发现前5s多基本都能够达到16ms刷新间隔， 5s多开始到7s多大于了15ms，说明此时存在绘制丢帧卡顿；同时可以发现surfaceflinger一行明显存在类似不规律间隔，这是因为有的地方是不需要重新渲染UI，所以有大范围不规律，有的是因为阻塞导致不规律，明显可以发现0到4s间大多是不需要渲染，而5s以后大多是阻塞导致；对应这个时间点我们放大可以看到每个部分所使用的时间和正在执行的任务，具体如下：

文章图片

可以发现具体的执行明显存在超时性能卡顿（原点不是绿色的基本都代表存在一定问题，下面和右侧都会提示你选择的帧相关详细信息或者alert信息），但是遗憾的是通过Systrace只能大体上发现是否存在性能问题，具体问题还需要通过Traceview或者代码中嵌入Trace工具类等去继续详细分析，总之很蛋疼。
PS：如果你想使用Systrace很轻松的分析定位所有问题，看明白所有的行含义，你还需要具备非常扎实的Android系统框架的原理才可以将该工具使用的得心应手。
2-3-8 使用traces.txt文件进行ANR分析优化
ANR（ Application Not Responding）是Android中AMS与WMS监测应用响应超时的表现；之所以把臭名昭著的ANR单独作为UI性能卡顿的分析来说明是因为ANR是直接卡死UI不动且必须要解掉的Bug，我们必须尽量在开发时避免他的出现，当然了，万一出现了那就用下面介绍的方法来分析吧。
我们应用开发中常见的ANR主要有如下几类：

按键触摸事件派发超时ANR，一般阈值为5s（设置中开启ANR弹窗，默认有事件派发才会触发弹框ANR）；
广播阻塞ANR，一般阈值为10s（设置中开启ANR弹窗，默认不弹框，只有log提示）；
服务超时ANR，一般阈值为20s（设置中开启ANR弹窗，默认不弹框，只有log提示）；

当ANR发生时除过logcat可以看见的log以外我们还可以在系统指定目录下找到traces文件或dropbox文件进行分析，发生ANR后我们可以通过如下命令得到ANR trace文件：

< code class= " hljs haskell has-numbering" > adb pull / data /anr/traces.txt ./ < /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < /ul>

然后我们用txt编辑器打开可以发现如下结构分析：

< code class= " hljs avrasm has-numbering" > //显示进程id、ANR发生时间点、ANR发生进程包名 ----- pid 19073 at 2015 - 10 - 08 17 : 24 : 38 ----- Cmd line: com .example .yanbo .myapplication //一些GC等object信息，通常可以忽略 ...... //ANR方法堆栈打印信息！重点！ DALVIK THREADS ( 18 ): " main" prio= 5 tid= 1 Sleeping | group= " main" sCount= 1 dsCount= 0 obj= 0x7497dfb8 self= 0x7f9d09a000 | sysTid= 19073 nice= 0 cgrp= default sched= 0 / 0 handle= 0x7fa106c0a8 | state= S schedstat= ( 125271779 68162762 280 ) utm= 11 stm= 1 core= 0 HZ= 100 | stack= 0x7fe90d3000 - 0x7fe90d5000 stackSize= 8 MB | held mutexes= at java .lang .Thread .sleep !(Native method) - sleeping on < 0x0a2ae345 > (a java .lang .Object ) at java .lang .Thread .sleep (Thread .java : 1031 ) - locked < 0x0a2ae345 > (a java .lang .Object ) //真正导致ANR的问题点，可以发现是onClick中有 sleep 导致。我们平时可以类比分析即可，这里不详细说明。 at java .lang .Thread .sleep (Thread .java : 985 ) at com .example .yanbo .myapplication .MainActivity $1 .onClick (MainActivity .java : 21 ) at android .view .View .performClick (View .java : 4908 ) at android .view .View $PerformClick .run (View .java : 20389 ) at android .os .Handler .handleCallback (Handler .java : 815 ) at android .os .Handler .dispatchMessage (Handler .java : 104 ) at android .os .Looper .loop (Looper .java : 194 ) at android .app .ActivityThread .main (ActivityThread .java : 5743 ) at java .lang .reflect .Method .invoke !(Native method) at java .lang .reflect .Method .invoke (Method .java : 372 ) at com .android .internal .os .ZygoteInit $MethodAndArgsCaller .run (ZygoteInit .java : 988 ) at com .android .internal .os .ZygoteInit .main (ZygoteInit .java : 783 ) ...... //省略一些不常关注堆栈打印 ......< /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < li> 8< /li> < li> 9< /li> < li> 10< /li> < li> 11< /li> < li> 12< /li> < li> 13< /li> < li> 14< /li> < li> 15< /li> < li> 16< /li> < li> 17< /li> < li> 18< /li> < li> 19< /li> < li> 20< /li> < li> 21< /li> < li> 22< /li> < li> 23< /li> < li> 24< /li> < li> 25< /li> < li> 26< /li> < li> 27< /li> < li> 28< /li> < li> 29< /li> < li> 30< /li> < li> 31< /li> < li> 32< /li> < li> 33< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < li> 8< /li> < li> 9< /li> < li> 10< /li> < li> 11< /li> < li> 12< /li> < li> 13< /li> < li> 14< /li> < li> 15< /li> < li> 16< /li> < li> 17< /li> < li> 18< /li> < li> 19< /li> < li> 20< /li> < li> 21< /li> < li> 22< /li> < li> 23< /li> < li> 24< /li> < li> 25< /li> < li> 26< /li> < li> 27< /li> < li> 28< /li> < li> 29< /li> < li> 30< /li> < li> 31< /li> < li> 32< /li> < li> 33< /li> < /ul>

至此常见的应用开发中ANR分析定位就可以解决了。
2-4 应用UI性能分析解决总结可以看见，关于Android UI卡顿的性能分析还是有很多工具的，上面只是介绍了应用开发中我们经常使用的一些而已，还有一些其他的，譬如Oprofile等工具不怎么常用，这里就不再详细介绍。
通过上面UI性能的原理、原因、工具分析总结可以发现，我们在开发应用时一定要时刻重视性能问题，如若真的没留意出现了性能问题，不妨使用上面的一些案例方式进行分析。但是那终归是补救措施，在我们知道上面UI卡顿原理之后我们应该尽量从项目代码架构搭建及编写时就避免一些UI性能问题，具体项目中常见的注意事项如下：

布局优化；尽量使用include、merge、ViewStub标签，尽量不存在冗余嵌套及过于复杂布局（譬如10层就会直接异常），尽量使用GONE替换INVISIBLE，使用weight后尽量将width和heigh设置为0dp减少运算， Item存在非常复杂的嵌套时考虑使用自定义Item View来取代，减少measure与layout次数等。
列表及Adapter优化；尽量复用getView方法中的相关View，不重复获取实例导致卡顿，列表尽量在滑动过程中不进行UI元素刷新等。
背景和图片等内存分配优化；尽量减少不必要的背景设置，图片尽量压缩处理显示，尽量避免频繁内存抖动等问题出现。
自定义View等绘图与布局优化；尽量避免在draw、measure、layout中做过于耗时及耗内存操作，尤其是draw方法中，尽量减少draw、measure、layout等执行次数。
避免ANR，不要在UI线程中做耗时操作，遵守ANR规避守则，譬如多次数据库操作等。

当然了，上面只是列出了我们项目中常见的一些UI性能注意事项而已，相信还有很多其他的情况这里没有说到，欢迎补充。还有一点就是我们上面所谓的UI性能优化分析总结等都是建议性的，因为性能这个问题是一个涉及面很广很泛的问题，有些优化不是必需的，有些优化是必需的，有些优化掉以后又是得不偿失的，所以我们一般着手解决那些必须的就可以了。
【工匠若水 http://blog.csdn.net/yanbober 转载请注明出处。点我开始Android技术交流】
3 应用开发Memory内存性能分析优化说完了应用开发中的UI性能问题后我们就该来关注应用开发中的另一个重要、严重、非常重要的性能问题了，那就是内存性能优化分析。Android其实就是嵌入式设备，嵌入式设备核心关注点之一就是内存资源；有人说现在的设备都在堆硬件配置（譬如国产某米的某兔跑分手机、盒子等），所以内存不会再像以前那么紧张了，其实这句话听着没错，但为啥再牛逼配置的Android设备上有些应用还是越用系统越卡呢？这里面的原因有很多，不过相信有了这一章下面的内容分析，作为一个移动开发者的你就有能力打理好自己应用的那一亩三分地内存了，能做到这样就足以了。关于Android内存优化，这里有一篇Google的官方指导文档，但是本文为自己项目摸索，会有很多不一样的地方。
3-1 Android内存管理原理系统级内存管理：
Android系统内核是基于Linux，所以说Android的内存管理其实也是Linux的升级版而已。Linux在进程停止后就结束该进程，而Android把这些停止的进程都保留在内存中，直到系统需要更多内存时才选择性的释放一些，保留在内存中的进程默认（不包含后台service与Thread等单独UI线程的进程）不会影响整体系统的性能（速度与电量等）且当再次启动这些保留在内存的进程时可以明显提高启动速度，不需要再去加载。
再直白点就是说Android系统级内存管理机制其实类似于Java的垃圾回收机制，这下明白了吧；在Android系统中框架会定义如下几类进程、在系统内存达到规定的不同level阈值时触发清空不同level的进程类型。

文章图片

可以看见，所谓的我们的Service在后台跑着跑着挂了，或者盒子上有些大型游戏启动起来就挂（之前我在上家公司做盒子时遇见过），有一个直接的原因就是这个阈值定义的太大，导致系统一直认为已经达到阈值，所以进行优先清除了符合类型的进程。所以说，该阈值的设定是有一些讲究的，额，扯多了，我们主要是针对应用层内存分析的，系统级内存回收了解这些就基本够解释我们应用在设备上的一些表现特征了。
应用级内存管理：
在说应用级别内存管理原理时大家先想一个问题，假设有一个内存为1G的Android设备，上面运行了一个非常非常吃内存的应用，如果没有任何机制的情况下是不是用着用着整个设备会因为我们这个应用把1G内存吃光然后整个系统运行瘫痪呢？
哈哈，其实Google的工程师才不会这么傻的把系统设计这么差劲。为了使系统不存在我们上面假想情况且能安全快速的运行， Android的框架使得每个应用程序都运行在单独的进程中（这些应用进程都是由Zygote进程孵化出来的，每个应用进程都对应自己唯一的虚拟机实例）；如果应用在运行时再存在上面假想的情况，那么瘫痪的只会是自己的进程，不会直接影响系统运行及其他进程运行。
既然每个Android应用程序都执行在自己的虚拟机中，那了解Java的一定明白，每个虚拟机必定会有堆内存阈值限制（值得一提的是这个阈值一般都由厂商依据硬件配置及设备特性自己设定，没有统一标准，可以为64M，也可以为128M等；它的配置是在Android的属性系统的/system/build.prop中配置dalvik.vm.heapsize= 128m即可，若存在dalvik.vm.heapstartsize则表示初始申请大小），也即一个应用进程同时存在的对象必须小于阈值规定的内存大小才可以正常运行。
接着我们运行的App在自己的虚拟机中内存管理基本就是遵循Java的内存管理机制了，系统在特定的情况下主动进行垃圾回收。但是要注意的一点就是在Android系统中执行垃圾回收（ GC）操作时所有线程（包含UI线程）都必须暂停，等垃圾回收操作完成之后其他线程才能继续运行。这些GC垃圾回收一般都会有明显的log打印出回收类型，常见的如下：

GC_MALLOC——内存分配失败时触发；
GC_CONCURRENT——当分配的对象大小超过一个限定值（不同系统）时触发；
GC_EXPLICIT——对垃圾收集的显式调用(System.gc()) ；
GC_EXTERNAL_ALLOC——外部内存分配失败时触发；

通过上面这几点的分析可以发现，应用的内存管理其实就是一个萝卜一个坑，坑都一般大，你在开发应用时要保证的是内存使用同一时刻不能超过坑的大小，否则就装不下了。
3-2 Android内存泄露性能分析有了关于Android的一些内存认识，接着我们来看看关于Android应用开发中常出现的一种内存问题—-内存泄露。
3-2-1 Android应用内存泄露概念
众所周知，在Java中有些对象的生命周期是有限的，当它们完成了特定的逻辑后将会被垃圾回收；但是，如果在对象的生命周期本来该被垃圾回收时这个对象还被别的对象所持有引用，那就会导致内存泄漏；这样的后果就是随着我们的应用被长时间使用，他所占用的内存越来越大。如下就是一个最常见简单的泄露例子（其它的泄露不再一一列举了）：

< code class= " hljs java has-numbering" > public final class MainActivity extends Activity { private DbManager mDbManager; @ Override protected void onCreate (Bundle savedInstanceState) { super .onCreate(savedInstanceState); setContentView(R.layout.activity_main); //DbManager是一个单例模式类，这样就持有了MainActivity引用，导致泄露 mDbManager = DbManager.getInstance( this ); } }< /code> < ul style= " opacity: 0.645695; " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < li> 8< /li> < li> 9< /li> < li> 10< /li> < li> 11< /li> < li> 12< /li> < /ul> < ul style= " " class= " pre-numbering" > < li> 1< /li> < li> 2< /li> < li> 3< /li> < li> 4< /li> < li> 5< /li> < li> 6< /li> < li> 7< /li> < li> 8< /li> < li> 9< /li> < li> 10< /li> < li> 11< /li> < li> 12< /li> < /ul>

可以看见，上面例子中我们让一个单例模式的对象持有了当前Activity的强引用，那在当前Acvitivy执行完onDestroy()后，这个Activity就无法得到垃圾回收，也就造成了内存泄露。
内存泄露可以引发很多的问题，常见的内存泄露导致问题如下：

应用卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC） ;
应用被从后台进程干为空进程（上面系统内存原理有介绍，也就是超过了阈值）；
应用莫名的崩溃（上面应用内存原理有介绍，也就是超过了阈值OOM）；

造成内存泄露泄露的最核心原理就是一个对象持有了超过自己生命周期以外的对象强引用导致该对象无法被正常垃圾回收；可以发现，应用内存泄露是个相当棘手重要的问题，我们必须重视。
3-2-2 Android应用内存泄露察觉手段
知道了内存泄露的概念之后肯定就是想办法来确认自己的项目是否存在内存泄露了，那该如何察觉自己项目是否存在内存泄露呢？如下提供了几种常用的方式：

察觉方式	场景
AS的Memory窗口	平时用来直观了解自己应用的全局内存情况，大的泄露才能有感知。
DDMS-Heap内存监测工具	同上，大的泄露才能有感知。
dumpsys meminfo命令	常用方式，可以很直观的察觉一些泄露，但不全面且常规足够用。
leakcanary神器	比较强大，可以感知泄露且定位泄露；实质是MAT原理，只是更加自动化了，当现有代码量已经庞大成型，且无法很快察觉掌控全局代码时极力推荐；或者是偶现泄露的情况下极力推荐。

AS的Memory窗口如下，详细的说明这里就不解释了，很简单很直观（使用频率高）：

文章图片

DDMS-Heap内存监测工具窗口如下，详细的说明这里就不解释了，很简单（使用频率不高）：

文章图片

dumpsys meminfo命令如下（使用频率非常高，非常高效，我的最爱之一，平时一般关注几个重要的Object个数即可判断一般的泄露；当然了， adb shell dumpsys meminfo不跟参数直接展示系统所有内存状态）：

文章图片

leakcanary神器使用这里先不说，下文会专题介绍，你会震撼的一B。有了这些工具的定位我们就能很方便的察觉我们App的内存泄露问题，察觉到以后该怎么定位分析呢，继续往下看。
3-2-3 Android应用内存泄露leakcanary工具定位分析
leakcanary是一个开源项目，一个内存泄露自动检测工具，是著名的GitHub开源组织Square贡献的，它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心，缺点在于还存在一些bug，不过正常使用百分之九十情况是OK的，其核心原理与MAT工具类似。
关于leakcanary工具的配置使用方式这里不再详细介绍，因为真的很简单，详情点我参考官方教程学习使用即可。
PS：之前在优化性能时发现我们有一个应用有两个界面退出后Activity没有被回收（ dumpsys meminfo发现一直在加），所以就怀疑可能存在内存泄露。但是问题来了，这两个Activity的逻辑十分复杂，代码也不是我写的，相关联的代码量也十分庞大，更加郁闷的是很难判断是哪个版本修改导致的，这时候只知道有泄露，却无法定位具体原因，使用MAT分析解决掉了一个可疑泄露后发现泄露又变成了概率性的。可以发现，对于这种概率性的泄露用MAT去主动抓取肯定是很耗时耗力的，所以决定直接引入leakcanary神器来检测项目，后来很快就彻底解决了项目中所有必现的、偶现的内存泄露。
总之一点，工具再强大也只是帮我们定位可能的泄露点，而最核心的GC ROOT泄露信息推导出泄露问题及如何解决还是需要你把住代码逻辑及泄露核心概念去推理解决。
3-2-4 Android应用内存泄露MAT工具定位分析
Eclipse Memory Analysis Tools（点我下载）是一个专门分析Java堆数据内存引用的工具，我们可以使用它方便的定位内存泄露原因，核心任务就是找到GC ROOT位置即可，哎呀，关于这个工具的使用我是真的不想说了，自己搜索吧，实在简单、传统的不行了。
PS：这是开发中使用频率非常高的一个工具之一，麻烦务必掌握其核心使用技巧，虽然Android Studio已经实现了部分功能，但是真的很难用，遇到问题目前还是使用Eclipse Memory Analysis Tools吧。
原谅我该小节的放荡不羁！！！！（其实我是困了，呜呜！）
3-2-5 Android应用开发规避内存泄露建议
有了上面的原理及案例处理其实还不够，因为上面这些处理办法是补救的措施，我们正确的做法应该是在开发过程中就养成良好的习惯和敏锐的嗅觉才对，所以下面给出一些应用开发中常见的规避内存泄露建议：