一、概述
在 Android內存泄漏終極解決篇（上）中我們介紹瞭如何檢查一個App是否存在內存泄漏的問題，本篇將總結典型的內存泄漏的代碼，並給出對應的解決方案。內存泄漏的主要問題可以分爲以下幾種類型：
靜態變量引起的內存泄漏 非靜態內部類引起的內存泄漏 資源未關閉引起的內存泄漏
二、靜態變量引起的內存泄漏
在java中靜態變量的生命週期是在類加載時開始，類卸載時結束。換句話說，在android中其生命週期是在進程啓動時開始，進程死亡時結束。所以在程序的運行期間，如果進程沒有被殺死，靜態變量就會一直存在，不會被回收掉。如果靜態變量強引用了某個Activity中變量，那麼這個Activity就同樣也不會被釋放,即便是該Activity執行了onDestroy(不要將執行onDestroy和被回收劃等號)。這類問題的解決方案爲：1.尋找與該靜態變量生命週期差不多的替代對象。2.若找不到，將強引用方式改成弱引用。比較典型的例子如下:
單例引起的Context內存泄漏
public class IMManager { private Context context; private static IMManager mInstance; public static IMManager getInstance(Context context) { if (mInstance == null) { synchronized (s) { if (mInstance == null) mInstance = new IMManager(context); } } return mInstance; } private IMManager(Context context) { ext = context; }}
當調用getInstance時，如果傳入的context是Activity的context。只要這個單例沒有被釋放，這個Activity也不會被釋放。
解決方案
傳入Application的context,因爲Application的context的生命週期比Activity長，可以理解爲Application的context與單例的生命週期一樣長，傳入它是最合適的。
public class IMManager { private Context context; private static IMManager mInstance; public static IMManager getInstance(Context context) { if (mInstance == null) { synchronized (s) { if (mInstance == null) //將傳入的`context轉換成Application的context mInstance = new IMManager(pplicationContext()); } } return mInstance; } private IMManager(Context context) { ext = context; }}
三、非靜態內部類引起的內存泄漏
在java中，創建一個非靜態的內部類實例，就會引用它的外圍實例。如果這個非靜態內部類實例做了一些耗時的操作，就會造成外圍對象不會被回收，從而導致內存泄漏。這類問題的解決方案爲：1.將內部類變成靜態內部類 2.如果有強引用Activity中的屬性，則將該屬性的引用方式改爲弱引用。3.在業務允許的情況下，當Activity執行onDestory時，結束這些耗時任務。
內部線程造成的內存泄漏
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { eate(savedInstanceState); setContentView(_leak); test(); } public void test() { //匿名內部類會引用其外圍實例,所以會導致內存泄漏 new Thread(new Runnable() { @Override public void run() { while (true) { try { p(1000); } catch (InterruptedException e) { tStackTrace(); } } } })t(); } }
解決方案
將非靜態匿名內部類修改爲靜態匿名內部類
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { eate(savedInstanceState); setContentView(_leak); test(); } //加上static，變成靜態匿名內部類 public static void test() { new Thread(new Runnable() { @Override public void run() { while (true) { try { p(1000); } catch (InterruptedException e) { tStackTrace(); } } } })t(); }}
Handler引起的內存泄漏
public class LeakAty extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { eate(savedInstanceState); setContentView(_leak); fetchData(); } private Handler mHandler = new Handler() { public void handleMessage(age msg) { switch () { case 0: // 刷新數據 break; default: break; } }; }; private void fetchData() { //獲取數據 EmptyMessage(0); }}
mHandler 爲匿名內部類實例，會引用外圍對象,如果該Handler在Activity退出時依然還有消息需要處理，那麼這個Activity就不會被回收。
解決方案
public class LeakAty extends Activity { private TextView tvResu< private MyHandler handler; @Override protected void onCreate(Bundle savedInstanceState) { eate(savedInstanceState); setContentView(_leak); tvResult = (TextView) findViewById(sult); handler = new MyHandler(this); fetchData(); } //第一步，將Handler改成靜態內部類。 private static class MyHandler extends Handler { //第二步，將需要引用Activity的地方，改成弱引用。 private WeakReferenceatyInstance; public MyHandler(LeakAty aty) { nstance = new WeakReference(aty); } @Override public void handleMessage(Message msg) { leMessage(msg); LeakAty aty = atyInstance == null ? null : (); //如果Activity被釋放回收了，則不處理這些消息 if (aty == null||nishing()) { return; } ext("fetch data success"); } } private void fetchData() { // 獲取數據 EmptyMessage(0); } @Override protected void onDestroy() { //第三步，在Activity退出的時候移除回調 stroy(); veCallbacksAndMessages(null); }}
四、資源未關閉引起的內存泄漏
當使用了BraodcastReceiver、Cursor、Bitmap等資源時，當不需要使用時，需要及時釋放掉，若沒有釋放，則會引起內存泄漏。
綜上所述，內存泄漏的主要情況爲上面的三大類型，最終歸結爲一點，就是資源在不需要的時候沒有被釋放掉。所以在編碼的過程中要注意這些細節，提高程序的性能。
