Restricciones del sistema cuando se trabaja en segundo plano

Los procesos en segundo plano pueden consumir mucha memoria y batería. Por ejemplo, un la transmisión implícita puede iniciar muchos procesos en segundo plano registrados en escucharla, incluso si esos procesos no brindan mucho trabajo. Puede tener un un impacto significativo en el rendimiento del dispositivo y la experiencia del usuario.

Para evitar restricciones del sistema, asegúrate de usar la API correcta para tu tarea en segundo plano. El La documentación de Descripción general de las tareas en segundo plano te ayuda a elegir la API adecuada para tus necesidades.

Restricciones iniciadas por el usuario

Si una app muestra comportamientos inadecuados que se describen en Android vitals, haz lo siguiente: el sistema solicita al usuario que restrinja el acceso de esa aplicación a los recursos del sistema.

Si el sistema detecta que una app está consumiendo recursos excesivos, al usuario y le da la opción de restringir las acciones de la aplicación. Entre los comportamientos que pueden activar la notificación, se incluyen los siguientes:

1. Bloqueos de activación excesivos: 1 bloqueo de activación parcial retenido durante una hora cuando la pantalla está desactivada
2. Exceso de servicios en segundo plano: Si la app está orientada a niveles de API inferiores al 26. y tiene demasiados servicios en segundo plano

Las restricciones precisas que se imponen son determinadas por el fabricante del dispositivo. Para por ejemplo, en compilaciones de AOSP, las apps restringidas no pueden ejecutar tareas, activar alarmas ni usar la red, excepto cuando la app está en primer plano.

Nota: Para evitar estas limitaciones y las advertencias asociadas, debes usar WorkManager para programar tus tareas en segundo plano

Restricciones para la recepción de emisiones de actividad de red

Las apps no reciben transmisiones de CONNECTIVITY_ACTION si se registran en recibirán en su manifiesto, y los procesos que dependen de esta transmisión no se inicia. Esto podría ser un problema para las apps que buscan detectar o realizar actividades de red masivas cuando el dispositivo se conecta a una red no medida. Hay varias soluciones para evadir esta restricción. existen en el framework de Android, pero elegir el correcto depende de lo que que quieres que tu app logre.

Nota: Un BroadcastReceiver registrado con Context.registerReceiver sigue recibiendo estas transmisiones mientras que la app se esté ejecutando.

Cómo programar el trabajo en conexiones de uso no medido

Cuando compiles un WorkRequest, agrega un 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)
}

Cuando se cumplan las condiciones para el trabajo, tu app recibirá una devolución de llamada para ejecutarse El método doWork() en la clase Worker especificada

Cómo supervisar la conectividad de red mientras se ejecuta la app

Las apps que están en ejecución pueden detectar CONNECTIVITY_CHANGE con una se registró: BroadcastReceiver. Sin embargo, la API de ConnectivityManager Proporciona un método más sólido para solicitar una devolución de llamada solo cuando se especifica la red. se cumplen las condiciones.

Los objetos NetworkRequest definen los parámetros de la devolución de llamada de red en condiciones de NetworkCapabilities. Creas objetos NetworkRequest con la clase NetworkRequest.Builder. registerNetworkCallback Luego, pasa el objeto NetworkRequest al sistema. Cuando se configura condiciones de servicio, la app recibe una devolución de llamada para ejecutar la onAvailable() definido en su ConnectivityManager.NetworkCallback.

La app continúa recibiendo devoluciones de llamada hasta que se cierra o llama unregisterNetworkCallback()

Restricciones para la recepción de emisiones de imagen y video

Las apps no pueden enviar ni recibir ACTION_NEW_PICTURE ni ACTION_NEW_VIDEO. Esta restricción ayuda a aliviar el rendimiento y la experiencia del usuario tiene un impacto en el momento en que varias apps deben activarse en orden para procesar una imagen o un video nuevos.

Cómo determinar qué autoridades de contenido activaron el trabajo

WorkerParameters permite que tu app reciba información útil sobre lo que Las autoridades de contenido y los URIs activaron el trabajo:

List<Uri> getTriggeredContentUris()

Muestra una lista de URI que activaron el trabajo. Este campo estará vacío si Ningún URI activó el trabajo (por ejemplo, porque el trabajo se activó debido a una fecha límite u otro motivo), o la cantidad de URI modificados es mayor que

List<String> getTriggeredContentAuthorities()

Muestra una lista de cadenas de autoridades de contenido que activaron el trabajo. Si la lista que se muestra no está vacía, usa getTriggeredContentUris() para recuperarla los detalles de qué URI cambiaron.

En el siguiente código de muestra, se anula el método CoroutineWorker.doWork(). y registra las autoridades de contenido y los URI que activaron el trabajo:

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()
    }
}

Cómo probar la app bajo restricciones del sistema

Optimizar tus apps para que se ejecuten en dispositivos con poca memoria o en condiciones de poca memoria mejorar el rendimiento y la experiencia del usuario. Eliminación de dependencias en segundo plano y los receptores de transmisiones implícitas registradas en manifiestos pueden ayudar funcionar mejor en esos dispositivos. Te recomendamos que optimices tu app para que se ejecute sin usar por completo estos procesos en segundo plano.

Algunos comandos adicionales de Android Debug Bridge (ADB) pueden ayudarte a probar la app con esos procesos en segundo plano inhabilitados:

• Para simular condiciones en las que se hacen transmisiones implícitas y servicios en segundo plano disponible, ingresa el siguiente comando:

  $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore

• Para volver a habilitar las transmisiones implícitas y los servicios en segundo plano, ingresa el siguiente código: :

  $ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow

Cómo optimizar aún más tu app

Para otras buenas formas de optimizar tus tareas en segundo plano el comportamiento de los usuarios, consulta Cómo optimizar el uso de batería para las APIs de programación de tareas en la documentación de Google Cloud.