mcpField
A
android-gradle-build-performance

android-gradle-build-performance

github.com/krutikjain開発1468 回インストール31 週間前に更新
リポジトリ

android-gradle-build-performance について

Android と Gradle のビルド性能を診断、改善するスキルです。開発者がボトルネックを切り分け、スキャンやキャッシュ確認で測定し、対象を絞った変更を広く適用する前に検証できるよう支援します。

主な機能

  1. 01ビルド性能の各段階の切り分け
  2. 02プロファイルとスキャンによる測定
  3. 03キャッシュと設定の監査
  4. 04プラグインと依存関係の確認
  5. 05対象を絞った最適化の検証

活用シーン

  1. 01ローカルビルドの遅さの診断
  2. 02CI ビルド時間の短縮
  3. 03キャッシュミスの調査
  4. 04KSP と kapt の処理負荷の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/krutikjain/android-agent-skills --skill android-gradle-build-performance

インストール後、Claude Code で/android-gradle-build-performanceを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
official-links.md
patterns.md
scenarios.md
scripts/
audit_build_performance.py
run_examples.sh

詳細

Android Gradle ビルドのパフォーマンス

使用する場面

  • 次の内容に関するリクエストでこのスキルを使用します:Android Gradle ビルドのパフォーマンス、Android ビルドの構成キャッシュ、Android における KSP と kapt の比較。
  • 主な目的:スキャン、キャッシュの確認、ボトルネックの監査を通じて、Android と Gradle のビルドパフォーマンスを診断し、改善します。
  • 問題がビルド速度、タスクの頻繁な再実行、キャッシュミス、CI の所要時間に関するもので、ビルドロジックの構造に関するものでない場合にこのスキルを使用します。
  • 測定手順や、Gradle でよく見られるパフォーマンス上の問題が必要な場合は、references/patterns.md を読みます。
  • サンプルプロジェクトを使って監査から始める場合は、references/scenarios.md を読みます。
  • 対象範囲が広がった場合は、次のスキルに引き継ぎます:
  • android-gradle-build-logic
  • android-ci-cd-release-playstore

ワークフロー

  1. 問題がローカルでの開発者のフィードバック時間、CI のビルド時間、またはその両方のどれに関するものかを特定します。
  2. 修正を提案する前に、--profile、--scan、構成キャッシュの診断機能、または付属の監査スクリプトを使って、一度に 1 つのビルド経路を測定します。
  3. gradle.properties、プラグインの適用方法、依存関係の宣言、タスク登録の方法、モジュールの規約を確認し、よくあるパフォーマンス上の問題がないか調べます。
  4. 確度の高い最適化を一度に 1 つ適用し、変更を積み重ねるのではなく、適用前後の動作を比較します。
  5. パフォーマンスのボトルネックを特定したら、構造的な Gradle のリファクタリングやリリースパイプラインの変更を引き継ぎます。

ガードレール

  • 単一のキャッシュ、プラグイン、依存関係のパターンが実際のボトルネックである場合に、大規模な書き換えを提案しないでください。
  • 測定結果と推測を分け、観測された内容と推論した内容を明示してください。
  • ツールチェーンが対応している場合は、KSP、構成キャッシュ、遅延タスク構成を優先してください。
  • 動的な依存関係のバージョン、変更されるモジュール、先行して作成されるタスクは、意図的な理由がない限り、パフォーマンスの低下として扱ってください。
  • 組織全体への展開を提案する前に、サンプルプロジェクトで再現可能な CI の手順を維持してください。

アンチパターン

  • 互換性や失敗を確認せずに、Gradle のフラグをすべて有効にする。
  • タスクのホットスポットを測定せずに、ビルドが遅い原因を AGP のアップグレードのせいにする。
  • 1 回の診断で、ビルドロジックのアーキテクチャに関する助言とビルド時間の診断を混在させる。
  • 依存関係の解決処理を何度も発生させる動的な依存関係のバージョンを使用する。

レビューの重点

  • 構成時間と実行時間、依存関係の解決時間、テストの所要時間。
  • 構成キャッシュとの互換性と遅延タスク登録。
  • KSP と kapt の比較、アノテーションプロセッサのホットスポット。
  • リモート/ローカルキャッシュの効果、動的な依存関係、CI 固有のボトルネック。

例

基本的なケース
  • シナリオ:Compose のフィクスチャを監査し、ビルドキャッシュ、構成キャッシュ、KSP、先行タスク作成に関する問題を確認します。
  • コマンド:python3 skills/android-gradle-build-performance/scripts/audit_build_performance.py examples/orbittasks-compose --json
例外的なケース
  • シナリオ:CI ビルドの最適化を選ぶ前に、XML と Compose のフィクスチャのビルド設定を比較します。
  • コマンド:bash skills/android-gradle-build-performance/scripts/run_examples.sh
失敗からの復旧
  • シナリオ:パフォーマンスフラグを有効にした後、展開前にプロジェクトを再確認して、性能低下を検出します。
  • コマンド:python3 skills/android-gradle-build-performance/scripts/audit_build_performance.py examples/orbittasks-xml

完了チェックリスト

  • ボトルネックが、特定のフェーズ、フラグ、プラグイン、または依存関係のパターンに関連付けられています。
  • 提案する最適化は測定可能で、元に戻せます。
  • 推奨する修正は、現在の Android と Gradle のツールチェーンに対応しています。
  • 構造的な Gradle の作業は、パフォーマンス調整とは分けて引き継がれています。

Official References

コメント