图片作为内存消耗大户,一直是开发人员尝试优化的重点对象。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
    • 使用压缩工具

Android图片优化指南的更多相关文章

  1. Unity开发Android应用优化指南(下)

    http://forum.china.unity3d.com/thread-27044-1-1.html 在Unity开发Android应用优化指南(上)一文中,从游戏性能,脚本等方面进行了分析和总结 ...

  2. android图片优化

    /1.不要将Button的背景设置为selector 如果是将Button的背景设置为selector,在初始化Button的时候会将正反选图片都加载在内存中,相当于一个按钮占用了两张相同大小图片所使 ...

  3. Unity开发Android应用优化指南(上)

    http://forum.china.unity3d.com/thread-27037-1-2.html 如今越来越多的开发者使用Unity开发Android及iOS项目,开发过程中难免会遇到一些性能 ...

  4. Android 性能优化——之图片的优化

    Android 性能优化——之图片的优化 在Android性能优化中,我们会发现占内存最大的和对性能影响最大的往往是图片资源,其次是控件资源.相对来说,其他的资源的影响会小一点.这里我就先对图片资源的 ...

  5. 性能优化——Android图片压缩与优化的几种方式

    图片优化压缩方式大概可以分为以下几类:更换图片格式,质量压缩,采样率压缩,缩放压缩,调用jpeg压缩等1.设置图片格式Android目前常用的图片格式有png,jpeg和webp,png:无损压缩图片 ...

  6. Android性能优化之图片压缩优化

    1 分类Android图片压缩结合多种压缩方式,常用的有尺寸压缩.质量压缩.采样率压缩以及通过JNI调用libjpeg库来进行压缩. 参考此方法:Android-BitherCompress 备注:对 ...

  7. Android APP内存优化之图片优化

    网上有很多大拿分享的关于Android性能优化的文章,主要是通过各种工具分析,使用合理的技巧优化APP的体验,提升APP的流畅度,但关于内存优化的文章很少有看到.在Android设备内存动不动就上G的 ...

  8. android开发中图片优化步骤

    android开发中图片优化方法 1.图片加载方法,方便用户加载图片 /*** * 加载本地图片 * @param context:主运行函数实例 * @param bitAdress:图片地址,一般 ...

  9. Android RecyclerView使用 及 滑动时加载图片优化方案

    1.控制线程数量 + 数据分页加载2.重写onScrollStateChanged方法 这个我们后面再谈,下面先来看看RecyclerView控件的使用及我们为什么选择使用它 RecyclerView ...

随机推荐

  1. 【Linux 网络编程】TCP/IP四层模型

    应用层.传输层.网络层.链路层 链路层:常用协议 ARP(将物理地址转化为IP地址) RARP(将IP地址转换为物理地址) 网络层(IP层):重要协议ICMP IP IGMP 传输层:重要的协议TCP ...

  2. [转帖]软件的变革与 AOT

    软件的变革与 AOT https://www.colabug.com/851475.html 文章写的很牛B .. 前言 AOT 即 Ahead of Time Compilation,即运行前编,与 ...

  3. Python 进阶篇

    作者:武沛齐 出处:http://www.cnblogs.com/wupeiqi/articles/5246483.html Model 到目前为止,当我们的程序涉及到数据库相关操作时,我们一般都会这 ...

  4. java实现spark常用算子之collect

    import org.apache.spark.SparkConf;import org.apache.spark.api.java.JavaRDD;import org.apache.spark.a ...

  5. redis、rabitmq对比

    redis.rabitmq对比 原文地址 简要介绍 RabbitMQ RabbitMQ是实现AMQP(高级消息队列协议)的消息中间件的一种,最初起源于金融系统,用于在分布式系统中存储转发消息,在易用性 ...

  6. Redis【3】其他部分~

    Java连接VMware的Redis:ping()返回PONG 要可以ping通VMware地址 端口号要正确.默认6379 VMware中的防火墙原因.需添加6379端口号的防火墙: vim /et ...

  7. java线程间的通讯

    主要通过wait()和notify()方法进行线程间的通讯 class Product extends Thread{ String name; float price; boolean flag = ...

  8. Spring-data-jpa n+1问题

    Spring-data-jpa的n+1问题 当我们使用JPA提供给我们的find方法时,如果查询出来的对象关联着另外10个对象,那么JPA将会发送1+10次查询(这个对象本身要查询一次,然后每个关联对 ...

  9. 2019-11-29-WPF-轻量级-MVVM-框架入门-2.1.2

    title author date CreateTime categories WPF 轻量级 MVVM 框架入门 2.1.2 lindexi 2019-11-29 10:16:10 +0800 20 ...

  10. softmax+交叉熵

    1 softmax函数 softmax函数的定义为 $$softmax(x)=\frac{e^{x_i}}{\sum_j e^{x_j}} \tag{1}$$ softmax函数的特点有 函数值在[0 ...