本篇文章主要介紹了Android性能優化之利用LeakCanary檢測記憶體泄漏及解決辦法，有興趣的同學可以了解一下，

前言
- - 什么是記憶體泄漏？
  - 記憶體泄漏造成什么影響？
  - 什么是LeakCanary？
  - - LeakCanary捕獲常見記憶體泄漏以及解決辦法
    - - 1.) 錯誤使用單例造成的記憶體泄漏
      - LeakCanary檢測結果如下：
      - 2.）Handler造成的記憶體泄漏
      - LeakCanary檢測結果如下：
      - 3.)執行緒造成的記憶體泄漏
      - LeakCanary檢測結果：
      - 4.）非靜態內部類創建靜態實體造成的記憶體泄漏
      - 5.）由WebView引起的記憶體泄漏
      - 先看下LeakCanary檢測到的結果如下：
      - 6.）資源未關閉造成的記憶體泄漏
- 總結：

前言

面試程序中聊到性能優化中如何避免記憶體泄漏問題時，很少有人全面的回答上來，所以決定抽空學習總結一下這方面的知識，以及分享一下我們是如何檢測記憶體泄漏的，我們公司使用開源框架LeakCanary來檢測記憶體泄漏，

什么是記憶體泄漏？

有些物件只有有限的生命周期，當它們的任務完成之后，它們將被垃圾回收，如果在物件的生命周期本該結束的時候，這個物件還被一系列的參考，這就會導致記憶體泄漏，隨著泄漏的累積，app將消耗完記憶體，

記憶體泄漏造成什么影響？

它是造成應用程式OOM的主要原因之一，由于android系統為每個應用程式分配的記憶體有限，當一個應用中產生的記憶體泄漏比較多時，就難免會導致應用所需要的記憶體超過這個系統分配的記憶體限額，這就造成了記憶體溢位而導致應用Crash，

什么是LeakCanary？

leakCanary是Square開源框架，是一個Android和Java的記憶體泄露檢測庫，如果檢測到某個 activity 有記憶體泄露，LeakCanary 就是自動地顯示一個通知，所以可以把它理解為傻瓜式的記憶體泄露檢測工具，通過它可以大幅度減少開發中遇到的oom問題，大大提高APP的質量，

LeakCanary捕獲常見記憶體泄漏以及解決辦法

1.) 錯誤使用單例造成的記憶體泄漏

在平時開發中單例設計模式是我們經常使用的一種設計模式，而在開發中單例經常需要持有Context物件，如果持有的Context物件生命周期與單例生命周期更短時，或導致Context無法被釋放回收，則有可能造成記憶體泄漏，錯誤寫法如下：

public class LoginManager {
  private static LoginManager mInstance;
  private Context mContext;

  private LoginManager(Context context) {
    this.mContext = context;
  }


  public static LoginManager getInstance(Context context) {
    if (mInstance == null) {
      synchronized (LoginManager.class) {
        if (mInstance == null) {
          mInstance = new LoginManager(context);
        }
      }
    }
    return mInstance;
  }

  public void dealData() {
  }

}

我們在一個Activity中呼叫的，然后關閉該Activity則會出現記憶體泄漏，

LoginManager.getInstance(this).dealData();

LeakCanary檢測結果如下：

在這里插入圖片描述
解決辦法要保證Context和AppLication的生命周期一樣，修改后代碼如下：

public class LoginManager {
  private static LoginManager mInstance;
  private Context mContext;

  private LoginManager(Context context) {
    this.mContext = context.getApplicationContext();
  }


  public static LoginManager getInstance(Context context) {
    if (mInstance == null) {
      synchronized (LoginManager.class) {
        if (mInstance == null) {
          mInstance = new LoginManager(context);
        }
      }
    }
    return mInstance;
  }

  public void dealData() {
  }

}

2.）Handler造成的記憶體泄漏

早些年Handler的使用頻率還是蠻高的，它是作業執行緒與UI執行緒之間通訊的橋梁，只是現在大量開源框架對其進行了封裝，我們這里模擬一種常見使用方式來模擬記憶體泄漏情形，

