一、前言

笔者最近致力于vivo游戏核心稳定性保护，在分析线上异样时，发现有相当一部分是由OutOfMemory引起。谈及OOM，咱们个别都会想到内存透露，其实，往往还有另外一个因素——图片，如果对图片使用不当的话，很容易吃掉大量内存，从而导致异样。

尤其是游戏核心在2020末~2021初的几个重要版本，上线了很多内容相干的feature，引入大量图片、视频列表，从而导致线上OOM占比回升。

在这篇文章中，笔者将解说一张看似一般的Bitmap对内存的占用，介绍Android Studio中帮忙咱们剖析图片占用内存的工具，举例说明风行的两大图片加载框架：Glide、Picasso在加载图片时应用内存的不同形式，接着剖析不同drawable目录下图片的显示策略，最初基于手机内存、版本，提出一种优化内存调配的计划。

二、查看图片内存占用

一张图片在内存占用的空间到底有多少，普遍存在的一个误会是，图片自身在磁盘上/从网络下载下来是多大，就会占用多少的内存。这种说法是不正确的，图片占用内存的大小不取决于它自身的大小，而取决于图片库所采纳的展现形式所申请的内存。

拿钢铁侠这张图片举例，它的尺寸是350*350，能够看到在电脑磁盘上，它只占36KB的空间。

咱们创立一个简略的Demo，页面正地方是一个ImageView，用于显示这张钢铁侠图片。

通过Android Studio进行heap dump，从而看图片所占用的内存。首先咱们将显示图片时的内存快照保留下来。操作门路为Profiler -> Memory -> Heap Dump，这会生成一个dump文件，在其中能够看到以后堆的应用状况。

在上面这张图能够看到，程序运行时，“钢铁侠”这张图片占用的内存（Retained Size）是2560000bytes，约等于2.4MB内存。与它在磁盘上36KB的大小，相差了整整70倍！

小技巧：如何查看dump文件中的图片

在调试时，如果咱们手头只有一个dump文件，往往须要还原图片内容，以帮忙定位问题。有两种形式能够从dump文件里提取原图片。

形式一：通过Android Studio间接查看

如果dump文件起源自Android版本为7.1.1（Android N，API=25）及以下的设施，能够应用这种办法。选中Bitmap对象，间接在窗口的Bitmap Preview中查看图片内容（如上图），十分不便。

形式二：通过MAT+GIMP查看

这种办法实用于全副Android版本的设施，首先用MAT关上dump文件，有时会产生下图的谬误：

起因是Android Studio的Profiler生成的dump文件不是规范格局，咱们能够应用位于门路SDK/platform-tools/hprof-conv.exe的工具将其转换为规范格局，转换命令为：

hprof-conv.exe <in-file> <out-file>

将转换后的dump文件通过MAT关上，在其中找到Bitmap对象的byte[]属性，将其复制为image01.data文件。

Tip: 能够看到这里image01.data文件的尺寸是2.44MB，也正是在运行时图片所占用的内存。

而后用GIMP工具关上该文件，在格局那里抉择RGBA（大部分Bitmap都应用这种格局），宽与高能够在MAT中看到，笔者这里是800 * 800。设置好格局和宽高后，就能够看到图片的实在面目了。

二、图片内存占用计算公式

在上一章节咱们晓得一个通过网络下载的36KB图片，在被加载到内存中时，须要2.4MB的空间。接下来解释这其中的换算关系，让咱们记住一个公式：

图片占用内存 = 图片品质 * 宽 * 高

这外面有“图片品质”、“宽”、“高”三个因素，它波及到图片加载框架的实现，不同的框架，对于这三者的默认取值是不一样的，咱们以以后最风行的Picasso和Glide为例。

Picasso

在Picasso中，图片默认显示的宽高与原始图片宽高统一。依然以这张钢铁侠为例，图片自身是350px 350px，当咱们把它加载到200px 200px的ImageView当中时，占用空间是0.49MB。

因而，在指标ImageView小于图片尺寸的状况下，好的做法是应用不超过ImageView尺寸的图片源，一方面能够缩短图片下载工夫，另一方面有助于优化内存占用。

Glide

Glide则采纳截然不同的解决形式，它最终应用的宽高是指标ImageView的宽高。如果咱们把同样一张图片加载到200px * 200px的ImageView中，占用空间只有0.16MB。

使Picasso达到与Glide同样的成果

Picasso的设计者也发现了这一毛病，提供一系列办法用来调整最终加载进去的图片尺寸，其一就是fit()，通过这个办法能够达到与Glide同样的成果。

Picasso().get().load(IMAGE_URL).fit().into(imageVIEW)

相同场景：小图加载到大ImageView中

通常为了提供更清晰的界面，避免图片拉伸后失真含糊，设计师提供的图片都是高分辨率的，咱们所面临的场景是将大图加载到小ImageView中。但也不排除相同的可能：将小图加载到大ImageView外面。这时Glide默认采纳的内存策略是存在有余的：它采纳指标ImageView的尺寸作为最终的宽和高。

举例说明，当把350 350的钢铁侠图片加载到600 600的ImageView中时，占用的内存高达1.41MB。

600 600 4bytes = 1.41MB

有没有一种办法，能够兼顾原图片与指标ImageView不同的大小关系呢？——有的，这就是centerInside()。

Glide.with(this).load(IMAGE_URL).centerInside().into(imageView)

借助centerInside()办法，能够达到“在原图片和指标ImageView中取最小宽高作为最终加载图片的尺寸”这样的成果。

三、图片品质

