內(nèi)存泄露優(yōu)化總結(jié)

1脊串、單例導致內(nèi)存泄露

單例模式在Android開發(fā)中會經(jīng)常用到裳擎,但是如果使用不當就會導致內(nèi)存泄露扰路。因為單例的靜態(tài)特性使得它的生命周期同應用的生命周期一樣長桑涎,如果一個對象已經(jīng)沒有用處了,但是單例還持有它的引用逃片,那么在整個應用程序的生命周期它都不能正常被回收屡拨,從而導致內(nèi)存泄露。

public class AppSettings {

private static AppSettings sInstance;

private Context mContext;

private AppSettings(Context context) {

    this.mContext = context;

}

public static AppSettings getInstance(Context context) {

    if(sInstance == null) {

sInstance = new AppSettings(context);

    }

    return sInstance;

}

}

像上面代碼中這樣的單例,如果我們在調(diào)用getInstance(Context context)方法的時候傳入的context參數(shù)是Activity呀狼、Service等上下文裂允,就會導致內(nèi)存泄露。

以Activity為例哥艇,當我們啟動一個Activity绝编,并調(diào)用getInstance(Context context)方法去獲取AppSettings的單例,傳入Activity.this作為context貌踏,這樣AppSettings類的單例sInstance就持有了Activity的引用十饥,當我們退出Activity時,該Activity就沒有用了哩俭,但是因為sIntance作為靜態(tài)單例(在應用程序的整個生命周期中存在)會繼續(xù)持有這個Activity的引用绷跑,導致這個Activity對象無法被回收釋放,這就造成了內(nèi)存泄露凡资。

為了避免這樣單例導致內(nèi)存泄露砸捏,我們可以將context參數(shù)改為全局的上下文:

private AppSettings(Context context) {

this.mContext = context.getApplicationContext();

}

全局的上下文Application Context就是應用程序的上下文,和單例的生命周期一樣長隙赁,這樣就避免了內(nèi)存泄漏垦藏。

單例模式對應應用程序的生命周期,所以我們在構(gòu)造單例的時候盡量避免使用Activity的上下文伞访,而是使用Application的上下文掂骏。

2、****靜態(tài)變量導致內(nèi)存泄露

靜態(tài)變量存儲在方法區(qū)厚掷,它的生命周期從類加載開始弟灼,到整個進程結(jié)束。一旦靜態(tài)變量初始化后冒黑,它所持有的引用只有等到進程結(jié)束才會釋放田绑。

比如下面這樣的情況,在Activity中為了避免重復的創(chuàng)建info抡爹,將sInfo作為靜態(tài)變量:

public class MainActivity extends AppCompatActivity {

private static Info sInfo;

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    if(sInfo != null) {

sInfo = new Info(this);

    }

}

}

class Info {

public Info(Activity activity) {

}

}

Info作為Activity的靜態(tài)成員掩驱,并且持有Activity的引用,但是sInfo作為靜態(tài)變量冬竟,生命周期肯定比Activity長欧穴。所以當Activity退出后,sInfo仍然引用了Activity泵殴,Activity不能被回收涮帘,這就導致了內(nèi)存泄露。

在Android開發(fā)中笑诅,靜態(tài)持有很多時候都有可能因為其使用的生命周期不一致而導致內(nèi)存泄露焚辅,所以我們在新建靜態(tài)持有的變量的時候需要多考慮一下各個成員之間的引用關系映屋,并且盡量少地使用靜態(tài)持有的變量苟鸯,以避免發(fā)生內(nèi)存泄露同蜻。當然,我們也可以在適當?shù)臅r候講靜態(tài)量重置為null早处,使其不再持有引用湾蔓,這樣也可以避免內(nèi)存泄露。

3砌梆、****非靜態(tài)內(nèi)部類導致內(nèi)存泄露

非靜態(tài)內(nèi)部類(包括匿名內(nèi)部類)默認就會持有外部類的引用默责,當非靜態(tài)內(nèi)部類對象的生命周期比外部類對象的生命周期長時,就會導致內(nèi)存泄露咸包。

非靜態(tài)內(nèi)部類導致的內(nèi)存泄露在Android開發(fā)中有一種典型的場景就是使用Handler桃序,很多開發(fā)者在使用Handler是這樣寫的:

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    start();

}

private void start() {

    Message msg = Message.obtain();

msg.what = 1;

    mHandler.sendMessage(msg);

}

privateHandler mHandler = new Handler() {

    @Override

    public void handleMessage(Message msg) {

        if(msg.what == 1) {

            // 做相應邏輯

        }

    }

};

}

