Android Studio の最近の追加機能の 1 つは APK アナライザーです。 トップメニューの Build → Analyze APK で確認できます。
APK Analyzer では、ローカルの Android Studio プロジェクトから構築した、または構築サーバーやその他の成果物リポジトリから取得した、コンピューター上の任意の APK ファイルの内容を開いて検査することができます。 Android Studio で開いているプロジェクトからビルドする必要はなく、その特定の APK のソース コードも必要ありません。
Note: APK Analyzer はリリース ビルドで最も効果的に機能します。 アプリのデバッグ ビルドを分析する必要がある場合は、Instant Run 用にインスツルメンテーションされていない APK を使用していることを確認します。 それを取得するには、Build → Build APKcommand を使用します。 アーカイブ内の instant-run.zip ファイルの存在を確認することにより、Instant Run のインスツルメンテッド APK を開いたかどうかを確認できます。
APK アナライザーを使用すると、APK ファイルの周りを突いてその構造について学び、リリース前にファイルの内容を確認したり、APK サイズや DEX 問題などのいくつかの共通の問題をデバッグする素晴らしい方法となります。 画面の上部には、APK のディスク上のサイズである Raw ファイル サイズが表示されます。 ダウンロード サイズは、Play ストアによって適用される圧縮を考慮して、アプリをダウンロードするために使用されるデータ量の推定値を示します。 このため、APK サイズ最適化の低ぶら下がり果実を特定するのに適しています。 フォルダをドリルダウンするたびに、APK で最もスペースを取っているリソースやその他のエンティティを確認することができます。
This example, when examining an APK for possible size reduction, I could immediately notice that 3-frame PNG animation is a single biggest thing in drawable resources, weigh at 1.0 in the same size.これらの画像はベクターとして保存するのに最適な候補のように見えるので、アートワークのソース ファイルを見つけ、Android Studio 2.2 の Vector Asset インポート ツールの新しい PSD サポートを使用して、VectorDrawables としてインポートしました。 下位互換性を維持するために、サポート ライブラリから VectorDrawableCompat を使用しました。
他のリソース フォルダを見ると、OGG に変換できるいくつかの非圧縮 WAV ファイルを簡単に見つけることができ、コードの行に触れることなくさらに節約することができました。
次にチェックすべきは lib/ フォルダーで、そこには当社がサポートする 3 つの ABI に対するネイティブ ライブラリが含まれていました。
Gradle ビルドで APK splits サポートを使用して、各 ABI に対して別々のバージョンのアプリを作成することに決定しました。
次に AndroidManifest.xml にすばやく目を通し、<application> に android:extractNativeLibs 属性がないことに気付きました。 この属性を false に設定すると、APK からファイル システムにネイティブ ライブラリをコピーアウトすることを防ぐため、デバイス上のスペースを節約できます。 唯一の要件は、ファイルがページアラインメントされ、APK 内に非圧縮で保存されていることで、これは Android Gradle プラグイン バージョン 2.2.0+ の新しいパッケージャーでサポートされています。
これらの変更を行った後、新しいバージョンのアプリが以前のものと比較してどのようになるかに興味を持ちました。 そのため、開始した git コミットからソースをチェックアウトし、APK をコンパイルして、別のフォルダーに保存しました。 それから、Compare with…機能を使って、新旧のビルド間のサイズの違いの内訳を確認しました。
リソースとネイティブ ライブラリを大きく前進させ、アプリにほとんど変更を加えずに合計 17 MB を削減することに成功しました。 しかし、DEX サイズが後退し、classes2.dex が 400KB 増加したことがわかります。
DEX の問題のデバッグ
この場合、依存関係を新しいバージョンにアップグレードして新しいライブラリーを追加することで違いが生じました。 Proguard と Multidex はすでにビルドで有効になっていたため、DEX サイズについてできることはあまりありません。 それでも、APK アナライザーは、このセットアップの問題をデバッグするための素晴らしいツールです。特に、プロジェクトで初めて Multidex または Proguard を有効にする場合はそうです。dex
任意の DEX ファイルをクリックすると、それが定義しているクラスとメソッドの数、および含まれている参照の合計数 (単一の DEX ファイルで 64K の制限に対してカウントされるのは参照) の概要が表示されます。 このスクリーンショットの例では、アプリはちょうど制限に達しようとしており、近い将来 MultiDex でクラスを別のファイルに分割する必要があることを意味します。 この場合、Support ライブラリと Google Play サービスがこの状況の主な原因であることがわかります:
MultiDex を有効にしてアプリをコンパイルしたら、2つ目の classes2.XXX が表示されます。dex ファイル (そして、場合によっては classes3.dex など) が表示されます。 Android gradle プラグインの MultiDex ソリューションは、アプリの起動に必要なクラスを見つけ出し、それらをプライマリ classes.dex ファイルに配置しますが、それがうまくいかず ClassNotFoundException が発生した場合、APK Analyzer を使用して DEX ファイルを検査し、不足しているクラスをプライマリ DEX ファイルに強制的に配置することができます。 APK アナライザーは、必要なメソッドやクラスが APK に存在するかどうか、また、名前が変更 (難読化) されているかどうかを簡単に確認できるため、Proguard 設定が正しいかどうかを確認する際に役立ちます。 また、削除したいクラスが実際に削除され、貴重な参照メソッド数を占めていないことを確認することもできます。