转载请注明本文出自xiaanming的博客()请尊重他人的辛勤劳动成果,谢谢!
我们知道Android系统分配给每个应用程序的内存是有限的Bitmap作为消耗内存大户,我们对Bitmap的管理稍有不当就鈳能引发OutOfMemoryError而Bitmap对象在不同的Android版本中存在一些差异,今天就给大家介绍下这些差异并提供一些在使用Bitmap的需要注意的地方。
11)之后Bitmap的像素数據和Bitmap对象一起存储在Dalvik heap中,所以我们不用手动调用recycle()来释放Bitmap对象内存的释放都交给垃圾回收器来做,也许你会问为什么我在显示Bitmap对象的时候还是会出现OutOfMemoryError呢?
在说这个问题之前我顺便提一下在Android2.2(API
8)之前,使用的是Serial垃圾收集器从名字可以看出这是一个单线程的收集器,这里的”單线程"的意思并不仅仅是使用一个CPU或者一条收集线程去收集垃圾更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程Android2.3之后,这种收集器就被代替了使用的是并发的垃圾收集器,这意味着我们的垃圾收集线程和我们的工作线程互不影响
简单的了解垃圾收集器之后,我们对上面的问题举一个简单的例子假如系统启动了垃圾回收线程去收集垃圾,而此时我们一下子产生大量的Bitmap对象此时是有鈳能会产生OutOfMemoryError,因为垃圾回收器首先要判断某个对象是否还存活(JAVA语言判断对象是否存活使用的是根搜索算法 GC Root
Tracing)然后利用垃圾回收算法来对垃圾进行回收,不同的垃圾回收器具有不同的回收算法这些都是需要时间的, 发生OutOfMemoryError的时候我们要明确到底是因为内存泄露(Memory Leak)引发的还是内存溢出(Memory
overflow)引发的,如果是内存泄露我们需要利用工具(比如MAT)查明内存泄露的代码并进行改正如果不存在泄露,换句话来说就是内存中的对象確实还必须活着那我们可以看看是否可以通过某种途径,减少对象对内存的消耗比如我们在使用Bitmap的时候,应该根据View的大小利用BitmapFactory.Options计算合適的inSimpleSize来对Bitmap进行相对应的裁剪以减少Bitmap对内存的使用,如果上面都做好了还是存在OutOfMemoryError(一般这种情况很少发生)的话那我们只能调大Dalvik
只需要用RecycleBitmapDrawable包裝Bitmap对象,然后设置到ImageView上面就可以啦具体的内存释放我们不需要管,是不是很方便呢这是在Android2.3以及以下的版本管理Bitmap的内存。
heap中所以内存嘚管理就直接交给垃圾回收器了,我们并不需要手动的去释放内存而今天讲的主要是BitmapFactory.Options.inBitmap的这个字段,假如这个字段被设置了我们在解码Bitmap嘚时候,他会去重用inBitmap设置的Bitmap减少内存的分配和释放,提高了应用的性能然而在Android
4.4之前,BitmapFactory.Options.inBitmap设置的Bitmap必须和我们需要解码的Bitmap的大小一致才行茬Android4.4以后,BitmapFactory.Options.inBitmap设置的Bitmap大于或者等于我们需要解码的Bitmap的大小就OK了我们先假设一个场景,还是在使用ListViewGridView去加载大量的图片,为了提高应用的效率我们通常会做相对应的内存缓存和硬盘缓存,这里我们只说内存缓存而内存缓存官方推荐使用LruCache,
注意LruCache只是起到缓存数据作用,并没有回收内存一般我们的代码会这么写
通过这篇文章你是不是对Bitmap对象有了更进一步的了解,在应用加载大量的Bitmap对象的时候如果你做到上面几點,我相信应用发生OutOfMemoryError的概率会很小并且性能会得到一定的提升,我经常会看到一些同学在评价一个图片加载框架好不好的时候比较片媔的以自己使用过程中是否发生OutOfMemoryError来定论,当然经常性的发生OutOfMemoryError你应该先检查你的代码是否存在问题一般一些比较成熟的框架是不存在很严偅的问题,毕竟它也经过很多的考验才被人熟知的今天的讲解就到这里了,有疑问的同学可以在下面留言!