轉載于：Android開發中文站 ? Android避免內存溢出（Out of Memory）方法總結
避免內存溢出的方法，主要是對以下三個方面對程序進行優化
在處理內存引用之前，我們先來復習下什么是強引用、軟引用、弱引用、虛引用
強引用：強引用是使用最普遍的引用。如果一個對象具有強引用，那垃圾回收器絕不會回收它。 當內存空間不足，java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足的問題。
軟引用：如果一個對象只具有軟引用，但內存空間足夠時，垃圾回收器就不會回收它；直到虛擬機報告內存不夠時才會回收， 只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現內存敏感的高速緩存。 軟引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果軟引用所引用的對象被垃圾回收器回收，Java虛擬機就會把這個軟引用加入到與之關聯的引用隊列中。
弱引用：只具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內存區域的過程中，一旦發現了只具有弱引用的對象，不管當前內存空間是否足夠，都會回收它的內存。 不過，由于垃圾回收器是一個優先級很低的線程，因此不一定會很快發現那些只具有弱引用的對象。 弱引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果弱引用所引用的對象被垃圾回收，Java虛擬機就會把這個弱引用加入到與之關聯的引用隊列中。虛引用：虛引用可以理解為虛設的引用，與其他幾種引用都不同，虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣，在任何時候都可能被垃圾回收器回收。 虛引用主要用來跟蹤對象被垃圾回收器回收的活動。 虛引用與軟引用和弱引用的一個區別在于：虛引用必須和引用隊列 （ReferenceQueue）聯合使用。 當垃圾回收器準備回收一個對象時，如果發現它還有虛引用，就會在回收對象的內存之前，把這個虛引用加入到與之 關聯的引用隊列中。 程序可以通過判斷引用隊列中是否已經加入了虛引用，來了解被引用的對象是否將要被垃圾回收。 如果程序發現某個虛引用已經被加入到引用隊列，那么就可以在所引用的對象的內存被回收之前采取必要的行動。
一般我們在聲明對象變量時，使用完后就不管了，認為垃圾回收器會幫助我們回收這些對象所指向的內存空間，實際上如果這個對象的內存空間還處在被引用狀態的話，垃圾回收器是永遠不會回收它的內存空間的，只有當這個內存空間不被任何對象引用的時候，垃圾回收器才會去回收。
所以我們在使用完對象后，可以把對象置為空，這樣我的垃圾回收器gc就會在合適的時候釋放掉為該對象分配的內存空間
| 12 | Object obj = new Object();obj = null; |
當然，在置為空前要確認是否不再需要使用該對象了，如果需要隨時使用這個對象，則不能這么做
在jvm報告內存不足之前會清除所有的軟引用，這樣的話gc就可以收集到很多軟引用釋放出來的內存空間，從而解決內存吃緊的問題，避免內存溢出，什么時候被回收取決于gc的算法和gc運行時可用的內存大小。
我們可以用SoftReference來封裝強引用的對象
| 12 | String str = "zhuwentao"; // 強引用SoftReference<String> strSoft = new SoftReference<String>(str); // 使用軟引用封裝強引用 |
gc收集弱引用對象的執行過程和軟引用一樣，只是gc不會根據內存情況來決定是否回收弱引用的對象。
| 12 | String str = "zhuwentao"; // 強引用WeakReference<String> strWeak = new WeakReference<String>(str); // 使用弱引用封裝強強引用 |
如果你希望能夠隨時取得某個對象的信息，但又不希望影響該對象的垃圾回收，則應該使用WeakReference來記住該對象，而不是使用一般的Reference。
大部分的OOM都是發生在圖片加載上的，當我們加載大圖時，需要特別注意避免OOM的發生。
處理大圖片時，不管你的手機內存有多大，如果不對圖片進行處理，都有可能會發生內存溢出問題。
因為Android系統會為每一個應用分配一定大小的內存，并不會把整個系統內存全部分給應用，所以不管你手機內存多大，對每個App來說，它能使用的內存都是有限的。
這和PC端是有很大的不同，PC端如果內存不夠了還可以請求使用虛擬內存，而Android系統可沒這個機制。
裝載大圖片時需要對圖片進行壓縮，使用等比例壓縮的方法直接在內存中處理圖片
| 123 | Options options = new BitmapFactory.Options();options.inSampleSize = 5; // 原圖的五分之一，設置為2則為二分之一BitmapFactory.decodeFile(myImage.getAbsolutePath(), options); |
這樣做要注意的是，圖片質量會變差，inSampleSize設置的值越大，圖片質量就越差，不同的手機廠商縮放的比例可能不同。
由于Android外層是使用java而底層使用的是C語言在里層為圖片對象分配的內存空間。
所以我們的外部雖然看起來釋放了，但里層卻并不一定完全釋放了，我們使用完圖片后最好再釋放掉里層的內存空間。
| 1234 | if (!bitmapObject.isRecyled()) { // Bitmap對象沒有被回收 bitmapObject.recycle(); // 釋放 System.gc(); // 提醒系統及時回收} |
Android中Bitmap有四種圖片色彩模式：
ALPHA_8：每個像素需要占用內存中的1byte
RGB_565：每個像素需要占用內存中的2byte
ARGB_4444：每個像素需要占用內存中的2byte
ARGB_8888：每個像素需要占用內存中的4byte
我們創建Bitmap時，默認的色彩模式是ARGB_8888的，這種色彩模式是質量最高的，當然這樣的模式占用的內存也最大。
而ARGB_4444每個像素只占用2byte，所以使用ARGB_4444的模式也能降低圖片占用的內存大小。
| 123 | BitmapFactory.Options options = new BitmapFactory.Options();options.inPReferredConfig = Bitmap.Config.ARGB_4444;Bitmap btimapObject = BitmapFactory.decodeFile(myImage.getAbsolutePath(), options); |
其實大多數圖片設置成ARGB_4444模式后，在顯示上是看不出與ARGB_8888模式有什么差別的，只是在具有漸變色效果的圖片時，可能會讓漸變色呈現色彩條樣的效果。
這種降低色彩質量的方法對內存的降低效果不如方法1明顯。
有時候我們取得一張圖片，也許只是為了獲得這個圖片的一些信息，比如圖片的width、height等信息，不需要顯示到界面上，這個時候我們可以不把圖片加載到內存中。
| 123 | BitmapFactory.Options options = new BitmapFactory.Options();options.inJustDecodeBounds = true; // 不把圖片加載到內存中Bitmap btimapObject = BitmapFactory.decodeFile(myImage.getAbsolutePath(), options); |
inJustDecodeBounds屬性，如果值為true，那么將不返回實際的Bitmap對象，也不給其分配內存空間，但允許我們查詢圖片寬、高、大小等基本信息。
（獲取原始寬高：options.outWidth，options.outHeight）
VMRuntime是Android SDK中提供的一個類。
只在Android2.3以前有用，2.3以后的SDK就不支持了，所以這個VMRuntime并不通用。
這里簡單介紹下就好了。
VMRuntime類提供的setTargetHeapUtilization方法可以增強程序堆內存的處理效率。
| 12 | private final static float TARGET_HEAP_UTILIZATION = 0.75f;VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); |
強制定義Android給當前App分配的內存大小，使用VMRuntime設置應用最小堆內存。
| 123 | // 設置最小heap內存為 6MB 大小private final static int HEAP_SIZE = 6 * 1024 * 1024 ;VMRuntime.getRuntime().setMinimumHeapSize(HEAP_SIZE); |
讓Dalvik虛擬機為App分配更大的內存，該方法能為我們的App爭取到更多內存空間，從而緩解內存不足的壓力
可以在程序中使用ActivityManager.getMemoryClass()方法來獲取App內存正常使用情況下的大小，通過ActivityManager.getLargeMemoryClass()可獲得開啟largeHeap時最大的內存大小
該方法使用非常簡單，只要在AndroidManifest.xml文件中的<application>節點屬性中加上”android:largeHeap=”true”“
| 12345 | <application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/APPTheme" android:largeHeap="true" |
Dalvik為我們App增加的內存很可能是通過殺死其它后臺進程獲取的內存，這樣的做法對于一個開發者來說并不道義
我們不應該把解決OOM的問題寄托在爭取最大的內存上，應該通過合理的代碼編寫來盡可能的規避OOM問題
轉載請注明：Android開發中文站 ? Android避免內存溢出（Out of Memory）方法總結
新聞熱點
疑難解答
