@Tyhj
2017-05-08T17:45:41.000000Z
字数 1940
阅读 2298
Android
讲个故事,那天发现一个问题,在segmentfault上搜到一个提问:
有没有人用android做过类似的事情,其中一个activity里面一有一百多张图片,如果反复进入该activity就会导致溢出。
已经测试过**universal-imageloader**,**picasso**、**fresco**工具,都不理想,或者是我使用方法的问题。求大神指点!!
我就提问给楼主:
兄弟我最近也遇到这个问题了,也是试过universal-imageloader,picasso,fresco,请问你是怎么解决的
楼主回:
android:largeHeap="true" .....这个问题的水很深,谷歌的解决方案都不会完全没有内存泄漏的问题。
刚开始时候我怀疑是系统的问题,然后网上开始搜,发现遇到这个问题的人并不多,我猜可能是因为他们图片加载比较少。楼主给的方案我早就知道了,一看就不行,只是分配的内存多了一点而已。却发现了内存泄漏,然后怀疑是图片缓存的问题,因为这几个图片加载工具都是支持图片缓存的,于是开始搜imageloader内存泄漏,发现了《使用AndroidStudio分析和解决ImageLoader引起内存泄露问题》这篇文章。
我当时以为我找到了答案,说的很有道理,也真的有用。就是把imageloader加载后生成的bitmap给手动回收掉。
我当时回楼主:
兄弟你悲观了,我找到了一个好办法,就是昨天晚上,universal-imageloader,picasso,包括Fresco,发现他们都是存在内存泄漏,但是可以改,universal-imageloader改了以后就可以了,http://blog.csdn.net/editor19...,找了一个晚上找到的,可以用,其中会有小问题,根据下面的评论和回答就可以搞定
但是我发现这个方法相当于把图片加载工具的优点抹杀了,最骚的是
当其他页面尝试使用imageloader加载同样的图片就会发生如下问题,而且并不好解决:
Canvas: trying to use a recycled bitmap android.graphics.Bitmap
我就自己去搞,最终找到一个方法,但是也开始怀疑其他问题,因为在找答案的时候搜到很多内存泄漏的问题,而且图片加载工具肯定很成熟的,怎么可能有这种问题,我就回了楼主:
再告诉你我的解决方案吧,首先我们之前都是怀疑图片工具的锅,其实我怀疑可能不是,当然我还没有确定,等一下测一下,可能是我们自己的原因导致的内存泄露,导致那个我们重复进去Activity没有被回收,原因是里面一东西没有回收,比如Context,或者Thread,我们用adpter时候最好传getApplication进去,因为我一直在优化,没时间去确认到底是哪里的问题,我现在解决方案,是那个要加载图片的Activity,用ImageLoad来加载,退出的时候之前那个方法回收bitmap,这个Activity以外可能有和这个Activity重复的图片,这样如果外面再用IamageLoad加载图片 ,你程序会崩掉,说你在使用一个已回收的bitmap,所以这时候,这个Activity以外有重复图片的Activity,用Picasso或者其他图片加载工具,这样解决了。这个方法看起来不专业,但能行。但是最重要的是可能我们两个都傻逼了,可能是我们自己的问题导致Activity没有被回收导致的内存泄露,我等一下测一下。我前两天被这个问题折磨,网上找了很久,自己也搞了很久才搞定,只是希望可以帮到更多的人
然后我开始去测试,去掉了之前那个手动回收的方法,发现真的没问题。搞了半天是因为自己因为线程里面传入了当前Activity的Context对象导致销毁Activity的时候线程还没有关,那么将导致Activity的内存资源无法回收,造成内存泄漏。
所以说,大家都没有问题那肯定是自己的问题,这么成熟的框架,不会犯这些错误。我发现imageloader是可以自己回收内存的,缓存达到一个值以后就释放了之前的缓存了。
Context的生命周期是一个Activiy,而ApplicationContext的生命周期是整个程序。我们最要注意的就是Context的内存泄露。在Activiy的UI中要使用Context,而在其他的地方比如数据库、网络、系统服务的需要频繁调用Context的情况时,要使用ApplicationContext,以防止内存泄露。
Android内存泄漏相关文章:http://www.jianshu.com/p/c59c199ca9fa