在Android中：

　　1.一個進(jìn)程的內(nèi)存可以由2個部門組成：java 施用內(nèi)存 ，C 施用內(nèi)存 ，這兩個內(nèi)存的和必需小于16M，不然就會出現(xiàn)各人熟悉的OOM，這個就是熬頭種OOM的情況。

　　2.一朝內(nèi)存分配給Java后，以后這塊內(nèi)存縱然開釋后，也只能給Java的施用，這個估計跟java虛擬機(jī)里把內(nèi)存分成好幾塊進(jìn)行緩存的原因有關(guān)，反正C就別想用到這塊的內(nèi)存了，所以要是Java突然占用了一個大塊內(nèi)存，縱然很快開釋了：

　　C能施用的內(nèi)存 = 16M - Java某一瞬間占在校大學(xué)生創(chuàng)業(yè)點子用的最大內(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界面加載一張圖片是一件很簡單的事情，但是當(dāng)你需要在界面上加載一大堆圖片的時候，情況就變得復(fù)雜起來。在很多情況下，（比如使用ListView, GridView 或者 ViewPager 這樣的組件），屏幕上顯示的圖片可以通過滑動屏幕等事件不斷地增加，最終導(dǎo)致OOM。

為了保證內(nèi)存的使用始終維持在一個合理的范圍，通常會把被移除屏幕的圖片進(jìn)行回收處理。此時垃圾回收器也會認(rèn)為你不再持有這些圖片的引用，從而對這些圖片進(jìn)行GC操作。用這種思路來解決問題是非常好的，可是為了能讓程序快速運行，在界面上迅速地加載圖片，你又必須要考慮到某些圖片被回收之后，用戶又將它重新滑入屏幕這種情況。這時重新去加載一遍剛剛加載過的圖片無疑是性能的瓶頸，你需要想辦法去避免這個情況的發(fā)生。

這個時候，使用內(nèi)存緩存技術(shù)可以很好的解決這個問題，它可以讓組件快速地重新加載和處理圖片。下面我們就來看一看如何使用內(nèi)存緩存技術(shù)來對圖片進(jìn)行緩存，從而讓你的應(yīng)用程序在加載很多圖片的時候可以提高響應(yīng)速度和流暢性。

內(nèi)存緩存技術(shù)對那些大量占用應(yīng)用程序?qū)氋F內(nèi)存的圖片提供了快速訪問的方法。其中最核心的類是LruCache (此類在android-support-v4的包中提供) 。這個類非常適合用來緩存圖片，它的主要算法原理是把最近使用的對象用強(qiáng)引用存儲在 LinkedHashMap 中，并且把最近最少使用的對象在緩存值達(dá)到預(yù)設(shè)定值之前從內(nèi)存中移除。

在過去，我們經(jīng)常會使用一種非常流行的內(nèi)存緩存技術(shù)的實現(xiàn)，即軟引用或弱引用 (SoftReference or WeakReference)。但是現(xiàn)在已經(jīng)不再推薦使用這種方式了，因為從 Android 2.3 (API Level 9)開始，垃圾回收器會更傾向于回收持有軟引用或弱引用的對象，這讓軟引用和弱引用變得不再可靠。另外，Android 3.0 (API Level 11)中，圖片的數(shù)據(jù)會存儲在本地的內(nèi)存當(dāng)中，因而無法用一種可預(yù)見的方式將其釋放，這就有潛在的風(fēng)險造成應(yīng)用程序的內(nèi)存溢出并崩潰。

為了能夠選擇一個合適的緩存大小給LruCache, 有以下多個因素應(yīng)該放入考慮范圍內(nèi)，例如：

你的設(shè)備可以為每個應(yīng)用程序分配多大的內(nèi)存？設(shè)備屏幕上一次最多能顯示多少張圖片？有多少圖片需要進(jìn)行預(yù)加載，因為有可能很快也會顯示在屏幕上？你的設(shè)備的屏幕大小和分辨率分別是多少？一個超高分辨率的設(shè)備（例如 Galaxy Nexus) 比起一個較低分辨率的設(shè)備（例如 Nexus S），在持有相同數(shù)量圖片的時候，需要更大的緩存空間。圖片的尺寸和大小，還有每張圖片會占據(jù)多少內(nèi)存空間。圖片被訪問的頻率有多高？會不會有一些圖片的訪問頻率比其它圖片要高？如果有的話，你也許應(yīng)該讓一些圖片常駐在內(nèi)存當(dāng)中，或者使用多個LruCache 對象來區(qū)分不同組的圖片。你能維持好數(shù)量和質(zhì)量之間的平衡嗎？有些時候，存儲多個低像素的圖片，而在后臺去開線程加載高像素的圖片會更加的有效。