Android の迅速な反復開発
このページでは、bazel mobile-install を使用して Android の反復開発を大幅に高速化する方法について説明します。このアプローチのメリットと、ビルドとインストールの手順を別々に行うことのデメリットについて説明します。
概要
Android アプリに小さな変更を非常に迅速にインストールするには、次の操作を行います。
- インストールするアプリの
android_binaryルールを見つけます。 - デバイスを
adbに接続します。 bazel mobile-install :your_targetを実行します。アプリの起動が通常より少し遅くなります。- コードまたは Android リソースを編集します。
bazel mobile-install :your_targetを実行します。- 高速で最小限の増分インストールをお楽しみください。
Bazel のコマンドライン オプションで役立つものの一部を次に示します。
--adbは、使用する adb バイナリを Bazel に伝えます。--adb_argを使用すると、adbのコマンドラインに追加の引数を追加できます。 この方法の便利な用途の 1 つは、ワークステーションに複数のデバイスが接続されている場合に、インストール先のデバイスを選択することです。bazel mobile-install :your_target -- --adb_arg=-s --adb_arg=<SERIAL>
不明な点がある場合は、 例を参照するか、 Google グループで問い合わせるか、 GitHub の問題を報告してください。
はじめに
デベロッパーのツールチェーンの最も重要な属性の 1 つは速度です。コードを変更して 1 秒以内に実行できる場合と、変更が期待どおりに機能するかどうかについてフィードバックを得るまでに数分、場合によっては数時間待つ必要がある場合とでは、大きな違いがあります。
残念ながら、.apk をビルドするための従来の Android ツールチェーンには、多くのモノリシックなシーケンシャル ステップが含まれており、Android アプリをビルドするには、これらのステップをすべて実行する必要があります。Google では、Google マップなどの大規模なプロジェクトで、1 行の変更をビルドするのに 5 分かかることは珍しくありませんでした。
bazel mobile-install は、変更のプルーニング、ワーク シャーディング、Android 内部の巧妙な操作を組み合わせて使用することで、アプリのコードを変更することなく、Android の反復開発を大幅に高速化します。
従来のアプリのインストールに関する問題
Android アプリのビルドには、次のような問題があります。
dex 変換。デフォルトでは、Dexer ツール（以前は
dx、現在はd8またはr8）はビルドで 1 回だけ呼び出され、以前のビルドの作業を再利用する方法がわかりません。1 つのメソッドのみが変更された場合でも、すべてのメソッドが再度 dex 変換されます。デバイスへのデータのアップロード。adb は USB 2.0 接続の全帯域幅を使用しないため、サイズの大きいアプリのアップロードに時間がかかることがあります。リソースや単一のメソッドなど、一部のみが変更された場合でも、アプリ全体がアップロードされるため、これがボトルネックになる可能性があります。
ネイティブ コードへのコンパイル。Android L では、新しい Android ランタイムである ART が導入されました。ART は、Dalvik のようにジャストインタイムでコンパイルするのではなく、アプリを事前コンパイルします。これにより、インストール時間が長くなる代わりに、アプリの速度が大幅に向上します。通常、ユーザーはアプリを 1 回インストールして何度も使用するため、これはユーザーにとって良いトレードオフですが、アプリが何度もインストールされ、各バージョンが数回しか実行されない開発では、速度が低下します。
bazel mobile-install のアプローチ
bazel mobile-install では、次のように改善されています。
シャーディングされた desugaring と dex 変換。アプリの Java コードをビルドした後、Bazel はクラスファイルをほぼ同じサイズのパーツに分割し、それらに対して個別に
d8を呼び出します。d8は、前回のビルドから変更されていないシャードでは呼び出されません。これらのシャードは、個別のシャーディングされた APK にコンパイルされます。増分ファイル転送。Android リソース、.dex ファイル、ネイティブ ライブラリはメインの .apk から削除され、別の mobile-install ディレクトリに保存されます。これにより、アプリ全体を再インストールせずに、コードと Android リソースを個別に更新できます。そのため、ファイルの転送に時間がかからず、変更された .dex ファイルのみがデバイス上で再コンパイルされます。
シャーディングされたインストール。Mobile-install は、Android Studio の
apkdeployerツールを使用して、接続されたデバイス上のシャーディングされた APK を結合し、まとまりのある エクスペリエンスを提供します。
シャーディングされた dex 変換
シャーディングされた dex 変換は比較的簡単です。.jar ファイルがビルドされると、a
ツール
によってほぼ同じサイズの個別の .jar ファイルに分割され、前回のビルドから変更されたファイルに対して
d8が呼び出されます。dex 変換するシャードを決定するロジックは Android 固有のものではなく、Bazel の一般的な変更プルーニング アルゴリズムを使用します。
シャーディング アルゴリズムの最初のバージョンでは、.class ファイルがアルファベット順に並べ替えられ、リストが同じサイズのパーツに分割されましたが、これは最適ではありませんでした。クラスが追加または削除されると（ネストされたクラスや匿名クラスでも）、その後のすべてのクラスがアルファベット順に 1 つずつシフトし、それらのシャードが再度 dex 変換されることになります。そのため、個々のクラスではなく Java パッケージをシャーディングすることになりました。もちろん、新しいパッケージが追加または削除された場合は、多くのシャードが dex 変換されますが、これは単一のクラスの追加または削除よりも頻度がはるかに少なくなります。
シャードの数は、--define=num_dex_shards=N フラグを使用して、コマンドライン構成で制御されます。理想的には、Bazel が最適なシャード数を自動的に決定しますが、Bazel は現在、アクション（ビルド中に実行されるコマンドなど）のセットを把握してから実行する必要があります。そのため、アプリに最終的に含まれる Java クラスの数がわからないため、最適なシャード数を決定できません。一般的に、シャードが多いほど、ビルドとインストールの速度は速くなりますが、動的リンカーがより多くの作業を行う必要があるため、アプリの起動が遅くなります。通常、最適な数は 10 ～ 50 個のシャードです。
増分デプロイ
増分 APK シャードの転送とインストールは、
apkdeployer ユーティリティによって、「mobile-install のアプローチ」で説明されているように処理されるようになりました。
以前の（ネイティブ）バージョンの mobile-install では、初回インストールを手動で追跡し、以降のインストールで --incremental
フラグを選択的に適用する必要がありましたが、rules_android
の最新バージョンでは大幅に簡素化されました。アプリがインストールまたは再インストールされた回数に関係なく、同じ mobile-install 呼び出しを使用できます。
大まかに言うと、apkdeployer ツールはさまざまな adb サブコマンドのラッパーです。メインのエントリ ポイント ロジックは
com.android.tools.deployer.Deployer
クラスにあり、他のユーティリティ クラスは同じパッケージに配置されています。
Deployer クラスは、分割された
APK のパスのリストやインストールに関する情報を含む protobuf などを取り込み、
Android App Bundle のデプロイ機能
を利用してインストール セッションを作成し、アプリの分割を増分的にデプロイします。
実装の詳細については、ApkPreInstaller
と ApkInstaller
クラスをご覧ください。
結果
パフォーマンス
一般的に、bazel mobile-install を使用すると、小さな変更後の大規模なアプリのビルドとインストールが 4 ～ 10 倍高速化されます。
次の数値は、いくつかの Google プロダクトで計算されたものです。
これはもちろん、変更の内容によって異なります。ベース ライブラリを変更した後の再コンパイルには時間がかかります。
制限事項
スタブ アプリケーションのトリックは、すべてのケースで機能するわけではありません。 次のようなケースでは、期待どおりに動作しません。
Mobile-install は、
rules_androidの Starlark ルールでのみサポートされています。 詳しくは、"mobile-install の簡単な歴史"について ご覧ください。ART を実行しているデバイスのみがサポートされています。Mobile-install は、Dalvik ではなく ART を実行しているデバイスにのみ存在する API とランタイム機能を使用します。Android L（API 21 以降）より新しい Android ランタイムは互換性があるはずです。
Bazel 自体は、ツール Java ランタイムと 17 以上の言語バージョンで実行する必要があります。
8.4.0 より前の Bazel バージョンでは、mobile-install 用に追加のフラグを指定する必要があります。Bazel Android チュートリアルをご覧ください。これらのフラグは、Starlark mobile-install アスペクトの場所と、サポートされているルールを Bazel に通知します。
mobile-install の簡単な歴史
以前の Bazel バージョンには、C++、Java、Android などの一般的な言語とエコシステム用の組み込みのビルドルールとテストルールがネイティブで含まれていました。 そのため、これらのルールはネイティブ ルールと呼ばれていました。 これらのルールの多くは Starlark言語に移行されたため、Bazel 8（2024 年リリース）ではこれらのルールの サポートが終了しました。詳しくは、"Bazel 8.0 LTS ブログ投稿" をご覧ください。
従来のネイティブ Android ルールでは、mobile-install 機能の従来のネイティブ バージョンもサポートされていました。 これは現在、「mobile-install v1」または「ネイティブ mobile-install」と呼ばれています。この機能は、組み込みの Android ルールとともに Bazel 8 で削除されました。
現在、すべての mobile-install 機能とすべての Android ビルドルールとテストルールは Starlark で実装され、rules_android GitHub リポジトリに存在します。最新バージョンは「mobile-install v3」または「MIv3」と呼ばれます。
命名に関する注意: Google 社内でのみ利用可能な「mobile-install v2」がかつて存在しましたが、外部には公開されませんでした。Google 社内と OSS の rules_android デプロイの両方で v3 のみが引き続き使用されています。