DaggerからHiltへの移行による収益

Hiltは2020年6月に発表し、Androidに依存項目注入(DI)の標準化案を提供した.新しいプロジェクトでは、Hiltはコンパイル期間の検証、良好なランタイム性能、拡張性を備えています(記事AndroidとHiltでの役割ドメイン限定を参照して、詳細を参照).しかし、HiltはすでにDaggerを使用しているアプリケーションにどのような利点があるのだろうか.既存のアプリケーションをHiltに移行する必要がありますか?次の点では、チームが移行に力を入れる必要がある理由を説明します.
✅ Android X拡張対応
Daggerを使用してViewModelまたはWorkManagerを処理している場合は、独自のViewModelFactoryとWorkerFactoryを注入するには、テンプレートコードが大量に必要であり、Daggerに関する知識が必要であることがわかります.最も一般的な実装はマルチバインディングを使用することであり、これはDaggerの中で最も複雑な機能の一つであり、開発者は理解しにくいことが多い.Hiltはテンプレートコードを削除することでAndroid Xの使用を大幅に簡素化した.さらに素晴らしいことに、Android FrameworkのクラスにFactoryを注入する必要もなく、Hiltを使用していないようです.@HiltViewModelを使用すると、Hiltは正しいViewModelProvider.Factoryを作成します.そのため、@AndroidEntryPointに注釈されたActivityとFragmentは直接使用できます.

@HiltViewModel
class PlayViewModel @Inject constructor(
  val db: MusicDatabase,
) : ViewModel() { ... }

@AndroidEntryPoint
class PlayActivity : AppCompatActivity() {

  val viewModel: PlayViewModel by viewModels()
  
  override fun onCreate(savedInstanceState: Bundle) {
    super.onCreate(bundle)
    viewModel.play()
  }
}

✅ テストAPIのサポート
DI(依存注入)はテストをより容易にするはずだったが,皮肉なことにDaggerを用いたテストには大量の仕事が必要であった.実際には、公式とテストのDagger関係図を同時に維持する必要がありますが、Hiltの実現方式はより便利です.
Hilt試験は、@UninstallModules機能を使用してDI関係図を明示的に修正することができる.これに加えて、@BindValueのような他の機能も提供され、テストフィールドをDI関係図に簡単にバインドすることができる.

@UninstallModules(AnalyticsModule::class)
@HiltAndroidTest
class ExampleTest {

  @get:Rule
  var hiltRule = HiltAndroidRule(this)
  
  @BindValue @JvmField
  val analyticsRepository = FakeAnalyticsRepository()
  
  @Test 
  fun myTest() { ... }
}

✅ 良好な整合性
Daggerでは同じ機能を実現する方法がたくさんあります.Androidアプリケーションのマニュアルドキュメントが初期に不足していたため(昨年、マニュアル記事:Daggerの基礎知識などの問題を解決しました)、コミュニティで多くの議論が起こり、最終的には異なる開発者がAndroidアプリケーションでDaggerを使用し、構成する方法が一致しませんでした.
現在のDagger構成が非常に完備しており、Daggerの動作原理とすべての依存項目がどのように注入されているかを完全に把握しているため、Hiltへの移行は価値がないという異議があるかもしれません.これは個人的には正しいかもしれませんが、潜在的な将来の同僚を含むチームの他のメンバーを考慮したことがありますか?新しいプロジェクトに切り替えても正常に動作しますか?Daggerのアプリケーションでの構成と使用を理解することは、困難で時間のかかる作業です.
アプリケーションでHiltを使用すると、すべてのHiltアプリケーションが同じ構成を使用しているため、上記の作業量は著しく減少します.新しくチームに参加した開発者は、Hiltの構成に困惑することはありません.これは、以前の構成とほぼ同じです.
✅ カスタムコンポーネントのサポート
定義された標準コンポーネントに加えて、Hiltは、文書Hilt-階層へのコンポーネントの追加を参照して、カスタムコンポーネントを作成してコンポーネント階層に追加する方法も提供する.
カスタムコンポーネントは一貫性を低下させますが、これは大きな収益をもたらします.カスタムコンポーネントは、モジュール自動検出機能(@InstallIn注記機能)およびテスト置換機能と組み合わせて使用することもできます.
しかし、カスタムコンポーネントとHilt内蔵コンポーネントの違いは、Android Frameworkのクラス(@AndroidEntryPointの機能)に自動的に注入できないことです.
✅ DaggerとHiltのインタラクションをサポート
HiltとDaggerが共存できる!Hilt継ぎ手SingletonComponentが許可される場合、Hiltの特性はアプリケーションの一部で使用され、そこから利益を得ることができ、他の特別な部分はDaggerを保持する.これは同様にHiltへの移行を段階的に完了が可能であることを意味する.
❌ コンポーネント依存はサポートされていません
Hiltの使いやすさは、あなたの代わりにいくつかの決定を下したことを意味します.Hiltはコンポーネント関係にサブコンポーネントモードを採用しており、関連ドキュメントを参照して設計の理由を理解できます.アプリケーションがコンポーネント依存性を採用するのに適していると信じている場合は、Hiltはアプリケーションの正しい選択ではありません.
ほとんどのプロジェクトでは、HiltをDaggerに移行する価値があります.Hiltがもたらす収益は、更新に必要な努力を超えています.移行を支援する多くのリソースが用意されています.関連項目:

詳細なドキュメントの移行

Codelab|DaggerからHiltへの移行

Google I/OアプリケーションはHiltのブログとコードコミットレコード

に移行する.

HiltとAssistedInjectの連携のポイント

何か問題があったり、もっと関連情報が必要な場合は、文章の下にフィードバックを残してください.