前置き
いろいろとライブラリを導入していったら、プロジェクトの初期にもかかわらず65K 問題が発生・・・。
2日ぐらい悪戦苦闘してベスト・プラクティスを発見したのでメモ。
Proguradで挫折
とりあえずは下記ページを参考にした。
Multidex化してもよいのだけれど、アプリのサイズが増えるのがどうしても許容できなかったため、proguardで利用していないメソッドを消す戦略をとった。
頑張った結果、アプリケーションの65K問題を回避できた。
ただdebugビルドにもproguardファイルが必須となり、testで65k問題が発生する・・・！ヽ(｀Д´)/
Instrumentation周りのproguard設定はかなり辛くて挫折。。。
JakeWharton神
現実逃避しながらgithubの海を漂っていると神スクリプトが・・・！
ソースは、GooglePlayService 5.0のmethod数を数えてみたって内容の記事だった。
65k問題の犯人探し
私の場合、leakcanaryを導入する前と後でmethod数が65kをちょうど超えたので、コレを導入する前のプロジェクト内のmethod数を数えた。
1. Smaliのinstall
smaliをinstallする
必要なのは下記の4ファイル
- smali
- smali-x.y.z.jar
- baksmali
- baksmali-x.y.z.jar
downloadしてPathを通しておく。
2. dex-method-countのinstall
~/.zshrc とか ~/.bashrc とかに上のスクリプトを突っ込む。
あるいは普通にsource dex.shしても。
3. 確認
65Kに至る前の状態で、dexファイルを作成する。
$ ./gradlew assemble
$ find . -type f -name '*.dex'
./app/build/intermediates/dex/debug/classes.dex
対象のdexファイルのmethod数を数える
$ dex-method-count-by-package ./app/build/intermediates/dex/debug/classes.dex
...
28197 com.google.android.gms
3370 android.support.v7.widget
3325 android.support.v4.view
3120 android.support.v7.internal
2098 android.support.v4.app
1758 android.support.v4.widget
1729 io.fabric.sdk.android
1491 android.support.v4.media
924 com.crashlytics.android.core
...
確認した結果、JakeWhartonさんのブログにもある通り、com.google.android.gmsが膨大なmethod数を参照している犯人だった。
対処
map部分のライブラリだけが必要だったので、コレのみを参照するようにした。
compile 'com.google.android.gms:play-services:7.0.0'
compile 'com.google.android.gms:play-services-maps:7.5.0'
実行するとmethod数が激減！！
6737 com.google.android.gms
というか、普通にGooglePlayの導入ページに注意書きで書いてあった.. orz
結論
GooglePlayServicesが大体犯人なので、コレを分割して必要なパッケージだけ導入しましょう。