背景

谷歌这位哥哥真的会整幺蛾子，好不容易把crash跟anr数据压下来一点，最近发现又给了我一条技术质量类型的整改建议，大致内容是

真的是一点不让我闲着，天天关心着我的kpi有没有达标，天天给我整技改。

但话又说回来，这是一条位图的优化建议。这个是说我的项目里面需要使用图片加载库，让它们自动处理降采样、缓存和内存管理。

难道我项目里面的Glide没有做这些事情？还是说我应该去配置点啥？有点懵。看来有必要先去了解下，如何才能真正优化项目中的位图。

什么问题会导致Google Play Console 给出这种整改建议

首先要知道这条建议怎么来的。

Google Play Console 的“位图优化”检测项会扫描 APK/AAB 中的位图资源，看看是否存在以下情况：

• 大尺寸位图是否被直接打包进安装包：图片的实际分辨率远超显示所需，造成安装包体积膨胀和运行时内存浪费
• 是否未使用WebP等高效格式：仍在使用PNG/JPEG等未压缩格式
• 图片未做屏幕密度适配：缺少对不同dpi目录（mdpi / hdpi / xhdpi / xxhdpi / xxxhdpi）的区分
• 运行时未下采样：图片加载到内存时未根据实际显示尺寸做采样，导致内存浪费

如果项目存在以上情况，应用就有可能在谷歌后台收到同样的整改建议。

图片加载库

这是最基本的一点：不要手动管理位图加载。

使用成熟的图片加载库，它们会自动处理缓存、下采样、复用和回收。

现在Android项目主要的图片加载库就是两个，一个是Glide，另一个是Coil。

• Coil的关键配置：ImageLoader、bitmapConfig、size
• Glide的关键配置:DecodeFormat、DownsampleStrategy、override()

Coil配置(Compose项目为例)

全局ImageLoader配置

Compose中使用 AsyncImage

列表中的SubcomposeAsyncImage（异步加载避免卡顿）

自定义ImageLoader拦截器（服务器端裁剪配合）

在 URL 后自动追加目标尺寸参数。

在 ImageLoader中注册

Glide配置(传统Android项目为例)

全局RequestOptions（限制图片质量与下采样）

限制内存缓存与BitmapPool

列表页面的Glide优化

列表Item中明确指定目标尺寸，让Glide自动下采样。

使用Glide的RequestManager生命周期管理

Painter参数陷阱：不要传递 Painter给Composable

为什么通常不建议直接传递Painter？关键就在于，Painter 这个接口本身并没有加上 @Stable 注解。

这样一来，Compose 编译器就很难可靠判断它有没有发生变化，结果往往是触发一些本可以避免的重组。

再往下看，根子其实出在Bitmap：它的 equals() 比较开销本来就不低，所以 Compose 编译器不会轻易把 Painter 认定为稳定类型。

避免Painter触发不必要的重组

传递资源id或URL

在ViewModel中的处理

避免在ViewModel中持有Bitmap或Painter

如果必须持有位图，使用ImageBitmap并注意生命周期

图片下采样（Downsampling）

加载图片时，始终只加载满足显示需求的尺寸。

避免将超大分辨率图片塞进小容器。

使用图片库自动下采样

Coil和Glide在确定目标尺寸后会自动下采样。

Coil的尺寸解析优先级

1. ImageRequest.Builder.size(width, height) ： 显式指定
2. AsyncImage 的 Modifier.size() ： 从布局约束推断
3. 无约束时 ： 加载原始尺寸，这种行为尽量避免

Glide的尺寸解析

使用 override() 显式指定

手动下采样（BitmapFactory）

如果项目中必须手动处理位图，那么可以使用 inSampleSize 进行安全的下采样。

PS:inSampleSize 必须是 2 的幂次（1, 2, 4, 8, 16...），系统会向下取整到最近的 2 的幂

服务器端裁剪优先

最佳实践：请求精确尺寸的图片。

从后端 API 请求图片时，尽量带上目标宽高参数，让服务器返回裁剪后的图片。

这样做的好处是：

• 减少网络传输量（下载更快、流量更省）
• 减少磁盘缓存占用空间
• 减少设备端裁剪的内存开销
• 提升列表滚动流畅度

实现方式

如果使用的是Coil，那么可以用上面讲到的拦截器去做。

如果用的是Glide，可以使用如下方式

后端配合确保CDN或图片服务支持以下参数

参数	说明	示例
w / width	目标宽度	w=200
h / height	目标高度	h=200
m / mode	裁剪模式（fill / fit / crop）	&m=crop
q / quality	压缩质量	&q=80

避免无约束的布局尺寸

不要在加载远程图片的 Composable 上使用 wrapContentSize 或无约束尺寸。

