Abhängigkeitsinjektion mit Hilt

Hilt ist eine Bibliothek für die Abhängigkeitsinjektion für Android, die den Boilerplate-Code für die manuelle Abhängigkeitsinjektion in Ihrem Projekt reduziert. Bei der manuellen Abhängigkeitsinjektion müssen Sie jede Klasse und ihre Abhängigkeiten manuell erstellen und Container verwenden, um Abhängigkeiten wiederzuverwenden und zu verwalten.

Hilt bietet eine Standardmethode für die Verwendung von DI in Ihrer Anwendung. Dazu werden Container für jede Android-Klasse in Ihrem Projekt bereitgestellt und deren Lebenszyklen automatisch verwaltet. Hilt basiert auf der beliebten DI-Bibliothek Dagger, um von der Korrektheit zur Kompilierzeit, der Laufzeitleistung, der Skalierbarkeit und der Android Studio-Unterstützung zu profitieren, die Dagger bietet. Weitere Informationen finden Sie unter Hilt und Dagger.

In diesem Leitfaden werden die grundlegenden Konzepte von Hilt und den generierten Containern erläutert. Außerdem wird gezeigt, wie Sie eine vorhandene App für die Verwendung von Hilt bootstrappen.

Abhängigkeiten hinzufügen

Fügen Sie zuerst das hilt-android-gradle-plugin-Plug-in in die build.gradle-Datei im Stammverzeichnis Ihres Projekts ein:

Kotlin

plugins {
  ...
  id("com.google.dagger.hilt.android") version "2.57.1" apply false
}

Groovy

plugins {
  ...
  id 'com.google.dagger.hilt.android' version '2.57.1' apply false
}

Wenden Sie dann das Gradle-Plug-in an und fügen Sie der Datei app/build.gradle die folgenden Abhängigkeiten hinzu:

Kotlin

plugins {
  id("com.google.devtools.ksp")
  id("com.google.dagger.hilt.android")
}

android {
  ...
}

dependencies {
  implementation("com.google.dagger:hilt-android:2.57.1")
  ksp("com.google.dagger:hilt-android-compiler:2.57.1")
}

Groovy

...
plugins {
  id 'com.google.devtools.ksp'
  id 'com.google.dagger.hilt.android'
}

android {
  ...
}

dependencies {
  implementation "com.google.dagger:hilt-android:2.57.1"
  ksp "com.google.dagger:hilt-compiler:2.57.1"
}

Damit Ihr Projekt für Java 17 konfiguriert ist, was für Jetpack Compose- und Hilt-Versionen erforderlich ist, fügen Sie der Datei app/build.gradle Folgendes hinzu:

Kotlin

android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
  }
}

Groovy

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_17
    targetCompatibility JavaVersion.VERSION_17
  }
}

Hilt-Anwendungsklasse

Alle Apps, die Hilt verwenden, müssen eine Application-Klasse enthalten, die mit @HiltAndroidApp annotiert ist.

@HiltAndroidApp löst die Codegenerierung von Hilt aus, einschließlich einer Basisklasse für Ihre Anwendung, die als Abhängigkeitscontainer auf Anwendungsebene dient.

@HiltAndroidApp
class ExampleApplication : Application() { ... }

Diese generierte Hilt-Komponente ist an den Lebenszyklus des Application-Objekts angehängt und stellt Abhängigkeiten dafür bereit. Außerdem ist sie die übergeordnete Komponente der App. Das bedeutet, dass andere Komponenten auf die von ihr bereitgestellten Abhängigkeiten zugreifen können.

Abhängigkeiten in Android-Klassen einfügen

Sobald Hilt in Ihrer Application-Klasse eingerichtet ist und eine Komponente auf Anwendungsebene verfügbar ist, kann Hilt Abhängigkeiten für andere Android-Klassen bereitstellen, die die Annotation @AndroidEntryPoint haben:

@AndroidEntryPoint
class ExampleActivity : ComponentActivity() { ... }

Hilt unterstützt derzeit die folgenden Android-Klassen:

• Application (mit @HiltAndroidApp)
• ViewModel (mit @HiltViewModel)
• Activity
• Service
• BroadcastReceiver

