App-Startzeit

Nutzer erwarten, dass Apps schnell geladen werden und schnell reagieren. Eine App mit einer langsamen Startzeit die Erwartungen nicht erfüllt und die Nutzer enttäuschen kann. Diese schlechte möglicherweise dazu führen, dass der Nutzer Ihre App im Play Store schlecht bewertet oder sogar ganz aufgeben.

Diese Seite enthält Informationen zur Optimierung der Startzeit Ihrer App, einschließlich einer Übersicht über die internen Abläufe des Einführungsprozesses, und einige häufige Probleme beim Start mit Tipps dazu, wie Sie und sie anzugehen.

Die verschiedenen Startstatus von Apps

Die App-Einführung kann in einem von drei Zuständen erfolgen: Kaltstart, Warmstart oder Heißstart. beginnen. Jeder Status hat Einfluss darauf, wie lange es dauert, bis Ihre App Nutzenden. Bei einem Kaltstart beginnt Ihre App bei null. In den anderen Bundesstaaten muss das System die ausgeführte App vom Hintergrund in den Vordergrund bringen.

Wir empfehlen, die Optimierung immer auf der Grundlage eines Kaltstarts durchzuführen. Dies kann auch die Leistung von Warm- und Heißstarts verbessern.

Um Ihre App für einen schnellen Start zu optimieren, sollten Sie wissen, auf System- und App-Ebene stattfinden und wie sie jeweils interagieren, Bundesländer.

Zwei wichtige Messwerte zum Ermitteln des App-Starts sind die Zeit bis zur ersten Anzeige. (TTID) und Zeit bis vollständig gezeichnet (TTFD). Die TTID ist die Zeit, die benötigt wird, ersten Frame anzeigen. TTFD ist die Zeit, die benötigt wird, bis die App vollständig interaktiv. Beide sind gleich wichtig, da die TTID den Nutzer ob die App geladen wird. TTFD ist der Zeitpunkt, an dem die App tatsächlich verwendet werden kann. Wenn entweder sind zu lang, könnte der Nutzer die App beenden, bevor sie überhaupt geladen wurde.

Kaltstart

Ein Kaltstart bezieht sich darauf, dass eine App bei null beginnt. Das bedeutet, dass bis zum wird der App-Prozess durch den Systemprozess erstellt. Kaltstarts sind möglich In Fällen, in denen deine App zum ersten Mal nach dem Starten des Geräts gestartet wird oder weil das System die App beendet hat.

Diese Art des Starts stellt die größte Herausforderung dar, da das System und die App mehr Arbeit zu erledigen haben als in den anderen Markteinführungsstatus.

Zu Beginn eines Kaltstarts führt das System die drei folgenden Aufgaben aus:

1. Laden Sie die App und starten Sie sie.
2. Sofort nach dem Start der App ein leeres Startfenster anzeigen
3. Erstellen Sie den Anwendungsprozess.

Sobald das System den App-Prozess erstellt hat, für die nächsten Phasen:

1. Erstellen Sie das App-Objekt.
2. Starten Sie den Hauptthread.
3. Erstellen Sie die Hauptaktivität.
4. Mehr Aufrufe erzielen
5. Layout des Bildschirms
6. Führen Sie die erste Zeichnung aus.

Wenn der App-Prozess die erste Ziehung abgeschlossen hat, tauscht der Systemprozess die eines angezeigten Hintergrundfensters und ersetzt es durch die Hauptaktivität. An dieser Stelle damit Nutzende die App nutzen können.

Abbildung 1 zeigt die Funktionsweise der System- und Anwendungsprozesse, die zwischen den einzelnen Prozessen übergeben werden. Sonstiges.

</ph>

Leistungsprobleme können während der Erstellung der App und der Erstellung der Aktivitäten.

App-Erstellung

Beim Starten der App bleibt das leere Startfenster so lange auf dem Bildschirm, bis ist das System damit fertig, die App zum ersten Mal zu zeichnen. An dieser Stelle Systemprozess tauscht das Startfenster für Ihre App aus, sodass der Nutzer mit der App.

