libhoudini 是否可用于 Chrome OS 上的 ARC

Question

NDK 二进制文件可以在 Chrome 操作系统上的 ARC 中运行。

（而且很高兴）

但是，许多 Android 开发人员只发布 ARM 二进制文件，因为 x86 在手机和平​​板电脑中的市场渗透率并不高。这得益于许多 x86 Android 设备上存在的libhoudini，这些设备可以在 x86 CPU 上运行 ARM NDK 代码，大概使用与 Android ARM 模拟器使用的相同类型的 opcode-translation-on-the-fly。它比拥有原生 x86 二进制文件要慢，但比应用程序根本不可用要好。

libhoudini（或同等技术）相对于 Chrome OS 上的 ARC 应用程序的状态如何？

• 除非铁杆用户搞乱他们的 Chrome 操作系统环境，否则它是否保证存在？

• 是否有可能存在，但不能保证（或多或少是当前的 x86-on-Android 状态）？

• 它是否不可用，所以如果您希望支持 NDK 的 Android 应用程序在 Chrome OS 上运行，您真的真的很想在您的应用程序中提供 ARM 和 x86 二进制文件吗？

• 还有其他一些我没有想到的更好地反映当前（以及可能在不久的将来）状态的选项吗？

就我个人而言，我会同时发布 ARM 和 x86，但我想知道在这个问题上给开发人员一般的建议。

Answer 1

对于 Chrome 操作系统上的 ARC 应用，libhoudini（或同等技术）的状态如何？

在 ARC 中，这称为 ndk_translation，据我了解，它的功能类似于 libhoudini。主要功能区别在于 ARC 的翻译层主要针对 NaCl x86-64 code，这是 x86-64 指令集的沙盒子集。

除非铁杆用户弄乱他们的 Chrome 操作系统环境，否则它是否保证存在？

此翻译层内置于 ARC 中，用户基本上无法禁用它（除了旧的不受支持的 ARC 版本，如原始 ARChon 运行时，但由于它的使用年限，这会导致许多其他支持问题)

是否有可能存在，但不能保证（或多或少是当前的 x86-on-Android 状态）？

不，如果您随 ARC 应用程序提供足以在每台 Chromebook 上运行的 ARM 二进制文件（不考虑 ARC 翻译层中的错误或漏洞）

它是否将不可用，所以如果您希望支持 NDK 的 Android 应用在 Chrome OS 上运行，您真的真的很想在您的应用中提供 ARM 和 x86 二进制文件吗？

由于底层目标机器是 NaCl x86-64，NDK 工具生成的 x86 二进制文件目前与 ARC 不兼容。由于 ARM 在部署方面占主导地位（许多应用程序只有 ARM 二进制文件），这就是 ARC 的 NDK 翻译的重点。

还有其他一些我没有想到的更好地反映当前（以及可能在不久的将来）状态的选项吗？

我认为您使用 x86 和 ARM 二进制文件的做法是一个谨慎的选择，这既是为了将来可能对 ARC 进行改进，也是为了更好地兼容其他 Android 设备。但目前 ARC 只会使用您的 ARM 二进制文件并在必要时转换为 x86。