壹般來說壹個點被精確的認定為1/72英寸,在WPF中,采用的設備無關單位即1/96英寸
所以程序中獲取的圖片大小比真實圖片的大小要大壹點,獲取到圖片大小後進行相應的轉換即可獲得圖片原來的尺寸如:height=height*72/96
bmp全屏截圖大小800*480。在任意位置顯示任意大小bmp圖片頭文件,普通全屏800*480顯示bmp,容易分析。BMP(全稱Bitmap)是Windows操作系統中的標準圖像文件格式,可以分成兩類:設備有向量相關位圖(DDB)和設備無向量相關位圖(DIB),使用非常廣。
Android內存優化五：Bitmap優化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以後就限制了匿名***享內存的使用。
在SDK11->18之間,重用的bitmap大小必須是壹致的,例如給inBitmap賦值的圖片大小為100-100,那麽新申請的bitmap必須也為100-100才能夠被重用。從SDK19開始,新申請的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