验证应用在 Android 运行时 (ART) 上的行为

Android 运行时 (ART) 是运行 Android 5.0（API 级别 21）及更高版本的设备的默认运行时。此运行时提供许多功能，可提升 Android 平台和应用的性能和流畅度。您可以在 介绍 ART 中找到有关 ART 新功能的更多信息。

但是，某些在 Dalvik 上有效的技术在 ART 上无效。本文档将让您了解在迁移现有应用以使其与 ART 兼容时需要注意的事项。大多数应用在使用 ART 运行时应该都能正常工作。

解决垃圾回收 (GC) 问题

在 Dalvik 环境下，应用经常会显式调用System.gc()来提示垃圾回收 (GC)。在 ART 环境下，这将变得不那么必要，尤其是在您调用垃圾回收是为了防止GC_FOR_ALLOC类型的事件发生或减少碎片时。您可以通过调用System.getProperty("java.vm.version")来验证正在使用的运行时。如果使用 ART，则该属性的值为"2.0.0"或更高版本。

ART 使用并发复制 (CC) 收集器，该收集器会并发地压缩 Java 堆。因此，您应该避免使用与压缩 GC 不兼容的技术（例如保存指向对象实例数据的指针）。对于使用 Java 本地接口 (JNI) 的应用，这一点尤其重要。有关更多信息，请参阅防止 JNI 问题。

防止 JNI 问题

ART 的 JNI 比 Dalvik 的 JNI 更加严格。使用 CheckJNI 模式来捕获常见问题是一个非常好的主意。如果您的应用使用 C/C++ 代码，您应该查看以下文章

使用 CheckJNI 调试 Android JNI

检查 JNI 代码中的垃圾回收问题

并发复制 (CC) 收集器可能会为了压缩而在内存中移动对象。如果您使用 C/C++ 代码，请不要执行与压缩 GC 不兼容的操作。我们已经增强了 CheckJNI 以识别一些潜在的问题（如ICS 中的 JNI 本地引用更改中所述）。

需要注意的一个特定领域是Get...ArrayElements()和Release...ArrayElements()函数的使用。在具有非压缩 GC 的运行时中，Get...ArrayElements()函数通常返回对实际支持数组对象的内存的引用。如果您更改了返回的数组元素之一，则数组对象本身也会发生更改（并且Release...ArrayElements()的参数通常会被忽略）。但是，如果使用压缩 GC，Get...ArrayElements()函数可能会返回内存的副本。如果您在使用压缩 GC 时误用该引用，则可能会导致内存损坏或其他问题。例如

  • 如果您对返回的数组元素进行了任何更改，则在完成操作后，必须调用相应的Release...ArrayElements()函数，以确保您所做的更改正确地复制回底层数组对象。
  • 释放内存数组元素时，必须根据您所做的更改使用相应的模式
    • 如果您没有对数组元素进行任何更改，请使用JNI_ABORT模式，该模式会在不将更改复制回底层数组对象的情况下释放内存。
    • 如果您对数组进行了更改，并且不再需要该引用，请使用代码0（这会更新数组对象并释放内存副本）。
    • 如果您对要提交的数组进行了更改，并且想要保留数组的副本，请使用JNI_COMMIT（这会更新底层数组对象并保留副本）。
  • 调用Release...ArrayElements()时，请返回Get...ArrayElements()最初返回的相同指针。例如，递增原始指针（以扫描返回的数组元素），然后将递增的指针传递给Release...ArrayElements()是不安全的。传递此修改后的指针可能会导致释放错误的内存，从而导致内存损坏。

错误处理

ART 的 JNI 在 Dalvik 未抛出错误的许多情况下都会抛出错误。（同样，您可以通过使用 CheckJNI 进行测试来捕获许多此类情况。）

例如，如果使用不存在的方法调用RegisterNatives（可能是因为该方法已被诸如**ProGuard**之类的工具删除），ART 现在会正确地抛出NoSuchMethodError

08-12 17:09:41.082 13823 13823 E AndroidRuntime: FATAL EXCEPTION: main
08-12 17:09:41.082 13823 13823 E AndroidRuntime: java.lang.NoSuchMethodError:
    no static or non-static method
    "Lcom/foo/Bar;.native_frob(Ljava/lang/String;)I"
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.nativeLoad(Native Method)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.doLoad(Runtime.java:421)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.Runtime.loadLibrary(Runtime.java:362)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
    at java.lang.System.loadLibrary(System.java:526)