Wenn Sie Application.onCreate() in Ihrer eigenen App überschreiben, ruft die Methode onCreate() für das App-Objekt auf. Anschließend wird die App aufgerufen, dem Hauptthread, auch UI-Thread genannt, zu erstellen und ihn mit der Erstellung Hauptaktivität.

Ab diesem Zeitpunkt verfahren die Prozesse auf System- und App-Ebene in Übereinstimmung mit den Phasen des App-Lebenszyklus.

Aktivitäten erstellen

Nachdem der App-Prozess Ihre Aktivität erstellt hat, führt die Aktivität Folgendes aus: Betriebsabläufe:

1. Initialisiert Werte.
2. Ruft Konstruktoren auf.
3. Ruft die Callback-Methode wie Activity.onCreate() auf auf den aktuellen Lebenszyklusstatus der Aktivität.

In der Regel hat die Methode onCreate() den größten Einfluss auf die Ladezeit. da er die Arbeit mit dem höchsten Aufwand ausführt: Laden und Aufblähen. und Initialisierung der Objekte, die für die Ausführung der Aktivität benötigt werden.

Warm start

Ein Warmstart umfasst eine Teilmenge der Vorgänge, die während Kaltstart. Gleichzeitig stellt sie mehr Aufwand dar als ein Heißstart. Es gibt viele mögliche Status, die als Warmstarts betrachtet werden können, z. B. Folgendes:

• Der Nutzer verlässt Ihre App, startet sie aber neu. Der Prozess kann weiter ausgeführt werden, aber die App muss die Aktivität mithilfe eines Aufruf von onCreate().

• Ihre App wird vom System entfernt und vom Nutzer neu gestartet. Die und die Aktivität muss neu gestartet werden, aber die Aufgabe kann von Vorteil sein. aus dem gespeicherten Instanzstatus-Bundle, das an onCreate() übergeben wurde.

Heißstart

Bei einem Heißstart Ihrer App ist der Overhead geringer als bei einem Kaltstart. Bei einem Heißstart bringt das System Ihre Aktivität in den Vordergrund. Wenn alle Aktivitäten sich weiterhin im Speicher befinden, kann die App die Wiederholung von Objekten vermeiden. Initialisierung, Layout-Inflation und Rendering.

Wenn jedoch ein Teil des Arbeitsspeichers als Reaktion auf Speicher Trimming-Ereignisse geleert wird, z. B. onTrimMemory(): Diese Objekte müssen als Reaktion auf das Heißstart-Ereignis.

Bei einem Heißstart wird dasselbe Bildschirmverhalten angezeigt wie bei einem Kaltstart. Die zeigt der Systemprozess einen leeren Bildschirm an, bis die App Aktivitäten.

</ph>

App-Start-up in Perfetto identifizieren

Um Probleme beim Starten von Apps zu beheben, ist es hilfreich zu ermitteln, was genau enthalten ist. in der App-Startphase sein. Um die gesamte App-Startphase im Perfetto:

1. Suchen Sie in Perfetto nach der Zeile mit dem abgeleiteten Messwert „Android-App-Starts“. Wenn wenn Sie es nicht sehen, versuchen Sie, einen Trace mit dem On-Device-System Tracing zu erfassen. App.

   <ph type="x-smartling-placeholder">

   </ph>

2. Klicken Sie auf das entsprechende Segment und drücken Sie M, um es auszuwählen. Um das Segment herum werden Klammern angezeigt, die angeben, wie lange es gedauert hat. Die Dauer beträgt auch auf dem Tab Aktuelle Auswahl angezeigt.

3. Pinnen Sie die Zeile „Android-App-Starts“ an, indem Sie auf das Stecknadelsymbol wenn Sie den Mauszeiger auf die Zeile bewegen.

4. Scrollen Sie zur Zeile mit der betreffenden App und klicken Sie auf die erste Zelle, um sie zu maximieren. Zeile.

