我有同样的问题，并通过避免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方式分配的，而是通过本机调用;分配是在虚拟堆之外完成的，但是 不算数!”

这里有两个问题....

位图内存不在VM堆中，而是在原生堆中——BitmapFactory OOM快把我逼疯了 原生堆的垃圾收集比VM堆的要慢——所以你需要在做位图时非常积极。recycle和bitmap =null每次你通过一个活动的onPause或onDestroy

我有同样的问题，并通过避免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%给了我一个很好的缓冲区，而不会在执行图像旋转时耗尽内存。

希望这能帮助到一些人。

我有一个更有效的解决方案，不需要任何形式的缩放。只需解码您的位图一次，然后将其缓存到一个映射中，以对应其名称。然后根据名称检索位图，并在ImageView中设置它。没有什么需要做的了。

这可以工作，因为解码后的位图的实际二进制数据并不存储在dalvik VM堆中。它存储在外部。因此，每次解码位图时，它都会在VM堆之外分配内存，这些内存永远不会被GC回收

为了更好地理解这一点，想象一下你把你的图像保存在可绘制文件夹中。你只需要通过getResources(). getdrwable (R.drawable.)来获取图像。这将不是每次解码你的图像，而是在每次调用它时重用一个已经解码的实例。所以本质上它是被缓存的。

现在，由于您的映像位于某个文件中(甚至可能来自外部服务器)，因此您有责任缓存解码后的位图实例，以便在任何需要的地方重用它。

希望这能有所帮助。

要修复OutOfMemory，你应该这样做，请尝试这段代码

public Bitmap loadBitmap(String URL, BitmapFactory.Options options) {
                Bitmap bitmap = null;
                InputStream in = null;
                options.inSampleSize=4;
                try {
                    in = OpenHttpConnection(URL);
                    Log.e("In====>", in+"");
                    bitmap = BitmapFactory.decodeStream(in, null, options);
                    Log.e("URL====>", bitmap+"");

                    in.close();
                } catch (IOException e1) {
                }
                return bitmap;
            }

and

try {
                    BitmapFactory.Options bmOptions;
                    bmOptions = new BitmapFactory.Options();
                    bmOptions.inSampleSize = 1;
                    if(studentImage != null){
                        galleryThumbnail= loadBitmap(IMAGE_URL+studentImage, bmOptions);    
                    }

                    galleryThumbnail=getResizedBitmap(galleryThumbnail, imgEditStudentPhoto.getHeight(), imgEditStudentPhoto.getWidth());
                    Log.e("Image_Url==>",IMAGE_URL+studentImage+"");

                } catch (Exception e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }