Android 图片加载之原理分析

android加载图片需要哪些优化？

首先，大家应该知道，我们编写的应用程序都是有一定内存限制的，程序占用了过高的内存就容易出现OOM(OutOfMemory)异常，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。因此在展示高分辨率图片的时候，最好先将图片进行压缩

当你需要在界面上加载一大堆图片的时候，需要频繁的加载同一张图片，这时重新去加载一遍刚刚加载过的图片无疑是性能的瓶颈，因此需要使用图片缓存技术

Android中一张图片占据的内存大小是如何计算？

首先，我们需要搞清楚一个概念：我们在电脑上看到的 png 格式或者 jpg 格式的图片，png(jpg) 只是这张图片的容器，它们是经过相对应的压缩算法将原图每个像素点信息转换用另一种数据格式表示，以此达到压缩目的，减少图片文件大小。

而当我们通过代码，将这张图片加载进内存时，会先解析图片文件本身的数据格式，然后还原为位图，也就是 Bitmap 对象，Bitmap 的大小取决于像素点的数据格式以及分辨率两者了。

所以，一张 png 或者 jpg 格式的图片大小，跟这张图片加载进内存所占用的大小完全是两回事。你不能说，我 jpg 图片也就 10KB，那它就只占用 10KB 的内存空间，这是不对的。

那么，一张图片占用的内存空间大小究竟该如何计算？
计算一张图片占用的内存大小公式：分辨率 * 每个像素点的大小。
例如：一张图片宽1080 ，高 452
那么，这张图片的大小按照这个公式应该是：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)

不过，这样的说法并不准确，在 Android 原生的 Bitmap 操作中，某些场景下，图片被加载进内存时的分辨率会经过一层转换，所以，虽然最终图片大小的计算公式仍旧是分辨率*像素点大小，但此时的分辨率已不是图片本身的分辨率了。

tip：

1.图片占据内存空间大小与图片在界面上显示的大小没有关系

2.当图片放在 res 内的不同目录中，最终图片加载进内存所占据的大小会不一样，因为系统在加载 res 目录下的资源图片时，会根据图片存放的不同目录做一次分辨率的转换，而转换的规则是：

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

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

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

目录和dpi的关系.png

3.同一个 app，但跑在不同 dpi 设备上，同样的界面，但所耗的内存有可能是不一样的

因为设备的dpi不一样