最近在面試中野建，被頻繁詢問(wèn)到關(guān)于Android圖片處理的問(wèn)題罗岖，對(duì)于一個(gè)初級(jí)Android 開(kāi)發(fā)者來(lái)說(shuō)，只會(huì)使用诅蝶，而不懂得原理是不行的退个。所以做一下記錄：
圖片緩存
Java中軟引用SoftReference
- Map<String,SoftReference<Bitmap>> imageCache
- 原理：對(duì)一個(gè)需要引用的對(duì)象不進(jìn)行直接引用，而是通過(guò)應(yīng)用一個(gè)特定的SoftReference對(duì)象调炬，然后再由該對(duì)象類去引用實(shí)際的對(duì)象语盈。
- 作用：被SoftReference對(duì)象引用的實(shí)際對(duì)象，在Java運(yùn)行時(shí)缰泡，如果出現(xiàn)內(nèi)存緊張的時(shí)候刀荒，會(huì)被適當(dāng)?shù)幕厥眨尫艃?nèi)存棘钞，軟引用對(duì)于內(nèi)存較少的設(shè)備起到了對(duì)內(nèi)存很好的利用率缠借。
- 我們從Google官方的Caching Bitmaps了解到，該方案的緩存策略已經(jīng)被棄用了宜猜，只適用于Android2.3之前的設(shè)備泼返，因?yàn)閺腁ndroid2.3開(kāi)始，GC更傾向于回收軟姨拥、弱引用绅喉，這使得會(huì)出現(xiàn)以下這種情況，在Listview中使用軟引用緩存異步加載圖片的情況下叫乌，對(duì)Listview進(jìn)行滑動(dòng)時(shí)柴罐，還是會(huì)進(jìn)行網(wǎng)絡(luò)請(qǐng)求，因?yàn)檐浺弥械膱D片被回收憨奸，所以無(wú)法命中緩存中的圖片革屠。
Note: In the past, a popular memory cache implementation was a SoftReference or WeakReference bitmap cache, however this is not recommended. Starting from Android 2.3 (API Level 9) the garbage collector is more aggressive with collecting soft/weak references which makes them fairly ineffective. In addition, prior to Android 3.0 (API Level 11), the backing data of a bitmap was stored in native memory which is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash.
LruCache和LruMemoryCache
- LruMemoryCache<String, Bitmap> mMemoryCache = new LruMemoryCache<String, Bitmap>(0.25f)
- Google推薦使用的方案是：LruCache最少使用算法，當(dāng)內(nèi)存達(dá)到設(shè)定的最大值的時(shí)候排宰，會(huì)將內(nèi)存中最近最少使用的對(duì)象進(jìn)行移除似芝，避免OOM。
- LruMemoryCache比LruCache多增加了一個(gè)緩存超期的處理额各。
LruCache原理
1.LruCache中LRU算法的實(shí)現(xiàn)是通過(guò)一個(gè)LinkedHashMap來(lái)實(shí)現(xiàn)的国觉。LinkedHashMap繼承于HashMap，使用一個(gè)雙向鏈表來(lái)存儲(chǔ)Map中的Enty順序關(guān)系虾啦。
2.當(dāng)我們執(zhí)行Get方法從LruCache中取出對(duì)象時(shí)麻诀，將該對(duì)象移動(dòng)到鏈表的末端傲醉。
3.當(dāng)我們執(zhí)行Put方法從LruCache中增加對(duì)象時(shí)蝇闭，插入對(duì)象并將對(duì)象移動(dòng)到鏈表的末端。
4.當(dāng)設(shè)備內(nèi)存達(dá)到設(shè)定的最大值時(shí)硬毕，將鏈表頭部的對(duì)象呻引，也就是最近最少使用的對(duì)象（最近最多使用的對(duì)象都被移動(dòng)到鏈表的末端）移除。
圖片失真
.9.png圖片
- 對(duì)于本地圖片吐咳，我們采用.9圖片逻悠，是Android提供的一種特殊的圖片技術(shù)元践，將圖片橫向和縱向同時(shí)進(jìn)行拉伸，以實(shí)現(xiàn)在多分辨率下的不失真的效果童谒。
Options.inJustDecodeBounds
- 對(duì)于網(wǎng)絡(luò)中的圖片单旁，我們可以采用壓縮圖片的方式。我們根據(jù)控件的大屑⒁痢（顯示到屏幕上的大邢蠡搿）來(lái)縮放圖片的inSamplesize（ex：顯示圖片控件大小為12896像素，那么就不需要用到1024768像素）
- 注意：由于解碼會(huì)占用內(nèi)存琅豆，通過(guò)設(shè)置options.inJustDecodeBounds為true愉豺，在進(jìn)行解碼就不會(huì)申請(qǐng)內(nèi)存創(chuàng)建Bitmap，會(huì)返回一個(gè)空的Bitmap茫因，但是可以從中獲取到圖片的屬性蚪拦。
計(jì)算壓縮圖片的比例
int calculateInSampleSize(BitmapFactory.Options options,int reqWidth,int reqHeight){
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if(height > reqHeight || width > reqWidth){
final int heightRatio = Math.round((float)height/(float)reqHeigth);
final int widhtRatio = Math.round((float)width/(float)reqWidth);
inSampleSize = heightRatio < widthRadio ? heightRatio : widthRatio;
}
return inSampleSize;
}
對(duì)圖片進(jìn)行壓縮處理
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(filePath,options);
options.inSampleSize = calculateInSampleSize(options,480,800);
optons.inJustDecodeBounds = false;
return BtimapFactory.decodeFile(filePath,options);
