Android 內(nèi)存泄漏總結(jié)

內(nèi)存管理的目的就是讓我們在開發(fā)中怎么有效的避免我們的應(yīng)用出現(xiàn)內(nèi)存泄漏的問題。內(nèi)存泄漏大家都不陌生了蛙紫，簡單粗俗的講拍屑，就是該被釋放的對象沒有釋放坑傅，一直被某個或某些實例所持有卻不再被使用導(dǎo)致 GC 不能回收丽涩。最近自己閱讀了大量相關(guān)的文檔資料，打算做個 總結(jié) 沉淀下來跟大家一起分享和學(xué)習(xí)裁蚁，也給自己一個警示矢渊，以后 coding 時怎么避免這些情況，提高應(yīng)用的體驗和質(zhì)量枉证。

我會從 java 內(nèi)存泄漏的基礎(chǔ)知識開始矮男，并通過具體例子來說明 Android 引起內(nèi)存泄漏的各種原因，以及如何利用工具來分析應(yīng)用內(nèi)存泄漏室谚，最后再做總結(jié)毡鉴。

Java 內(nèi)存分配策略

Java 程序運行時的內(nèi)存分配策略有三種,分別是靜態(tài)分配,棧式分配,和堆式分配，對應(yīng)的秒赤，三種存儲策略使用的內(nèi)存空間主要分別是靜態(tài)存儲區(qū)（也稱方法區(qū)）猪瞬、棧區(qū)和堆區(qū)。

• 靜態(tài)存儲區(qū)（方法區(qū)）：主要存放靜態(tài)數(shù)據(jù)入篮、全局 static 數(shù)據(jù)和常量陈瘦。這塊內(nèi)存在程序編譯時就已經(jīng)分配好，并且在程序整個運行期間都存在潮售。

• 棧區(qū) （先進后出痊项，保證后入的變量可以訪問先進的變量引用，而且保證方法執(zhí)行完后酥诽，從內(nèi)存中退出）：當(dāng)方法被執(zhí)行時鞍泉，方法體內(nèi)的局部變量（其中包括基礎(chǔ)數(shù)據(jù)類型、對象的引用）都在棧上創(chuàng)建肮帐，并在方法執(zhí)行結(jié)束時這些局部變量所持有的內(nèi)存將會自動被釋放咖驮。因為棧內(nèi)存分配運算內(nèi)置于處理器的指令集中，效率很高训枢，但是分配的內(nèi)存容量有限托修。

• 堆區(qū) （先進先出，保證對象的生命周期在程序運行中存在肮砾，從而使程序正常運行）： 又稱動態(tài)內(nèi)存分配诀黍，通常就是指在程序運行時直接 new 出來的內(nèi)存袋坑，也就是對象的實例仗处。這部分內(nèi)存在不使用時將會由 Java 垃圾回收器來負(fù)責(zé)回收眯勾。

棧與堆的區(qū)別：

在方法體內(nèi)定義的（局部變量）一些基本類型的變量和對象的引用變量都是在方法的棧內(nèi)存中分配的。當(dāng)在一段方法塊中定義一個變量時婆誓，Java 就會在棧中為該變量分配內(nèi)存空間吃环，當(dāng)超過該變量的作用域后，該變量也就無效了洋幻，分配給它的內(nèi)存空間也將被釋放掉郁轻，該內(nèi)存空間可以被重新使用。

堆內(nèi)存用來存放所有由 new 創(chuàng)建的對象（包括該對象其中的所有成員變量）和數(shù)組文留。在堆中分配的內(nèi)存好唯，將由 Java 垃圾回收器來自動管理。在堆中產(chǎn)生了一個數(shù)組或者對象后燥翅，還可以在棧中定義一個特殊的變量骑篙，這個變量的取值等于數(shù)組或者對象在堆內(nèi)存中的首地址，這個特殊的變量就是我們上面說的引用變量森书。我們可以通過這個引用變量來訪問堆中的對象或者數(shù)組靶端。

舉個例子:

public class Sample {
    int s1 = 0;
    Sample mSample1 = new Sample();

    public void method() {
        int s2 = 1;
        Sample mSample2 = new Sample();
    }
}

Sample mSample3 = new Sample();

Sample 類的局部變量 s2 和引用變量 mSample2 都是存在于棧中，但 mSample2 指向的對象是存在于堆上的凛膏。
mSample3 指向的對象實體存放在堆上杨名，包括這個對象的所有成員變量 s1 和 mSample1，而它自己存在于棧中猖毫。

