Lag dans le développement mobile : définition, causes et méthodes de résolution

Qu'est-ce que le lag dans le développement mobile

Le lag dans une application mobile est un retard subjectivement perceptible entre l'action de l'utilisateur (toucher, balayage, saisie de texte) et la réponse de l'interface. Techniquement, le lag se mesure comme le temps entre l'événement d'entrée et le rendu complet de l'image : le seuil confortable est jusqu'à 100 ms, perceptible à partir de 200 ms, critique au-delà de 500 ms.

Différence entre lag, bug et lenteur

Dans la terminologie utilisateur, « lag » et « lenteur » sont souvent utilisés comme synonymes, mais techniquement le lag est un retard fixe (ex. 300 ms à chaque toucher), tandis que « lenteur » est un ralentissement intermittent : l'application fonctionne fluidement puis se fige pendant une seconde. Un bug, contrairement au lag, n'est pas lié à la vitesse mais à la correction de l'affichage.

Impact du lag sur les métriques de l'application

Google Play et l'App Store prennent en compte les métriques de performance lors du classement des applications. Le taux d'ANR, la fréquence de jank et le temps de démarrage affectent la visibilité dans la recherche et la conversion d'installation. Une application avec un lag persistant perd jusqu'à 40 % des utilisateurs après le premier lancement.

Causes du lag et des ralentissements dans les applications

Le lag se produit lorsque le thread principal d'UI ne parvient pas à traiter les images à 60 FPS (16,6 ms par image) ou 120 FPS (8,3 ms). Examinons les principales sources de ralentissements.

Blocage du thread principal

Toute opération synchrone dans le thread UI — lecture de SharedPreferences, travail avec une base de données via Room sans suspend, décodage d'une image en Bitmap — bloque le rendu de l'image. Sur Android, cela provoque du jank, sur iOS, un retard du rendu Core Animation.

Fuites mémoire et pauses GC fréquentes

Lorsque le ramasse-miettes sur Android ou ARC sur iOS libère de la mémoire, tous les threads sont suspendus. Des pauses GC fréquentes surviennent lors de la création de nombreux objets temporaires — par exemple, créer une nouvelle instance de ViewHolder à chaque appel d'adaptateur. Cela se manifeste par un défilement saccadé.

Hiérarchies de layout lourdes

Des ConstraintLayout imbriqués, de multiples LinearLayout, des Views qui se chevauchent — chaque niveau d'imbrication augmente le temps de mesure et de layout pass. Xcode indique qu'une hiérarchie de couches profonde (plus de 10 niveaux) provoque une chute de FPS de 20 à 30 %.

• Android — requestLayout excessif, chaînes ConstraintLayout inefficaces, grand Bitmap sans downscale
• iOS — contraintes Auto Layout avec conflits, CALayer lourd, shadowPath sans rastérisation
• Multiplateforme — appels HTTP synchrones dans le thread UI, parsing JSON lourd, images sous-optimales haute résolution

Comment diagnostiquer les ralentissements de performance

Pour identifier les causes du lag, on utilise des profileurs intégrés aux IDE et des outils de surveillance système. Chaque outil résout sa propre tâche.

CPU Profiler dans Android Studio

CPU Profiler montre quelles méthodes consomment du temps CPU et dans quels threads elles s'exécutent. Si une méthode de calcul lourd s'exécute dans le thread principal — c'est la cause racine. L'enregistrement d'une trace avec sample Java Method activé permet de voir la pile d'appels à tout moment et de trouver les points chauds.

Time Profiler dans Xcode Instruments

L'outil équivalent pour iOS — Time Profiler — collecte des échantillons de pile chaque milliseconde et montre quel pourcentage de temps CPU chaque méthode consomme. Combiné avec le drapeau Main Thread Only, il filtre uniquement les opérations du thread principal, pointant directement vers les sources de lag.

Network Profiler et analyse des requêtes

