码迷,mamicode.com
首页 > 移动开发 > 详细

Android Studido下的应用性能优化总结-内存优化

时间:2016-04-24 12:50:20      阅读:309      评论:0      收藏:0      [点我收藏+]

标签:

转载请标明出处(请勿转载删除底部微博、微信等信息):
http://blog.csdn.net/Y1258429182/article/details/51176424
本文出自:杨哲丶的博客

上一篇文章总结的布局优化的问题,如果对布局优化不是很熟悉的,可以看一下Android Studido下的应用性能优化总结–布局优化 , 这周一直筹划总结一下内存优化的问题,因为现在对于应用优化的文章很多,但是还是想完善一下才想分享这篇文章的,我会从项目中遇到的一个问题,通过解决问题的过程来分享知识,希望大家有所收获。

“A small leak will sink a great ship.” - Benjamin Franklin
小楼不修补,大船也会翻。——本杰明 富兰克林


出现的问题(What)

  • 场景(Scene): Y君某年某月某日碰到一个奇怪的问题:A页面跳转到B页面,然后跳转到其他页面没有问题,但是在A跳转B,然后B跳转到A页面,就开始发生卡顿,程序也不崩溃!!OMG,这是什么问题,Y君当时确实有点懵逼了,这是肿么一个情况,但是Y君毕竟也是上过刀山下过火海,在bug堆里走出来的人(突然想起了那句话,我要成为海贼王的男人…),扯远了,还是回到问题上来.

分析问题(Why)

由于出现卡顿现象,大部分都出自内存的问题上,所以我们开始分析自己应用的内存使用情况,但是问题来了,用什么工具查看应用的内存使用情况?
因为以前Ecliplse的内存查看略显繁琐,而且Goole推出的新的开发工具Android Studio,有很多我们方便我们安卓开发程序猿调试和分析问题,在这里我就介绍一下Android Studio中的内存分析工具Memory,如果不熟悉的可以按照箭头指示,点击应用相对应的包名,就可以查看该应用内存情况,分析截图如下
技术分享

  • Y君处理内存还是有稍许经验的,不急不缓的亮出自己珍藏已久的内存分析三剑客:
    1. LeakCanary
    2. Memory Analyzer Tool(MAT)
    3. TraceView
  • 那么我们开始分析问题出在哪里吧 ,Are You Ready? Go!

LeakCanary的使用方法

LeakCanary的GitHub地址
工具介绍:LeakCanary是Square开源的一个内存泄露自动探测神器,它是一个Android和Java的内存泄露检测库,可以大幅度减少了开发中遇到的OOM问题,对于安卓开发者来说,无疑是个福音。
GitHub里边介绍的已经很详细了,我这里也简短的介绍一下使用方法!
在项目的build.gradle文件添加:

 dependencies {
   debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.4-beta2‘
   releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2‘
   testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2‘
 }

在Application里边初始化

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    LeakCanary.install(this);
  }
}

当正常接入的情况下,测试应用出现内存不足的时候会接受到通知,截图如下

技术分享

但是Y君的这个bug出现这种分析,没有接到通知,截图如下

技术分享

  • Leakcanary是的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心,缺点在于还存在一些bug,不过正常使用百分之九十情况是OK的,然后我就成了那百分之十,具体问题我也不清楚,但是不妨碍这是一个很好的检查工具。

Memory Analyzer Tool(MAT)的使用方法

MAT独立版内存检测工具下载

工具介绍:MAT(Memory Analyzer Tool)工具在分析 大内存的dump文件时,可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询,以及可以很方便的找出对象GC Roots的相关信息,当然最吸引人的还是能够快速为开发人员生成内存泄露报表,方便定位问题和分析问题。

