ライブラリがAndroidアプリで使用されているかどうかを確認します
_build.gradle_で、ほぼ20以上の依存関係を持つ、アプリのレガシーコード（私が開発したものではなく、他のチームが開発したもの）を受け取りました。
ここで、未使用のライブラリー/依存関係を_build.gradle_から削除して、それらをクリーンアップしたいと思いました。
私はグーグルで検索し、これに出くわしました プロジェクト リソース縮小のために。ただし、パッケージ化されたアプリでビルド時に未使用のリソースを削除するために使用されているようで、これにより、リソースがアプリケーションで実際に必要でない場合に依存しているライブラリからリソースも削除されます。
また、_shrinkResources true_の_build.gradle_と組み合わせて、難読化と圧縮のためにProGuardを使用します
私の意図は、アプリの機能を損なうことなく、build.gradle自体から未使用のライブラリー/依存関係を削除することです。
アプリの機能を損なうことなく、どのライブラリが安全に削除できるかを示す方法またはツールはありますか？
20以上の依存関係により、ツールは必要なく、手動でチェックできます。
私はこのように進みます：
- すべての依存関係をコメント化し、何が失敗するかを確認します（以下を参照）
- 失敗の原因となる依存関係のコメントを外します
- 繰り返す
この方法では、めったに使用されない依存関係や、プロジェクトで使用する標準ライブラリや他のライブラリに置き換えることができる依存関係に気付く場合もあります。
以下は、依存関係が必要であることを示すものです（フィードバックループを遅くする順序で）。
- コンパイルエラー
- 単体テストのエラー
- 統合/システム/エンドツーエンド/デバイステストエラー（使用して呼び出すものは何でも）
- 実行時のアプリケーション機能
- 実行時のアプリケーションパフォーマンス
ランタイムの依存関係は特に注意が必要です。たとえば、コードはライブラリに依存しない場合がありますが、このライブラリは、依存する他のライブラリのランタイム実装を提供します。このような依存関係の削除は、実行時にのみ機能またはパフォーマンスの問題が欠落しているように見えます。
すべての依存関係をコメントアウトする代わりに、私は逆に行きます-一度に1つの依存関係をコメントアウトし、何が壊れるかを確認します。 IDEはコードが壊れた場所を示しているので、この方法ですべての依存関係のユースケースを把握することもできます。依存関係をコメントアウトしても何も壊れない場合は、可能性のあるもう1つのことは、難読化されていないリリースの.apkを分析することです。この場合、未使用の依存関係はすべて失われますが、パッケージ構造は保持されます。