使用BitmapFactory压缩图片遇到的问题总结

1,305 阅读6分钟

压缩前先搞明白原理:Bitmap占用的内存大小:

bytes = 原始图片宽*(options.inTargetDensity/options.inDensity)*原始图片长*(options.inTargetDensity/options.inDensity)*每个像素点位数

inTargetDensity指的是当前手机的密度,inDensity是图片的所在drawable目录生成的密度

使用sample采样率来对Bitmap进行压缩到指定的宽和高(原理不在赘述) 方法相信大家都熟悉,网上一搜都大体类似,下面是具体的方法

// 使用decodeRes方法对资源进行转换,使用InJustDecodeBounds属性置为true,先获图
//片高,native层先不返回Bitmap
//进行计算sampleSize,然后设为false,再次decode返回Bitmap
public Bitmap compressBitmapIntoThumbnailPic(Context context, int res) {
        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        Bitmap bitmap1 = BitmapFactory.decodeResource(context.getResources(), res, options);
        Log.d("tag", "first bitmap == " + bitmap1);
        int sampleBitmap = calculateInSampleSize(options, 40, 40);
        options.inSampleSize = sampleBitmap;
        options.inJustDecodeBounds = false;
        Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(), res, options);
        Log.d("tag", "final == " + bitmap.getByteCount() +
                " target real density  " + options.inTargetDensity + " folder density " + options.inDensity);
        return bitmap;
    }
// 对要求的宽高和当前图片宽高对比,取一个最小的比例作为sampleSize
 private int calculateInSampleSize(BitmapFactory.Options options, int requireW, int requereH) {
        int sampleSize = 1;
        int outHeight = options.outHeight;
        int outWidth = options.outWidth;
        int rationHeight = Math.round(outHeight / requereH);
        int rationWidth = Math.round(outWidth / requireW);
        if (rationHeight > 1 || rationWidth > 1) {
            sampleSize = rationHeight > rationWidth ? rationWidth : rationHeight;
        }
        Log.d("tag", "outHeight = " + outHeight + "outWidth = " + outWidth + " -------- " + sampleSize);
        return sampleSize;
    }

执行上述的代码能正常的将一个大图片进行压缩展示,然后自己看了下源码,发现BitmapFactory最终调用的都是decodeStream(...) 这个方法来处理的,于是想试一下直接处理流来对图片压缩也应该可以,代码见下:

