はじめに
「ちょっとコードを1行直しただけなのに、ビルドに3分かかる」
この地味な待ち時間が、開発の集中力を一番削っている人は多いはずだ。
Android Studioのビルドを担っているのはGradleだ。
Android Studio本体の重さとは別に、プロジェクトのビルド構成そのものが遅い というケースは非常に多い。逆に言えば、構成を見直すだけで、体感速度が大きく変わる余地が残っている。
この記事では、gradle.propertiesやbuild.gradle.ktsをいじるだけで効果が出る、再現性の高い高速化設定 を優先度順にまとめた。
Android Studio自体の動作が重い場合は、以下の記事もあわせて参考にしてほしい。
関連記事：[Android Studioが重い・起動しない・エラーが出る時の原因と対処法]
まずボトルネックを特定する
設定をいじる前に、どこに時間がかかっているかを把握しておくと無駄がない。Android StudioにはBuild Analyzerという診断機能が標準で搭載されている。
Build メニューから Analyze Build を実行すると、タスクごとの所要時間や、キャッシュが効いていない原因が一覧表示される。特にガベージコレクションがビルド時間の15%を超えている場合 は、ヒープサイズ不足のサインなので、後述のJVM設定を優先して見直してほしい。
gradle.propertiesで効く設定
プロジェクト直下のgradle.propertiesは、ビルド全体の挙動を左右する最重要ファイルだ。以下の設定は、多くのプロジェクトで効果が確認できる定番の組み合わせになる。
# 並列ビルドを有効化
org.gradle.parallel=true
# ビルドキャッシュを有効化（同じ入力のタスクを再実行しない）
org.gradle.caching=true
# デーモンを常駐させ、次回起動を高速化
org.gradle.daemon=true
# JVMヒープサイズとGCの調整
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1g -XX:+UseParallelGC
# 構成キャッシュ（Gradle 8以降で安定版）
org.gradle.configuration-cache=true
| 設定項目 | 効果 | 注意点 |
|---|---|---|
org.gradle.parallel |
複数モジュールを並列コンパイル | モジュール分割されていないと効果が薄い |
org.gradle.caching |
タスク単位で結果を再利用 | クリーンビルド直後は効果を実感しにくい |
org.gradle.jvmargs |
ヒープ不足によるGC頻発を防ぐ | 値を上げすぎるとマシン全体が重くなる |
org.gradle.configuration-cache |
構成フェーズ自体をスキップ | 一部のプラグインが未対応の場合がある |
ヒープサイズは搭載メモリの半分以下を目安にするのが無難だ。16GB環境なら-Xmx4g〜-Xmx6gあたりから試し、Build Analyzerでビフォーアフターを比較するとよい。
依存関係とアノテーション処理の見直し
kaptからKSPへ移行する
RoomやHiltなどのアノテーション処理をkaptで行っている場合、これはKotlin Symbol Processing（KSP） に切り替えるだけでビルド時間が大きく短縮できる代表的なポイントだ。kaptはKotlinのコードを一度Javaのスタブに変換してから処理するため、構造的に遅い。
// 変更前
plugins {
id("kotlin-kapt")
}
dependencies {
kapt("androidx.room:room-compiler:2.6.1")
}
// 変更後
plugins {
id("com.google.devtools.ksp") version "2.0.0-1.0.24"
}
dependencies {
ksp("androidx.room:room-compiler:2.6.1")
}
対応ライブラリであれば、置き換えるだけで効果が出やすい。移行手順は依存関係を差し替えるだけで完結することが多く、コストの割にリターンが大きい施策だ。
依存関係のバージョンは固定する
'com.google.dagger:hilt-android:2.+'のような動的バージョン指定は、Gradleが毎回更新チェックのために通信を行うため、ビルドが遅くなる原因になる。バージョンは必ず数値で固定してほしい。
implementation("com.google.dagger:hilt-android:2.52")
モジュール構成を見直す
巨大な単一モジュールのプロジェクトは、1行の変更でも全体の再コンパイルが走りやすい。機能単位でAndroidライブラリモジュールに分割しておくと、変更のあったモジュールだけが再ビルドされるようになる。
さらに、モジュールが分かれていればorg.gradle.parallel=trueの恩恵も受けやすくなる。分割の手間はかかるが、プロジェクトが大きくなるほど投資対効果は上がる施策だ。
リソース関連の最適化
開発用フレーバーでリソースを絞る
開発中のビルドで、対応言語や画面密度をすべて含める必要はない。dev用のプロダクトフレーバーを作り、リソースを限定するとビルド対象が減り、時間短縮につながる。
android {
productFlavors {
create("dev") {
resourceConfigurations += listOf("ja", "xxhdpi")
}
}
}
非推移的なRクラスを使う
モジュールをまたいだリソース参照が多いプロジェクトでは、android.nonTransitiveRClass=trueを有効にすることで、各モジュールが自分のリソースだけを参照するようになり、コンパイル対象が絞られる。Android Gradle Plugin 8.0以降ではデフォルトで有効になっているため、古いプロジェクトから移行した場合は設定を確認しておきたい。
使っていない仕組みを止める
Jetifierを無効にする
すでに依存関係がすべてAndroidX対応になっているなら、Jetifierは不要な変換処理を行っているだけになる。gradle.propertiesに以下を追加して無効化する。
android.enableJetifier=false
Build Analyzerで安全に外せるかどうかの警告も出るので、外す前に確認しておくと安心だ。
不要なプラグインリポジトリの順序を見直す
settings.gradle.ktsのリポジトリ宣言は、上から順番に検索される。gradlePluginPortal()を先頭に置いていると、大半のプラグインが見つかるgoogle()やmavenCentral()より先に無駄な検索が走ってしまう。gradlePluginPortal()は最後に置くのが基本だ。
pluginManagement {
repositories {
google()
mavenCentral()
gradlePluginPortal()
}
}
効果測定の進め方
設定を一気に変えると、何が効いたのか分からなくなる。以下の順で1つずつ試すのがおすすめだ。
- Build Analyzerでボトルネックを確認する
- JVMヒープサイズとGC設定を調整する
- kaptを使っている場合はKSPへ移行する
- 依存関係バージョンを固定する
- 構成キャッシュ・ビルドキャッシュを有効化する
それぞれの変更後に、同じコード変更を加えて増分ビルドの時間を比較すれば、効果の有無が数字で見える。
まとめ
Android Studioのビルド高速化は、派手な施策よりも 地道な構成の積み上げ がものを言う分野だ。
- まずは Build Analyzer でボトルネックを把握する
- JVMヒープ・並列ビルド・キャッシュ の3点は最初に見直す
- kaptからKSPへの移行 はコストの割に効果が大きい
一つひとつの効果は小さくても、積み重なれば体感速度は大きく変わる。
待ち時間にストレスを感じているなら、まずはgradle.propertiesを1行ずつ見直すところから始めてほしい。
コメント