5. Zoomen Sie den Hauptthread heran, meist oben, indem Sie auf w drücken. (Drücken Sie s, a, d zum Herauszoomen, zum Verschieben nach links und nach rechts, )

   <ph type="x-smartling-placeholder">

   </ph>

6. Durch das Segment mit den abgeleiteten Messwerten lässt sich leichter erkennen, beim Start der App, damit Sie detailliertere Fehlerbehebungen durchführen können.

Start-ups anhand von Messwerten analysieren und verbessern

Um die Leistung bei der Startzeit korrekt zu diagnostizieren, können Sie Messwerte erfassen, die wie lange es dauert, bis Ihre App startet. Android bietet mehrere Möglichkeiten, dass deine App ein Problem hat, und hilft dir bei der Diagnose. Android Vitals kann Sie werden darauf hingewiesen, dass ein Problem auftritt, und Diagnose-Tools können Ihnen helfen, um das Problem zu diagnostizieren.

Vorteile der Nutzung von Start-up-Messwerten

Android verwendet die Zeit bis zur ersten Anzeige (Time to initial display, TTID) und die Zeit bis zur vollständigen Anzeige (TTFD), um kalte und warme App-Starts zu optimieren. Android Runtime (ART) nutzt die Daten aus diesen Messwerten, um Code zur Optimierung effizient vorzukompilieren von zukünftigen Start-ups.

Schnellere Starts führen zu einer nachhaltigeren Interaktion der Nutzer mit Ihrer App. reduziert Fälle vorzeitigem Beenden, Neustarten der Instanz oder Verlassen der Seite in einer anderen App.

Android Vitals

Android Vitals kann dir helfen, die Leistung deiner App zu verbessern, indem du Play Console, wenn die Startzeiten Ihrer App zu lang sind

In Android Vitals sind die folgenden Startzeiten für deine App zu hoch:

• Der Kaltstart dauert mindestens 5 Sekunden.
• Der Warmstart-Start dauert 2 Sekunden oder länger.
• Der Heißstart dauert 1,5 Sekunden oder länger.

In Android Vitals wird der Messwert Zeit bis zur ersten Anzeige (TTID) verwendet. Für Informationen zur Erhebung von Android Vitals-Daten durch Google Play finden Sie in der Google Play-Hilfe Dokumentation zur Console

Zeit bis zur ersten Anzeige

Die Zeit bis zur ersten Anzeige (Time to initial display, TTID) ist die Zeit, die benötigt wird, um den ersten Frame anzuzeigen der Benutzeroberfläche der App. Dieser Messwert gibt an, wie lange eine App ersten Frame einschließlich der Prozessinitialisierung während eines Kaltstarts, während eines Kalt- oder Warmstarts erstellt wird und der erste Frame angezeigt wird. Wird beibehalten Eine niedrige TTID für Ihre App trägt zu einer besseren Nutzererfahrung bei, da Nutzer sehen können, schnell auf den Markt zu kommen. Die TTID wird automatisch für jede App vom Android- Framework. Bei der Optimierung für App-Start-ups empfehlen wir, reportFullyDrawn, um Informationen bis zu TTFD zu erhalten.

Die TTID wird als Zeitwert gemessen, der die gesamte verstrichene Zeit darstellt, die folgende Ereignissequenz umfasst:

• Prozess wird gestartet.
• Objekte initialisieren
• Erstellen und Initialisieren der Aktivität
• Layout-Inflation
• Sie zeichnen die App zum ersten Mal.

TTID abrufen

Um die TTID zu finden, suchen Sie im Logcat-Befehlszeilentool nach einer Ausgabezeile der den Wert Displayed enthält. Dieser Wert ist die TTID und sieht ähnlich aus mit dem folgenden Beispiel, in dem die TTID 3s534ms ist:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Um die TTID in Android Studio zu finden, deaktivieren Sie die Filter in Ihrer Logcat-Ansicht in der und suchen Sie dann die Uhrzeit (Displayed) (siehe Abbildung 5). Das Deaktivieren der Filter ist notwendig, da der Systemserver und nicht die Anwendung liefert dieses Protokoll.

</ph>

