android - Android在xml中设置ImageView源时会自动使用inJustDecodeBounds吗？

Question

我知道，如果我要加载图像并将其设置为 ImageView 中的源以编程方式，最好的做法是首先使用 inJustDecodeBounds 计算图像的大小>，弄清楚我需要多少缩放比例，然后使用该缩放比例进行解码:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.drawable.my_drawable, options);

float srcHeight = options.outHeight;
float srcWidth = options.outWidth;

int inSampleSize = ...; // compute

options = new BitmapFactory.Options();
options.inSampleSize = inSampleSize;

Bitmap myBitmap = BitmapFactory.decodeResource(getResources(), R.drawable.my_drawable, options);

myImageview.setImageBitmap(myBitmap);

现在，如果我想在 xml 中设置它，我只在 /drawables 中提供一个基础 drawable(在 /drawables-hdpi< 中没有其他资源等)

<ImageView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:src="@drawable/my_drawable"/>

我知道 Android 会对生成的位图进行某种缩放以确保它适合，但它会像我自己解码位图一样高效地执行此操作吗？还是将整个位图加载到内存中，然后缩放它？

换句话说，当 Android 留给自己的设备对图像重新采样时，当我只提供一个基础 /drawable 时，它这样做效率高吗？

Answer 1

如果你确定你想要的大小，自己缩放位图将节省内存，因为 android 不会这样做，至少不会像你期望的那样(见底部的编辑和评论)。

我认为您还需要做一些其他考虑。当您自己解码位图时，您的目标是一个大小，可能是 ImageView 的大小(因此在计算完 ImageView 的大小之后)。在膨胀 xml 时，该大小尚不清楚。如果在解码 Bitmap 后 ImageView 的大小发生变化，会发生什么情况？你会重新调整它吗？在那种情况下，解码更大的 Bitmap 然后缩放绘图不是更有效吗？

查明 android 是否像您那样缩放 Bitmap 的一种方法非常简单，尝试在 xml 中将一个大得离谱的图像设置为 src，然后看看会发生什么(剧透警报，它'会爆炸)。

深入研究源代码，似乎 ImageView 的 src 的 Bitmap 是在这种方法中解码的Drawable类，貌似没有考虑尺寸，只考虑屏幕密度

public static Drawable createFromResourceStream(Resources res, TypedValue value,
        InputStream is, String srcName, BitmapFactory.Options opts) {
    if (is == null) {
        return null;
    }

    /*  ugh. The decodeStream contract is that we have already allocated
        the pad rect, but if the bitmap does not had a ninepatch chunk,
        then the pad will be ignored. If we could change this to lazily
        alloc/assign the rect, we could avoid the GC churn of making new
        Rects only to drop them on the floor.
    */
    Rect pad = new Rect();

    // Special stuff for compatibility mode: if the target density is not
    // the same as the display density, but the resource -is- the same as
    // the display density, then don't scale it down to the target density.
    // This allows us to load the system's density-correct resources into
    // an application in compatibility mode, without scaling those down
    // to the compatibility density only to have them scaled back up when
    // drawn to the screen.
    if (opts == null) opts = new BitmapFactory.Options();
    opts.inScreenDensity = Drawable.resolveDensity(res, 0);
    Bitmap  bm = BitmapFactory.decodeResourceStream(res, value, is, pad, opts);
    if (bm != null) {
        byte[] np = bm.getNinePatchChunk();
        if (np == null || !NinePatch.isNinePatchChunk(np)) {
            np = null;
            pad = null;
        }

        final Rect opticalInsets = new Rect();
        bm.getOpticalInsets(opticalInsets);
        return drawableFromBitmap(res, bm, np, pad, opticalInsets, srcName);
    }
    return null;
}

而且，在 BitmapDrawable 的 draw(Canvas canvas) 方法中，绘图是用这一行完成的:

canvas.drawBitmap(bitmap, null, mDstRect, paint);

看起来 Bitmap 被按原样使用，它是执行缩放的目标 Rect

编辑

今天无意间还发现了一个有趣的事情，我在drawable文件夹中放了一张图片(未指定密度)，然后用BitmapFactory.decodeResourceStream(res, value, is, pad, opts)获取了一个Bitmap >，同上。我得到的位图比可绘制文件夹中的图像大得多，我认为如果未指定密度，它将假定为 mdpi，甚至会对位图进行上采样以获得更高的目标密度。