移動端測試===Android記憶體泄露和GC機制

標籤：人工   ext   jpg   廣播   項目開發   圖片   ++   一起   合并   

本文轉自：https://www.testwo.com/article/1153

 

1、前言

Hello，小夥伴們，相信大家在項目測試中都遇到過記憶體泄露問題，小編也著實爬過很多坑。比如小編所測項目，更換了多執行個體版本的sdk，橫豎屏切換後有MapView沒有銷毀，導致記憶體泄露。小編測試手錶項目，因為手錶記憶體有限，測試中常遇到應用無響應或者閃退，故而小編對GC機制進行了進一步學習瞭解。

        本文先對Android記憶體記憶體回收機制進行介紹，之後對分析、定位記憶體泄露常用的測試方法進行總結，分享給大家。

 

2、Android記憶體記憶體回收（GC機制）

2.1綜述

        Android 應用中預設有三個線程：“main”主線程、GC線程、和Heap線程，而且在GC線程啟動並執行過程中，主線程會中斷執行。Java程式與C/C++等原生程式的一個不同點就是，Java虛擬機器在運行Java程式的過程中，可以自動回收不再使用的對象執行個體，從而避免了程式員人工管理記憶體的繁瑣工作。如果裝置是單核CPU裝置，一次只能運行一個線程，因此在GC線程啟動並執行時候，必須中斷主線程。但是如果裝置上有多核CPU，即主線程可以和GC線程同時運行，在這種情況下執行GC，會不會中斷主線程呢？答案是會的。

        雖然有不同的記憶體記憶體回收實現演算法，但有些演算法需要中斷其他Java線程的執行，如果中斷的時間過長，給使用者的感覺就是應用的響應速度變的越來越慢，甚至有可能出現ANR錯誤。

2.2Android記憶體管理原理

2.2.1垃圾記憶體回收演算法

    常見的記憶體回收演算法引用計數法、標註並清理、拷貝、逐代回收，其中android系統採用的是標註並清理和拷貝GC，並不是大多數JVM實現中採用的逐代回收演算法。在很多記憶體回收實現中，常常可以看到將幾種演算法合并使用的情境。

 

2.2.2Logcat中的GC資訊

 

Logcat中GC輸出的資訊格式如下：

Dalvik虛擬機器的Log資訊

在Davlik虛擬機器(非ART)中，每一次記憶體回收都會返回一條類似的資訊。例子如下：

 

D/dalvikvm( 9050): GC_CONCURRENT freed2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

它們大致可以分成如下幾個部分：

 

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

[GC的原因][回收的記憶體總量][GC堆記憶體的統計資訊][外部記憶體的統計資訊][停機時間]

各個欄位的含義如下：

(1)、GC的原因，也就是GC類別,可分為：

1.  GC_FOR_MALLOC 表示記憶體記憶體回收過程是因為在分配記憶體空間如（建立對象）時，記憶體不夠而引發的。系統會殺死應用的進程並且回收所有記憶體。

2.    GC_CONCURRENT 表明GC是在記憶體使用量率達到一定的警戒線時，自動觸發的。

3. GC_EXPLICIT 表明GC是被顯式請求觸發的。

4. GC_EXTERNAL_ALLOC在API版本10(Android3.0)以下的時候的記憶體回收機制。3.0以上版本所有的記憶體都在Dalvik堆中分配。它是用來回收dalvik虛擬機器以外的記憶體（例如Bitmap中的記憶體或者NIObuffer中的記憶體）。

5.  GC_HPROF_DUMP_HEAP 當請求產生HPROF檔案來分析記憶體的時候會觸發此類記憶體回收

(2)、回收的記憶體總量

(3)、回收後GC記憶體對的統計資訊

堆中可用空間所佔的百分比和（堆中對象的數量）/（堆的大小）

(4)、外部記憶體的統計資訊

系統API版本10以下的系統中，Dalvik虛擬機器堆外（分配的記憶體）/（限制的記憶體量）

 

(5)、GC造成的應用其他線程中斷的時間

Concurrent類型的記憶體回收有兩次暫停時間：一次發生在開始，另一次發生在結束。堆的內容越多，暫停時間越長。

