android中图片加载到内存中所占空间大小计算:分辨率 height*width*一个像素所占空间大小
解析:decode时指定解码方式为ARGB_8888 代表用8位表示透明度(A),8位表示红色(R),8位表示绿色(G),8位表示蓝色(B),也就是说每个像素占用4*8=32位空间(等于4byte),相对应 RGB_565,一共用16位(2byte)表示一个像素
举个例子,上述属性图片,加载到程序中 分别占用720*1230*4=3542400byte= 3.38MB(ARGB_8888);720*1230*2=1771200byte=1.67MB(RGB_565)
光说不行,咱得上代码上图,没图说个**对不对
代码很简单,bitmap自带getByteCount()方法。
然后两者的清晰度区别,从上面两张图中还是能看出来有些差别,16位解码出的图片略微有点失真。
=================================华丽的分割线=================================
接下来说下bitmap的compress方法。
compress将bitmap压缩输出到流当中,参数一指定输出的文件类型,参数二0-100指定质量,也决定了压缩后的流大小。
参数一指定png 参数二就都为100了,不会再打折压缩了,所以要压缩质量,要指定为jpeg,(第三种webp格式没有接触过)
不知道是不是错觉,指定jpeg情况下,哪怕质量指定100,出来的图片还是感觉跟原图有差距,略微有些失真,所以,需要保持原图效果,还是指定为png格式吧。
compress方法查看源码,直接调用的是c层代码,跟进c层代码 发现是skia库起的作用,skia中继续调用了libjpeg或者libpng库来处理压缩图片。
继续上图举例子:
jpeg 100%情况下 压缩后流大小为299490byte(300k)左右
jpeg 80%情况下 压缩后流大小为56043byte(56k)左右
jpeg 50%情况下 压缩后流大小为35443byte(35k)左右
jpeg 20%情况下 压缩后流大小为24802byte(25k)左右
可以看到,压缩后图片大小的减少还是非常明显的,不过一般情况下 压缩率在80%以上就OK,继续往下,文件减少的幅度大幅下降,失真度却大幅上升。
如果还对图片占用大小不满意,那要从图片分辨率方面入手(文章第一部分),而不是继续降低压缩比率。