bazel モバイル インストール

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

Android の迅速な反復開発

このページでは、bazel mobile-install を使用して Android の反復開発 を大幅に高速化する方法について説明します。このアプローチのメリットと、 従来の方法でアプリをインストールする際の問題点について説明します。

概要

Android アプリに小さな変更をすばやくインストールするには、次の操作を行います。

  1. インストールするアプリの android_binary ルールを見つけます。
  2. proguard_specs 属性を削除して、Proguard を無効にします。
  3. multidex 属性を native に設定します。
  4. dex_shards 属性を 10 に設定します。
  5. ART（Dalvik ではない）を実行しているデバイスを USB で接続し、USB デバッグを有効にします。
  6. bazel mobile-install :your_target を実行します。アプリの起動が通常より少し 遅くなります。
  7. コードまたは Android リソースを編集します。
  8. bazel mobile-install --incremental :your_target を実行します。
  9. 待つ必要がなくなります。

Bazel のコマンドライン オプションの一部を次に示します。

  • --adb は、使用する adb バイナリを Bazel に伝えます。
  • --adb_arg を使用すると、adb のコマンドラインに引数を追加できます。 たとえば、ワークステーションに複数のデバイスが接続されている場合に、インストール先のデバイスを選択できます。 bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target
  • --start_app はアプリを自動的に起動します。

不明な点がある場合は、 例 を参照するか、Google までお問い合わせください。

はじめに

デベロッパーのツールチェーンの最も重要な属性の 1 つは速度です。コードを変更して 1 秒以内に実行できる場合と、変更が期待どおりに機能するかどうかを確認するまでに数分、場合によっては数時間も待つ必要がある場合とでは、大きな違いがあります。

残念ながら、.apk をビルドするための従来の Android ツールチェーンには 多くのモノリシックなシーケンシャル ステップが含まれており、Android アプリをビルドするには、これらのステップをすべて実行する必要があります。Google では、Google マップなどの大規模なプロジェクトで、1 行の変更をビルドするのに 5 分かかることも珍しくありませんでした。

bazel mobile-install は、変更のプルーニング、ワーク シャーディング、Android 内部の巧妙な操作を組み合わせて使用することで、アプリのコードを変更することなく、Android の反復開発を大幅に高速化します。

従来の方法でアプリをインストールする際の問題点

Android アプリのビルドには、次のような問題があります。

  • dex 変換。デフォルトでは、ビルドで「dx」が 1 回だけ呼び出されます。以前のビルドの作業を再利用する方法がわからないため、1 つのメソッドのみが変更された場合でも、すべてのメソッドが再度 dex 変換されます。

  • デバイスへのデータのアップロード。adb は USB 2.0 接続の全帯域幅を使用しないため、サイズの大きいアプリのアップロードに時間がかかることがあります。リソースや単一のメソッドなど、一部のみが変更された場合でも、アプリ全体が アップロードされるため、ボトルネックになる可能性があります。

  • ネイティブ コードへのコンパイル。Android L では、新しい Android ランタイムである ART が導入されました。 ART は、Dalvik のようにジャストインタイムでコンパイルするのではなく、事前コンパイルを行います。 これにより、アプリの速度は大幅に向上しますが、インストール時間 が長くなります。ユーザーは通常、アプリを 1 回インストールして何度も使用するため、これはユーザーにとって良いトレードオフです。ただし、アプリが 何度もインストールされ、各バージョンが数回しか実行されない開発では、速度が低下します。

bazel mobile-install のアプローチ

bazel mobile-install では、次のような改善が行われています。

  • シャーディングされた dex 変換。アプリの Java コードをビルドした後、Bazel はクラス ファイルをほぼ同じサイズのパーツに分割し、dxそれぞれに対して個別に 呼び出します。dx は最後のビルド以降に変更されていないシャードに対して呼び出されません。

  • 増分ファイル転送。Android リソース、.dex ファイル、ネイティブ ライブラリは、メインの .apk から削除され、別の mobile-install ディレクトリに保存されます。これにより、アプリ全体を再インストールすることなく、コードと Android リソースを個別に更新できます。そのため、 ファイルの転送に時間がかからず、変更された .dex ファイルのみが デバイス上で再コンパイルされます。

  • .apk の外部からアプリの一部を読み込む。小さなスタブ アプリケーションが .apk に配置され、デバイス上の mobile-install ディレクトリから Android リソース、Java コード、ネイティブ コード を読み込み、実際のアプリに制御を転送します。これは、後述するいくつかの特殊なケース を除き、アプリに対して透過的です。

シャーディングされた dex 変換

