[[164245]]

Android 編程所使用的 Java 是一門(mén)使用垃圾收集器（GC, garbage collection）來(lái)自動(dòng)管理內(nèi)存的語(yǔ)言，它使得我們不再需要手動(dòng)調(diào)用代碼來(lái)進(jìn)行內(nèi)存回收。那么它是如何判斷的呢？簡(jiǎn)單說(shuō)，如果一個(gè)對(duì)象，從它的根節(jié)點(diǎn)開(kāi)始不可達(dá)的話(huà)，那么這個(gè)對(duì)象就是沒(méi)有引用的了，是會(huì)被垃圾收集器回收的，其中，所謂的 “根節(jié)點(diǎn)” 往往是一個(gè)線程，比如主線程。因此，如果一個(gè)對(duì)象從它的根節(jié)點(diǎn)開(kāi)始是可達(dá)的有引用的，但實(shí)際上它已經(jīng)沒(méi)有再使用了，是無(wú)用的，這樣的對(duì)象就是內(nèi)存泄漏的對(duì)象，它會(huì)在內(nèi)存中占據(jù)我們應(yīng)用程序原本就不是很多的內(nèi)存，導(dǎo)致程序變慢，甚至內(nèi)存溢出（OOM）程序崩潰。

內(nèi)存泄漏的原因并不難理解，但僅管知道它的存在，往往我們還是會(huì)不知覺(jué)中寫(xiě)出致使內(nèi)存泄漏的代碼。在 Android 編程中，也是有許多情景容易導(dǎo)致內(nèi)存泄漏，以下將一一列舉一些我所知道的內(nèi)存泄漏案例，從這些例子中應(yīng)該能更加直觀了解怎么導(dǎo)致了內(nèi)存泄漏，從而在編程過(guò)程中去避免。
靜態(tài)變量造成內(nèi)存泄漏

首先，比較簡(jiǎn)單的一種情況是，靜態(tài)變量致使內(nèi)存泄漏，說(shuō)到靜態(tài)變量，我們至少得了解其生命周期才能徹底明白。靜態(tài)變量的生命周期，起始于類(lèi)的加載，終止于類(lèi)的釋放。對(duì)于 Android 而言，程序也是從一個(gè) main 方法進(jìn)入，開(kāi)始了主線程的工作，如果一個(gè)類(lèi)在主線程或旁枝中被使用到，它就會(huì)被加載，反過(guò)來(lái)說(shuō)，假如一個(gè)類(lèi)存在于我們的項(xiàng)目中，但它從未被我們使用過(guò)，算是個(gè)孤島，這時(shí)它是沒(méi)有被加載的。一旦被加載，只有等到我們的 Android 應(yīng)用進(jìn)程結(jié)束它才會(huì)被卸載。

于是，當(dāng)我們?cè)?Activity 中聲明一個(gè)靜態(tài)變量引用了 Activity 自身，就會(huì)造成內(nèi)存泄漏：

public class LeakActivity extends AppCompatActivity {  
   
    private static Context sContext;  
   
   
    @Override protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_leak);  
        sContext = this;  
    }  
} 

這樣的代碼會(huì)導(dǎo)致當(dāng)這個(gè) Activity 結(jié)束的時(shí)候，sContext 仍然持有它的引用，致使 Activity 無(wú)法回收。解決辦法就是在這個(gè) Activity 的 onDestroy 時(shí)將 sContext 的值置空，或者避免使用靜態(tài)變量這樣的寫(xiě)法。

同樣的，如果一個(gè) Activity 的靜態(tài) field 變量?jī)?nèi)部獲得了當(dāng)前 Activity 的引用，比如我們經(jīng)常會(huì)把 this 傳給 View 之類(lèi)的對(duì)象，這個(gè)對(duì)象若是靜態(tài)的，并且沒(méi)有在 Activity 生命周期結(jié)束之前置空的話(huà)，也會(huì)導(dǎo)致同樣的問(wèn)題。
非靜態(tài)內(nèi)部類(lèi)和匿名內(nèi)部類(lèi)造成內(nèi)存泄漏