public class MainActivity1 extends AppCompatActivity {
  private Handler mHandler = new Handler();
  private TextView mTextView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    mTextView = (TextView) findViewById(R.id.text);
    //模擬記憶體泄露
    mHandler.postDelayed(new Runnable() {
      @Override
      public void run() {
        mTextView.setText("lcj");
      }
    }, 3 * 60 * 1000);
    finish();
  }
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    mHandler.removeCallbacksAndMessages(null);
    mHandler=null;
    LApplication.getRefWatcher().watch(this);
  }
}

上述代碼通過內部類的方式創建mHandler物件,此時mHandler會隱式地持有一個外部類物件參考這里就是MainActivity，當執行postDelayed方法時，該方法會將你的Handler裝入一個Message，并把這條Message推到MessageQueue中，MessageQueue是在一個Looper執行緒中不斷輪詢處理訊息，那么當這個Activity退出時訊息佇列中還有未處理的訊息或者正在處理訊息，而訊息佇列中的Message持有mHandler實體的參考，mHandler又持有Activity的參考，所以導致該Activity的記憶體資源無法及時回收，引發記憶體泄漏，

LeakCanary檢測結果如下：

在這里插入圖片描述

要想避免Handler引起記憶體泄漏問題，需要我們在Activity關閉退出的時候的移除訊息佇列中所有訊息和所有的Runnable，上述代碼只需在onDestroy()函式中呼叫mHandler.removeCallbacksAndMessages(null);就行了，

public class MainActivity1 extends AppCompatActivity {
  private Handler mHandler = new Handler();
  private TextView mTextView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    mTextView = (TextView) findViewById(R.id.text);
    //模擬記憶體泄露
    mHandler.postDelayed(new Runnable() {
      @Override
      public void run() {
        mTextView.setText("lcj");
      }
    }, 3 * 60 * 1000);
    finish();
  }
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    mHandler.removeCallbacksAndMessages(null);
    mHandler=null;
    LApplication.getRefWatcher().watch(this);
  }
}

3.)執行緒造成的記憶體泄漏

最早時期的時候處理耗時操作多數都是采用Thread+Handler的方式，后來逐步被AsyncTask取代，直到現在采用RxJava的方式來處理異步，這里以AsyncTask為例，可能大部分人都會這樣處理一個耗時操作然后通知UI更新結果：

public class MainActivity extends AppCompatActivity {
  private AsyncTask<Void, Void, Integer> asyncTask;
  private TextView mTextView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    mTextView = (TextView) findViewById(R.id.text);
    testAsyncTask();
    finish();
  }
 
  private void testAsyncTask() {
    asyncTask = new AsyncTask<Void, Void, Integer>() {
      @Override
      protected Integer doInBackground(Void... params) {
        int i = 0;
        //模擬耗時操作
        while (!isCancelled()) {
          i++;
          if (i > 1000000000) {
            break;
          }
          Log.e("LeakCanary", "asyncTask---->" + i);
        }
        return i;
      }
 
      @Override
      protected void onPostExecute(Integer integer) {
        super.onPostExecute(integer);
        mTextView.setText(String.valueOf(integer));
      }
    };
    asyncTask.execute();
 
  }
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
  }
 
}

對于上面的例子來說，在處理一個比較耗時的操作時，可能還沒處理結束MainActivity就執行了退出操作，但是此時AsyncTask依然持有對MainActivity的參考就會導致MainActivity無法釋放回收引發記憶體泄漏，

LeakCanary檢測結果：

在這里插入圖片描述如何解決這種記憶體泄漏呢？在使用AsyncTask時，在Activity銷毀時候也應該取消相應的任務AsyncTask.cancel()方法，避免任務在后臺執行浪費資源，進而避免記憶體泄漏的發生，

