https://www.cnblogs.com/popfisher/p/6959106.html
https://www.cnblogs.com/dasusu/p/9789389.html
（以上两篇博客很不错）
我们先假设我们有一张图片时 600 * 800 的，图片占用空间大小假设是 100KB。
图片内存大小跟占用空间大小有什么关系？
占用空间的大小不是图片占用内存的大小，一些初学者可能会误解一下。占用空间是在磁盘上占用的空间，内存大小是加载到内存中占用的内存大小。两个只是单位是一样的，本质不是一个概念。
一张图片到底占用多少内存呢？
1. 图片占用内存的计算公式：图片高度 * 图片宽度 * 一个像素占用的内存大小
2. 所以上面的图片占用内存是：800 * 600 * 4 byte = 1875KB = 1.83M
当图片放在 res 内的不同目录中时，为什么最终图片加载进内存所占据的大小会不一样呢？
如果你们去看下Bitmap.decodeResource()源码，你们会发现，系统在加载 res 目录下的资源图片时，会根据图片存放的不同目录做一次分辨率的转换，而转换的规则是：
新图的高度 = 原图高度 * (设备的 dpi / 目录对应的 dpi )
新图的宽度 = 原图宽度 * (设备的 dpi / 目录对应的 dpi )
目录名称与 dpi 的对应关系如下，drawable 没带后缀对应 160 dpi：
所以，我们来看下序号 2 的实验，按照上述理论的话，我们来计算看看这张图片的内存大小：
转换后的分辨率：1080 * （240/160） * 452 * （240/160） = 1620 * 678
同一图片，在同一台设备中，如果图片放在 res 内的不同资源目录下，那么图片占用的内存空间是会不一样的
同一图片，放在 res 内相同的资源目录下，但在不同 dpi 的设备中，图片占用的内存空间也是会不一样的
图片优化
所以，如果单从图片本身考虑优化的话，也就只有两个方向：
降低分辨率
减少每个像素点大小
总结
最后，来稍微总结一下：
一张图片占用的内存大小的计算公式：分辨率 * 像素点大小；但分辨率不一定是原图的分辨率，需要结合一些场景来讨论，像素点大小就几种情况：ARGB_8888(4B)、RGB_565(2B) 等等。
如果不对图片进行优化处理，如压缩、裁剪之类的操作，那么 Android 系统会根据图片的不同来源决定是否需要对原图的分辨率进行转换后再加载进内存。
图片来源是 res 内的不同资源目录时，系统会根据设备当前的 dpi 值以及资源目录所对应的 dpi 值，做一次分辨率转换，规则如下：新分辨率 = 原图横向分辨率 * (设备的 dpi / 目录对应的 dpi ) * 原图纵向分辨率 * (设备的 dpi / 目录对应的 dpi )。
其他图片的来源，如磁盘，文件，流等，均按照原图的分辨率来进行计算图片的内存大小。
jpg、png 只是图片的容器，图片文件本身的大小与它所占用的内存大小没有什么关系。
基于以上理论，以下场景的出现是合理的：
同个 app，在不同 dpi 设备中，同个界面的相同图片所占的内存大小有可能不一样。
同个 app，同一张图片，但图片放于不同的 res 内的资源目录里时，所占的内存大小有可能不一样。
以上场景之所说有可能，是因为，一旦使用某个热门的图片开源库，那么，以上理论基本就不适用了。
因为系统支持对图片进行优化处理，允许先将图片压缩，降低分辨率后再加载进内存，以达到降低占用内存大小的目的
而热门的开源图片库，内部基本都会有一些图片的优化处理操作：
当使用 fresco 时，不管图片来源是哪里，即使是 res，图片占用的内存大小仍旧以原图的分辨率计算。
当使用 Glide 时，如果有设置图片显示的控件，那么会自动按照控件的大小，降低图片的分辨率加载。图片来源是 res 的分辨率转换规则对它也无效。
的