也是一個(gè)很常見(jiàn)的情景，經(jīng)常會(huì)遇到的 Handler 問(wèn)題就是這樣一種情況，如果我們?cè)?field 聲明一個(gè) Handler 變量：

private Handler mHandler = new Handler() {  
    @Override public void handleMessage(Message msg) {  
        super.handleMessage(msg);  
    }  
}; 

由于在 Java 中，非靜態(tài)內(nèi)部類(lèi)（包括匿名內(nèi)部類(lèi)，比如這個(gè) Handler 匿名內(nèi)部類(lèi)）會(huì)引用外部類(lèi)對(duì)象（比如 Activity），而靜態(tài)的內(nèi)部類(lèi)則不會(huì)引用外部類(lèi)對(duì)象。所以這里 Handler 會(huì)引用 Activity 對(duì)象，當(dāng)它使用了 postDelayed 的時(shí)候，如果 Activity 已經(jīng) finish 了，而這個(gè) handler 仍然引用著這個(gè) Activity 就會(huì)致使內(nèi)存泄漏，因?yàn)檫@個(gè) handler 會(huì)在一段時(shí)間內(nèi)繼續(xù)被 main Looper 持有，導(dǎo)致引用仍然存在，在這段時(shí)間內(nèi)，如果內(nèi)存吃緊至超出，就很危險(xiǎn)了。

解決辦法就是大家都知道的使用靜態(tài)內(nèi)部類(lèi)加 WeakReference：

private StaticHandler mHandler = new StaticHandler(this);  
   
public static class StaticHandler extends Handler {  
    private final WeakReference<Activity> mActivity;  
   
   
    public StaticHandler(Activity activity) {  
        mActivity = new WeakReference<Activity>(activity);  
    }  
   
   
    @Override public void handleMessage(Message msg) {  
        super.handleMessage(msg);  
    }  
} 

另外，綜合上面兩種情況，如果一個(gè)變量，既是靜態(tài)變量，而且是非靜態(tài)的內(nèi)部類(lèi)對(duì)象，那么也會(huì)造成內(nèi)存泄漏：

public class LeakActivity extends AppCompatActivity {  
   
    private static Hello sHello;  
   
   
    @Override protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_leak);  
           
        sHello = new Hello();  
    }  
   
   
    public class Hello {}  
} 

注意，這里我們定義的 Hello 雖然是空的，但它是一個(gè)非靜態(tài)的內(nèi)部類(lèi)，所以它必然會(huì)持有外部類(lèi)即 LeakActivity.this 引用，導(dǎo)致 sHello 這個(gè)靜態(tài)變量一直持有這個(gè) Activity，于是結(jié)果就和***個(gè)例子一樣，Activity 無(wú)法被回收。

到這里大家應(yīng)該可以看出，內(nèi)存泄漏經(jīng)常和靜態(tài)變量有關(guān)。和靜態(tài)變量有關(guān)的，還有一種常見(jiàn)情景，就是使用單例模式?jīng)]有解綁致使內(nèi)存泄漏，單例模式的對(duì)象經(jīng)常是和我們的應(yīng)用相同的生命周期，如果我們使用 EventBus 或 Otto 并生成單例，注冊(cè)了一個(gè) Activity 而沒(méi)有在頁(yè)面結(jié)束的時(shí)候進(jìn)行解除注冊(cè)，那么單例會(huì)一直持有我們的 Activity，這個(gè) Activity 雖然沒(méi)有使用了，但會(huì)一直占用著內(nèi)存。
屬性動(dòng)畫(huà)造成內(nèi)存泄漏

另外當(dāng)我們使用屬性動(dòng)畫(huà)，我們需要調(diào)用一些方法將動(dòng)畫(huà)停止，特別是***循環(huán)的動(dòng)畫(huà)，否則也會(huì)造成內(nèi)存泄漏，好在使用 View 動(dòng)畫(huà)并不會(huì)出現(xiàn)內(nèi)存泄漏，估計(jì) View 內(nèi)部有進(jìn)行釋放和停止。
RxJava 使用不當(dāng)造成內(nèi)存泄漏

