我认为避免OutOfMemoryError的最好方法是面对它并理解它。

我做了一个应用程序，故意引起OutOfMemoryError，并监控内存使用情况。

在对这个App做了大量的实验之后，我得到了以下结论:

在Honey Comb之前，我先谈谈SDK版本。

位图存储在原生堆中，但它会自动被垃圾收集，调用recycle()是不必要的。 如果{VM堆大小}+{已分配的本机堆内存}>={设备的VM堆大小限制}，并且您正在尝试创建位图，则会抛出OOM。 注意:计算的是虚拟机堆大小，而不是虚拟机已分配内存。 VM堆大小在增长后永远不会缩小，即使分配的VM内存减少了。 所以你必须保持VM内存的峰值尽可能低，以保持VM堆大小不会变得太大，以节省可用的内存位图。 手动调用system .gc()是没有意义的，系统会在尝试增加堆大小之前先调用它。 原生堆大小也永远不会缩小，但它不计入OOM，所以不用担心。

然后，让我们谈谈SDK从蜂巢开始。

位图存储在VM堆中，OOM不计算本机内存。 OOM的条件要简单得多:{虚拟机堆大小}>={设备的虚拟机堆大小限制}。 所以你有更多的可用内存来创建位图与相同的堆大小限制，OOM不太可能被抛出。

以下是我对垃圾收集和内存泄漏的一些观察。

你可以自己在App中看到它。如果一个Activity执行了一个AsyncTask，而这个AsyncTask在Activity被销毁后仍然在运行，那么这个Activity在AsyncTask完成之前不会被垃圾收集。

这是因为AsyncTask是一个匿名内部类的实例，它持有一个Activity的引用。

如果任务在后台线程的IO操作中被阻塞，调用AsyncTask.cancel(true)将不会停止执行。

回调也是匿名的内部类，所以如果项目中的静态实例持有它们并且不释放它们，内存就会泄漏。

如果你计划一个重复或延迟的任务，例如定时器，你不调用取消()和清除()在onPause()，内存将被泄漏。

