嗨，我會(huì)定期分享Android知識(shí)點(diǎn)及解析，還會(huì)不斷更新的BATJ面試專(zhuān)題，歡迎大家前來(lái)探討交流，如有好的文章也歡迎投稿，如果喜歡的朋友也歡迎關(guān)注。

成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括海倫網(wǎng)站建設(shè)、海倫網(wǎng)站制作、海倫網(wǎng)頁(yè)制作以及海倫網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專(zhuān)注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，海倫網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶(hù)以成都為中心已經(jīng)輻射到海倫省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶(hù)的支持與信任！

前言

對(duì)于內(nèi)存泄漏，我想大家在開(kāi)發(fā)中肯定都遇到過(guò)，只不過(guò)內(nèi)存泄漏對(duì)我們來(lái)說(shuō)并不是可見(jiàn)的，因?yàn)樗窃诙阎谢顒?dòng)，而要想檢測(cè)程序中是否有內(nèi)存泄漏的產(chǎn)生，通常我們可以借助LeakCanary、MAT等工具來(lái)檢測(cè)應(yīng)用程序是否存在內(nèi)存泄漏，MAT是一款強(qiáng)大的內(nèi)存分析工具，功能繁多而復(fù)雜，而LeakCanary則是由Square開(kāi)源的一款輕量第三方內(nèi)存泄漏檢測(cè)工具，當(dāng)它檢測(cè)到程序中有內(nèi)存泄漏的產(chǎn)生時(shí)，它將以最直觀(guān)的方式告訴我們?cè)搩?nèi)存泄漏是由誰(shuí)產(chǎn)生的和該內(nèi)存泄漏導(dǎo)致誰(shuí)泄漏了而不能回收，供我們復(fù)查。

內(nèi)存泄漏

為什么會(huì)產(chǎn)生內(nèi)存泄漏？

當(dāng)一個(gè)對(duì)象已經(jīng)不需要再使用了，本該被回收時(shí)，而有另外一個(gè)正在使用的對(duì)象持有它的引用從而導(dǎo)致它不能被回收，這導(dǎo)致本該被回收的對(duì)象不能被回收而停留在堆內(nèi)存中，這就產(chǎn)生了內(nèi)存泄漏。

內(nèi)存泄漏對(duì)程序的影響？

內(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。

Android中常見(jiàn)的內(nèi)存泄漏匯總

單例造成的內(nèi)存泄漏

單例模式非常受開(kāi)發(fā)者的喜愛(ài)，不過(guò)使用的不恰當(dāng)?shù)脑?huà)也會(huì)造成內(nèi)存泄漏，由于單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長(zhǎng)，這就說(shuō)明了如果一個(gè)對(duì)象已經(jīng)不需要使用了，而單例對(duì)象還持有該對(duì)象的引用，那么這個(gè)對(duì)象將不能被正?；厥?，這就導(dǎo)致了內(nèi)存泄漏。
如下這個(gè)典例：

????private?static?AppManager?instance;????private?Context?context;????private?AppManager(Context?context)?{????????this.context?=?context;
????}????public?static?AppManager?getInstance(Context?context)?{????????if?(instance?!=?null)?{
????????????instance?=?new?AppManager(context);
????????}????????return?instance;
????}
}

這是一個(gè)普通的單例模式，當(dāng)創(chuàng)建這個(gè)單例的時(shí)候，由于需要傳入一個(gè)Context，所以這個(gè)Context的生命周期的長(zhǎng)短至關(guān)重要：

1、傳入的是Application的Context：?這將沒(méi)有任何問(wèn)題，因?yàn)閱卫纳芷诤虯pplication的一樣長(zhǎng)
2、傳入的是Activity的Context：?當(dāng)這個(gè)Context所對(duì)應(yīng)的Activity退出時(shí)，由于該Context和Activity的生命周期一樣長(zhǎng)（Activity間接繼承于Context），所以當(dāng)前Activity退出時(shí)它的內(nèi)存并不會(huì)被回收，因?yàn)閱卫龑?duì)象持有該Activity的引用。
所以正確的單例應(yīng)該修改為下面這種方式：

????private?static?AppManager?instance;????private?Context?context;????private?AppManager(Context?context)?{????????this.context?=?context.getApplicationContext();
????}????public?static?AppManager?getInstance(Context?context)?{????????if?(instance?!=?null)?{
????????????instance?=?new?AppManager(context);
????????}????????return?instance;
????}
}

這樣不管傳入什么Context最終將使用Application的Context，而單例的生命周期和應(yīng)用的一樣長(zhǎng)，這樣就防止了內(nèi)存泄漏。

非靜態(tài)內(nèi)部類(lèi)創(chuàng)建靜態(tài)實(shí)例造成的內(nèi)存泄漏

有的時(shí)候我們可能會(huì)在啟動(dòng)頻繁的Activity中，為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源，可能會(huì)出現(xiàn)這種寫(xiě)法：

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

