android中常見的內存泄漏和解決的方法

android中的內存溢出預計大多數人在寫代碼的時候都出現過，事實上突然認為工作一年和工作三年的差別是什么呢。事實上干的工作或許都一樣，產品汪看到的結果也都一樣，那差別就是速度和質量了。

寫在前面的一點兒想法：工作做完了事實上不會的還有非常多，每天都有莫名的危機感，從真正寫代碼的這一年多總認為自己的學習速度比別人的慢非常多

內存泄漏是什么鬼？

• 當某些對象不再被程序所使用。可是這些對象仍然被某些對象所引用着。進而導致垃圾收集器不能及時釋放它們。

  
  （無效的對象沒有及時回收。導致內存不夠用。致使程序
  出錯）
  來個圖片了解一下
  

  知道為什么導致內存泄露那就非常好辦了。都是跟對象有關系（就是new出來的 不要想着他會跟你結婚）

主要有以下幾方面吧：平時注意一下 全然能夠杜絕的

• Context
• 內部類（handler等）
• Cursor
• Adapter
• Bitmap

Context的溢出

來個圖讓大家分分鍾理解一下：

看到這個圖在稍加思索會不會認為我們的工具類 貌似好多都持有了activity，並且工具類還是static類型。
在細琢磨一下呢。是不是activity的上下文都能夠被application替代呢？

經驗之談：dialog ，fragment。inflate和啟動activity 的上下文都是activity的。其它的都都能夠被application替代。比方數據庫的 服務的 廣播的。都不要再用activity了吧。

當然也要酌情處理。

• 舉個栗子(太多了根本舉只是來)

1.獲取系統的服務

getSystemService(Context.SENSOR_SERVICE);
    改為            getApplicationContext().getSystemService(Context.SENSOR_SERVICE);

2.弄個數據庫

public class NoteSQLiteOpenHelper extends SQLiteOpenHelper {

    /** * @param context 上下文 ; * @param name 數據庫的名稱 * @param cursorfactory 游標工廠null為默認的。是從第一條開始查詢 * @param version 數據庫的版本從1開始。
 */ public NoteSQLiteOpenHelper(getApplicationContext()) { super(getApplicationContext(), "note123.db", null, 1); } } 事實上這里用activity的也無所謂可是會出現用着用着就把他弄成靜態的了。那就悲劇了。 

其它的就是 千萬不要在 static的工具類里面 增加activity上下文

內部類的種種問題（感覺這個比較多一些呢）

簡單說一下呢：比方 activity 開線程 跳刀handler 彈出dialog。 activity在銷毀了，thread持有activity。然后跳到了handler，handler的對象也存在着了對吧，然后彈出dialog。這個時候呢dialog也持有了activity。可是由於activity銷毀了所以不彈了。但對象還是持有者了。

怎么解決 內部類的問題呢。就是在 依附於的那個類銷毀的時候 自己也銷毀。

就相似於activity銷毀了。什么thread，dialog。handler全關掉

• handler的情況

public class LeakActivity extends Activity {

  /** * 聲明靜態內部類不會持有外部類的隱式引用 */
  private static class MyHandler extends Handler {
    private final WeakReference<SampleActivity> mActivity;

    public MyHandler(SampleActivity activity) {
      mActivity = new WeakReference<SampleActivity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
      SampleActivity activity = mActivity.get();
      if (activity != null) {
        // ...
      }
    }
  }

  private final MyHandler mHandler = new MyHandler(this);

  /** * 這里的Runnable也是 * 聲明靜態內部類不會持有外部類的隱式引用 */
  private static final Runnable sRunnable = new Runnable() {
      @Override
      public void run() { /* ... */ }
  };

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    //10分鍾之后發送消息 
    mHandler.postDelayed(sRunnable, 1000 * 60 * 10);

    // 退回到上一個Activity
    finish();
  }
}


@Override
public void onDestroy() {
   //簡單粗暴
    mHandler.removeMessages(message);
    mHandler.removeCallbacks(Runnable);
    mHandler.removeCallbacksAndMessages(null);
}

切斷聯系即可啦。
- dialog
剛才說的按個 activity都銷毀了。

可是還要在handler中運行dialog。那么久做個推斷吧

Handler handler = new Handler() {
    public void handleMessage(Message msg) {
     super.handleMessage(msg);
        switch (msg.what) {
        case 1:

            if (!isFinishing()) {
               dialog.show();

            }  
            break;
        default:
            break;
        }  

    }  
};

• thread 和asynctask的情況
  在寫這個的時候我就在想我還有必要寫么。

  我都已經太久遠的沒用這兩個了。

  我都用的是線程池了。
  以下貼一個自己定義的線程池代碼。讀者直接拿走（能夠用 線程池+handler 或者 線程池+eventbus，rxbus等等來更新ui），activity銷毀的事后 直接讓線程池關閉即可啦

package com.ihealth.utils;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor.AbortPolicy;
import java.util.concurrent.TimeUnit;

