この記事は、インテル® Developer Zone に公開されている「Options for Releasing Native Android* Apps for Intel® Architecture (x86)」の参考訳です。

---

概要

Android* 2.3.7 のリリースにおいて、インテルと Google* は x86 (インテル® アーキテクチャー (IA)) においてネイティブ・アプリケーションを実行するため、将来の Android* のバージョンを最適化するために協業することを発表しました。

各アーキテクチャー向けに優れたパフォーマンスとユーザー体験を提供する開発者にとって、Android* NDK アプリケーションのリリースとパッケージングは重要です。この記事では、Google Play からいくつかの具体的なアプリケーションを選択して分析することで、Android* NDK アプリケーションのパッケージにおけるいくつかの既存のオプションを紹介します。開発者の Android* NDK アプリケーションに最も適したオプションを選択できます。

Android* NDK アプリケーションをリリースするオプション

表 1: Android* NDK アプリケーションをリリースするオプション

表 1 に示すように、Android* NDK アプリケーションをリリースするには 4 つの選択肢があります。表 1 は 2 色に色分けされています。緑の部分は、Google Play における基本オプションであるシングル APK もしくはマルチプル APK です。実際には、この 2 つはすべてのアプリケーションのリリースをカバーできます。皆さんもご存じのように、Android* は非常にオープンで柔軟性のあるオペレーティング・システムです。そのため、いくつかの特殊なオプションが黄色で示されています: それは、セパレート APK とトリッキー APK です。どちらも公式な Google Play オプションです。

まず、より良い x86 サポートを提供するという観点から、各オプションを分析する方法を説明します。続くセクションでは、x86 固有の “利点”、”デメリット”、”潜在的リスク”、そして “リスクを回避する方法” を述べます。

潜在的なリスクは、開発者がこのオプションを採用している場合に発生する可能性があります。これら、実例に基づいています。ここではアプリケーションで潜在的なリスクを回避する方法を説明します。

シングル APK

表 2: シングル APK の機能

種類	詳細
利点	1. 常に最新の x86 バージョンをサポートする 2. アプリケーション・ストアで一般的に見られる
欠点	APK ファイルサイズが大きくなり、多くのメモリーを必要とする
潜在的なリスク	アプリケーションが x86 をサポートしていないコンポーネントを統合した時に、/lib/x86 内のライブラリー・ファイルを失う可能性があります。
リスクを回避する方法	開発者とアプリケーション・ストアの両方で、公開前に x86 デバイスでアプリケーションを評価する必要があります。

Google* は、可能な限り多くのデバイス構成をサポートするシングル APK アプリケーションを開発して公開することを推奨しています。シングル APK は、間違いなく最新のバージョンと x86 をサポートする最善かつ簡単なオプションであり、アプリケーション・ストアで見られる最も一般的なオプションです。しかし、バイナリーは大きくなります。

潜在的なリスクは、アプリケーションが x86 をサポートしていないサードパーティーの新しいコンポーネントと統合されると、アプリケーションがバイナリーを失ってしまう可能性があることです。このような場合、アプリケーションが起動された時にクラッシュすると、システムはライブラリーが見つからないことをエラーとして報告します。このリスクを避けるには、開発者とアプリケーション・ストアの双方が、アプリケーションを公開する前に IA デバイス上で検証を行う必要があります。

Sina Weibo は、次のスクリーンショットのように、すべてのネイティブ・ライブラリー・ファイルをパッケージングしているアプリケーションの一例です。

図 1. Sina Weibo NDK ライブラリー

シングル APK は、Sina Weibo のような軽量な NDK アプリケーションに適しています。x86 バイナリーを構成する 4 つのファイルの合計は 235KB のみであり、圧縮前の APK の合計 809KB と比べると僅かなものです。

図 2. Sina Weibo x86 ライブラリーのファイルサイズ

マルチプル APK

表 3: マルチプル APK の機能

種類	詳細
利点	1. 小さな APK サイズ 2. 常に x86 をサポート 3. アプリケーション・ストアで一般的に見られる
欠点	Google Play でのみサポートされる
潜在的なリスク	サードパーティーのアプリケーション・ストアは、x86 ベースの APK を正しく ARM 携帯電話へプッシュできないため、クラッシュを引き起こします。
リスクを回避する方法	アプリケーションは、ネイティブ・ライブラリーをロードする前に、CPU をチェックする必要があります。

マルチプル APK オプションは、開発者がアプリケーションごとに異なる APK を公開することを可能にします。各ターゲットは、特に CPU アーキテクチャーのようなデバイス固有の構成を持ちます。各パッケージは同じ名前である必要がありますが、独立したバージョンと異なるファイルサイズにすることができます。

図 3 に Google Play にある Chrome* のスクリーンショットを示します。サイズとバージョンは、デバイスによって異なることが分かります。

図 3. Goole Play で提供される Android* 版の Chrome*

マルチプル APK には、多くの利点があります。デバイスにダウンロードされる APK ファイルのサイズは、シングル APK よりも小さく、利用者は時間とネットワーク・トラフィックを節約できます。利用者は、常に x86 ネイティブ・バージョンを取得できます。また、各 APK は Google Play で同じアプリケーションのリストを共有しているため、利用者は簡単に x86 の APK を見つけることができます。これは、完璧なソリューションに思われます。ただし、Google Play はサポートしていますが、多くのサードパーティーのアプリケーション・ストアは残念ながらサポートしていません。