シャーディングされた dex 変換は比較的簡単です。.jar ファイルがビルドされると、a ツール によってほぼ同じサイズの個別の .jar ファイルに分割され、前のビルド以降に変更されたファイルに対して dxが呼び出されます。dex 変換するシャードを決定するロジックは Android に固有のものではなく、Bazel の一般的な変更プルーニング アルゴリズムを使用します。

シャーディング アルゴリズムの最初のバージョンでは、.class ファイルがアルファベット順に並べ替えられ、リストが同じサイズのパーツに分割されましたが、これは最適ではありませんでした。クラスが追加または削除されると（ネストされたクラスや匿名クラスでも）、その後のすべてのクラスが 1 つずつシフトし、それらのシャードが再度 dex 変換されることになります。そのため、個々のクラスではなく Java パッケージをシャーディングすることになりました。もちろん、新しいパッケージが追加または削除された場合でも、多くのシャードが dex 変換されますが、単一のクラスの追加または削除よりも頻度ははるかに 少なくなります。

シャードの数は、BUILD ファイル（ android_binary.dex_shards 属性を使用）によって制御されます。理想的には、Bazel が 最適なシャード数を自動的に判断しますが、Bazel は現在、アクションのセット（ビルド中に実行されるコマンドなど）を 把握してから実行する必要があります。そのため、アプリに最終的に含まれる Java クラスの数がわからないため、最適なシャード数を 判断できません。一般的に、シャードが多いほど、ビルドと インストールの速度は速くなりますが、動的 リンカーの処理が増えるため、アプリの起動が遅くなります。通常、最適なシャード数は 10 ～ 50 個です。

増分ファイル転送

アプリをビルドしたら、次のステップはインストールです。できるだけ手間をかけずにインストールすることをおすすめします。インストールは次の手順で行います。

  1. .apk のインストール（通常は adb install を使用）
  2. .dex ファイル、Android リソース、ネイティブ ライブラリを mobile-install ディレクトリにアップロードする

最初のステップでは、アプリがインストールされるかどうかのいずれかであるため、増分はあまりありません。Bazel は、このステップが必要かどうかを判断できないため、ユーザーがこのステップを実行するかどうかを --incremental コマンドライン オプションを使用して指定する必要があります。

2 番目のステップでは、ビルドのアプリファイルが、デバイス上のアプリファイルとその チェックサムを一覧表示するデバイス上の マニフェスト ファイルと比較されます。新しいファイルはデバイスにアップロードされ、変更されたファイルは 更新され、削除されたファイルは デバイスから削除されます。マニフェストが存在しない場合は、すべてのファイルをアップロードする必要があるとみなされます。

デバイス上のファイルを変更しても、マニフェストのチェックサムを変更しないことで、増分インストール アルゴリズムをだますことができます。デバイス上のファイルのチェックサムを計算することで、これを防ぐことができますが、インストール時間の増加に見合うものではないと判断されました。

スタブ アプリケーション

スタブ アプリケーションは、デバイス上の mobile-install ディレクトリから dex、ネイティブ コード、 Android リソースを読み込むための処理が行われる場所です。

実際の読み込みは、BaseDexClassLoader をサブクラス化することで実装され、 十分に文書化された手法です。これはアプリの クラスが読み込まれる前に行われるため、apk 内のアプリケーション クラスをデバイス上の mobile-install ディレクトリに配置して、adb install を使用せずに更新できます。

アプリの クラスが読み込まれる前にこれを行う必要があります。これにより、アプリケーション クラスを .apk に含める必要がなくなり、これらのクラスを変更してもフル 再インストールする必要がなくなります。

これは、Application クラスを AndroidManifest.xmlで指定された スタブ アプリケーションに置き換えることで実現されます。アプリが起動すると、このクラスが制御を引き継ぎ、Android フレームワークの内部で Java リフレクションを使用して、クラスローダーと リソース マネージャーを適切なタイミング（コンストラクタ）で調整します。

スタブ アプリケーションは、mobile-install によってインストールされたネイティブ ライブラリ を別の場所にコピーします。動的リンカーはファイルに X ビットを設定する必要があるため、これは必要です。ルート以外の adb でアクセスできる場所では、これを行うことはできません。

これらの処理がすべて完了すると、スタブ アプリケーションは実際の Application クラスをインスタンス化し、Android フレームワーク内の実際の アプリケーションへの参照をすべて変更します。

結果

パフォーマンス

一般的に、bazel mobile-install を使用すると、小さな変更後の大規模なアプリのビルド とインストールが 4 ～ 10 倍速くなります。

次の数値は、いくつかの Google プロダクトで計算されたものです。

これもちろん、変更の内容によって異なります。ベース ライブラリを変更した後の再コンパイルには時間がかかります。

制限事項

スタブ アプリケーションの処理は、すべてのケースで機能するわけではありません。 次のようなケースでは、期待どおりに動作しません。