Batería y red: el coste energético de lo que no se ve

De todos los recursos que administra una aplicación, la energía es el único que el usuario percibe con retraso, sin poder atribuirlo y con una capacidad de rencor notable. Nadie nota el instante en que una app enciende la radio celular por tercera vez en un minuto, ni el momento en que un servicio de ubicación de alta precisión empieza a alimentar el receptor de satélite de forma continua; lo que se nota es que el teléfono está caliente a media tarde y que el porcentaje de batería baja más rápido de lo normal, y el sistema ofrece una pantalla que atribuye ese consumo a una app concreta con nombre y apellidos. Ese diferimiento entre causa y efecto explica por qué el consumo energético es el problema de rendimiento peor gestionado del ecosistema: no rompe nada, no aparece en ninguna prueba, no genera un informe de fallo, y sin embargo es una de las razones más citadas para desinstalar. La buena noticia es que su física es sencilla y sus causas dominantes son pocas.

La cola de la radio y por qué el patrón manda

La energía es potencia multiplicada por tiempo, y en un teléfono la potencia de cada subsistema no es constante sino que sigue una máquina de estados con histéresis. La radio celular es el ejemplo canónico y el más contraintuitivo. Encenderla desde reposo cuesta bastante energía y bastante latencia, de modo que para no pagar ese arranque en cada paquete el modem no vuelve a reposo en cuanto termina una transferencia: permanece en un estado de alta potencia durante unos segundos, luego desciende a un estado intermedio, y solo después de un intervalo que ronda las decenas de segundos regresa a reposo. Ese periodo de descenso se conoce como la cola de la radio, y durante él tu app consume energía sin transferir absolutamente nada.

La consecuencia es que el coste energético de una petición no es proporcional a los bytes que mueve sino, en buena medida, a que exista. Doce peticiones pequeñas separadas por veinte segundos cada una mantienen la radio despierta durante minutos enteros y pueden costar mucho más que una única transferencia veinte veces mayor. Formulado como principio de diseño: agrupar y diferir vence a reducir. La red inalámbrica local tiene una máquina de estados análoga, con potencias menores pero la misma forma, y por eso la conclusión se mantiene con independencia del medio.

flowchart LR
A[Reposo, potencia minima] --> B[Encendido, coste alto]
B --> C[Transferencia activa]
C --> D[Cola de alta potencia sin datos]
D --> E[Estado intermedio]
E --> A
F[Peticion nueva durante la cola] --> C

De ahí nacen las herramientas del sistema pensadas exactamente para este problema. Una sesión discrecional permite declarar que la transferencia no es urgente y ceder al sistema la decisión de cuándo ejecutarla, con lo que se agrupa con la actividad de otros procesos y se aprovecha una radio ya encendida. La espera por conectividad evita el patrón de reintentos periódicos que mantiene el modem activo sin lograr nada. Y las banderas de red cara y de red restringida permiten respetar las decisiones del usuario sobre datos móviles y modo de datos reducidos en lugar de ignorarlas.

let configuracion = URLSessionConfiguration.background(withIdentifier: "com.ejemplo.sync")
configuracion.isDiscretionary = true              // el sistema elige el momento oportuno
configuracion.waitsForConnectivity = true          // en lugar de fallar y reintentar en bucle
configuracion.allowsExpensiveNetworkAccess = false // respeta datos moviles caros
configuracion.allowsConstrainedNetworkAccess = false // respeta el modo de datos reducidos
configuracion.sessionSendsLaunchEvents = true

La ubicación, el recurso más caro del catálogo

Ningún otro servicio del sistema tiene un rango de coste tan amplio ni tan mal comprendido. Pedir la máxima precisión posible mantiene activo el receptor de satélite de forma continua, y ese subsistema es, con diferencia, el mayor consumidor individual que una app puede activar; sostenerlo durante una sesión larga produce el tipo de consumo que el usuario atribuye correctamente y castiga. En el extremo opuesto, la monitorización de cambios significativos se apoya en la infraestructura celular que el teléfono ya está usando para funcionar, y su coste marginal es prácticamente nulo.

La regla de ingeniería que se deduce es que la precisión debe pedirse como función de la tarea en curso y renegociarse cuando la tarea cambia, en lugar de configurarse una vez al arrancar. Una app de reparto necesita precisión alta mientras hay una entrega activa y cambios significativos el resto del día; una de comercio necesita precisión reducida una sola vez y nada más. Además, desde que el sistema permite al usuario conceder ubicación aproximada, pedir precisión completa cuando no hace falta no solo gasta batería sino que fuerza una petición de permiso que muchos usuarios rechazan, con lo que la función acaba deshabilitada por completo. El coste energético y el coste de privacidad apuntan aquí en la misma dirección.

Trabajo en segundo plano como negociación

