Nicht optimierte Downloads vermeiden

Einige Nutzer Ihrer App haben nur sporadisch Zugriff auf das Internet oder es gibt Einschränkungen bei der Menge an Informationen, die sie auf ihre Geräte herunterladen können. Sie können Nutzer dazu anregen, häufiger mit Ihrer App zu interagieren, indem Sie die Menge der Daten reduzieren, die Ihre App herunterladen muss.

Die einfachste Möglichkeit, die Anzahl der Downloads zu reduzieren, besteht darin, nur das herunterzuladen, was Sie benötigen. Für Daten bedeutet das, REST APIs zu implementieren, mit denen Sie Abfragekriterien angeben können, die die zurückgegebenen Daten mithilfe von Parametern wie dem Zeitpunkt der letzten Aktualisierung einschränken.

Beim Herunterladen von Bildern empfiehlt es sich ebenfalls, die Größe der Bilder serverseitig zu reduzieren, anstatt Bilder in voller Größe herunterzuladen, die dann auf dem Client reduziert werden.

HTTP-Antworten im Cache speichern

Außerdem sollten Sie darauf achten, keine doppelten Daten herunterzuladen. Mithilfe von Caching lässt sich die Wahrscheinlichkeit verringern, dass dasselbe Datenelement wiederholt heruntergeladen wird. Wenn Sie die Daten und Ressourcen Ihrer App im Cache speichern, erstellen Sie eine lokale Kopie der Informationen, auf die Ihre App verweisen muss. Wenn Ihre App innerhalb kurzer Zeit mehrmals auf dieselbe Information zugreifen muss, müssen Sie sie nur einmal in den Cache herunterladen.

Es ist wichtig, so viel wie möglich im Cache zu speichern, um die Gesamtmenge der heruntergeladenen Daten zu reduzieren. Speichern Sie statische Ressourcen, einschließlich On-Demand-Downloads wie Bilder in Originalgröße, so lange wie möglich im Cache. On-Demand-Ressourcen sollten separat gespeichert werden, damit Sie den On-Demand-Cache regelmäßig leeren und so seine Größe verwalten können.

Damit Ihr Cache nicht dazu führt, dass Ihre App veraltete Daten anzeigt, verwenden Sie die entsprechenden HTTP-Statuscodes und ‑Header, z. B. die Header ETag und Last-Modified. So können Sie festlegen, wann die zugehörigen Inhalte aktualisiert werden sollen. Beispiel:

// url represents the website containing the content to place into the cache.
val conn: HttpsURLConnection = url.openConnection() as HttpsURLConnection
val currentTime: Long = System.currentTimeMillis()
val lastModified: Long = conn.getHeaderFieldDate("Last-Modified", currentTime)

// lastUpdateTime represents when the cache was last updated.
if (lastModified < lastUpdateTime) {
    // Skip update
} else {
    // Parse update
    lastUpdateTime = lastModified
}

// url represents the website containing the content to place into the cache.
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
long currentTime = System.currentTimeMillis();
long lastModified = conn.getHeaderFieldDate("Last-Modified", currentTime);

// lastUpdateTime represents when the cache was last updated.
if (lastModified < lastUpdateTime) {
    // Skip update
} else {
    // Parse update
    lastUpdateTime = lastModified;
}

Sie können einige Netzwerkbibliotheken so konfigurieren, dass diese Statuscodes und ‑header automatisch berücksichtigt werden. Wenn Sie beispielsweise OkHttp verwenden, können Sie ein Cache-Verzeichnis und eine Cache-Größe für den Client konfigurieren, damit die Bibliothek HTTP-Caching verwenden kann, wie im folgenden Codebeispiel gezeigt:

val cacheDir = Context.getCacheDir()
val cacheSize = 10L * 1024L * 1024L // 10 MiB
val client: OkHttpClient = OkHttpClient.Builder()
    .cache(Cache(cacheDir, cacheSize))
    .build()

File cacheDir = Context.getCacheDir();
long cacheSize = 10L * 1024L * 1024L; // 10 MiB
OkHttpClient client = new OkHttpClient.Builder()
    .cache(new Cache(cacheDir, cacheSize))
    .build();

Wenn der Cache konfiguriert ist, können Sie vollständig im Cache gespeicherte HTTP-Anfragen direkt aus dem lokalen Speicher bereitstellen, sodass keine Netzwerkverbindung geöffnet werden muss. Bei bedingt im Cache gespeicherten Antworten kann die Aktualität vom Server überprüft werden, sodass die mit dem Download verbundenen Bandbreitenkosten entfallen. Nicht im Cache gespeicherte Antworten werden für zukünftige Anfragen im Antwortcache gespeichert.

Sie können nicht vertrauliche Daten mit Context.getExternalCacheDir() im nicht verwalteten externen Cacheverzeichnis zwischenspeichern. Alternativ können Sie Daten mit Context.getCacheDir() im verwalteten, sicheren Anwendungscache zwischenspeichern. Beachten Sie, dass dieser interne Cache möglicherweise geleert wird, wenn der verfügbare Speicherplatz des Systems knapp wird.

Repository verwenden

Für einen ausgefeilteren Ansatz zum Caching können Sie das Repository-Designmuster verwenden. Dazu müssen Sie eine benutzerdefinierte Klasse erstellen, die als Repository bezeichnet wird und eine API-Abstraktion für bestimmte Daten oder Ressourcen bietet. Das Repository kann seine Daten anfangs aus verschiedenen Quellen abrufen, z. B. aus einem Remote-Webdienst, stellt aber bei nachfolgenden Aufrufen eine im Cache gespeicherte Version der Daten bereit. Diese Ebene der Indirektion ermöglicht es Ihnen, eine robuste Caching-Strategie zu implementieren, die speziell auf Ihre App zugeschnitten ist. Weitere Informationen zur Verwendung des Repository-Musters in Ihrer App finden Sie im Leitfaden zur App-Architektur.