libhoudini适用于Chrome OS上的ARC
NDK二进制文件可以在Chrome OS上的ARC中工作。
（有很多的欣喜）
但是，许多Android开发人员只发布ARM二进制文件，因为x86在手机和平板电脑中的市场渗透率并不高。 这可以通过许多x86安卓设备上的libhoudini来实现，这些设备可以在x86 CPU上运行ARM NDK代码，这大概与Android ARM仿真器使用相同类型的操作码 - 即时翻译。 它比使用本机x86二进制文件要慢，但它比根本不可用的应用程序更好。
Chrome OS上ARC应用程序的libhoudini （或同等技术）的状态如何？
它是否保证在那里，禁止硬核用户搞砸他们的Chrome操作系统环境？
是否有可能在那里，但不能保证（或多或少是当前的x86-on-Android状态）？
它是否不可用，所以如果你想让你的支持NDK的Android应用程序在Chrome OS上工作，你真的真的想要将ARM和x86二进制文件发布到你的应用程序中吗？
有没有其他的选择，我没有想到，更好地反映了目前（和可能不久的将来）状态？
就个人而言，我将发布ARM和x86，但我想知道一般情况下给开发人员提供什么建议。
Chrome OS上ARC应用程序的libhoudini（或同等技术）的状态如何？
在ARC中，这被称为ndk_translation，并且按照我的理解，其功能类似于libhoudini。 主要的功能差异在于ARC的翻译层主要针对NaCl x86-64代码，这是x86-64指令集的沙盒子集。
它是否保证在那里，禁止硬核用户搞砸他们的Chrome操作系统环境？
这个翻译层是内置在ARC中的，基本上用户可以做任何事情来禁用它（除了有一个旧的不受支持的ARC版本，就像原来的ARChon运行时一样，但由于它的年龄会导致许多其他支持问题）
是否有可能在那里，但不能保证（或多或少是当前的x86-on-Android状态）？
不，如果您向您的ARC应用发布ARM二进制文件，并且足以在每台Chromebook上运行（不考虑ARC翻译层中的错误或漏洞）
它是否不可用，所以如果你想让你的支持NDK的Android应用程序在Chrome OS上工作，你真的真的想要将ARM和x86二进制文件发布到你的应用程序中吗？
由于底层目标机器是NaCl x86-64，因此NDK工具生成的x86二进制文件与ARC目前不兼容。 由于ARM在部署方面占主导地位（许多应用程序只有ARM二进制文件），这是ARC NDK翻译的重点。
有没有其他的选择，我没有想到，更好地反映了目前（和可能不久的将来）状态？
我认为，您在运行x86和ARM二进制文件方面所做的工作是一个谨慎的选择，既可以用于未来ARC的改进，也可以提高与其他Android设备的兼容性。 但是目前ARC只会使用您的ARM二进制文件并在必要时转换为x86。
链接地址: http://www.djcxy.com/p/24627.html