位图背景图像应支持哪些屏幕尺寸/密度组合？
我正在编写一个应用程序，我需要一些全屏位图背景。基于我对 Android 文档中的支持多屏幕的天真的阅读，涵盖了所有内容我的基础是，每个位图可能应该有 16 个版本：所有对 [ 小、正常、大、xlarge ] 和 [ ldpi, mdpi, hdpi, xhdpi ]。这应该会减少 CPU 缩放图像所需的工作量，但会带来巨大的存储成本。
然而，这似乎效率极低，原因有二：
- 并非所有这些组合都在实践中找到。
- 由于我只是为每个物理尺寸渲染矢量艺术（不考虑 DPI），像大/mdpi 和正常/hdpi 这样的对（都是〜480x854像素）是重复的文件。
那么，我应该只提供非常大的图像并让系统将其缩小吗？硬着头皮提供大量重复图片？完全避免这个问题并用原始资源拼凑一些代码解决方案？还有其他想法吗？谢谢。
编辑：显然，您可以创建 XML 位图可绘制对象，它是实际位图的别名。这解决了第二个低效率的争论。不过，我想知道其他人在实践中提供了哪些这些组合？
I'm writing an application where I will need a number of full screen bitmap backgrounds. Based on my naive reading of Supporting Multiple Screens in the Android documentation, to cover all my bases I should probably have 16 versions of each bitmap: all pairs of [ small, normal, large, xlarge ] and [ ldpi, mdpi, hdpi, xhdpi ]. This should reduce the work the CPU has to do for scaling the images, but will come at great storage cost.
However, this seems wildly inefficient for two reasons:
- Not all of these combinations are found in practice.
- As I'm just rendering vector art for each physical size (without respect for DPI), pairs like large/mdpi and normal/hdpi (which are both ~ 480x854 pixels) are duplicate files.
So, should I just provide really large images and let the system scale them down? Bite the bullet and provide a lot of duplicate images? Avoid the issue altogether and cobble some code solution with raw resources? Any other ideas? Thanks.
EDIT: Apparently you can create XML bitmap drawables which alias an actual bitmap. That solves the second inefficiency argument. Still, I wonder, what combinations of these do others provide in practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议提供 ldpi、mdpi、hdpi 和可选的 xhdpi 图像（取决于您的目标用户）。这将使您能够很好地涵盖最常用的分辨率。
如果您最终感觉应用程序变得太大（无论是决定添加所有可能的图像大小还是其他原因），您还可以考虑允许将应用程序移动到 SD 卡。这样，存储就不再是一个问题了。 （http://developer.android.com/guide/appendix/install-location。 html)
I would advise providing images for ldpi, mdpi, hdpi and optionally xhdpi (depending on your target users). That will allow you to cover the most commonly used resolutions just fine.
If you end up with the feeling that your application is getting too large (either by deciding to add all possible image sizes or other reasons), you can also look into allowing your application to be moved to an SD card. That way, storage won't be much of an issue anymore. (http://developer.android.com/guide/appendix/install-location.html)
如果您希望该艺术品具有恒定的尺寸，无论其显示的屏幕 dpi 为何，您只需提供不同分辨率的图像。图标或按钮就是这样的一个例子。
对于此处描述的背景图像，您不关心图像 dpi 是多少——您只关心 x * y 尺寸是多少。因此，您不必生成尺寸与 dpi 的叉积。您只需要考虑 4 种屏幕尺寸类别。
在 4 种屏幕尺寸类别中，您只需存储较大尺寸之一（xlarge 或large），然后让框架根据需要放大或缩小该尺寸。您还可以以编程方式进行缩放，以确保不会更改背景的纵横比，也不会裁剪它。
另请参阅适用于所有屏幕尺寸的 Android 游戏，这有望吸引更好的答案。
You would only provide images at different resolutions if you want that piece of art to be a constant size, regardless of the screen dpi it is displayed on. An icon or a button would be an example of this.
For the background images described here, you don't care what the image dpi is -- you only care what the x * y dimensions are. So you don't have to produce the cross-product of sizes vs. dpi. You only need consider the 4 screen size categories.
And within the 4 screen size categories, you only need store one of the larger sizes (xlarge or large) and let the framework scale that up or down as needed. You can also do the scaling programmatically, to ensure that you don't change the aspect ratio of your background, and you don't crop it.
See also Android game working on all screen sizes which will hopefully attract a better answer.