/**
     *  用流的形式生成Bitmap
     **/
    public Bitmap compressBitmapIntoThumbnailPic(InputStream is) {
        BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        // 最终返回的Bitmap
        Bitmap finalBitmap = null;
        if(Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT){
            //设置inJustDecodeBounds在native decode时候只返回尺寸等,Bitmap为空
            // 或者将inputStream -> BufferedInputStream 保证某些情况reset不支持
            BitmapFactory.decodeStream(is, null, options);
            int sampleBitmap = calculateInSampleSize(options, 80, 80);
            options.inSampleSize = sampleBitmap;
            options.inJustDecodeBounds = false;
            try {
                is.reset();
            } catch (IOException e) {
                e.printStackTrace();
            }
            finalBitmap = BitmapFactory.decodeStream(is, null, options);
        }else {// 4.4包含以后就没有这个is.mark(1024)的大小限制问题了。不会出现OOM
            if (is.markSupported()) {
                try {
                    BitmapFactory.decodeStream(is,null,options);
                    int sampleBitmap = calculateInSampleSize(options, 40, 40);
                    options.inSampleSize = sampleBitmap;
                    options.inJustDecodeBounds = false;
                    is.reset();
                    finalBitmap = BitmapFactory.decodeStream(is, null, options);
                    Log.d("tag", "final == " + finalBitmap.getByteCount() +
                            " target real density  " + options.inTargetDensity + " folder density " + options.inDensity);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return finalBitmap;
    }

这里对版本做了一个判断,只是为了调式方便。先说下原因,和上面方法相比而言,多了一个 is.reset , 不加的话直接就返回null 了,即使我们已近设置了inJustDecodeBounds为false, 这就奇怪了,这时候还是看下源码来找答案吧,圈红的部分意思是 : 我们在options里设置要求只返回大小或者流不能被decode的时候就返回null,那就说明是流不能被decode了,然后想到了流被使用过后的位置是会改变的,我们第一次decode的时候流执行了mark方法,下次再执行这个流的时候就必须要使用reset,返回上次标记的内容,这样才能正常使用流。有点恍然大悟~,被自己感动了。

这里写图片描述
然后我们去看下InputStream的源码是怎么说的,重点是readLimit这个关键字,大体意思是在流支持mark的情况下,调用reset方法会返回给记录的字节数,但是如果超过了这个 阀值,调用reset不能全部的返回,

/**
     * Marks the current position in this input stream. A subsequent call to
     * the <code>reset</code> method repositions this stream at the last marked
     * position so that subsequent reads re-read the same bytes.
     *
     * <p> The <code>readlimit</code> arguments tells this input stream to
     * allow that many bytes to be read before the mark position gets
     * invalidated.
     *
     * <p> The general contract of <code>mark</code> is that, if the method
     * <code>markSupported</code> returns <code>true</code>, the stream somehow
     * remembers all the bytes read after the call to <code>mark</code> and
     * stands ready to supply those same bytes again if and whenever the method
     * <code>reset</code> is called.  However, the stream is not required to
     * remember any data at all if more than <code>readlimit</code> bytes are
     * read from the stream before <code>reset</code> is called.
     *
     * <p> Marking a closed stream should not have any effect on the stream.
     *
     * <p> The <code>mark</code> method of <code>InputStream</code> does
     * nothing.
     *
     * @param   readlimit   the maximum limit of bytes that can be read before
     *                      the mark position becomes invalid.
     * @see     java.io.InputStream#reset()
     */

在reset的时候容易发生OOM,原因是在流在创建时没有调用mark的话,mark记录的大小肯定是小于整体的,这时候你去调用reset请求的大于mark记录的大小,就会OOM 。参考此条解决方式

/**
     * Repositions this stream to the position at the time the
     * <code>mark</code> method was last called on this input stream.
     *
     * <p> The general contract of <code>reset</code> is:
     *
     * <ul>
     * <li> If the method <code>markSupported</code> returns
     * <code>true</code>, then:
     *
     *     <ul><li> If the method <code>mark</code> has not been called since
     *     the stream was created, or the number of bytes read from the stream
     *     since <code>mark</code> was last called is larger than the argument
     *     to <code>mark</code> at that last call, then an
     *     <code>IOException</code> might be thrown.
     *
     *     <li> If such an <code>IOException</code> is not thrown, then the
     *     stream is reset to a state such that all the bytes read since the
     *     most recent call to <code>mark</code> (or since the start of the
     *     file, if <code>mark</code> has not been called) will be resupplied
     *     to subsequent callers of the <code>read</code> method, followed by
     *     any bytes that otherwise would have been the next input data as of
     *     the time of the call to <code>reset</code>. </ul>
     *
     * <li> If the method <code>markSupported</code> returns
     * <code>false</code>, then:
     *
     *     <ul><li> The call to <code>reset</code> may throw an
     *     <code>IOException</code>.
     *
     *     <li> If an <code>IOException</code> is not thrown, then the stream
     *     is reset to a fixed state that depends on the particular type of the
     *     input stream and how it was created. The bytes that will be supplied
     *     to subsequent callers of the <code>read</code> method depend on the
     *     particular type of the input stream. </ul></ul>
     *
     * <p>The method <code>reset</code> for class <code>InputStream</code>
     * does nothing except throw an <code>IOException</code>.
     *
     * @exception  IOException  if this stream has not been marked or if the
     *               mark has been invalidated.
     * @see     java.io.InputStream#mark(int)
     * @see     java.io.IOException
     */
    public synchronized void reset() throws IOException {
        throw new IOException("mark/reset not supported");
    }

上面代码中有区分4.4版本的判断,这里解释下原因:如下图所示,在4.3源码中默认mark的阀值大小为1024K,这样的话对大图片很容易引起OOM ; 在4.4(包含)之后,去掉了这个case,没有具体的1024限制了。这里只是对原理做了简单的研究,实际上我们还是使用Glide之类的框架去做加载图片的工作。但是对原理有些了解还是不错的。

这里写图片描述

这里写图片描述

扩展 这里还有俩点疑问,

  1. 为啥设置了inJustDecodeBounds = true 就返回空的Bitmap ; 2.第一种用decodeResource的方法为啥能成功的返回Bitmap ??? 还是要去源码中找答案:

这里写图片描述

这里写图片描述
上面这俩张显示了在native层对Bitmap的操作 ; 下面这张图解释了疑问 2 ,因为decodeRes不是直接操作流的,是根据资源Id去加载流,内部做了处理,每次返回的是可用的流,这样就没问题了。
这里写图片描述

结尾

有疑问还是要去看源码啊,知其然也要知其所以然·,水平有限,错误之处请帮忙斧正