什么情況下會導致內存泄露(Memory Leak)？
Android 的虛擬機是基於寄存器的Dalvik，它的最大堆大小一般是16M，有的機器為24M。因此我們所能利用
的內存空間是有限的。如果我們的內存占用超過了一定的水平就會出現OutOfMemory 的錯誤。
內存溢出的幾點原因：
1、資源釋放問題
程序代碼的問題，長期保持某些資源，如Context、Cursor、IO 流的引用，資源得不到釋放造成內存泄露。
需要適當的釋放資源的情況，這些硬件資源可能包括：視頻、音頻、相機等。
2、廣播注冊后沒取消造成的內存泄漏
記得在activity銷毀的時候一定要取消廣播的注冊
3、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;
4、線程導致內存溢出
線程產生內存泄露的主要原因在於線程生命周期的不可控。我們來考慮下面一段代碼。
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 引用。
5、Handler內存泄漏
Handler作為內部類存在於Activity中，但是Handler生命周期與Activity生命周期往往並不是相同的，比如當Handler對象有Message在排隊，則無法釋放，進而導致本該釋放的Acitivity也沒有辦法進行回收。 解決辦法：
① 在onDestroy里移除msg或callback
② 聲明handler為static類，這樣內部類就不再持有外部類的引用了，就不會阻塞Activity的釋放
③ 如果內部類實在需要用到外部類的對象，可在其內部聲明一個弱引用引用外部類。
6、使用application的context來替代activity
這是一個很隱晦的內存泄漏的情況。有一種簡單的方法來避免context相關的內存泄漏，最顯著地一個是避免context逃出他自己的范圍之外，使用Application context，這個context的生存周期和你的應用的生存周期一樣長，而不是取決於activity的生存周期。如果你想保持一個長期生存的對象，並且這個對象需要一個context,記得使用application對象。
7、集合中對象沒清理造成的內存泄漏
我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。
如果這個集合是static的話，那情況就更嚴重了。
附：
1. Android內存泄漏的檢測流程、捕捉以及分析