【Unity】Android App Bundleを触ってみた
【Unity】Android App Bundleを触ってみた:
2018年カヤックUnityアドベントカレンダーの18日目の記事になります。
Unityが新しくサポートしたAndroid App Bundleを触ってみた際の記録をもとにした記事になります。
つっこんだ技術的な内容はなく軽めの記事になっていますので、気軽に読んでもらえると幸いです。
アプリストアからアプリをダウンロードする際にダウンロード時間をゲームをプレイするより楽しむユーザはいませんよね。
ダウンロード時間を短くするために、私たちアプリ開発者にできることとしてアプリサイズを小さくすることが考えられます。
一方、アプリストアのGoogle Play側でも改善の取り組みが行われています。その改善のひとつがAABになります。
そして、AABを使用することで、アプリを配信する際のサイズをより小さくすることが可能となるようです。
AABフォーマットのファイルはコンパイルされたコードがすべて含まれたもので、APKの生成と署名が保留された状態ものになります。
APKの生成が保留されていることでGoogle Playではアプリをダウンロードするユーザのデバイスに応じて無駄なファイルを含まないAPKを生成することができる仕組みになっているようです。
これまで、アプリサイズを小さくするためにTarget Architecturesでx86をわけたりすることなどアプリ開発者側が検討する場合もありましたが、そういった対応がAABを使うことで不要になることになると考えられます。
Architecturesの他にもAABでは画面密度の情報などを利用してAPKを生成するようです。
1つめのプロジェクトはキューブが置かれているシーンがビルド対象のシンプルなプロジェクトになります。
2つめのプロジェクトはゲームが実装されたプロジェクトになります。この記事で使用したUnityのバージョンは2018.3.0b11になります。
また、使用した端末は下記のものになります。CPUの違いで選択しています。
AABを利用してビルドするためには下記の図のようにBuild SettingsにあるBuild App Bundleにチェックを入れるだけでできるようになっています。
凄い簡単ですね。
それでは実際にビルドを実行した際に作られるAABファイルのサイズやインストールサイズを見てみましょう。
AABファイルのサイズを下記の表にまとめました。
ここでAAB[MB]の項目はAABファイルのサイズを表しています。
また、APK(ARMv7のみ) [MB]はAABを使用せずに、Target ArchitecturesにARMv7のみを指定した際に作成されたAPKファイルのサイズを表しています。x86のみとARMv7とx86も同様にそれぞれ設定した際のファイルサイズを表しています。
この表からは、今回使用したプロジェクトにおいてはAABファイルのサイズはArchitecturesにARMv7とx86を設定した際と同程度のファイルサイズになっていることがわかります。
次にインストールサイズをプロジェクト毎に見ていきましょう。
プロジェクトSimple Mobile Placeholderでのインストールサイズは下記の表の通りになりました。AAB [MB]の項目はAABを使用した際のインストールサイズになります。
また、APK(ARMv7のみ) [MB]はArchitecturesにARMv7のみを指定して作成したAPKファイルを使用した際のインストールサイズになります。
x86のみとARMv7とx86も同様にそれぞれの設定において生成されたAPKを使用した際のインストールサイズになります。
プロジェクトEndless Runner - Sample Gameでのインストールサイズは下記の通りです。読み方は前の表と同じになります。
2つの表から、AABを使用した際のインストールサイズはEssential Phone PH-1の場合はARMv7とx86を設定した際のAPKを使用した場合のインストールサイズよりも小さく、ARMv7のみを設定して生成したAPKを使用した際のサイズとほぼ同じになっています。
また、ZenPad 7.0(Z370C)の場合はx86のみを使用した際のビルドサイズよりも10MBほど小さくなっていることがわかります。
興味深いですね。
また、プロジェクトの内容によらず同程度の増減が生じていることもわかります。これはプロジェクトによらず共通した部分が削減されているからだと考えられます。
またインストールサイズから、1つのAABファイルで異なるアーキテクチャの端末に対していサイズを大きくせずにアプリをインストールできることがわかりました。
実際にストアで使用する際にはGoogle Play App Signingを使用したり必要があったりして別途対応が必要になります。
また、Unity Blogの記事にある通り、ビルドからインストールまでの時間を短縮するために、普段の開発では通常のAPKを生成することがおすすめされています。
そのため、開発フローに取り入れるには少し対応が必要になりそうです。
しかし、このフォーマットに切り替えることの利点がGoogle Developersの記事で複数アナウンスされています。
まだ早期アクセスのようですがインストールAPKサイズが500MBまでのファイルをアップロードできるようになるといったことなどが挙げられています。
いずれにしても、AAB形式を扱うことでダウンロード時間を短くするのには効果があるとのことなので是非取り入れることを考えていきたいですね。
明日は須藤さんによるAppStoreReviewガイドラインの『4.2 最低限の機能』に対応した話になります!お楽しみに!
はじめに
ソーシャルゲーム事業部所属の荒井です。2018年カヤックUnityアドベントカレンダーの18日目の記事になります。
Unityが新しくサポートしたAndroid App Bundleを触ってみた際の記録をもとにした記事になります。
つっこんだ技術的な内容はなく軽めの記事になっていますので、気軽に読んでもらえると幸いです。
Unity 2018.3ベータでAndorid App Bundle(AAB)をサポート
10月3日のUnity Blogの記事にある通り、2018.3ベータからAndroid App Bundle(AAB)をサポートが使えるようになりました。アプリストアからアプリをダウンロードする際にダウンロード時間をゲームをプレイするより楽しむユーザはいませんよね。
ダウンロード時間を短くするために、私たちアプリ開発者にできることとしてアプリサイズを小さくすることが考えられます。
一方、アプリストアのGoogle Play側でも改善の取り組みが行われています。その改善のひとつがAABになります。
AABとは
AABとは新しいアップロードする際のフォーマットになります。そして、AABを使用することで、アプリを配信する際のサイズをより小さくすることが可能となるようです。
AABフォーマットのファイルはコンパイルされたコードがすべて含まれたもので、APKの生成と署名が保留された状態ものになります。
APKの生成が保留されていることでGoogle Playではアプリをダウンロードするユーザのデバイスに応じて無駄なファイルを含まないAPKを生成することができる仕組みになっているようです。
これまで、アプリサイズを小さくするためにTarget Architecturesでx86をわけたりすることなどアプリ開発者側が検討する場合もありましたが、そういった対応がAABを使うことで不要になることになると考えられます。
Architecturesの他にもAABでは画面密度の情報などを利用してAPKを生成するようです。
サンプルプロジェクトでAABを触ってみた
簡単にですが説明はここまでにして、実際にどんな感じなのかをUnity Technologies社がAsset Storeで提供しているプロジェクト、Simple Mobile PlaceholderとEndless Runner - Sample Gameに対してAABを利用したビルドと端末へのアプリのインストールを行ってみました。1つめのプロジェクトはキューブが置かれているシーンがビルド対象のシンプルなプロジェクトになります。
2つめのプロジェクトはゲームが実装されたプロジェクトになります。この記事で使用したUnityのバージョンは2018.3.0b11になります。
また、使用した端末は下記のものになります。CPUの違いで選択しています。
端末名 | CPU | Androidバージョン |
---|---|---|
Essential Phone PH-1 | Qualcomm® Snapdragon™ 835 | 9 |
ZenPad 7.0(Z370C) | インテル® Atom™ x3-C3200 | 5.0.2 |
凄い簡単ですね。
それでは実際にビルドを実行した際に作られるAABファイルのサイズやインストールサイズを見てみましょう。
AABファイルのサイズを下記の表にまとめました。
ここでAAB[MB]の項目はAABファイルのサイズを表しています。
また、APK(ARMv7のみ) [MB]はAABを使用せずに、Target ArchitecturesにARMv7のみを指定した際に作成されたAPKファイルのサイズを表しています。x86のみとARMv7とx86も同様にそれぞれ設定した際のファイルサイズを表しています。
この表からは、今回使用したプロジェクトにおいてはAABファイルのサイズはArchitecturesにARMv7とx86を設定した際と同程度のファイルサイズになっていることがわかります。
プロジェクト名 | AAB [MB] | APK(ARMv7のみ) [MB] | APK(x86のみ) [MB] | APK(ARMv7とx86) [MB] |
---|---|---|---|---|
Simple Mobile Placeholder | 22.9 | 12.4 | 13.7 | 22.8 |
Endless Runner - Sample Game |
41.8 | 31.4 | 32.7 | 41.8 |
プロジェクトSimple Mobile Placeholderでのインストールサイズは下記の表の通りになりました。AAB [MB]の項目はAABを使用した際のインストールサイズになります。
また、APK(ARMv7のみ) [MB]はArchitecturesにARMv7のみを指定して作成したAPKファイルを使用した際のインストールサイズになります。
x86のみとARMv7とx86も同様にそれぞれの設定において生成されたAPKを使用した際のインストールサイズになります。
端末名 | AAB [MB] | APK(ARMv7のみ) [MB] | APK(x86のみ) [MB] | APK(ARMv7とx86) [MB] |
---|---|---|---|---|
Essential Phone PH-1 |
34.64 | 34.55 | - | 44.91 |
ZenPad 7.0 (Z370C) |
29.74 | - | 39.58 | 48.22 |
端末名 | AAB [MB] | APK(ARMv7のみ) [MB] | APK(x86のみ) [MB] | APK(ARMv7とx86) [MB] |
---|---|---|---|---|
Essential Phone PH-1 |
53.67 | 53.55 | - | 63.88 |
ZenPad 7.0 (Z370C) |
47.86 | - | 57.63 | 66.27 |
また、ZenPad 7.0(Z370C)の場合はx86のみを使用した際のビルドサイズよりも10MBほど小さくなっていることがわかります。
興味深いですね。
また、プロジェクトの内容によらず同程度の増減が生じていることもわかります。これはプロジェクトによらず共通した部分が削減されているからだと考えられます。
ビルド後にインストールを行うには
ビルド後にAABファイルを用いてアプリのインストールを行うにはbundletoolを使用することで行なえるようです。Unity Blogの記事にある通り、Unityをインストールしている場合、このツールはすぐに使えます。Mac OSでUnity 2018.3.0b11の場合、Editor/2018.3.0b11/PlaybackEngines/AndroidPlayer/Tools以下にbundletool-all-0.6.0.jarというファイルが用意されていました。細かいオプションに関しては上記のリンクページを確認してみてください。ビルドする際に使用する端末情報を取得できるget-device-specは今回の用途以外でも使えそうでした。おわりに
実際にABBを利用したビルドを行ってみて、AABファイルのサイズはTarget ArchitecturesでARMv7とx86を選択したときに生成されるAPKファイルのサイズ程度であることがわかりました。またインストールサイズから、1つのAABファイルで異なるアーキテクチャの端末に対していサイズを大きくせずにアプリをインストールできることがわかりました。
実際にストアで使用する際にはGoogle Play App Signingを使用したり必要があったりして別途対応が必要になります。
また、Unity Blogの記事にある通り、ビルドからインストールまでの時間を短縮するために、普段の開発では通常のAPKを生成することがおすすめされています。
そのため、開発フローに取り入れるには少し対応が必要になりそうです。
しかし、このフォーマットに切り替えることの利点がGoogle Developersの記事で複数アナウンスされています。
まだ早期アクセスのようですがインストールAPKサイズが500MBまでのファイルをアップロードできるようになるといったことなどが挙げられています。
いずれにしても、AAB形式を扱うことでダウンロード時間を短くするのには効果があるとのことなので是非取り入れることを考えていきたいですね。
明日は須藤さんによるAppStoreReviewガイドラインの『4.2 最低限の機能』に対応した話になります!お楽しみに!
オリジナルのエンクロージャ: |
20181214152235.png |
コメント
コメントを投稿