Android中一张图片占据的内存大小是如何计算(1)，Android彻底组件化方案实践方法

好了，我们开始来分析这些实验数据：

首先，如果按照图片大小的计算公式：分辨率 * 像素点大小

那么，这张图片的大小按照这个公式应该是：1080 * 452 * 4B = 1952640B ≈ 1.86MB

ps: 这里像素点大小以 4B 来计算是因为，当没有特别指定时，系统默认为 ARGB_8888 作为像素点的数据格式，其他的格式如下：

• ALPHA_8 – (1B)
• RGB_565 – (2B)
• ARGB_4444 – (2B)
• ARGB_8888 – (4B)
• RGBA_F16 – (8B)

上述实验中，按理就应该都是这个大小，那，为什么还会出现一些其他大小的数据呢？所以，具体我们就一条条来分析下：

分析点1

先看序号 1，2 的实验，这两者的区别仅在于图片显示的空间的大小上面。做这个测试是因为，有些人会认为，图片占据内存空间大小与图片在界面上显示的大小会有关系，显示控件越大占用内存越多。显然，这种理解是错误的。

想想，图片肯定是先加载进内存后，才绘制到控件上，那么当图片要申请内存空间时，它此时还不知道要显示的控件大小的，怎么可能控件的大小会影响到图片占用的内存空间呢，除非提前告知，手动参与图片加载过程。

分析点2

再来看看序号 2，3，4 的实验，这三个的区别，仅仅在于图片在 res 内的不同资源目录中。当图片放在 res 内的不同目录中时，为什么最终图片加载进内存所占据的大小会不一样呢？

如果你们去看下 Bitmap.decodeResource() 源码，你们会发现，系统在加载 res 目录下的资源图片时，会根据图片存放的不同目录做一次分辨率的转换，而转换的规则是：

新图的高度 = 原图高度 * (设备的 dpi / 目录对应的 dpi )

新图的宽度 = 原图宽度 * (设备的 dpi / 目录对应的 dpi )

目录名称与 dpi 的对应关系如下，drawable 没带后缀对应 160 dpi：

所以，我们来看下序号 2 的实验，按照上述理论的话，我们来计算看看这张图片的内存大小：

转换后的分辨率：1080 * （240/160） * 452 * （240/160） = 1620 * 678

显然，此时的分辨率已不是原图的分辨率了，经过一层转换，最后计算图片大小：

1620 * 678 * 4B = 4393440B ≈ 4.19MB

这下知道序号 2 的实验结果怎么来的了吧，同样的道理，序号 3 资源目的是 hdpi 对应的是 240，而设备的 dpi 刚好也是 240，所以转换后的分辨率还是原图本身，结果也才会是 1.86MB。

小结一下：

位于 res 内的不同资源目录中的图片，当加载进内存时，会先经过一次分辨率的转换，然后再计算大小，转换的影响因素是设备的 dpi 和不同的资源目录。

分析点3

基于分析点 2 的理论，看下序号 5，6，7 的实验，这三个实验其实是用于跟序号 2，3，4 的实验进行对比的，也就是这 6 个实验我们可以得出的结论是：

• 同一图片，在同一台设备中，如果图片放在 res 内的不同资源目录下，那么图片占用的内存空间是会不一样的
• 同一图片，放在 res 内相同的资源目录下，但在不同 dpi 的设备中，图片占用的内存空间也是会不一样的

所以，有可能出现这种情况，同一个 app，但跑在不同 dpi 设备上，同样的界面，但所耗的内存有可能是不一样的。

为什么这里还要说是有可能不一样呢？按照上面的理论，同图片，同目录，但不同 dpi 设备，那显然分辨率转换就不一样，所耗内存应该是肯定不一样的啊，为什么还要用有可能这种说辞？

emmm，继续看下面的分析点吧。

分析点4

序号 8，9 的实验，其实是想验证是不是只有当图片的来源是 res 内才会存在分辨率的转换，结果也确实证明了，当图片在磁盘中，SD 卡也好，assert 目录也好，网络也好（网络上的图片其实最终也是下载到磁盘），