10

NDK バイナリは、Chrome OS の ARC で動作します。

（そして、多くの喜びがありました）

ただし、多くの Android 開発者は ARM バイナリのみを出荷しています。これは、携帯電話やタブレットでの x86 の市場普及率が低いためです。これはlibhoudini、x86 CPU で ARM NDK コードを実行できる多くの x86 Android デバイスに が存在することで、おそらく Android ARM エミュレータが使用するのと同じ種類の opcode-translation-on-the-fly を使用して支援されます。ネイティブの x86 バイナリよりは遅くなりますが、アプリがまったく利用できないよりはましです。

libhoudiniChrome OS 上の ARC アプリに関して (または同等の技術)のステータスはどのようなものですか?

  • 筋金入りのユーザーが Chrome OS 環境をめちゃくちゃにしない限り、そこにあることが保証されていますか?

  • そこにいることは可能ですが、保証されていません(多かれ少なかれ、現在のx86-on-Androidステータス)?

  • 利用できないので、NDK 対応の Android アプリを Chrome OS で動作させたい場合、ARM と x86 のバイナリをアプリと一緒に出荷したいですか?

  • 現在の（そしておそらく近い将来の）状態をよりよく反映する、私が考えていない他のオプションはありますか？

個人的には、ARM と x86 の両方を出荷しますが、この問題全般について開発者にどのようなアドバイスを与えるべきか知りたいです。

4

1 に答える 1

9

Chrome OS 上の ARC アプリに関して、libhoudini (または同等のテクノロジ) のステータスはどのようなものですか?

ARC では、これは ndk_translation と呼ばれ、私が理解しているように、libhoudini と同様に機能します。主な機能上の違いは、ARC の変換レイヤーがほとんどの場合、x86-64 命令セットのサンドボックス化されたサブセットであるNaCl x86-64 コードをターゲットにしていることです。

筋金入りのユーザーが Chrome OS 環境をめちゃくちゃにしない限り、そこにあることが保証されていますか?

この変換レイヤーは ARC に組み込まれているため、ユーザーが無効にするためにできることは基本的にありません (元の ARChon ランタイムのようにサポートされていない古いバージョンの ARC を使用している場合を除きますが、古いため、他の多くのサポートの問題が発生します)。

そこにいることは可能ですが、保証されていません(多かれ少なかれ、現在のx86-on-Androidステータス)?

いいえ、ARM バイナリを ARC アプリと一緒に出荷すれば、すべての 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 に変換します。

于 2015-04-08T15:18:25.360 に答える