結(jié)論：

局部變量的基本數(shù)據(jù)類型和引用存儲于棧中台谍，引用的對象實體存儲于堆中∮醵希—— 因為它們屬于方法中的變量典唇，生命周期隨方法而結(jié)束。

成員變量全部存儲與堆中（包括基本數(shù)據(jù)類型胯府，引用和引用的對象實體）—— 因為它們屬于類介衔，類對象終究是要被new出來使用的。

了解了 Java 的內(nèi)存分配之后骂因，我們再來看看 Java 是怎么管理內(nèi)存的炎咖。

Java是如何管理內(nèi)存

Java的內(nèi)存管理就是對象的分配和釋放問題。在 Java 中寒波，程序員需要通過關(guān)鍵字 new 為每個對象申請內(nèi)存空間 (基本類型除外)乘盼，所有的對象都在堆 (Heap)中分配空間俄烁。另外绸栅，對象的釋放是由 GC 決定和執(zhí)行的。在 Java 中页屠，內(nèi)存的分配是由程序完成的粹胯，而內(nèi)存的釋放是由 GC 完成的蓖柔，這種收支兩條線的方法確實簡化了程序員的工作。但同時风纠，它也加重了JVM的工作况鸣。這也是 Java 程序運行速度較慢的原因之一。因為竹观，GC 為了能夠正確釋放對象镐捧，GC 必須監(jiān)控每一個對象的運行狀態(tài)，包括對象的申請臭增、引用懂酱、被引用、賦值等誊抛，GC 都需要進行監(jiān)控玩焰。

監(jiān)視對象狀態(tài)是為了更加準(zhǔn)確地、及時地釋放對象芍锚，而釋放對象的根本原則就是該對象不再被引用昔园。

為了更好理解 GC 的工作原理，我們可以將對象考慮為有向圖的頂點并炮，將引用關(guān)系考慮為圖的有向邊默刚，有向邊從引用者指向被引對象。另外逃魄，每個線程對象可以作為一個圖的起始頂點荤西，例如大多程序從 main 進程開始執(zhí)行，那么該圖就是以 main 進程頂點開始的一棵根樹伍俘。在這個有向圖中邪锌，根頂點可達(dá)的對象都是有效對象，GC將不回收這些對象癌瘾。如果某個對象 (連通子圖)與這個根頂點不可達(dá)(注意觅丰，該圖為有向圖)，那么我們認(rèn)為這個(這些)對象不再被引用妨退，可以被 GC 回收妇萄。
以下，我們舉一個例子說明如何用有向圖表示內(nèi)存管理咬荷。對于程序的每一個時刻冠句，我們都有一個有向圖表示JVM的內(nèi)存分配情況。以下右圖幸乒，就是左邊程序運行到第6行的示意圖懦底。

[圖片上傳失敗...(image-d9abd4-1519457433403)]

Java使用有向圖的方式進行內(nèi)存管理，可以消除引用循環(huán)的問題罕扎，例如有三個對象聚唐，相互引用丐重，只要它們和根進程不可達(dá)的，那么GC也是可以回收它們的拱层。這種方式的優(yōu)點是管理內(nèi)存的精度很高，但是效率較低宴咧。另外一種常用的內(nèi)存管理技術(shù)是使用計數(shù)器根灯，例如COM模型采用計數(shù)器方式管理構(gòu)件，它與有向圖相比掺栅，精度行低(很難處理循環(huán)引用的問題)烙肺，但執(zhí)行效率很高。

什么是Java中的內(nèi)存泄露

在Java中氧卧，內(nèi)存泄漏就是存在一些被分配的對象桃笙，這些對象有下面兩個特點，首先沙绝，這些對象是可達(dá)的搏明，即在有向圖中，存在通路可以與其相連闪檬；其次星著，這些對象是無用的，即程序以后不會再使用這些對象粗悯。如果對象滿足這兩個條件虚循，這些對象就可以判定為Java中的內(nèi)存泄漏，這些對象不會被GC所回收样傍，然而它卻占用內(nèi)存横缔。

在C++中，內(nèi)存泄漏的范圍更大一些衫哥。有些對象被分配了內(nèi)存空間茎刚，然后卻不可達(dá)，由于C++中沒有GC撤逢，這些內(nèi)存將永遠(yuǎn)收不回來斗蒋。在Java中，這些不可達(dá)的對象都由GC負(fù)責(zé)回收笛质，因此程序員不需要考慮這部分的內(nèi)存泄露泉沾。

