setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多的内存。改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的sourcedecodeStream最大的好处在于其直接调用JNI 的nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间如果在读取时加上图片的Config参数，可以更有效减少加载的内存，从而更有效避免out of memory的异常另外，decodeStream直接拿图片来读取字节码，不会根据机器的各种分辨率来自动适应，使用了decodeStream之后，需要配置相应大小的图片资源默认情况下android进程的内存占用量为16M，因为bitmap他除了java中持有数据外，底层C++的skia图形库还会持有一个SKBitmap对象，因此一般图片占用内存推荐大小应该不超过8M
1、BitmapFactory.Options
inPreferredConfig 指定decode到内存中，手机中所采用的编码，可选值定义在Bitmap.Config中。缺省值是ARGB_8888。可以使ALPHA_8、ARGB_444、ARGB_8888、RGB_565 bitmap占用内存的算法如下：图片的width*height*Config 如果config设置为ARGB_8888，那么上面的Config为4，也就是4个字节的意思。一张480*320的图片占用的内存就是480*320*4byte。 inJustDecodeBounds 如果设置为true，并不会把图像的数据完全解码，亦即decodeXyz()返回值为null，但是Options的outAbc中解出了图像的基本信息。 inSampleSize 设置decode时的缩放比例。 inPurgeable设为true的话表示使用BitmapFactory创建的Bitmap用于存储Pixel的内存空间在系统内存不足时可以被回收，在应用需要再次访问bitmap的Pixel时，系统会再次条用BitmapFactory decoder重新生成Bitmap的Pixel数组，为了能够重新解码图像，bitmap要能够访问存储bitmap的原始数据。在inPugeable为false时表示创建bitmap的pixel内存空间不能被回收，这样bitmapfactory在不停decodeByteArray创建新的Bitmap对象，不同设备的内存不同，因此能够同时创建的Bitmap个数可能有所不同，200个bitmap足以使大部分的设备出现OutOfMemory错误。当inPurgeable设为true时，系统中内存不足时，可以回收部分bitmap占据的内存空间，这时一般不会出现OutOfMemory错误 inInputShareable是否深拷贝
2、以最省内存的方式读取本地资源的图片
BitmapFactory.Options opt = new BitmapFactory.Options(); opt.inPreferredConfig = Bitmap.Config.RGB_565; opt.inPurgeable = true; opt.inInputShareable = true; //获取资源图片 InputStream is = context.getResources().openRawResource(resId); BitmapFactory.decodeStream(is,null,opt);
3、最近解决bitmap加载时out of memory的心得
游戏在加载背景图片
要么挂在
BitmapFactory. decodeStream(
assets
.open(path));
要么挂在
surface
= Bitmap.createBitmap (
surface
, 0, 0,
surface
.getWidth(),
surface
.getHeight(), matrix,
true
);
第一次尝试：
看到图片是png格式的，将图片转为jpg。图片大小减少了不少。不过没多大效果。
原因：虽然改为jpg，加载时存储的方式会默认为ARGB_565，本来是png为ARGB_8888，占用内存会减少一半。不过开销还是很大，用createBitmap放大时，改方法是java层的实现，效率太差。
第二次尝试：想到cocos2d-x的瓦片地图，所以将背景图片分割为9份（自己用ps切），有些效果，不会每次切换场景都会挂，但是很多的征战地图，没全部切，所以当进入没切的场景时，还是会挂。
原因：没有找到问题的源头，变小图了，加载时开销的内存确实减少不少。不过太多场景都去切不太实际，这样程序改变很大。可能会出现bug的风险。
第三次尝试：配置BitmapFactory.Config的属性，使用（2）中的方式读取图片，省去createBitmap去放大图片，使用两套资源，在这些屏幕上用大图。成功解决问题。
原因：都用了BitmapFactory.decodeStream方法读取图片，改方法直接使用native方法，用c++实现。效率果然是高。虽然当时还不知道这个原因。今天总结的时候通过源代码才理解
Android小记读取Bitmap 的几种方式和优化内存溢出
查了很多资料终于找到了。
现总结以下几种读取Bitmap的方法。
1．以文件流的方式，假设在sdcard下有 test.png图片
FileInputStream fis = new FileInputStream("/sdcard/test.png");
Bitmap bitmap = BitmapFactory.decodeStream(fis);
2. 以R文件的方式，假设 res/drawable下有 test.jpg文件
Bitmap bitmap = BitmapFactory.decodeResource(this.getContext().getResources(), R.drawable.test);
3.以ResourceStream的方式，但不用到R文件。
Bitmap.bitmap=BitmapFactory.decodeStream(getClass().getResourceAsStream(“/res/drawable/test.png”));
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2; //图片宽高都为原来的二分之一，即图片为原来的四分一
//以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，
因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。
因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，
decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。
作者：IF_I_WERE_A_BOY
链接：http://www.jianshu.com/p/f0a5b853200e
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
