android - 为什么 Android ART 有时不会在离开作用域时对局部变量进行 GC？

Question

在我看来，有时 ART 会在离开其作用域时对局部变量进行 GC，但有时不会发生。在我看来，Dalvik 也将永远如此。

我使用 Android Studio 内存监视器运行以下测试用例。它们都是关于在onCreate中添加的方法testMemoryUsage:

@Override
protected final void onCreate(final Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    testMemoryUsage(); // For testing only
    setupActivity(); // Added to setup the activity to be ready to run
}

测试用例 1(控制)

testMemoryUsage 只是一个空方法:

// For testing only
private void testMemoryUsage() {
}

测试用例 2(非最终局部变量)

testMemoryUsage 只是创建一个非 final 局部变量 uniqueStrings:

// For testing only
private void testMemoryUsage() {
    List<String> uniqueStrings = new Vector<>();
    for (Integer index = 0; index < 1000000; index++) {
        uniqueStrings.add(index.toString());
    }
}

测试流程

大约每 10 秒，应用程序将通过按设备后退按钮关闭并通过单击应用程序图标立即重新打开。

测试设备

GT-N7000(安卓版本4.1.2)-达尔维克

LG-D802(安卓版本4.4.2) - 达尔维克

LG-H860(安卓版本6.0.1)-艺术

Nexus 5X(Android 7.0 版)- 艺术

通过使用 2 台设备，每台设备都有不同的 Android 版本，Dalvik 和 2 台设备，每台设备都有不同的 Android 版本，带 ART，这个设置应该消除由于设备和 Android 版本而不是 Dalvik 和 ART 引起的变量。

内存监控结果

Memory Monitor Result 1(LG-H860 in Test Case 1)

Nexus 5X(ART) 显示了与控制测试用例基本相似的内存监控结果。 然而，GT-N7000(Dalvik) 和 LG-D802(Dalvik) 的结果几乎持平。

Memory Monitor Result 2(LG-H860 in Test Case 2)

Nexus 5X(ART) 显示了基本相似的内存监控结果。 但是，GT-N7000(Dalvik) 和 LG-D802(Dalvik) 都显示出类似锯齿的结果，在完成添加所有这 1000000 个唯一字符串后触发下降沿，这意味着 Dalvik 总是立即 GC 本地变量 uniqueStrings离开其范围 testMemoryUsage。

对于 ART，它有时会在第一次和第二次应用程序启动离开其范围 testMemoryUsage 时对局部变量 uniqueStrings 进行 GC，但有时不会。此外，有时此类 GC 会在随后的关闭和重新打开时发生，但有时会发生。

我在 LG-H860(ART) 和 Nexus 5X(ART) 上分别运行了将近 10 次这些测试，即使在相同的测试设备，除了 1 点 - GC 将在上述时间立即发生，或者无论我等待多长时间都不会发生，尽管如果我在应用程序中执行其他操作可能会发生。 不过，GT-N7000(Dalvik)和LG-D802(Dalvik)的内存监控结果非常一致。

我曾尝试在互联网上搜索答案，但尽管努力了数小时仍未找到任何答案，所以我决定在这里提问:

ART 真的是所有这些问题的根源，还是我犯了一些可怕的错误？

Answer 1

ART的GC算法不同于Dalvik的GC算法。一旦应用程序退出，Dalvik 就会被触发，甚至在应用程序运行时多次触发，导致 UI 线程因操作受阻而暂停。在您的过期中，Dalvik 行为是完美的，它会在应用程序退出时立即触发并执行并发 GC 扫描以清除内存。

ART默认的方案是CMS(concurrent mark sweep)方案，主要使用粘性CMS和部分CMS。 Sticky CMS 是 ART 的非移动分代垃圾收集器。它只扫描自上次 GC 以来修改的堆部分，并且只能回收自上次 GC 以来分配的对象。除了 CMS 计划之外，当应用程序将进程状态更改为卡顿不易察觉的进程状态(例如后台或缓存)时，ART 还会执行堆压缩。所以您看到 ART 的 GC 行为是完美的，它等待下一个 GC 扫描周期来清除内存。这有两个方面的帮助:

1. 没有异步 GC 扫描。因此，与 Dalvik 相比，GC 扫描次数减少了。
2. 在您的情况下，由于应用会立即重新启动，因此会适本地重复使用内存。

因此 ART 不是所有这些问题的根源，而是它按照其设计的行为方式。

您将获得更多详细信息here