***說(shuō)一說(shuō) RxJava 使用不當(dāng)造成的內(nèi)存泄漏，RxJava 是一個(gè)非常易用且優(yōu)雅的異步操作庫(kù)。對(duì)于異步的操作，如果沒(méi)有及時(shí)取消訂閱，就會(huì)造成內(nèi)存泄漏：

Observable.interval(1, TimeUnit.SECONDS)  
          .subscribe(new Action1<Long>() {  
              @Override public void call(Long aLong) {  
                  // pass  
              }  
          }); 

同樣是匿名內(nèi)部類(lèi)造成的引用沒(méi)法被釋放，使得如果在 Activity 中使用就會(huì)導(dǎo)致它無(wú)法被回收，即使我們的 Action1 看起來(lái)什么也沒(méi)有做。解決辦法就是接收 subscribe 返回的 Subscription 對(duì)象，在 Activity onDestroy 的時(shí)候?qū)⑵淙∠嗛喖纯桑?/p>

public class LeakActivity extends AppCompatActivity {  
   
    private Subscription mSubscription;  
   
   
    @Override protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_leak);  
   
        mSubscription = Observable.interval(1, TimeUnit.SECONDS)  
            .subscribe(new Action1<Long>() {  
              @Override public void call(Long aLong) {  
                  // pass  
              }  
            });  
    }  
   
   
    @Override protected void onDestroy() {  
        super.onDestroy();  
        mSubscription.unsubscribe();  
    }  
} 

除了以上這種解決方式之外，還有一種解決方式就是通過(guò) RxJava 的 compose 操作符和 Activity 的生命周期掛鉤，我們可以使用一個(gè)很方便的第三方庫(kù)叫做 RxLifecycle 來(lái)快捷做到這點(diǎn)，使用起來(lái)就像這樣：

public class MyActivity extends RxActivity {  
    @Override 
    public void onResume() {  
        super.onResume();  
        myObservable  
            .compose(bindToLifecycle())  
            .subscribe();  
    }  
} 

另外，它還提供了和 View 的便捷綁定，詳情可以點(diǎn)擊我提供的鏈接進(jìn)行了解，這里不多說(shuō)了。

總結(jié)來(lái)說(shuō)，仍然是前面說(shuō)的內(nèi)部類(lèi)或匿名內(nèi)部類(lèi)引用了外部類(lèi)造成了內(nèi)存泄漏，所以在實(shí)際編程過(guò)程中，如果涉及此類(lèi)問(wèn)題或者線程操作的，應(yīng)該特別小心，很可能不知不覺(jué)中就寫(xiě)出了帶內(nèi)存泄漏的代碼了。
內(nèi)存泄漏的檢測(cè)

前面說(shuō)了不少內(nèi)存泄漏的場(chǎng)景和對(duì)應(yīng)的解決辦法，但如果我們不知不覺(jué)中寫(xiě)出了帶有內(nèi)存泄漏隱患的代碼怎么辦，面對(duì)這個(gè)問(wèn)題，其實(shí)到現(xiàn)在，我們是很幸運(yùn)的，因?yàn)橛泻芏嘞嚓P(guān)的檢查方式或組件可以選擇，比如最簡(jiǎn)單的：觀察 Memory Monitor 內(nèi)存走勢(shì)圖，可以或多或少知道內(nèi)存情況，但如果要精確地追蹤到內(nèi)存泄漏點(diǎn)，這里特別推薦偉大的 Square 公司開(kāi)源的 LeakCanary 方案，LeakCanary 可以做到非常簡(jiǎn)單方便、低侵入性地捕獲內(nèi)存泄漏代碼，甚至很多時(shí)候你可以捕捉到 Android 官方組件的內(nèi)存泄漏代碼，具體使用大家可以自行參看其說(shuō)明，由于本文主要想講的是內(nèi)存泄漏的原因和一些常見(jiàn)場(chǎng)景，對(duì)于檢測(cè)，這里就不多說(shuō)啦