2024年Android图片资源管理：多密度drawable vs 单张高分辨率assets？

背景与问题 #

我正在开发一款原生Android应用，正考量图片资源的最优管理方式。传统做法是将每张图片的多个尺寸版本分别存入drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi等不同drawable目录，以适配不同设备的屏幕密度，但我质疑该方式在当下是否仍具必要性。

鉴于Android在图片与屏幕密度处理上的技术进步，仅在assets文件夹中存储单张高分辨率图片（例如原本100x100的图存储为400x400），再根据设备屏幕密度动态调整尺寸，是否更高效或更具优势？

以原本100x100的图片为例，传统存储的各密度版本如下：

drawable-mdpi = 100x100
drawable-hdpi = 150x150
drawable-xhdpi = 200x200
drawable-xxhdpi = 300x300
drawable-xxxhdpi = 400x400

但在屏幕密度系数为2.625的Google Pixel 7这类设备上，系统会从drawable-xxhdpi获取300x300的图片，再将其缩放到263x263px，这会导致图片被两次缩放，可能降低画质。

我有两个具体疑问：

• 许多应用似乎主要将图片存储在assets文件夹而非drawable目录，这是否为普遍做法？
• 2024年Android应用处理图片时，兼顾画质与性能的推荐方案是什么？

核心结论与推荐方案 #

1. 传统多密度drawable目录的必要性 #

传统全密度版本的做法已经没必要全覆盖了，但也不能完全抛弃：

• 目前主流设备的屏幕密度集中在xxhdpi和xxxhdpi，mdpi/hdpi这类低密设备占比极低，可简化为只保留xxhdpi（作为基准）和xxxhdpi版本，甚至只保留xxxhdpi版本。
• 系统向下缩放高分辨率图片的画质损耗远小于向上拉伸低分辨率图，所以只存高密图让系统自动适配低密设备，画质损失基本可以忽略。
• 像Pixel 7这类非标准密度设备，若只提供xxxhdpi的400x400图，系统只需一次缩放到263x263，避免了传统方案中先从xxxhdpi缩到xxhdpi、再由系统缩到目标尺寸的两次缩放，画质会更好。

2. assets存储图片是否是普遍做法？ #

不算普遍，主流应用还是优先用drawable目录：

• drawable目录能享受系统的自动密度适配、资源索引优化，还支持Android App Bundle的按密度分包，用户下载时只会获取对应设备密度的资源，大幅减小APK下载体积。
• assets的使用场景通常是需要动态加载、自定义缩放逻辑，或是存储非图片类资源（如字体、配置文件），普通UI图片用drawable更省心高效。

3. 2024年兼顾画质与性能的推荐方案 #

• 优先使用VectorDrawable：对于图标、简单图形类资源，直接用矢量图，完全适配所有屏幕密度，体积小且画质无损，是当前最优解。
• 简化位图密度版本：位图资源只保留xxhdpi和xxxhdpi，或仅保留xxxhdpi，既减少维护成本，又能保证多数设备的画质。
• 采用高效图片格式：用WebP或AVIF替代PNG/JPG，同等画质下体积可减小30%-50%。Android 7.0+完全支持WebP，Android 12+支持AVIF，能显著降低APK体积，提升加载性能。
• 借助图片加载库：如果是大量网络图片，使用Glide、Coil这类成熟的图片加载库，它们会自动根据设备密度加载适配尺寸的图片，同时优化内存与磁盘缓存，避免内存溢出。
• 自定义缩放优化：若必须用assets存储位图，处理缩放时要使用BitmapFactory.Options设置inSampleSize和inScaled，或通过Canvas配合Paint.setFilterBitmap(true)实现高质量缩放，减少画质损耗。

内容的提问来源于stack exchange，提问作者zeus