通過分析，我們得知妇押，對于C++跷究，程序員需要自己管理邊和頂點，而對于Java程序員只需要管理邊就可以了(不需要管理頂點的釋放)敲霍。通過這種方式俊马，Java提高了編程的效率丁存。

[圖片上傳失敗...(image-77b3b7-1519457433403)]

因此，通過以上分析柴我，我們知道在Java中也有內(nèi)存泄漏解寝，但范圍比C++要小一些。因為Java從語言上保證艘儒，任何對象都是可達(dá)的聋伦，所有的不可達(dá)對象都由GC管理。

對于程序員來說界睁，GC基本是透明的觉增，不可見的。雖然翻斟，我們只有幾個函數(shù)可以訪問GC逾礁，例如運行GC的函數(shù)System.gc()，但是根據(jù)Java語言規(guī)范定義访惜， 該函數(shù)不保證JVM的垃圾收集器一定會執(zhí)行嘹履。因為，不同的JVM實現(xiàn)者可能使用不同的算法管理GC债热。通常植捎，GC的線程的優(yōu)先級別較低。JVM調(diào)用GC的策略也有很多種阳柔，有的是內(nèi)存使用到達(dá)一定程度時焰枢，GC才開始工作，也有定時執(zhí)行的舌剂，有的是平緩執(zhí)行GC济锄，有的是中斷式執(zhí)行GC。但通常來說霍转，我們不需要關(guān)心這些荐绝。除非在一些特定的場合，GC的執(zhí)行影響應(yīng)用程序的性能避消，例如對于基于Web的實時系統(tǒng)低滩，如網(wǎng)絡(luò)游戲等，用戶不希望GC突然中斷應(yīng)用程序執(zhí)行而進行垃圾回收岩喷，那么我們需要調(diào)整GC的參數(shù)恕沫，讓GC能夠通過平緩的方式釋放內(nèi)存，例如將垃圾回收分解為一系列的小步驟執(zhí)行纱意，Sun提供的HotSpot JVM就支持這一特性婶溯。

同樣給出一個 Java 內(nèi)存泄漏的典型例子，

static Vector v = new Vector(10);
for (int i = 1; i < 100; i++) {
    Object o = new Object();
    v.add(o);
    o = null;   
}

在這個例子中，我們循環(huán)申請Object對象迄委，并將所申請的對象放入一個 Vector 中褐筛，如果我們僅僅釋放引用本身，那么 Vector 仍然引用該對象叙身，所以這個對象對 GC 來說是不可回收的渔扎。因此，如果對象加入到Vector 后信轿，還必須從 Vector 中刪除晃痴，最簡單的方法就是將 Vector 對象設(shè)置為 null。

詳細(xì)Java中的內(nèi)存泄漏

1.Java內(nèi)存回收機制

不論哪種語言的內(nèi)存分配方式虏两，都需要返回所分配內(nèi)存的真實地址愧旦，也就是返回一個指針到內(nèi)存塊的首地址世剖。Java中對象是采用new或者反射的方法創(chuàng)建的定罢，這些對象的創(chuàng)建都是在堆（Heap）中分配的，所有對象的回收都是由Java虛擬機通過垃圾回收機制完成的旁瘫。GC為了能夠正確釋放對象祖凫，會監(jiān)控每個對象的運行狀況，對他們的申請酬凳、引用惠况、被引用、賦值等狀況進行監(jiān)控宁仔，Java會使用有向圖的方法進行管理內(nèi)存稠屠，實時監(jiān)控對象是否可以達(dá)到，如果不可到達(dá)翎苫，則就將其回收权埠，這樣也可以消除引用循環(huán)的問題。在Java語言中煎谍，判斷一個內(nèi)存空間是否符合垃圾收集標(biāo)準(zhǔn)有兩個：一個是給對象賦予了空值null攘蔽，以下再沒有調(diào)用過，另一個是給對象賦予了新值呐粘，這樣重新分配了內(nèi)存空間满俗。

2.Java內(nèi)存泄漏引起的原因

內(nèi)存泄漏是指無用對象（不再使用的對象）持續(xù)占有內(nèi)存或無用對象的內(nèi)存得不到及時釋放，從而造成內(nèi)存空間的浪費稱為內(nèi)存泄漏作岖。內(nèi)存泄露有時不嚴(yán)重且不易察覺唆垃，這樣開發(fā)者就不知道存在內(nèi)存泄露，但有時也會很嚴(yán)重痘儡，會提示你Out of memory降盹。j

