Android开发解决加载图片OOM问题（非常全面 兼顾4.0以下系统）（by 星空武哥）
转载请标明：http://blog.csdn.net/lsyz0021/article/details/51295402
我们项目中经常会加载图片，有时候如果加载图片过多的话，小则导致程序很卡，重则OOM导致App挂了，今天翻译https://developer.Android.com/training/displaying-bitmaps/index.html，学习Google高效加载大图片的方法。
图片有各种形状和大小，但在大多数情况下，这些图片都会大于我们程序所需要的大小。比如说系统图片库里展示的图片大都是用手机摄像头拍出来的，这些图片的分辨率会比我们手机屏幕的分辨率高得多。大家应该知道，我们编写的应用程序都是有一定内存限制的，程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。我们可以通过下面的代码看出每个应用程序最高可用内存是多少。
- <span style="font-size:18px;">int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024/1024);</span>
现在大部分手机都是32M，既然知道了每个app分配的内存，所以就要计算好加载多少图片而不导致出现OOM，所以要计算每张图片所占用的内存是多少。
Android中计算一张图片所占内存大小方法：图片长*宽*所占像素字节数,而像素字节数Android中也就四种,
1：ALPHA_8 占1个字节
2：ARGB_4444 占2个字节
3：ARGB_8888 占4个字节
4：RGB_565 占2个字节
透明度 红色 绿色 蓝色
而这些字节数是可以通过bitmap对象去设置的,bitmap.setConfig(Bitmap.Config.ARGB_4444)；如果这是个定值，那么要改变一个张图片的大小，就只能改宽或者高了，如果只改高，宽不变的话,就会造成图片变形，因此一般都是一起改动，所以图片要缩放，而缩放时根据屏幕的宽和高来缩放的，因为Android设备很多，每个屏幕的宽和高也不一样，这样就能达到加载大图片避免OOM。
- BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。如下代码所示：
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inJustDecodeBounds = true;
- BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
- int imageHeight = options.outHeight;
- int imageWidth = options.outWidth;
- String imageType = options.outMimeType;
Android系统的手机在系统底层指定了堆内存的上限值，大部分手机的缺省值是16MB，不过也有些高配置的机型是24MB的，所以我们的程序在申请内存空间时，为了确保能够成功申请到内存空间，应该保证当前已分配的内存加上当前需要分配的内存值的总大小不能超过当前堆的最大内存值。由于内存管理上将外部内存完全当成了当前堆的一部分，也就是说Bitmap对象通过栈上的引用来指向堆上的Bitmap对象，而堆上的Bitmap对象又对应了一个使用了外部存储的native图像，也就是实际上使用的字节数组byte[]来存储的位图信息，因此解码之后的Bitmap的总大小就不能超过8M了。
解决这类问题的最根本的，最有效的办法就是，使用完bitmap之后，调用bitmap对象的recycle()方法释放所占用的内存，以便于下一次使用。
下面是网上找到的一些常用的优化办法，但是基本上都不能从本质上解决问题。
1.设置系统的最小堆大小：
- int newSize = 4 * 1024 * 1024 ; //设置最小堆内存大小为4MB
- VMRuntime.getRuntime().setMinimumHeapSize(newSize);
- VMRuntime.getRuntime().setTargetHeapUtilization(0.75); // 设置堆内存的利用率为75%
补充说明：堆（HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，当堆内存实际的利用率偏离设定的值的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。比如初始的HEAP是4M大小，当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。
2.对图片的大小进行压缩控制
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inSampleSize = 2; //图片宽高都为原来的二分之一，即图片为原来的四分之一
- Bitmap bitmap = BitmapFactory.decodeFile("/mnt/sdcard/a.jpg",options);
补充说明：这种方法只是对图片做了一个缩放处理，降低了图片的分辨率，在需要保证图片质量的应用中不可取。
3.设置临时存储空间
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inTempStorage = new byte[1024*1024*5]; //5MB的临时存储空间
- Bitmap bm = BitmapFactory.decodeFile("/mnt/sdcard/a.jpg",options);
补充说明：从创建Bitmap的C++底层代码BitmapFactory.cpp中的处理逻辑来看，如果option不为null的话，那么会优先处理option中设置的各个参数，假设当前你设置option的inTempStorage为1024*1024*4(4M)大小的话，而且每次解码图像时均使用该option对象作为参数，那么你的程序极有可能会提前失败，经过测试，如果使用一张大小为1.03M的图片来进行解码，如果不使用option参数来解码，可以正常解码四次，也就是分配了四次内存，而如果使用option的话，就会出现内存溢出错误，只能正常解码两次。Options类有一个预处理参数，当你传入options时，并且指定临时使用内存大小的话，Android将默认先申请你所指定的内存大小，如果申请失败，就会先抛出内存溢出错误。而如果不指定内存大小，系统将会自动计算，如果当前还剩3M空间大小，而解码只需要2M大小，那么在缺省情况下将能解码成功，而在设置inTempStorage大小为4M的情况下就将出现内存溢出错误。所以，通过设置Options的inTempStorage大小也不能从根本上解决大图像解码的内存溢出问题。
总之再做android开发时，出现内存溢出是属于系统底层限制，只要解码需要的内存超过系统可分配的最大内存值，那么内存溢出错误必然会出现。
对于Android4.0以下的手机我们还要这么处理：
Android平台在图片处理方面经常会出现OOM的问题，一直被这个问题所困扰，在这方面也搜集了许多的资料，今天仅仅针对Android平台的Bitmap说事儿，今后再对内存的问题做详细的探讨，android平台对图片解码这块确实设置的有内存上限，在解码Bitmap的时候android平台会对其需要占用的内存进行Check，一旦需要的内存超越上限，则直接报错，下面援引邓凡平老师的解释：
你最好分析下你的图片尺寸大小，实在不行的话，把buffer传递给native层，然后在native层做修改。记住我刚才说的，内存检查是Bitmap自己去check的。native层其实malloc/new多大内存都无所谓，只要你不去check。
BitmapFactory.Options options = new BitmapFactory.Options();
options.inNativeAlloc = true;
/***
* Normally bitmap allocations count against the dalvik heap, which
* means they help trigger GCs when a lot have been allocated. However,
* in rare cases, the caller may want to allocate the bitmap outside of
* that heap. To request that, set inNativeAlloc to true. In these
* rare instances, it is solely up to the caller to ensure that OOM is
* managed explicitly by calling bitmap.recycle() as soon as such a
* bitmap is no longer needed.
*
* @hide pending API council approval
*/
我在Android Developers 论坛上找到了一段话：
> On Wed, Jun 8, 2011 at 10:17 AM, Erik R <[email protected]> wrote:
> > I'm working on a simple image manipulation app that requires opening
> > bitmaps at full resolution, which of course results in OutOfMemory
> > issues. I know that the short answer is to simply use less memory via
> > BitmapFactory's inSampleSize Option to downsample the bitmap, but for
> > this app I really would like to retain the full resolution for
> > editing. One solution I have been investigating is loading the bitmap
> > entirely on the native heap, after learning that the memory limitation
> > is only imposed within the Dalvik VM heap. A look into the Android
> > source code revealed that this is already the case... BitmapFactory
> > uses native methods to load a bitmap on the native heap, while
> > maintaining a reference to it on the VM heap. The issue then is that
> > it appears the native memory used by the bitmap is actually counted
> > against the available VM memory, when it really isn't there. A look
> > into the stock Camera and Gallery apps' source revealed that they get
> > around this by using an additional BitmapFactory Option,
> > inNativeAlloc. I was able to find this field in the Java code for
> > BitmapFactory:
