內存泄漏優化

時間 2019-11-16

標籤內存泄漏優化简体版

原文原文鏈接

目錄介紹：

1.什麼是內存泄漏
2.內存泄漏形成什麼影響
3.內存泄漏檢測的工具備哪些
4.關於Leakcanary使用介紹
5.Leakcanary捕捉常見的內存泄漏及解決辦法php
- 5.0.1 錯誤使用單例形成的內存泄漏
- 5.0.2 錯誤使用靜態變量，致使引用後沒法銷燬
- 5.0.3 [常見]Handler使用不當形成的內存泄漏
- 5.0.4 線程形成的內存泄漏[比較少見]
- 5.0.5 非靜態內部類建立靜態實例形成的內存泄漏
- 5.0.6 不須要用的監聽未移除會發生內存泄露
- 5.0.7 [常見]資源未關閉形成的內存泄漏
- 5.0.8 未註銷EventBus致使的內存泄漏
- 5.0.9 [常見]持有activity引用未被釋放致使內存泄漏
- 5.1.0 靜態集合使用不當致使的內存泄漏
- 5.1.1 動畫資源未釋放致使內存泄漏
- 5.1.2 系統bug之InputMethodManager致使內存泄漏
6.其餘建議android
- 6.0.1 儘可能避免使用 static 成員變量
7.版本更新git
- v1.0.0 更新於2016年3月19日
- v1.1.0 更新於2017年7月8日
- v1.2.0 更新於2018年5月3日
- v1.3.0 更新於2018年9月18日

1.什麼是內存泄漏？

一些對象有着有限的聲明週期，當這些對象所要作的事情完成了，咱們但願它們會被垃圾回收器回收掉。可是若是有一系列對這個對象的引用存在，那麼在咱們期待這個對象生命週期結束時被垃圾回收器回收的時候，它是不會被回收的。它還會佔用內存，這就形成了內存泄露。持續累加，內存很快被耗盡。
好比：當Activity的onDestroy()方法被調用後，Activity以及它涉及到的View和相關的Bitmap都應該被回收掉。可是，若是有一個後臺線程持有這個Activity的引用，那麼該Activity所佔用的內存就不能被回收，這最終將會致使內存耗盡引起OOM而讓應用crash掉。

2.內存泄漏會形成什麼影響？

它是形成應用程序OOM的主要緣由之一。因爲android系統爲每一個應用程序分配的內存有限，當一個應用中產生的內存泄漏比較多時，就不免會致使應用所須要的內存超過這個系統分配的內存限額，這就

3.內存泄漏檢測的工具備哪些

最多見的是：Leakcanary

4.關於Leakcanary使用介紹

leakCanary是Square開源框架，是一個Android和Java的內存泄露檢測庫，若是檢測到某個 activity 有內存泄露，LeakCanary 就是自動地顯示一個通知，因此能夠把它理解爲傻瓜式的內存泄露檢測工具。經過它能夠大幅度減小開發中遇到的oom問題，大大提升APP的質量。
關於如何配置，這個就不說呢，網上有步驟

5.Leakcanary捕捉常見的內存泄漏及解決辦法

5.0.1 錯誤使用單例形成的內存泄漏

在平時開發中單例設計模式是咱們常用的一種設計模式，而在開發中單例常常須要持有Context對象，若是持有的Context對象生命週期與單例生命週期更短時，或致使Context沒法被釋放回收，則有可能形成內存泄漏，錯誤寫法以下：

問題引發內存泄漏代碼github

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

    private LoginManager(Context context) {
        this.mContext = 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() {}
}

使用場景segmentfault
- 在一個Activity中調用的，而後關閉該Activity則會出現內存泄漏。
```
LoginManager.getInstance(this).dealData();
```
看看報錯截圖設計模式
解決辦法：網絡
- 要保證Context和AppLication的生命週期同樣，修改後代碼以下：
- this.mContext = context.getApplicationContext();
- 一、若是此時傳入的是 Application 的 Context，由於 Application 的生命週期就是整個應用的生命週期，因此這將沒有任何問題。
- 二、若是此時傳入的是 Activity 的 Context，當這個 Context 所對應的 Activity 退出時，因爲該 Context 的引用被單例對象所持有，其生命週期等於整個應用程序的生命週期，因此當前 Activity 退出時它的內存並不會被回收，這就形成泄漏了。

