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