如何判斷一個Android應用程序是否確實在泄漏內存？

在開發應用程序時，我注意到它最終崩潰，因爲JVM無法分配更多內存。使用adb shell dumpsys meminfo命令，我可以看到分配的本地堆增長，同時切換活動，直到它接近16M時，它崩潰了。我相信我現在已經修正了代碼來阻止這種情況的發生，但是我注意到由..meminfo返回的數字有所不同，現在一般似乎略有上升。如何判斷一個Android應用程序是否確實在泄漏內存？

基本上我不知道他們是否應該在我啓動並停止應用程序時返回相同的值。我有這些數字，我不知道他們是否意味着我有內存泄漏與否：

在主屏幕，內存（PID看到DDMS）應用程序，但沒有運行

亞行外殼dumpsys meminfo中（相關PID）給出：

    native dalvik other total 
      size:  5248  4039  N/A  9287 
     allocated:  5227  3297  N/A  8524 
      free:  12  742  N/A  754 
      (Pss):  2183  3534  1726  7443 
    (shared dirty):  1976  4640  876  7492 
    (priv dirty):  2040  1664  940  4644

應用從主屏幕開始，acivities開始依次爲：

閃屏 - >選擇模式 - >活動1，那麼所有的退了出去使用返回按鈕，直到回到家裏現在creen

meminfo中：

    native dalvik other total 
      size:  5572  4231  N/A  9803 
     allocated:  5497  3153  N/A  8650 
      free:  74  1078  N/A  1152 
      (Pss):  2479  3614  1742  7835 
    (shared dirty):  1976  4632  876  7484 
    (priv dirty):  2336  1740  956  5032

過程重複：

    native dalvik other total 
      size:  5696  4231  N/A  9927 
     allocated:  5211  2949  N/A  8160 
      free:  392  1282  N/A  1674 
      (Pss):  2515  3713  1742  7970 
    (shared dirty):  1976  4632  876  7484 
    (priv dirty):  2372  1840  956  5168

Eclipse的內存分析工具（我沒有找到所有的信息）以下「泄漏嫌疑人的報道：

3,143 instances of "java.lang.Class", loaded by "<system class loader>" occupy 736,760 (35.69%) bytes. 

Biggest instances: 

class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ 0x40158fe0 - 165,488 (8.02%) bytes. 
class android.text.Html$HtmlParser @ 0x400eebd8 - 126,592 (6.13%) bytes. 
class com.google.googlenav.proto.GmmMessageTypes @ 0x43d183d8 - 56,944 (2.76%) bytes. 
class org.apache.harmony.security.fortress.Services @ 0x40071430 - 51,456 (2.49%) bytes. 
class android.content.res.Resources @ 0x4004df38 - 33,584 (1.63%) bytes. 
class android.text.AutoText @ 0x400f23c8 - 31,344 (1.52%) bytes. 



Keywords 
java.lang.Class 


Details » 
    Problem Suspect 2 
8,067 instances of "java.lang.String", loaded by "<system class loader>" occupy 497,304 (24.09%) bytes. 

Keywords 
java.lang.String 


Details » 
    Problem Suspect 3 
54 instances of "org.bouncycastle.jce.provider.X509CertificateObject", loaded by "<system class loader>" occupy 256,024 (12.40%) bytes. These instances are referenced from one instance of "java.util.HashMap$HashMapEntry[]", loaded by "<system class loader>" 

Keywords 
org.bouncycastle.jce.provider.X509CertificateObject 
java.util.HashMap$HashMapEntry[]

所有意見將會感激地收到

來源

2011-02-23 NickT

請參閱此相關的問題：http://stackoverflow.com/questions/1147172/what-android-tools-and-methods最好找到內存資源泄漏 – 2011-02-23 22:34:24

@Mayra：謝謝你的指針。 '分配跟蹤器'看起來很有前景。我明天會調查一下。 – NickT 2011-02-23 23:03:24

接收機將導致內存的註冊和註銷泄漏

至於如果你已經註冊與registerReceiver（接收的例子），並在應用中的自我嘗試阿恩註冊它沒有做註銷然後會導致你太內存泄漏問題。

從調試和錯誤修正中瞭解了這件事。

來源

2011-02-24 09:09:08

沿着這些路線，還可以在BroadcastReceiver中查看[setDebugUnregister]（http://developer.android.com/reference/android/content/BroadcastReceiver.html）。 – greg7gkb 2012-09-06 01:44:16

根據我在創建Android應用程序方面的經驗，操作系統似乎在內存中留下了大量垃圾。但是，當設備需要重要的東西時，它會（幾乎不分青紅皁白地）採取任何需要的東西。即使它會覆蓋另一個當前打開的應用程序中的數據。除此之外，背景中還可能有其他一些事情會影響您的數字，所以我不相信我們可以從中得出任何確鑿的信息。如果你創建的應用程序正在泄漏，那麼很可能你正在做的事情會導致任何其他基於Java的環境中的內存泄漏。像這樣的文章：http://www.ibm.com/developerworks/library/j-leaks/應該有助於解決大多數泄漏問題。

來源

2011-03-01 03:49:30 CuddleBunny

如果我遇到與我的應用程序的內存問題，我正在使用包含在android開發工具中的ddbms工具的獨立版本。

看一看這個鏈接：http://android-developers.blogspot.com/2009/02/track-memory-allocations.html

有了這個工具，你可以看一下從「的觀點在Java點」的內存消耗，所以你可以看到哪些物體堵住大部分的內存。這將使您能夠精確定位所遇到的內存泄漏並優化代碼。

你給輸出只給出所有使用的內存的概述在應用程序但不知道如何使用它。

來源

2011-03-18 08:30:25 Chris

在MAT中，我幾乎從未遇到實際上是泄漏的「泄漏可疑」。你真正想要的是在GC掃描之後保留的對象，這不應該是。

例如，假設我有一個儀表板的活動，可以啓動活動A和B.我啓動控制板，然後啓動活性的，按下後退按鈕，啓動活動B，並按下返回按鈕。

使用Eclipse調試視圖，您可以通過「原因GC」按鈕強制GC回收事件。現在，單擊「轉儲HPROF文件」按鈕並啓動MAT。點擊「Dominator Tree」鏈接。

在這一點上，我希望任何與活動A & B相關聯的內存都被收集爲垃圾，除非代碼中有錯誤。通常情況下，這就是我在應用程序中被認定爲「內存泄漏」的原因。