我使用解码文件描述符，它为我工作:

 FileInputStream  fileInputStream = null;
        try {
            fileInputStream  = new FileInputStream(file);
             FileDescriptor fd = fileInputStream.getFD();
            Bitmap imageBitmap = decodeSampledBitmapFromDescriptor(fd , 612,
                    816);
            imageView.setImageBitmap(imageBitmap);
        } catch (Exception e) {
            e.printStackTrace();
        }finally {
            if(fileInputStream != null){
                try {
                    fileInputStream.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }

从文件描述符解码采样位图的代码:

 /**
     * Decode and sample down a bitmap from a file input stream to the requested width and height.
     *
     * @param fileDescriptor The file descriptor to read from
     * @param reqWidth       The requested width of the resulting bitmap
     * @param reqHeight      The requested height of the resulting bitmap
     * @return A bitmap sampled down from the original with the same aspect ratio and dimensions
     * that are equal to or greater than the requested width and height
     */
    public static Bitmap decodeSampledBitmapFromDescriptor(
            FileDescriptor fileDescriptor, int reqWidth, int reqHeight) {

        // First decode with inJustDecodeBounds=true to check dimensions
        final BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeFileDescriptor(fileDescriptor, null, options);

        // Calculate inSampleSize
        options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);

        // Decode bitmap with inSampleSize set
        options.inJustDecodeBounds = false;
        return BitmapFactory.decodeFileDescriptor(fileDescriptor, null, options);
    }

    /**
     * Calculate an inSampleSize for use in a {@link android.graphics.BitmapFactory.Options} object when decoding
     * bitmaps using the decode* methods from {@link android.graphics.BitmapFactory}. This implementation calculates
     * the closest inSampleSize that will result in the final decoded bitmap having a width and
     * height equal to or larger than the requested width and height. This implementation does not
     * ensure a power of 2 is returned for inSampleSize which can be faster when decoding but
     * results in a larger bitmap which isn't as useful for caching purposes.
     *
     * @param options   An options object with out* params already populated (run through a decode*
     *                  method with inJustDecodeBounds==true
     * @param reqWidth  The requested width of the resulting bitmap
     * @param reqHeight The requested height of the resulting bitmap
     * @return The value to be used for inSampleSize
     */
    public static int calculateInSampleSize(BitmapFactory.Options options,
                                            int reqWidth, int reqHeight) {
        // Raw height and width of image
        final int height = options.outHeight;
        final int width = options.outWidth;
        int inSampleSize = 1;

        if (height > reqHeight || width > reqWidth) {

            // Calculate ratios of height and width to requested height and width
            final int heightRatio = Math.round((float) height / (float) reqHeight);
            final int widthRatio = Math.round((float) width / (float) reqWidth);

            // Choose the smallest ratio as inSampleSize value, this will guarantee a final image
            // with both dimensions larger than or equal to the requested height and width.
            inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;

            // This offers some additional logic in case the image has a strange
            // aspect ratio. For example, a panorama may have a much larger
            // width than height. In these cases the total pixels might still
            // end up being too large to fit comfortably in memory, so we should
            // be more aggressive with sample down the image (=larger inSampleSize).

            final float totalPixels = width * height;

            // Anything more than 2x the requested pixels we'll sample down further
            final float totalReqPixelsCap = reqWidth * reqHeight * 2;

            while (totalPixels / (inSampleSize * inSampleSize) > totalReqPixelsCap) {
                inSampleSize++;
            }
        }
        return inSampleSize;
    }

我花了一整天的时间来测试这些解决方案，唯一对我有用的是上面的获取图像和手动调用GC的方法，我知道这是不必要的，但当我把应用程序置于繁重的负载测试下时，这是唯一有效的方法。我的应用程序有一个缩略图列表在列表视图(让说活动a)，当你点击其中一个图像，它带你到另一个活动(让说活动B)，显示该项目的主图像。当我在两个活动之间来回切换时，我最终会得到OOM错误，应用程序将强制关闭。

当我走到列表视图一半的时候它就崩溃了。

现在，当我在活动B中实现以下内容时，我可以毫无问题地遍历整个列表视图，并继续下去……而且速度很快。

@Override
public void onDestroy()
{   
    Cleanup();
    super.onDestroy();
}

private void Cleanup()
{    
    bitmap.recycle();
    System.gc();
    Runtime.getRuntime().gc();  
}

我有iOS经验，我很沮丧地发现加载和显示图像这样基本的问题。毕竟，每个人都有这个问题，试图显示合理大小的图像。不管怎样，这里有两个改变解决了我的问题(并使我的应用程序非常灵敏)。

1)每次执行BitmapFactory. decodexyz()时，确保传入一个BitmapFactory。选项inPurgeable设置为true(最好inInputShareable也设置为true)。

2)绝对不要使用位图。createBitmap(width, height, Config.ARGB_8888)。我的意思是绝不!我从来没有过这个东西在几次传递后不产生内存错误。没有多少recycle()， System.gc()，任何有用的东西。它总是抛出异常。另一种实际工作的方法是在你的绘图中有一个虚拟图像(或另一个你使用上述步骤1解码的位图)，将其重新缩放为你想要的任何东西，然后操纵结果位图(例如将它传递到画布上以获得更多乐趣)。所以，你应该使用的是:位图。createScaledBitmap(srcBitmap, width, height, false)。如果出于某种原因你必须使用暴力创建方法，那么至少要传递Config.ARGB_4444。

这几乎可以保证节省你几个小时，如果不是几天。所有关于缩放图像等的讨论都是行不通的(除非你认为得到错误的大小或降级的图像是一个解决方案)。

我有同样的问题，并通过避免BitmapFactory.decodeStream或decodeFile函数来解决它，而是使用BitmapFactory.decodeFileDescriptor

decodeFileDescriptor看起来像调用了不同于decodeStream/decodeFile的本地方法。

不管怎样，这样做是有效的(注意，我添加了一些选项，就像上面的一些选项一样，但这并不是造成不同的原因。关键是调用BitmapFactory.decodeFileDescriptor而不是decodeStream或decodeFile):

