Tareas en segundo plano en desarrollo móvil: qué son, tipos y cómo funcionan

¿Qué son las tareas en segundo plano?

Una tarea en segundo plano es cualquier código que se ejecuta cuando la aplicación no está en primer plano (pantalla activa). Puede incluir: sincronización periódica de datos con el servidor, descarga de archivos grandes, procesamiento de notificaciones push, seguimiento de geolocalización, actualización de widgets. Cada plataforma tiene sus propias restricciones en el trabajo en segundo plano: iOS es más estricto (10–30 minutos de tiempo en segundo plano), Android es más flexible pero ha endurecido las reglas desde la versión 9.

La arquitectura de las tareas en segundo plano se basa en tres niveles: (1) tareas inmediatas — se ejecutan ahora mismo (Foreground Service); (2) tareas diferidas — se ejecutan cuando las condiciones son adecuadas (WorkManager, BGTaskScheduler); (3) tareas periódicas — se repiten en un intervalo determinado. Elegir el nivel correcto determina si la tarea se completará a tiempo y si provocará el rechazo de la aplicación en la tienda.

En ambas plataformas, Google/Apple recomiendan encarecidamente usar APIs declarativas en lugar de gestionar hilos directamente en segundo plano. WorkManager en Android y BGTaskScheduler en iOS permiten al sistema distribuir óptimamente el trabajo en segundo plano entre las aplicaciones, agrupando tareas para ahorrar energía. En IT Sectr, siempre comenzamos el diseño de la arquitectura en segundo plano analizando los requisitos de frecuencia y urgencia de las actualizaciones.

Tareas en segundo plano en iOS (Background Fetch, BGTaskScheduler)

iOS proporciona varios mecanismos para el trabajo en segundo plano. Background Fetch — actualización periódica de contenido con un intervalo determinado por el sistema (no por el desarrollador). La aplicación obtiene una ventana de ~30 segundos para descargar nuevos datos. Background Fetch se activa mediante Capabilities → Background Modes → Background Fetch y se implementa en AppDelegate: application(_:performFetchWithCompletionHandler:).

BGTaskScheduler es la API moderna para iOS 13+, que reemplaza Background Fetch. El desarrollador registra una tarea con un identificador, y el sistema la ejecuta cuando las condiciones son adecuadas. BGAppRefreshTask — para actualizaciones cortas de contenido; BGProcessingTask — para tareas largas (limpieza de caché, sincronización de base de datos). Las tareas se registran al iniciar la aplicación y el sistema programa su ejecución teniendo en cuenta el estado de la batería, la red y la actividad del usuario.

Background Modes — una lista de modos que permiten el trabajo en segundo plano para escenarios específicos: Audio (reproducción en segundo plano), Location (GPS), VoIP (llamadas mediante PushKit), BLE (conexión a dispositivos Bluetooth), Processing (tareas largas mediante BGTaskScheduler). Cada modo requiere justificación durante la revisión de App Store. Usar modos sin necesidad real es una causa común de rechazo de la aplicación.

Significant Location Change — un mecanismo para aplicaciones que no necesitan geolocalización constante pero necesitan saber sobre movimientos significativos del usuario (más de 500 metros). El sistema activa la aplicación cuando cambia la torre de telefonía móvil. Este mecanismo ahorra significativamente batería en comparación con el GPS constante.

Tareas en segundo plano en Android (WorkManager, JobScheduler, Foreground Service)

Android ofrece el conjunto más rico de APIs para tareas en segundo plano, pero desde la versión 8.0 (API 26), las reglas se han vuelto más estrictas. WorkManager es la solución recomendada por Google para todos los tipos de tareas en segundo plano. WorkManager garantiza la ejecución de la tarea incluso después de reiniciar el dispositivo (mediante BootReceiver) y admite cadenas de tareas, LiveData/Flow observables y compatibilidad con versiones anteriores hasta API 14.

