Chargement de données, synchronisation de contenu, envoi d'analyses — de nombreuses tâches ne nécessitent pas la participation active de l'utilisateur. Cependant, les appareils mobiles limitent le travail en arrière-plan pour économiser la batterie et maintenir les performances. Les tâches en arrière-plan (background tasks) sont des mécanismes qui permettent à une application d'exécuter du code lorsque l'utilisateur ne la voit pas. Dans cet article, nous aborderons WorkManager, BGTaskScheduler, Foreground Service et les particularités de Doze Mode. Plus de détails dans la documentation officielle de WorkManager.
Points clés
Une tâche en arrière-plan est tout code exécuté lorsque l'application n'est pas au premier plan (écran actif). Cela peut inclure : la synchronisation périodique des données avec le serveur, le téléchargement de fichiers volumineux, le traitement des notifications push, le suivi de géolocalisation, la mise à jour des widgets. Chaque plateforme a ses propres restrictions sur le travail en arrière-plan : iOS est plus strict (10–30 minutes de temps d'arrière-plan), Android est plus indulgent mais a renforcé les règles depuis la version 9.
L'architecture des tâches en arrière-plan repose sur trois niveaux : (1) tâches immédiates — s'exécutent tout de suite (Foreground Service) ; (2) tâches différées — s'exécutent dans des conditions appropriées (WorkManager, BGTaskScheduler) ; (3) tâches périodiques — se répètent à intervalle défini. Choisir le bon niveau détermine si la tâche sera terminée à temps et si elle entraînera un refus de l'application sur l'App Store.
Sur les deux plateformes, Google/Apple recommandent fortement d'utiliser des API déclaratives plutôt que de gérer directement les threads en arrière-plan. WorkManager sur Android et BGTaskScheduler sur iOS permettent au système de répartir de manière optimale le travail en arrière-plan entre les applications, en regroupant les tâches pour économiser l'énergie. Chez IT Sectr, nous commençons toujours la conception de l'architecture d'arrière-plan en analysant les exigences de fréquence et d'urgence des mises à jour.
iOS fournit plusieurs mécanismes pour le travail en arrière-plan. Background Fetch — mise à jour périodique du contenu à un intervalle déterminé par le système (pas le développeur). L'application obtient une fenêtre d'environ 30 secondes pour télécharger de nouvelles données. Background Fetch s'active via Capabilities → Background Modes → Background Fetch et s'implémente dans AppDelegate : application(_:performFetchWithCompletionHandler:).
BGTaskScheduler est l'API moderne pour iOS 13+, remplaçant Background Fetch. Le développeur enregistre une tâche avec un identifiant, et le système l'exécute lorsque les conditions sont appropriées. BGAppRefreshTask — pour les mises à jour courtes de contenu ; BGProcessingTask — pour les tâches longues (nettoyage du cache, synchronisation de base de données). Les tâches sont enregistrées au lancement de l'application, et le système planifie leur exécution en tenant compte de l'état de la batterie, du réseau et de l'activité de l'utilisateur.
Background Modes — une liste de modes qui autorisent le travail en arrière-plan pour des scénarios spécifiques : Audio (lecture en arrière-plan), Location (GPS), VoIP (appels via PushKit), BLE (connexion à des appareils Bluetooth), Processing (tâches longues via BGTaskScheduler). Chaque mode nécessite une justification lors de la révision de l'App Store. Utiliser des modes sans besoin réel est une cause courante de rejet de l'application.
Significant Location Change — un mécanisme pour les applications qui n'ont pas besoin de géolocalisation constante mais doivent connaître les déplacements significatifs de l'utilisateur (plus de 500 mètres). Le système réveille l'application lors du changement de tour cellulaire. Ce mécanisme économise considérablement la batterie par rapport au GPS constant.
Android offre l'ensemble d'API le plus riche pour les tâches en arrière-plan, mais depuis la version 8.0 (API 26), les règles sont devenues plus strictes. WorkManager est la solution recommandée par Google pour tous les types de tâches en arrière-plan. WorkManager garantit l'exécution de la tâche même après un redémarrage de l'appareil (via BootReceiver) et prend en charge les chaînes de tâches, LiveData/Flow observables et la rétrocompatibilité jusqu'à API 14.
WorkManager utilise Worker — une classe de base avec la méthode doWork(). Constraints définit les conditions d'exécution : NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — pour les tâches périodiques avec un intervalle minimum de 15 minutes. WorkManager s'adapte automatiquement à Doze Mode et App Standby, regroupant les tâches en fenêtres de maintenance. Exemple d'un Worker simple :
class SyncWorker(
context: Context,
params: WorkerParameters
) : CoroutineWorker(context, params) {
override suspend fun doWork(): Result {
return try {
val repository =
Injection.provideRepository(applicationContext)
repository.syncData()
Result.success()
} catch (e: Exception) {
Result.retry()
}
}
}
// Запланировать задачу
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.build()
val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
.setConstraints(constraints)
.build()
WorkManager.getInstance(context)
.enqueue(syncRequest)
JobScheduler — une API plus ancienne (Android 5+, API 21). Elle planifie des tâches avec des conditions spécifiées (réseau, charge, inactivité). Limitation : elle ne prend pas en charge le redémarrage de l'appareil (nécessite BootReceiver) et n'a pas d'état observable. JobScheduler convient aux tâches simples dans les projets legacy ; pour les nouveaux projets, utilisez WorkManager.
Foreground Service — un service que l'utilisateur voit via une notification persistante (ongoing notification). Utilisé pour : la lecture de musique, le suivi GPS, le téléchargement de fichiers volumineux. Foreground Service a une priorité élevée — le système ne le tuera pas en cas de manque de mémoire. À partir d'Android 13, l'autorisation FOREGROUND_SERVICE_SPECIAL_USE est requise pour certains types. Une alternative est WorkManager avec ForegroundServiceOption (tâches longues).
AlarmManager — pour les tâches qui doivent s'exécuter à une heure exacte (alarme, rappel). AlarmManager peut réveiller l'appareil du Doze Mode (setAlarmClock). Déconseillé pour la synchronisation régulière en raison de la consommation énergétique élevée. Pour les tâches périodiques, utilisez WorkManager, et AlarmManager seulement lorsque l'heure exacte est critique.
| Scénario | iOS | Android |
|---|---|---|
| Mise à jour périodique du contenu | BGAppRefreshTask (BGTaskScheduler) | WorkManager (PeriodicWorkRequest) |
| Tâche longue en arrière-plan | BGProcessingTask | WorkManager + ForegroundService |
| Lecture audio | Background Audio Mode | Foreground Service |
| Suivi GPS | Significant Location Change / Background Location | Foreground Service + FusedLocationProvider |
| VoIP / Appels | PushKit + CallKit | ConnectionService + Foreground Service |
| Heure exacte (alarme) | UNNotificationRequest (calendar) | AlarmManager |
| Traitement push (arrière-plan) | Notification Service Extension | FirebaseMessagingService (onMessageReceived) |
Doze Mode est un mode d'économie d'énergie sous Android qui affecte l'exécution des tâches en arrière-plan. Introduit dans Android 6.0 (API 23). Lorsque l'appareil n'est pas en charge, l'écran est éteint et l'appareil est immobile, Doze Mode bloque les requêtes réseau, diffère JobScheduler et WakeLock. Périodiquement, Doze ouvre des fenêtres de maintenance — de courts intervalles pendant lesquels les applications peuvent exécuter des tâches différées. Depuis Android 7.0 (API 24), Doze s'active lorsque l'écran est éteint, pas seulement lorsqu'il est complètement immobile.
App Standby — un mode dans lequel les applications inutilisées sont mises en veille. Si une application n'a pas de notification active et n'a pas été ouverte depuis plusieurs jours, elle est placée dans un Standby Bucket : actif (active), working, frequent, rare. Moins l'application est utilisée, plus les restrictions sont strictes : les requêtes réseau sont différées, la synchronisation est bloquée, JobScheduler ne s'exécute pas.
WakeLock — un mécanisme qui maintient l'appareil éveillé (l'empêche de s'endormir). Utilisé pour terminer des opérations importantes. WakeLock doit être libéré après l'achèvement de la tâche, sinon la batterie se déchargera en quelques heures. WakeLock ne fonctionne pas en Doze Mode — le système l'ignore. Travailler avec WakeLock sous Android 8+ nécessite l'autorisation WAKE_LOCK et une gestion appropriée du cycle de vie.
Chez IT Sectr, nous prenons en compte Doze Mode et App Standby dès la phase de conception. WorkManager gère automatiquement ces modes, mais pour Foreground Service, il faut prévoir une gestion correcte des transitions vers Doze. Il est recommandé de tester le travail en arrière-plan sur des appareils réels avec le mode d'économie d'énergie activé et après des périodes d'inactivité prolongées.
Lors de la conception de tâches en arrière-plan, suivez ces conseils. 1. Utilisez toujours WorkManager pour les nouveaux projets Android. Il résout les problèmes de compatibilité, Doze Mode et redémarrage de l'appareil. 2. Sur iOS, préférez BGTaskScheduler à Background Fetch pour iOS 13+. 3. Utilisez Foreground Service uniquement lorsque la tâche nécessite vraiment une notification visible. 4. N'abusez pas de WakeLock — cela épuise la batterie et peut entraîner le rejet de l'application. 5. Testez les tâches en arrière-plan en Doze Mode : adb shell dumpsys deviceidle force-idle. 6. Vérifiez toujours l'achèvement de la tâche via la journalisation et les analyses. 7. Rappelez-vous des limites : iOS donne ~30 secondes pour Background Fetch et ~quelques minutes pour BGProcessingTask. Android WorkManager ne garantit pas un temps d'exécution exact.
Questions fréquentes
Background Service s'exécute sans notification visible et peut être tué par le système à tout moment. Foreground Service doit afficher une notification persistante (ongoing notification) et a une priorité plus élevée. Foreground Service est utilisé pour la lecture de musique et le suivi GPS.
Doze Mode est un mode d'économie d'énergie d'Android qui désactive l'accès réseau et diffère JobScheduler/WakeLock lorsque l'appareil n'est pas utilisé. WorkManager s'adapte automatiquement à Doze Mode.
Sur iOS, les tâches en arrière-plan s'exécutent via Background Fetch (mises à jour périodiques), BGTaskScheduler (tâches différées) ou Background Modes (audio, VoIP, BLE, localisation). BGTaskScheduler est l'API moderne pour iOS 13+, remplaçant Background Fetch.
WorkManager est la solution recommandée par Google pour toutes les tâches en arrière-plan sur Android. JobScheduler est une API plus ancienne aux capacités limitées. WorkManager prend en charge les chaînes de tâches, LiveData/Flow observables et la rétrocompatibilité jusqu'à API 14.
App Standby est un mode Android dans lequel les applications inutilisées sont mises en état de veille : les requêtes réseau sont différées, la synchronisation est suspendue. Si une application n'est pas utilisée pendant plusieurs jours, Android la place dans un Standby Bucket (active, working, frequent, rare).
Résumé
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.