Android应用性能优化之分析工具[二]

Android应用性能优化之分析工具

　　上一次记录了解决过分绘制的过程，这一次，想先弄清个概念性的东西，就是如何判断顺不畅？

　　这东西其实最初我本身也以为有点废话，用起来会卡就明显是不畅咯。

　　但这东西就跟我很想吐槽不少应用同样，明明那么卡还放出来同样的道理。

理论永远是理论，实践才是第一辈子产力。

 

　　由于我本身的应用也能感受到卡顿，如今回头分析，能明白，卡顿永远不是“用心的程序员”本来的初衷，但不少东西，真心是难言之隐。

　　知错就改才是好人...因此要改，就要知道究竟错在哪。

 

　　 一、纵观全局

　　对于顺畅度的分析，首先要知道一个总体状况，是局部，仍是全局，这样在优化上才能有方向。

　　若是是局部问题，那就须要仔细分析出具体的相关操做，若是是大致上的问题，那在思考的时候，就须要从总体的实现机制来考虑，有多是实现方式上出现了问题。

　　在android4.1中，谷歌提供了一个工具来，叫作“  GPU呈现模式分析(Profile GPU rendering) ”，在开启这个功能后，系统就会记录保留每一个界面最后128帧图像绘制的相关时间信息。

　　若是是在开启应用后才开启此功能，记得先把应用结束后从新启动。

　　开启后操做你须要分析的部分（好比滑动列表之类的），而后执行adb命令

　　$ adb shell dumpsys gfxinfo com.xxxx.xxx

在执行的结果中，有一块叫作“Profile data in ms”底下有一堆数据.

 

　　Draw:表示在Java中建立显示列表部分中，OnDraw()方法占用的时间。

　　Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长

　　Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。实际上是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。因此这个时间，通常都很短。

 

　　PS：View类包含Surface（变量名mSurface），每一个Surface一般对应两个buffer，一个front buffer, 一个back buffer。(4.1以后是3个，一个前，两个后)其中，back buffer就是canvas绘图时对应的bitmap (研究 Android_view_Surface.cpp::lockCanvas)。所以，绘画老是在back buffer上，须要更新时，则将back buffer和front buffer互换。

 

　　Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保存每秒60帧。

 

　　将数据复制到excel中（win记得逐列复制，mac下就直接复制过去吧），而后将数据生成“堆积柱形图”

 

　　从图上看，能看出几个现象。第一，确实4.1的黄油项目还真的有点做用，每帧的时间控制在16ms左右。第二，有几帧超过16ms，确实会有丢帧的现象。

　　看来，页面的卡顿应该是个别操做的问题。

 

　　但这种数据是否还能看出其余问题呢？

　　按照3个数据分别标示的内容，理论来说，若是UI线程占用的时间过长，Draw的时间数据会应该会很长，因此作了个实验，在UI线程中睡了1S。获得了下面这个图。

 

　　从图上看有几帧Draw部分异常的高就能看出，Draw部分能看出UI线程的大致使用状况。

　　

　　固然，其实这个数据主要能看出的是总体状况，单独的某个部分跟测试的环境也有很大关系，好比一下2组数据，都是instagram的，一样的数据，上面是Desire Z 4.1系统，下面是盖3 4.1系统，在Execute部分，二者有明显的差距。

 

 

二、具体分析

　　“GPU呈现模式分析”的数据只能说明个现象，好比上面提到的数据，能说明在实际运行中会有短暂的长时间绘制问题。但形成问题的具体缘由并无说明。

　　并且“GPU呈现模式分析”显示的是最后128帧的数据，但丢帧也有多是两帧之间存在长时间的操做而形成的。 　　

　　因此咱们须要分析帧与帧之间的状况，才能对所分析应用的总体性能状况有个更升入的了解。

　　在android中提供了两个工具来达到这个目的：一、Systrace  (这工具坑的我....等下再吐槽) 二、t raceview

 

　　

　　Systrace是对整个系统进行分析，数据比较准确，固然也包括咱们所要分析的应用。

当这个工具的使用是有条件限制的：

　　（1）是4.1以后才提供的工具。