也許有人會說,mHandler并未作為靜態(tài)變量持有Activity引用烂瘫,生命周期可能不會比Activity長媒熊,應該不一定會導致內(nèi)存泄露呢,顯然不是這樣的坟比!

熟悉Handler消息機制的都知道芦鳍,mHandler會作為成員變量保存在發(fā)送的消息msg中,即msg持有mHandler的引用葛账,而mHandler是Activity的非靜態(tài)內(nèi)部類實例柠衅,即mHandler持有Activity的引用,那么我們就可以理解為msg間接持有Activity的引用籍琳。msg被發(fā)送后先放到消息隊列MessageQueue中菲宴,然后等待Looper的輪詢處理(MessageQueue和Looper都是與線程相關聯(lián)的,MessageQueue是Looper引用的成員變量趋急,而Looper是保存在ThreadLocal中的)喝峦。那么當Activity退出后,msg可能仍然存在于消息對列MessageQueue中未處理或者正在處理宣谈,那么這樣就會導致Activity無法被回收愈犹,以致發(fā)生Activity的內(nèi)存泄露。

通常在Android開發(fā)中如果要使用內(nèi)部類闻丑,但又要規(guī)避內(nèi)存泄露漩怎,一般都會采用靜態(tài)內(nèi)部類+弱引用的方式。

public class MainActivity extends AppCompatActivity {

private Handler mHandler;

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

mHandler = new MyHandler(this);

    start();

}

private void start() {

    Message msg = Message.obtain();

msg.what = 1;

    mHandler.sendMessage(msg);

}

private static class MyHandler extends Handler {

    private WeakReference<MainActivity> activityWeakReference;

    public MyHandler(MainActivity activity) {

activityWeakReference = new WeakReference<>(activity);

    }

    @Override

    public void handleMessage(Message msg) {

        MainActivity activity = activityWeakReference.get();

        if(activity != null) {

            if(msg.what == 1) {

                // 做相應邏輯

            }

        }

    }

}

}

mHandler通過弱引用的方式持有Activity嗦嗡,當GC執(zhí)行垃圾回收時勋锤,遇到Activity就會回收并釋放所占據(jù)的內(nèi)存單元。這樣就不會發(fā)生內(nèi)存泄露了侥祭。

上面的做法確實避免了Activity導致的內(nèi)存泄露叁执,發(fā)送的msg不再已經(jīng)沒有持有Activity的引用了茄厘,但是msg還是有可能存在消息隊列MessageQueue中,所以更好的是在Activity銷毀時就將mHandler的回調(diào)和發(fā)送的消息給移除掉谈宛。

@Overrideprotected void onDestroy() {

super.onDestroy();

mHandler.removeCallbacksAndMessages(null);

}

非靜態(tài)內(nèi)部類造成內(nèi)存泄露還有一種情況就是使用Thread或者AsyncTask次哈。

比如在Activity中直接new一個子線程Thread:

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    new Thread(new Runnable() {

        @Override

        public void run() {

            // 模擬相應耗時邏輯

            try {

                Thread.sleep(2000);

} catch (InterruptedException e) {

                e.printStackTrace();

            }

        }

    }).start();

}

}

或者直接新建AsyncTask異步任務:

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    new AsyncTask<Void, Void, Void>() {

        @Override

        protected Void doInBackground(Void... params) {

            // 模擬相應耗時邏輯

            try {

                Thread.sleep(2000);

} catch (InterruptedException e) {

                e.printStackTrace();

            }

            return null;

        }

    }.execute();

}

}

很多初學者都會像上面這樣新建線程和異步任務,殊不知這樣的寫法非常地不友好吆录,這種方式新建的子線程Thread和AsyncTask都是匿名內(nèi)部類對象窑滞,默認就隱式的持有外部Activity的引用,導致Activity內(nèi)存泄露恢筝。要避免內(nèi)存泄露的話還是需要像上面Handler一樣使用靜態(tài)內(nèi)部類+弱應用的方式(代碼就不列了哀卫,參考上面Hanlder的正確寫法)。

4撬槽、****未取消注冊或回調(diào)導致內(nèi)存泄露

比如我們在Activity中注冊廣播此改,如果在Activity銷毀后不取消注冊,那么這個剛播會一直存在系統(tǒng)中侄柔,同上面所說的非靜態(tài)內(nèi)部類一樣持有Activity引用共啃,導致內(nèi)存泄露。因此注冊廣播后在Activity銷毀后一定要取消注冊勋拟。

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    this.registerReceiver(mReceiver, new IntentFilter());

}