Java內(nèi)存泄漏的根本原因是什么呢？長生命周期的對象持有短生命周期對象的引用就很可能發(fā)生內(nèi)存泄漏，盡管短生命周期對象已經(jīng)不再需要蓄坏，但是因為長生命周期持有它的引用而導(dǎo)致不能被回收价捧，這就是Java中內(nèi)存泄漏的發(fā)生場景。具體主要有如下幾大類：

1涡戳、靜態(tài)集合類引起內(nèi)存泄漏：

像HashMap结蟋、Vector等的使用最容易出現(xiàn)內(nèi)存泄露，這些靜態(tài)變量的生命周期和應(yīng)用程序一致渔彰，他們所引用的所有的對象Object也不能被釋放嵌屎，因為他們也將一直被Vector等引用著。

例如

static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}

在這個例子中恍涂，循環(huán)申請Object 對象宝惰，并將所申請的對象放入一個Vector 中，如果僅僅釋放引用本身（o=null）再沧，那么Vector 仍然引用該對象尼夺，所以這個對象對GC 來說是不可回收的。因此炒瘸，如果對象加入到Vector 后淤堵，還必須從Vector 中刪除，最簡單的方法就是將Vector對象設(shè)置為null顷扩。

2拐邪、當(dāng)集合里面的對象屬性被修改后，再調(diào)用remove()方法時不起作用隘截。

例如：

public static void main(String[] args)
{
Set<Person> set = new HashSet<Person>();
Person p1 = new Person("唐僧","pwd1",25);
Person p2 = new Person("孫悟空","pwd2",26);
Person p3 = new Person("豬八戒","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("總共有:"+set.size()+" 個元素!"); //結(jié)果：總共有:3 個元素!
p3.setAge(2); //修改p3的年齡,此時p3元素對應(yīng)的hashcode值發(fā)生改變

set.remove(p3); //此時remove不掉扎阶，造成內(nèi)存泄漏

set.add(p3); //重新添加，居然添加成功
System.out.println("總共有:"+set.size()+" 個元素!"); //結(jié)果：總共有:4 個元素!
for (Person person : set)
{
System.out.println(person);
}
}

3婶芭、監(jiān)聽器

在java 編程中东臀，我們都需要和監(jiān)聽器打交道，通常一個應(yīng)用當(dāng)中會用到很多監(jiān)聽器雕擂，我們會調(diào)用一個控件的諸如addXXXListener()等方法來增加監(jiān)聽器啡邑，但往往在釋放對象的時候卻沒有記住去刪除這些監(jiān)聽器，從而增加了內(nèi)存泄漏的機會井赌。

4谤逼、各種連接

比如數(shù)據(jù)庫連接（dataSourse.getConnection()），網(wǎng)絡(luò)連接(socket)和io連接仇穗，除非其顯式的調(diào)用了其close（）方法將其連接關(guān)閉流部，否則是不會自動被GC 回收的。對于Resultset 和Statement 對象可以不進行顯式回收纹坐，但Connection 一定要顯式回收枝冀，因為Connection 在任何時候都無法自動回收，而Connection一旦回收，Resultset 和Statement 對象就會立即為NULL果漾。但是如果使用連接池球切，情況就不一樣了，除了要顯式地關(guān)閉連接绒障，還必須顯式地關(guān)閉Resultset Statement 對象（關(guān)閉其中一個吨凑，另外一個也會關(guān)閉），否則就會造成大量的Statement 對象無法釋放户辱，從而引起內(nèi)存泄漏鸵钝。這種情況下一般都會在try里面去的連接，在finally里面釋放連接庐镐。

5恩商、內(nèi)部類和外部模塊的引用

內(nèi)部類可以引用到外部類的原因是在編譯之后會持有外部類的指針，因為在內(nèi)部類的缺省構(gòu)造方法中需要傳入外部類指針必逆。

內(nèi)部類的引用是比較容易遺忘的一種怠堪，而且一旦沒釋放可能導(dǎo)致一系列的后繼類對象沒有釋放。此外程序員還要小心外部模塊不經(jīng)意的引用末患，例如程序員A 負(fù)責(zé)A 模塊研叫，調(diào)用了B 模塊的一個方法如：
public void registerMsg(Object b);
這種調(diào)用就要非常小心了锤窑，傳入了一個對象璧针，很可能模塊B就保持了對該對象的引用，這時候就需要注意模塊B 是否提供相應(yīng)的操作去除引用渊啰。

6探橱、單例模式

不正確使用單例模式是引起內(nèi)存泄漏的一個常見問題，單例對象在初始化后將在JVM的整個生命周期中存在（以靜態(tài)變量的方式）绘证，如果單例對象持有外部的引用隧膏，那么這個對象將不能被JVM正常回收嚷那，導(dǎo)致內(nèi)存泄漏胞枕，考慮下面的例子：

class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B類采用單例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
} 

