1.static變量引起的內存泄漏
因為static變量的生命周期是在類加載時開始 類卸載時結束，也就是說static變量是在程序進程死亡時才釋放，如果在static變量中 引用了Activity 那么 這個Activity由於被引用，便會隨static變量的生命周期一樣，一直無法被釋放，造成內存泄漏。
解決辦法：
在Activity被靜態變量引用時，使用 getApplicationContext 因為Application生命周期從程序開始到結束，和static變量的一樣。注意有些場景不能使用Application的Context 代替Activity的Context，比如傳入Context構建靜態的ProgressDialog對象，ProgressDialog要依附父View而存在，Application的Context 中沒有View，這是只能繼續使用Activity的Context；解決方法，可以換成在改Activity的OnDestroy方法執行時，將靜態的ProgressDialog對象設為null。這樣它不再擁有Activity的引用，Activity可以被及時回收。
2.線程造成的內存泄漏
類似於上述例子中的情況，線程執行時間很長，及時Activity跳出還會執行，因為線程或者Runnable是Acticvity內部類，因此握有Activity的實例(因為創建內部類必須依靠外部類)，因此造成Activity無法釋放。
AsyncTask 有線程池，問題更嚴重
解決辦法：
1.合理安排線程執行的時間，控制線程在Activity結束前結束。
2.將內部類改為靜態內部類，並使用弱引用WeakReference來保存Activity實例 因為弱引用 只要GC發現了 就會回收它 ，因此可盡快回收
3.BitMap占用過多內存
bitmap的解析需要占用內存，但是內存只提供8M的空間給BitMap，如果圖片過多，並且沒有及時 recycle bitmap 那么就會造成內存溢出。
解決辦法：
及時recycle 壓縮圖片之后加載圖片
4.資源未被及時關閉造成的內存泄漏
比如一些Cursor 沒有及時close 會保存有Activity的引用，導致內存泄漏
解決辦法：
在onDestory方法中及時 close即可
5.Handler的使用造成的內存泄漏
由於在Handler的使用中，handler會發送message對象到 MessageQueue中 然后 Looper會輪詢MessageQueue 然后取出Message執行，但是如果一個Message長時間沒被取出執行（比如執行了Handler的postDelayed()方法），那么由於 Message中有 Handler的引用，而 Handler 一般來說也是內部類對象，Message引用 Handler ，Handler引用 Activity 這樣 使得 Activity無法回收。
解決辦法：
依舊使用 靜態內部類+弱引用的方式 可解決
其中還有一些關於 集合對象沒移除，注冊的對象沒反注冊，代碼壓力的問題也可能產生內存泄漏，但是使用上述的幾種解決辦法一般都是可以解決的。