Les requêtes réseau lentes créent l'impression de lag même si le thread UI n'est pas bloqué. Network Profiler dans Android Studio et Network Link Conditioner dans Xcode permettent de simuler des connexions lentes et d'identifier comment l'application se comporte dans des conditions réelles. Les réponses fragmentées sans progression et les gros payloads JSON sont des sources typiques de lag apparent.

Exemple de profilage d'une requête réseau avec OkHttp avec mesure de temps :

class TimingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val start = System.nanoTime()
        val response = chain.proceed(chain.request())
        val duration = (System.nanoTime() - start) / 1_000_000
        Log.d("Timing", "Request took $duration ms")
        return response
    }
}

Méthodes pour résoudre le lag sur Android et iOS

Résoudre le lag nécessite un travail systématique : de l'optimisation d'une seule méthode aux changements architecturaux. Examinons les techniques les plus efficaces.

Traitement asynchrone avec coroutines et GCD

Kotlin Coroutines avec Dispatchers.IO pour les requêtes réseau et Dispatchers.Default pour les calculs garantissent que le thread principal reste libre pour l'UI. Sur iOS, Grand Central Dispatch avec queue .global(qos: .userInitiated) pour les tâches d'arrière-plan et .main pour les mises à jour de l'UI est l'approche standard. Évitez les opérations sync entre les files d'attente.

Optimisation des adaptateurs et listes

RecyclerView sur Android et UICollectionView sur iOS nécessitent une configuration correcte : ViewHolder avec création minimale d'objets dans onBindViewHolder, DiffUtil pour le calcul des changements, prefetching pour le chargement anticipé des données. Sur iOS, utilisez diffable data source pour des mises à jour animées sans gestion manuelle.

Mise en cache des données et images

Charger la même image à chaque défilement est un lag garanti. Coil (Android) et Kingfisher (iOS) mettent en cache les images en mémoire et sur disque, assurant un affichage instantané lors de requêtes répétées. Pour les données, utilisez Room avec une couche de cache basée sur Flow ou Combine.

Exemple de configuration du cache d'images avec Coil sur Android :

val imageLoader = ImageLoader(context) {
    memoryCachePolicy(CachePolicy.ENABLED)
    diskCachePolicy(CachePolicy.ENABLED)
    crossfade(true)
    size(512, 512)
}

// Loading with auto-caching enabled
imageView.load("https://example.com/image.jpg") {
    placeholder(R.drawable.placeholder)
    error(R.drawable.error)
}

Prévention du lag en phase de développement

Prévenir le lag est moins coûteux que de le corriger en production. Les mesures préventives sont intégrées au processus de développement au niveau des outils et de l'architecture.

StrictMode sur Android

StrictMode est un outil intégré d'Android qui détecte les opérations d'E/S accidentelles et les appels réseau sur le thread principal pendant le développement. Activez-le dans Application.onCreate avec une politique penaltyDeath pour les violations critiques. C'est le seul moyen de garantir que le développeur voit le problème avant le commit.

Main Thread Checker sur iOS

L'équivalent iOS — Main Thread Checker dans Xcode, faisant partie de Runtime Sanitization — vérifie automatiquement que tous les appels UIKit et AppKit s'exécutent sur le thread principal. Activez-le dans le schéma de build Debug et visez zéro avertissement dans le CI.

Benchmarks de performance dans le CI

Ajoutez des exécutions de Macrobenchmark (Android) et XCTMetrics (iOS) à votre pipeline CI pour mesurer le temps de démarrage, le FPS de défilement et l'utilisation mémoire. Définissez des seuils : si un nouveau commit augmente le temps de démarrage de plus de 5 % — le build échoue.

• Android — Macrobenchmark, Baseline Profiles, Jetpack Benchmark Library
• iOS — XCTMetrics, os_signpost, MetricKit pour collecter des métriques depuis les appareils des utilisateurs
• Approche générale — profilage avant et après chaque changement significatif, tests de régression de performance