使用Android Studio分析内存问题

大家好!本人是即将毕业学生一枚,闲暇时间经常看大神们写的博客学到很多东西。最近在做毕业设计的时候遇到一些问题,然后把自己的问题和解决方法总结一下,有不对的地方希望大家多多包涵,提出批评与指导。

这篇博文主要介绍使用AndroidStudio对内存进行分析和跟踪,还有就是从源码角度解决ImageLoader引起的OOM问题。

我正在做的项目使用到了ImageLoader来加载图片,我也是第一次使用,就拿来直接用了。写完的代码运行很正常的加载图片,并没有发现什么问题。但是在测试的时候发现了问题。当多次打开软件中一个浏览大图片的Activity(每次的图片都不一样)后,这时在这个Activity中点击返回后,屏幕会突然变黑,然后回到了MainActivity,并没有回到上一级Activity,甚至连之间打开的多个Activity都没有返回。想了一下问题怀疑可能是重启了这个应用。但那个大图片的Activity开始打开的几次都可以正常的回到上一级Activity,再多打开几次就不能正常回退了,这时候我就开始看LogCat打出的日志,看看有没有发生什么异常。发现ImageLoader产生了OOM的Bug。如下图:

<img alt="OOM" src="https://www.2cto.com/uploadfile/Collfiles/20160506/20160506090821420.png" title="" kf="" ware="" vc="" "="" target="_blank" class="keylink" style="border-width: 0px; padding: 0px; margin: 0px auto; list-style: none; display: block; max-width: 630px; cursor: pointer; width: 630px; height: 54.8323px;">vc+086Osvs3Du9PQs6LK1FZvbGxleb/yvNyho7u509DIy8u1ysfTps6qyrnTw8HLY2FjaGVJbk1lbW9yeaOodHJ1ZaOpus1jYWNoZU9uRGlzY6OodHJ1ZaOp1eLBvbj2yvTQ1LW81sK1xKOstavKx87SvavL+8PHyejOqmZhbHNlu7nKx7vh0v23ok9PTaOsy/nS1L7N19S8utPDuaS+37fWzvahozxiciAvPg0KvMjIu7L6yfrBy09PTaOsztLDx77N0qq31s72xNq05qOsv7S/tL7fzOXKx8qyw7TUrdLytbzWwrXEoaPKudPDPGEgY2xhc3M9"replace_word" href="http://lib.csdn.net/base/15" target="_blank" title="undefined">AndroidStudio工具(发现很多地方都比eclipse强大),在使用AndroidStudio的Memory工具观察的时候发现了问题,在我多次打开这个Activity的时候,发现Memory在一直的增长,每次Activity退出后Memory也没有下降。

内存上升图

就这样当我多次浏览不同的图片,多次打开这个Activity后,这个Memory就一直的增长,当增长到120+M的时候应用突然挂掉,之后又自动重启。发现了这个现象我们就可以借助AndroidStudio的强大工具来分析导致这个问题的原因。在Memory窗口的左边有四个按钮,分别是:
Enabled(蓝色的开关):就是一个正常的开关功能
Initiate GC(橙色小卡车):就是手动调用GC,我们在抓内存前,一定要手动点击 Initiate GC按钮手动触发GC,这样抓到的内存使用情况就是不包括Unreachable对象的(Unreachable指的是可以被垃圾回收器回收的对象,但是由于没有GC发生,所以没有释放,这时抓的内存使用中的Unreachable就是这些对象)
Dump Java Heap(紫色带向下的箭头):获取hprof文件(hprof文件是我们使用MAT工具分析内存时使用的文件),但这里直接产生的文件MAT还不能直接使用,需用转换成标准的hprof文件。可以使用AndroidStudio转换或者用hprof-conv命令转化,网上可以查到。
Start Allocation Tracking(紫色带圆圈):开始分配追踪,第一次点击可以指定追踪内存的开始位置,第二次点击可以结束追踪的位置。这样我们截取了一段要分析的内存,等待几秒钟AndroidStudio会给我们打开一个Allocation视图(感觉和MAT工具差不多,不过MAT工具更加强大,我们也可以获取hprof文件,使用MAT来分析)例如下图:

我截取了这段内存,接下来我们就看Allocation视图来分析。

\

通过视图中的内容我们首先看到1号线程它占用了百分之92的内存,那么我们就点开它看一下,每次都只要点开其中内存占用最大的就可以。

\

到划红线的那个位置就可以了,这里已经到了安卓的graphics源码的层次,所以我们不需要再向下看了。我们看一下红线上面的ImageLoader里的那个decodeStream方法:
decodeStream

