Android应用内存问题答案

【问题标题】：Android app memory issueAndroid应用内存问题
【发布时间】：2014-02-06 19:18:49
【问题描述】：

我正在制作用于观看电影的应用程序，它在网格、列表和水平滚动视图中显示类别和电影的图像。应用程序有几个活动，每个活动都显示图像。 Proglem 是当用户仅向前更改活动时，在某一时刻应用程序崩溃并出现 OutOfMemory 异常。

使用堆和 MAT 工具，我发现位图在每个活动中都使用大量的堆内存。在相同的手机上，如三星 Galaxy S4 和具有全高清显示屏的阿尔卡特 OneTouch Idol，应用程序仅在 2-3 次活动中崩溃。这太疯狂了:)

所以，我的问题是，我怎样才能克服这个内存问题？我知道这是普通的 Android 问题，但我必须采取一些措施来解决此问题。

每个图像都针对其位置进行了优化（图像尺寸在附加到图像视图之前被精确测量）。干杯。

【问题讨论】：

发布关于位图的代码。
抱歉，系统太大，无法发布代码。 :) 基本上，我必须回收堆内存，而不是当用户继续进行活动时。我需要有人向我解释一下，当活动暂停并置于后台并显示其他活动时，视图及其位图和内存一般会发生什么。

标签： android memory-management out-of-memory

【解决方案1】：

做一些分析。

您没有提供任何代码或日志。所以，将告诉您我遵循的基本方法。

开始你的第一个活动。继续运行 adb shell dumpsys "PID" or "PackageName" 。

在重现活动时获取信息。执行adb shell " while true ; do dumpsys meminfo 22188 ; done ; " > dumpsysOfsmthn.txt

* MEMINFO in pid 22188 [com.sec.android.smthn] **

                   Pss  Private  Private  Swapped     Heap     Heap     Heap

                 Total    Dirty    Clean    Dirty     Size    Alloc     Free

                ------   ------   ------   ------   ------   ------   ------

  Native Heap       44       44        0        0    11132    10455      184

  Dalvik Heap    19189    18804        0        0    25660    19221     6439

 Dalvik Other     3891     3828        0        0                           

        Stack      200      200        0        0                           

       Ashmem        2        0        0        0                           

    Other dev     8168     7844        4        0                           

     .so mmap     1990     1032      508        0                           

    .jar mmap        5        0        4        0                           

    .apk mmap      315        0      124        0                           

    .ttf mmap       21        0        4        0                           

    .dex mmap     6553      248     5584        0                           

   Other mmap       90        4       20        0                           

      Unknown     5743     5740        0        0                           

        TOTAL    46211    37744     6248        0    36792    29676     6623



 Objects

               Views:       39         ViewRootImpl:        1

         AppContexts:        4           Activities:        1

              Assets:        3        AssetManagers:        3

       Local Binders:       78        Proxy Binders:       42

    Death Recipients:        2

     OpenSSL Sockets:        0



 SQL

         MEMORY_USED:      286

  PAGECACHE_OVERFLOW:       53          MALLOC_SIZE:       62



 DATABASES

      pgsz     dbsz   Lookaside(b)          cache  Dbname

         4       24             53         2/17/3  /data/data/com.sec.android.smthn/databases/sns.db

         4       32             55         1/13/2  /data/data/com.sec.android.smthn/databases/picasa.db

         4       36             27        10/17/3  /data/data/com.sec.android.smthn/databases/local.db

Applications Memory Usage (kB):

Uptime: 31556347 Realtime: 96096816

检查部分的哪一部分不断增加。

它可以是 ViewRootImpl 或活动上下文或任何东西。

以上信息可能会为您提供一些线索。

如前所述，使用 MAT 或 JHAT 进行 heapdump 分析。垫是真棒工具恕我直言。

you should look for memory leaks caused by:

Long-lived references to an Activity, Context, View, Drawable, and other objects that may hold a reference to the container Activity or Context.
Non-static inner classes (such as a Runnable, which can hold the Activity instance).
Caches that hold objects longer than necessary.

任何对象都可能导致泄漏。通常位图很大。如果内存不足很容易发生，那么您需要检查位图等重物。

对于MAT和Leaks的理解Click this

还有this。

除了上述内容之外，您还可以使用 DDMS 分配跟踪器来获取更多线索 > 是的，没有什么比 MAT 更好的数据了。

还可以查看这篇文章。 Very informative

【讨论】：