Android应用中大量图片的高效处理方案咨询
问题背景
我开发的Android应用包含约200张可选商品图片，目前用Glide从本地加载。为适配不同分辨率，将原图转换为mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi五套资源存入对应drawable目录，但单张图五套总大小达18MB，200张总计3.6GB，导致包体过大。
可行优化方案
只保留最高分辨率资源，依赖系统自动缩放
把所有图片仅放在drawable-xxxhdpi目录，Android系统会根据设备分辨率自动向下缩放适配。这样单张图仅需7.8MB，200张总大小降至1.56GB，直接砍掉近一半体积。虽然低分辨率设备会有轻微的缩放性能开销，但当前中高端设备占比极高，实际影响可忽略；再配合Glide的缓存机制，能进一步降低重复缩放的消耗。替换为WebP格式
WebP在画质相当的前提下，比JPG小25%-35%、比PNG小50%以上。将五套分辨率的图片全部转成WebP，单张总大小可从18MB压缩至12-14MB，200张总大小控制在2.4-2.8GB，同时保留多分辨率适配优势。Android 4.2.1+原生支持WebP，Glide也完美兼容，无需担心兼容性问题。图片按需下载（最推荐）
将图片托管到后端服务器，用户浏览对应商品时，通过Glide从网络加载并缓存到本地。APK包体仅需保留少量占位图，彻底解决本地存储占用问题。可配置Glide的缓存策略，让高频访问的图片长期留存，低频图片自动清理；若需支持离线使用，可在首次启动时批量下载核心商品图，或提供手动离线下载功能。采用Android App Bundle（AAB）发布
提交应用时使用AAB格式，Google Play会根据用户设备的分辨率，仅下发对应分辨率的图片资源。比如xxxhdpi设备只获取xxxhdpi图，mdpi设备仅获取mdpi图，用户实际下载的APK体积会大幅降低（200张图的单分辨率包体仅1.56GB或140MB）。国内主流应用市场也大多支持类似的按需分发机制。压缩图片画质
用图片压缩工具对原图及各分辨率图进行无损/有损压缩，在画质损失可接受的前提下减小体积。比如原图从4.2MB压缩至2MB，对应五套图总大小也会成比例下降，200张总大小可控制在1.8GB以内。
关于保留多分辨率同时控包体的可行性
完全可以实现，核心思路是：
- 转WebP格式，在保留多分辨率的基础上大幅降低单图体积
- 采用AAB发布，让不同设备仅获取对应分辨率资源，用户侧包体极小，开发者只需维护一套全分辨率资源
- 结合图片压缩工具，进一步挤压各分辨率图的体积冗余
内容的提问来源于stack exchange，提问作者VanessaF
