Android StrictMode InstanceCountViolation

Question

我正在运行我的应用程序，并在开发中激活了 StrictMode，如此处所述 StrictMode for lower platform versions并注意到一条错误消息，我不知道该怎么想，也找不到任何引用。

我得到一个 android.os.StrictMode$InstanceCountViolation，其中包含 instances 和 limit 的值，例如

instances=3; limit=2

现在我想知道:

• A) 限额是如何计算的
• B) 这种违规行为怎么会发生，然后我会调查规避行为。

有什么想法吗？

Answer 1

一切尽在代码中

key 是StrictMode.sExpectedActivityInstanceCount and incrementExpectedActivityCount and decrementExpectedActivityCount :

• 在 ActivityThread.performLaunchActivity 中调用增量
  在创建 Activity 实例之后。
• 在 ActivityThread.performDestroyActivity 中调用递减
  从应用程序中删除 Activity 之后。

所以每次销毁 Activity 时 limit 都会减少，但是如果实例泄漏，实际实例计数将大于限制，为了检测它是否泄漏，他们会执行一些 GC 魔术(在 decrementExpectedActivityCount):

    System.gc();
    System.runFinalization(); // added in https://github.com/android/platform_frameworks_base/commit/6f3a38f3afd79ed6dddcef5c83cb442d6749e2ff
    System.gc();

如果在此之后 GC 没有从应用程序的内存中删除 Activity，则将其视为泄漏。

结论

基于上述情况，唯一的预防方法是确保在 onDestroy 之后没有对违规 Activity 的引用。问题是有些可能有一些 WeakReference 仍然可以通过一些 native 对象访问，这些 native 对象似乎具有不同的生命周期。我是这样得出这个结论的:

• 从 MyActivity 退出并查看日志消息后
• 进行堆转储 (.hprof)
• 在 Eclipse 内存分析器中打开它
• 运行 OQL:select * from instanceof full.package.name.of.MyActivity
• 使用 Ctrl+Click 或 Shift+Click
全选
• 右键单击并Merge Shortest Path to GC Roots > 与所有引用

解决方法

如果我们 increase the count initially在它报告特定类的泄漏之前，我们将有更多的伸腿空间:

// Application.onCreate or nearby where you set up StrictMode detectActivityLeaks
Method incrementExpectedActivityCount = StrictMode.class.getMethod("incrementExpectedActivityCount", Class.class)
incrementExpectedActivityCount.invoke(null, MyActivity.class);
incrementExpectedActivityCount.invoke(null, MyActivity2.class);

进一步阅读

• WeakReferences
• Eclipse Memory Analyzer (MAT)
• History of StrictMode