機能拡張やマルチモジュール構成化もありデバッグビルドがどんどん遅くなっていったので、Androidが推奨するビルド速度の最適化の中で適用できるものを試してみました。
計測方法
以下のコマンドでクリーンビルドの時間を計測しました。ネットワーク状況による誤差をなくすため、オフラインモードで実行します。
./gradlew clean
./gradlew assembleDevDebug --offline
不要なリソースのコンパイルを回避
build.gradleに以下のような記述を追加し、対象の言語や画像リソースを限定することで、ビルド速度の改善が期待できるようです。
android {
...
productFlavors {
dev {
resConfigs "en", "xxhdpi"
}
...
}
}
開発を担当しているReluxではテストに複数言語が必要なため、resConfigs "xxhdpi"
のみを追加。
計測
前 | 後 |
---|---|
10m15s | 10m16s |
早くなっていない・・・言語ファイルも限定できる場合は早くなるのだろう・・。 |
デバッグビルドでのCrashlyticsの無効化
デバッグビルドでCrashlyticsへのレポートが不要な場合は、その設定を無効にします。
android {
...
buildTypes {
debug {
ext.enableCrashlytics = false
}
}
val crashlytics = Crashlytics.Builder()
.core(CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
.build()
Fabric.with(this, crashlytics)
計測
前 | 後 |
---|---|
10m16s | 10m11s |
微妙に早くなったのかな・・? |
静的な依存関係バージョンを使用
build.gradle内でバージョン番号の後ろにプラス記号をつけて記述しているものをハードコード指定に置き換えます。一つ該当していましたので置き換え。
//classpath 'io.fabric.tools:gradle:1.+'
classpath 'io.fabric.tools:gradle:1.29.0'
計測
前 | 後 |
---|---|
10m11s | 9m23s |
結構早くなった!プラス記号を多く使っているプロジェクトの場合はさらに改善が見込めそう・・! |
Gradleヒープサイズの増加とdex-inプロセスの有効化
build.gradleのdexOptionsのjavaMaxHeapSizeの値を調整し、gradle.propertiesに下記のような記述を追加します。XmxはjavaMaxHeapSizeに+1024MBした値にすると良いようです。
dexOptions {
javaMaxHeapSize "4g"
}
org.gradle.jvmargs= -Xmx5120M
計測
前 | 後 |
---|---|
9m23s | 8m49s |
早くなったー! |
約14%高速化(10m15s -> 8m49s)できました(^_^)/