Der Messwert Displayed in der Logcat-Ausgabe erfasst nicht unbedingt den Messwert bis alle Ressourcen geladen und angezeigt wurden. Wird weggelassen Ressourcen, auf die in der Layoutdatei nicht verwiesen wird oder die von der App als Teil der Objektinitialisierung. Diese Ressourcen werden ausgeschlossen, da sie geladen werden. ist ein Inline-Prozess und blockiert die anfängliche Anzeige der App nicht.

Manchmal enthält die Zeile Displayed in der Logcat-Ausgabe ein zusätzliches Feld für die Gesamtzeit. Beispiel:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

In diesem Fall bezieht sich die erste Messung nur auf die Aktivität, die zuerst gezeichnet. Die Messung der total-Zeit beginnt beim Start des Anwendungsprozesses und kann eine andere Aktivität enthalten, die zuerst gestartet wurde, auf dem Bildschirm. Die Zeitmessung für total wird nur angezeigt, wenn eine die Differenz zwischen der Einzelaktivität und der Startzeit insgesamt.

Wir empfehlen die Verwendung von Logcat in Android Studio, Studio verwenden, können Sie die TTID auch messen, indem Sie Ihre App mit der adb-Shell ausführen. Aktivitätsmanager-Befehl. Beispiel:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Der Messwert Displayed wird wie zuvor in der Logcat-Ausgabe angezeigt. Mein Terminal wird Folgendes angezeigt:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

Die Argumente -c und -a sind optional und ermöglichen die Angabe von <category>. und <action>.

Zeit bis zur vollständigen Anzeige

Die Zeit bis zur vollständigen Anzeige (Time to Full Display, TTFD) ist die Zeit, die benötigt wird, bis eine App für die Nutzenden interaktiv. Es wird angegeben, wie lange es dauert, ersten Frame der App-Benutzeroberfläche sowie der asynchron geladene Inhalt nachdem der erste Frame angezeigt wird. Im Allgemeinen ist dies der primäre Inhalt, der geladen wird. aus dem Netzwerk oder Laufwerk, wie von der App gemeldet. Mit anderen Worten, TTFD beinhaltet TTID sowie die Zeit, die benötigt wird, bis die App nutzbar ist. Der Schutz Ihrer App Die niedrige TTFD-Einstellung bietet eine bessere Nutzererfahrung, da die Nutzer mit Ihrer Website interagieren können. schnell aktualisieren.

Das System bestimmt die TTID, wenn Choreographer den Aufruf onDraw() an und wenn ihr diese zum ersten Mal aufruft. Das System weiß jedoch nicht, wann TTFD bestimmt werden soll, da jede App sich anders verhält. Zum Ermitteln von TTFD muss die App dem System ein Signal senden sobald er vollständig gezeichnet wurde.

TTFD abrufen

Um TTFD zu finden, signalisieren Sie den vollständigen Status, indem Sie die Methode reportFullyDrawn()-Methode des ComponentActivity-Elements. Die Die Methode reportFullyDrawn gibt an, wann die App vollständig gezeichnet wurde und sich in einer nutzbaren Bundesstaat. Das TTFD ist die Zeit, die ab dem Empfang der App-Einführung im System verstrichen ist. Intent für den Aufruf von reportFullyDrawn(). Wenn Sie nicht anrufen reportFullyDrawn(), es wird kein TTFD-Wert gemeldet.

Rufen Sie zum Messen von TTFD reportFullyDrawn() auf, nachdem Sie die Benutzeroberfläche vollständig gezeichnet haben alle Daten. reportFullyDrawn() nicht vor dem Aufruf der ersten Aktivität aufrufen zunächst wie vom System gemessen dargestellt und gezeichnet, erfasst die vom System gemessene Zeit. Mit anderen Worten: Wenn Sie reportFullyDrawn() bevor das System die TTID erkennt, meldet das System sowohl TTID und TTFD denselben Wert; dieser Wert ist der TTID-Wert.

