概要
Androidはアプリ内で定義しているメソッド数(依存ライブラリも含む)が65536を超えると、ビルドできなくなる問題があります。
この問題に対する対応法はこちらの記事を参照していただけば十分であるが、Proguardでの対処法について具体例がないため本記事ではそのあたりについて述べます。
注意
正直Proguardで対応するよりも、上記の記事の通りにMultiple Dex Filesを使用して対応した方が汎用性があり、かつデメリットが少ないのでオススメです。
Proguardでやる
Proguardには難読化(obfuscate)以外に、使用していないメソッドの削除(shrink)、最適化(optimize)といった機能があります。
今回はメソッド数が65536を超えてしまった場合に、Proguardで使用していないメソッドを削除させてメソッド数を65536以下に押さえ込むことを考えます。
(Proguardを使用しメソッドを削除しても65536を超える場合はMultiple Dex Filesを使用して対応してください。)
Proguardはデフォルトで使用していないメソッドの削除機能が有効なので、Proguardを有効にすればOKです。
しかし、デバッグビルドでもProguardによる難読化・最適化がなされてしまうとデバッグに非常に手間取るため、これらを無効にします。
buildTypes {
debug {
debuggable true
// デバッグビルドでもProguardを有効にする
minifyEnabled true
// デバッグビルド用のProguardルールファイル proguard-rules-debug.pro を指定する。
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules-debug.pro'
}
release {
debuggable false
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
proguard-rules-debug.proは下記の通り。
# リリースビルド用のProgurdルールをインポートする
-include proguard-rules.pro
# テストとかのため、自信で記述したアプリケーションのクラスは保持
-keep class your.application.packagename.** { *; }
# シュリンクはする
#-dontshrink
# 難読化しない
-dontobfuscate
# 最適化しない
-dontoptimize
これでProguardによる難読化・最適化されずに、使用していないメソッドの削除がなされます。
Proguardでやることのメリット・デメリット
メリット
- Multiple Dex Filesを使用するとパフォーマンスが悪い(らしい)のを回避できる
- 個人的にはこれを体感したことがない…
- Multiple Dex Filesを使用するとアプリのファイルサイズが増えるのを回避できる
デメリット
- デバッグビルドでもビルドに時間がかかるようになる
- アプリの規模にもよりますが、10画面以上の商用アプリでビルド時間が倍近くに延びました。正直いらいらするレベルです。
- 使用していないメソッドを削除してもメソッド数が65536を超える場合には、どうにせよMultiple Dex Filesを使用しなければならない
まとめ
メリットの少なさのわりにデメリットが大きいので、おとなしくMultiple Dex Filesにしとけってことですね。