WorkManager usa Worker — una clase base con el método doWork(). Constraints define las condiciones de ejecución: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow. PeriodicWorkRequest — para tareas periódicas con un intervalo mínimo de 15 minutos. WorkManager se adapta automáticamente a Doze Mode y App Standby, agrupando tareas en ventanas de mantenimiento. Ejemplo de 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 — una API más antigua (Android 5+, API 21). Programa tareas con condiciones especificadas (red, carga, inactividad). Limitación: no admite reinicio del dispositivo (necesita BootReceiver) y no tiene estado observable. JobScheduler es adecuado para tareas simples en proyectos heredados; para proyectos nuevos, use WorkManager.

Foreground Service — un servicio que el usuario ve a través de una notificación persistente (ongoing notification). Se usa para: reproducción de música, seguimiento GPS, descarga de archivos grandes. Foreground Service tiene alta prioridad — el sistema no lo matará cuando falte memoria. A partir de Android 13, se requiere el permiso FOREGROUND_SERVICE_SPECIAL_USE para algunos tipos. Una alternativa es WorkManager con ForegroundServiceOption (tareas largas).

AlarmManager — para tareas que deben ejecutarse a una hora exacta (alarma, recordatorio). AlarmManager puede despertar el dispositivo de Doze Mode (setAlarmClock). No se recomienda para sincronización regular debido al alto consumo de energía. Para tareas periódicas, use WorkManager, y AlarmManager solo cuando la hora exacta sea crítica.

Doze Mode y App Standby

Doze Mode es un modo de ahorro de energía en Android que afecta la ejecución de tareas en segundo plano. Introducido en Android 6.0 (API 23). Cuando el dispositivo no se está cargando, la pantalla está apagada y el dispositivo está inmóvil, Doze Mode bloquea las solicitudes de red, aplaza JobScheduler y WakeLock. Periódicamente, Doze abre ventanas de mantenimiento — intervalos cortos en los que las aplicaciones pueden ejecutar tareas diferidas. Desde Android 7.0 (API 24), Doze se activa cuando la pantalla está apagada, no solo cuando está completamente inmóvil.

App Standby — un modo en el que las aplicaciones no utilizadas se ponen en espera. Si una aplicación no tiene una notificación activa y no se ha abierto durante varios días, se coloca en un Standby Bucket: activo, working, frequent, rare. Cuanto menos se usa la aplicación, más estrictas son las restricciones: las solicitudes de red se aplazan, la sincronización se bloquea, JobScheduler no se ejecuta.

WakeLock — un mecanismo que mantiene el dispositivo despierto (evita que se duerma). Se usa para completar operaciones importantes. WakeLock debe liberarse después de completar la tarea, de lo contrario la batería se agotará en pocas horas. WakeLock no funciona en Doze Mode — el sistema lo ignora. Trabajar con WakeLock en Android 8+ requiere el permiso WAKE_LOCK y una gestión adecuada del ciclo de vida.

En IT Sectr, consideramos Doze Mode y App Standby en la etapa de diseño. WorkManager maneja automáticamente estos modos, pero para Foreground Service se debe prever el manejo correcto de las transiciones a Doze. Se recomienda probar el trabajo en segundo plano en dispositivos reales con el modo de ahorro de energía activado y después de períodos prolongados de inactividad.

Consejos prácticos

Al diseñar tareas en segundo plano, siga estos consejos. 1. Use siempre WorkManager para proyectos nuevos de Android. Resuelve problemas de compatibilidad, Doze Mode y reinicio del dispositivo. 2. En iOS, prefiera BGTaskScheduler en lugar de Background Fetch para iOS 13+. 3. Use Foreground Service solo cuando la tarea realmente requiera una notificación visible. 4. No abuse de WakeLock — agota la batería y puede provocar el rechazo de la aplicación. 5. Pruebe las tareas en segundo plano en Doze Mode: adb shell dumpsys deviceidle force-idle. 6. Siempre verifique la finalización de la tarea mediante registro y analíticas. 7. Recuerde los límites: iOS da ~30 segundos para Background Fetch y ~unos minutos para BGProcessingTask. Android WorkManager no garantiza el tiempo exacto de ejecución.