它里面就是调用了BitmapFactory.decoceStream()方法然后返回了一个Bitmap对象。基本上已经可以确定占用如此多内存的就是Bitmap对象,那么我们只要将这个Bitmap释放掉就可以了。那么就接着分析看看在什么地方释放,我们看一下最上面的ImageLoader.core包下的LoadAndDisplayImageTask类的run()方法,发现里面有一个Bitmap对象,他是调用了内部tryLoadBitmap()方法给赋值的,而这个方法最后其实就是我们上面看到的调用的decodeStream方法返回的Bitmap。应为这之间的Bitmap都是方法里的局部变量所以我们不用考虑这些Bitmap的释放,那就接着向下看,发现这个Bitmap被传到了DisplayBitmapTask这个类中,那么我们再进入到这个类中看发现了一个惊喜:

DisplayBitmapTask

这个对象被传到了DisplayBitmapTask的成员变量中,DisplayBitmapTask本身也实现了Runnable接口,那么我就想是不是应为DisplayBitmapTask这个类没有及时回收导致的Bitmap成员变量占用内存的问题,所以我就在run()方法跑完之后,让Bitmap = null。然后又将程序运行了一遍,但是发现根本没有解决这个问题。这时候又重头想了一下整个过程,发现我的操作是不对的,虽然我成功将DisplayBitmapTask中的Bitmap成员变量置为了空,但是他只是真正的Bitmap内存的一个引用,我并没有将真正的Bitmap内存空间所释放,只是将他的一个引用给释放了。通过网上查询发现,Bitmap会保存在C层的内存中,如果我们想要释放他在C层中的内存,可以调用Bitmap的recycle()方法,从代码中看,这个方法本身会调用Bitmap.cpp中的Bitmap_recycle方法,这个是native方法。这样就可以通知底层将C层中的Bitmap内存释放掉,而且还会将一些相关的引用计数置0。但是并不会立即释放掉,这要看系统。 一下子完美解决。既然查到了原因,那就好办了,我将Bitmap = null这句话改为Bitmap.recycle()。好了,接下来我再次运行,发现这回应用直接就崩了,只要能在Logcat中抓到Log,一切问题都好解决。看了一下log发现下面这个Error:

error

通过字面理解的意思就是,我们的View去显示了已经recycle的Bitmap。仔细想一想确实是,我们在ImageLoader中的一个线程的run方法中直接将Bitmap释放掉了,那我们的应用岂不是直接显示一个空的Bitmap,这当然会引起错误。既然不能在这里释放掉Bitmap,那我们应该在什么地方释放呢?那一定是在我们的View不再使用这个Bitmap的时候调用,想一想,那我们只要在Activity或者fragment的onDestory()方法中释放了不就可以了吗?但这时又有一个问题产生,我们该如何在上层应用获取到这个View用到的Bitmap的对象呢?想了半天发现好像只能通过改写ImageLoader的源码来想办法将这个对象会传到上层应用。正当我在ImageLoader中寻找在哪里写这个回调方法时,突然我看到了这段代码:

这里写图片描述

发现其实ImageLoader的源码中已经为我们写好了这个回调监听器接口,而且在ImageLoader的displayImage方法中,也重载了一个提供了传递ImageLoaderListener实现对象的方法。这样我们只需要实现ImageLoaderListener这个接口,并实现他的onLoadingComplete方法,在这个方法中对Bitmap做处理就可以了。

这里写图片描述

我们只需要在Activity或Fragment的onDestory()方法中再调用cleanBitmapList()方法就可以了。通过上面的更改我再次运行应用,发现真的解决了这个问题,我的应用内存不再会是一直的上升,而是上升之后又会下降。如图:

这里写图片描述

注:这个方式比较适合cacheInMemory(false)和cacheOnDisc(false)的情况写,应为如果你将这两个设置为true时,那么下次再次加载图片时他会从内存和硬盘中去加载图片,这两个地方也持有Bitmap的引用,这时就会再次出现trying to use a recycled bitmap 这个错误。当然你也是可以设置为true的,只要在清除Bitmap(也就是我们这里调用cleanBitmapList)的地方再加上mImageLoader.clearDiscCache()和mImageLoader.clearMemoryCache()这两句话就可以。

好了,整个ImageLoader引起的OOM问题额分析与解决的过程就是这些,希望能对需要的人有帮助,通过这个问题我也学会到,遇到问题最好的解决办法就是我们要从最根本源码的角度去分析,这样既能学到很多东西,又可以解决困难问题。

展开阅读全文

没有更多推荐了,返回首页