测试Demo:我写了一个Demo来模拟当时我遇到的情况!让计时器一直发送消息到Handler刷新时间,代码如下

 private void getCurrentTime() {
        //为了测试更加明显
        new Thread() {

            @Override
            public void run() {
                super.run();
                while (flag) {
//                    SystemClock.sleep(1000);
                    long endTime = System.currentTimeMillis();
                    long time = endTime - mStartTime;
                    String result = new SimpleDateFormat("mm:ss").format(new Date(time));
                    Message message = handler.obtainMessage();
                    message.what = MessageConstants.UPDATETIMEFLAG;
                    mFinallyTime = result;//为了跳转携带数据
                    message.obj = result;
                    handler.sendMessage(message);
                }
            }
        }.start();
    }
  • 步骤一:我只讲Android Studio下如何抓取内存使用的情况,点击左上角的箭头提示,会抓取你相对应的位置的内存使用情况,如图4
    技术分享
  • 步骤二:稍等一会,生成的文件会出现在captures中,然后选择文件,点击右键转换成标准的hprof文件,就可以在MAT中打开了。
    技术分享
    再次我解释一下,MAT分两种类型,一种是用于Eclispse插件版,一种是独立版,因为我们用是Android Studio所以只能使用用独立版的MAT.
  • 步骤三:在MAT中打开抓取到的文件后,截图如下
    技术分享
    MAT中提供了非常多的功能,这里我们只要学习几个最常用的就可以了。上图最中央的那个饼状图展示了最大的几个对象所占内存的比例,这张图中提供的内容并不多,我们可以忽略它。
    图片中红色框有使我们经常使用的模块,它们的职责分别是:
  • Histogram可以列出内存中每个对象的名字、数量以及大小。
  • Dominator Tree会将所有内存中的对象按大小进行排序,并且我们可以分析对象之间的引用结构。

MAT中的Dominator Tree 的分析

现在点击Dominator Tree,截图如下:
技术分享
这张图包含的信息非常多,我来带着大家一起解析一下。首先Retained Heap表示这个对象以及它所持有的其它引用(包括直接和间接)所占的总内存,因此从上图中看,前两行的Retained Heap是最大的,我们分析内存泄漏时,内存最大的对象也是最应该去怀疑的。
另外大家应该可以注意到,在每一行的最左边都有一个文件型的图标,这些图标有的左下角带有一个红色的点,有的则没有。带有红点的对象就表示是可以被GC Roots访问到的,根据上面的讲解,可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗?当然不是,因为有些对象系统需要一直使用,本来就不应该被回收。我们可以注意到,上图当中所有带红点的对象最右边都有写一个System Class,说明这是一个由系统管理的对象,并不是由我们自己创建并导致内存泄漏的对象。
那么上图中就无法看出内存泄漏的原因了吗?确实,内存泄漏本来就不是这么容易找出的,我们还需要进一步进行分析。上图当中,除了带有System Class的行之外,最大的就是第一行的MessageQueue对象了,虽然MessageQueue对象现在不能被GC Roots访问到,但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GC Roots -> exclude weak references,为什么选择exclude weak references呢?因为弱引用是不会阻止对象被垃圾回收器回收的,所以我们这里直接把它排除掉,结果如下图所示:
技术分享
最终我们找到了罪魁祸首,开启的很多个线程,while死循环没有停止,我跳转的时候也没把循环关掉,所以有这么多的Thread。

MAT中的Histogram 的分析

首先我们学习一下Histogram的用法,回到Overview界面,点击Histogram,结果如下图所示
技术分享
这里是把当前应用程序中所有的对象的名字、数量和大小全部都列出来了,需要注意的是,这里的对象都是只有Shallow Heap而没有Retained Heap的,那么Shallow Heap又是什么意思呢?就是当前对象自己所占内存的大小,不包含引用关系的,比如说上图当中,String对象的Shallow Heap最高,说明我们应用程序中用了很多String类型的数据,我们不断的发送Handler不断的创作String对象。可以通过右键 -> List objects -> with incoming references来查看具体是谁在使用这些String,分析如图下,发现然并卵。
技术分享
那么通过Histogram又怎么去分析内存泄漏的原因呢?当然其实也可以用和Dominator Tree中比较相似的方式,即分析大内存的对象,比如上图中byte[]对象内存占用很高,我们通过分析byte[],最终也是能找到内存泄漏所在的,但是这里我准备使用另外一种更适合Histogram的方式。大家可以看到,Histogram中是可以显示对象的数量的,那么比如说我们现在怀疑MainActivity中有可能存在内存泄漏,就可以在第一行的正则表达式框中搜索“MainActivity”,如下所示:
技术分享
可以看到,这里将包含“MainActivity”字样的所有对象全部列出了出来,其中第一行就是MainActivity的实例。但是大家有没有注意到,当前内存中是有30个MainActivity的实例的,这太不正常了,通过情况下一个Activity应该只有一个实例才对。其实这些对象就是由于我们刚才不断地横竖屏切换所产生的,因为横竖屏切换一次,Activity就会经历一个重新创建的过程,但是由于LeakClass的存在,之前的Activity又无法被系统回收,那么就出现这种一个Activity存在多个实例的情况了。