潜在的なリスクは、サードパーティーのアプリケーション・ストアは 、x86 APK を 正しく ARM 携帯電話へプッシュできないため、ARM バージョンのアップデートとして誤って見られる可能性があります。これは、x86 APK のバージョンコードは、ARM APK よりも高い値を持つためです (バージョンコードの詳細については、次を参照してください: http://software.intel.com/en-us/articles/google-play-supports-cpu-architecture-filtering-for-multiple-apk)。利用者がこのアプリケーションを起動するとクラッシュするでしょう。

開発者がこの問題を回避する最善策は、アプリケーションがネイティブ・ライブラリーをロードする前に、CPU チェックを追加することです。ターゲットデバイスの CPU アーキテクチャーが一致しない場合、メッセージボックスを表示して、正しいバージョンをダウンロードすることを利用者に通知します。

最も良い解決策は、すべてのアプリケーション・ストアがマルチプル APK をサポートすることです。そうすれば、すべてが上手くいきます。

セパレート APK

表 4: セパレート APK の機能

種類	詳細
利点	1. シングル APK よりも小さな APK サイズ 2. すべてのアプリケーション・ストアがマルチプル APK をサポートしていないため、開発者向けのオプション
欠点	1.x86 バージョンをアプリケーション・ストアで見つけるのが困難 2.アプリケーションに多くのバージョンが存在するため、利用者が混乱する
潜在的なリスク	利用者によって x86 デバイスに ARM バージョンがインストールされることがあります。
リスクを回避する方法	アプリケーションは、ネイティブ・ライブラリーをロードする前に CPU チェックを追加して、正しいバージョンがインストールされるよう利用者を誘導します。

セパレート APK とマルチプル APK の最も重要な違いは、パッケージ名です。このタイプのアプリケーション例として、UC Browser があります。図 4 の UC Browser(x86) のパッケージ名に、”x86″ のポストフィックスがあることが分かります。そして、Android* システムがそれら 2 つの異なるアプリケーションを考慮します。

図 4. UC Browser のパッケージ名

すべてのアプリケーションのバージョンで x86 ブランチを保守する必要が無いため、開発者はこの解決策を好みます。モバイル・インターネットは急速に変化しており、最新のトレンドに追いつくために頻繁にモバイル・アプリーションを更新するのに必要な開発者のリソースは限られています。セパレート APK には、より多くのアーキテクチャーをサポートする労力を最小限にできるというトレードオフがあります。欠点は、新規アプリケーションとしてダウンロードされることがまれであるため、見つけることが難しいことです。

潜在的なリスクは、x86 と ARM の違いを知らない利用者によって、ARM バージョンがまだインストールされてしまうことです。アプリケーションが、ネイティブ・ライブラリーをロードする前に CPU チェックを追加して、正しいバージョンがインストールされるよう利用者を誘導することで、このリスクを回避できます。

長期的に見ると、セパレート APK は一時的な解決策をもたらすソリューションであり、多くのアプリケーション・ストアがマルチプル APK のサポートを完了した時になくなるでしょう。

トリッキー APK

表 5: トリッキー APK の機能

種類	詳細
利点	1. シングル APK よりも小さな APK サイズ 2. 各 CPU ベースのデバイスで最良のパフォーマンス
欠点	２ ステップのインストール
潜在的なリスク	なし
リスクを回避する方法	なし

トリッキー APK は特殊なオプション。基本的な考え方は、2 ステップでネイティブ・ライブラリーをダウンロードすることです。開発者は、アプリケーション自身によって制御されるアップデートのメカニズムとして、このオプションを考えることができます。

トリッキー APK ソリューションを採用するアプリケーションの例として、MoboPlayer が上げられます。図 5 にスクリーンショットを示します。

図 5. MoboPlayer NDK ライブラリーの 2 ステップ・インストール

MoboPlayer は、FFMPEG オープンソース・プロジェクトに基づく Android* マルチメディア・プレイヤーです。シングル APK をベースにしています。利用者は、わずらわしい NDK ライブラリー・ファイルをダウンロードすることなく、アプリケーションをダウンロードするだけで済みます。利用者が最初にこのアプリケーションを実行した時に、アプリケーションは CPU タイプをチェックし、最大限のパフォーマンスが得られるよう最適化されたバイナリーをダウンロードすることを利用者にうながします。

まとめ

Android* NDK アプリケーションをパッケージングしリリースするには、いくつかのソリューションが用意されています。開発者は、アプリケーションの構造 (特にネイティブコード部分) を完全に理解している必要があります。優先するものは何ですか? 優れたパフォーマンスと消費電力ですか? APK サイズですか? 複数の CPU アーキテクチャーをサポートする労力ですか? 同時に、正しいネイティブコードをロードするため、開発者はコードに CPU チェックを追加することで、誤った APK をダウンロードする潜在的なリスクを回避する必要があります。それには、アプリケーション APK の不一致が発生した場合の例外処理や利用者のガイドを含みます。最終的な目標は、すべての CPU アーキテクチャーで最高の体験を提供することです。

参考資料

https://www.izzz.us/article/idz/android/ (日本語)

http://developer.android.com/google/play/publishing/multiple-apks.html

https://www.izzz.us/smartphones/google-play-supports-cpu-architecture-filtering-for-multiple-apk/ (日本語)

https://play.google.com/store/apps/details?id=com.sina.weibo

https://play.google.com/store/apps/details?id=com.android.chrome

https://play.google.com/store/apps/details?id=com.UCMobile.intl

https://play.google.com/store/apps/details?id=com.UCMobile.intl.x86

https://play.google.com/store/apps/details?id=com.clov4r.android.nil

http://www.moboplayer.com/moboplayer_en.html

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。