- 一个进程的内存可以由2个部分组成:
native和dalvik
dalvik
就是我们平常说的java
堆,我们创建的对象是在这里面分配的,而bitmap
是直接在native
上分配的。
一旦内存分配给Java
后,以后这块内存即使释放后,也只能给Java
的使用,所以如果Java
突然占用了一个大块内存,即使很快释放了,C
能用的内存也是16M减去Java
最大占用的内存数。 而Bitmap
的生成是通过malloc
进行内存分配的,占用的是C
的内存,这个也就说明了,上述的4MBitmap
无法生成的原因,因为在13M
被Java
用过后,剩下C
能用的只有3M
了。 -
在
Android
应用里,最耗费内存的就是图片资源。
在Android
系统中,读取位图Bitmap
时,分给虚拟机中的图片的堆栈大小只有8M,如果超出了,就会出现OutOfMemory
异常。 -
及时回收Bitmap的内存
- 捕获异常
在实例化Bitmap
的代码中,一定要对OutOfMemory
异常进行捕获。下面对初始化Bitmap
对象过程中可能发生的OutOfMemory
异常进行了捕获。
如果发生了异常,应用不会崩溃,而是得到了一个默认的图片。 - 缓存通用的Bitmap对象
-
压缩图片
如果图片像素过大可以将图片缩小,以减少载入图片过程中的内存的使用,避免异常发生。
使用BitmapFactory.Options.inSampleSize
就可以缩小图片。属性值inSampleSize
表示缩略图大小为原始图片大小的几分之一。
即如果这个值为2,则取出的缩略图的宽和高都是原始图片的1/2,图片的大小就为原始大小的1/4。
如果知道图片的像素过大,就可以对其进行缩小。那么如何才知道图片过大呢?
使用BitmapFactory.Options
设置inJustDecodeBounds
为true
后,并不会真正的分配空间,即解码出来的Bitmap
为null
,
但是可计算出原始图片的宽度和高度,即options.outWidth
和options.outHeight
。
通过这两个值,就可以知道图片是否过大了。在实际项目中,可以利用上面的代码,先获取图片真实的宽度和高度,然后判断是否需要跑缩小。如果不需要缩小,设置inSampleSize的值为1。如果需要缩小,则动态计算并设置inSampleSize的值,对图片进行缩小。需要注意的是,在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前,别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。
以从Gallery获取一个图片为例讲解缩放: