正在切换页面...

ImageView 底层机制与 ScaleType 源码级解析

mediumAndroidUIImageViewScaleType源码最近更新

在 Android 的 UI 体系中，ImageView 可能是开发者接触最早、使用最频繁的控件之一。表面上看，它只是一个用于展示图片的容器，调用 setImageResource() 就能显示图片。但当我们遇到“图片被拉伸变形”、“圆角图片有锯齿或卡顿”、“wrap_content 失效”等问题时，往往是因为我们对它的内部工作原理缺乏深刻的理解。

本文将剥离表象，从源码和数学运算的层面，带你深入探究 ImageView 的测量机制、ScaleType 的底层矩阵变换原理，以及自定义圆角图片的底层逻辑。

相框与画的博弈

要理解 ImageView，我们需要在直觉上建立一个极其贴切的比喻：ImageView 就像是一个相框，而 Drawable 是一幅画。

相框（ImageView）：它是一个 View，参与整个 View 树的测量（Measure）和布局（Layout），它受限于父容器给它分配的可用空间，它有自己的 padding，有最大的宽度限制。
画（Drawable）：它是实际被展示的像素内容，它有自己的“天然尺寸”（Intrinsic Size，比如一张 800x600 的照片），但它不是一个 View，不能独立存在于屏幕上，必须被挂在“相框”里。

为什么要将“展示容器”和“图像内容”分离开来？这是一种经典的解耦设计。如果我们把加载、缩放、裁剪、像素渲染全部塞进一个类里，这个类会变得极其臃肿。Android 的设计是：ImageView 负责向 View 树申请占地面积（相框尺寸计算），并计算出如何将画面塞进相框的“变换策略”（Matrix）；而真正的像素绘制逻辑，交由具体的 BitmapDrawable、VectorDrawable 自己去完成。

测量阶段：尺寸计算的内幕

当我们在 XML 中把 ImageView 的宽高设置为精确值（如 100dp）或 match_parent 时，它的测量过程与普通 View 无异。但最容易引发诡异问题的，是把它设置为 wrap_content 时。

wrap_content 到底是以谁为准？

如果是 wrap_content，ImageView 的 onMeasure 逻辑会去询问“画”（Drawable）的内在尺寸：

// ImageView 的 onMeasure 伪代码逻辑
int w = 0;
int h = 0;
if (mDrawable != null) {
    w = mDrawable.getIntrinsicWidth();
    h = mDrawable.getIntrinsicHeight();
}
w += mPaddingLeft + mPaddingRight;
h += mPaddingTop + mPaddingBottom;

但这里有一个致命的冲突：如果这幅画的尺寸是 2000x2000，而屏幕只有 1080x1920 呢？由于父容器（如 LinearLayout）在传递 MeasureSpec 时，通常会带有 AT_MOST（最多只能这么大）的限制，ImageView 最终会将尺寸限制在父容器允许的范围内。

adjustViewBounds 的真正作用

假设一张宽高比为 2:1 的横向照片（1000x500），被放进一个 maxWidth="500" 并且 layout_width="wrap_content"，layout_height="wrap_content" 的 ImageView 中。按照常规测量，由于 maxWidth 的限制，宽度最终被测量为 500。那么高度呢？高度没有 maxHeight 限制，它会使用照片的原高度 500。最终这个相框变成了一个 500x500 的正方形！但是照片是 2:1 的，放进正方形相框里，上下就会留出大量空白。

这就是 adjustViewBounds 存在的意义。它的底层逻辑是打破常规测量机制，强行让相框的宽高比去迎合画的宽高比。

在源码层面，开启 adjustViewBounds="true" 后，ImageView 会在 onMeasure 中计算宽和高的缩放比例，并应用相同的缩放比例来修正另一个维度的尺寸：

// 源码级逻辑：如果开启了 adjustViewBounds，并且宽度受限
if (mAdjustViewBounds) {
    float widthRatio = (float) widthSize / (float) w;
    // 使用宽度的缩放比，强行缩小高度，保持比例
    int newHeight = (int) (h * widthRatio);
    heightSize = Math.min(newHeight, heightSize);
}

如此一来，高度也被等比例缩小为了 250，最终相框的尺寸变为了 500x250，完美贴合照片的 2:1 比例，消除了上下留白。

绘制核心：ScaleType 的矩阵魔法

当相框的大小和画的大小不一致时，如何把画塞进去？这就是 ScaleType 的工作。初学者通常会去死记硬背各种 ScaleType 的效果，但从底层视角看，这无非是一个生成矩阵（Matrix）的数学游戏。

在 ImageView 的源码中，真正执行缩放的并不是在绘制像素时使用某种拉伸算法，而是在 configureBounds() 方法中预先计算好一个 3x3 的数学变换矩阵 mDrawMatrix。在 onDraw 时，它只是简单地把矩阵交给底层的 Canvas：

@Override
protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    // ...
    if (mDrawMatrix != null) {
        // 将底层坐标系按照矩阵进行缩放和平移变换
        canvas.concat(mDrawMatrix); 
    }
    // 让 Drawable 在变换后的坐标系中傻瓜式地画出自己原来的尺寸
    mDrawable.draw(canvas);
}

我们来深入剖析几种常见 ScaleType 是如何计算这个矩阵的。