　　（2）手机的内核必定要支持trace（能够查看是否存在 /sys/kernel/debug/tracing 这个目录 ），因此不少第三方ROM或者三星之类的rom都在内核中remove了这个模块。模拟器里面好像也都没有。[这个坑的我刷了无数多的rom才找到适合的...以前的one x我记得好像也有，这个也间接说明一点，做为开发者，仍是乖乖的买亲儿子好]

 

　　Systrace的运行方式有两种，一种是运行sdk包下的py文件，这种要求的环境配置比较多。另外一种就是在adt下的工具，点击直接运行。因此下面的使用介绍主要是这种。

　　

 

 

 

　　在流畅程度的这种特殊分析情景下，咱们通常只关注图形性能。因此咱们要选择Graphics和View.还有其余不少选项，若是是在作音频处理或者视频播放的分析测试话，能够选择其余选项。　　

　　确认运行以后，滚轮咱们要测试的列表，工具会记录5秒钟的数据，以后咱们回获得一个html页面。打开后，咱们能看到页面中显示了系统中一切运行状况的概述。

 

　　浏览的操做时经过WASD来完成，W/S 放大/缩小 A/D 左移/右移

 

　　页面中有个surfaceFlinger， 知道android绘制原理的人应该能明白，这个就是负责绘制Android应用程序UI的服务，因此surfaceFlinger能反应出总体绘制情 况，通常正常状况都是连续的，若是出现空档，一种是没有操做或者滑动到头，没东西须要绘制，这种属于正常，另外一种就是有问题存在，有其余操做时间过长。

 

　　对应所要分析的程序那行，放大后就能看到具体的状况，点击后能看到每一个部分所使用的时间。

　　好比

　　deliverInputEvent是系统提供的触摸事件。

　　performTraversals是开始布局而且绘画显示画面的过程。

　　draw是绘画的过程。

　　...

 

　　对于一个listview，若是deliverInputEvent过长，颇有多是在adapter中的getView方法中处理时间过长致使。

 

　　因此经过 Systrace的数据，能够大致上的发现是否存在性能问题。

　　但若是要知道具体状况，就须要用到另一个工具。

 

　　 traceview

　　这个工具其实比较简单，是一个分析器，记录了应用程序中每一个函数的的执行时间。在DDMS中，选中要分析的进场，点击 “Start method profiling”（就是右上角有个红点的图标）。而后开始操做要分析的应用，而后再次点击按钮来中止跟踪。　　

　　而后下面显示的数据应该挺通俗易懂的。

　　具体的能够参见：http://hubingforever.blog.163.com/blog/static/17104057920112825035143/

　　这里我想介绍下我使用的一个经验。 

　　ViewRootImpl.draw()，这个是绘制函数，点击后，绘制的部分就会被突出出来。从理论上讲，只要操做时没有太多停顿，draw()的图示应该是较为连续的。而且要保持顺畅，每个draw区域应该在16ms及如下。

因此一旦看到区域有大于16ms的，就能够认真分析下，看看都作了些什么操做。从而找到致使绘制时间过长的问题所在。

 

　　对于这些工具的使用，虽然很大程度上可以帮助咱们更快的定位到问题之处，但仍是有许多局限的地方。

　　若是对android总体系统原理有必定的理解，而且深入知道本身的程序的运转状况，这样分析起来，才会炉火纯青。

 

　　以上是我我的的一些见解，但愿能帮助到你们，没写的太细，够用就好，由于有些部分，本身也有不少疑问，找到了一堆资料，发现也没有说明的特别详细的地方。

 

　　如下是参考的一些地方，你们能够去看看，有些须要走出去（怎么出去这东西每一个程序员都会吧？）：

　　 http://www.youtube.com/watch?v=Q8m9sHdyXnE（google IO的，需翻）　　

　　 http://udinic.wordpress.com/2013/03/04/android-app-to-the-challenge/ (

需翻)

　　 http://www.curious-creature.org/docs/android-performance-case-study-1.html ( 需翻)

　　 http://blog.chengyunfeng.com/?p=458（这个是上面的中文翻译） 　　

　　 http://www.linuxidc.com/Linux/2010-10/29168.htm