El sistema no ejecuta tu tarea de fondo cuando tú quieres, sino cuando le conviene al conjunto, y decide con un modelo que aprende de la conducta del usuario: a qué horas abre tu app, con qué frecuencia, si el dispositivo está cargando, si hay red inalámbrica, cuál es el estado térmico y si el modo de bajo consumo está activo. Presentado así, el diseño correcto deja de ser una cuestión de intervalos y pasa a ser una cuestión de declaración de intenciones.

import BackgroundTasks

// Refresco corto y frecuente: actualizar contenido ligero
let refresco = BGAppRefreshTaskRequest(identifier: "com.ejemplo.refresco")
refresco.earliestBeginDate = Date(timeIntervalSinceNow: 3600)

// Procesamiento largo: mantenimiento, indexado, limpieza
let proceso = BGProcessingTaskRequest(identifier: "com.ejemplo.mantenimiento")
proceso.requiresNetworkConnectivity = false
proceso.requiresExternalPower = true   // el sistema lo ejecutara mientras carga

try? BGTaskScheduler.shared.submit(refresco)
try? BGTaskScheduler.shared.submit(proceso)

Dos detalles distinguen una implementación robusta de una que se abandona. El primero es el manejador de expiración: el sistema concede un presupuesto de tiempo acotado y, si se agota, exige que la tarea se detenga de inmediato; no hacerlo cuenta como incumplimiento y penaliza la planificación futura. El segundo es la idempotencia: como el instante de ejecución es impredecible y la tarea puede interrumpirse a medias, el trabajo tiene que poder repetirse sin duplicar efectos.

Hay además una decisión de diseño previa que ahorra más energía que cualquier ajuste: preguntarse si la tarea de fondo debe existir. Una parte considerable del trabajo que las apps programan en segundo plano existe para que el contenido esté fresco en el instante improbable en que el usuario abra la app, y su valor real es que la pantalla inicial aparezca poblada medio segundo antes. Comparado con el coste de despertar el proceso, encender la radio y sincronizar varias veces al día durante meses, ese beneficio rara vez sale a cuenta. La alternativa honesta suele ser cargar al abrir, mostrando lo que hay en cache mientras llega lo nuevo.

Conviene además leer el contexto antes de decidir cuánto trabajo hacer. El modo de bajo consumo es una declaración explícita del usuario de que prefiere autonomía a funcionalidad, y respetarlo significa reducir la frecuencia de sincronización, desactivar la precarga especulativa y bajar la precisión de ubicación. El estado térmico es la señal complementaria: cuando el sistema entra en niveles serios de calentamiento ya está limitando la frecuencia del procesador, y seguir empujando trabajo solo empeora el rendimiento de todo el dispositivo.

let info = ProcessInfo.processInfo
if info.isLowPowerModeEnabled || info.thermalState == .serious {
    sincronizador.reducirCadencia()
    precarga.desactivar()
}

Medir energía sin un vatímetro

La objeción habitual es que el consumo no se puede medir sin instrumentación de hardware, y es falsa desde hace años. MetricKit entrega a diario tres familias de datos que bastan para gobernar el dominio: tiempo de CPU acumulado, bytes transferidos en celular y en red inalámbrica separados por dirección, y tiempo de actividad de ubicación desglosado por escala de precisión. Esa última métrica es especialmente reveladora porque suele destapar que una app pasa horas al día con precisión alta activa sin que nadie del equipo lo supiera.

import MetricKit

func didReceive(_ payloads: [MXMetricPayload]) {
    for carga in payloads {
        registrar(cpu: carga.cpuMetrics?.cumulativeCPUTime)
        registrar(red: carga.networkTransferMetrics?.cumulativeCellularUpload)
        registrar(ubicacion: carga.locationActivityMetrics?.cumulativeBestAccuracyTime)
    }
}

En desarrollo, el medidor de energía de Xcode ofrece una lectura relativa e inmediata mientras se usa la app, y el registro energético de Instruments desglosa por subsistema con suficiente resolución para atribuir un pico a la radio, a la ubicación o al procesador. Y el organizador de Xcode agrega en producción el consumo y la escritura en disco por versión, que es la vista adecuada para detectar la regresión que introdujo una función nueva.

Merece una mención aparte esa última métrica, la escritura en disco, porque suele sorprender que aparezca en un panel de consumo. La memoria flash de un teléfono gasta energía al escribir mucho más que al leer, y además el sistema de archivos con registro por diario multiplica cada escritura pequeña por su contabilidad asociada. Una app que persiste el estado en cada pulsación, que registra telemetría con una escritura por evento o que reconstruye su cache en disco a cada rato aparece en ese panel sin haber tocado la radio ni la ubicación. El remedio es el mismo principio de agrupación que rige la red: acumular en memoria y volcar por lotes, con un volcado forzado al pasar a segundo plano para no perder datos.