In Compose müssen Sie einzelne Composables nicht annotieren. Annotieren Sie stattdessen das Stamm-ComponentActivity mit @AndroidEntryPoint. Dies dient als einziger DI-Einstiegspunkt für Ihre gesamte UI-Hierarchie, sodass Sie direkt in Ihren zusammensetzbaren Funktionen auf von Hilt eingefügte ViewModels zugreifen können.

Hinweis: Hilt unterstützt nur Aktivitäten, die ComponentActivity erweitern, z. B. AppCompatActivity.

@AndroidEntryPoint generiert für jede Android-Klasse in Ihrem Projekt eine eigene Hilt-Komponente. Diese Komponenten können Abhängigkeiten von ihren jeweiligen übergeordneten Klassen erhalten, wie unter Komponentenhierarchie beschrieben.

Wenn Sie Abhängigkeiten von einer Komponente abrufen möchten, verwenden Sie die Annotation @Inject, um eine Field Injection durchzuführen:

@AndroidEntryPoint
class ExampleActivity : ComponentActivity() {

  @Inject lateinit var analytics: AnalyticsAdapter
  ...
}

Hinweis: Von Hilt eingefügte Felder können nicht privat sein. Der Versuch, ein privates Feld mit Hilt einzufügen, führt zu einem Kompilierungsfehler.

Klassen, die von Hilt eingefügt werden, können andere Basisklassen haben, die ebenfalls die Einfügung verwenden. Diese Klassen benötigen die Annotation @AndroidEntryPoint nicht, wenn sie abstrakt sind.

Weitere Informationen dazu, in welchen Lebenszyklus-Callback eine Android-Klasse eingefügt wird, finden Sie unter Lebensdauer von Komponenten.

Hilt-Bindungen definieren

Für die Field Injection muss Hilt wissen, wie Instanzen der erforderlichen Abhängigkeiten aus der entsprechenden Komponente bereitgestellt werden. Eine Bindung enthält die Informationen, die erforderlich sind, um Instanzen eines Typs als Abhängigkeit bereitzustellen.

Eine Möglichkeit, Hilt Bindungsinformationen bereitzustellen, ist die Constructor Injection. Verwenden Sie die Annotation @Inject für den Konstruktor einer Klasse, um Hilt mitzuteilen, wie Instanzen dieser Klasse bereitgestellt werden sollen:

class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

Die Parameter eines annotierten Konstruktors einer Klasse sind die Abhängigkeiten dieser Klasse. Im Beispiel hat AnalyticsAdapter die Abhängigkeit AnalyticsService. Daher muss Hilt auch wissen, wie Instanzen von AnalyticsService bereitgestellt werden.

Hinweis: Beim Erstellen generiert Hilt Dagger-Komponenten für Android-Klassen. Anschließend geht Dagger Ihren Code durch und führt die folgenden Schritte aus:

• Erstellt und validiert Abhängigkeitsdiagramme, um sicherzustellen, dass keine unerfüllten Abhängigkeiten und keine Abhängigkeitszyklen vorhanden sind.
• Generiert die Klassen, die zur Laufzeit verwendet werden, um die tatsächlichen Objekte und ihre Abhängigkeiten zu erstellen.

Hilt-Module

Manchmal kann ein Typ nicht per Constructor Injection eingefügt werden. Dies kann mehrere Gründe haben. Beispielsweise können Sie keine Schnittstelle per Constructor Injection einfügen. Außerdem können Sie keinen Typ per Constructor Injection einfügen, der Ihnen nicht gehört, z. B. eine Klasse aus einer externen Bibliothek. In diesen Fällen können Sie Hilt mithilfe von Hilt-Modulen Bindungsinformationen zur Verfügung stellen.

Ein Hilt-Modul ist eine Klasse, die mit @Module annotiert ist. Sie enthält Anweisungen für Hilt, wie Instanzen von Typen erstellt werden, die nicht über Constructor Injection bereitgestellt werden können, z. B. Schnittstellen oder Klassen von Drittanbietern. Außerdem müssen Sie jedes Modul mit @InstallIn annotieren, um Hilt mitzuteilen, in welcher Android-Klasse das jeweilige Modul verwendet oder installiert wird.

Hinweis: Hilt-Module unterscheiden sich von Gradle-Modulen.

