サイト内検索
Android Studio には、ビルドプロセスが完了した後すぐにAPKの構成を調査できるAPK アナライザーが実装されています。 APKアナライザーを使用するとアプリ内のDEX ファイルとリソースに関する問題のデバッグにかかる時間を減らすことができ、 同様にAPKサイズを減らすことにも役立ちます。 Android Studio APK アナライザーを使うと、以下のようなことができます:
AndroidManifest.xmlのような)の最終バージョンを素早く見ることができます。プロジェクトを開いている時、APK アナライザーにアクセスする方法は三つあります。:
build/output/apks/ディレクトリ内にあるAPKをダブルクリックします。
重要:
デバッグビルドを分析する際には、Build > Build APKの順で選んで作成した、もしくはgradle コマンドライン上から作成したAPK を使用してください。
ツールバーの Run をクリックすると、 インスタントランが有効になっているAPKが作成されます。最適化作業の際に、このAPKをAPK アナライザーにかけるべきではありません。—
これは開発作業でのみ使用されるもので、ほとんどのリソースを動的に読み込みます。
Instant Run APKは、APK内に埋め込まれた instant-run.zipファイルで識別することができます。
APKはZIPファイル形式に従ったファイルです。 APK アナライザーは各ファイルやフォルダーを、展開してフォルダーの中身を見ることができる機能が付いたエンティティとして表示します。 エンティティの階層は、APKファイル内のファイルとフォルダーの構造を反映したものになっています。
図 1で示すように、APK アナライザーは各エンティティの raw file size と download file size を表示します。 Raw File Size とはディスク上で圧縮解除された状態のエンティティのサイズを表します。 一方Download Sizeは Google Playによって配信される際のエンティティの推定圧縮サイズを表します % of Total Download Size は、APKの総ダウンロードサイズに占めるこのエンティティのパーセンテージを表します。
図 1. APK アナライザー内でのファイルサイズ
プロジェクトが複数の AndroidManifest.xml ファイル (プロダクトフレーバーごとのマニフェストファイルのような) を含んでいたり、
マニフェストファイルを持ったライブラリを含んでいたりする場合、
それらはAPK内で一つのファイルに結合されます。
このマニフェストファイルは通常APK内ではバイナリファイルですが、
APK アナライザーの画面上でこのエンティティを選択するとXML形式に再構築されて表示されます。
このビューアーを使うことで、ビルド時にアプリに対して行われた変更について理解することができます。
例えば、あなたのアプリケーションが依存しているライブラリのAndroidManifest.xml ファイルが、どのようにして最終AndroidManifest.xmlファイルに結合されたのかを確認できます。
さらに、このビューアーではいくつかのlint 機能を提供し、画面の右上隅に警告やエラーが表示されます。 図 5 は選択したマニフェストファイルで報告されたエラーを表示しています。
図 5. 選択したマニフェストファイルのエラーアイコンが、右余白に表示されています。
ビルドの際の様々な処理によって、APKファイル内の最終的なエンティティは変更されます。 例えば、Proguard の削減ルールファイルによって最終コードは変更されることがあり、 プロダクトフレーバー内のリソースによって画像リソースは上書きされることがあります。 APK アナライザーを使えばファイルの最終バージョンを簡単に見ることができます。 : エンティティをクリックすると、ファイル一覧のすぐ下に状況依存型のファイルビューが表示されます。 これにはテキストエンティティと画像エンティティのプレビューも含まれます。
図 2. 最終画像リソースのプレビュー
APK アナライザーは様々なテキストファイルとバイナリファイルを表示することもできます。
例えば、resources.arscエンティティビューを使用することで、
文字列リソースの特定の言語翻訳のような、設定固有値を見ることができます。
図 3では、各文字列リソースの翻訳を見ることができます。
図 3. 翻訳済み文字列リソースのプレビュー
APK アナライザーのDEX ファイルビューアを使うと、アプリのDEXファイルの基礎情報にすぐにアクセスできます。 このビューアでは、クラス、パッケージ、参照、宣言の数を見ることができます。 これは、マルチDEX を使用するかどうか、64k DEX 制限を下回るようにどうやって依存ファイルを削除するか、を決めるのに役立ちます。
図 4 は 64k DEX制限に達しつつある中規模アプリを示しています。 各パッケージ、クラス、メソッドには、 Defined Method 列とReferenced Method 列にその数が一覧表記されています。 Referenced Methods 列はDEX ファイルから参照されている全てのメソッド数をカウントしています。 これには通常、コード内で定義されているメソッド、依存関係ライブラリ、標準JavaとAndroidパッケージで定義されているコードで使用しているメソッド、が含まれています。—these are the これらは各DEXファイルの64Kメソッド制限に対してカウントされているメソッドです。 Defined Methods列はDEX ファイル内で定義されているメソッドのみの数をカウントしているので、この数はReferenced Methodsの一部です。 依存ファイルをAPK内にパッケージした場合、依存ファイル内に定義されているメソッドは両方の列でカウントされるので注意してください。 また、minification と(もしくは) Proguard 削減機能を使うと、ソースコードのコンパイル後に少なからずDEX ファイルの中身が変更されるので注意してください。
図 4. マルチDEX を使用しているアプリをAPKアナライザーで表示した画面
APK アナライザーは、異なる二つのAPKファイル内にあるエンティティのサイズを比較することもできます。 これは、前回のバージョンと比べてなぜアプリのサイズが増加したのかを理解しようとする際に役立ちます。
アップデートしたAPKを配信する前に、配信しようとしてるAPKのバージョンをAPK アナライザーに読み込んでください。 そしてAPK アナライザーウィンドウの右上隅にあるCompare Withをクリックします。 選択ダイアログで、最後にユーザーに配信したAPKを探してOKをクリックします。 図 6 のようなダイアログが表示され、このアップデートがユーザーに与える営業を比較することができます。
図 6 はあるアプリのデバッグビルドとリリースビルドの違いを示しています。 これらのビルドタイプでは異なるビルドオプションが使用されており、それによりエンティティの基礎的な部分で違いが生じているのです。
図 6. デバッグAPKとリリースAPKの違い