顯然B采用singleton模式，它持有一個A對象的引用魏宽，而這個A類的對象將不能被回收腐泻。想象下如果A是個比較復(fù)雜的對象或者集合類型會發(fā)生什么情況

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

集合類泄漏

集合類如果僅僅有添加元素的方法，而沒有相應(yīng)的刪除機制队询，導(dǎo)致內(nèi)存被占用派桩。如果這個集合類是全局性的變量 (比如類中的靜態(tài)屬性，全局性的 map 等即有靜態(tài)引用或 final 一直指向它)蚌斩，那么沒有相應(yīng)的刪除機制铆惑，很可能導(dǎo)致集合所占用的內(nèi)存只增不減。比如上面的典型例子就是其中一種情況，當(dāng)然實際上我們在項目中肯定不會寫這么 2B 的代碼员魏，但稍不注意還是很容易出現(xiàn)這種情況丑蛤，比如我們都喜歡通過 HashMap 做一些緩存之類的事，這種情況就要多留一些心眼撕阎。

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

由于單例的靜態(tài)特性使得其生命周期跟應(yīng)用的生命周期一樣長盏阶，所以如果使用不恰當(dāng)?shù)脑挘苋菀自斐蓛?nèi)存泄漏闻书。比如下面一個典型的例子名斟，

public class AppManager {
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;
}
}

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

1、如果此時傳入的是 Application 的 Context坑律，因為 Application 的生命周期就是整個應(yīng)用的生命周期岩梳，所以這將沒有任何問題。

2晃择、如果此時傳入的是 Activity 的 Context冀值，當(dāng)這個 Context 所對應(yīng)的 Activity 退出時，由于該 Context 的引用被單例對象所持有宫屠，其生命周期等于整個應(yīng)用程序的生命周期列疗，所以當(dāng)前 Activity 退出時它的內(nèi)存并不會被回收，這就造成泄漏了浪蹂。

正確的方式應(yīng)該改為下面這種方式：

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();// 使用Application 的context
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context);
}
return instance;
}
}

或者這樣寫抵栈，連 Context 都不用傳進來了：

在你的 Application 中添加一個靜態(tài)方法，getContext() 返回 Application 的 context坤次，

...

context = getApplicationContext();

...
   /**
     * 獲取全局的context
     * @return 返回全局context對象
     */
    public static Context getContext(){
        return context;
    }

public class AppManager {
private static AppManager instance;
private Context context;
private AppManager() {
this.context = MyApplication.getContext();// 使用Application 的context
}
public static AppManager getInstance() {
if (instance == null) {
instance = new AppManager();
}
return instance;
}
}

匿名內(nèi)部類/非靜態(tài)內(nèi)部類和異步線程

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

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

        public class MainActivity extends AppCompatActivity {
        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)建了一個非靜態(tài)內(nèi)部類的單例，每次啟動Activity時都會使用該單例的數(shù)據(jù)，這樣雖然避免了資源的重復(fù)創(chuàng)建芬位，不過這種寫法卻會造成內(nèi)存泄漏掏熬，因為非靜態(tài)內(nèi)部類默認(rèn)會持有外部類的引用捻勉，而該非靜態(tài)內(nèi)部類又創(chuàng)建了一個靜態(tài)的實例骚勘，該實例的生命周期和應(yīng)用的一樣長，這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用蹬挤，導(dǎo)致Activity的內(nèi)存資源不能正掣苛回收。正確的做法為：

將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來封裝成一個單例焰扳，如果需要使用Context倦零，請按照上面推薦的使用Application 的 Context误续。當(dāng)然，Application 的 context 不是萬能的扫茅，所以也不能隨便亂用蹋嵌，對于有些地方則必須使用 Activity 的 Context，對于Application葫隙，Service栽烂，Activity三者的Context的應(yīng)用場景如下：

image