/** * @author wanghao * * 說明：一個簡易的線程池管理類。提供三個線程池 進本的 子線程操作都能夠滿足 * * 線程內部都是 挨個進行，僅僅有創建多個線程池的才可能會並發進行。
 */ public class ThreadManager { public static final String DEFAULT_SINGLE_POOL_NAME = "DEFAULT_SINGLE_POOL_NAME"; private static ThreadPoolProxy mLongPool = null; private static Object mLongLock = new Object(); private static ThreadPoolProxy mShortPool = null; private static Object mShortLock = new Object(); private static ThreadPoolProxy mDownloadPool = null; private static Object mDownloadLock = new Object(); private static Map<String, ThreadPoolProxy> mMap = new HashMap<String, ThreadPoolProxy>(); private static Object mSingleLock = new Object(); /** 獲取下載線程 */ public static ThreadPoolProxy getDownloadPool() { synchronized (mDownloadLock) { if (mDownloadPool == null) { mDownloadPool = new ThreadPoolProxy(3, 3, 5L); } return mDownloadPool; } } /** 獲取一個用於運行長耗時任務的線程池，避免和短耗時任務處在同一個隊列而堵塞了重要的短耗時任務，通經常使用來聯網操作 */ public static ThreadPoolProxy getLongPool() { synchronized (mLongLock) { if (mLongPool == null) { mLongPool = new ThreadPoolProxy(5, 5, 5L); } return mLongPool; } } /** 獲取一個用於運行短耗時任務的線程池，避免由於和耗時長的任務處在同一個隊列而長時間得不到運行。通經常使用來運行本地的IO/SQL */ public static ThreadPoolProxy getShortPool() { synchronized (mShortLock) { if (mShortPool == null) { mShortPool = new ThreadPoolProxy(2, 2, 5L); } return mShortPool; } } /** 獲取一個單線程池，全部任務將會被依照增加的順序運行，免除了同步開銷的問題 */ public static ThreadPoolProxy getSinglePool() { return getSinglePool(DEFAULT_SINGLE_POOL_NAME); } /** 獲取一個單線程池，全部任務將會被依照增加的順序運行。免除了同步開銷的問題 */ public static ThreadPoolProxy getSinglePool(String name) { synchronized (mSingleLock) { ThreadPoolProxy singlePool = mMap.get(name); if (singlePool == null) { singlePool = new ThreadPoolProxy(1, 1, 5L); mMap.put(name, singlePool); } return singlePool; } } public static class ThreadPoolProxy { private ThreadPoolExecutor mPool; private int mCorePoolSize; private int mMaximumPoolSize; private long mKeepAliveTime; private ThreadPoolProxy(int corePoolSize, int maximumPoolSize, long keepAliveTime) { mCorePoolSize = corePoolSize; mMaximumPoolSize = maximumPoolSize; mKeepAliveTime = keepAliveTime; } /** 運行任務，當線程池處於關閉，將會又一次創建新的線程池 */ public synchronized void execute(Runnable run) { if (run == null) { return; } if (mPool == null || mPool.isShutdown()) { //參數說明 //當線程池中的線程小於mCorePoolSize。直接創建新的線程增加線程池運行任務 //當線程池中的線程數目等於mCorePoolSize，將會把任務放入任務隊列BlockingQueue中 //當BlockingQueue中的任務放滿了，將會創建新的線程去運行。 //可是當總線程數大於mMaximumPoolSize時，將會拋出異常，交給RejectedExecutionHandler處理 //mKeepAliveTime是線程運行完任務后，且隊列中沒有能夠運行的任務，存活的時間，后面的參數是時間單位 //ThreadFactory是每次創建新的線程工廠 mPool = new ThreadPoolExecutor(mCorePoolSize, mMaximumPoolSize, mKeepAliveTime, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), Executors.defaultThreadFactory(), new AbortPolicy()); } mPool.execute(run); } /** 取消線程池中某個還未運行的任務 */ public synchronized void cancel(Runnable run) { if (mPool != null && (!mPool.isShutdown() || mPool.isTerminating())) { mPool.getQueue().remove(run); } } /** 取消線程池中某個還未運行的任務 */ public synchronized boolean contains(Runnable run) { if (mPool != null && (!mPool.isShutdown() || mPool.isTerminating())) { return mPool.getQueue().contains(run); } else { return false; } } /** 立馬關閉線程池。並且正在運行的任務也將會被中斷 */ public void stop() { if (mPool != null && (!mPool.isShutdown() || mPool.isTerminating())) { mPool.shutdownNow(); } } /** 平緩關閉單任務線程池，可是會確保全部已經增加的任務都將會被運行完成才關閉 */ public synchronized void shutdown() { if (mPool != null && (!mPool.isShutdown() || mPool.isTerminating())) { mPool.shutdownNow(); } } } } 

• 廣播
  … has leaked IntentReceiver … Are you missing a call to unregisterReceiver()?
  這個錯誤我們如今公司的代碼還有大把的了。

  這么解決，一個大神的方法

簡單粗暴
private void unregisterReceiverSafe(BroadcastReceiver receiver) {
    try {
        getContext().unregisterReceiver(receiver);
    } catch (IllegalArgumentException e) {
        // ignore
    }
}

接下來的幾個感覺大家應該都不會出太大的問題吧

Cursor

try{}catch（）{}
finally{ cur.close(); cur=null; }

adapter (如今都用recycleview了。感覺寫這個有點兒雞肋)

會造成內存溢出代碼：
public View getView  (int position, View convertView, ViewGroup parent)  {
          View  view   =   new  View();
          XXX                   XXX
          return    view;
}
修正后的代碼：
public View getView (int position, View convertView, ViewGroup parent)  {
           if  (convertView  ==  null)  {
                 convertView   =  new View();
                 XXX                     XXX
           }  else  {
                 XXX                     XXX
           }
}

Bitmap

不用的時候調用 recycle(),把他清理掉
也能夠用lrucache等方法，這就不做具體介紹。

轉載請注明：http://blog.csdn.net/wanghao200906/article/details/50426881
就這樣吧。忙里偷閑寫了個博客，總結一下，事實上內存溢出的問題都是 不小心導致的，避免起來也比較easy。

文章有點兒長 讀完了 ：辛苦了您內，0基礎文章大神勿噴