仅在 Android 应用程序中使用 XHDPI 可绘制对象？
如果您计划在不久的将来支持 LDPI、MDPI、HPDI，或许还有 XHDPI，那么是否可以在项目中仅包含 XHDPI 可绘制对象并让设备将其缩放到所需的分辨率？
我已经测试过在 Photoshop 中将可绘制对象的大小调整为 MDPI 和 HDPI，然后将结果与仅通过 Android 调整大小的 XHDPI 可绘制对象进行比较，我根本看不出任何差异。走这条捷径是不是设计不好？如果不必将每个可绘制对象的大小调整为 3 种不同的分辨率，那就太好了。
计划使用的目标SDK是2.1或2.2。
BR 埃米尔
If you're planning to support LDPI, MDPI, HPDI, and perhaps XHDPI in the near future, is it ok to only include XHDPI drawables in the project and let the devices scale them to their desired resolution?
I've tested to resize the drawables into MDPI and HDPI in Photoshop and then compared the result with XHDPI drawables only resized by Android, and I can't see any difference at all. Is it bad design to take this shortcut? It would be nice to not have to resize each and every drawable into 3 different resolutions.
Planning to use target SDK is 2.1 or 2.2.
BR
Emil
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我想这是一个好方法。我能想到的唯一缺点是小型设备上的资源开销以及由于缩小规模而可能出现的工件。实际上，在今年的 Google IO 上，Chris Pruett 建议仅嵌入高分辨率资源并让 opengl 处理缩放。
I guess that's a good way to go. The only downside I can think of is the resource overhead on small scale devices and possible artifacts because of the downscaling. Actually at this year's Google IO Chris Pruett recommended embedding only high resolution assets and let opengl handle the scaling.
从 Android 1.6 开始，可以处理不同的密度，包括 XHDPI（直到 2.2 才正式添加）。您的应用程序将首先查找与其密度相匹配的图像，但它可以查找更大的“桶”（例如 XHDPI），然后为您执行缩放。
最好包含您想要支持的密度的特定资产。 100x100 的图像需要 40kb； 200x200 的图像需要 160k（未压缩）。因此，MDPI 设备上使用的任何 XHDPI 资源的数据量是您所需数据量的四倍，必须在应用程序启动且资源准备就绪时处理这些数据。更低的内存使用意味着更高的效率，更少出现 OutOfMemoryException 的机会。
此外，自动缩放时特定类型的图像看起来会很糟糕。特别是，具有细线或精细图案的图像的细节会变得模糊。当您手动缩小图像时，您可以选择最适合您需求的算法（线性、双三次、lanczos 等）。
如果您担心自己调整大小所需的时间，可以合并批处理或使用九个补丁调整器等工具：http://code.google.com/p/9patch-resizer/
As of Android 1.6, different densities are handled, including XHDPI (which wasn't officially added until 2.2). Your app will first look for an image matching its density, but it can look into larger "buckets" like XHDPI and then perform the scaling for you.
It's best to include specific assets for the densities you want to support. An image that's 100x100 takes 40kb; and image that's 200x200 takes 160k (uncompressed). So, any XHDPI assets used on MDPI devices have four times the amount of data that you need, which has to be handled when the app starts and your resources are prepared. Lower memory use means greater efficiency, less chance for an OutOfMemoryException.
Further, specific types of images will look bad when automatically scaled. In particular, images with fine lines or fine patterns will have their detail muddied. When you shrink the images by hand, you can choose the algorithm that best matches your needs (linear, bicubic, lanczos, etc.).
If you're worried about the time it takes to do the resizing yourself, you can incorporate a batch process or use tools such as Nine Patch Resizer: http://code.google.com/p/9patch-resizer/
我在一个简单的应用程序（针对 Android 2.1 开发）中仅使用 xhdpi 图像进行了测试，它在小、中和高分辨率下都可以正常工作...即使我在 Android 2.1（小分辨率）中进行了测试，它也可以毫无问题地打开图像。
也许记忆里的东西是真的，所以有必要有人测试一下。
I tested in a simple app (develop for Android 2.1) using only xhdpi images and it works fine in small, medium and high resolutions... even I tested in an Android 2.1 (small resolution) and it opens the imagen without problem.
Maybe the thing with the memory is true, so its necessary someone test this.
我个人发现仅使用 xhdpi 文件夹在许多应用程序中效果很好，并且我是这种方法的大力支持者。在内存开销中确实如此，但对于当今的设备，我认为它可以忽略不计。另外，我认为缩小规模后会涉及一些缓存，因为我从未注意到因此而导致任何速度减慢。仅包含一个文件夹可以显着减小 APK 的大小，最终用户会非常欣赏这一点。您应该记住，某些图像会出现缩放伪影（精细图案等），但我个人在我的应用程序中从未遇到过任何关键问题。另外，对于按钮和其他东西，请务必使用 9 个补丁，以减少圆角上的伪影，您甚至可以通过使用此方法稍微减小图像大小。 API 级别在旧版本上不会成为问题，因为我认为在不支持它的版本上，drawable-xhdpi 被视为只是可绘制的。
不要忽视在 xml 中定义一些简单的可绘制对象的机会，例如，仅使用形状创建渐变背景非常容易，这样您就可以节省空间，并且不会产生缩放伪影的风险。
I personally found that using just xhdpi folder works quite good in many apps and am a big supporter of this approach. In memory overhead is true but with todays devices I would consider it negligible. Also I think there is some caching involved after downscaling since I never noticed any slow down because of this. Including only one folder can dramatically reduce your APK size which end users will quite appreciate. You should keep in mind that some images will get scaling artifacts (fine patterns and stuff) but I personally never encountered nothing critical in my apps. Also for buttons and stuff be sure to use 9patches in order to reduce artifacts on rounded corners, you can even slightly reduce image size by using this approach. API level will not be a problem on older versions since I think that drawable-xhdpi is regarded as just drawable on versions that didn't support it.
Don't ignore chances to define some simple drawables in xml, for example it's really easy to create gradient background with just shapes and with this you save space and don't risk scaling artifacts.
XHDPI 仅在 Android SDK API Level 9 (Gingerbread) 中引入（请参阅 http: //developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_XHIGH）因此，如果您计划将最低 SDK 级别设置为低于 9，则还需要至少提供 HDPI 绘图，否则具有 Froyo 或更低版本的设备将不会显示任何内容。
更新：实际上，Gingerbread 之前的版本似乎会显示 xhdpi 图像： https://groups.google.com/d/msg/android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ
XHDPI was only introduced in Android SDK API Level 9 (Gingerbread) (see http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_XHIGH) so if you plan to have a minimum SDK level of less than 9 you will also need to provide, at least, HDPI drawables as well otherwise devices with Froyo or below will display nothing.
Update: It actually seems like versions prior to Gingerbread will display xhdpi images: https://groups.google.com/d/msg/android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ
只有 xhdpi 资源也可以。但请注意，xhdpi 是在 API 级别 9（姜饼）中引入的。也就是说，如果您的目标 api 级别 <=8，您至少还需要 hdpi 资源。
It's OK to have only xhdpi resources. But note that xhdpi was introduced with api level 9 (gingerbread). That is, if you target api levels <=8 you need at least also hdpi resources.
关于额外内存使用的这种说法是错误的。
如果将
XHDPI大小的可绘制对象放入MDPI文件夹中，则会出现内存问题。但是，如果您在
XHDPI文件夹中提供XHDPI可绘制对象，则不会使用额外的内存，因为 Android 通过跳过部分图像来对图像进行下采样。这种
跳过就是您需要为您计划支持的每个密度提供可绘制对象以使它们看起来不错的原因。另一方面，只有某些图像在下采样时看起来会很糟糕（主要是小图标），因此只要图像有足够的数据可以丢弃，它看起来就不错。或者想象一下，如果您有一个网格作为可绘制对象，那么一些网格线可能会被丢弃，并且图像看起来会很糟糕。
最后，您最好尝试不同的设备，然后您可以判断哪些抽屉需要替代资源来满足其密度。
This statement about extra memory usage is wrong.
If you put
XHDPIsized drawables insideMDPIfolder, then you will have memory problems.But if you provide
XHDPIdrawables insideXHDPIfolder, then no extra memory will be used since android downsamples the images by skipping parts of it.This
skippingis the reason why you need to provide drawables for every density you plan to support in order them to look good.On the other hand, only certain images will look bad when downsampled (mostly small icons) so as long as the image has enough data to be thrown away, it will look ok. Or imagne if you have a grid as a drawable, so potentialy some grid lines can get thrown away and the image will look bad.
In the end, it is better for you to experiment with different devices, then you can tell which drawales need alternative resources for their density.