其中： NO1表示 Application 和 Service 可以啟動一個 Activity，不過需要創(chuàng)建一個新的 task 任務(wù)隊列恋脚。而對于 Dialog 而言腺办，只有在 Activity 中才能創(chuàng)建

匿名內(nèi)部類

android開發(fā)經(jīng)常會繼承實現(xiàn)Activity/Fragment/View，此時如果你使用了匿名類糟描，并被異步線程持有了怀喉，那要小心了，如果沒有任何措施這樣一定會導(dǎo)致泄露

    public class MainActivity extends Activity {
    ...
    Runnable ref1 = new MyRunable();
    Runnable ref2 = new Runnable() {
        @Override
        public void run() {

        }
    };
       ...
    }

ref1和ref2的區(qū)別是船响，ref2使用了匿名內(nèi)部類躬拢。我們來看看運行時這兩個引用的內(nèi)存：

image

可以看到，ref1沒什么特別的见间。

但ref2這個匿名類的實現(xiàn)對象里面多了一個引用：

this$0這個引用指向MainActivity.this聊闯，也就是說當(dāng)前的MainActivity實例會被ref2持有，如果將這個引用再傳入一個異步線程米诉，此線程和此Acitivity生命周期不一致的時候菱蔬，就造成了Activity的泄露。
（這個還是可以從編譯后的.class文件可以看到荒辕，內(nèi)部類的缺省構(gòu)造函數(shù)中需要傳入外部類的指針）

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

Handler 的使用造成的內(nèi)存泄漏問題應(yīng)該說是最為常見了汗销，很多時候我們?yōu)榱吮苊?ANR 而不在主線程進行耗時操作犹褒，在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請求回調(diào)等api都借助Handler來處理抵窒，但 Handler 不是萬能的，對于 Handler 的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏叠骑。另外李皇，我們知道 Handler、Message 和 MessageQueue 都是相互關(guān)聯(lián)在一起的宙枷，萬一 Handler 發(fā)送的 Message 尚未被處理掉房，則該 Message 及發(fā)送它的 Handler 對象將被線程 MessageQueue 一直持有。

由于 Handler 屬于 TLS(Thread Local Storage) 變量, 生命周期和 Activity 是不一致的慰丛。因此這種實現(xiàn)方式一般很難保證跟 View 或者 Activity 的生命周期保持一致卓囚，故很容易導(dǎo)致無法正確釋放。

舉個例子：

    public class SampleActivity extends Activity {

    private final Handler mLeakyHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
      // ...
    }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // Post a message and delay its execution for 10 minutes.
    mLeakyHandler.postDelayed(new Runnable() {
      @Override
      public void run() { /* ... */ }
    }, 1000 * 60 * 10);

    // Go back to the previous Activity.
    finish();
    }
    }

在該 SampleActivity 中聲明了一個延遲10分鐘執(zhí)行的消息 Message诅病，mLeakyHandler 將其 push 進了消息隊列 MessageQueue 里哪亿。當(dāng)該 Activity 被 finish() 掉時粥烁，延遲執(zhí)行任務(wù)的 Message 還會繼續(xù)存在于主線程中，它持有該 Activity 的 Handler 引用蝇棉，所以此時 finish() 掉的 Activity 就不會被回收了從而造成內(nèi)存泄漏（因 Handler 為非靜態(tài)內(nèi)部類讨阻，它會持有外部類的引用，在這里就是指 SampleActivity）篡殷。

修復(fù)方法：在 Activity 中避免使用非靜態(tài)內(nèi)部類钝吮，比如上面我們將 Handler 聲明為靜態(tài)的，則其存活期跟 Activity 的生命周期就無關(guān)了板辽。同時通過弱引用的方式引入 Activity奇瘦，避免直接將 Activity 作為 context 傳進去，見下面代碼：

public class SampleActivity extends Activity {

  /**
   * Instances of static inner classes do not hold an implicit
   * reference to their outer class.
   */
  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);

  /**
   * Instances of anonymous classes do not hold an implicit
   * reference to their outer class when they are "static".
   */
  private static final Runnable sRunnable = new Runnable() {
      @Override
      public void run() { /* ... */ }
  };

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // Post a message and delay its execution for 10 minutes.
    mHandler.postDelayed(sRunnable, 1000 * 60 * 10);

    // Go back to the previous Activity.
    finish();
  }
}

綜述劲弦，即推薦使用靜態(tài)內(nèi)部類 + WeakReference + remove MessageQueue中未被處理的Message 這種方式链患。每次使用前注意判空。

