Android应用是否需要提供xxhdpi、xxxhdpi等多套尺寸的本地图片资源？

单套xxxhdpi资源缩放的性能问题 #

首先纠正一个容易踩的坑：无后缀的drawable文件夹默认对应mdpi等级，如果你直接把xxxhdpi规格的图片放在这个文件夹下，系统会将其识别为mdpi资源，在高dpi设备上会被数倍放大加载，反而会出现内存暴涨、图片模糊的问题，正确的做法是把这套xxxhdpi资源放到drawable-xxxhdpi文件夹下。

针对你关心的缩放性能问题：

• 系统对本地drawable资源的缩放只会在首次加载时执行一次，缩放后的Bitmap会被存入资源缓存，后续复用不会重复计算，CPU开销极低，普通应用场景完全可以忽略
• 内存占用不会额外增加：缩放后的Bitmap尺寸是匹配当前设备dpi的，反而比强制加载全尺寸xxxhdpi资源的内存占用更低

两个通用问题解答 #

1. xxxhdpi规格下使用更小体积的图片是否有收益？ #

收益分场景明确存在：

• 必然收益：图片体积越小，安装包占用空间越小，用户下载安装转化率越高；同时小体积图片的磁盘IO耗时更短，加载速度更快
• 内存收益分情况：如果是同分辨率、同编码格式的图片，只是压缩率更高导致体积更小，只要解码后的像素尺寸、像素格式（比如ARGB_8888）一致，运行时内存占用完全相同，没有内存收益；如果体积小是因为你裁剪了多余像素、移除了不必要的透明通道、降低了超出显示需求的分辨率，解码后的Bitmap尺寸更小，会有明显的内存降低收益

2. 可用jpg的场景用png是否有负面影响？ #

• 内存层面无差异：图片加载到内存后都会被解码为原始像素数组，只要最终解码的像素尺寸、像素格式一致，不管源文件是jpg还是png，运行时内存占用完全相同
• 其他层面的负面影响：同画质下png的文件体积普遍比jpg大30%以上，会增加安装包体积和IO加载耗时；同时png的解码速度略低于jpg，批量加载大量资源时会有可感知的速度差异

如果你的图片不需要透明通道，更推荐使用webp格式，同画质下体积比jpg还要小25%-35%，Android 4.0及以上系统已经原生支持webp的解码，适配成本极低。

针对自定义背景场景的额外建议 #

因为你支持用户更换自定义图片，建议加载用户上传的图片时，先按应用需要的最大显示分辨率做下采样处理，避免用户上传超大分辨率图片导致内存溢出。

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