Bitmap四种属性

我们知道Android系统分配给每个应用程序的内存是有限的，Bitmap作为消耗内存大户，我们对Bitmap的管理稍有不当就可能引发OutOfMemoryError，而Bitmap对象在不同的Android版本中存在一些差异，今天就给大家介绍下这些差异，并提供一些在使用Bitmap的需要注意的地方。

在Android2.3.3(API 10)及之前的版本中，Bitmap对象与其像素数据是分开存储的，Bitmap对象存储在Dalvik heap中，而Bitmap对象的像素数据则存储在Native Memory（本地内存）中或者说Derict Memory（直接内存）中，这使得存储在Native Memory中的像素数据的释放是不可预知的，我们可以调用recycle()方法来对Native Memory中的像素数据进行释放，前提是你可以清楚的确定Bitmap已不再使用了，如果你调用了Bitmap对象recycle()之后再将Bitmap绘制出来，就会出现Canvas: trying to use a recycled bitmap错误，而在Android3.0(API 11)之后，Bitmap的像素数据和Bitmap对象一起存储在Dalvik heap中，所以我们不用手动调用recycle()来释放Bitmap对象，内存的释放都交给垃圾回收器来做，也许你会问，为什么我在显示Bitmap对象的时候还是会出现OutOfMemoryError呢？

在说这个问题之前我顺便提一下，在Android2.2(API 8)之前，使用的是Serial垃圾收集器，从名字可以看出这是一个单线程的收集器，这里的”单线程的意思并不仅仅是使用一个CPU或者一条收集线程去收集垃圾，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，Android2.3之后，这种收集器就被代替了，使用的是并发的垃圾收集器，这意味着我们的垃圾收集线程和我们的工作线程互不影响。

简单的了解垃圾收集器之后，我们对上面的问题举一个简单的例子，假如系统启动了垃圾回收线程去收集垃圾，而此时我们一下子产生大量的Bitmap对象，此时是有可能会产生OutOfMemoryError，因为垃圾回收器首先要判断某个对象是否还存活(JAVA语言判断对象是否存活使用的是根搜索算法 GC Root Tracing)，然后利用垃圾回收算法来对垃圾进行回收，不同的垃圾回收器具有不同的回收算法，这些都是需要时间的， 发生OutOfMemoryError的时候，我们要明确到底是因为内存泄露(Memory Leak)引发的还是内存溢出(Memory overflow)引发的，如果是内存泄露我们需要利用工具(比如MAT)查明内存泄露的代码并进行改正，如果不存在泄露，换句话来说就是内存中的对象确实还必须活着，那我们可以看看是否可以通过某种途径，减少对象对内存的消耗，比如我们在使用Bitmap的时候，应该根据View的大小利用BitmapFactory.Options计算合适的inSimpleSize来对Bitmap进行相对应的裁剪，以减少Bitmap对内存的使用，如果上面都做好了还是存在OutOfMemoryError(一般这种情况很少发生)的话，那我们只能调大Dalvik heap的大小了，在Android 3.1以及更高的版本中，我们可以在AndroidManifest.xml的application标签中增加一个值等于“true”的android:largeHeap属性来通知Dalvik虚拟机应用程序需要使用较大的Java Heap，但是我们也不鼓励这么做。

Bitmap:

(1)     public Bitmap (int width,int height,int stride,     PixelFormat format,IntPtr scan0)

用指定的大小、像素格式和像素数据初始化 Bitmap 类的新实例。

(2)     LockBits():,就是把图像的内存区域根据格式锁定，拿到那块内存的首地址。这样就可以直接改写这段内存了。这个方法的设计是挺好，可惜都是C++作为源泉来的，.NET Framework里面根本就不推荐用指针，需要用Marshal.Copy把内容Copy到一个byte数组里面，然后处理完了再Copy回去。

(3)     UnlockBits():从系统内存解锁此 Bitmap。

 

BitmapData:位图图像的属性

(1)   Height获取或设置 Bitmap 对象的像素高度。有时也称作扫描行数。

(2)   PixelFormat: 获取或设置返回此 BitmapData 对象的 Bitmap 对象中像素信息的格式。

(3)   Reserved: 保留。不要使用。

(4)   Scan0: 获取或设置位图中第一个像素数据的地址。它也可以看成是位图中的第一个扫描行。

(5)   Stride: 获取或设置 Bitmap 对象的跨距宽度（也称为扫描宽度）。

Stride:跨距是单行像素（一个扫描行）的宽度，舍入为一个 4 字节的边界。跨距总是大于或等于实际像素宽度。如果跨距为正，则位图自顶向下。如果跨距为负，则位图颠倒。Stride是指图像每一行需要占用的字节数。根据BMP格式的标准，Stride一定要是4的倍数。据个例子，一幅1024*768的24bppRgb的图像，每行有效的像素信息应该是1024*3 = 3072。因为已经是4的倍数，所以Stride就是3072。那么如果这幅图像是35*30，那么一行的有效像素信息是105，但是105不是4的倍数，所以填充空字节，Stride应该是108。这一行计算出来的offset就是3。一要注意必须是4的倍数，二单位是字节！

(6)   Width: 获取或设置 Bitmap 对象的像素宽度。这也可以看作是一个扫描行中的像素数。

 

PixelFormat：

(1)     Format24bppRgb,也就是24位色。在这种格式下3个字节表示一种颜色，也就是我们通常所知道的R,G,B，所以每个字节表示颜色的一个分量。

(2)     Format32bppArgb,除了RGB，在图像中还存在一个通道，叫做A。这个A就是用来描述当前像素是透明，半透明，还是全透明的分量。这个通道是2个叫Catmull和Smith在上世纪70年代初发明的。通过这个分量，我们可以进行alpha混合的一些计算。从而使表面的图像和背景图像混合，从而造成透明半透明的效果。在这种格式下A作为一个byte，取值可以从0到255，那么0表示图像完全透明，则完全不可见，255则表示图像完全不透明。每个像素都可以实现这种透明或者半透明的效果。更详细解释可以参考http://en.wikipedia.org/wiki/Alpha_compositing，或者去买本数字图像处理的书回来看。

(3)     Format32bppPArgb，这叫做premultiplied alpha，就是说在RGB分量里面，alpha分量的数据已经被预先乘进去了。比如说，一个半透明的红色点，在ARGB下，矢量是(255,0,0,128),而在PARGB下就变成了(128,0,0,128)。这是为了不要每次都做乘法。

(4)     Bitmap保存成为一个文件，那么必须用png格式，才能够保存alpha通道的信息。如果你存为JPG/BMP/GIF,那么alpha通道的信息将会被丢失。如果存为BMP,那么文件格式将变成Format32bppRgb，其中1个字节不再使用；如果保存为JPEG，那么是Format24bppRgb；存为GIF，格式将变成Format8bppIndexed。根据标准，BMP/JPG本来就不支持透明通道，所以没有可能保留透明信息。GIF倒是支持透明，但是GIF中颜色的信息都是索引，所以Alpha的解释对GIF完全没有效果，

 

BitmapInfoHeader:

biHeight：说明图象的高度，以象素为单位。

    如果该值是一个正数，说明Btimap是Bottom up DIB，起始点是左下角，也就是从图像的最下面一行扫描，位图数组中得到的第一行数据实际是图形的最下面的一行。图像是倒向的；

    如果该值是一个负数，则说明图像是TopDown DIB，起始点是左上角，图像从最上面一行扫描，图像正向的。

   大多数的BMP文件都是倒向的位图，也就是时，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）