来自“adb shell dumpsys meminfo my-app-name"的profile详解? [英] Detailed explanation for profile from "adb shell dumpsys meminfo my-app-name"?

问题描述

谁能给我详细解释一下adb shell dumpsys meminfo my-app-name得到的profile?

Can anyone give me a detailed explanation about the profile gotten by adb shell dumpsys meminfo my-app-name?

结果如下 如何在 Android 中发现我的应用程序的内存使用情况?:

** MEMINFO in pid 890 [process-name] **
                    native   dalvik    other    total
            size:    10940     7047      N/A    17987
       allocated:     8943     5516      N/A    14459
            free:      336     1531      N/A     1867
           (Pss):     4585     9282    11916    25783
  (shared dirty):     2184     3596      916     6696
    (priv dirty):     4504     5956     7456    17916

 Objects
           Views:      149        ViewRoots:        4
     AppContexts:       13       Activities:        0
          Assets:        4    AssetManagers:        4
   Local Binders:      141    Proxy Binders:      158
Death Recipients:       49
 OpenSSL Sockets:        0

 SQL
            heap:      205          dbFiles:        0
       numPagers:        0   inactivePageKB:        0
    activePageKB:        0

每一列(native、dalvik、other、total)是什么意思?尤其是其他"列是什么(我不知道除了原生和 dalvik 之外是什么)?如果有人可以举一个具体的例子来详细说明这一点，那就太好了.例如我有一个应用程序 A.A 有自己的对象 obj_private 和自己的本机库 lib_private.此外，A 引用了 Android 框架 obj_shared 的一些对象和 Android 框架 lib_shared 的一些原生库.并且 obj_shared 引用了 Android lib_shared_indirect 的一些原生库.对于这种情况，我可以说这些吗?

What does the each column (native, dalvik, other, total) mean? especially what's the "other" column (I can't figure out what's that besides native and dalvik)? It would be great if someone can give a concrete example to elaborate about this. e.g. I have an app A. A has its own object obj_private and its own native library lib_private. Besides, A references some object of Android framework obj_shared and some native lib of Android framework lib_shared. And obj_shared reference some native lib of Android lib_shared_indirect. For this case, can I say those?

1. 总大小"等于obj_private + lib_private + obj_shared + lib_shared + lib_shared_indirect"使用的所有内存.
2. 私有脏"等于被obj_private + lib_private"弄脏的内存

我们想要明确这一点的原因是:与之前的版本相比，我们最新版本的应用程序的运行时内存出现了一些不寻常的增加.当我使用 dumpsys meminfo 时，我发现native"和other"列显着增加.但是新版本的变化只和java有关，其他"栏目没有说明.我用谷歌搜索了这个并没有找到任何文件.我还尝试阅读 adb 的源代码.但是我发现像我这样的新手很容易迷失在源代码中.所以我在这里发布这个问题，以防有人可以提供帮助.

The reason we want to make clear about this is: there are some unusual runtime-memory increase of our latest version app compared to previous version. And when I used the dumpsys meminfo, I found the columns "native" and "other" increased dramatically. But the change of the new version is only related to java and there is no explain about the "other" column. I googled this and found no document. I also tried to read the source code of the adb. But I found it's easy to get lost in the source code for novice like me. So I post this question here in case that some one can help.

推荐答案

我们现在有更多关于 Android 中 RAM 使用的文档，其中详细介绍了不同 RAM 数字的含义:管理应用的内存.特别是，请查看此处讨论 meminfo 转储关键部分的页面中间:调查您的 RAM 使用情况.

We now have more documentation covering RAM use in Android that goes into some detail about what different RAM numbers mean: Managing Your App's Memory. In particular, have a look at the middle of the page here that discusses key parts of the meminfo dump: Investigating Your RAM Usage.

看起来您的 meminfo 输出来自相当老的 Android 版本，在我们识别出许多不同类型的分配之前.要将您所看到的内容映射到当前文档，只需将其他"视为现代转储显示的除本机和 dalvik 部分之外的所有内容.在您的转储中，我相信您的 dalvik 部分实际上是现代的Dalvik Heap"和Dalvik Other"的组合.

It looks like your meminfo output is from a fairly old version of Android, before we could identify many of the different types of allocations. To map what you are seeing to the current documentation, just consider "other" to be everything that the modern dump shows besides the native and dalvik sections. In your dump, I believe your dalvik section is actually the modern "Dalvik Heap" and "Dalvik Other" put together.

就本地和其他部分越来越多地仅在 Java 代码中进行更改之后，是的，这肯定会发生.Android Java API 的许多部分位于本机分配之上，也可能导致其他分配.这方面的经典示例是 Gingerbread 和更早版本上的位图，其中位图的数据是本机分配，而不是像现在这样在 Java 堆中分配数组.

As far as the native and other sections increasingly after only a change in the Java code, yes this can certainly happen. A number of parts of the Android Java API sits on top of native allocations, and can also cause other allocations. The classic example of this would be bitmaps on Gingerbread and earlier, where the data for the bitmap was a native allocation rather than being an array allocations in the Java heap as it is today.

您增加的其他分配可能是由于您将在最新版本的数据中看到的许多事情 - 内存支持游标、ashmem 的共享内存区域、为您分配东西的设备，例如图形纹理等等.有很多事情很难说会发生什么，这就是为什么这些天报告更加详细的原因.(即使在那里，我们仍然有很多东西被折叠成未知的.)

Your increased other allocations can be due to a number of things as you will see listed in the more recent versions of the data -- the memory backing cursors, shared memory areas from ashmem, devices allocating things for you such as graphics textures, etc. There are so many things it can be hard to say what might be going on, which is why the report is more detailed these days. (And even there, we still have a number of things that get collapsed in to unknown.)

为了调试它，您可能希望查看 Java 堆中是否存在泄漏对象.由于对象的实际分配不在 Java 堆中，这当然会很棘手.我建议在你的应用程序早期进行堆转储，做任何导致其 RAM 占用增加的事情，之后进行堆转储，并查看哪些对象计数增加了.参考文档显示了如何将堆转储与 MAT 进行比较.

For debugging this, you probably want to look at your Java heap for leaked objects. Since the actual allocation for the object is not in the Java heap, this can be tricky of course. I'd suggest taking a heap dump early in your app, do whatever you do that causes its RAM footprint to increase, take a heap dump after that, and look for what object counts have increased. The referenced documentation shows how to compare heap dumps with MAT.

此外，当您仅将 Java 堆视为一般分析时(进行差异分析时除外)，请始终确保按照那里的说明去除堆的 zygote 部分.正如文档所述，每个进程都有大量来自 zygote 的分配，但这些分配在所有进程之间共享，因此通常与堆分析无关.我经常看到有人担心，因为他们在他们的应用程序中看到很多非常大的位图，系统似乎已经分配给他们，并认为这是在他们的应用程序中使用 RAM 的主要事情，如果不是，那只是来自 zygote 的共享分配.

Also when you are looking at your Java heap just as a general analysis (except when doing diffs), always be sure to follow the instructions there for stripping out the zygote part of the heap. As the documentation mentions, every process has a large number of allocations from zygote, but these are shared across all processes so not generally relevant for heap analysis. I very often see people concerned because they see a lot of very large bitmaps in their app that the system seems to have allocated on them, and think that is the major thing using RAM in their app, when it is not, it is just the shared allocations from zygote.

这篇关于来自“adb shell dumpsys meminfo my-app-name"的profile详解?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！