5.0.2 錯誤使用靜態變量，致使引用後沒法銷燬

在平時開發中，有時候咱們建立了一個工具類。好比分享工具類，十分方便多處調用，所以使用靜態方法是十分方便的。可是建立的對象，建議不要全局化，全局化的變量必須加上static。這樣會引發內存泄漏！
問題代碼架構

使用場景app

在Activity中引用後，關閉該Activity會致使內存泄漏

DoShareUtil.showFullScreenShareView(PNewsContentActivity.this, title, title, shareurl, logo);

查看報錯框架
解決辦法
- 靜態方法中，建立對象或變量，不要全局化，全局化後的變量或者對象會致使內存泄漏；popMenuView和popMenu都不要全局化

知識延伸

非靜態內部類，靜態實例化
public class MyActivity extends AppCompatActivity {
    //靜態成員變量
    public static InnerClass innerClass = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_my);
        innerClass = new InnerClass();
    }

    class InnerClass {
        public void doSomeThing() {}
    }
}
這裏內部類InnerClass隱式的持有外部類MyActivity的引用，而在MyActivity的onCreate方法中調用了。
這樣innerClass就會在MyActivity建立的時候是有了他的引用，而innerClass是靜態類型的不會被垃圾回收，
MyActivity在執行onDestory方法的時候因爲被innerClass持有了引用而沒法被回收，因此這樣MyActivity就老是被innerClass持有而沒法回收形成內存泄露。

靜態變量引用不當會致使內存泄漏
靜態變量Activity和View會致使內存泄漏，在下面這段代碼中對Activity的Context和TextView設置爲靜態對象，從而產生內存泄漏。
public class MainActivity extends AppCompatActivity {

    private static Context context;
    private static TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        context = this;
        textView = new TextView(this);
    }
}

5.0.3 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("yangchong");
            }
        }, 2000);
    }
}

形成內存泄漏緣由分析
- 上述代碼經過內部類的方式建立mHandler對象,此時mHandler會隱式地持有一個外部類對象引用這裏就是MainActivity，當執行postDelayed方法時，該方法會將你的Handler裝入一個Message，並把這條Message推到MessageQueue中，MessageQueue是在一個Looper線程中不斷輪詢處理消息，那麼當這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息，而消息隊列中的Message持有mHandler實例的引用，mHandler又持有Activity的引用，因此致使該Activity的內存資源沒法及時回收，引起內存泄漏。
查看報錯結果以下：
解決方案
- 第一種解決辦法
  - 要想避免Handler引發內存泄漏問題，須要咱們在Activity關閉退出的時候的移除消息隊列中全部消息和全部的Runnable。
  - 上述代碼只需在onDestroy()函數中調用mHandler.removeCallbacksAndMessages(null);就好了。

@Override
protected void onDestroy() {
    super.onDestroy();
    if(handler!=null){
        handler.removeCallbacksAndMessages(null);
        handler = null;
    }
}

* 第二種解決方案
    - 使用弱引用解決handler內存泄漏問題
```
public class SampleActivity 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);
    private static final Runnable sRunnable = new Runnable() {
        @Override
        public void run() { /* ... */ }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
        finish();
    }
}

即推薦使用靜態內部類 + WeakReference 這種方式。每次使用前注意判空。
```

5.0.4 線程形成的內存泄漏

早時期的時候處理耗時操做多數都是採用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();
    }
}

形成內存泄漏緣由分析
- 在處理一個比較耗時的操做時，可能還沒處理結束MainActivity就執行了退出操做，可是此時AsyncTask依然持有對MainActivity的引用就會致使MainActivity沒法釋放回收引起內存泄漏
查看報錯結果以下：

解決辦法

在使用AsyncTask時，在Activity銷燬時候也應該取消相應的任務AsyncTask.cancel()方法，避免任務在後臺執行浪費資源，進而避免內存泄漏的發生

private void destroyAsyncTask() {
    if (asyncTask != null && !asyncTask.isCancelled()) {
        asyncTask.cancel(true);
    }
    asyncTask = null;
}

