Éviter les téléchargements non optimisés

Certains utilisateurs de votre application ont un accès intermittent à Internet ou ont des limites sur la quantité d'informations qu'ils peuvent télécharger sur leurs appareils. Vous pouvez d'inciter les utilisateurs à interagir plus souvent avec votre application en réduisant le nombre de les données que votre application doit télécharger.

Pour réduire le nombre de téléchargements, le plus simple est de ne télécharger que ce que vous besoin. En termes de données, cela signifie implémenter des API REST qui vous permettent spécifier des critères de requête limitant les données renvoyées à l'aide de paramètres tels que l'heure de la dernière mise à jour.

De même, lors du téléchargement d'images, il est recommandé de réduire la taille des images côté serveur, plutôt que de télécharger des images en taille réelle qui sont réduites sur le client.

Mettre en cache les réponses HTTP

Une autre technique importante consiste à éviter de télécharger des données en double. Vous pouvez réduire la probabilité de télécharger plusieurs fois le même élément de données en utilisant mise en cache. En mettant en cache les données et les ressources de votre application, vous créez une copie locale les informations que votre application doit référencer. Si votre application a besoin d'accéder la même information plusieurs fois sur une courte période, vous devez de ne les télécharger qu'une seule fois dans le cache.

Il est important d'effectuer une mise en cache aussi agressive que possible afin de réduire la quantité totale la quantité de données que vous téléchargez. Mettez toujours en cache les ressources statiques, y compris des téléchargements à la demande, par exemple des images en taille réelle, pour une durée possible. Les ressources à la demande doivent être stockées séparément vider régulièrement votre cache à la demande pour gérer sa taille.

Pour vous assurer que votre mise en cache n'entraîne pas l'affichage de données obsolètes, utilisez les codes d'état HTTP et en-têtes, telles que ETag et Last-Modified en-têtes. Cela vous permet de déterminer quand le contenu associé doit être actualisées. Exemple :

Kotlin

// 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
}

Java

// 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;
}

Vous pouvez configurer certaines bibliothèques réseau pour qu'elles respectent ces codes d'état et automatiquement. Lorsque vous utilisez OkHttp, par exemple, pour configurer un répertoire de cache et une taille de cache pour le client permettra à la bibliothèque d'utiliser Mise en cache HTTP, comme illustré dans l'exemple de code suivant:

Kotlin

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

Java

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

Une fois le cache configuré, vous pouvez diffuser des requêtes HTTP entièrement mises en cache directement à partir d'un stockage local, ce qui élimine le besoin d'ouvrir une connexion réseau. Les réponses mises en cache de manière conditionnelle peuvent valider leur actualisation à partir du serveur. éliminant les coûts de bande passante associés au téléchargement. Réponses non mises en cache sont stockées dans le cache de réponses pour les futures requêtes.

Vous pouvez mettre en cache des données non sensibles dans le répertoire de cache externe non géré : avec Context.getExternalCacheDir() Vous pouvez également mettre en cache des données dans le cache de l'application gérée et sécurisée en avec Context.getCacheDir() Notez que ce cache interne peut être vidé lorsque l'espace disponible sur le système est insuffisant. l'espace de stockage disponible.

Remarque :Les fichiers stockés dans l'un ou l'autre des emplacements du cache sont effacés lorsque l'application est désinstallée.

Utiliser un dépôt

Pour une approche plus sophistiquée de la mise en cache, envisagez la conception du dépôt du modèle. Cela implique de créer une classe personnalisée, appelée Repository, qui fournit une abstraction de l'API sur des données ou des ressources spécifiques. Le dépôt peut initialement récupérer ses données à partir de différentes sources, comme un service Web distant, mais fournit aux appelants une version mise en cache des données lors des appels suivants. Ce d'indirection vous permet de fournir une stratégie de mise en cache efficace spécifiques à votre application. Pour en savoir plus sur l'utilisation du modèle de dépôt dans votre application, consultez le Guide to app architecture.