bitmap设置图片大小-Android内存优化五：Bitmap优化

一般来说一个点被精确的认定为1/72英寸,在WPF中,采用的设备无关单位即1/96英寸

所以程序中获取的图片大小 比真实图片的大小要大一点, 获取到图片大小后进行相应的转换即可获得图片原来的尺寸 如: height=height*72/96

800*480。在任意位置显示任意大小bmp图片头文件,普通全屏800*480显示bmp,容易分析。BMP(全称Bitmap)是Windows操作系统中的标准图像文件格式,可以分成两类:设备有向量相关位图(DDB)和设备无向量相关位图(DIB),使用非常广。

Android内存优化一:java垃圾回收机制

Android内存优化二:内存泄漏

Android内存优化三:内存泄漏检测与监控

Android内存优化四:OOM

Android内存优化五:Bitmap优化

压缩比:scale = (flaot) targetDensity / density

targetDensity : 设备屏幕像素密度dpi

density: 图片对应的文件夹的像素密度dpi

1)、同一张图片放在不同的资源目录下,其分辨率会有变化。

2)、Bitmap的分辨率越高,其解析后的宽高越小,甚至小于原有的图片(及缩放),从而内存也响应的减少。

3)、图片不放置任何资源目录时,其使用默认分辨率mdpi:160。

4)、资源目录分辨率和屏幕分辨率一致时,图片尺寸不会缩放。

Bitmap放在资源目录中的计算方式为:

主要通过编码、采样、复用、匿名共享区进行优化

由于ARGB_4444的画质惨不忍睹,一般假如对图片没有透明度要求的话,可以改成RGB_565,相比ARGB_8888将节省一半的内存开销

其中,A代表透明度;R代表红色;G代表绿色;B代表蓝色。

ALPHA_8 表示8位Alpha位图,即A=8,一个像素点占用1个字节,它没有颜色,只有透明度。

ARGB_4444 表示16位ARGB位图,即A=4,R=4,G=4,B=4,一个像素点占4+4+4+4=16位,2个字节。

ARGB_8888 表示32位ARGB位图,即A=8,R=8,G=8,B=8,一个像素点占8+8+8+8=32位,4个字节。

RGB_565 表示16位RGB位图,即R=5,G=6,B=5,它没有透明度,一个像素点占5+6+5=16位,2个字节。

bitmap的占用内存,是以bitmap的宽高和每个像素占用的字节数决定的。

根据BitmapFactory 的采样率进行压缩 设置采样率,不能小于1 假如是2 则宽为之前的1/2,高为之前的1/2,一共缩小1/4 以此类推

图片复用指的是inBitmap这个属性。

不使用这个属性,你加载三张图片,系统会给你分配三份内存空间,用于分别储存这三张图片

如果用了inBitmap这个属性,加载三张图片,这三张图片会指向同一块内存,而不用开辟三块内存空间。

inBitmap的限制:

1、3.0-4.3

复用的图片大小必须相同

编码必须相同

2、4.4以上

复用的空间大于等于即可

编码不必相同

3、不支持WebP

4、图片复用,这个属性必须设置为true;

= true;

Android 系统为了进程间共享数据开辟的一块内存区域,由于这块区域不受应用的Head的大小限制,相当于可以绕开oom,FaceBook的Fresco首次应用到实际中。

限制:5.0以后就限制了匿名共享内存的使用。

在SDK 11 -> 18之间,重用的bitmap大小必须是一致的,例如给inBitmap赋值的图片大小为100-100,那么新申请的bitmap必须也为100-100才能够被重用。从SDK 19开始,新申请的bitmap大小必须小于或者等于已经赋值过的bitmap大小。 新申请的bitmap与旧的bitmap必须有相同的解码格式,例如大家都是8888的,如果前面的bitmap是8888,那么就不能支持4444与565格式的bitmap了。 我们可以创建一个包含多种典型可重用bitmap的对象池,这样后续的bitmap创建都能够找到合适的“模板”去进行重用。

8.0Bitmap的像素数据存储在Native,为什么又改为Native存储呢?

因为8.0共享了整个系统的内存,测试8.0手机如果一直创建Bitmap,如果手机内存有1G,那么你的应用加载1G也不会oom。

可以利用LRU开管理Bitmap,给他设置内存最大值,及时回收。

BitmapRegionDecoder