public class MainActivity3 extends AppCompatActivity {
  private AsyncTask<Void, Void, Integer> asyncTask;
  private TextView mTextView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    mTextView = (TextView) findViewById(R.id.text);
    testAsyncTask();
    finish();
  }
 
  private void testAsyncTask() {
    asyncTask = new AsyncTask<Void, Void, Integer>() {
      @Override
      protected Integer doInBackground(Void... params) {
        int i = 0;
        //模擬耗時操作
        while (!isCancelled()) {
          i++;
          if (i > 1000000000) {
            break;
          }
          Log.e("LeakCanary", "asyncTask---->" + i);
        }
        return i;
      }
 
      @Override
      protected void onPostExecute(Integer integer) {
        super.onPostExecute(integer);
        mTextView.setText(String.valueOf(integer));
      }
    };
    asyncTask.execute();
 
  }
 
  private void destroyAsyncTask() {
    if (asyncTask != null && !asyncTask.isCancelled()) {
      asyncTask.cancel(true);
    }
    asyncTask = null;
  }
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    destroyAsyncTask();
    LApplication.getRefWatcher().watch(this);
  }
 
}

4.）非靜態內部類創建靜態實體造成的記憶體泄漏

有時我們需要一個可以隨著螢屏旋轉的Activity，比如視頻播放Activity，這時我們為了防止多次呼叫onCreate方法導致某些引數重新初始化，我們一般會選擇創建一個內部類和一個靜態實體來保存這些引數，比如以下實作：

public class MainActivity extends AppCompatActivity {
  private static Config mConfig;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //模擬記憶體泄露
    if (mConfig == null) {
      mConfig = new Config();
      mConfig.setSize(18);
      mConfig.setTitle("老九門");
    }
    finish();
  }
 
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
  }
 
  class Config {
    private int size;
    private String title;
 
    public int getSize() {
      return size;
    }
 
    public void setSize(int size) {
      this.size = size;
    }
 
    public String getTitle() {
      return title;
    }
 
    public void setTitle(String title) {
      this.title = title;
    }
  }
}

上述代碼看著沒有任何問題，其實內部類都會持有一個外部類參考，這里這個外部類就是MainActivity，然而內部類實體又是static靜態變數其生命周期與Application生命周期一樣，所以在MainActivity關閉的時候，內部類靜態實體依然持有對MainActivity的參考，導致MainActivity無法被回收釋放，引發記憶體泄漏，LeakCanary檢測記憶體泄漏結果如下：
在這里插入圖片描述

對于這種泄漏的解決辦法就是將內部類改成靜態內部類，不再持有對MainActivity的參考即可，修改后的代碼如下：

public class MainActivity extends AppCompatActivity {
  private static Config mConfig;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //模擬記憶體泄露
    if (mConfig == null) {
      mConfig = new Config();
      mConfig.setSize(18);
      mConfig.setTitle("老九門");
    }
    finish();
  }
 
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
  }
 
  static class Config {
    private int size;
    private String title;
 
    public int getSize() {
      return size;
    }
 
    public void setSize(int size) {
      this.size = size;
    }
 
    public String getTitle() {
      return title;
    }
 
    public void setTitle(String title) {
      this.title = title;
    }
  }
}

5.）由WebView引起的記憶體泄漏

在目前的開發中多多少少會用到Hybrid開發方式，這樣我們就會用WebView去承載Html網頁，就如下面這種方式：

public class MainActivity5 extends AppCompatActivity {
  private WebView mWebView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_web);
    mWebView = (WebView) findViewById(R.id.web);
    mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
  }
 
 
  @Override
  protected void onDestroy() {
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
  }
 
}

xml布局檔案：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:id="@+id/activity_main"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:orientation="vertical">
 
  <WebView
    android:id="@+id/web"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"/>
</LinearLayout>

WebView決議網頁時會申請Native堆記憶體用于保存頁面元素，當頁面較復雜時會有很大的記憶體占用，如果頁面包含圖片，記憶體占用會更嚴重，并且打開新頁面時，為了能快速回退，之前頁面占用的記憶體也不會釋放，有時瀏覽十幾個網頁，都會占用幾百兆的記憶體，這樣加載網頁較多時，會導致系統不堪重負，最終強制關閉應用，也就是出現應用閃退或重啟，及時Activity關閉時在onDestroy中呼叫如下代碼也是沒有任何作用，