这样做会导致问题。

问题

当图片库无法推断目标边界时，会回退加载完整原始图片，然后就会出现：

• 内存占用远大于实际需要
• 加载延迟增加
• 列表滚动卡顿

原理

正确做法

设置明确尺寸

定义宽高比，让布局引擎计算出确切像素目标

列表中使用固定尺寸

避免无约束，导致加载原始尺寸

选择正确的像素格式

不同像素格式的内存占用差异显著：

格式	每像素位数	支持透明度	适用场景	相比 ARGB_8888 省多少
ARGB_8888	32 bit	支持	需要透明通道（默认）	/
RGB_565	16 bit	不支持	不需要透明度的图片	节省一半内存
ARGB_4444	16 bit	支持	不推荐（画质差）	节省一半（不推荐）
ALPHA_8	8 bit	仅透明度	遮罩/蒙版	节省 75%

不是特殊场景的情况下，应用中 80% 以上的图片RGB_565就够用了。

这样可以立即将内存占用减半。

配置方式

Coil

Glide

判断是否需要透明度

项目当中可以根据不同场景来判断图片是否需要透明度，比如以下四种场景就不需要。

但是如果遇到如下场景，那么就要让图片支持透明度。

GPU纹理上传优化

调用 ImageBitmap.prepareToDraw() 可在实际绘制前提前将纹理上传到 GPU，减少首帧渲染延迟。

大多数图片加载库已内置此优化。

只有在没有用到图片加载库、需要手动调用的时候，才要做如上处理。

硬件位图（Hardware Bitmap）

Android 8.0（API 26）支持硬件位图，位图数据只存在于 GPU 内存中，减少 CPU 内存占用。

如果使用Coil加载库，那么会自动使用硬件位图。

如果使用Glide，Glide默认启用硬件位图，如果想要关闭，可使用以下方式

矢量图优先于位图

对于几何图形、图标等场景，始终优先使用矢量图( ShapeDrawable、VectorDrawable)。

这样做的好处是：

• 矢量文件一个体积也就几百字节，远小于位图
• 可适配任意屏幕密度
• 不随分辨率增加而增大内存占用
• 支持主题色（tint）

既然这样我们还要位图干什么呢？或者什么时候用位图比较合适，什么时候用矢量图比较合适，列了几个场景：

• 图标，logo：适合用矢量图，因为图形简单，文件小，可缩放
• 照片、截图：适合用位图，因为复杂的色彩渐变，是矢量图无法做到的
• 动图图标：适合用矢量图，因为体积小
• 商品图：适合用位图，因为需要真实色彩还原

内存管理与释放

使用图片加载库时

图片库会管理 Bitmap池，在不再需要时将Bitmap释放回池中复用，保留内存缓冲区。

不需要手动回收。

手动管理时

给图片添加内边距的正确方式

在给图片添加内边距时，有人习惯使用letterboxing，直接修改图片尺寸添加透明边框。

但是这样会改变图片尺寸，增大内存占用。

正确的做法是保持图片尺寸不变，使用 InsetDrawable 或在父容器上添加 padding。

避免大图打包进 APK/AAB

有的项目里面，一张静态资源图片可能会有几百k甚至几兆。

直接加载到内存的话，内存一定会飙升。

所以应当避免在项目中引入大图。如果一定要使用大图的话，可以先做下以下几件事情：

• 转换为 WebP 格式（点右键 → Convert to WebP）
• 压缩图片，比如tinyPng
• 托管在服务器上按需下载

多密度适配

尽量将不同分辨率的图片放入对应目录，避免在低密度设备上加载高分辨率图片。

性能监控与分析方法

adb 命令监控

Android Studio Memory Profiler

1. 打开 Profiler → Memory 面板
2. 录制场景：进入页面 → 加载图片 → 滚动 → 离开页面
3. 关注以下指标：
   • Ja va Heap：Bitmap 对象占用的堆内存
   • Native Heap：native 层的 Bitmap 像素数据
   • Graphics：GPU 纹理内存
4. 检查内存是否在离开页面后回落（内存泄漏检测）

Coil内存监控

最后

这段内容主要想说明一件事：项目里该怎么把位图处理到位，尽量避免收到谷歌的警告。

可现实里经常会碰到一种情况——明明项目各个环节都已经把位图问题处理得比较细了，整改建议还是照样会来。

那就别只盯着自己代码排查了，很可能问题就出在某个接入的 SDK 上。

正因为如此，定期去看看所用第三方库官网的更新情况，其实很有必要。

很多时候，开发方已经在新版本里把这类问题修掉了。如果还一直抱着老版本反复分析原因，说到底，就是在白白消耗时间和精力。