轉自:http://zhiweiofli.iteye.com/blog/905066
首先解析一下基本的知識:
位圖模式,bitmap顏色位數是1位
灰度模式,bitmap顏色位數是8位,和256色一樣
RGB模式,bitmap顏色位數是24位 在RGB模式下,一個像素對應的是紅、綠、藍三個字節
CMYK模式,bitmap顏色位數是32位 在CMYK模式下,一個像素對應的是青、品、黃、黑四個字節
圖像文件的字節數(Byte) = 圖像分辨率*顏色深度/8(bit/8)
例如:一幅640*480圖像分辨率、RGB色一般爲24位真彩色,圖像未經壓縮的數據容量爲:640X480X24/8=921600字節=900KB(1KB=l千字節=1024字節)。
注:一個圖像文件佔的磁盤空間大小還和磁盤的文件格式有關。如:NTFS最小單位爲4KB 所以圖像文件大小肯定是4KB的倍數。但是有圖圖片壓縮算法的存在,圖片文件在保存時,體積要比在內存的大小小得多,如640x480的圖片文件大小一般只在200K~300K。這也是爲什麼,加載幾MB的圖片文件,會導致JVM內存溢出,導致OutofMemoryException的原因。
由上面的公式,我們可以得出,加載的圖片所佔的內存大小,取決於其分辨率和顏色數。
我們再來看看Google官方的介紹:
這個已經非常的明白了,我們VM的app進程所獲得的內存只有區區的16MB,普普通通的5MP攝像頭拍出來的圖片,直接加載,將佔用接近19MB的內存。可見,不進行壓縮,內存將會直接溢出。
再瞭解一下,android讀取解析圖片的方式,基本與Java的方式類型,通過文件輸入流,然後進行解碼,再轉成圖片格式;
當然google的android也爲我們封裝好了若干方法,來方便快捷地完成這項工作,如ImageView的setImageBitmap,setImageResource,BitmapFactory的decodeResource等,但是儘量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設置一張大圖,因爲這些函數在完成decode後,最終都是通過java層的createBitmap來完成的,需要消耗更多內存;
因此,改用先通過BitmapFactory.decodeStream方法,創建出一個bitmap,再將其設爲ImageView的source,加載顯示。decodeStream最大的祕密在於其直接調用JNI>>nativeDecodeAsset()來完成decode,無需再使用java層的createBitmap,從而節省了java層的空間。