Restrictions système concernant les tâches en arrière-plan

Les processus en arrière-plan peuvent utiliser beaucoup de mémoire et de batterie. Par exemple, un une diffusion implicite peut démarrer de nombreux processus en arrière-plan enregistrés dans écoutez-les, même si ces processus peuvent ne pas faire beaucoup de travail. Cela peut avoir un un impact important sur les performances des appareils et sur l'expérience utilisateur.

Pour éviter les restrictions du système, assurez-vous d'utiliser l'API adaptée à votre une tâche en arrière-plan. La la documentation Présentation des tâches en arrière-plan vous aide à choisir l'API adaptée à vos besoins.

Restrictions initiées par l'utilisateur

Si une application présente certains des comportements insatisfaisants décrits dans Android Vitals : le système invite l'utilisateur à limiter l'accès de cette application aux ressources système.

Si le système remarque qu'une application consomme trop de ressources, il en informe l'utilisateur et lui donne la possibilité de limiter les actions de l'application. Cette notification peut apparaître dans les cas suivants :

  1. Nombre excessif de wakelocks: un wakelock partiel est maintenu pendant une heure lorsque l'écran est désactivé
  2. Nombre excessif de services d'arrière-plan: si l'application cible des niveaux d'API inférieurs à 26 et utilise trop de services en arrière-plan

Les restrictions précises imposées sont déterminées par le fabricant de l'appareil. Pour Par exemple, sur les builds AOSP, les applications dont l'accès est limité ne peuvent pas exécuter de jobs, déclencher d'alarmes ni utiliser sur le réseau, sauf lorsque l'application est exécutée au premier plan.

Restrictions concernant la réception d'annonces d'activité réseau

Les applications ne reçoivent pas d'annonces CONNECTIVITY_ACTION si elles s'inscrivent sur les recevoir dans leur fichier manifeste, ainsi que les processus qui dépendent de cette diffusion ne démarre pas. Cela peut poser problème pour les applications qui souhaitent écouter le réseau ou d'effectuer des opérations groupées sur le réseau lorsque l'appareil se connecte un réseau illimité. Plusieurs solutions existent déjà pour contourner cette restriction existent dans le framework Android, mais le choix du modèle dépend que votre application accomplit.

Planifier des tâches sur des connexions sans compteur

Lorsque vous créez une WorkRequest, ajoutez un élément NetworkType.UNMETERED Constraint.

fun scheduleWork(context: Context) {
    val workManager = WorkManager.getInstance(context)
    val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
       .setConstraints(
           Constraints.Builder()
               .setRequiredNetworkType(NetworkType.UNMETERED)
               .build()
           )
       .build()

    workManager.enqueue(workRequest)
}

Lorsque les conditions de votre tâche sont remplies, votre application reçoit un rappel pour s'exécuter la méthode doWork() dans la classe Worker spécifiée.

Surveiller la connectivité réseau pendant l'exécution de l'application

Les applis en cours d'exécution peuvent toujours écouter CONNECTIVITY_CHANGE avec une enregistré le BroadcastReceiver. Cependant, l'API ConnectivityManager fournit une méthode plus robuste pour demander un rappel uniquement lorsque le réseau spécifié sont remplies.

Les objets NetworkRequest définissent les paramètres du rappel réseau dans conditions d'utilisation de NetworkCapabilities. Vous créez des objets NetworkRequest. avec la classe NetworkRequest.Builder. registerNetworkCallback puis transmet l'objet NetworkRequest au système. Lorsque le réseau si les conditions sont remplies, l'application reçoit un rappel pour exécuter La méthode onAvailable() définie dans ses ConnectivityManager.NetworkCallback.

L'application continue de recevoir des rappels jusqu'à ce qu'elle se ferme ou qu'elle appelle unregisterNetworkCallback().

Restrictions concernant la réception d'annonces images et vidéos

Les applications ne peuvent pas envoyer ni recevoir ACTION_NEW_PICTURE ou ACTION_NEW_VIDEO : diffusions. Cette restriction permet d'atténuer sur les performances et l'expérience utilisateur, qui ont un impact sur le déclenchement de plusieurs applications pour traiter une nouvelle image ou vidéo.

Déterminer les autorités de contenu à l'origine des opérations

WorkerParameters permet à votre application de recevoir des informations utiles sur les éléments les autorités de contenu et les URI ont déclenché la tâche:

List<Uri> getTriggeredContentUris()

Renvoie la liste des URI ayant déclenché la tâche. Ce champ est vide si Soit aucun URI n'a déclenché la tâche (par exemple, la tâche a été déclenchée en raison d'une un délai ou pour une autre raison) ou si le nombre d'URI modifiés est supérieur à 50.

List<String> getTriggeredContentAuthorities()

Affiche une liste de chaînes d'autorités de contenu ayant déclenché la tâche. Si la liste renvoyée n'est pas vide, utilisez getTriggeredContentUris() pour récupérer les détails des URI modifiés.

L'exemple de code suivant remplace la méthode CoroutineWorker.doWork() et enregistre les autorités de contenu et les URI ayant déclenché la tâche:

class MyWorker(
    appContext: Context,
    params: WorkerParameters
): CoroutineWorker(appContext, params)
    override suspend fun doWork(): Result {
        StringBuilder().apply {
            append("Media content has changed:\n")
            params.triggeredContentAuthorities
                .takeIf { it.isNotEmpty() }
                ?.let { authorities ->
                    append("Authorities: ${authorities.joinToString(", ")}\n")
                    append(params.triggeredContentUris.joinToString("\n"))
                } ?: append("(No content)")
            Log.i(TAG, toString())
        }
        return Result.success()
    }
}

Tester l'application avec des restrictions du système

Optimiser vos applications pour qu'elles s'exécutent sur des appareils ou dans des conditions de faible mémoire peut améliorer les performances et l'expérience utilisateur. Supprimer les dépendances en arrière-plan et les broadcast receivers implicites enregistrés dans le fichier manifeste peuvent aider votre application fonctionnent mieux sur ces appareils. Nous vous recommandons d'optimiser votre application pour qu'elle s'exécute sans utiliser complètement ces processus en arrière-plan.

Certaines commandes Android Debug Bridge (ADB) supplémentaires peuvent vous aider à tester l'application comportement lorsque ces processus en arrière-plan sont désactivés:

  • Simuler des conditions dans lesquelles les diffusions implicites et les services d'arrière-plan sont non disponible, saisissez la commande suivante:

    $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore

  • Pour réactiver les diffusions implicites et les services d'arrière-plan, saisissez la commande suivante : :

    $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow

Optimisez encore votre application

D'autres moyens efficaces d'optimiser vos tâches en arrière-plan comportement, consultez les API Optimiser l'utilisation de la batterie pour la planification des tâches. dans la documentation Google Cloud.