private void showImage(String path)   {

    Log.i("showImage","loading:"+path);
    BitmapFactory.Options bfOptions=new BitmapFactory.Options();
    bfOptions.inDither=false;                     //Disable Dithering mode
    bfOptions.inPurgeable=true;                   //Tell to gc that whether it needs free memory, the Bitmap can be cleared
    bfOptions.inInputShareable=true;              //Which kind of reference will be used to recover the Bitmap data after being clear, when it will be used in the future
    bfOptions.inTempStorage=new byte[32 * 1024]; 

    File file=new File(path);
    FileInputStream fs=null;
    try {
        fs = new FileInputStream(file);
    } catch (FileNotFoundException e) {
        //TODO do something intelligent
        e.printStackTrace();
    }

    try {
        if(fs!=null) bm=BitmapFactory.decodeFileDescriptor(fs.getFD(), null, bfOptions);
    } catch (IOException e) {
        //TODO do something intelligent
        e.printStackTrace();
    } finally{ 
        if(fs!=null) {
            try {
                fs.close();
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }
    //bm=BitmapFactory.decodeFile(path, bfOptions); This one causes error: java.lang.OutOfMemoryError: bitmap size exceeds VM budget

    im.setImageBitmap(bm);
    //bm.recycle();
    bm=null;                        
}

我认为在decodeStream/decodeFile中使用的本机函数有问题。我已经确认使用decodeFileDescriptor时调用了不同的本机方法。此外，我读到的是“图像(位图)不是以标准的Java方式分配的，而是通过本机调用;分配是在虚拟堆之外完成的，但是 不算数!”

这里的所有解决方案都需要设置IMAGE_MAX_SIZE。这限制了硬件更强大的设备，如果图像尺寸太小，在高清屏幕上看起来会很难看。

我想出了一个解决方案，它适用于我的三星Galaxy S3和其他几台设备(包括功能不太强大的设备)，当使用功能更强大的设备时，图像质量会更好。

它的要点是计算在特定设备上分配给应用程序的最大内存，然后将规模设置为尽可能低的，而不超过这个内存。代码如下:

public static Bitmap decodeFile(File f)
{
    Bitmap b = null;
    try
    {
        // Decode image size
        BitmapFactory.Options o = new BitmapFactory.Options();
        o.inJustDecodeBounds = true;

        FileInputStream fis = new FileInputStream(f);
        try
        {
            BitmapFactory.decodeStream(fis, null, o);
        }
        finally
        {
            fis.close();
        }

        // In Samsung Galaxy S3, typically max memory is 64mb
        // Camera max resolution is 3264 x 2448, times 4 to get Bitmap memory of 30.5mb for one bitmap
        // If we use scale of 2, resolution will be halved, 1632 x 1224 and x 4 to get Bitmap memory of 7.62mb
        // We try use 25% memory which equals to 16mb maximum for one bitmap
        long maxMemory = Runtime.getRuntime().maxMemory();
        int maxMemoryForImage = (int) (maxMemory / 100 * 25);

        // Refer to
        // http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html
        // A full screen GridView filled with images on a device with
        // 800x480 resolution would use around 1.5MB (800*480*4 bytes)
        // When bitmap option's inSampleSize doubled, pixel height and
        // weight both reduce in half
        int scale = 1;
        while ((o.outWidth / scale) * (o.outHeight / scale) * 4 > maxMemoryForImage)
        scale *= 2;

        // Decode with inSampleSize
        BitmapFactory.Options o2 = new BitmapFactory.Options();
        o2.inSampleSize = scale;
        fis = new FileInputStream(f);
        try
        {
            b = BitmapFactory.decodeStream(fis, null, o2);
        }
        finally
        {
            fis.close();
        }
    }
    catch (IOException e)
    {
    }
    return b;
}

我将此位图使用的最大内存设置为最大已分配内存的25%，您可能需要根据需要进行调整，并确保此位图被清理，并且当您使用完它时，它不会停留在内存中。通常我使用这段代码来执行图像旋转(源和目标位图)，所以我的应用程序需要同时在内存中加载2个位图，25%给了我一个很好的缓冲区，而不会在执行图像旋转时耗尽内存。

希望这能帮助到一些人。