问题标签 [art-runtime]

我正在努力不断地做一份工作。对于这项工作，我正在使用处理程序并以恒定的时间间隔递归地调用此处理程序。我的代码在 Android 版本 4.3 的三星 Galaxy Note 2 中运行，但不能在 Android 版本 4.4.2 的 Nexus 5 中运行。我被这个问题困住了。我正在输入代码和错误日志，请帮忙。祝你有美好的一天。（我正在简化代码，因此您可以轻松分析，但是如果您愿意，我可以在这里编写所有代码。）（另外，由于它的大小，我没有写所有的错误日志。）

代码：

错误日志：

我不知道为什么，但一周前当我在 android studio 中调试我的应用程序时，设备中的应用程序非常慢，但是如果生成 APK 或使用播放（非调试）选项工作正常..

有人知道为什么吗？我想我在 sdk 或应用程序中没有任何改变来做到这一点..

我想问你是否正确理解了编译过程。

将 Android 应用程序导出到 .apk 文件后，我们会收到字节码(.apk)。

当我们想在 Android 设备上启动我们的应用程序时：

达尔维克：

字节码 (.apk) -> Dalvik VM JIT 编译 -> 编译原生代码 -> 程序执行（整个程序分配在内存中）

每次我们启动应用程序时都会执行这个 Dalvik JIT 编译。

艺术：

安装：

字节码 (.apk) -> ART VM AOT 编译 -> 编译的本机代码

应用启动：

本机代码 -> 执行（只有部分程序分配内存）

AOT 编译仅在应用安装后进行一次。

目前，可以将类文件动态加载.dex到 Android 的 Dalvik VM 中。这也可能用于运行时的动态代码生成。

即将到来的 ART 运行时这仍然可能吗？

我们都知道，谷歌正在从 Dalvik 转向 ART（4.4.2 甚至也有实验性支持），原因很明显，在我最近开始出于某种目的对生成的 smali 文件进行 mdify 之后，我脑海中出现了一个非常基本的问题。这是我的问题：

展开任何 apk 文件后，我们会看到 dalvik 可执行文件和各种包含 dalvik 操作码和其他相关内容的 smali 文件。因此，一旦 Google 强制使用 ART，如果 apk 文件中的这个结构将包含类似的内容，我感到很惊讶，即我不清楚在 ART 接管后修改 smali 文件是否有效。

对于许多人来说，这可能是非常基本的问题，但这是我在这个论坛上的第一个问题，所以请原谅我对这个主题的了解有限。

在 ART 环境中，它无法传递复杂的 Parcelable 对象。

存在从实现Parcelable的类的内部类的CREATOR的Parcel的内部处理调用另一个类的CREATOR的情况。它将采取不同类别的反射领域是当读取 Parcel 内的 Parcelable 类时到期。

例如：

• ListParamDto.java 实现 Parcelable。
• DetailParamDto.java 扩展 ListParamDto.java
• intent.putExtra(detailParamDto.getClass().getCanonicalName(), DetailParamDto) 和 startActivity(intent)。

2133 行 API 19 Parcel.java https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/Parcel.java#L2139

它在 Dalvik 环境中进展顺利。

我附上了堆栈跟踪日志，

你知道吗？

我想，现在问这个问题可能有点早。但是需要你对此的想法。

我阅读了有关ART模式（Android Runttime）的信息，如下所示，

“ART 是在 KitKat 4.4 版本中以实验性方式引入的新 Android 运行时。这是 KitKat 正在进行的工作的预览。它可用于获得早期开发人员和合作伙伴的反馈。”

但也请阅读，如果切换到 ART 模式，某些应用程序可能会崩溃。所以，我想知道，在编程时是否需要考虑任何设计目标才能在 ART 和 DVM 模式下运行我的应用程序？

我一直看到报告（谣言）很快 Android 将从 Dalvik 切换到 ART，因为它是默认运行时。我真的不知道这意味着什么，我猜运行时（有点？）就像操作系统一样。

我的应用程序没有做任何特别/独特的事情，因为它主要对数据发出 HTTP 请求，并使用 LocationListeners 几次。

在我读过的一些关于传闻中的变化的文章中，我看到有人说“我喜欢 ART，如果 X 应用程序支持它，我现在就使用它”。（我记得提到的一个应用是 Xposed）

我已将手机切换到 ART，并且我的应用程序似乎运行良好，所以我猜标题问题的答案是否定的，但我很好奇 Xposed 应用程序是如何不兼容的。他们做了什么（或没有做什么）使他们的应用无法在 ART 中运行？

我在启动时在我的应用程序中启动了一个 LooperThreads 库，但它似乎在艺术下崩溃

谷歌搜索第一行在艺术源代码中找到了这个引用 - 看起来在 Looper 线程启动后挂起它们可能存在一些问题。或者从下面的链接可能启动一个线程哪个 GCing？

参见第 77 行 https://android.googlesource.com/platform/art/+/05c87be/src/thread_list.cc

我真的不知道发生了什么，但我想我最好在所有手机默认启用 ART 运行时之前修复它，我认为这很快就会发生。

下面是部分转储：完整的跟踪发布在这里： http: //pastebin.com/MiFa6fLD

ImageController 第一部分的代码（带有线程的东西）在这里： http: //pastebin.com/xiJ9N9fK

直奔主题，Android L 引入了 ART 作为默认运行时。我有一个示例应用程序，基本上是一个文档查看器。大部分文档查看代码，包括后退按钮、搜索等，都是用 C 语言编写的，Android App 使用 JNI 接口。我更新了我的代码以使其为 Android L 构建，它似乎可以很好地打开文档。但是，当按下后退按钮并关闭文档时，应用程序似乎崩溃了，并且看到了以下回溯：

按下后退按钮后，当文件描述符应该关闭时，调用 CallIntMethodV，最终检查 JNI 失败。相同的代码似乎在 dalvik 上工作得很好。我必须添加以下标志以使 JNI 代码能够为 Android L 预览版正常编译：

关键是为什么它现在开始在艺术上失败，而不是在 dalvik 上。CallIntMethodV 中导致问题或编译器严格性的任何特定更改是否会导致引发此类错误？任何指针。如果需要，我很乐意提供更多详细信息。

更新：我暂时禁用了对本机代码调用 JNI 的文件关闭函数的调用，我现在似乎没有看到任何崩溃。