Bitmap內存占用大小的計算
一個BitMap位圖占用的內存=圖片長度*圖片寬度*單位像素占用的字節(jié)數。使用BitmapFactory來decode一張bitmap時，其單位像素占用的字節(jié)數由其參數BitmapFactory.Options的inPreferredConfig變量決定。(注：drawable目錄下有的png圖使用Bitmap.Config.RGB_565和ARGB_8888decode出來的大小一樣，未解)
- ALPHA_8:只有alpha值，沒有RGB值，占一個字節(jié)。計算：size=w*h
- ARGB_4444:一個像素占用2個字節(jié)，alpha(A)值，Red（R）值，Green(G)值，Blue（B）值各占4個bites,共16bites，這種格式的圖片，看起來質量太差，已經不推薦使用。計算：size=wh2
- ARGB_8888:一個像素占用4個字節(jié)，alpha(A)值，Red（R）值，Green(G)值，Blue（B）值各占8個bites,共32bites,即4個字節(jié)。這是一種高質量的圖片格式，電腦上普通采用的格式。android2.3開始的默認格式。計算：size=wh4
- RGB_565:一個像素占用2個字節(jié)，沒有alpha(A)值，即不支持透明和半透明，Red（R）值占5個bites ，Green(G)值占6個bites ，Blue（B）值占5個bites,共16bites,即2個字節(jié)。對于沒有透明和半透明顏色的圖片并且不需要顏色鮮艷的來說，該格式的圖片能夠達到比較的呈現效果，相對于ARGB_8888來說也能減少一半的內存開銷，因此它是一個不錯的選擇。計算：size=wh2
實際開發(fā)中通過代碼獲取bitmap大小
`
@TargetApi(Build.VERSION_CODES.KITKAT)
public static int getBitmapSize(BitmapDrawable value) {
Bitmap bitmap = value.getBitmap();
if (VersionUtils.hasKitKat()) {
return bitmap.getAllocationByteCount();
} if (VersionUtils.hasHoneycombMR1()) {
return bitmap.getByteCount();
}
return bitmap.getRowBytes() * bitmap.getHeight();
}
`
大圖片的有效加載
手機拍出來的圖片分辨率通常比手機屏幕的分辨率高的多，對于Galaxy Nexus手機拍的2592x1936圖片，采用ARGB_8888為2592x1936x4=19M，可能會超出在某些設備上每個應用的內存限制（16m）引發(fā)OOM。
針對超出顯示區(qū)域(通常是imageview或其他view)的大圖片的加載，通常做法如下：
`
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId, int reqWidth, int reqHeight) {
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
`
上面代碼先通過設置Options.inJustDecodeBounds屬性為true，然后執(zhí)行BitmapFactory.decodeXXX()方法，這一步不會真正加載圖片到內存，僅僅是得到圖片尺寸信息，存在Options.outHeight和outWidth和outMimeType中，這樣就得到了圖片在寬和高，再根據目標顯示區(qū)域的大小計算出縮放比例，并賦值給Options.inSampleSize。如inSampleSize == 4，返回一個原來寬高的1/4的圖片，是原來像素數的1/16。比如我們有一張20481536像素的圖片，將inSampleSize的值設置為4，就可以把這張圖片壓縮成512384像素。原本加載這張圖片需要占用13M的內存，壓縮后就只需要占用0.75M了(假設圖片是ARGB_8888類型)。
計算inSampleSize的方法如下：
`
public static int calculateInSampleSize(BitmapFactory.Options options,int reqWidth, int reqHeight) {
// Raw height and width of image
final int height = options.outHeight; final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
// Calculate ratios of height and width to requested height and width,計算出實際寬高和目標寬高的比率
final int heightRatio = Math.round((float) height / (float) reqHeight);
// 選擇寬和高中最小的比率作為inSampleSize的值，這樣可以保證最終圖片的寬和高一定都會大于等于目標的寬和高。
final int widthRatio = Math.round((float) width / (float) reqWidth);
inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
// Anything more than 2x the requested pixels we'll sample down
final float totalPixels = width * height;
// further
final float totalReqPixelsCap = reqWidth * reqHeight * 2;
while (totalPixels / (inSampleSize * inSampleSize) > totalReqPixelsCap) {
inSampleSize++;
}
} return inSampleSize;
}
`
bitmap的回收
Android3.0之前，Bitmap的像素級數據是存儲在native內存上，而Bitmap對象本身是存儲在Java虛擬機堆中。在native內存中的像素數據的釋放是不可預知的，native內存的增加也會算在堆上，從而容易使用程序崩潰。對于一張確定不再使用的bitmap，要調用recycle()方法并把對象設置為null值。所以對于Android3.0之前的手機，通過DDMS觀看Heap信息的時候不顯示native部分分配的內存大小，如圖所示，加載了一張7M多的圖片，但是顯示分配Allocated才2M多。但是native分配的內存大小是算在heap上的，所以當heap大小顯示的不是HeapMaxSize的時候，也有可能OOM。
Android3.0之后，Bitmap像素數據和它對象本身都存儲在Java虛擬機的堆內存中，受GC管理的內存，可以通過GC回收。因此調用recycle()并不會加速bitmap的像素級內存的回收。
為了更有效的利用內存，Android3.0起引入BitmapFactory.Options.inBitmap，如果設置了該屬性，那么當使用了帶有該 Options 參數的 decode 方法在加載內容時，decode 方法會嘗試重用一個已經存在的位圖。這就意味著位圖內存已經被重用了，從而性能得到了改善，并且移除了內存的分配和解除分配。在Android4.4之前，可重用bitmap的條件是寬，高相等，并且計算出來的inSampleSize為1。到了Android4.4，可重用的條件變?yōu)樾耣itmap的大小應該小于或等于被重用bitmap的getAllocationByteCount值。