Wenn Sie reportFullyDrawn() verwenden, zeigt Logcat eine Ausgabe wie die folgende an: Beispiel, wobei die TTFD 1s54ms beträgt:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Die Logcat-Ausgabe enthält manchmal die Zeit total, wie unter Time to anfängliche Anzeige.

Wenn die Anzeigezeiten länger als gewünscht sind, können Sie versuchen, Engpässe im Startprozess.

In einfachen Fällen können Sie reportFullyDrawn() verwenden, um den vollständig dargestellten Zustand zu signalisieren in dem Sie erkennen, dass der vollständig gezeichnete Zustand erreicht wird. In Fällen, in denen Dabei müssen Hintergrundthreads die Hintergrundarbeit abschließen, bevor sie vollständig gezeichnet werden. erreicht wurde, müssen Sie reportFullyDrawn() verzögern, um eine genauere TTFD-Messung: Weitere Informationen zum Verzögern von reportFullyDrawn() findest du hier: .

Genauigkeit beim Startzeitpunkt verbessern

Wenn Ihre App Lazy Loading ausführt und die anfängliche Anzeige keinen z. B. wenn Ihre App Bilder aus dem Netzwerk abruft, sollten Sie den Aufruf von reportFullyDrawn möglicherweise so lange verzögern, bis Ihre App verwendbar, sodass Sie die Bevölkerung der Liste in die Benchmark aufnehmen können. Timing ist.

Dies ist beispielsweise der Fall, wenn die UI eine dynamische Liste wie ein RecyclerView-Element enthält. oder Lazy-Liste, kann diese durch eine Hintergrundaufgabe gefüllt werden, die nach wird die Liste zuerst gezeichnet, d. h. nachdem die Benutzeroberfläche als vollständig gezeichnet markiert wurde. In diesen Fällen wird das Füllen der Liste nicht in das Benchmarking einbezogen.

Um die Bevölkerung der Liste in den Benchmark-Zeitplan einzubeziehen, rufen Sie den Messwert FullyDrawnReporter mithilfe von getFullyDrawnReporter() und fügen Sie einen in Ihrem App-Code hinzufügen können. Reporter nach der Hintergrundaufgabe loslassen das Ausfüllen der Liste beendet.

FullyDrawnReporter ruft die Methode reportFullyDrawn() erst auf, wenn alle die hinzugefügten Reporter frei. Durch Hinzufügen eines Reporters bis zum Hintergrundprozess enthält, enthalten die Timings auch die Zeit, die benötigt wird, in den Startzeitdaten. Dies ändert nichts am App-Verhalten für den aber die Daten zum Zeitpunkt des Starts enthalten die Zeit, die benötigt wird, um die Daten auf der Liste. reportFullyDrawn() wird erst aufgerufen, wenn alle Aufgaben erledigt sind abgeschlossen sein, unabhängig vom Auftrag.

Das folgende Beispiel zeigt, wie Sie mehrere Hintergrundaufgaben ausführen können gleichzeitig, wobei jeder seinen eigenen Reporter registriert:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

public class MainActivity extends ComponentActivity {
    private FullyDrawnReporter fullyDrawnReporter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        fullyDrawnReporter = getFullyDrawnReporter();
        fullyDrawnReporter.addOnReportDrawnListener(() -> {
            // Trigger the UI update.
            return Unit.INSTANCE;
        });

        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();

                // Do the background work.

               fullyDrawnReporter.removeReporter();
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();

                // Do the background work.

                fullyDrawnReporter.removeReporter();
            }
        }).start();
    }
}

Wenn Ihre App Jetpack Compose verwendet, können Sie mit den folgenden APIs angeben, vollständig gezeichneter Zustand:

• ReportDrawn: Gibt an, dass die zusammensetzbare Funktion sofort einsatzbereit ist. Interaktion.
• ReportDrawnWhen: verwendet ein Prädikat wie list.count > 0, um um anzugeben, wann die zusammensetzbare Funktion interaktiv ist.
• ReportDrawnAfter: Hiermit wird eine Sperrmethode verwendet, die nach Abschluss zeigt an, dass die zusammensetzbare Funktion zur Interaktion bereit ist.