接下来对着MainActivity右键 -> List objects -> with incoming references查看具体MainActivity实例,如下图所示
技术分享
发现跟上边的效果一样,但是对比起来上边的方法比较方便,如果你无法判断是哪一个Acitivity出的问题,你就无法处理了,所以推荐用Dominator Tree分析问题。
总结: 这大概就是MAT工具最常用的一些用法了,当然这里还要提醒大家一句,工具是死的,人是活的,MAT也没有办法保证一定可以将内存泄漏的原因找出来,还是需要我们对程序的代码有足够多的了解,知道有哪些对象是存活的,以及它们存活的原因,然后再结合MAT给出的数据来进行具体的分析,这样才有可能把一些隐藏得很深的问题原因给找出来。

TraceView的使用方法

借鉴了许多关于TraceView的分析,发现都是抄来抄去,最终都是一种解决办法,不是针对各种问题解决问题,针对我这次碰到的这个问题,我慢慢琢磨了这么工具的使用,发现直接可以分析出具体那个方法占用CPU的时间,个人认为从CPU角度思考内存优化,可以考虑使用这个工具来分析。
如何使用打开DDMS,然后如图
技术分享
先按下Start Method Profiling(箭头1标的位置),然后过一会可以按Stop Method Profiling,然后出现这种跟答题卡一样的,我们只看下部分的分析
技术分享
显而易见,分析Intel Cpu Time 属性,点击它按照从大到小的排序后,我们清晰发现run()方法居然占了93%的CPU运行内存,并且直接具体到哪一个类里边的方法。剩下的一些属性估计有用,在这里我也就不一一介绍了!如果你想详细了解,点击文章最后的参考链接即可。

解决问题(How)

通过这三种方法分析的分析结果:
1. LeakCanary反馈的信息没有,无法分析
2. Memory Analyzer Tool(MAT)反馈的信息是MainAcitity中创建了很多的Thread,可以直接分析到死循环的毛病
3. TraceView通过CPU的使用情况非常直观的显示出,MainAcitivity中的run()方法占用95%的使用,干净利索的分析出问题的所在

最后解决办法:加1s的sleep时间,A跳转到B页面的时候,关掉循环!!

总结

文章也写到了最后:
如果遇到卡顿问题的时候,推荐分析的步骤:
1. 先用Memory产看内存使用情况
2. 在用LeakCanary看是否能直接分析出那一个类出的错误
3. 如果LeakCanary分析的步骤不够清晰,导出文件用MAT具体分析
4. 如果在MAT你也没有检查出哪里出的错误,可以尝试TraceView来分析内存使用情况,因为他可以具体到哪一个方法。

参考文章:
1. Android最佳性能实践(二)——分析内存的使用情况
2. 正确使用Android性能分析工具——TraceView
3. Android性能优化之被忽视的Memory Leaks


欢迎关注我的微博:
http://weibo.com/u/5345060833

关注微信公众号:YangZheShare
(欢迎关注,最新最实用的技术干货分享)
技术分享

Android Studido下的应用性能优化总结-内存优化

标签:

原文地址:http://blog.csdn.net/y1258429182/article/details/51176424

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!