Abhängigkeiten, die Sie in Hilt-Modulen angeben, sind in allen generierten Komponenten verfügbar, die mit der Android-Klasse verknüpft sind, in der Sie das Hilt-Modul installieren.

Hinweis: Da die Codegenerierung von Hilt Zugriff auf alle Gradle-Module benötigt, die Hilt verwenden, muss das Gradle-Modul, das Ihre Application-Klasse kompiliert, auch alle Ihre Hilt-Module und per Constructor Injection eingefügten Klassen in seinen transitiven Abhängigkeiten enthalten.

Schnittstelleninstanzen mit @Binds einfügen

Betrachten Sie das Beispiel AnalyticsService. Wenn AnalyticsService eine Schnittstelle ist, können Sie sie nicht per Constructor Injection einfügen. Stattdessen stellen Sie Hilt die Bindungsinformationen zur Verfügung, indem Sie eine abstrakte Funktion mit der Annotation @Binds in einem Hilt-Modul erstellen.

Die Annotation @Binds teilt Hilt mit, welche Implementierung verwendet werden soll, wenn eine Instanz einer Schnittstelle bereitgestellt werden muss.

Die annotierte Funktion stellt Hilt die folgenden Informationen zur Verfügung:

• Der Rückgabetyp der Funktion gibt Hilt an, für welche Schnittstelle die Funktion Instanzen bereitstellt.
• Der Funktionsparameter teilt Hilt mit, welche Implementierung bereitgestellt werden soll.

interface AnalyticsService {
  fun analyticsMethods()
}

// Constructor-injected, because Hilt needs to know how to
// provide instances of AnalyticsServiceImpl, too.
class AnalyticsServiceImpl @Inject constructor(
  ...
) : AnalyticsService { ... }

@Module
@InstallIn(ActivityComponent::class)
abstract class AnalyticsModule {

  @Binds
  abstract fun bindAnalyticsService(
    analyticsServiceImpl: AnalyticsServiceImpl
  ): AnalyticsService
}

Das Hilt-Modul AnalyticsModule ist mit @InstallIn(ActivityComponent.class) annotiert, da Sie möchten, dass Hilt diese Abhängigkeit in ExampleActivity einfügt. Diese Annotation bedeutet, dass alle Abhängigkeiten in AnalyticsModule in allen Aktivitäten der App verfügbar sind.

Instanzen mit @Provides einfügen

Schnittstellen sind nicht der einzige Fall, in dem Sie einen Typ nicht per Constructor Injection einfügen können. Constructor Injection ist auch nicht möglich, wenn Sie nicht der Inhaber der Klasse sind, weil sie aus einer externen Bibliothek stammt (Klassen wie Retrofit, OkHttpClient oder Room-Datenbanken), oder wenn Instanzen mit dem Builder-Muster erstellt werden müssen.

Betrachten Sie das vorherige Beispiel. Wenn Sie nicht der direkte Inhaber der Klasse AnalyticsService sind, können Sie Hilt mitteilen, wie Instanzen dieses Typs bereitgestellt werden sollen. Erstellen Sie dazu eine Funktion in einem Hilt-Modul und annotieren Sie diese Funktion mit @Provides.

Die annotierte Funktion liefert die folgenden Informationen an Hilt:

• Der Rückgabetyp der Funktion gibt Hilt an, von welchem Typ die Funktion Instanzen bereitstellt.
• Die Funktionsparameter teilen Hilt die Abhängigkeiten des entsprechenden Typs mit.
• Der Funktionsrumpf teilt Hilt mit, wie eine Instanz des entsprechenden Typs bereitgestellt wird. Hilt führt den Funktionskörper jedes Mal aus, wenn eine Instanz dieses Typs bereitgestellt werden muss.

@Module
@InstallIn(ActivityComponent::class)
object AnalyticsModule {

  @Provides
  fun provideAnalyticsService(
    // Potential dependencies of this type
  ): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .build()
               .create(AnalyticsService::class.java)
  }
}

Mehrere Bindungen für denselben Typ bereitstellen

Wenn Hilt verschiedene Implementierungen desselben Typs als Abhängigkeiten bereitstellen soll, müssen Sie Hilt mehrere Bindungen zur Verfügung stellen. Sie können mehrere Bindungen für denselben Typ mit Qualifizierern definieren.

Ein Qualifier ist eine Annotation, mit der Sie eine bestimmte Bindung für einen Typ identifizieren, wenn für diesen Typ mehrere Bindungen definiert sind.

Betrachten Sie das Beispiel. Wenn Sie Aufrufe an AnalyticsService abfangen müssen, können Sie ein OkHttpClient-Objekt mit einem Interceptor verwenden. Bei anderen Diensten müssen Sie Aufrufe möglicherweise auf andere Weise abfangen. In diesem Fall müssen Sie Hilt mitteilen, wie zwei verschiedene Implementierungen von OkHttpClient bereitgestellt werden sollen.

Definieren Sie zuerst die Qualifier, die Sie zum Annotieren der Methoden @Binds oder @Provides verwenden:

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class AuthInterceptorOkHttpClient

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class OtherInterceptorOkHttpClient

Anschließend muss Hilt wissen, wie eine Instanz des Typs bereitgestellt wird, der dem jeweiligen Qualifier entspricht. In diesem Fall können Sie ein Hilt-Modul mit @Provides verwenden. Beide Methoden haben denselben Rückgabetyp, aber die Qualifier kennzeichnen sie als zwei verschiedene Bindungen:

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

  @AuthInterceptorOkHttpClient
  @Provides
  fun provideAuthInterceptorOkHttpClient(
    authInterceptor: AuthInterceptor
  ): OkHttpClient {
      return OkHttpClient.Builder()
               .addInterceptor(authInterceptor)
               .build()
  }

  @OtherInterceptorOkHttpClient
  @Provides
  fun provideOtherInterceptorOkHttpClient(
    otherInterceptor: OtherInterceptor
  ): OkHttpClient {
      return OkHttpClient.Builder()
               .addInterceptor(otherInterceptor)
               .build()
  }
}

Sie können den gewünschten Typ einfügen, indem Sie das Feld oder den Parameter mit dem entsprechenden Qualifier annotieren:

// As a dependency of another class.
@Module
@InstallIn(ActivityComponent::class)
object AnalyticsModule {

  @Provides
  fun provideAnalyticsService(
    @AuthInterceptorOkHttpClient okHttpClient: OkHttpClient
  ): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .client(okHttpClient)
               .build()
               .create(AnalyticsService::class.java)
  }
}

// As a dependency of a constructor-injected class.
class ExampleServiceImpl @Inject constructor(
  @AuthInterceptorOkHttpClient private val okHttpClient: OkHttpClient
) : ...

// At field injection.
@AndroidEntryPoint
class ExampleActivity: ComponentActivity() {

  @AuthInterceptorOkHttpClient
  @Inject lateinit var okHttpClient: OkHttpClient
}

Als Best Practice gilt: Wenn Sie einem Typ einen Qualifier hinzufügen, fügen Sie allen möglichen Möglichkeiten, diese Abhängigkeit bereitzustellen, Qualifier hinzu. Wenn Sie die Basis- oder allgemeine Implementierung ohne Qualifier belassen, ist das fehleranfällig und kann dazu führen, dass Hilt die falsche Abhängigkeit einfügt.

Vordefinierte Qualifizierer in Hilt

Hilt bietet einige vordefinierte Qualifier. Wenn Sie beispielsweise die Klasse Context entweder aus der Anwendung oder der Aktivität benötigen, stellt Hilt die Qualifier @ApplicationContext und @ActivityContext bereit.

Angenommen, die Klasse AnalyticsAdapter aus dem Beispiel benötigt den Kontext der Aktivität. Der folgende Code zeigt, wie der Aktivitätskontext für AnalyticsAdapter bereitgestellt wird:

class AnalyticsAdapter @Inject constructor(
    @ActivityContext private val context: Context,
    private val service: AnalyticsService
) { ... }

Weitere vordefinierte Bindungen, die in Hilt verfügbar sind, finden Sie unter Standardbindungen für Komponenten.

Generierte Komponenten für Android-Klassen

Für jede Android-Klasse, in der Sie eine Field Injection ausführen können, gibt es eine zugehörige Hilt-Komponente, auf die Sie in der Annotation @InstallIn verweisen können. Jede Hilt-Komponente ist dafür verantwortlich, ihre Bindungen in die entsprechende Android-Klasse einzufügen.

In den vorherigen Beispielen wurde die Verwendung von ActivityComponent in Hilt-Modulen gezeigt.

Hilt bietet die folgenden Komponenten:

Hilt-Komponente	Injektor für
SingletonComponent	Application
ActivityRetainedComponent	–
ViewModelComponent	ViewModel
ActivityComponent	Activity
ServiceComponent	Service

Hinweis: Hilt generiert keine Komponente für Übertragungsempfänger, da Hilt Übertragungsempfänger direkt aus SingletonComponent einfügt.

Lebensdauer von Komponenten

Hilt erstellt und löscht automatisch Instanzen generierter Komponentenklassen, die dem Lebenszyklus der entsprechenden Android-Klassen folgen.

Generierte Komponente	Erstellt am	Gelöscht am
SingletonComponent	Application#onCreate()	Application zerstört
ActivityRetainedComponent	Activity#onCreate()	Activity#onDestroy()
ViewModelComponent	ViewModel erstellt	ViewModel zerstört
ActivityComponent	Activity#onCreate()	Activity#onDestroy()
ServiceComponent	Service#onCreate()	Service#onDestroy()

Hinweis: ActivityRetainedComponent bleibt über Konfigurationsänderungen hinweg bestehen. Es wird also beim ersten Activity#onCreate() erstellt und beim letzten Activity#onDestroy() gelöscht.

Komponentenbereiche

Standardmäßig sind alle Bindungen in Hilt unscoped. Das bedeutet, dass Hilt jedes Mal, wenn Ihre App die Bindung anfordert, eine neue Instanz des erforderlichen Typs erstellt.

Im Beispiel stellt Hilt jedes Mal, wenn AnalyticsAdapter als Abhängigkeit für einen anderen Typ oder über Field Injection (wie in ExampleActivity) bereitgestellt wird, eine neue Instanz von AnalyticsAdapter bereit.

Hilt ermöglicht es aber auch, eine Bindung auf eine bestimmte Komponente zu beschränken. Hilt erstellt eine Bindung mit Bereich nur einmal pro Instanz der Komponente, auf die sich die Bindung bezieht. Alle Anfragen für diese Bindung verwenden dieselbe Instanz.

In der folgenden Tabelle sind die Bereichsannotationen für jede generierte Komponente aufgeführt:

Android-Klasse	Generierte Komponente	Umfang
Application	SingletonComponent	@Singleton
Activity	ActivityRetainedComponent	@ActivityRetainedScoped
ViewModel	ViewModelComponent	@ViewModelScoped
Activity	ActivityComponent	@ActivityScoped
Service	ServiceComponent	@ServiceScoped

Wenn Sie im Beispiel AnalyticsAdapter mit @ActivityScoped auf ActivityComponent beschränken, stellt Hilt während der gesamten Lebensdauer der entsprechenden Aktivität dieselbe Instanz von AnalyticsAdapter bereit:

@ActivityScoped
class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

Hinweis: Das Festlegen des Bereichs einer Bindung auf eine Komponente kann kostspielig sein, da das bereitgestellte Objekt im Speicher bleibt, bis diese Komponente gelöscht wird. Minimieren Sie die Verwendung von bereichsbezogenen Bindungen in Ihrer Anwendung. Es ist sinnvoll, Bindungen mit Komponentenbereich für Bindungen mit einem internen Zustand zu verwenden, der erfordert, dass dieselbe Instanz innerhalb eines bestimmten Bereichs verwendet wird, für Bindungen, die synchronisiert werden müssen, oder für Bindungen, die nach Ihren Messungen teuer zu erstellen sind.

Angenommen, AnalyticsService hat einen internen Status, der erfordert, dass jedes Mal dieselbe Instanz verwendet wird – nicht nur in ExampleActivity, sondern überall in der App. In diesem Fall ist es sinnvoll, den Bereich von AnalyticsService auf SingletonComponent festzulegen. Das Ergebnis ist, dass die Komponente immer dieselbe Instanz von bereitstellt, wenn sie eine Instanz von AnalyticsService bereitstellen muss.

Das folgende Beispiel zeigt, wie Sie eine Bindung auf eine Komponente in einem Hilt-Modul beschränken. Der Bereich einer Bindung muss mit dem Bereich der Komponente übereinstimmen, in der sie installiert ist. In diesem Beispiel müssen Sie AnalyticsService in SingletonComponent anstelle von ActivityComponent installieren:

// If AnalyticsService is an interface.
@Module
@InstallIn(SingletonComponent::class)
abstract class AnalyticsModule {

  @Singleton
  @Binds
  abstract fun bindAnalyticsService(
    analyticsServiceImpl: AnalyticsServiceImpl
  ): AnalyticsService
}

// If you don't own AnalyticsService.
@Module
@InstallIn(SingletonComponent::class)
object AnalyticsModule {

  @Singleton
  @Provides
  fun provideAnalyticsService(): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .build()
               .create(AnalyticsService::class.java)
  }
}

Weitere Informationen zu Hilt-Komponentenbereichen finden Sie unter Scoping in Android und Hilt.

Hinweis: Weitere Informationen zu den Unterschieden zwischen der Bereichsdefinition mit @ActivityRetainedScoped und @ViewModelScoped finden Sie im Abschnitt @ViewModelScoped im Dokument zu Hilt- und Jetpack-Integrationen.

Komponentenhierarchie

Wenn Sie ein Modul in einer Komponente installieren, können Sie auf seine Bindungen als Abhängigkeit von anderen Bindungen in dieser Komponente oder in einer untergeordneten Komponente in der Komponentenhierarchie zugreifen.

Abbildung 1. Hierarchie der von Hilt generierten Komponenten.

Standardbindungen für Komponenten

Jede Hilt-Komponente enthält eine Reihe von Standardbindungen, die Hilt als Abhängigkeiten in Ihre eigenen benutzerdefinierten Bindungen einfügen kann. Diese Bindungen entsprechen dem allgemeinen Aktivitätstyp und keiner bestimmten Unterklasse. Das liegt daran, dass Hilt eine einzelne Aktivitätskomponentendefinition verwendet, um alle Aktivitäten einzufügen. Jede Aktivität hat eine andere Instanz dieser Komponente.

Android-Komponente	Standardbindungen
SingletonComponent	Application
ActivityRetainedComponent	Application
ViewModelComponent	SavedStateHandle
ActivityComponent	Application, Activity
ServiceComponent	Application, Service

Die Bindung des Anwendungskontexts ist auch über @ApplicationContext verfügbar. Beispiel:

class AnalyticsServiceImpl @Inject constructor(
  @ApplicationContext context: Context
) : AnalyticsService { ... }

// The Application binding is available without qualifiers.
class AnalyticsServiceImpl @Inject constructor(
  application: Application
) : AnalyticsService { ... }

Die Aktivitätskontextbindung ist auch über @ActivityContext verfügbar. Beispiel:

class AnalyticsAdapter @Inject constructor(
  @ActivityContext context: Context
) { ... }

// The Activity binding is available without qualifiers.
class AnalyticsAdapter @Inject constructor(
  activity: ComponentActivity
) { ... }

Abhängigkeiten in Klassen einfügen, die von Hilt nicht unterstützt werden

In Compose ist es üblich, Abhängigkeiten per Constructor Injection in ein @HiltViewModel einzufügen und dann in der zusammensetzbaren Funktion hiltViewModel() zu verwenden, um auf das ViewModel zuzugreifen. Hilt unterstützt zwar die gängigsten Android-Klassen, aber es kann vorkommen, dass Sie auf nicht unterstützte Klassen stoßen, für die Sie eine Field Injection durchführen müssen.

In diesen Fällen können Sie einen Einstiegspunkt mit der Annotation @EntryPoint erstellen. Ein Einstiegspunkt ist die Grenze zwischen Code, der von Hilt verwaltet wird, und Code, der nicht von Hilt verwaltet wird. An diesem Punkt wird der Code zum ersten Mal in das Objektdiagramm eingefügt, das von Hilt verwaltet wird. Einstiegspunkte ermöglichen es Hilt, Code zu verwenden, der nicht von Hilt verwaltet wird, um Abhängigkeiten innerhalb des Abhängigkeitsgraphen bereitzustellen.

Hilt unterstützt beispielsweise keine Contentanbieter direkt. Wenn ein Contentanbieter Hilt verwenden soll, um einige Abhängigkeiten abzurufen, müssen Sie für jeden gewünschten Bindungstyp eine Schnittstelle definieren, die mit @EntryPoint annotiert ist, und Qualifier einfügen. Fügen Sie dann @InstallIn hinzu, um die Komponente anzugeben, in der der Einstiegspunkt installiert werden soll:

class ExampleContentProvider : ContentProvider() {

  @EntryPoint
  @InstallIn(SingletonComponent::class)
  interface ExampleContentProviderEntryPoint {
    fun analyticsService(): AnalyticsService
  }

  ...
}

Verwenden Sie die entsprechende statische Methode aus EntryPointAccessors, um auf einen Einstiegspunkt zuzugreifen. Der Parameter sollte entweder die Komponenteninstanz oder das @AndroidEntryPoint-Objekt sein, das als Komponentenhalter fungiert. Achten Sie darauf, dass die Komponente, die Sie als Parameter übergeben, und die statische Methode EntryPointAccessors mit der Android-Klasse in der Annotation @InstallIn auf der Schnittstelle @EntryPoint übereinstimmen:

class ExampleContentProvider: ContentProvider() {
    ...

  override fun query(...): Cursor {
    val appContext = context?.applicationContext ?: throw IllegalStateException()
    val hiltEntryPoint =
      EntryPointAccessors.fromApplication(appContext, ExampleContentProviderEntryPoint::class.java)

    val analyticsService = hiltEntryPoint.analyticsService()
    ...
  }
}

In diesem Beispiel müssen Sie ApplicationContext verwenden, um den Einstiegspunkt abzurufen, da der Einstiegspunkt in SingletonComponent installiert ist. Wenn sich die Bindung, die Sie abrufen möchten, in der ActivityComponent befindet, verwenden Sie stattdessen die ActivityContext.

Hilt und Dagger

Hilt ist die offiziell empfohlene Bibliothek für die Abhängigkeitsinjektion in Android. Sie bietet eine standardisierte, vordefinierte und effiziente Möglichkeit, die Abhängigkeitsinjektion in Ihrer Anwendung zu implementieren, und ist speziell für Jetpack Compose und Single-Activity-Architekturen optimiert.

Hilt hat folgende Ziele:

• Erstellen eines Standardsatzes von Komponenten und Bereichen, um die Einrichtung, Lesbarkeit und Codefreigabe zwischen Apps zu vereinfachen.
• Eine einfache Möglichkeit, verschiedene Bindungen für verschiedene Build-Typen wie Tests, Debugging oder Releases bereitzustellen.

Da das Android-Betriebssystem viele seiner eigenen Framework-Klassen instanziiert, müssen Sie bei der Verwendung von Dagger in einer Android-App eine erhebliche Menge an Boilerplate-Code schreiben. Hilt reduziert den Boilerplate-Code, der bei der Verwendung von Dagger in einer Android-App anfällt. Hilt generiert und stellt automatisch Folgendes bereit:

• Komponenten für die Integration von Android-Framework-Klassen in Dagger, die Sie sonst manuell erstellen müssten.
• Bereichsannotationen, die mit den Komponenten verwendet werden, die Hilt automatisch generiert.
• Vordefinierte Bindungen zur Darstellung von Android-Klassen wie Application oder Activity.
• Vordefinierte Qualifizierer für @ApplicationContext und @ActivityContext.

Dagger- und Hilt-Code können in derselben Codebasis koexistieren. In den meisten Fällen ist es jedoch am besten, Hilt zu verwenden, um die gesamte Nutzung von Dagger unter Android zu verwalten. Informationen zum Migrieren eines Projekts, das Dagger verwendet, zu Hilt finden Sie in der Migrationsanleitung.

Zusätzliche Ressourcen

Weitere Informationen zu Hilt findest du in den folgenden Ressourcen.

Beispiele

Blogs

• Abhängigkeitsinjektion unter Android mit Hilt
• Scoping in Android und Hilt
• Komponenten zur Hilt-Hierarchie hinzufügen
• Migrating the Google I/O app to Hilt

Inhalte ansehen

• Dependency Injection mit Hilt (Ansichten)