Android加载图片OOM错误解决方式

 

前几天作项目的时候，甲方要求是PAD （SAMSUNG P600 10.1寸 2560*1600）的PAD上显示高分辨率的大图片。

SQLITE採用BOLD方式存储图片，这个存取过程就不说了哈，网上一大堆。

但是在加载/读取/显示图片的时候会报OOM错误，上网查了很是多解决方式还绕了很是多弯路，最后仍是找到了缘由所在。如下从几个方面来解释一下OOM问题的解决方式。

（谢谢周同窗的“尺寸”提醒。否则我可能一生都要蒙在鼓里）

 

1.Android APP内存

作一个APP开发的时候，仍是不要想着去扩大Android系统赋予的内存上限了。部分老机型老系统16M。大部分都是24M了。

一些大型游戏用dalvik.system.VMRuntime来干涉GC过程（这个类我尚未学过。

。

。刚据说不久）。

听说用NDK开发时候，C可以动态申请多余的内存空间，但是我没用过NDK，从此也不打算用了（我的缘由）。

 

2.图片文件大小

甲方给了一大堆文件大小不一的图片，在加载数据库->读取出来->显示出来的这个过程当中，出现了很是多OOM，分为：

a.加载图片时使用ByteArrayStream建立流，size为Height * Width * 4。OOM；

b.读取图片时候OOM，同上；

c.显示图片时候OOM，decodeResource函数报错，OOM；

開始时候觉得是文件大小问题。后来发现有些2M的图片都能显示，但是某些1M的图片确报错。因此在必定范围内，可以证实。图片OOM问题与文件大小无关。

 

3.图片尺寸（分辨率）

调查这些能显示的图片和不能显示的图片的不一样。发现长宽差距很是大。那些能成功显示的图片为1005*1500大小，而其它图片都是3000*5000以上。

我用PAINT（一款适合小白的图像处理软件。尽管不如PS但是功能已经很强大了，最新版需要安装NET 4.5）压缩了图片大小。压缩到1005*1500。显示成功。

 

4.函数调用

阅读了这位大神的博客：

http://blog.csdn.net/huangbiao86/article/details/8072128

摘取当中最精华的部分吧：

尽可能不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完毕decode后。终于都是经过java层的createBitmap来完毕的。需要消耗不少其它内存。

 

所以，改用先经过BitmapFactory.decodeStream方法，建立出一个bitmap，再将其设为ImageView的 source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完毕decode。无需再使用java层的createBitmap，从而节省了java层的空间。

假设在读取时加上图片的Config參数，可以跟有效下降载入的内存。从而跟有效阻止抛out of Memory异常

另外。decodeStream直接拿的图片来读取字节码了。 不会依据机器的各类分辨率来本身主动适应， 使用了decodeStream以后，需要在hdpi和mdpi，ldpi中配置对应的图片资源， 不然在不一样分辨率机器上都是相同大小（像素点数量），显示出来的大小就不正确了。

看来读底层源代码仍是很是实用的，setImageBitmap 和 setImageResource 和 decodeResource在运行过程当中仍是调用了createBitmap来建立一个新的bitmap。建立bitmap会加重内存消耗，因此不推荐使用了。应该使用decodeStream方法。

图片的压缩过程也可以设置一个合适的百分比来控制大小。

多张图片的使用中，请注意流的flush与close（我没有及时flush和close的时候也执行正确了，这个有待研究一下，但是为了保证一个良好的习惯仍是注意下吧）。

 

5.关于options方法

网上还有很是多文章用BitmapFactory.Options来做为decodeStream时候的一个參数，这个我临时没有详细实验过，哪位朋友实验过了可以回复交流哈