我需要加载一个大尺寸的图像到位图，我使用Glide来解决这个问题。首先用BitmapFactory检查图像大小。选项使用injstdecodebounds设置为true，然后使用Glide获取位图对象。我使用分析器来检查内存使用情况，但我没有看到任何内存峰值，就像我使用BitmapFactory.decodeFile()时那样。 我是用c#写的，因为我使用Xamarin，所以需要在Java中使用一点小调整。 Glide库文档

private Bitmap DecodeFile(File file) {
        // Decode image size
        BitmapFactory.Options options = new BitmapFactory.Options();
        
        // setting inJustDecodeBounds to true won't load the file into memory, 
        // but gives you the actual file size.
        options.InJustDecodeBounds = true;
        BitmapFactory.decodeStream(new FileInputStream(file), null, options);
        int actualWidth = options.OutWidth;
        int actualHeight = options.OutHeight;
                
        var ratio = (double)actualHeight / actualWidth;

        // Default to 800 x 600. changed the size whatever you need.
        var desiredWidth = 800;
        var desiredHeight = 600;

        if(actualHeight > actualWidth)
        {
            var ratio = (double)actualWidth / actualHeight;
            var futureTarget = Glide.With(Application.Context)
                .AsBitmap()
                .Load(file)
                .SetDiskCacheStrategy(DiskCacheStrategy.None)
                .SkipMemoryCache(true)
                .Submit((int)(desiredWidth * ratio), desiredWidth);
            bitmap = futureTarget.Get() as Bitmap;
        }
        else
        {
            var ratio = (double)actualHeight / actualWidth;
            var futureTarget = Glide.With(Application.Context)
                .AsBitmap()
                .Load(file)
                .SetDiskCacheStrategy(DiskCacheStrategy.None)
                .SkipMemoryCache(true)
                .Submit(desiredWidth, (int)(desiredWidth * ratio));
            bitmap = futureTarget.Get() as Bitmap;
        }return bitmap;}

这对我很管用!

public Bitmap readAssetsBitmap(String filename) throws IOException {
    try {
        BitmapFactory.Options options = new BitmapFactory.Options(); 
        options.inPurgeable = true;
        Bitmap bitmap = BitmapFactory.decodeStream(assets.open(filename), null, options);
        if(bitmap == null) {
            throw new IOException("File cannot be opened: It's value is null");
        } else {
            return bitmap;
        }
    } catch (IOException e) {
        throw new IOException("File cannot be opened: " + e.getMessage());
    }
}

在manifest.xml文件中添加以下代码行:

<application

    android:hardwareAccelerated="false"
    android:largeHeap="true">

    <activity>
    </activity>

</application>

我认为避免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;
    }

这似乎是一个长期存在的问题，有很多不同的解释。我采纳了这里给出的两个最常见答案的建议，但它们都没有解决我的VM声称它无法负担字节来执行过程的解码部分的问题。经过一番深入研究，我了解到这里的真正问题是解码过程从NATIVE堆中取出。

BitmapFactory OOM把我逼疯了

这将我引向另一个讨论线程，在那里我找到了这个问题的更多解决方案。一个是调用system .gc();显示图像后手动操作。但这实际上会使你的应用程序使用更多的内存，以减少本机堆。对于2.0版本(Donut)来说，更好的解决方案是使用BitmapFactory选项“inPurgeable”。所以我添加了o2.inPurgeable=true;就在o2.inSampleSize=scale;之后。

关于这个主题的更多信息:内存堆的限制只有6M吗?

现在，说了这么多，我对Java和Android也是个十足的笨蛋。所以如果你认为这是一个糟糕的解决问题的方法，你可能是对的。;-)但这已经为我工作的奇迹，我发现它不可能运行VM的堆缓存现在。唯一的缺点我能找到的是，你是垃圾缓存绘制的图像。这意味着如果你直接回到那个图像，你每次都要重新绘制它。就我的应用程序的工作方式而言，这并不是真正的问题。你的里程可能会有所不同。