這樣就在Activity內(nèi)部創(chuàng)建了一個(gè)非靜態(tài)內(nèi)部類(lèi)的單例，每次啟動(dòng)Activity時(shí)都會(huì)使用該單例的數(shù)據(jù)，這樣雖然避免了資源的重復(fù)創(chuàng)建，不過(guò)這種寫(xiě)法卻會(huì)造成內(nèi)存泄漏;

因?yàn)榉庆o態(tài)內(nèi)部類(lèi)默認(rèn)會(huì)持有外部類(lèi)的引用，而又使用了該非靜態(tài)內(nèi)部類(lèi)創(chuàng)建了一個(gè)靜態(tài)的實(shí)例，該實(shí)例的生命周期和應(yīng)用的一樣長(zhǎng)，這就導(dǎo)致了該靜態(tài)實(shí)例一直會(huì)持有該Activity的引用，導(dǎo)致Activity的內(nèi)存資源不能正?；厥?。正確的做法為：
將該內(nèi)部類(lèi)設(shè)為靜態(tài)內(nèi)部類(lèi)或?qū)⒃搩?nèi)部類(lèi)抽取出來(lái)封裝成一個(gè)單例，如果需要使用Context，請(qǐng)使用ApplicationContext

Handler造成的內(nèi)存泄漏

Handler的使用造成的內(nèi)存泄漏問(wèn)題應(yīng)該說(shuō)最為常見(jiàn)了，平時(shí)在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請(qǐng)求回調(diào)等api都應(yīng)該會(huì)借助Handler來(lái)處理，對(duì)于Handler的使用代碼編寫(xiě)一不規(guī)范即有可能造成內(nèi)存泄漏，如下示例：

????private?Handler?mHandler?=?new?Handler()?{????????@Override
????????public?void?handleMessage(Message?msg)?{????????????//...
????????}
????};????@Override
????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState);
????????setContentView(R.layout.activity_main);
????????loadData();
????}????private?void?loadData(){????????//...request
????????Message?message?=?Message.obtain();
????????mHandler.sendMessage(message);
????}
}

這種創(chuàng)建Handler的方式會(huì)造成內(nèi)存泄漏，由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類(lèi)的實(shí)例?，所以它持有外部類(lèi)Activity的引用，我們知道消息隊(duì)列是在一個(gè)Looper線(xiàn)程中不斷輪詢(xún)處理消息，那么當(dāng)這個(gè)Activity退出時(shí)消息隊(duì)列中還有未處理的消息或者正在處理消息，而消息隊(duì)列中的Message持有mHandler實(shí)例的引用，mHandler又持有Activity的引用，所以導(dǎo)致該Activity的內(nèi)存資源無(wú)法及時(shí)回收，引發(fā)內(nèi)存泄漏，所以另外一種做法為：

public?class?MainActivity?extends?AppCompatActivity?{????private?MyHandler?mHandler?=?new?MyHandler(this);????private?TextView?mTextView?;????private?static?class?MyHandler?extends?Handler?{????????private?WeakReference?reference;????????public?MyHandler(Context?context)?{
????????????reference?=?new?WeakReference<>(context);
????????}????????@Override
????????public?void?handleMessage(Message?msg)?{
????????????MainActivity?activity?=?(MainActivity)?reference.get();????????????if(activity?!=?null){
????????????????activity.mTextView.setText("");
????????????}
????????}
????}????@Override
????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState);
????????setContentView(R.layout.activity_main);
????????mTextView?=?(TextView)findViewById(R.id.textview);
????????loadData();
????}????private?void?loadData()?{????????//...request
????????Message?message?=?Message.obtain();
????????mHandler.sendMessage(message);
????}
}

創(chuàng)建一個(gè)靜態(tài)Handler內(nèi)部類(lèi)，然后對(duì)Handler持有的對(duì)象使用弱引用，這樣在回收時(shí)也可以回收Handler持有的對(duì)象，這樣雖然避免了Activity泄漏,不過(guò)Looper線(xiàn)程的消息隊(duì)列中還是可能會(huì)有待處理的消息，所以我們?cè)贏ctivity的Destroy時(shí)或者Stop時(shí)應(yīng)該移除消息隊(duì)列中的消息，更準(zhǔn)確的做法如下：

public?class?MainActivity?extends?AppCompatActivity?{????private?MyHandler?mHandler?=?new?MyHandler(this);????private?TextView?mTextView?;????private?static?class?MyHandler?extends?Handler?{????????private?WeakReference?reference;????????public?MyHandler(Context?context)?{
????????????reference?=?new?WeakReference<>(context);
????????}????????@Override
????????public?void?handleMessage(Message?msg)?{
????????????MainActivity?activity?=?(MainActivity)?reference.get();????????????if(activity?!=?null){
????????????????activity.mTextView.setText("");
????????????}
????????}
????}????@Override
????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState);
????????setContentView(R.layout.activity_main);
????????mTextView?=?(TextView)findViewById(R.id.textview);
????????loadData();
????}????private?void?loadData()?{????????//...request
????????Message?message?=?Message.obtain();
????????mHandler.sendMessage(message);
????}????@Override
????protected?void?onDestroy()?{????????super.onDestroy();
????????mHandler.removeCallbacksAndMessages(null);
????}
}

