前置き

いろいろとライブラリを導入していったら、プロジェクトの初期にもかかわらず65K 問題が発生・・・。
2日ぐらい悪戦苦闘してベスト・プラクティスを発見したのでメモ。

Proguradで挫折

とりあえずは下記ページを参考にした。

Androidのメソッド数が65k(65536)を超えた場合にビルドができなくなる問題の対処法

Multidex化してもよいのだけれど、アプリのサイズが増えるのがどうしても許容できなかったため、proguardで利用していないメソッドを消す戦略をとった。

頑張った結果、アプリケーションの65K問題を回避できた。
ただdebugビルドにもproguardファイルが必須となり、testで65k問題が発生する・・・！ヽ(｀Д´)/

Instrumentation周りのproguard設定はかなり辛くて挫折。。。

JakeWharton神

現実逃避しながらgithubの海を漂っていると神スクリプトが・・・！

dex.sh

ソースは、GooglePlayService 5.0のmethod数を数えてみたって内容の記事だった。

Play Services 5.0 Is A Monolith Abomination

65k問題の犯人探し

私の場合、leakcanaryを導入する前と後でmethod数が65kをちょうど超えたので、コレを導入する前のプロジェクト内のmethod数を数えた。

1. Smaliのinstall

smaliをinstallする

https://bitbucket.org/JesusFreke/smali/downloads

必要なのは下記の4ファイル

smali
smali-x.y.z.jar
baksmali
baksmali-x.y.z.jar

downloadしてPathを通しておく。

2. dex-method-countのinstall

dex.sh

~/.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

https://developers.google.com/android/guides/setup

結論

GooglePlayServicesが大体犯人なので、コレを分割して必要なパッケージだけ導入しましょう。