Android图片加载机制
1.系统支持4种格式的色彩格式 源码在.中，如下图：
.：只有一个alpha通道，每个像素占1个字节（Byte）
.：只有RGB3个通道，没有alpha通道，R（红）G（绿）B（蓝） 分量分别使用5位、6位、5位，没有透明度，所以一个像素点占 16 位，也就是 2 字节。
.：ARGB 分量都是8 位，ARGB 分量都是8 位，所以一个像素点占 32 位，也就是 4 字节，它是最能保证图片效果的一种模式
.系统默认格式为：
2、系统内存策略
1) .4-.0：图片内存的加载，是在Java 堆栈，进程的内存占用量为16M，因为他除了java中持有数据外，底层C++的skia图形库还会持有一个对象，因此一般图片占用内存推荐大小应该不超过8M。如果超过这个限制，会出现OOM异常
2) .0及以上：8.0之后的内存分配是在，Java层的创建之后，实际上像素内存的分配是在层直接调用，所以其像素分配的是在 heap上， 这也是为什么8.0之后的消耗内存可以无限增长，直到耗尽系统内存，也不会提示Java OOM的原因，但是会出现的异常ANR
3、图片占用内存与宽、高、色彩模式的关系
1) 以一张1080*1920分辨率的图片为例，占用内存=宽*高*像素点大小所占用内存
2) 加载这张图片的原始内存为：1080*1920*4 = = =7.91M（约为7.91M）
3) 由于图片加载非常耗内测，所以加载图片时，会通过多个途径进行优化：
4) 设置压缩比：为了保证图片正常显示，会根据屏幕/图片/组件大小，设置最优压缩比，设置方式：
val options = BitmapFactory.Options()
options.inSampleSize = 2
val bitmap1 = BitmapFactory.decodeResource(resources, R.drawable.test_xxhdpi, options)我们以压缩比为2为例：宽和高都为之前的1/2
加载耗用内存为:1080*1/2*1920*1/2*4 = = = 1.98M（约为1.98M），为设置压缩比之前的1/4
5) 设置图片色彩模式（默认为）：
默认是是32位，占用4byte（4字节）
在设置压缩比后，将图片色彩模式设置为，占用16位，两字节，为默认的1/2，所以设置压缩比并图片色彩模式后，占用内存为1080*1/2*1920*1/2*4*1/2 = 1012.5KB = 0.99M（约为0.99M），为原生的1/8
4、本地图片与网络图片 4.1 本地图片：
ldpi： 屏幕密度为120的手机设备
mdpi： 屏幕密度为160的手机设备（此为，其他均以此为基准，在此设备上，1dp = 1px）
hdpi： 屏幕密度为240的手机设备 1.5倍dpi
xhdpi： 屏幕密度为320的手机设备 2倍dpi
：屏幕密度为480的手机设备 3倍dpi
：屏幕密度为640的手机设备 4倍dpi
同一张1920*1080的图片放在不同资源文件夹下，耗用内存如下（所以对应资源放对应尺寸图 片）：
1) 以屏幕宽度为480的手机设备的手机，为100px * 100px为例：
放在文件夹下，图片尺寸为 100 * 100 * （480 / 480)，内存消耗为 1920 *1080 * 480 / 480 * 4 =
2) 以屏幕宽度为640的手机设备的手机，为100px 100px为例：放在文件夹下，图片尺寸为 100 * 100 *（480/640）为原始的3/4，内存消耗为 1920 *（480/640）* 1080 （480/640）* 4 = 4556.25kb，为原始的9/16
3) 以屏幕宽度为320的手机设备的手机，为100px 100px为例：放在xhdpi资源文件下，图片尺寸为100* 100*（480/320）为原始的3/2， 内存消耗为1920*（480/320）*1080*（480/320）*4= ，为原始的2.25倍
结论为：
图片尺寸为：手机终端的dpi / 图片所在资源目录对应的dpi * 图片尺寸
图片内存为：宽*（手机终端的dpi / 图片所在资源目录对应的dpi）*高*（手机终端的dpi / 图片所在资源目录对应的dpi）*像素点大小所占用内存
4.2 网络图片：
网络图片不受文件夹约束，占用内存为：宽*高*像素点大小所占用内存（一般我们通过压缩比和设置色彩模式来调节）网络图片使用Glide框架加载，压缩比已帮我们自动计算，默认色彩模式
5、Glide框架的好处 5.1图片加载的总体流程介绍
1) 封装参数：从指定来源，到输出结果，中间可能经历很多流程，所以第一件事就是封装参数，这些参数会贯穿整个过程；
2) 解析路径：图片的来源有多种，格式也不尽相同，需要规范化；
3) 读取缓存：为了减少计算，通常都会做缓存；同样的请求，从缓存中取图片（）即可；
4) 查找文件/下载文件：如果是本地的文件，直接解码即可；如果是网络图片，需要先下载；
5) 解码：这一步是整个过程中最复杂的步骤之一，有不少细节；
6) 变换：解码出之后，可能还需要做一些变换处理（圆角，滤镜等）；
7) 缓存：得到最终之后，可以缓存起来，以便下次请求时直接取结果；
8) 显示：显示结果，可能需要做些动画（淡入动画，等）
5.缓存机制做了哪些优化？
下载图片是非常耗费资源的，所以图片缓存机制是图片加载框架很重要的一部分：
1.
缓存类型
缓存代表
说明
活动缓存
如果当前对应的图片资源是从内存缓存中获取的，那么会将这个图片存储到活动资源中。
内存缓存
图片解析完成并最近被加载过，则放入内存中
磁盘缓存-资源类型
被解码后的图片写入磁盘文件中
磁盘缓存-原始数据
网络请求成功后将原始数据在磁盘中缓存
2.Glide的缓存机制，主要分为2种缓存，一种是内存缓存，一种是磁盘缓存。
之所以使用内存缓存的原因是：防止应用重复将图片读入到内存，造成内存资源浪费。
之所以使用磁盘缓存的原因是：防止应用重复的从网络或者其他地方下载和读取数据。
正式因为有着这两种缓存的结合，才构成了Glide极佳的缓存效果。
3.Glide详解链接：