Engpässe identifizieren

Mit dem CPU-Profiler von Android Studio können Sie nach Engpässen suchen. Weitere Informationen Weitere Informationen finden Sie unter CPU-Aktivität mit CPU Profiler prüfen.

Durch Inline-Tracing erhalten Sie einen Einblick in potenzielle Engpässe. in den Einstellungen deiner Apps und Aktivitäten“ onCreate()-Methoden. Weitere Informationen zu Inline-Creatives Tracing finden Sie in der Dokumentation zu den Trace-Funktionen und in der Übersicht der Systemverfolgung.

Häufige Probleme beheben

In diesem Abschnitt werden mehrere Probleme behandelt, die sich häufig auf die Startleistung von Anwendungen auswirken. Diese Probleme betreffen hauptsächlich die Initialisierung von App- und Aktivitätsobjekten sowie das Laden von Bildschirmen.

Komplexe App-Initialisierung

Die Startleistung kann beeinträchtigt werden, wenn dein Code das Application-Objekt überschreibt und führt bei der Initialisierung des Objekts schwere Arbeit oder komplexe Logik aus. Ihre App kann beim Start Zeit verschwenden, wenn Ihre abgeleiteten Application-Klassen erfolgreich sind Initialisierungen, die noch nicht durchgeführt werden müssen.

Einige Initialisierungen sind möglicherweise vollkommen unnötig, z. B. bei der Initialisierung. für die Hauptaktivität, wenn die App tatsächlich gestartet wird. Antwort auf einen Intent. Bei einem Intent verwendet die App nur eine Teilmenge der zuvor initialisierten Statusdaten.

Weitere Herausforderungen bei der App-Initialisierung sind unter anderem die automatische Speicherbereinigung. die gleichzeitig aktiv oder zahlreich sind, oder Laufwerks-E/A, Initialisierung, die den Initialisierungsprozess weiter blockiert. Müll ist bei der Dalvik-Laufzeit besonders wichtig; das Android- Laufzeit (ART) führt gleichzeitig eine automatische Speicherbereinigung durch, die Auswirkungen des Vorgangs.

Problem diagnostizieren

Sie können Methoden- oder Inline-Tracing verwenden, um das Problem zu diagnostizieren.

Methoden-Tracing

Wenn Sie den CPU-Profiler ausführen, sehen Sie, dass der callApplicationOnCreate() ruft die Methode com.example.customApplication.onCreate auf. Wenn zeigt das Tool, dass die Ausführung dieser Methoden lange dauert. um zu sehen, was dort gerade passiert.

Inline-Tracing

Mit Inline-Tracing können Sie potenzielle Täter untersuchen, darunter:

• Die anfängliche onCreate()-Funktion Ihrer App.
• Alle globalen Singleton-Objekte, die von Ihrer App initialisiert werden.
• Jegliche Laufwerks-E/A, Deserialisierung oder enge Schleifen, die während den Engpass beseitigen.

Lösungen für das Problem

Unabhängig davon, ob das Problem durch unnötige Initialisierungen oder die Laufwerk-E/A verursacht wird, ist die verzögerte Initialisierung. Mit anderen Worten: Initialisieren Sie nur Objekte, sofort benötigt werden. Anstatt globale statische Objekte zu erstellen, wechseln Sie zu einem Singleton-Muster, bei dem die App Objekte nur dann initialisiert, wenn sie zum ersten Mal benötigt wird. .

Erwägen Sie auch die Verwendung eines Abhängigkeitsinjektions-Frameworks wie Hilt, das Objekte und Abhängigkeiten erstellt, wenn diese zum ersten Mal injiziert werden.

Wenn Ihre App Contentanbieter für die Initialisierung von App-Komponenten beim Start verwendet, Verwenden Sie stattdessen die App-Start-Bibliothek.

Initialisierung starker Aktivitäten

Das Erstellen von Aktivitäten ist häufig mit einem hohen Arbeitsaufwand verbunden. Häufig gibt es Möglichkeiten zur Optimierung dieser Arbeit, um Leistungsverbesserungen zu erzielen. Ein solches Folgende Probleme treten häufig auf:

