Android效能最佳化之利用強大的LeakCanary檢測記憶體流失及解決辦法_Android

來源:互聯網
上載者:User

前言:

最近公司C輪融資成功了,移動團隊準備擴大一下,需要招聘Android開發工程師,陸陸續續面試了幾位Android應聘者,面試過程中聊到效能最佳化中如何避免記憶體流失問題時,很少有人全面的回答上來。所以決定抽空學習總結一下這方面的知識,以及分享一下我們是如何檢測記憶體流失的。我們公司使用開源架構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 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);//類比記憶體泄露    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);  }}

上述代碼通過內部類的方式建立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網頁,就如下面這種方式:

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解析網頁時會申請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檢測到的記憶體流失情況以及解決辦法。希望對大家的學習有所協助,也希望大家多多支援雲棲社區。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.