如果使用没有方法的调用RegisterNatives，ART 还会记录错误（在 logcat 中可见）

W/art     ( 1234): JNI RegisterNativeMethods: attempt to register 0 native
methods for <classname>

此外，JNI 函数GetFieldID()和GetStaticFieldID()现在会正确地抛出NoSuchFieldError，而不是简单地返回 null。类似地，GetMethodID()和GetStaticMethodID()现在会正确地抛出NoSuchMethodError。这可能会导致 CheckJNI 失败，因为未处理的异常或异常被抛出到原生代码的 Java 调用者。这使得使用 CheckJNI 模式测试与 ART 兼容的应用尤其重要。

ART 期望 JNI CallNonvirtual...Method()方法（例如CallNonvirtualVoidMethod()）的用户使用方法的声明类，而不是子类，这符合 JNI 规范的要求。

防止堆栈大小问题

Dalvik 为原生代码和 Java 代码分别使用了不同的堆栈，默认的 Java 堆栈大小为 32KB，默认的原生堆栈大小为 1MB。ART 使用统一的堆栈以获得更好的局部性。通常，ART Thread堆栈大小应与 Dalvik 差不多。但是，如果您显式设置堆栈大小，则可能需要重新检查在 ART 中运行的应用的这些值。

  • 在 Java 中，请检查指定显式堆栈大小的Thread构造函数的调用。例如，如果发生StackOverflowError，则需要增加大小。
  • 在 C/C++ 中，请检查对pthread_attr_setstack()和pthread_attr_setstacksize()的使用，这些函数用于还通过 JNI 运行 Java 代码的线程。以下是在应用尝试调用 JNI AttachCurrentThread()时 pthread 大小太小而记录的错误示例
    F/art: art/runtime/thread.cc:435]
    Attempt to attach a thread with a too-small stack (16384 bytes)

对象模型更改

Dalvik 错误地允许子类重写包私有方法。ART 在此类情况下会发出警告

Before Android 4.1, method void com.foo.Bar.quux()
would have incorrectly overridden the package-private method in
com.quux.Quux

如果您打算在不同的包中重写类的某个方法，请将该方法声明为public或protected。

Object现在具有私有字段。在类层次结构中反映字段的应用应注意不要尝试查看Object的字段。例如，如果您正在迭代类层次结构作为序列化框架的一部分，则在

Class.getSuperclass() == java.lang.Object.class

时停止，而不是继续直到方法返回null。

如果没有任何参数，则代理InvocationHandler.invoke()现在会接收null，而不是空数组。此行为以前已记录在案，但在 Dalvik 中未正确处理。早期版本的Mockito对此有困难，因此在使用 ART 进行测试时，请使用更新的 Mockito 版本。

修复 AOT 编译问题

ART 的提前 (AOT) Java 编译应该适用于所有标准 Java 代码。编译由 ART 的dex2oat工具执行；如果您在安装时遇到与dex2oat相关的任何问题，请告知我们（请参阅报告问题），以便我们尽快修复它们。需要注意的几个问题

  • ART 在安装时进行比 Dalvik 更严格的字节码验证。Android 构建工具生成的代码应该没问题。但是，一些后处理工具（特别是执行混淆的工具）可能会生成 Dalvik 可以容忍但 ART 会拒绝的无效文件。我们一直在与工具供应商合作查找和修复此类问题。在许多情况下，获取最新版本的工具并重新生成 DEX 文件可以解决这些问题。
  • ART 验证器标记的一些典型问题包括
    • 无效的控制流
    • 不平衡的monitorenter/monitorexit
    • 0 长度的参数类型列表大小
  • 某些应用依赖于/system/framework、/data/dalvik-cache或DexClassLoader的优化输出目录中安装的.odex文件格式。这些文件现在是 ELF 文件，而不是 DEX 文件的扩展形式。虽然 ART 试图遵循与 Dalvik 相同的命名和锁定规则，但应用不应依赖于文件格式；格式可能会随时更改，恕不另行通知。

    注意：在 Android 8.0（API 级别 26）及更高版本中，DexClassLoader优化输出目录已被弃用。有关更多信息，请参阅DexClassLoader()构造函数的文档。

报告问题

如果您遇到任何并非由于应用 JNI 问题而导致的问题，请通过 Android 开源项目问题跟踪器https://code.google.com/p/android/issues/list报告这些问题。如果可用，请包含"adb bugreport"和 Google Play 商店中应用的链接。否则，如果可能，请附加一个可以重现该问题的 APK。请注意，问题（包括附件）是公开可见的。