觀察這些Log資訊，如果heapstats中的數值(堆中對象數量)/(堆的大小)越來越大，那麼應用中很有可能存在記憶體流失。

(6)、總結

一般根據下面兩個線索判斷應用是否存在記憶體泄露問題

1、應用運行一段時間後，因為內部拋出java.lang.OutOfMemoryError異常而崩潰；

2、在logcat中看到頻繁的GC資訊；

 

 

3、記憶體泄露

3.1什麼是記憶體流失

 

 

對於不同的語言平台來說，進行標記回收記憶體的演算法是不一樣的，像Android（Java）則採用GC-Root的標記回收演算法。（Google 2011的IO大會）展示了Android記憶體的回收管理原則。

 

圖中的每個圓節點代表對象的記憶體資源，箭頭代表可達路徑。當圓節點與GC Roots存在可達路徑時，表示當前資源正被引用，虛擬機器是無法對其進行回收的（中的黃色節點）。反過來，如果圓節點與GC Roots不存在可達路徑，則意味著這塊對象的記憶體資源不再被程式引用，系統虛擬機器可以在GC過程中將其回收掉。

        有了上面的記憶體回收的栗子，那麼接下來就可以說說什麼是記憶體流失了。

 

        從定義上講，Android（Java）平台的記憶體流失是指沒有用的對象資源任與GC-Root保持可達路徑，導致系統無法進行回收。舉一個最簡單的栗子，我們在Activity的onCreate函數中註冊一個廣播接收者，但是在onDestory函數中並沒有執行反註冊，當Activity被finish掉時，Activity對象已經走完了自身的生命週期，應該被資源回收釋放掉，但由於沒有反註冊，此時Activity和GC-Root間仍然有可達路徑存在，導致Activity雖然被銷毀，但是所佔用的記憶體資源卻無法被回收掉。

 

 

3.2泄漏的源頭

     這裡，將其歸位以下三類：

    (1).   自身編碼引起

    由項目開發人員自身的編碼造成。

    (2).   第三方代碼引起

    這裡的第三方程式碼封裝含兩類：第三方非開源的SDK和開源的第三方架構。

    (3).   系統原因

    由Android系統自身造成的泄漏，如像WebView、InputMethodManager等引起的問題，還有某些第三方ROM存在的問題。

3.3泄漏的定位

      記憶體流失不像閃退的BUG，排查起來相對要比較困難些，比較極端的情況是當應用OOM了才發現存在記憶體流失問題，對使用者影響太大。為此，我們希望在測試過程中能夠儘早發現問題。下面介紹幾種分析記憶體泄露問題的工具、方法。

3.3.1靜態程式碼分析工具 —— Lint

        Lint是 Android Studio內建的工具，使用姿勢很簡單Analyze -> Inspect Code然後選擇想要掃面的地區即可。

 對可能引起泄漏的編碼，Lint都會進行溫馨提示。

 

   關於Lint，大家可以自行拓展學習。

 

3.3.2Android Memory Monitor

        Android Studio提供的工具，用於監控應用的記憶體使用量狀態，在開發中也是非常實用的工具，可以用來列印出記憶體的狀態資訊。

 

 列印獲得的記憶體資訊如下，可以通過右上方的綠色三角形按鈕去分析泄漏的Activity和一些重複的字串，目前只支援這兩個，希望Google後面能夠加入更多可選分析規則。

3.3.3adb shell 命令

      使用 adb shell dumpsys meminfo [PackageName]，可以列印出指定包名的應用記憶體資訊。

  使用該命令可以很直觀的觀察到Activity的泄漏問題，是平常分析比較常用的一種方式。除了使用命令外，Android Studio也提供了下面的功能，和使用命令是一樣效果的。

 

以上就是我在做記憶體流失定位分析的時候會用到的工具和方法，通常都是結合起來用，使用多個工具互補分析問題可以提高我們的效率和最終取得的效果。

以上，就是小編做記憶體流失分析的一些心得總結，如有錯誤和不足，還請大家指出。如果大家針對記憶體泄露測試、分析，還有什麼建議或者心得，歡迎留言、一起探討~~O(∩_∩)O~~

移動端測試===Android記憶體泄露和GC機制（轉）