內存泄漏(Memory Leak)

什麼狀況下會致使內存泄露(Memory Leak)？

Android 的虛擬機是基於寄存器的Dalvik，它的最大堆大小通常是16M，有的機器爲24M。所以咱們所能利用

的內存空間是有限的。若是咱們的內存佔用超過了必定的水平就會出現OutOfMemory 的錯誤。

內存溢出的幾點緣由：

一、資源釋放問題
程序代碼的問題，長期保持某些資源，如Context、Cursor、IO 流的引用，資源得不到釋放形成內存泄露。

須要適當的釋放資源的狀況，這些硬件資源可能包括：視頻、音頻、相機等。

 

二、廣播註冊後沒取消形成的內存泄漏

記得在activity銷燬的時候必定要取消廣播的註冊 

三、static 關鍵字的使用問題
static 是Java 中的一個關鍵字，當用它來修飾成員變量時，那麼該變量就屬於該類，而不是該類的實例。

因此用static 修飾的變量，它的生命週期是很長的，若是用它來引用一些資源耗費過多的實例（Context 的狀況最多），

這時就要謹慎對待了。

public class ClassName {
private static Context mContext;
//省略
}
以上的代碼是很危險的，若是將Activity 賦值到mContext 的話。那麼即便該Activity 已經onDestroy，

可是因爲仍有對象保存它的引用，所以該Activity 依然不會被釋放。

咱們舉Android 文檔中的一個例子。

private static Drawable sBackground;
　　@Override
　　protected void onCreate(Bundle state) {
　　super.onCreate(state);
　　TextView label = new TextView(this);
　　label.setText("Leaks are bad");
　　if (sBackground == null) {
　　　　sBackground = getDrawable(R.drawable.large_bitmap);
　　}
　　label.setBackgroundDrawable(sBackground);
　　setContentView(label);
}
sBackground 是一個靜態的變量，可是咱們發現，咱們並無顯式的保存Contex 的引用，可是，當Drawable
與View 鏈接以後，Drawable 就將View 設置爲一個回調，因爲View 中是包含Context 的引用的，因此，實
際上咱們依然保存了Context 的引用。這個引用鏈以下：Drawable->TextView->Context
因此，最終該Context 也沒有獲得釋放，發生了內存泄露。
針對static 的解決方案
① 應該儘可能避免static 成員變量引用資源耗費過多的實例，好比Context。
② 此時的Context 儘可能使用ApplicationContext，由於Application 的Context 的生命週期比較長，引用它不會出現內存泄露的問題。
③ 使用WeakReference 代替強引用。好比可使用WeakReference<Context> mContextRef;

四、線程致使內存溢出
線程產生內存泄露的主要緣由在於線程生命週期的不可控。咱們來考慮下面一段代碼。

public class MyActivity extends Activity {
　　@Override
　　public void onCreate(Bundle savedInstanceState) {
　　super.onCreate(savedInstanceState);
　　setContentView(R.layout.main);
　　new MyThread().start();
　　}
private class MyThread extends Thread{
　　@Override
　　public void run() {
　　super.run();
　　//do somthing
　　　　}
　　}
}
這段代碼很日常也很簡單，是咱們常用的形式。咱們思考一個問題：假設MyThread 的run 函數是一個很費
時的操做，當咱們開啓該線程後，將設備的橫屏變爲了豎屏，通常狀況下當屏幕轉換時會從新建立Activity，按照我
們的想法，老的Activity 應該會被銷燬纔對，然而事實上並不是如此。
因爲咱們的線程是Activity 的內部類，因此MyThread 中保存了Activity 的一個引用，當MyThread 的run 函
數沒有結束時，MyThread 是不會被銷燬的，所以它所引用的老的Activity 也不會被銷燬，所以就出現了內存泄露的問題。

有些人喜歡用Android 提供的AsyncTask，但事實上AsyncTask 的問題更加嚴重，Thread 只有在run 函數不結
束時纔出現這種內存泄露問題，然而AsyncTask 內部的實現機制是運用了ThreadPoolExcutor,該類產生的Thread 對
象的生命週期是不肯定的，是應用程序沒法控制的，所以若是AsyncTask 做爲Activity 的內部類，就更容易出現內存泄露的問題。
針對這種線程致使的內存泄露問題的解決方案：
①  將線程的內部類，改成靜態內部類（由於非靜態內部類擁有外部類對象的強引用，而靜態類則不擁有）。
②在線程內部採用弱引用保存Context 引用。

 

五、Handler內存泄漏
Handler做爲內部類存在於Activity中，可是Handler生命週期與Activity生命週期每每並非相同的，好比當Handler對象有Message在排隊，則沒法釋放，進而致使本該釋放的Acitivity也沒有辦法進行回收。 解決辦法：

① 在onDestroy裏移除msg或callback

② 聲明handler爲static類，這樣內部類就再也不持有外部類的引用了，就不會阻塞Activity的釋放

③ 若是內部類實在須要用到外部類的對象，可在其內部聲明一個弱引用引用外部類。

 

六、使用application的context來替代activity

這是一個很隱晦的內存泄漏的狀況。有一種簡單的方法來避免context相關的內存泄漏，最顯著地一個是避免context逃出他本身的範圍以外，使用Application context，這個context的生存週期和你的應用的生存週期同樣長，而不是取決於activity的生存週期。若是你想保持一個長期生存的對象，而且這個對象須要一個context,記得使用application對象。

 

七、集合中對象沒清理形成的內存泄漏

咱們一般把一些對象的引用加入到了集合中，當咱們不須要該對象時，並無把它的引用從集合中清理掉，這樣這個集合就會愈來愈大。

若是這個集合是static的話，那狀況就更嚴重了。

 

附： 

1. 微信團隊原創分享：Android內存泄漏監控和優化技巧總結

2. Android內存泄漏的檢測流程、捕捉以及分析