FIT_XY：不择手段的填满

最暴力的策略，独立计算 X 轴和 Y 轴的缩放比例。

float scaleX = (float) viewWidth / (float) drawableWidth;
float scaleY = (float) viewHeight / (float) drawableHeight;
mDrawMatrix.setScale(scaleX, scaleY);

后果：由于 scaleX 和 scaleY 不相等，图片在渲染引擎中被严重挤压变形。

CENTER_CROP：舍身取义的填满

这是实际开发中最常用的策略。它保证画能完全填满相框，且不产生变形。代价是多出来的部分被裁剪。在数学上，如何保证不变形？必须让 X 轴和 Y 轴的缩放比例相等。如何保证完全填满？必须取 X 轴和 Y 轴中更大的那个缩放比例。

// 取宽或高两者中，较大的那个缩放比例
float scale = Math.max(
    (float) viewWidth / (float) drawableWidth,
    (float) viewHeight / (float) drawableHeight
);

// 缩放后，画的尺寸肯定会大于等于相框的尺寸。为了居中，需要计算负平移量。
float dx = (viewWidth - drawableWidth * scale) * 0.5f;
float dy = (viewHeight - drawableHeight * scale) * 0.5f;

mDrawMatrix.setScale(scale, scale);
mDrawMatrix.postTranslate(Math.round(dx), Math.round(dy));

例如相框是 100x100的正方形，画是 200x100的横图。宽度比 100/200 = 0.5，高度比 100/100 = 1.0。取较大者 1.0 作为全局缩放比例。于是画的高度刚刚好，但宽度变成了 200，超出了相框的 100。接着平移 dx = (100 - 200) * 0.5 = -50。这意味着画向左平移 50 像素，完美实现居中裁剪。

FIT_CENTER：委曲求全的完整

保证画完整可见，且不产生变形。代价是相框会留有空白边缘。底层的矩阵计算原理与 CENTER_CROP 高度相似，唯一的区别是：它取宽和高缩放比例中更小的那个。

// 取宽或高两者中，较小的那个缩放比例
float scale = Math.min(
    (float) viewWidth / (float) drawableWidth,
    (float) viewHeight / (float) drawableHeight
);
// 后续计算居中平移 dx, dy 逻辑同上

通过 Math.min 的魔法，画被缩到了能够完整塞入相框的最大安全范围。

高级实践：自定义圆角图片的底层演进

在业务开发中，将头像或封面图处理为圆角几乎是标配。从底层实现上看，业界经历了三种不同的原理演进：

方案一：Xfermode 遮罩叠加（早期方案，性能较差）

原理是利用画板渲染阶段的 PorterDuffXfermode 混合模式。

先在屏幕外的离屏缓冲区（Off-screen Buffer，调用 canvas.saveLayer）画一个圆角的纯色黑块。
设置混合模式为 SRC_IN（取两层绘制交集，显示上层）。
再把原图画上去。 为什么性能差？ 因为 saveLayer 会在 GPU 开辟一块新的内存，打断了原本的渲染管线，造成较高的重绘开销。这种方式目前已经被彻底淘汰。

方案二：BitmapShader（Glide 等框架的底层首选）

利用底层的 Skia 渲染引擎特性。将图片作为一种着色器挂载到 Paint 画笔上，然后直接告诉 Canvas 去画一个圆角矩形。

BitmapShader shader = new BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);
// 还能顺带在这里应用 Matrix 进行 ScaleType 的缩放
shader.setLocalMatrix(mDrawMatrix);
mPaint.setShader(shader);
// 直接让底层渲染出带有图片纹理的圆角矩形，没有离屏缓冲开销！
canvas.drawRoundRect(rect, radius, radius, mPaint);

它的核心优势是：把裁切过程融入到了渲染管线内部，直接根据画笔的区域将像素对应上去，这在操作 GPU 时是非常高效率的。

方案三：ViewOutlineProvider（Android 5.0 后的硬件加速降维打击）

自 Android 5.0 引入 Material Design 后，系统级别提供了一种极度低成本的裁剪方式。你不必再去处理图片的像素或者 Paint，而是直接告诉渲染树（RenderNode）：帮我把这个 View 的外围轮廓切成圆角的。

imageView.setOutlineProvider(new ViewOutlineProvider() {
    @Override
    public void getOutline(View view, Outline outline) {
        // 直接在渲染树级别截断
        outline.setRoundRect(0, 0, view.getWidth(), view.getHeight(), radius);
    }
});
imageView.setClipToOutline(true);

底层机制：这个操作发生在硬件加速的 DisplayList 录制阶段。GPU 绘制时会直接通过硬件特性丢弃 Outline 之外的片元（Fragment），不增加任何内存开销，性能登峰造极。缺点是灵活性不足（例如只支持简单的圆和圆角矩形，不支持复杂的异形裁剪）。

结语

在 Android 开发中，即便是 ImageView 这样“简单”的组件，其背后也隐藏着一套严谨的数学模型与图形渲染体系。当我们透视到底层的 MeasureSpec 博弈和 3x3 Matrix 运算后，遇到再诡异的图片展示错乱，我们也能如庖丁解牛般迅速定位问题，甚至能根据渲染机制的开销，写出性能最极致的代码。