Android-Bitmap

参考:https://www.jianshu.com/p/3c5ac5fdb62a

作为开发者，我们经常和Bitmap打交道，比如：imageView.setImageBitmap( bitmap)，但Bitmap到底是个什么，今天来深究一下。

Bitmap简介

位图（Bitmap）是使用像素阵列(Pixel-array/Dot-matrix点阵)来表示的图像，包括像素以及长、宽、颜色等描述信息。长宽和像素位数是用来描述图片的，可以通过这些信息计算出图片的像素占用内存的大小。扩展名可以是.bmp或者.dib。位图是Windows标准格式图形文件，它将图像定义为由点（像素）组成，每个点可以由多种色彩表示，包括2、4、8、16、24和32位色彩。位图文件是非压缩格式的，需要占用较大存储空间。

1.Bitmap占内存大小的计算方式

我们先来看一张图片，抛几个问题：

1.1.问题一：第一张图片显示薛之涛.jpg的大小是3.50kb,为什么占用空间不是3.50kb而是4.00kb?

答：我们需要先搞清楚一个概念：我们在电脑上看到的 png 格式或者 jpg 格式的图片，png(jpg) 只是这张图片的容器，它们是经过相对应的压缩算法将原图每个像素点信息转换用另一种数据格式表示，以此达到压缩目的，减少图片文件大小。而当我们通过代码，将这张图片加载进内存时，会先解析图片文件本身的数据格式，然后还原为位图，也就是 Bitmap 对象，Bitmap 的大小取决于像素点的数据格式以及分辨率两个因素。所以，一张 png 或者 jpg 格式的图片大小，跟这张图片加载进内存所占用的大小完全是两回事。但图片在内存中的大小和Bitmap大小相同

1.2.问题二： 如何计算图片在内存中的大小?

在计算内存大小之前我们先普及相关知识：
在安卓系统中默认bitmap图片一般有32位(ARGB_8888)，16位(ARGB_4444,ARGB_565)，8位(ALPHA_8)，我们来说一下其含义：
ARGB_8888其含义是：ARGB分别代表的是透明度（alpha）,红色（red）,绿色(green),蓝色(blue),8888表示A=8,R=8,G=8,B=8即每个值分别用8bit来记录并进行存储的，计算如下：
单位像素ARGB_8888占位计算： 8+8+8+8 =32bit ，其中 bit是最小单位，1 byte = 8bit,也就是说ARAG每单位像素占4byte。
ARGB_4444其含义是：ARGB分别代表的是透明度,红色,绿色,蓝色,4444表示每个值分别用4bit来记录并进行存储的，计算如下：
单位像素ARGB_4444占位计算：4+4+4+4 =16bit ，也就是说ARAG_4444每单位像素占内存2byte。
RGB_565含义：RGB分别代表的是红色,绿色,蓝色,565表示R=5，G=6,B=5，所以其每单位像素的计算公式为：
单位像素RGB_565占位计算：5+6+5=16bit,等于2byte内存
ALPHA_8含义：ALPHA代表该像素只保存透明度，所以其每单位像素的计算公式为：
单位像素ALPHA_8占位计算为8bit等于1byte内存

Android中图片有四种颜色格式

我们在对图片的8位，16位，32位做一个说明，讲一下区别（只是部分区别）：

• 拿8位来说，它表示2的8次方，意味着有256种灰度或彩色组合，同样16位就是2的16次方，意味有65536种可能的颜色组合等。其他位类同。
• 16位图像相比8位图像有较好的色彩过渡，更加细腻，携带的色彩信息可以更加丰富。其他位类同。
• 如果一个8位图像有10MB大小，它变成16时，大小就要翻一翻变成20MB。其他位类同。

在实际应用中而言,建议使用ARGB_8888以及RGB_565。 如果你不需要透明度,选择RGB_565,可以减少一半的内存占用.

好了先在说回我们的图片内存计算，网上通用的计算方式是：内存大小公式=分辨率 * 每个像素点的大小。那么我们来计算一下一张像素为：1920px高x1080px宽的32的图片占用内存的计算方式：