privateBroadcastReceiver mReceiver = new BroadcastReceiver() {

    @Override

    public void onReceive(Context context, Intent intent) {

        // 接收到廣播需要做的邏輯

    }

};

@Override

protected void onDestroy() {

    super.onDestroy();

    this.unregisterReceiver(mReceiver);

}

}

在注冊觀察則模式的時候勋磕,如果不及時取消也會造成內(nèi)存泄露。比如使用Retrofit+RxJava注冊網(wǎng)絡請求的觀察者回調(diào)敢靡,同樣作為匿名內(nèi)部類持有外部引用挂滓,所以需要記得在不用或者銷毀的時候取消注冊。

5啸胧、****Timer和TimerTask導致內(nèi)存泄露

Timer和TimerTask在Android中通常會被用來做一些計時或循環(huán)任務赶站,比如實現(xiàn)無限輪播的ViewPager:

public class MainActivity extends AppCompatActivity {

private ViewPager mViewPager;

private PagerAdapter mAdapter;

private Timer mTimer;

private TimerTask mTimerTask;

@Override

protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    init();

mTimer.schedule(mTimerTask, 3000, 3000);

}

private void init() {

    mViewPager = (ViewPager) findViewById(R.id.view_pager);

mAdapter = new ViewPagerAdapter();

    mViewPager.setAdapter(mAdapter);

mTimer = new Timer();

mTimerTask = new TimerTask() {

        @Override

        public void run() {

            MainActivity.this.runOnUiThread(new Runnable() {

                @Override

                public void run() {

                    loopViewpager();

                }

            });

        }

    };

}

private void loopViewpager() {

    if(mAdapter.getCount() > 0) {

        int curPos = mViewPager.getCurrentItem();

        curPos = (++curPos) % mAdapter.getCount();

        mViewPager.setCurrentItem(curPos);

    }

}

private void stopLoopViewPager() {

    if(mTimer != null) {

        mTimer.cancel();

        mTimer.purge();

mTimer = null;

    }

    if(mTimerTask != null) {

        mTimerTask.cancel();

mTimerTask = null;

    }

}

@Override

protected void onDestroy() {

    super.onDestroy();

    stopLoopViewPager();

}

}

當我們Activity銷毀的時,有可能Timer還在繼續(xù)等待執(zhí)行TimerTask纺念,它持有Activity的引用不能被回收贝椿,因此當我們Activity銷毀的時候要立即cancel掉Timer和TimerTask,以避免發(fā)生內(nèi)存泄漏陷谱。

5烙博、****集合中的對象未清理造成內(nèi)存泄露

這個比較好理解,如果一個對象放入到ArrayList烟逊、HashMap等集合中渣窜,這個集合就會持有該對象的引用。當我們不再需要這個對象時宪躯,也并沒有將它從集合中移除乔宿,這樣只要集合還在使用(而此對象已經(jīng)無用了),這個對象就造成了內(nèi)存泄露访雪。并且如果集合被靜態(tài)引用的話详瑞,集合里面那些沒有用的對象更會造成內(nèi)存泄露了掂林。所以在使用集合時要及時將不用的對象從集合remove,或者clear集合坝橡,以避免內(nèi)存泄漏泻帮。

6、****資源未關閉或釋放導致內(nèi)存泄露

在使用IO驳庭、File流或者Sqlite刑顺、Cursor等資源時要及時關閉。這些資源在進行讀寫操作時通常都使用了緩沖饲常,如果及時不關閉,這些緩沖對象就會一直被占用而得不到釋放狼讨,以致發(fā)生內(nèi)存泄露贝淤。因此我們在不需要使用它們的時候就及時關閉,以便緩沖能及時得到釋放政供,從而避免內(nèi)存泄露播聪。

7、****屬性動畫造成內(nèi)存泄露

動畫同樣是一個耗時任務布隔,比如在Activity中啟動了屬性動畫(ObjectAnimator)离陶,但是在銷毀的時候,沒有調(diào)用cancle方法衅檀,雖然我們看不到動畫了招刨,但是這個動畫依然會不斷地播放下去,動畫引用所在的控件哀军,所在的控件引用Activity沉眶,這就造成Activity無法正常釋放。因此同樣要在Activity銷毀的時候cancel掉屬性動畫杉适,避免發(fā)生內(nèi)存泄漏谎倔。

@Overrideprotected void onDestroy() {

super.onDestroy();

mAnimator.cancel();

}

8、****WebView造成內(nèi)存泄露

關于WebView的內(nèi)存泄露猿推,因為WebView在加載網(wǎng)頁后會長期占用內(nèi)存而不能被釋放片习,因此我們在Activity銷毀后要調(diào)用它的destory()方法來銷毀它以釋放內(nèi)存。

