图片作为内存消耗大户，一直是开发人员尝试优化的重点对象。Bitmap的内存从3.0以前的位于native，到后来改成jvm，再到8.0又改回到native。fresco花费很多精力在5.0系统之前把Bitmap内存改回到native，高版本上面则遵循系统实现，却又被官方打脸。
jvm每个进程都有内存上限，而native则没有限制（不是没有影响，至少不会oom），所以把内存大户Bitmap挪到native可能是很多人的梦想，但native的管理和实现明显比jvm更为复杂，除非有现成实现，很少有人去动这一块。行业里面的大部分图片库都没有涉及这块，大部分的程序员也秉着够用就好的态度用了很多年，这说明程序员也是会偷懒的。官方的策略修改到底原因几何，其实我也没搜到相关说明，有知道的同学欢迎留言。
第一条规则：把Bitmap保存到native
一个app里面的图片都会有尺寸，一般情况下面图片的尺寸就是view的大小，而view的大小在我们使用dp单位后在不同的机器上面表现出来的实际像素都有差别，为了节约流量开销，加快返回速度，同时符合按需加载的原则，我们应该只加载实际view尺寸大小的图片。一般图片存储提供商都会提供在线压缩服务，我们只需要在请求链接里面加上参数即可。这里还有个问题我们一般请求加载图片的代码都是写在Activity的onCreate，或者Adapter的getView函数里面，这个时候其实是获取不到view尺寸的（还未measure），这里有几种做法：
使用目测：比如一个列表是左右图片布局的，那就可以请求屏幕一半宽度的尺寸图片
view使用了固定尺寸：这个没有问题，我们直接拿getLayoutParams()的width和height就可以了
view的maxWidth/maxHeight：view无法固定尺寸，我们可以在xml里面给view配置maxWidth/maxHeight来指导图片库加载什么尺寸的图片
加载图片前先measure：不怎么推荐，因为图片加载出来后view还得measure一次
一般做法是给图片加载库包装一层，根据传进来的url判断是否已经指定大小（开发者当然可以决定想加载多大图片），如果还未指定则使用上面的策略进行动态调整，如果最后还是没能加上缩放参数，则有个兜底策略，不加载超过屏幕尺寸大小。
第二条规则：按需请求
做了上面按需加载后还有个问题，会发现有时候不同的页面需要加载同一个图片url，但在尺寸上面有细微差别，结果导致请求重复（一般图片加载库都是url作为缓存key），有点弄巧成拙，反倒浪费了流量和时间。这种情况我们需要做些微调。对于A页面图片尺寸是200x200，对于B页面图片尺寸是180x180，我们认为可以使用200x200的图片缩放到180x180，这有两种做法：第一种是让开发者始终都去加载稍微大一点的图，这个要求有点高，一个页面开发的时候很难前后联系。第二种是修改图片加载库，自动完成这个事情。后者自然合理，修改图片加载库在决定使用缓存的那一步判断是否有比自己大的缓存已经存在即可，当然这个策略可以每个产品自己调整，比如也可以认为已经存在的缓存尺寸小于一定值也是可以接受也是可以的。还有复杂的情况比如缓存图片高宽比和要加强的不一样如何处理等等，策略都可以自己定，但一定有必要做这个事情。
这里还要补充一点，大型产品一般图片域名会有好几个，用来做链路择优用的，一定要记得缓存的时候用来做key的url要去掉域名影响。
再补充一点，有些特殊的使用场景可以考虑采用上面说的第一种方式来做，举个例子比如一个操作一定会加载100x100的图，然后也一定会等会加载500x500的同一张图，这种场景下面按第二种方式来处理显然会加载两次，但如果开发者这2个位置写死都加载500x500则明显更好一些。所以方法是死的，人是活的，要看实际使用场景。
还有一些特殊场景，比如程序里面有两个进程，A进程会加载500x500的图，B进程会加载不管什么尺寸的同一张图，默认情况下面这2个请求会同时发出，这就很可能会造成重复请求，这种情况下面需要做一点跨进程同步，或者简单一点其中一个进程请求做一点延迟处理。
第三条规则：合并相似请求
实在不得已要从服务端加载大图或者原始尺寸下来，或者因为上面说的策略故意加载大图下来，在decode的时候要进行采样，这个是老生常谈了，使用options.inJustDecodeBounds来获取原始尺寸，然后按需使用options.inSampleSize来采样图片到接近view尺寸。
第四条规则：按需加载
Bitmap在decode的时候可以使用inPreferredConfig指定配置格式，常见的有：
参数取值含义ALPHA_8图片中每个像素用一个字节（8位）存储，该字节存储的是图片8位的透明度值RGB_565图片中每个像素用两个字节（16位）存储，两个字节中高5位表示红色通道，中间6位表示绿色通道，低5位表示蓝色通道ARGB_4444图片中每个像素用两个字节（16位）存储，Alpha，R，G，B四个通道每个通道用4位表示ARGB_8888图片中每个像素用四个字节（32位）存储，Alpha，R，G，B四个通道每个通道用8位表示
对于质量细节要求比较高的图片可以使用ARGB_888，这也是fresco的默认配置。而对于JPG图片可以使用RGB_565，从上面可以看出内存占用之间减少一半，非常有吸引力，而app里面事实上大部分应该都是JPG。但往往在和视觉的PK当中开发往往败下阵来，降低了图片质量不行！！开发总是锲而不舍，我们可以建议采用这样的策略：对于尺寸小于一定尺寸的JPG（比如300），我们使用565，而对于大图为了保留细节我们仍然使用8888。还是那句话策略是活的。
第五条规则：进一步按需加载
使用三级缓存机制，内存磁盘网络，这也是官方推荐的方式。内存缓存旨在加快访问速度，磁盘缓存避免反复请求。关于这一点就不在赘述了，基本开源图片库都会这么做
第六条规则：使用三级缓存机制
很多场景下面我们需要显示图片的一部分，或者进行图片效果叠加，比如做个倒影之类的。很多同学上来就准备createBitmap，然后把叠加效果绘制到这个临时Bitmap，或者从原始Bitmap里面先剪一部分出来生成一个新的Bitmap，再设给ImageView。或者使用createScaledBitmap进行缩放。更不小心的同学可能直接把这些操作代码写在UI线程，然后写在子线程又比较麻烦，这边推荐的是使用自定义绘制，canvas有个drawBitmap方法可以把某个区域绘制到指定位置。叠加效果也可以完全使用自定义view来自己draw，这样不会有临时Bitmap生成，效率会更高。
如果自定义view有困难，我们可以使用Drawable，只要能拿到canvas，这两种做法是一样的。
这里列举一些实例，好让大家可以进一步理解：
一个按钮有普通和按下状态，按下是普通状态上面叠加一个遮罩，不需要切两张图，按下状态的Drawable可以使用自定义Drawable的canvas先绘制普通状态的图，再在上面绘制一层颜色。或者按下状态使用LayerDrawable，这个Drawable自动帮你做了这个事情
需要把Bitmap的[0,0,200,200]的区域显示到ImageView上面，使用canvas.drawBitmap(bitmap, [0,0,200,200], [0,0,图片宽,图片高],paint)
绘制倒影，这个逻辑性比较强了，这里就不具体展开，canvas的操作学习下，结合局部绘制其实很简单
有个图片，需要在左上角显示一个角标，正常情况下面需要在左上角摆一个view，如果使用Drawable自定义绘制，canvas画一下就好，类似下面的示例代码。
给大家一个自定义绘制的例子，随心组合：
class WithLineDrawable extends DrawableWrapper {
private MyConstantState mMyConstantState;
private boolean mForTop;
private Paint mLinePaint = new Paint();
public WithLineDrawable(Drawable drawable, boolean forTop) {
super(drawable);
mLinePaint.setColor(getLineColor());
mForTop = forTop;
}
@Override
public void draw(Canvas canvas) {
super.draw(canvas);
if (mForTop) {
canvas.drawLine(0, 0, getBounds().width(), 0, mLinePaint);
} else {
canvas.drawLine(0, getBounds().height(), getBounds().width(), getBounds().height(), mLinePaint);
}
}
@Nullable
@Override
public ConstantState getConstantState() {
if (mMyConstantState == null) {
mMyConstantState = new MyConstantState();
}
return mMyConstantState;
}
class MyConstantState extends ConstantState {
@NonNull
@Override
public Drawable newDrawable() {
return new WithLineDrawable(getWrappedDrawable().getConstantState().newDrawable(), mForTop);
}
@Override
public int getChangingConfigurations() {
return 0;
}
}
}
一定要把观念从Bitmap转变到Drawable，当还在费劲心思Bitmap该如何处理的时候，想想Drawable里面如何使用canvas进行各种自定义绘制。
第七条规则：多使用自定义View或者Drawable自定义绘制
图片格式发展到今天已经非常多样了，目前很多开源库都支持了webp来代替jpg和gif，webp在压缩率上面有很多优势，虽然解码上面略逊一筹，经过我们测试还是很不错的。也是推荐大家使用，不论是网络图片下载还是apk内置，用来代替jpg很合适，而代替png则还需要一些时间，主要是低版本系统对于透明webp还有些兼容问题。Android
P上面支持了heif格式也是想代替jpg，不过这个格式目前还没仔细研究过。
对于内置apk的图标类，则推荐使用svg，不再需要切几套图，而且非常小，官方使用的compat包里面解码svg会做缓存，也进一步提升性能。不过也正因为此尽量不要一个图片使用过多不同尺寸。大部分的图标都使用代码代替图片后，apk大小可以明显减少，这也符合我们的原则：能程序画的就绝不切图。
第八条规则：使用更好的图片格式
很多时候我们需要给图标换色，关于颜色混合有一套理论，官方很早就支持，使用ColorFilter，后来compat包里面出了个tint，所以如果有颜色混合处理的相关逻辑，千万不要去生成临时Bitmap，使用类似如下代码：
//1:通过图片资源文件生成Drawable实例
Drawable drawable = getResources().getDrawable(R.mipmap.ic_launcher).mutate();
//2:先调用DrawableCompat的wrap方法
drawable = DrawableCompat.wrap(drawable);
//3:再调用DrawableCompat的setTint方法，为Drawable实例进行着色
DrawableCompat.setTint(drawable, Color.RED);
第九条规则：使用着色API
内置apk的图片资源非常多，总有一些常规图片仍然需要使用jpg或者png，我们要想办法进一步压缩他们，这样可以有效控制apk大小，这里推荐使用ImageOptim，这个工具集合了很多种压缩方式，效果显著。
第十条规则：使用压缩工具
后记：
很多面试的时候问如何做图片加载优化，他们会回答recycle
bitmap，事实上这个操作要很谨慎，一不留神就会导致出问题。大部分的应用不太会干这个事情，吃力不讨好，交给jvm垃圾回收多好。图片解码还有一些参数可以优化，比如inBitmap，这里就不具体展开了。
总结下：
把Bitmap保存到native
按需请求
按需加载
合并相似请求
使用三级缓存机制
多使用自定义View或者Drawable自定义绘制
使用更好的图片格式
使用着色API
使用压缩工具
更多文章请关注微信公众号：安卓之美
