Android性能優(yōu)化之利用強(qiáng)大的LeakCanary檢測(cè)內(nèi)存泄漏及解決辦法

更新時(shí)間：2016年11月18日 17:32:21 作者：總李寫代碼

本篇文章主要介紹了Android性能優(yōu)化之利用LeakCanary檢測(cè)內(nèi)存泄漏及解決辦法，有興趣的同學(xué)可以了解一下。

前言：

最近公司C輪融資成功了，移動(dòng)團(tuán)隊(duì)準(zhǔn)備擴(kuò)大一下，需要招聘Android開(kāi)發(fā)工程師，陸陸續(xù)續(xù)面試了幾位Android應(yīng)聘者，面試過(guò)程中聊到性能優(yōu)化中如何避免內(nèi)存泄漏問(wèn)題時(shí)，很少有人全面的回答上來(lái)。所以決定抽空學(xué)習(xí)總結(jié)一下這方面的知識(shí)，以及分享一下我們是如何檢測(cè)內(nèi)存泄漏的。我們公司使用開(kāi)源框架LeakCanary來(lái)檢測(cè)內(nèi)存泄漏。

什么是內(nèi)存泄漏？

有些對(duì)象只有有限的生命周期。當(dāng)它們的任務(wù)完成之后，它們將被垃圾回收。如果在對(duì)象的生命周期本該結(jié)束的時(shí)候，這個(gè)對(duì)象還被一系列的引用，這就會(huì)導(dǎo)致內(nèi)存泄漏。隨著泄漏的累積，app將消耗完內(nèi)存。

內(nèi)存泄漏造成什么影響？

它是造成應(yīng)用程序OOM的主要原因之一。由于android系統(tǒng)為每個(gè)應(yīng)用程序分配的內(nèi)存有限，當(dāng)一個(gè)應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時(shí)，就難免會(huì)導(dǎo)致應(yīng)用所需要的內(nèi)存超過(guò)這個(gè)系統(tǒng)分配的內(nèi)存限額，這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。

什么是LeakCanary？

leakCanary是Square開(kāi)源框架，是一個(gè)Android和Java的內(nèi)存泄露檢測(cè)庫(kù)，如果檢測(cè)到某個(gè) activity 有內(nèi)存泄露，LeakCanary 就是自動(dòng)地顯示一個(gè)通知，所以可以把它理解為傻瓜式的內(nèi)存泄露檢測(cè)工具。通過(guò)它可以大幅度減少開(kāi)發(fā)中遇到的oom問(wèn)題，大大提高APP的質(zhì)量。

LeakCanary捕獲常見(jiàn)內(nèi)存泄漏以及解決辦法

1.）錯(cuò)誤使用單例造成的內(nèi)存泄漏

在平時(shí)開(kāi)發(fā)中單例設(shè)計(jì)模式是我們經(jīng)常使用的一種設(shè)計(jì)模式，而在開(kāi)發(fā)中單例經(jīng)常需要持有Context對(duì)象，如果持有的Context對(duì)象生命周期與單例生命周期更短時(shí)，或?qū)е翪ontext無(wú)法被釋放回收，則有可能造成內(nèi)存泄漏，錯(cuò)誤寫法如下：

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() {
  }

}

弱我們?cè)谝粋€(gè)Activity中調(diào)用的，然后關(guān)閉該Activity則會(huì)出現(xiàn)內(nèi)存泄漏。

LoginManager.getInstance(this).dealData();

LeakCanary檢測(cè)結(jié)果如下：

解決辦法要保證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造成的內(nèi)存泄漏

早些年Handler的使用頻率還是蠻高的，它是工作線程與UI線程之間通訊的橋梁，只是現(xiàn)在大量開(kāi)源框架對(duì)其進(jìn)行了封裝，我們這里模擬一種常見(jiàn)使用方式來(lái)模擬內(nèi)存泄漏情形。

public class MainActivity 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);//模擬內(nèi)存泄露
    mHandler.postDelayed(new Runnable() {
      @Override
      public void run() {
        mTextView.setText("lcj");
      }
    }, 3 * 60 * 1000);
    finish();
  }

  @Override
  protected void onDestroy() {
    super.onDestroy();
    LApplication.getRefWatcher().watch(this);
  }
}