private void destroyWebView() {
    if (mWebView != null) {
      mLinearLayout.removeView(mWebView);
      mWebView.pauseTimers();
      mWebView.removeAllViews();
      mWebView.destroy();
      mWebView = null;
    }
  }

先看下LeakCanary檢測到的結果如下：

在這里插入圖片描述
該如何解決呢？這個查了不少資料，其中一種就是使用getApplicationgContext作為引數構建WebView，然后動態添加到一個ViewGroup中，最后退出的時候呼叫webView的銷毀的函式，雖然也達到了防止記憶體溢位的效果，但是在有些網頁彈出時候需要記住密碼的對話框的時候，會出現Unable to add window – token null is not for an application 的錯誤，所以這里采用的解決辦法是
通過把使用了WebView的Activity(或者Service)放在單獨的行程里，
然后在檢測到應用占用記憶體過大有可能被系統干掉或者它所在的Activity(或者Service)結束后，呼叫android.os.Process.killProcess(android.os.Process.myPid());，主動Kill掉行程，由于系統的記憶體分配是以行程為準的，行程關閉后，系統會自動回收所有記憶體，

修改后的代碼如下：

public class MainActivity5 extends AppCompatActivity {
  private WebView mWebView;
 
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_web);
    mWebView = (WebView) findViewById(R.id.web);
    mWebView.loadUrl("http://www.cnblogs.com/whoislcj/p/5720202.html");
  }
 
  @Override
  protected void onDestroy() {
    destroyWebView();
    android.os.Process.killProcess(android.os.Process.myPid());
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
 
  }
 
  private void destroyWebView() {
    if (mWebView != null) {
      mWebView.pauseTimers();
      mWebView.removeAllViews();
      mWebView.destroy();
      mWebView = null;
    }
  }
 
}

manifest中對應的activity配置如下：

<activity
  android:name=".MainActivity5"
  android:process="com.whoislcj.webview"/>

6.）資源未關閉造成的記憶體泄漏

對于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源的使用，應該在Activity銷毀時及時關倍訓者注銷，否則這些資源將不會被回收，造成記憶體泄漏，例如獲取媒體庫圖片地址代碼在查詢結束的時候一定要呼叫

Cursor 的關閉方法防止造成記憶體泄漏，

 String columns[] = new String[]{
                MediaStore.Images.Media.DATA, 
                MediaStore.Images.Media._ID,
                MediaStore.Images.Media.TITLE,
                MediaStore.Images.Media.DISPLAY_NAME
        };
        Cursor cursor = this.getContentResolver().query(
                MediaStore.Images.Media.EXTERNAL_CONTENT_URI, 
                columns, 
                null, null, null);
        if (cursor != null) {
            int photoIndex = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA);
            //顯示每張圖片的地址，但是首先要判斷一下，Cursor是否有值
            while (cursor.moveToNext()) {
                String photoPath = cursor.getString(photoIndex); //這里獲取到的就是圖片存盤的位置資訊
                Log.e("LeakCanary", "photoPath---->" + photoPath);
            }
            cursor.close();
        }
    }

總結：

以上就是通過LeakCanary檢測到的記憶體泄漏情況以及解決辦法，希望對大家的學習有所幫助，

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/274428.html

標籤：其他

上一篇：dell筆記本怎么安裝ubuntu和windows雙作業系統

下一篇：在多人音視頻聊天中插入現場直播

Android性能優化之利用強大的LeakCanary檢測記憶體泄漏及解決辦法

目錄

前言

什么是記憶體泄漏？

記憶體泄漏造成什么影響？

什么是LeakCanary？

LeakCanary捕獲常見記憶體泄漏以及解決辦法

1.) 錯誤使用單例造成的記憶體泄漏

LeakCanary檢測結果如下：

2.）Handler造成的記憶體泄漏

LeakCanary檢測結果如下：

3.)執行緒造成的記憶體泄漏

LeakCanary檢測結果：

4.）非靜態內部類創建靜態實體造成的記憶體泄漏

5.）由WebView引起的記憶體泄漏

先看下LeakCanary檢測到的結果如下：

6.）資源未關閉造成的記憶體泄漏

總結：