Linux内存进程无法杀死我的Android应用程序

Question

这是在使用Android 4.0.2平台的自定义版本的嵌入式系统上发生的。我看到我们的一个Android活动应用程序增长到大约400MB（调用“ps”时的rss大小）并被Linux OOM杀手杀死。 android平台的最大堆大小设置为62M。我不知道Dalvik VM如何让活动增长到400MB。

当堆达到大约60MB时，应用程序是否应该让Java内存不足？ 我们在logcat日志或anr跟踪中看不到这些Java异常。

我们实现了一个示例活动，它按顺序分配字节数组并将每个字节设置为虚拟值。当活动分配大约60MB时，我们确实看到了Outofmemory异常。

android中的分配路径是否计入堆预算？ 该活动呈现从网站下载的位图png。

以下是我们平台上的“getprop”结果。

$ adb shell getprop | grep -i heap

我很欣赏任何指示。

由于

编辑： 注意： 下面是ps输出。 Pss和Uss大约在316M左右。

                             PID      Vss      Rss      Pss    Uss    cmdline
logcat: hd[0]: pexecd(65):   982  351512K  351316K  326300K  316632K  mytest.home^M
logcat: hd[0]: pexecd(65):   660  679916K   61044K   57200K   56952K  ./videngine^M

RAM: 741764K total, 20320K free, 2148K buffers, 80104K cached, 24964K shmem, 10368K slab

Answer 1

本机代码中的直接分配不计入该Java堆总数。可能还有其他可能性（可能是从文件映射和填充的页面？）。

如果您有自定义的Android构建，您可以设置OOM杀手值以保留您自己的应用程序。

Answer 2

  

我看到我们的一个Android活动应用程序增长到大约400MB（调用“ps”时的rss大小）

引用Dianne Hackborn关于Android上ps的输出：“Vss和Rss列基本上是噪音（这些是过程的直接地址空间和RAM使用情况，如果你加起来的话跨进程的RAM使用量会得到一个非常大的数字）“

我衷心鼓励您阅读her epic SO answer on measuring an app's memory footprint。值得注意的是，除了上面引用的引用之外，Rss在她的分析中没有任何作用。因此，我建议不要担心Rss并关注其他指标。

Answer 3

您可以通过以下方式了解应用正在使用的内存。

转到DDMS，通过单击如下所示的图标来创建堆转储：

接下来，使用androir-sdk / tools文件夹中的hprof-conv工具将HP格式的HPROF转换为常规的HPROF格式。

接下来，使用Eclipse Memory Analyser（MAT）打开堆转储，然后查看支配树，您将看到应用程序强制Dalvik垃圾收集器（GC）保留的变量列表。右键单击它们并转到“路径GC根”，“排除弱引用”，将显示保持这些对象存活的引用。查看并查看是否有任何过期的引用被保留为内存泄漏。

您可以在Android应用程序中查看有关查找内存泄漏的详细方法this video。