上述代碼通過(guò)內(nèi)部類的方式創(chuàng)建mHandler對(duì)象,此時(shí)mHandler會(huì)隱式地持有一個(gè)外部類對(duì)象引用這里就是MainActivity，當(dāng)執(zhí)行postDelayed方法時(shí)，該方法會(huì)將你的Handler裝入一個(gè)Message，并把這條Message推到MessageQueue中，MessageQueue是在一個(gè)Looper線程中不斷輪詢處理消息，那么當(dāng)這個(gè)Activity退出時(shí)消息隊(duì)列中還有未處理的消息或者正在處理消息，而消息隊(duì)列中的Message持有mHandler實(shí)例的引用，mHandler又持有Activity的引用，所以導(dǎo)致該Activity的內(nèi)存資源無(wú)法及時(shí)回收，引發(fā)內(nèi)存泄漏。

LeakCanary檢測(cè)結(jié)果如下：

要想避免Handler引起內(nèi)存泄漏問(wèn)題，需要我們?cè)贏ctivity關(guān)閉退出的時(shí)候的移除消息隊(duì)列中所有消息和所有的Runnable。上述代碼只需在onDestroy()函數(shù)中調(diào)用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);
    //模擬內(nèi)存泄露
    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.)線程造成的內(nèi)存泄漏

最早時(shí)期的時(shí)候處理耗時(shí)操作多數(shù)都是采用Thread+Handler的方式，后來(lái)逐步被AsyncTask取代，直到現(xiàn)在采用RxJava的方式來(lái)處理異步。這里以AsyncTask為例，可能大部分人都會(huì)這樣處理一個(gè)耗時(shí)操作然后通知UI更新結(jié)果：

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;
        //模擬耗時(shí)操作
        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);
  }

}

對(duì)于上面的例子來(lái)說(shuō)，在處理一個(gè)比較耗時(shí)的操作時(shí)，可能還沒(méi)處理結(jié)束MainActivity就執(zhí)行了退出操作，但是此時(shí)AsyncTask依然持有對(duì)MainActivity的引用就會(huì)導(dǎo)致MainActivity無(wú)法釋放回收引發(fā)內(nèi)存泄漏。

LeakCanary檢測(cè)結(jié)果：

如何解決這種內(nèi)存泄漏呢？在使用AsyncTask時(shí)，在Activity銷毀時(shí)候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask.cancel()方法，避免任務(wù)在后臺(tái)執(zhí)行浪費(fèi)資源，進(jìn)而避免內(nèi)存泄漏的發(fā)生。

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;
        //模擬耗時(shí)操作
        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.）非靜態(tài)內(nèi)部類創(chuàng)建靜態(tài)實(shí)例造成的內(nèi)存泄漏

有時(shí)我們需要一個(gè)可以隨著屏幕旋轉(zhuǎn)的Activity，比如視頻播放Activity，這時(shí)我們?yōu)榱朔乐苟啻握{(diào)用onCreate方法導(dǎo)致某些參數(shù)重新初始化，我們一般會(huì)選擇創(chuàng)建一個(gè)內(nèi)部類和一個(gè)靜態(tài)實(shí)例來(lái)保存這些參數(shù)，比如以下實(shí)現(xiàn)：

public class MainActivity extends AppCompatActivity {
  private static Config mConfig;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //模擬內(nèi)存泄露
    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;
    }
  }
}

上述代碼看著沒(méi)有任何問(wèn)題，其實(shí)內(nèi)部類都會(huì)持有一個(gè)外部類引用，這里這個(gè)外部類就是MainActivity，然而內(nèi)部類實(shí)例又是static靜態(tài)變量其生命周期與Application生命周期一樣，所以在MainActivity關(guān)閉的時(shí)候，內(nèi)部類靜態(tài)實(shí)例依然持有對(duì)MainActivity的引用，導(dǎo)致MainActivity無(wú)法被回收釋放，引發(fā)內(nèi)存泄漏。LeakCanary檢測(cè)內(nèi)存泄漏結(jié)果如下：