使用mHandler.removeCallbacksAndMessages(null);是移除消息隊(duì)列中所有消息和所有的Runnable。當(dāng)然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();來(lái)移除指定的Runnable和Message。

線(xiàn)程造成的內(nèi)存泄漏

對(duì)于線(xiàn)程造成的內(nèi)存泄漏，也是平時(shí)比較常見(jiàn)的，如下這兩個(gè)示例可能每個(gè)人都這樣寫(xiě)過(guò)：

//——————test1
????????new?AsyncTask()?{????????????@Override
????????????protected?Void?doInBackground(Void...?params)?{
????????????????SystemClock.sleep(10000);????????????????return?null;
????????????}
????????}.execute();//——————test2
????????new?Thread(new?Runnable()?{????????????@Override
????????????public?void?run()?{
????????????????SystemClock.sleep(10000);
????????????}
????????}).start();

上面的異步任務(wù)和Runnable都是一個(gè)匿名內(nèi)部類(lèi)，因此它們對(duì)當(dāng)前Activity都有一個(gè)隱式引用。如果Activity在銷(xiāo)毀之前，任務(wù)還未完成；
那么將導(dǎo)致Activity的內(nèi)存資源無(wú)法回收，造成內(nèi)存泄漏。正確的做法還是使用靜態(tài)內(nèi)部類(lèi)的方式，如下：

????static?class?MyAsyncTask?extends?AsyncTask?{????????private?WeakReference?weakReference;????????public?MyAsyncTask(Context?context)?{
????????????weakReference?=?new?WeakReference<>(context);
????????}????????@Override
????????protected?Void?doInBackground(Void...?params)?{
????????????SystemClock.sleep(10000);????????????return?null;
????????}????????@Override
????????protected?void?onPostExecute(Void?aVoid)?{????????????super.onPostExecute(aVoid);
????????????MainActivity?activity?=?(MainActivity)?weakReference.get();????????????if?(activity?!=?null)?{????????????????//...
????????????}
????????}
????}????static?class?MyRunnable?implements?Runnable{????????@Override
????????public?void?run()?{
????????????SystemClock.sleep(10000);
????????}
????}//——————
????new?Thread(new?MyRunnable()).start();????new?MyAsyncTask(this).execute();

這樣就避免了Activity的內(nèi)存資源泄漏，當(dāng)然在Activity銷(xiāo)毀時(shí)候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask::cancel()，避免任務(wù)在后臺(tái)執(zhí)行浪費(fèi)資源。

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

對(duì)于使用了BraodcastReceiver，ContentObserver，F(xiàn)ile，Cursor，Stream，Bitmap等資源的使用，應(yīng)該在Activity銷(xiāo)毀時(shí)及時(shí)關(guān)閉或者注銷(xiāo)，否則這些資源將不會(huì)被回收，造成內(nèi)存泄漏。

一些建議

1. 對(duì)于生命周期比Activity長(zhǎng)的對(duì)象如果需要應(yīng)該使用ApplicationContext

2. 在涉及到Context時(shí)先考慮ApplicationContext，當(dāng)然它并不是萬(wàn)能的，對(duì)于有些地方則必須使用Activity的Context，對(duì)于Application，Service，Activity三者的Context的應(yīng)用場(chǎng)景如下：

   

其中：NO1表示Application和Service可以啟動(dòng)一個(gè)Activity，不過(guò)需要?jiǎng)?chuàng)建一個(gè)新的task任務(wù)隊(duì)列。而對(duì)于Dialog而言，只有在Activity中才能創(chuàng)建。

1. 對(duì)于需要在靜態(tài)內(nèi)部類(lèi)中使用非靜態(tài)外部成員變量（如：Context、View )，可以在靜態(tài)內(nèi)部類(lèi)中使用弱引用來(lái)引用外部類(lèi)的變量來(lái)避免內(nèi)存泄漏

2. 對(duì)于生命周期比Activity長(zhǎng)的內(nèi)部類(lèi)對(duì)象，并且內(nèi)部類(lèi)中使用了外部類(lèi)的成員變量，可以這樣做避免內(nèi)存泄漏：

• 將內(nèi)部類(lèi)改為靜態(tài)內(nèi)部類(lèi)

• 靜態(tài)內(nèi)部類(lèi)中使用弱引用來(lái)引用外部類(lèi)的成員變量

1. 對(duì)于不再需要使用的對(duì)象，顯示的將其賦值為null，比如使用完Bitmap后先調(diào)用recycle()，再賦為null。

2. 保持對(duì)對(duì)象生命周期的敏感，特別注意單例、靜態(tài)對(duì)象、全局性集合等的生命周期。

覺(jué)得文章不錯(cuò)的朋友幫忙點(diǎn)點(diǎn)贊加關(guān)注哦，有什么問(wèn)題的話(huà)也歡迎大家前來(lái)探討交流。