android 加載大圖片時(shí)報(bào)OOM的解決方案
在Android中：
1.一個(gè)進(jìn)程的內(nèi)存可以由2個(gè)部門組成：java 施用內(nèi)存 ，C 施用內(nèi)存 ，這兩個(gè)內(nèi)存的和必需小于16M，不然就會(huì)出現(xiàn)各人熟悉的OOM，這個(gè)就是熬頭種OOM的情況。
2.一朝內(nèi)存分配給Java后，以后這塊內(nèi)存縱然開釋后，也只能給Java的施用，這個(gè)估計(jì)跟java虛擬機(jī)里把內(nèi)存分成好幾塊進(jìn)行緩存的原因有關(guān)，反正C就別想用到這塊的內(nèi)存了，所以要是Java突然占用了一個(gè)大塊內(nèi)存，縱然很快開釋了：
C能施用的內(nèi)存 = 16M - Java某一瞬間占在校大學(xué)生創(chuàng)業(yè)點(diǎn)子用的最大內(nèi)存。
而Bitmap的生成是路程經(jīng)過過程malloc進(jìn)行內(nèi)存分配的，占用的是C的內(nèi)存。
?
Code :
/**
?*?@author?frankiewei.?工具類.
?*/
public?class?ImageCacheUtil?{
public?static?final?int?UNCONSTRAINED?=?-1;
/*
?*?獲得設(shè)置信息
?*/
public?static?Options?getOptions(String?path)?{
Options?options?=?new?Options();
options.inJustDecodeBounds?=?true;//?只描邊，不讀取數(shù)據(jù)
BitmapFactory.decodeFile(path,?options);
return?options;
}
/**
?*?獲得圖像
?*?
?*?@param?path
?*?@param?options
?*?@return
?*?@throws?FileNotFoundException
?*/
public?static?Bitmap?getBitmapByPath(String?path,?Options?options,
int?screenWidth,?int?screenHeight)?throws?FileNotFoundException?{
File?file?=?new?File(path);
if?(!file.exists())?{
throw?new?FileNotFoundException();
}
FileInputStream?in?=?null;
in?=?new?FileInputStream(file);
if?(options?!=?null)?{
Rect?r?=?getScreenRegion(screenWidth,?screenHeight);
int?w?=?r.width();
int?h?=?r.height();
int?maxSize?=?w?>?h???w?:?h;
int?inSimpleSize?=?computeSampleSize(options,?maxSize,?w?*?h);
options.inSampleSize?=?inSimpleSize;?//?設(shè)置縮放比例
options.inJustDecodeBounds?=?false;
}
Bitmap?b?=?BitmapFactory.decodeStream(in,?null,?options);
try?{
in.close();
}?catch?(IOException?e)?{
e.printStackTrace();
}
return?b;
}
private?static?Rect?getScreenRegion(int?width,?int?height)?{
return?new?Rect(0,?0,?width,?height);
}
/**
?*?獲取需要進(jìn)行縮放的比例，即options.inSampleSize
?*?
?*?@param?options
?*?@param?minSideLength
?*?@param?maxNumOfPixels
?*?@return
?*/
public?static?int?computeSampleSize(BitmapFactory.Options?options,
int?minSideLength,?int?maxNumOfPixels)?{
int?initialSize?=?computeInitialSampleSize(options,?minSideLength,
maxNumOfPixels);
int?roundedSize;
if?(initialSize?<=?8)?{
roundedSize?=?1;
while?(roundedSize?<?initialSize)?{
roundedSize?<<=?1;
}
}?else?{
roundedSize?=?(initialSize?+?7)?/?8?*?8;
}
return?roundedSize;
}
private?static?int?computeInitialSampleSize(BitmapFactory.Options?options,
int?minSideLength,?int?maxNumOfPixels)?{
double?w?=?options.outWidth;
double?h?=?options.outHeight;
int?lowerBound?=?(maxNumOfPixels?==?UNCONSTRAINED)???1?:?(int)?Math
.ceil(Math.sqrt(w?*?h?/?maxNumOfPixels));
int?upperBound?=?(minSideLength?==?UNCONSTRAINED)???128?:?(int)?Math
.min(Math.floor(w?/?minSideLength),
Math.floor(h?/?minSideLength));
if?(upperBound?<?lowerBound)?{
//?return?the?larger?one?when?there?is?no?overlapping?zone.
return?lowerBound;
}
if?((maxNumOfPixels?==?UNCONSTRAINED)
&&?(minSideLength?==?UNCONSTRAINED))?{
return?1;
}?else?if?(minSideLength?==?UNCONSTRAINED)?{
return?lowerBound;
}?else?{
return?upperBound;
}
}
}工具類的使用：
String?path?=?"/sdcard/a01.jpg";
Bitmap?bitmap?=?null;
try?{
bitmap?=?ImageCacheUtil.getBitmapByPath(path,
ImageCacheUtil.getOptions(path),?mScreenWidth,
mScreenHeight);
}?catch?(FileNotFoundException?e)?{
e.printStackTrace();
}?
?
使用圖片緩存技術(shù)
在你應(yīng)用程序的UI界面加載一張圖片是一件很簡(jiǎn)單的事情，但是當(dāng)你需要在界面上加載一大堆圖片的時(shí)候，情況就變得復(fù)雜起來。在很多情況下，（比如使用ListView, GridView 或者 ViewPager 這樣的組件），屏幕上顯示的圖片可以通過滑動(dòng)屏幕等事件不斷地增加，最終導(dǎo)致OOM。
為了保證內(nèi)存的使用始終維持在一個(gè)合理的范圍，通常會(huì)把被移除屏幕的圖片進(jìn)行回收處理。此時(shí)垃圾回收器也會(huì)認(rèn)為你不再持有這些圖片的引用，從而對(duì)這些圖片進(jìn)行GC操作。用這種思路來解決問題是非常好的，可是為了能讓程序快速運(yùn)行，在界面上迅速地加載圖片，你又必須要考慮到某些圖片被回收之后，用戶又將它重新滑入屏幕這種情況。這時(shí)重新去加載一遍剛剛加載過的圖片無疑是性能的瓶頸，你需要想辦法去避免這個(gè)情況的發(fā)生。
這個(gè)時(shí)候，使用內(nèi)存緩存技術(shù)可以很好的解決這個(gè)問題，它可以讓組件快速地重新加載和處理圖片。下面我們就來看一看如何使用內(nèi)存緩存技術(shù)來對(duì)圖片進(jìn)行緩存，從而讓你的應(yīng)用程序在加載很多圖片的時(shí)候可以提高響應(yīng)速度和流暢性。
內(nèi)存緩存技術(shù)對(duì)那些大量占用應(yīng)用程序?qū)氋F內(nèi)存的圖片提供了快速訪問的方法。其中最核心的類是LruCache (此類在android-support-v4的包中提供) 。這個(gè)類非常適合用來緩存圖片，它的主要算法原理是把最近使用的對(duì)象用強(qiáng)引用存儲(chǔ)在 LinkedHashMap 中，并且把最近最少使用的對(duì)象在緩存值達(dá)到預(yù)設(shè)定值之前從內(nèi)存中移除。
在過去，我們經(jīng)常會(huì)使用一種非常流行的內(nèi)存緩存技術(shù)的實(shí)現(xiàn)，即軟引用或弱引用 (SoftReference or WeakReference)。但是現(xiàn)在已經(jīng)不再推薦使用這種方式了，因?yàn)閺?Android 2.3 (API Level 9)開始，垃圾回收器會(huì)更傾向于回收持有軟引用或弱引用的對(duì)象，這讓軟引用和弱引用變得不再可靠。另外，Android 3.0 (API Level 11)中，圖片的數(shù)據(jù)會(huì)存儲(chǔ)在本地的內(nèi)存當(dāng)中，因而無法用一種可預(yù)見的方式將其釋放，這就有潛在的風(fēng)險(xiǎn)造成應(yīng)用程序的內(nèi)存溢出并崩潰。
為了能夠選擇一個(gè)合適的緩存大小給LruCache, 有以下多個(gè)因素應(yīng)該放入考慮范圍內(nèi)，例如：
你的設(shè)備可以為每個(gè)應(yīng)用程序分配多大的內(nèi)存？設(shè)備屏幕上一次最多能顯示多少張圖片？有多少圖片需要進(jìn)行預(yù)加載，因?yàn)橛锌赡芎芸煲矔?huì)顯示在屏幕上？你的設(shè)備的屏幕大小和分辨率分別是多少？一個(gè)超高分辨率的設(shè)備（例如 Galaxy Nexus) 比起一個(gè)較低分辨率的設(shè)備（例如 Nexus S），在持有相同數(shù)量圖片的時(shí)候，需要更大的緩存空間。圖片的尺寸和大小，還有每張圖片會(huì)占據(jù)多少內(nèi)存空間。圖片被訪問的頻率有多高？會(huì)不會(huì)有一些圖片的訪問頻率比其它圖片要高？如果有的話，你也許應(yīng)該讓一些圖片常駐在內(nèi)存當(dāng)中，或者使用多個(gè)LruCache 對(duì)象來區(qū)分不同組的圖片。你能維持好數(shù)量和質(zhì)量之間的平衡嗎？有些時(shí)候，存儲(chǔ)多個(gè)低像素的圖片，而在后臺(tái)去開線程加載高像素的圖片會(huì)更加的有效。
下載文檔