前面提到了 WeakReference瓶您，所以這里就簡單的說一下 Java 對象的幾種引用類型麻捻。

Java對引用的分類有 Strong reference, SoftReference, WeakReference, PhatomReference 四種。

image

在Android應(yīng)用的開發(fā)中呀袱，為了防止內(nèi)存溢出贸毕，在處理一些占用內(nèi)存大而且聲明周期較長的對象時候，可以盡量應(yīng)用軟引用和弱引用技術(shù)夜赵。

軟/弱引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用明棍，如果軟引用所引用的對象被垃圾回收器回收，Java虛擬機就會把這個軟引用加入到與之關(guān)聯(lián)的引用隊列中寇僧。利用這個隊列可以得知被回收的軟/弱引用的對象列表摊腋，從而為緩沖器清除已失效的軟/弱引用。

假設(shè)我們的應(yīng)用會用到大量的默認(rèn)圖片嘁傀，比如應(yīng)用中有默認(rèn)的頭像兴蒸，默認(rèn)游戲圖標(biāo)等等，這些圖片很多地方會用到细办。如果每次都去讀取圖片橙凳，由于讀取文件需要硬件操作，速度較慢笑撞，會導(dǎo)致性能較低岛啸。所以我們考慮將圖片緩存起來，需要的時候直接從內(nèi)存中讀取茴肥。但是坚踩，由于圖片占用內(nèi)存空間比較大，緩存很多圖片需要很多的內(nèi)存瓤狐，就可能比較容易發(fā)生OutOfMemory異常瞬铸。這時卧晓，我們可以考慮使用軟/弱引用技術(shù)來避免這個問題發(fā)生。以下就是高速緩沖器的雛形：

首先定義一個HashMap赴捞，保存軟引用對象逼裆。

private Map <String, SoftReference<Bitmap>> imageCache = new HashMap <String, SoftReference<Bitmap>> ();

再來定義一個方法，保存Bitmap的軟引用到HashMap赦政。

image

使用軟引用以后胜宇，在OutOfMemory異常發(fā)生之前，這些緩存的圖片資源的內(nèi)存空間可以被釋放掉的恢着，從而避免內(nèi)存達(dá)到上限桐愉，避免Crash發(fā)生。

如果只是想避免OutOfMemory異常的發(fā)生掰派，則可以使用軟引用从诲。如果對于應(yīng)用的性能更在意，想盡快回收一些占用內(nèi)存比較大的對象靡羡，則可以使用弱引用系洛。

另外可以根據(jù)對象是否經(jīng)常使用來判斷選擇軟引用還是弱引用。如果該對象可能會經(jīng)常使用的略步，就盡量用軟引用描扯。如果該對象不被使用的可能性更大些，就可以用弱引用趟薄。

ok绽诚，繼續(xù)回到主題。前面所說的杭煎，創(chuàng)建一個靜態(tài)Handler內(nèi)部類恩够，然后對 Handler 持有的對象使用弱引用，這樣在回收時也可以回收 Handler 持有的對象羡铲，但是這樣做雖然避免了 Activity 泄漏蜂桶，不過 Looper 線程的消息隊列中還是可能會有待處理的消息，所以我們在 Activity 的 Destroy 時或者 Stop 時應(yīng)該移除消息隊列 MessageQueue 中的消息犀勒。

下面幾個方法都可以移除 Message：

public final void removeCallbacks(Runnable r);

public final void removeCallbacks(Runnable r, Object token);

public final void removeCallbacksAndMessages(Object token);

public final void removeMessages(int what);

public final void removeMessages(int what, Object object);

盡量避免使用 static 成員變量

如果成員變量被聲明為 static屎飘，那我們都知道其生命周期將與整個app進程生命周期一樣。

這會導(dǎo)致一系列問題贾费，如果你的app進程設(shè)計上是長駐內(nèi)存的，那即使app切到后臺檐盟，這部分內(nèi)存也不會被釋放褂萧。按照現(xiàn)在手機app內(nèi)存管理機制，占內(nèi)存較大的后臺進程將優(yōu)先回收葵萎，yi'wei如果此app做過進程互保钡加蹋活唱凯，那會造成app在后臺頻繁重啟。當(dāng)手機安裝了你參與開發(fā)的app以后一夜時間手機被消耗空了電量谎痢、流量磕昼，你的app不得不被用戶卸載或者靜默。

這里修復(fù)的方法是：