什么是“图片品质”？简略说就是用多少字节来示意一个像素点的色彩，它的学名叫做“位深度”，在图片属性当中能够看到。

图片位深度通常有1位、8位、16位、24位、32位。

PNG格局有8位、24位、32位三种模式，其中8位PNG反对两种不同的通明模式（索引通明和alpha通明），24位PNG不反对通明，32位 PNG 在24位根底上减少了8位通明通道，因而可展示256级通明水平。

Glide和Picasso默认采纳的图片品质都是ARGB_8888、也就是带透明度的32位深度，一个像素点须要占用4bytes的内存，这也解释了为什么上文中的计算都是采纳宽_高_4bytes的公式。

注：v4开始，Glide将ARGB\_8888作为默认配置。在那之前它始终默认应用RGB\_565。

对客户端应用的大部分图片来说，32位深度、16位深度的显示品质是肉眼较难分辨的，但它们在占用内存上相差了整整一倍。因而，笔者倡议在大部分场景下，应用RGB_565作为加载图片的模式。以下两种场景除外：

1）含通明局部的图片：如果采纳RGB_565图片格式来显示图片，是无奈失常展示通明区域的。比方上方这个钢铁侠图片，本来通明的局部会被显示为彩色。

2）含渐变色并且对显示品质要求高的图片：32位比16位能够反对更多的色彩，在突变的显示上出现更加天然的过渡（如下图）。这时咱们该当在显示品质和利用性能之间作取舍。对于低端设施，利用的稳定性比显示品质更加重要，笔者强烈建议采纳16位深度来显示。

四、drawable目录下图片加载形式

我的项目的资源目录下，个别都有drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi目录，它们是用来匹配不同显示密度的设施的，对应表格如下。

通过adb shell wm density能够获取以后设施的dpi，对Nexus 6P模拟器执行后，能够读取到它的dpi是560，属于xxxhdpi。

$ adb shell wm densityPhysical density: 560

那么同一个图片放在不同目录下，对分配内存是否有影响呢？答案是有的，基于两步简略的推导：

图片所在资源目录、设施密度两者决定图片最终显示在屏幕上的像素尺寸；
像素尺寸、图片品质独特决定分配内存。

其中第2点曾经在上文解说过，这里次要剖析第1点。应用图片编辑软件，将本来是350 350的钢铁侠图片放大至700 700，并别离放入xhdpi、xxxhdpi两个目录下。

为什么应用这样的组合呢？因为从上表得悉，xhdpi与xxxhdpi的显示密度是1:2，意味着一台xxxhdpi的设施在显示drawable-xhdpi目录下的图片时，会将其放大为2倍进行展现。因而咱们将350 350的骨片放入drawable-xhdpi，将700 700的图片放入drawable-xxxhdpi，预期它们最终在屏幕上显示的尺寸雷同。

在布局里创立两个ImageView，察看这两张图片最终的显示成果，以及分配内存状况。

<FrameLayout    xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="match_parent"    android:background="#000000">    <!-- 350 * 350，位于drawable-xhdpi -->    <ImageView        android:id="@+id/iv_image_1"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:padding="40dp"        android:src="@drawable/iron_man_350_square_xhdpi"        />    <!-- 700 * 700，位于drawable-xxxhdpi -->    <ImageView        android:id="@+id/iv_image_2"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:padding="40dp"        android:layout_gravity="bottom"        android:src="@drawable/iron_man_700_square_xxxhdpi"        /></FrameLayout>

显示成果以及内存调配如下：

能够剖析得出以下论断：

对于显示尺寸613 613的图片，其占据内存为613 613 * 4 = 1,503,076B ≈ 1.5MB，合乎上文中咱们对图片内存的剖析；
决定图片占用内存的是其最终显示在屏幕上的尺寸，与图片自身分辨率、在哪个drawable目录下没有间接关系；
因为xxxhdpi密度是xhdpi密度的两倍，故在屏幕密度属于xxxhdpi的Nexus 6P设施上，drawable-xxxhdpi目录下的图片被以近似于原像素尺寸（700px）进行显示（显示为613px），而位于drawable-xhdpi目录下的图片被放大至2倍显示，最终显示尺寸同样是613px。

五、优化策略

在理论的开发中，咱们心愿中高端机型加载更清晰的图片（ARGB\_8888），以晋升用户体验，对于低端机型则心愿加载占用内存更小的图片（RGB\_565），以升高OOM产生的概率。能够在初始化Glide时进行这样的配置。须要注意的是不要对含通明区域的图片采纳这种优化计划。

@GlideModuleclass MyGlideModule : AppGlideModule() {    override fun applyOptions(context: Context, builder: GlideBuilder) {        builder.setDefaultRequestOptions(RequestOptions().format(getBitmapQuality()))    }    private fun getBitmapQuality(): DecodeFormat {        return if (Build.VERSION.SDK_INT < Build.VERSION_CODES.N || hasLowRam()) {            // 低端机型采纳RGB_565以节约内存            DecodeFormat.PREFER_RGB_565        } else {            DecodeFormat.PREFER_ARGB_8888        }    }}

六、小结

借助一些开源工具，咱们能够便捷地定位大图，如滴滴开源的DoKit，篇幅起因不进行具体介绍。最初，对于咱们日常开发总结几点倡议，心愿大家的利用稳定性节节攀升。

在多图的场景（比方RecyclerView）留神及时开释图片资源；
应用占据内存更小的图片格式；
图片源文件尺寸该当与指标ImageView相近；
优先满足xxhdpi、xxxhdpi的图片资源需要；
依据设施性能，采纳不同的图片加载策略。

作者：vivo互联网客户端团队-Li Lei