HSPTV!掲示板

Gradle対応のDish Helperで初めてaabファイルを作りました。
keystoreファイルはGradle対応以前のDish Helperで作成したもので大丈夫でした。

また、驚いたことは、デバックビルドのapkファイルよりもリリースビルドしたaabファイルのほうが処理速度が速かったことです。
下記アプリがリリースされて、インストールしたところ一番処理の重い（文字を大量に表示する）ところのFPSがaabでは「59〜60」と安定した速度が出ていました。apkでは「43〜45」位でした。
使用Android機は、「UMIDIGI A3 PRO」という機種でAndroid 9です。

MediaTek MT6739
メモリ：3GB
ストレージ：32GB

「PIYOKO DEFENSE」
https://play.google.com/store/apps/details?id=com.simakuroneko.piyoko_defense

動画
https://www.youtube.com/watch?v=lWV1DYbcW2k

iPhone投稿の部外者です。
私が書かなくてもご存知かと。

ファイル自体が、小さくなってませんか？

元々、過去のapkファイルには
使わない言語ファイル等が含まれて
ビルドされていたようで、aab 提出に
なってから、この辺りをGoogle側で
削減して最適化？するようになったようです。

(※aab化については、優良アプリの囲い込み
審査、ウイルス系対策、ファイルサイズ減による
Google側の通信量削減等が目的で
この件はオマケらしい？ですが。)


動作タイミングに関わる問題でなく
操作感の向上、等のユーザー側の
メリットに繋がっているなら
良かったのではないでしょうか。

> ファイル自体が、小さくなってませんか？

インストール前のapkは27.62MBで、aabは28.02MBでした。
インストール後のapkは29.75MBで、aabは31.78MBでした。
aabの方が大きいですね。

> 動作タイミングに関わる問題でなく
> 操作感の向上、等のユーザー側の
> メリットに繋がっているなら
> 良かったのではないでしょうか。

そうですね。
処理速度が上がってくれて有難いです。

aabはあくまでストアへのアップロード形式で、それを元にGoogleが各アーキテクチャ向けにビルドしてapkを生成、配信するという認識です。
なのでGoogleの最適化が効いてるんでしょうね。

従来のdishで作成したapkには arm/x86 それぞれ 32/64bit 計4つの.soが入っていましたが、ユーザー端末で使われるのはどれか1つで他の3つは使われませんでした。

あまり問題ではないでしょうがaabになってひとつユーザーにとってデメリットがあって、インストール済アプリからapkをバックアップしても、それが使えるのは同じアーキテクチャを採用した端末だけだということです(それ用のコードしか含まれていないため)。

> 窓月ららさん
分かりやすい解説ありがとうございます。