App 性能優化系列：
Android App 性能優化(二)----內存泄露（Memory Leak）
Android App 性能優化(一)----布局優化
一. 什么是內存泄露
內存泄漏（Memory Leak）是指程序中己動態分配的堆內存由于某種原因程序未釋放或無法釋放，造成系統內存的浪費，導致程序運行速度減慢甚至系統崩潰等嚴重后果。
當一個對象使已經用完不需要時，這時候應該被回收才對，但由于另外一個正在使用的對象直接或者間接的持有它的引用從而導致它不能被回收，這時就會導致本應該被系統回收的內存不能被回收而占用著堆內存，內存泄漏就產生了；
二. 內存泄露對程序的影響
造成應用程序OOM的主要原因之一，當應用中多處地方內存泄漏時可能導致內存緊缺，如果當沒有內存可分配時就造成內存溢出，最終程序崩潰；
一般情況下程序在運行的過程中會不斷地去回收使用完的內存，但由于內存泄漏會導致內存過快的出現緊缺，這時可能會導致系統頻繁的GC，從而導致程序越來越卡，最終內存溢出崩潰；
內存溢出
OutOfMemoery，是指APP向系統申請超過最大閥值的內存請求，系統不會再分配多余的空間，就會造成OOM error。
三. Java 的內存管理
要分析內存泄露就必須要知道 Java 內存管理, 要知道對象的分配和回收.
在 Java 中，通過關鍵字 new 為每個對象申請內存空間，所有的對象都在堆中分配空間.
而內存的釋放是由垃圾回收器GC完成的，程序創建的每一個對象垃圾回收器GC都要對它的運行狀態進行監控, 包括對象的申請、賦值, 被引用等. 垃圾回收機制確實簡化了程序員的工作, 但同時也帶來了性能上的影響，這也是Java程序運行速度比較慢的重要原因.
垃圾回收器GC回收一個對象的條件是這個對象不再被引用, 具體怎么做到這點的就要去了解垃圾回收器的工作原理了, 下面簡單的介紹下目前常用的垃圾回收器的工作原理:
為了更好理解垃圾回收器GC的工作原理，我們可以將對象考慮為有向圖的頂點，將引用關系考慮為圖的有向邊，有向邊從引用者指向被引對象。另外，每個線程對象可以作為一個圖的起始頂點，例如大多程序從main進程開始執行，那么該圖就是以main進程頂點開始的一棵根樹。在這個有向圖中，根頂點可達的對象都是有效對象，GC將不回收這些對象。如果某個對象 (連通子圖)與這個根頂點不可達(注意，該圖為有向圖)，那么我們認為這個(這些)對象不再被引用，可以被GC回收. Java使用有向圖的方式進行內存管理，可以消除引用循環的問題.
Java 中的內存分配
- 靜態儲存區：
編譯時就分配好，在程序整個運行期間都存在, 存放在對象中用static定義的靜態成員；
- 棧區
(1)在堆中產生了一個對象后，還可以在棧中定義一個特殊的變量，讓棧中這個變量的取值等于對象在堆內存中的首地址，棧中的這個變量就成了對象的引用變量
(2). 在方法中定義的一些基本類型的變量數據和對象的引用變量都在方法的棧內存中分配, 當在一段代碼塊定義一個變量時，Java就在棧中為這個變量分配內存空間，當該方法執行完之后，Java會自動釋放掉該方法中定義的變量以及對象所分配的內存空間.
- 堆區
通常存放 new 出來的對象。由 Java 垃圾回收器回收。堆內存用來存放由new創建的對象和數組。 在堆中分配的內存，由Java虛擬機的自動垃圾回收器來管理。
當然java內存分配還有其他幾種, 比如常量池, 寄存器等, 但這些都和垃圾回收無關,暫不討論.
三. Java中四種引用類型
強引用(StrongReference)
如果一個對象具有強引用，它就不會被垃圾回收器回收, 即使當前內存空間不足，JVM 也不會回收它，而是拋出 OutOfMemoryError 錯誤，使程序異常終止。如果想中斷強引用和某個對象之間的關聯，可以顯式地將引用賦值為null，這樣JVM在合適的時間就會回收該對象;
軟引用(SoftReference)
在使用軟引用時，如果內存的空間足夠，軟引用就能繼續被使用，而不會被垃圾回收器回收，只有在內存不足時，軟引用才會被垃圾回收器回收。
軟引用基本上和弱引用差不多，只是相比弱引用，它阻止垃圾回收期回收其指向的對象的能力強一些。如果一個對象是弱引用可到達，那么這個對象會被垃圾回收器接下來的回收周期銷毀。但是如果是軟引用可以到達，那么這個對象只有當內存不足的時候才會被垃圾回收器回收。 軟引用可用來實現內存敏感的高速緩存
弱引用(WeakReference)
具有弱引用的對象擁有的生命周期更短暫，因為當 JVM 進行垃圾回收，一旦發現弱引用對象，無論當前內存空間是否充足，都會將弱引用回收。
Java使用WeakReference表示相應的對象為弱引用，垃圾回收器會幫你來決定引用的對象何時回收并且將對象從內存移除。
虛引用(PhantomReference)
如果一個對象僅持有虛引用，在任何時候都可能被垃圾回收，虛引用與軟引用和弱引用的一個區別在于：虛引用必須和引用隊列聯合使用，虛引用主要用來跟蹤對象 被垃圾回收的活動。
與其他幾種引用都不同，虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣，在任何時候都可能被垃圾回收器回收。
虛引用主要用來跟蹤對象被垃圾回收器回收的活動。虛引用與軟引用和弱引用的一個區別在于：虛引用必須和引用隊列 （ReferenceQueue）聯合使用。當垃圾回收器準備回收一個對象時，如果發現它還有虛引用，就會在回收對象的內存之前，把這個虛引用加入到與之關聯的引用隊列中。
程序可以通過判斷引用隊列中是否已經加入了虛引用，來了解被引用的對象是否將要被垃圾回收。如果程序發現某個虛引用已經被加入到引用隊列，那么就可以在所引用的對象的內存被回收之前采取必要的行動。
四. Android 中常見的內存泄漏
1. 單例造成的內存泄露
單例的靜態特性導致其生命周期同應用一樣長。
單例模式的靜態特性使得單例的生命周期和 Application 的生命周期一樣長，這就會導致如果一個對象已經不需要使用了，而單例對象還持有該對象的引用，那么這個對象將不能被正常回收，這就導致了內存泄漏了；
具體來說在Android中創建單例的時候有時需要傳入一個Context, 那么此時這個 Activity 就會被這個單例持有，就會造成 Activity 無法正常回收釋放。
請不要傳入 Activity 的 Context，而應該傳入 Application 的 Context，因為 Application 的 Context 生命周期與應用程序一樣長，所以就不會造成內存泄漏了。
解決方案：
將該屬性的引用方式改為弱引用; 如果傳入Context，使用ApplicationContext;
2. 非靜態內部類
在Java中，非靜態內部類和匿名類都會潛在的引用它們所屬的外部類，但是，靜態內部類卻不會。如果這個非靜態內部類實例做了一些耗時的操作，就會造成外圍對象不會被回收，從而導致內存泄漏。
非靜態內部內為什么會造成內存泄露?
內部類雖然和外部類寫在同一個文件中， 但是編譯完成后， 還是生成各自的class文件，內部類通過this訪問外部類的成員。
1 編譯器自動為內部類添加一個成員變量， 這個成員變量的類型和外部類的類型相同， 這個成員變量就是指向外部類對象(this)的引用；
2 編譯器自動為內部類的構造方法添加一個參數， 參數的類型是外部類的類型， 在構造方法內部使用這個參數為內部類中添加的成員變量賦值；
3 在調用內部類的構造函數初始化內部類對象時，會默認傳入外部類的引用。
解決方案：
將內部類變成靜態內部類; 如果有強引用Activity中的屬性，則將該屬性的引用方式改為弱引用; 在業務允許的情況下，當Activity執行onDestory時，結束這些耗時任務;
3. Context 的不正確使用
在Android應用程序中通常可以使用兩種Context對象：Activity和Application。當類或方法需要Context對象的時候常見的做法是使用第一個作為Context參數。這樣就意味著View對象對整個Activity保持引用，因此也就保持對Activty的所有的引用。 假設一個場景，當應用程序有個比較大的Bitmap類型的圖片，每次旋轉是都重新加載圖片所用的時間較多。為了提高屏幕旋轉是Activity的創建速度，最簡單的方法時將這個Bitmap對象使用Static修飾。 當一個Drawable綁定在View上，實際上這個View對象就會成為這份Drawable的一個Callback成員變量。而靜態變量的生命周期要長于Activity。導致了當旋轉屏幕時，Activity無法被回收，而造成內存泄露。
解決方案：
使用ApplicationContext代替ActivityContext，因為ApplicationContext會隨著應用程序的存在而存在，而不依賴于activity的生命周期；對Context的引用不要超過它本身的生命周期，慎重的對Context使用“static”關鍵字。Context里如果有線程，一定要在onDestroy()里及時停掉。
4. Handler引起的內存泄漏
當Handler中有延遲的的任務或是等待執行的任務隊列過長，由于消息持有對Handler的引用，而Handler又持有對其外部類的潛在引用，這條引用關系會一直保持到消息得到處理，而導致了Activity無法被垃圾回收器回收，而導致了內存泄露。
當使用內部類或者匿名類來創建Handler的時候，Handler對象會隱式地持有一個外部類對象(activity)的引用，而Handler通常會伴隨著一個耗時的后臺線程一起出現，這個后臺線程在任務執行完畢之后，通過消息機制通知Handler，然后Handler再更新界面。但是如果此時Activity退出，正常情況下，Activity不再被使用，它就有可能在GC檢查時被回收掉，但由于這時線程尚未執行完，而該線程持有Handler的引用，這個Handler又持有Activity的引用，就導致該Activity無法被回收，直到處理耗時任務的線程結束。
如果使用Handler的postDelayed()方法去開啟一個后臺線程時，在這個延遲任務沒有開啟之前都會有一條MessageQueue -> Message -> Handler -> Activity的引用鏈，導致你的Activity被持有引用而無法被回收。
解決辦法:
可以把Handler類放在單獨的類文件中，或者使用靜態內部類便可以避免泄露; 如果想在Handler內部去調用所在的Activity,那么可以在handler內部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式來達到斷開Handler與Activity之間存在引用關系的目的。
在Activity結束后，關閉線程，如果你的Handler是被delay的Message持有了引用，那么調用removeCallbacks方法來移除消息隊列。
5. 注冊監聽器的泄漏
系統服務可以通過Context.getSystemService 獲取，它們負責執行某些后臺任務，或者為硬件訪問提供接口。如果Context 對象想要在服務內部的事件發生時被通知，那就需要把自己注冊到服務的監聽器中。然而，這會讓服務持有Activity 的引用，如果在Activity onDestory時沒有釋放掉引用就會內存泄漏。
解決方案：
使用ApplicationContext代替ActivityContext; 在Activity執行onDestory時，調用反注冊;
6. Cursor，Stream沒有close，View沒有recyle
資源性對象比如(Cursor，File文件等)往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不僅存在于 java虛擬機內，還存在于java虛擬機外。如果我們僅僅是把它的引用設置為null,而不關閉它們，往往會造成內存泄漏。因為有些資源性對象，比如SQLiteCursor(在析構函數finalize(),如果我們沒有關閉它，它自己會調close()關閉)，如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對于資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然后才置為null. 在我們的程序退出時一定要確保我們的資源性對象已經關閉。
解決方案:
調用onRecycled()
7. 引用沒釋放
1. 注冊服務沒取消導致內存泄漏
ContentObserver，FileObserver在Activity onDeatory或者某類聲明周期結束之后一定要unregister掉，否則這個Activity類會被system強引用，不會被內存回收。
2. 集合中的對象沒有及時清理導致的內存泄露
當該集合為靜態的時候，那么在集合里面對象越來越多的時候，要及時清理不需要用到的對象。
解決方案：
在Activity退出之前，將集合里的東西clear，然后置為null，再退出程序。
8. WebView造成的泄露
當我們不要使用WebView對象時，應該調用它的destory()函數來銷毀它，并釋放其占用的內存，否則其占用的內存長期也不能被回收，從而造成內存泄露。
解決方案：
為webView開啟另外一個進程，通過AIDL與主線程進行通信，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀，從而達到內存的完整釋放。
9. 動畫
在屬性動畫中有一類無限循環動畫，如果在Activity中播放這類動畫并且在onDestroy中去停止動畫，那么這個動畫將會一直播放下去，這時候Activity會被View所持有，從而導致Activity無法被釋放。解決此類問題則是需要早Activity中onDestroy去去調用objectAnimator.cancel()來停止動畫。
10. Activity 泄漏
如果你持有一個未使用的 Activity 的引用，其實也就持有了 Activity 的布局，自然也就包含了所有的 View。最棘手的是持有靜態引用。別忘了，Activity 和 Fragment 都有自己的生命周期。一旦我們持有了靜態引用，Activity 和 Fragment 就不會被垃圾回收器清理掉了。這就是為什么靜態引用很危險。
參考
[1]http://blog.csdn.net/u013495603/article/details/50696170
