Question

我运行了这个命令adb shell dumpsys meminfo <package_name>并得到了

 Objects
               Views:       74         ViewRootImpl:        1
         AppContexts:        3           Activities:        1
              Assets:        4        AssetManagers:        4
       Local Binders:       11        Proxy Binders:       20
    Death Recipients:        0
     OpenSSL Sockets:        2

 SQL
         MEMORY_USED:        0   
  PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0

按下后退按钮并再次启动应用程序，只需重复此过程几次即可：

 Objects
               Views:     1408         ViewRootImpl:        8
         AppContexts:       14           Activities:       12
              Assets:        5        AssetManagers:        5
       Local Binders:       13        Proxy Binders:       32
    Death Recipients:        0
     OpenSSL Sockets:        1

 SQL
         MEMORY_USED:        0
  PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0

注意活动和 AppContexts 计数，只需反复启动应用，它们就会不断增加。这是否意味着我有内存泄漏？

我阅读了这篇文档https://developer.android.com/tools/debugging/debugging-memory.html#ViewingAllocations，其中写道：

AppContexts和活动应用上下文和活动的数量目前存在于您的流程中的对象。这可能很有用快速识别泄露的Activity对象，不能是垃圾由于它们的静态引用而收集，这很常见。这些对象通常有很多与之相关的其他分配这是跟踪大量内存泄漏的好方法。

Answer 1

Android中最常见的内存泄漏原因是保留

的实例

活动
上下文
位图/绘制对象
资源

在一些比活动本身更长寿的容器中。那些容器可能是

回调
静态变量

观看https://www.youtube.com/watch?v=_CruQY55HOk，了解如何使用内存分析工具和堆转储查找内存泄漏。

Answer 2

这似乎是内存泄漏。为了确保它，您可以在每次迭代测试后强制运行垃圾收集器（您可以使用DDMS执行此操作）。这样做，您将确定它是内存泄漏。

之后，您可以使用MAT（Memory Analyzer Tool - http://www.eclipse.org/mat/）来识别导致泄漏的引用。

祝你好运！

可能的内存泄漏Android

2 个答案: