一. 避免OOM :
1.使用更加輕量的數(shù)據(jù)結構:例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統(tǒng)數(shù)據(jù)結構(數(shù)組 加鏈表實現(xiàn) 擴容x2) ,SparseArray更加高效，在于他們避免了對key與value的自動裝箱. 使用 StringBuilder 或StringBuffer 代替 String 對字符串進行操作；
減少Bitmap 對象的內(nèi)存占用；inSampleSize：縮放比例，在把圖片載入內(nèi)存之前，我們需 要先計算出一個合適的縮放比例，避免不必要的大圖載入。decode format 設置編碼，：inPurgeable：設置為True時，表示系統(tǒng)內(nèi)存不足時可以被回 收，設置為False時，表示不能被回收
xhdpi 對應文件下放置對應的圖片，并且使用更小的圖片；資源文件需要選擇合適的文件夾進行存放
內(nèi)存對象的重復利用；減少對象的創(chuàng)建或者采用創(chuàng)建對象池，處理好復用邏輯， 對常用的對象采用單例模式創(chuàng)建 降低內(nèi)存的分配； ListView Gridview 的ConvertView 的復用；Bitmap 的復用，LRU的機制來緩存處理好的Bitmap 并對bitmap 進行壓縮；
二.避免對象的內(nèi)存泄漏（反復進入某個界面 內(nèi)存并沒有消失）
內(nèi)存對象的泄漏，會導致一些不再使用的對象無法及時釋放，這樣一方面占用了寶貴的內(nèi)存空間，很容易導致后續(xù)需要分配內(nèi)存的時候，空閑空間不足而出現(xiàn)OOM。
1.ActivityContext 被傳遞到其他實例中 導致自身被引用而發(fā)生了泄漏，非靜態(tài)內(nèi)部類持有外部的引用，導致內(nèi)存泄漏；Handler 導致Activity泄漏（如果Handler中有延遲的任務或者是等待執(zhí)行的任務隊列過長，都有可能因為Handler繼續(xù)執(zhí)行而導致Activity發(fā)生泄漏。）為了解決這個問題，可以在UI退出之前，執(zhí)行remove Handler消息隊列中的消息與runnable對象?；蛘呤鞘褂肧tatic + WeakReference的方式來達到斷開Handler與Activity之間存在引用關系的目的。Application Context而不是Activity Context對于非UI 的Context 可以使用 Application Context。 開啟Activity ,廣播,Service,獲取資源等操作單例的持有Context 換為持有Application Context
2.打開資源的關閉 ，如數(shù)據(jù)庫Cursor對象，文件流， Dialog 要關閉 ，廣播要解除注冊；等
- 臨時創(chuàng)建的Bitmap的回收 ,退出顯示圖片的頁面時，清空緩存釋放內(nèi)存；
4 軟引用與弱引用的應用
如果一個對象只具有軟引用，那么如果內(nèi)存空間足夠，垃圾回收器就不會回收它；如果內(nèi)存空間不足了，就會回收這些對象的內(nèi)存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現(xiàn)內(nèi)存敏感的高速緩存。軟引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果軟引用所引用的對象被垃圾回收，Java虛擬機就會把這個軟引用加入到與之關聯(lián)的引用隊列中。
弱引用與軟引用的根本區(qū)別在于：只具有弱引用的對象擁有更短暫的生命周期，可能隨時被回收。而只具有軟引用的對象只有當內(nèi)存不夠的時候才被回收，在內(nèi)存足夠的時候，通常不被回收。
假設我們的應用會用到大量的默認圖片，比如應用中有默認的頭像，默認游戲圖標等等，這些圖片很多地方會用到。如果每次都去讀取圖片，由于讀取文件需要硬件操作，速度較慢，會導致性能較低。所以我們考慮將圖片緩存起來，需要的時候直接從內(nèi)存中讀取。但是，由于圖片占用內(nèi)存空間比較大，緩存很多圖片需要很多的內(nèi)存，就可能比較容易發(fā)生OutOfMemory異常。這時，我們可以考慮使用軟引用技術來避免這個問題發(fā)生。
首先定義一個HashMap，保存軟引用對象。
private Map> imageCache = new HashMap>();
private Map> imageCache = new HashMap>();
public void addBitmapToCache(String path) {
// 強引用的Bitmap對象
Bitmap bitmap = BitmapFactory.decodeFile(path);
// 軟引用的Bitmap對象
SoftReference softBitmap = new SoftReference(bitmap);
// 添加該對象到Map中使其緩存
imageCache.put(path, softBitmap);
}
public Bitmap getBitmapByPath(String path) {
// 從緩存中取軟引用的Bitmap對象
SoftReference softBitmap = imageCache.get(path);
// 判斷是否存在軟引用
if (softBitmap == null) {
return null;
}
// 取出Bitmap對象，如果由于內(nèi)存不足Bitmap被回收，將取得空
Bitmap bitmap = softBitmap.get();
return bitmap;
}
使用軟引用以后，在OutOfMemory異常發(fā)生之前，這些緩存的圖片資源的內(nèi)存空間可以被釋放掉的，從而避免內(nèi)存達到上限，避免Crash發(fā)生。
需要注意的是，在垃圾回收器對這個Java對象回收前，SoftReference類所提供的get方法會返回Java對象的強引用，一旦垃圾線程回收該Java對象之后，get方法將返回null。所以在獲取軟引用對象的代碼中，一定要判斷是否為null，以免出現(xiàn)NullPointerException異常導致應用崩潰。
個人認為，如果只是想避免OutOfMemory異常的發(fā)生，則可以使用軟引用。如果對于應用的性能更在意，想盡快回收一些占用內(nèi)存比較大的對象，則可以使用弱引用。還有就是可以根據(jù)對象是否經(jīng)常使用來判斷。如果該對象可能會經(jīng)常使用的，就盡量用軟引用。如果該對象不被使用的可能性更大些，就可以用弱引用。