@Override
protected void onDestroy() {
    super.onDestroy();
    destroyAsyncTask();
}

5.0.5 非靜態內部類建立靜態實例形成的內存泄漏

有的時候咱們可能會在啓動頻繁的Activity中，爲了不重複建立相同的數據資源，可能會出現這種寫法

問題代碼

private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    if(mResource == null){
        mResource = new TestResource();
    }
}

class TestResource {
     //裏面代碼引用上下文，Activity.this會致使內存泄漏
}

解決辦法
- 將該內部類設爲靜態內部類或將該內部類抽取出來封裝成一個單例，若是須要使用Context，請按照上面推薦的使用Application 的 Context。
分析問題
- 這樣就在Activity內部建立了一個非靜態內部類的單例，每次啓動Activity時都會使用該單例的數據，這樣雖然避免了資源的重複建立，不過這種寫法卻會形成內存泄漏，由於非靜態內部類默認會持有外部類的引用，而該非靜態內部類又建立了一個靜態的實例，該實例的生命週期和應用的同樣長，這就致使了該靜態實例一直會持有該Activity的引用，致使Activity的內存資源不能正常回收。

5.0.6 不須要用的監聽未移除會發生內存泄露

問題代碼

//add監聽，放到集合裏面
tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
    @Override
    public void onWindowFocusChanged(boolean b) {
        //監聽view的加載，view加載出來的時候，計算他的寬高等。
    }
});

解決辦法

//計算完後，必定要移除這個監聽
tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);

注意事項：

tv.setOnClickListener();//監聽執行完回收對象，不用考慮內存泄漏
tv.getViewTreeObserver().addOnWindowFocusChangeListene,add監聽，放到集合裏面，須要考慮內存泄漏

5.0.7 [常見]資源未關閉形成的內存泄漏

BroadcastReceiver，ContentObserver，FileObserver，Cursor，Callback等在 Activity onDestroy 或者某類生命週期結束以後必定要 unregister 或者 close 掉，不然這個 Activity 類會被 system 強引用，不會被內存回收。值得注意的是，關閉的語句必須在finally中進行關閉，不然有可能由於異常未關閉資源，導致activity泄漏。

5.0.7.1 廣播註冊以後沒有被銷燬致使內存泄漏

- 好比咱們在Activity中註冊廣播，若是在Activity銷燬後不取消註冊，那麼這個廣播會一直存在系統中，同上面所說的非靜態內部類同樣持有Activity引用，致使內存泄露。所以註冊廣播後在Activity銷燬後必定要取消註冊。
- 在註冊觀察則模式的時候，若是不及時取消也會形成內存泄露。好比使用Retrofit+RxJava註冊網絡請求的觀察者回調，一樣做爲匿名內部類持有外部引用，因此須要記得在不用或者銷燬的時候取消註冊。
```
public class MeAboutActivity extends BaseActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        this.registerReceiver(mReceiver, new IntentFilter());
    }

    private BroadcastReceiver mReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            // 接收到廣播須要作的邏輯
        }
    };

    @Override
    protected void onDestroy() {
        super.onDestroy();
        this.unregisterReceiver(mReceiver);
    }
}
```

5.0.7.2 資源未關閉致使資源被佔用而內存泄漏

在使用IO、File流或者Sqlite、Cursor等資源時要及時關閉。這些資源在進行讀寫操做時一般都使用了緩衝，若是及時不關閉，這些緩衝對象就會一直被佔用而得不到釋放，以至發生內存泄露。所以咱們在不須要使用它們的時候就及時關閉，以便緩衝能及時獲得釋放，從而避免內存泄露。

5.0.8 未註銷EventBus致使的內存泄漏

直接展現代碼

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_common);
    EventBus.getDefault().register(this);
}

@Subscribe
public void onEvent(MessageEvent msg) {

}

@Override
protected void onDestroy() {
    super.onDestroy();
    //未移除註冊的EventBus
    //EventBus.getDefault().unregister(this);
}

5.0.9 持有activity引用未被釋放致使內存泄漏

5.0.9.1 第一種場景