先说一下转化关系：
1 Byte = 8 Bits（即 1B=8b）
1 KB = 1024 Bytes
1 MB = 1024 KB
1 GB = 1024 MB1920x1080的32位图片占内存计算：1920x1080x32=66355200bit=8294400Byte=8100kb≈7.91M

2.Bitmap占内存大小的计算实际分析

上面已经给出了计算方式，为什么还要实际分析呢？原因在于：上面的计算方式并不准确，我们要考虑不同设备以及同一设备不同条件：

2.1.1同设备或不同设备不同条件又分好多种：

• 不同drawable文件
• 磁盘或res中
• 图片格式由png转为jpg

那我们就从同设备不同Drawable入手测试,看看图片放在drawable-xdip和drawable-xxxdip下，其他条件一致，相关代码如下：

ImageView mImageView;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);mImageView=findViewById(R.id.imageView);BitmapFactory.Options options = new BitmapFactory.Options();Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.xzt, options);mImageView.setImageBitmap(bitmap);if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {Log.e(TAG, "API19获取Bitmap的内存的大小:"+bitmap.getAllocationByteCount());}if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB_MR1) {Log.e(TAG, "API12获取Bitmap的内存的大小:"+bitmap.getByteCount());}Log.e(TAG, "获取Bitmap的宽为:"+bitmap.getWidth()+"获取Bitmap的高为:"+bitmap.getHeight() );Log.e(TAG, "获取图片所在的Drawable分辨率为:"+options.inDensity+"获取屏幕的像素密度为:"+options.inTargetDensity );Log.e(TAG, "获取图片所在控件的宽为:"+mImageView.getWidth()+"获取图片所在控件的高为:"+mImageView.getHeight());}

将图片放在drawable-xdip结果:

将图片放在drawable-xxxdip结果:

可以看到将同一图片放在不同分辨率的Drawable文件夹下所占用的内存是不同的，Drawable分辨率越高所占内存越小。为什么会这样呢？
原因是:系统在加载 res 目录下的资源图片时，会根据图片存放的不同目录做一次分辨率的转换，而转换的规则是：
新图的高度 = 原图高度 * (设备的 dpi / 目录对应的 dpi )
新图的宽度 = 原图宽度 * (设备的 dpi / 目录对应的 dpi )
录名称与 dpi 的对应关系如下，drawable 没带后缀对应 160 dpi：

也就是位于 res 内的不同资源目录中的图片，当加载进内存时，会先经过一次分辨率的转换，然后再计算大小，转换的影响因素是设备的 dpi 和不同的资源目录
其实影响内存的还有其他因素，我们这里就不测试了，直接总结一下：
(1)：同一图片，在同一台设备中，如果图片放在 res 内的不同资源目录下，那么图片占用的内存空间是会不一样的，通常是drawable文件夹分辨率越高，内存越小
(2):同一图片，放在 res 内相同的资源目录下，但在不同 dpi 的设备中，图片占用的内存空间也是会不一样的。通常是设备dpi越高内存越大。
(3):同等条件下，图片所占内存与控件大小(Imageview)无关。
(4):同等条件下，图片所占内存与图片格式无关，即xzt.jpg和xzt.png的同等条件下所占内存相同。

3.图片的优化

知道了Bitmap的计算方式，那么自然而然要考虑优化了。从上面的分析可以得出，如果单从图片本身考虑，优化的方向就两个：

• 降低分辨率
• 减少图片单位像素点大小

3.1 降低分辨率

降低分辨率也就是我们前面说到的ARGB_8888设置为ARGB_4444或者ARGB_565.但前者ARGB_4444但会大大降低图片质量，不推荐。而后者不支持透明度。

3.2减少图片像素点大小

降低分辨率不靠谱那就只好试试减少图片的像素点大小了，也就是图片的尺寸压缩。
我们都知道在Android3.0以前Bitmap是存放在内存中的，我们需要回收native层和Java层的内存，在Android3.0以后Bitmap是存放在堆中的，我们只要回收堆内存即可，官方建议我们3.0以后使用recycle（）方法进行回收，该方法可以不主动调用，因为垃圾回收器会自动收集不可用的Bitmap对象进行回收。
emmm.................算了，不想说了。
因为之前写过文章感兴趣的参考：https://www.jianshu.com/p/4b0ba08bfb58
告辞！