對(duì)于這種泄漏的解決辦法就是將內(nèi)部類改成靜態(tài)內(nèi)部類，不再持有對(duì)MainActivity的引用即可，修改后的代碼如下：

public class MainActivity extends AppCompatActivity {
  private static Config mConfig;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //模擬內(nèi)存泄露
    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引起的內(nèi)存泄漏

在目前的開(kāi)發(fā)中多多少少會(huì)用到Hybrid開(kāi)發(fā)方式，這樣我們就會(huì)用WebView去承載Html網(wǎng)頁(yè)，就如下面這種方式：

java代碼：

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解析網(wǎng)頁(yè)時(shí)會(huì)申請(qǐng)Native堆內(nèi)存用于保存頁(yè)面元素，當(dāng)頁(yè)面較復(fù)雜時(shí)會(huì)有很大的內(nèi)存占用。如果頁(yè)面包含圖片，內(nèi)存占用會(huì)更嚴(yán)重。并且打開(kāi)新頁(yè)面時(shí)，為了能快速回退，之前頁(yè)面占用的內(nèi)存也不會(huì)釋放。有時(shí)瀏覽十幾個(gè)網(wǎng)頁(yè)，都會(huì)占用幾百兆的內(nèi)存。這樣加載網(wǎng)頁(yè)較多時(shí)，會(huì)導(dǎo)致系統(tǒng)不堪重負(fù)，最終強(qiáng)制關(guān)閉應(yīng)用，也就是出現(xiàn)應(yīng)用閃退或重啟。及時(shí)Activity關(guān)閉時(shí)在onDestroy中調(diào)用如下代碼也是沒(méi)有任何作用。

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

先看下LeakCanary檢測(cè)到的結(jié)果如下：

該如何解決呢？這個(gè)查了不少資料，其中一種就是使用getApplicationgContext作為參數(shù)構(gòu)建WebView，然后動(dòng)態(tài)添加到一個(gè)ViewGroup中，最后退出的時(shí)候調(diào)用webView的銷毀的函數(shù)，雖然也達(dá)到了防止內(nèi)存溢出的效果，但是在有些網(wǎng)頁(yè)彈出時(shí)候需要記住密碼的對(duì)話框的時(shí)候，會(huì)出現(xiàn)Unable to add window -- token null is not for an application 的錯(cuò)誤，所以這里采用的解決辦法是通過(guò)把使用了WebView的Activity(或者Service)放在單獨(dú)的進(jìn)程里。然后在檢測(cè)到應(yīng)用占用內(nèi)存過(guò)大有可能被系統(tǒng)干掉或者它所在的Activity(或者Service)結(jié)束后，調(diào)用android.os.Process.killProcess(android.os.Process.myPid());，主動(dòng)Kill掉進(jìn)程。由于系統(tǒng)的內(nèi)存分配是以進(jìn)程為準(zhǔn)的，進(jìn)程關(guān)閉后，系統(tǒng)會(huì)自動(dòng)回收所有內(nèi)存。

修改后的代碼如下：

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中對(duì)應(yīng)的activity配置如下：

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

6.）資源未關(guān)閉造成的內(nèi)存泄漏

對(duì)于使用了BraodcastReceiver，ContentObserver，F(xiàn)ile，Cursor，Stream，Bitmap等資源的使用，應(yīng)該在Activity銷毀時(shí)及時(shí)關(guān)閉或者注銷，否則這些資源將不會(huì)被回收，造成內(nèi)存泄漏。例如獲取媒體庫(kù)圖片地址代碼在查詢結(jié)束的時(shí)候一定要調(diào)用

Cursor 的關(guān)閉方法防止造成內(nèi)存泄漏。

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); //這里獲取到的就是圖片存儲(chǔ)的位置信息
        Log.e("LeakCanary", "photoPath---->" + photoPath);
      }
      cursor.close();
    }

總結(jié)：

以上就是通過(guò)LeakCanary檢測(cè)到的內(nèi)存泄漏情況以及解決辦法。希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: