App-Start Teil von Android Jetpack

Die App-Start-Bibliothek bietet eine einfache und leistungsstarke Möglichkeit, Komponenten beim Start von Anwendungen zu initialisieren. Sowohl Bibliotheks- als auch App-Entwickler können App Startup verwenden, um Startsequenzen zu optimieren und die Reihenfolge der Initialisierung explizit festzulegen.

Anstatt für jede zu initialisierende Komponente separate Contentanbieter festzulegen, können Sie mit dem App-Start Komponenteninitialisierungen mit einem einzigen Contentanbieter definieren. Dies kann die Startzeit der App erheblich verkürzen.

Einrichten

Wenn Sie Jetpack Startup in Ihrer Bibliothek oder App verwenden möchten, fügen Sie Ihrer Gradle-Datei Folgendes hinzu:

Groovig

dependencies {
    implementation "androidx.startup:startup-runtime:1.1.1"
}

Kotlin

dependencies {
    implementation("androidx.startup:startup-runtime:1.1.1")
}

Komponenten beim App-Start initialisieren

Anwendungen und Bibliotheken sind häufig darauf angewiesen, dass Komponenten sofort beim Start der App initialisiert werden. Sie können diese Anforderung erfüllen, indem Sie Contentanbieter verwenden, um jede Abhängigkeit zu initialisieren. Die Instanziierung von Contentanbietern ist jedoch teuer und kann die Startsequenz unnötig verlangsamen. Außerdem initialisiert Android Contentanbieter in einer unbestimmten Reihenfolge. Der App-Start bietet eine leistungsfähigere Möglichkeit, Komponenten beim Start der Anwendung zu initialisieren und deren Abhängigkeiten explizit zu definieren.

Wenn Sie „App Startup“ verwenden möchten, um Komponenten beim Start automatisch zu initialisieren, müssen Sie für jede Komponente, die von der App initialisiert werden muss, einen Komponenteninitialisierer definieren.

Komponenteninitialisierungen implementieren

Zum Definieren jedes Komponenteninitialisierers erstellen Sie eine Klasse, die die Initializer<T>-Schnittstelle implementiert. In dieser Schnittstelle werden zwei wichtige Methoden definiert:

  • Die Methode create(), die alle erforderlichen Vorgänge zum Initialisieren der Komponente enthält und eine Instanz von T zurückgibt.
  • Die Methode dependencies(), die eine Liste der anderen Initializer<T>-Objekte zurückgibt, von denen der Initialisierer abhängt. Mit dieser Methode können Sie die Reihenfolge steuern, in der die Anwendung die Initialisierungen beim Start ausführt.

Angenommen, Ihre Anwendung ist von WorkManager abhängig und muss beim Start initialisiert werden. Definieren Sie eine WorkManagerInitializer-Klasse, die Initializer<WorkManager> implementiert:

Kotlin

// Initializes WorkManager.
class WorkManagerInitializer : Initializer<WorkManager> {
    override fun create(context: Context): WorkManager {
        val configuration = Configuration.Builder().build()
        WorkManager.initialize(context, configuration)
        return WorkManager.getInstance(context)
    }
    override fun dependencies(): List<Class<out Initializer<*>>> {
        // No dependencies on other libraries.
        return emptyList()
    }
}

Java

// Initializes WorkManager.
class WorkManagerInitializer implements Initializer<WorkManager> {

    @Override
    public WorkManager create(Context context) {
        Configuration configuration = Configuration.Builder().build();
        WorkManager.initialize(context, configuration);
        return WorkManager.getInstance(context);
    }

    @Override
    public List<Class<Initializer<?>>> dependencies() {
        // No dependencies on other libraries.
        return emptyList();
    }

}

Die Methode dependencies() gibt eine leere Liste zurück, da WorkManager nicht von anderen Bibliotheken abhängig ist.

Angenommen, Ihre Anwendung hängt auch von einer Bibliothek namens ExampleLogger ab, die wiederum von WorkManager abhängt. Diese Abhängigkeit bedeutet, dass der App-Start-up zuerst WorkManager initialisieren muss. Definieren Sie eine ExampleLoggerInitializer-Klasse, die Initializer<ExampleLogger> implementiert:

Kotlin

// Initializes ExampleLogger.
class ExampleLoggerInitializer : Initializer<ExampleLogger> {
    override fun create(context: Context): ExampleLogger {
        // WorkManager.getInstance() is non-null only after
        // WorkManager is initialized.
        return ExampleLogger(WorkManager.getInstance(context))
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        // Defines a dependency on WorkManagerInitializer so it can be
        // initialized after WorkManager is initialized.
        return listOf(WorkManagerInitializer::class.java)
    }
}

Java

// Initializes ExampleLogger.
class ExampleLoggerInitializer implements Initializer<ExampleLogger> {

    @Override
    public ExampleLogger create(Context context) {
        // WorkManager.getInstance() is non-null only after
        // WorkManager is initialized.
        return ExampleLogger(WorkManager.getInstance(context));
    }

    @Override
    public List<Class<Initializer<?>>> dependencies() {
        // Defines a dependency on WorkManagerInitializer so it can be
        // initialized after WorkManager is initialized.
        return Arrays.asList(WorkManagerInitializer.class);
    }
}

Da Sie WorkManagerInitializer in die Methode dependencies() aufnehmen, initialisiert App-Start WorkManager vor ExampleLogger.

Manifesteinträge einrichten

App-Start umfasst einen speziellen Inhaltsanbieter namens InitializationProvider, mit dem Ihre Komponenteninitialisierer erkannt und aufgerufen werden. App Startup erkennt Komponenteninitialisierer, indem es zuerst nach einem <meta-data>-Eintrag unter dem Manifesteintrag InitializationProvider sucht. Anschließend ruft der App-Start die Methoden dependencies() für alle Initialisierer auf, die bereits erkannt wurden.

Das bedeutet, dass eine der folgenden Bedingungen erfüllt sein muss, damit ein Komponenteninitialisierer vom App-Start erkannt werden kann:

  • Der Komponenteninitialisierer hat einen entsprechenden <meta-data>-Eintrag unter dem Manifesteintrag InitializationProvider.
  • Der Komponenteninitialisierer wird in der Methode dependencies() eines Initialisierers aufgeführt, der bereits sichtbar ist.

Betrachten Sie noch einmal das Beispiel mit WorkManagerInitializer und ExampleLoggerInitializer. Damit der App-Start diese Initialisierer erkennen kann, fügen Sie der Manifestdatei Folgendes hinzu:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <!-- This entry makes ExampleLoggerInitializer discoverable. -->
    <meta-data  android:name="com.example.ExampleLoggerInitializer"
          android:value="androidx.startup" />
</provider>

Sie müssen für WorkManagerInitializer keinen <meta-data>-Eintrag hinzufügen, da WorkManagerInitializer eine Abhängigkeit von ExampleLoggerInitializer ist. Wenn also ExampleLoggerInitializer sichtbar ist, ist es auch WorkManagerInitializer.

Das Attribut tools:node="merge" sorgt dafür, dass das Tool zum Zusammenführen von Manifesten alle in Konflikt stehenden Einträge korrekt auflöst.

Lint-Prüfungen ausführen

Die App-Startbibliothek enthält eine Reihe von Lint-Regeln, mit denen Sie prüfen können, ob Sie die Komponenteninitialisierer korrekt definiert haben. Sie können diese Lint-Prüfungen ausführen, indem Sie ./gradlew :app:lintDebug über die Befehlszeile ausführen.

Komponenten manuell initialisieren

Wenn Sie „App-Start“ verwenden, verwendet das Objekt InitializationProvider normalerweise eine Entität mit dem Namen AppInitializer, um Komponenteninitialisierer beim Start der Anwendung automatisch zu erkennen und auszuführen. Sie können AppInitializer jedoch auch direkt verwenden, um Komponenten manuell zu initialisieren, die Ihre Anwendung beim Start nicht benötigt. Dies wird als verzögerte Initialisierung bezeichnet und kann die Startkosten minimieren.

Sie müssen zuerst die automatische Initialisierung für alle Komponenten deaktivieren, die Sie manuell initialisieren möchten.

Automatische Initialisierung für eine einzelne Komponente deaktivieren

Wenn Sie die automatische Initialisierung für eine einzelne Komponente deaktivieren möchten, entfernen Sie den Eintrag <meta-data> für den Initialisierer dieser Komponente aus dem Manifest.

Wenn du der Manifestdatei beispielsweise Folgendes hinzufügst, wird die automatische Initialisierung für ExampleLogger deaktiviert:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data android:name="com.example.ExampleLoggerInitializer"
              tools:node="remove" />
</provider>

Im Eintrag wird tools:node="remove" verwendet, anstatt den Eintrag einfach zu entfernen. So sorgen Sie dafür, dass das Zusammenführungstool den Eintrag auch aus allen anderen zusammengeführten Manifestdateien entfernt.

Automatische Initialisierung für alle Komponenten deaktivieren

Wenn du die gesamte automatische Initialisierung deaktivieren möchtest, entferne den gesamten Eintrag für InitializationProvider aus dem Manifest:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    tools:node="remove" />

Komponenten-Initialisierer manuell aufrufen

Wenn die automatische Initialisierung für eine Komponente deaktiviert ist, können Sie diese Komponente und ihre Abhängigkeiten mit AppInitializer manuell initialisieren.

Mit dem folgenden Code wird beispielsweise AppInitializer aufgerufen und ExampleLogger manuell initialisiert:

Kotlin

AppInitializer.getInstance(context)
    .initializeComponent(ExampleLoggerInitializer::class.java)

Java

AppInitializer.getInstance(context)
    .initializeComponent(ExampleLoggerInitializer.class);

Daher initialisiert App Startup auch WorkManager, da WorkManager eine Abhängigkeit von ExampleLogger ist.

Feedback geben

Teilen Sie uns Ihr Feedback und Ihre Ideen über diese Ressourcen mit:

Problemverfolgung
Melden Sie Probleme, damit wir sie beheben können.