android - 设备屏幕尺寸对缩放的 ImageViews 有奇怪的影响

Question

更新: 多设备屏幕尺寸是一个转移注意力的问题 - 问题只是图像没有适本地放大以填满屏幕 - 请参阅 Ivan 的回答评论。

我有一个包含一张图片的布局文件:

<ImageView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/image"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:adjustViewBounds="true"
    android:scaleType="centerCrop" />

然后我分配一个 drawable，它很小并且必须按比例放大:

setContentView(R.layout.image_story);
ImageView image = (ImageView)findViewById(R.id.image);
image.setImageDrawable(s.image);

这是它在两个具有不同屏幕尺寸的 AVD 上的呈现方式。这些应该是相同的(底部的详细问题)。抱歉图片太大。

使用 scaleType=centerCrop:

有 centerInside

AVD:

编辑:

使用 layout_height="fill_parent"和 scaleType="centerInside"

我有一个具有默认值的 2.1 AVD，因此屏幕较小，这完全符合预期 - 图像按比例放大以填充宽度， View 高度包裹到缩放后的高度。

在我的屏幕较长的 Droid Bionic 和任何具有相同屏幕尺寸的 AVD 上，这不起作用 - 图像被缩放以填充宽度，但 View 被包裹到原始 预缩放图像高度，因此顶部和底部被裁掉。

我不知道为什么设备屏幕纵横比会对此产生影响。我已经尝试了无数种布局参数和比例类型的组合，试图让它在 Bionic 上运行。在较小的屏幕上，一切都完全符合预期，而不是在较大的屏幕上。如果我在 dp 中明确设置图像高度，它会按预期工作，但我永远不知道图像(或屏幕)的尺寸是多少。有什么建议吗？

Answer 1

这确实是一个很好的问题。

这就是它表现如此的原因(来自 ImageView.onMeasure(int, int) [line 661] ):

// Try adjusting height to be proportional to width
if (!done && resizeHeight) {
    int newHeight = (int)((widthSize - pleft - pright)
            / desiredAspect) + ptop + pbottom;
    if (newHeight <= heightSize) { // line 661
        heightSize = newHeight;
    } // line 663
}

它所做的是，只有当基于可绘制对象的纵横比和调整后的宽度(在我们的例子中，即父 View 的确切宽度)的新高度小于时，它才会调整 View 的高度 比调整后的高度(在我们的例子中，这只是 drawable 的原始高度加上填充。如果你想让我进一步降低这一点，请告诉我。)

我不明白的是为什么有新高度必须更小的限制。仅当我们的 heightSize 为 EXACTLY 或 AT_MOST 并且已设置为上限时才有意义。在其他情况下，它没有必要如此。

所以实际上应该调用另一个 661 到 663 而不是 661 到

heightSize = resolveAdjustedSize(newHeight, mMaxHeight, heightSpec);

确保我们只在应该限制时使用高度限制(即，我们在 heightSpec 中得到了 AT_MOST 限制，并且 heightSpec 中的高度值小于新高度。除非我们使用可变宽度，否则不会发生在这里.)

也许，我错过了什么。伙计们，无论谁正在阅读本文，如果您发现其中的任何缺陷，请发表评论，特别是如果您是 Google Android 团队的一员:)

PS 作为解决方法，我建议您实现自定义 ImageView 并覆盖 onMeasure(int, int) 以将边界设置为您的确切宽高比。如果您需要有关实际代码的帮助，请告诉我。

UPD 我要写下名字以引起 Google 聪明的 android 人的注意(我希望他们已经设置了 Google Alerts):Romain Guy、Roman Nurik、Reto Meier ，请看一下这个讨论。