先看看問題代碼
- 這個是在開發中常常會犯的錯誤，NastyManager.getInstance() 是一個單例，當咱們經過 addListener(this) 將 Activity 做爲 Listener 和 NastyManager 綁定起來的時候，因爲單例和Activity生命週期不一樣，所以銷燬時就會致使內存泄漏。
```
public class LeakActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        NastyManager.getInstance().addListener(this);
    }
}
```

解決辦法：

在你的 Acitivity 被銷燬的時候，將他和 NastyManager 取消掉綁定就好

public class LeakActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        NastyManager.getInstance().addListener(this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        NastyManager.getInstance().removeListener(this);
    }
}

5.0.9.2 第二種場景

先來看看形成內存泄漏的代碼

經過查看Toast類的源碼能夠看到，Toast類內部的mContext指向傳入的Context。而ToastUtils中的toast變量是靜態類型的，其生命週期是與整個應用同樣長的，從而致使activity得不到釋放。所以，對Context的引用不能超過它自己的生命週期。

/**
 * 吐司工具類    避免點擊屢次致使吐司屢次，最後致使Toast就長時間關閉不掉了
 * @param context       注意：這裏若是傳入context會報內存泄漏；傳遞activity..getApplicationContext()
 * @param content       吐司內容
 */
private static Toast toast;
@SuppressLint("ShowToast")
public static void showToast(Context context, String content) {
    if (toast == null) {
        toast = Toast.makeText(context , content, Toast.LENGTH_SHORT);
    } else {
        toast.setText(content);
    }
    toast.show();
}

解決辦法
- 是改成使用 ApplicationContext便可，由於ApplicationContext會隨着應用的存在而存在，而不依賴於Activity的生命週期

5.1.0 靜態集合使用不當致使的內存泄漏

有時候咱們須要把一些對象加入到集合容器（例如ArrayList）中，當再也不須要當中某些對象時，若是不把該對象的引用從集合中清理掉，也會使得GC沒法回收該對象。若是集合是static類型的話，那內存泄漏狀況就會更爲嚴重。所以，當再也不須要某對象時，須要主動將之從集合中移除。

5.1.1 動畫資源未釋放致使內存泄漏

問題代碼

public class LeakActivity extends AppCompatActivity {

    private TextView textView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_leak);
        textView = (TextView)findViewById(R.id.text_view);
        ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(textView,"rotation",0,360);
        objectAnimator.setRepeatCount(ValueAnimator.INFINITE);
        objectAnimator.start();
    }
}

解決辦法
- 在屬性動畫中有一類無限循環動畫，若是在Activity中播放這類動畫而且在onDestroy中去中止動畫，那麼這個動畫將會一直播放下去，這時候Activity會被View所持有，從而致使Activity沒法被釋放。解決此類問題則是須要早Activity中onDestroy去去調用objectAnimator.cancel()來中止動畫。
```
@Override
protected void onDestroy() {
    super.onDestroy();
    mAnimator.cancel();
}
```

5.1.2 系統bug之InputMethodManager致使內存泄漏

每次從MainActivity退出程序時總會報InputMethodManager內存泄漏，緣由系統中的InputMethodManager持有當前MainActivity的引用，致使了MainActivity不能被系統回收，從而致使了MainActivity的內存泄漏。查了不少資料，發現這是 Android SDK中輸入法的一個Bug，在15<=API<=23中都存在，目前Google尚未解決這個Bug。

6.其餘建議

6.0.1 儘可能避免使用 static 成員變量

儘可能避免使用 static 成員變量
- 若是成員變量被聲明爲 static，那咱們都知道其生命週期將與整個app進程生命週期同樣。這會致使一系列問題，若是你的app進程設計上是長駐內存的，那即便app切到後臺，這部份內存也不會被釋放。按照如今手機app內存管理機制，佔內存較大的後臺進程將優先回收，若是此app作過進程互保保活，那會形成app在後臺頻繁重啓。當手機安裝了你參與開發的app之後一晚上時間手機被消耗空了電量、流量，你的app不得不被用戶卸載或者靜默。
- 架構設計上要思考是否真的有必要這樣作，儘可能避免。若是架構須要這麼設計，那麼此對象的生命週期你有責任管理起來。