在Android開(kāi)發(fā)過(guò)程中，我們經(jīng)常碰到的情況就是在我們不清楚為什么情況下，程序突然出現(xiàn)Crash了。其中有一類日志相信大家都經(jīng)常碰到過(guò)，這類日志就是OOM相關(guān)的日志。這類日志除了我們知道的Bitmap操作的時(shí)候會(huì)經(jīng)常導(dǎo)致，還有一種隱藏的較深的原因就是內(nèi)存泄露（Memory Leak）。

內(nèi)存泄露產(chǎn)生原因和影響： 原因：當(dāng)一個(gè)Object不再需要的時(shí)候，本該被GC回收時(shí)，但是因?yàn)榱硪粋€(gè)正在使用的Object持有它導(dǎo)致不能正常的被回收，本該被回收的對(duì)象不能回收，還存留在堆內(nèi)存中，此時(shí)就產(chǎn)生了內(nèi)存泄露。影響：Android系統(tǒng)能夠?yàn)槊總€(gè)應(yīng)用程序分配的內(nèi)存是有限的，當(dāng)一個(gè)應(yīng)用程序中產(chǎn)生的內(nèi)存泄露過(guò)多的時(shí)候，會(huì)難免導(dǎo)致應(yīng)用程序需要的內(nèi)存超過(guò)限額而導(dǎo)致內(nèi)存溢出使得應(yīng)用程序崩潰。 內(nèi)存泄露的檢測(cè)方式

推薦使用 LeakCanary 工具來(lái)檢測(cè)應(yīng)用程序是否存在內(nèi)存泄露。LeakCanary是由 Square 開(kāi)源的一款輕量級(jí)的第三方內(nèi)存泄漏檢測(cè)工具，當(dāng)檢測(cè)到程序中產(chǎn)生內(nèi)存泄漏時(shí)，它將以最直觀的方式告訴我們哪里產(chǎn)生了內(nèi)存泄漏和導(dǎo)致誰(shuí)泄漏了而不能被回收。

如何避免內(nèi)存泄露

1、合理使用單例模式。

單例的靜態(tài)特性使得其生命周期和應(yīng)用的生命周期一樣長(zhǎng)。

如圖，我們先聲明一個(gè)單例對(duì)象：

解決方案：

2、使用資源時(shí)注意資源的關(guān)閉

一般情況下，容易產(chǎn)生內(nèi)存泄露的資源主要為：File，Cursor，Stream，Bitmap，BroadcastReceiver等，這些資源在使用時(shí)建議及時(shí)關(guān)閉，否則當(dāng)這些資源沒(méi)有及時(shí)回收的時(shí)候，內(nèi)存泄露也就產(chǎn)生了。針對(duì)這些資源使用，給如下建議：

BroadcastReceiver 在register之后，需要在適當(dāng)?shù)臅r(shí)機(jī)unregister Cursor、Stream、File 這類資源類型的對(duì)象往往會(huì)使用一些Cache，所以我們?cè)诓皇褂玫臅r(shí)候，應(yīng)該及時(shí)關(guān)閉，以便Cache被及時(shí)回收。如果我們僅僅把它的引用設(shè)置為null，而不去關(guān)閉他們，往往會(huì)造成內(nèi)存泄露。一般建議是先close()后置為null。 Bitmap在不使用的時(shí)候，調(diào)用recycle()方法。目前 Android 2.3版本以后，不需要我們手動(dòng)去這樣做的，這里也就是簡(jiǎn)單的交代一下。

3、 合理使用Handler避免內(nèi)存泄露

在我們使用Handler的時(shí)候，經(jīng)常看到編輯器提示我們Handler可能會(huì)造成內(nèi)存泄露，一般在這種情況下，我們可以將Handler獨(dú)立出來(lái)或者使用靜態(tài)內(nèi)部類，這樣可以避免內(nèi)存泄露。
這樣做的原因是：非靜態(tài)內(nèi)部類會(huì)潛在的持有它所屬的外部類的引用，但是靜態(tài)內(nèi)部類是不會(huì)的。

4、 合理的使用WeakReference來(lái)引用外部類的成員變量

我們可以使用WeakReference來(lái)規(guī)避好多潛在的內(nèi)存泄露的問(wèn)題，但是并不表明WeakReference就是解決內(nèi)存泄露的金鑰匙。是否使用WeakReference主要取決于對(duì)當(dāng)前對(duì)問(wèn)題的理解，這需要我們對(duì)問(wèn)題的的建模思想。