bitmap 图片压缩-Android黑科技，图片终极压缩

1、等比压缩,等比压缩是保持原图长宽比例的压缩,只是图片变小,展示的还是原图的所有内容(区别于第二种通过Matrix压缩,可以选取图片的一部分,类似于上传头像时,让你在图上选一块zoom的形式)。等比压缩用的的主要是,通过options缩放比例的设置,来生成缩略图:

2、通过Matrix进行更加灵活的缩放:这种方式主要是通过构建缩放矩阵和方法来实现灵活缩放,宽和高缩放的比例可以不一致,而且通过方法创建出来的是新的位图,这个位图可以是选取原图的一部分,而不是对原图进行整体缩放!类似于上传头像时,让你在原图上扣下来一块的效果,控制非常灵活。

3、无损压缩,无损压缩是说图片大小和清晰度看上去和原图没有什么差别,但是确实size缩小了,这里缩小的原理是牺牲了分辨率等其他直观看不到的东西,看起来和原图一样,但是一放大就立马失真了,不会和原图一样放大很多才会逐渐变得不清晰。无损压缩后的图片像素并不会减少,而Bitmap占用内存的定义就是像素点占的内存,所以以Bitmap的方式加载到内存中时,和压缩前占用的内存是同样大的,原来会oom的图片,质量压缩后同样会oom;但是,质量压缩后将流输出到文件中,文件的size会大幅度减小,所以质量压缩特别适合在 Android 端进行图片上传的时候进行图片压缩,既能保持上传后的清晰度,又能减小size。另外质量压缩不是可以无限缩小的,降低到一定程度,就算把quality设置的再小,size也不会再降低了。另外这种方式最好返回保存压缩后的图片保存的文件路径,而不要直接返回Bitmap,示例就懒得改了。

一张图片处理过程,建议先进行等比压缩或者Matrix压缩后,再进行质量压缩,这样组合使用,不管是生成缩略图还是图片上传,效果都不错

一、支持自定义配置、不失真和批量处理

二、图片上传为什么要压缩

1、图片服务器空间限制,磁盘昂贵

2、网络不稳定,大文件需要断点续传

3、尽可能避免安卓OOM异常

4、后台约定的规则<200KB

5、需要上传原图的应用有医院临床项目、金融银行

三、图片压缩流程

1、递归每张图片

2、设置图片格式

png, jpg,webp

3、质量压缩(format,quality,baos)

由于png是无损压缩,所以设置quality无效(不适合作为缩略图)

采样率压缩

缩小图片分辨率,减少所占用磁盘空间和内存大小

缩放压缩(bitmap, null,rectF,null)

减少图片的像素,降低所占用磁盘空间大小和内存大小,可用于缓存缩略图

JNI调用JPEG库

Android的图片引擎使用的是阉割版的skia引擎,去掉了图片压缩中的哈夫曼算法

4、像素修复

5、返回压缩

6、完成压缩

demo:

参考:

Luban框架

缺点

1、当没有设定压缩路径时,抛异常无闪退

2、源码中,压缩比率固定值60,无法修改

3、压缩配置,参数不太适应真实项目需求

4、不能指定压缩大小,比如100KB以内

android7.0之前,不支持哈夫曼压缩算法,压缩效率不高,因此引入libTurboJpeg库来改善压缩效率。

安卓底层使用Skia作为它的图片处理引擎,通过对libjpeg进行封装,来进行压缩图片。然而在libjpeg进行压缩图片时,有一个参数,叫optimize_coding,默认为FALSE。关于这个参数,官方的解释是,如果设置为TRUE,在压缩过程中,会计算哈夫曼表,这会显著消耗空间和时间。

然而这是对于十几年前的设备而言的,现在的设备来做这个计算完全没有压力。因此,只有在安卓7.0之后,才支持了哈夫曼算法。

开发时,把Java层的Bitmap传递到native层,然后使用 AndroidBitmap API 取出图像所有的argb数据,接着可以舍弃a通道信息,只保留rgb信息到一个新的uint_8数组中,将这个数组作为参数传入jpeg-turbo库中,开启哈夫曼编码,就可以保存到一个新的路径中。

参考链接:

我们来看看2,6,8,9,3权值节点构成哈夫曼树的过程。

初始时候各个节点独立,先将其排序(这里使用优先队列),然后选两个最小节点(抛出)生成一个新的节点,再将其加入优先队列中,此次操作完成后优先队列中有5,6,8,9节点

重复上面操作,这次结束 队列中有11,8,9节点(排序后8,9,11)

如果队列为空,那么返回节点,并且这个节点为整个哈夫曼树根节点root。

否则继续加入队列进行排序。重复上述操作,直到队列为空。

先统计字符出现的次数,然后将这个次数当成权值按照上面介绍的方法构造一棵哈夫曼树,然后树的根不存,往左为0往右为1每个叶子节点得到的二进制数字就是它的编码,这样频率高的字符在上面更短在整个二进制存储中也更节省空间。