• Das Aufblähen großer oder komplexer Layouts
• Blockierende Bildschirmzeichnung auf dem Laufwerk oder der Netzwerk-E/A.
• Bitmaps laden und decodieren
• VectorDrawable-Objekte rastern
• Initialisierung anderer Subsysteme der Aktivität.

Problem diagnostizieren

Auch in diesem Fall können sowohl Methoden- als auch Inline-Tracing nützlich sein.

Methoden-Tracing

Achten Sie bei Verwendung des CPU-Profilers auf den Application Ihrer App abgeleiteten Klassenkonstruktoren und com.example.customApplication.onCreate()-Methoden.

Zeigt das Tool, dass die Ausführung dieser Methoden lange dauert, um zu sehen, was dort gerade passiert.

Inline-Tracing

Mit Inline-Tracing können Sie potenzielle Täter untersuchen, darunter:

• Die anfängliche onCreate()-Funktion deiner App.
• Alle globalen Singleton-Objekte, die initialisiert werden.
• Jegliche Laufwerks-E/A, Deserialisierung oder enge Schleifen, die während den Engpass beseitigen.

Lösungen für das Problem

Es gibt viele potenzielle Engpässe, aber zwei häufige Probleme und Abhilfen sind wie folgt:

• Je größer Ihre Ansichtshierarchie ist, desto mehr Zeit benötigt die App, um sie zu erhöhen. Zwei können Sie Folgendes tun, um das Problem zu beheben: <ph type="x-smartling-placeholder">
  </ph>
  • Sie können Ihre Ansichtshierarchie vereinfachen, indem Sie redundante oder verschachtelte Layouts reduzieren.
  • Blende keine Bereiche der Benutzeroberfläche auf, die beim Start nicht sichtbar sein müssen. Verwenden Sie stattdessen ein ViewStub-Objekt als Platzhalter für Unterhierarchien. damit sich die App zu einem geeigneten Zeitpunkt aufblähen kann.
• Die gesamte Initialisierung der Ressourcen im Hauptthread kann ebenfalls verlangsamt werden. herunterfahren können. Sie können dieses Problem so beheben: <ph type="x-smartling-placeholder">
  </ph>
  • Verschieben Sie die gesamte Ressourceninitialisierung, sodass die App sie verzögert auf einer einem anderen Thread.
  • Laden Sie die App und zeigen Sie Ihre Ansichten an und aktualisieren Sie später die Grafik die von Bitmaps und anderen Ressourcen abhängig sind.

Personalisierte Startbildschirme

Möglicherweise wird beim Start zusätzliche Zeit hinzugefügt, wenn Sie zuvor eine der folgenden Optionen verwendet haben: die folgenden Methoden, um einen benutzerdefinierten Ladebildschirm in Android 11 (API) zu implementieren Level 30) oder früher:

• Das Designattribut windowDisablePreview verwenden, um den Anfangszustand zu deaktivieren leerer Bildschirm, der beim Start vom System gezeichnet wird.
• Mit einer dedizierten Activity.

Ab Android 12 ist eine Migration zur SplashScreen API erforderlich. Diese API ermöglicht eine schnellere Startzeit und ermöglicht es Ihnen, den Ladebildschirm in auf folgende Arten:

• Wählen Sie ein Design aus, um das Aussehen des Ladebildschirms zu ändern.
• Sie können festlegen, wie lange der Ladebildschirm angezeigt wird, windowSplashScreenAnimationDuration
• Passen Sie die Ladebildschirmanimation an und verwenden Sie Animation zum Schließen des Ladebildschirms.

Darüber hinaus wird die SplashScreen API von der kompatiblen Bibliothek rückportiert, um Abwärtskompatibilität und sorgt für ein einheitliches Erscheinungsbild Bildschirmdarstellung bei allen Android-Versionen.

Weitere Informationen finden Sie in der Migrationsanleitung für den Ladebildschirm.