不要在類初始時初始化靜態(tài)成員节猿∑贝樱可以考慮lazy初始化。
架構(gòu)設(shè)計上要思考是否真的有必要這樣做滨嘱，盡量避免峰鄙。如果架構(gòu)需要這么設(shè)計，那么此對象的生命周期你有責(zé)任管理起來太雨。

避免 override finalize()

1吟榴、finalize 方法被執(zhí)行的時間不確定，不能依賴與它來釋放緊缺的資源囊扳。時間不確定的原因是：
虛擬機調(diào)用GC的時間不確定
Finalize daemon線程被調(diào)度到的時間不確定

2吩翻、finalize 方法只會被執(zhí)行一次，即使對象被復(fù)活锥咸，如果已經(jīng)執(zhí)行過了 finalize 方法仿野，再次被 GC 時也不會再執(zhí)行了，原因是：

含有 finalize 方法的 object 是在 new 的時候由虛擬機生成了一個 finalize reference 在來引用到該Object的她君，而在 finalize 方法執(zhí)行的時候脚作，該 object 所對應(yīng)的 finalize Reference 會被釋放掉，即使在這個時候把該 object 復(fù)活(即用強引用引用住該 object )缔刹，再第二次被 GC 的時候由于沒有了 finalize reference 與之對應(yīng)球涛，所以 finalize 方法不會再執(zhí)行。
（finalize reference隊列中會存儲實現(xiàn)了finalize方法的對象的引用校镐，而且當(dāng)執(zhí)行finalize方法后此引用會被刪除亿扁，所以程序的finalize方法在程序的生命周期的時間內(nèi)只會調(diào)用一次）

3、含有Finalize方法的object需要至少經(jīng)過兩輪GC才有可能被釋放鸟廓。

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

對于使用了BraodcastReceiver从祝，ContentObserver，F(xiàn)ile引谜，游標(biāo) Cursor牍陌，Stream，Bitmap等資源的使用员咽，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷毒涧，否則這些資源將不會被回收，造成內(nèi)存泄漏贝室。

一些不良代碼造成的內(nèi)存壓力

有些代碼并不造成內(nèi)存泄露契讲，但是它們仿吞，或是對沒使用的內(nèi)存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內(nèi)存捡偏。

比如：
Bitmap 沒調(diào)用 recycle()方法唤冈，對于 Bitmap 對象在不使用時,我們應(yīng)該先調(diào)用 recycle() 釋放內(nèi)存，然后才它設(shè)置為 null. 因為加載 Bitmap 對象的內(nèi)存空間银伟，一部分是 java 的你虹，一部分 C 的（因為 Bitmap 分配的底層是通過 JNI 調(diào)用的 )。 而這個 recyle() 就是針對 C 部分的內(nèi)存釋放枣申。
構(gòu)造 Adapter 時售葡，沒有使用緩存的 convertView ,每次都在創(chuàng)建新的 converView。這里推薦使用 ViewHolder忠藤。

總結(jié)

對 Activity 等組件的引用應(yīng)該控制在 Activity 的生命周期之內(nèi)挟伙； 如果不能就考慮使用 getApplicationContext 或者 getApplication，以避免 Activity 被外部長生命周期的對象引用而泄露模孩。

盡量不要在靜態(tài)變量或者靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量（包括context )尖阔，即使要使用，也要考慮適時把外部成員變量置空榨咐；也可以在內(nèi)部類中使用弱引用來引用外部類的變量介却。

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

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

Handler 的持有的引用對象最好使用弱引用齿坷，資源釋放時也可以清空 Handler 里面的消息。比如在 Activity onStop 或者 onDestroy 的時候数焊，取消掉該 Handler 對象的 Message和 Runnable.

在 Java 的實現(xiàn)過程中永淌，也要考慮其對象釋放，最好的方法是在不使用某對象時佩耳，顯式地將此對象賦值為 null遂蛀，比如使用完Bitmap 后先調(diào)用 recycle()，再賦為null,清空對圖片等資源有直接引用或者間接引用的數(shù)組（使用 array.clear() ; array = null）等干厚，最好遵循誰創(chuàng)建誰釋放的原則李滴。

正確關(guān)閉資源，對于使用了BraodcastReceiver蛮瞄，ContentObserver所坯，F(xiàn)ile，游標(biāo) Cursor裕坊，Stream包竹，Bitmap等資源的使用，應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷籍凝。

保持對對象生命周期的敏感周瞎，特別注意單例、靜態(tài)對象饵蒂、全局性集合等的生命周期声诸。