另外在查閱WebView內(nèi)存泄露相關資料時看到這種情況:

Webview下面的Callback持有Activity引用蹬叭,造成Webview內(nèi)存無法釋放藕咏,即使是調(diào)用了Webview.destory()等方法都無法解決問題(Android5.1之后)。

最終的解決方案是:在銷毀WebView之前需要先將WebView從父容器中移除具垫,然后在銷毀WebView侈离。詳細分析過程請參考這篇文章:<u>WebView內(nèi)存泄漏解決方法</u>

@Overrideprotected void onDestroy() {

super.onDestroy();

// 先從父控件中移除WebView

mWebViewContainer.removeView(mWebView);

mWebView.stopLoading();

mWebView.getSettings().setJavaScriptEnabled(false);

mWebView.clearHistory();

mWebView.removeAllViews();

mWebView.destroy();

}

總結(jié)

內(nèi)存泄露在Android內(nèi)存優(yōu)化是一個比較重要的一個方面筝蚕,很多時候程序中發(fā)生了內(nèi)存泄露我們不一定就能注意到卦碾,所有在編碼的過程要養(yǎng)成良好的習慣铺坞。總結(jié)下來只要做到以下這幾點就能避免大多數(shù)情況的內(nèi)存泄漏:

構(gòu)造單例的時候盡量別用Activity的引用洲胖; 靜態(tài)引用時注意應用對象的置空或者少用靜態(tài)引用济榨; 使用靜態(tài)內(nèi)部類+軟引用代替非靜態(tài)內(nèi)部類; 及時取消廣播或者觀察者注冊绿映; 耗時任務擒滑、屬性動畫在Activity銷毀時記得cancel; 文件流叉弦、Cursor等資源及時關閉丐一; Activity銷毀時WebView的移除和銷毀。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末淹冰,一起剝皮案震驚了整個濱河市库车,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌樱拴,老刑警劉巖柠衍,帶你破解...
    沈念sama閱讀 222,729評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異晶乔,居然都是意外死亡珍坊,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,226評論 3 399
  • 文/潘曉璐 我一進店門正罢,熙熙樓的掌柜王于貴愁眉苦臉地迎上來阵漏,“玉大人,你說我怎么就攤上這事腺怯「し梗” “怎么了?”我有些...
    開封第一講書人閱讀 169,461評論 0 362
  • 文/不壞的土叔 我叫張陵呛占,是天一觀的道長虑乖。 經(jīng)常有香客問我,道長晾虑,這世上最難降的妖魔是什么疹味? 我笑而不...
    開封第一講書人閱讀 60,135評論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮帜篇,結(jié)果婚禮上糙捺,老公的妹妹穿的比我還像新娘。我一直安慰自己笙隙,他們只是感情好洪灯,可當我...
    茶點故事閱讀 69,130評論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著竟痰,像睡著了一般签钩。 火紅的嫁衣襯著肌膚如雪掏呼。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,736評論 1 312
  • 那天铅檩,我揣著相機與錄音憎夷,去河邊找鬼。 笑死昧旨,一個胖子當著我的面吹牛拾给,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播兔沃,決...
    沈念sama閱讀 41,179評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼蒋得,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了粘拾?” 一聲冷哼從身側(cè)響起窄锅,我...
    開封第一講書人閱讀 40,124評論 0 277
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎缰雇,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體追驴,經(jīng)...
    沈念sama閱讀 46,657評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡械哟,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,723評論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了殿雪。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片暇咆。...
    茶點故事閱讀 40,872評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖丙曙,靈堂內(nèi)的尸體忽然破棺而出爸业,到底是詐尸還是另有隱情,我是刑警寧澤亏镰,帶...
    沈念sama閱讀 36,533評論 5 351
  • 正文 年R本政府宣布扯旷,位于F島的核電站,受9級特大地震影響索抓,放射性物質(zhì)發(fā)生泄漏钧忽。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 42,213評論 3 336
  • 文/蒙蒙 一逼肯、第九天 我趴在偏房一處隱蔽的房頂上張望耸黑。 院中可真熱鬧,春花似錦篮幢、人聲如沸大刊。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,700評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽缺菌。三九已至葫辐,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間男翰,已是汗流浹背另患。 一陣腳步聲響...
    開封第一講書人閱讀 33,819評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留蛾绎,地道東北人昆箕。 一個月前我還...
    沈念sama閱讀 49,304評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像租冠,于是被迫代替她去往敵國和親鹏倘。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,876評論 2 361

推薦閱讀更多精彩內(nèi)容