3

我正在编写一个需要大量全屏位图背景的应用程序。根据我在 Android 文档中对Supporting Multiple Screens的天真阅读，为了涵盖我的所有基础，我可能应该有每个位图的 16 个版本：所有对[ small, normal, large, xlarge ]和[ ldpi, mdpi, hdpi, xhdpi ]. 这应该会减少 CPU 为缩放图像而必须做的工作，但会带来巨大的存储成本。

然而，这似乎非常低效，原因有两个：

  1. 并非所有这些组合都在实践中被发现。
  2. 因为我只是为每个物理尺寸渲染矢量图（不考虑 DPI），所以像 large/mdpi 和 normal/hdpi （都是 ~ 480x854 像素）这样的对是重复文件。

那么，我应该只提供非常大的图像并让系统按比例缩小它们吗？咬紧牙关并提供大量重复的图像？完全避免这个问题并用原始资源拼凑一些代码解决方案？还有其他想法吗？谢谢。

编辑：显然，您可以创建 XML 位图可绘制对象，其别名为实际位图。这解决了第二个效率低下的论点。不过，我想知道，其他人在实践中提供了哪些这些组合？

4

2 回答 2

0

如果您希望该艺术品具有恒定大小，则仅提供不同分辨率的图像，而不管它显示在哪个屏幕 dpi 上。图标或按钮就是一个例子。

对于此处描述的背景图像，您并不关心图像 dpi 是什么——您只关心 x * y 尺寸是多少。因此，您不必产生尺寸与 dpi 的叉积。您只需要考虑 4 种屏幕尺寸类别。

在 4 种屏幕尺寸类别中，您只需要存储较大尺寸（xlarge 或 large）中的一种，并让框架根据需要向上或向下缩放。您还可以以编程方式进行缩放，以确保您不会更改背景的纵横比，也不会裁剪它。

另请参阅适用于所有屏幕尺寸的 Android 游戏， 这有望吸引更好的答案。

于 2013-03-28T18:07:44.793 回答
-1

我建议为 ldpi、mdpi、hdpi 和可选的 xhdpi 提供图像（取决于您的目标用户）。这将使您能够很好地涵盖最常用的分辨率。

如果您最终感觉您的应用程序变得太大（通过决定添加所有可能的图像大小或其他原因），您还可以考虑允许将您的应用程序移动到 SD 卡。这样，存储将不再是一个大问题。（http://developer.android.com/guide/appendix/install-location.html）

于 2011-03-22T15:32:37.170 回答