在Android中：

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

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

　　C能施用的內存 = 16M - Java某一瞬間占在校大學生創(chuàng)業(yè)點子用的最大內存。

　　而Bitmap的生成是路程經過過程malloc進行內存分配的，占用的是C的內存。

?

Code :

/**
?*?@author?frankiewei.?工具類.
?*/
public?class?ImageCacheUtil?{

	public?static?final?int?UNCONSTRAINED?=?-1;

	/*
	?*?獲得設置信息
	?*/
	public?static?Options?getOptions(String?path)?{
		Options?options?=?new?Options();
		options.inJustDecodeBounds?=?true;//?只描邊，不讀取數據
		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;?//?設置縮放比例
			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);
	}

	/**
	?*?獲取需要進行縮放的比例，即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();
		}

?

?

使用圖片緩存技術

在你應用程序的UI界面加載一張圖片是一件很簡單的事情，但是當你需要在界面上加載一大堆圖片的時候，情況就變得復雜起來。在很多情況下，（比如使用ListView, GridView 或者 ViewPager 這樣的組件），屏幕上顯示的圖片可以通過滑動屏幕等事件不斷地增加，最終導致OOM。

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

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

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

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

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

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