• slidebg1

iOS, Mejorar el consumo energético en el uso del GPS


Es importante saber que los servicios de localización del GPS (del inglés Global Positioning System) y WiFi requieren de un consumo intenso de la batería.

Según Wikipedia, GPS es un sistema para determinar la posición de un objeto sobre la tierra. Una variante de este sistema es el GPS diferencial que permite localizar un objeto con una precisión de centímetros, cuando el sistema habitual utilizado por los dispositivos con esta tecnología tiene una precisión de unos pocos metros. Este sistema de posicionamiento tiene un total de 24 satélites alrededor de la tierra, posicionados a 20 200km de altura sobre el nivel del mar.

El cálculo de la localización del usuario mediante GPS depende principalmente de dos factores:

Tiempo. Cada transmisión de GPS es única y se genera con un número pseudo-aleatorio de 1023-bit cada milisegundo, con un ratio de datos de 1024 Mbps. El chip receptor de GPS debe alinearse correctamente con el tiempo actual del satélite.

Frecuencia. El receptor GPS debe calcular cualquier señal relativa al movimiento entre el satélite y el receptor.

Enlazar de manera completamente correcta con el satélite tarda aproximadamente 30 segundos, y la localización se obtiene por cualquier satélite que se encuentre en el rango del receptor. Cuantos más satélites se encuentren en este rango, más exacta será la localización.

Calcular la posición de esta manera requiere de un uso intenso de la CPU y del GPS, cuando ambos trabajan juntos pueden consumir la batería muy rápidamente.

NOTA: Las siguientes buenas prácticas han sido inspiradas por las utilizadas en el libro de Vaish[1].

 

Buenas prácticas

 

Para entender la complejidad de la localización del GPS, veremos cómo hay que utilizarlo pero con cuidado, particularmente si se desea desarrollar una aplicación plenamente basada en mapas.

Figura 13: Inicialización y obtención de la posición del usuario en Swift

A continuación se mostrarán qué buenas prácticas hay que seguir para minimizar el consumo energético en lenguaje Swift.

Como se puede observar en la figura 13, hay dos parámetros que tienen un papel muy importante cuando se llama a startUpDatingLocation:

distanceFilter

El filtro de distancia hará que el manejador notifique al delegado acerca de los eventos locationManager:didUpdateLocations sólo si el dispositivo se ha movido una distancia mínima. La distancia es representada en unidades del SI (metros). Esto no ayudará a reducir el consumo del GPS, pero reducirá indirectamente el consumo de la CPU ya que salvo que la distancia entre la primera toma de posición y la última sean superiores al filtro indicado, esta última posición no será procesada completamente.

desiredAccuracy

El parámetro de la precisión tiene un impacto directo en el número de antenas que se utilizan, y con ello en el consumo de la batería. Se debe elegir un nivel de precisión basado en las necesidades de la aplicación. La precisión de la señal, se define con las siguientes constantes:

kCLLocationAccuracyBestForNavigation

Se trata del mejor nivel de precisión para usos de navegación.

kCLLocationAccuracyBest

Es el mejor nivel de precisión para un dispositivo.

Figura 14: Obtener ubicación de manera poco precisa en Swift 

kCLLocationAccuracyNearestTenMeters

Precisión de hasta 10 metros. Se utiliza cuando no es necesario conocer cada metro recorrido por el usuario.

kCLLocationAccuracyHundredMeters

Precisión de hasta 100 metros.

kCLLocationAccuracyKilometer

Precisión de hasta 1000 metros. Útil cuando se desea calcular la distancia aproximada entre dos puntos que pueden estar a cientos de kilómetros de distancia.

kCLLocationAccuracyThreeKilometers

Precisión de hasta 3000 metros.

 

SOLICITAR ACTUALIZACIONES DE UBICACIÓN RÁPIDA

 

Si la aplicación no requiere de una ubicación demasiado exacta, es mejor llamar al método requestLocation del objeto del locationManager. De este modo, se detendrán automáticamente los servicios de ubicación una vez que se haya cumplido la solicitud, dejando el hardware de posicionamiento GPS apagado si no se utiliza en otro lugar. Las actualizaciones de ubicación solicitadas de esta manera se entregan mediante una devolución de llamada al método locationManager:didUpdateLocations:, que debe implementar la aplicación (Figura 14).

 

ES IMPORTANTE MANTENER APAGADAS AQUELLAS FUNCIONALIDADES QUE NO SE UTILIZAN

 

Es importante decidir cuándo se necesita realizar el seguimiento de los cambios de ubicación. Invocar a startUpdatingLocation cuando sea necesario realizar un seguimiento y stopUpdatingLocation para detenerlo cuando no sea necesario. Ambos métodos provenientes del CLLocationManager ya vienen implementados en la librería MapKit de Swift.

Un ejemplo podría ser una aplicación como iMessages (chat nativo en iOS), que permite compartir la ubicación con otros usuarios. Para compartir la ubicación podrían existir dos opciones:

Enviar la situación actual del usuario, obtener la posición actual e inmediatamente desactivar los servicios de posicionamiento.

Compartir la posición durante un periodo de tiempo mediante una corta monitorización del usuario (velocidad, dirección…). Se podría prever cada qué periodo de tiempo sería necesario obtener la posición del usuario; así evita el uso constante del GPS.

El seguimiento de la ubicación debería desactivarse si la aplicación no está en primer plano o si el usuario no está utilizándola.

Una solución aún mejor es dar al usuario final una opción para desactivar características no esenciales. Por ejemplo, la conocida aplicación de mapas colaborativos Waze que ofrece la opción de desactivar todas las actividades de la aplicación si el usuario no está utilizando la aplicación.

UTILIZAR LA RED SÓLO SI ES ESENCIAL.

Por eficiencia energética, iOS desactiva el hardware de red tanto como sea posible. Cuando una aplicación necesita establecer una conexión de red, iOS aprovechará esta oportunidad para permitir que las aplicaciones de fondo compartan esta sesión de red, de modo que puedan procesarse los eventos de baja prioridad, como notificaciones push, recuperación de correo electrónico, etc.

El resultado es que siempre que la aplicación se conecta a la red, el hardware de red permanecerá activo durante varios segundos después de que la aplicación termine con la conexión. Cada una de estas ráfagas de tráfico de red puede consumir un punto porcentual completo de duración de la batería.

Para minimizar este problema, el software necesita hacer un uso más económico de la red. Debería tratar de procesar el acceso a la red en ráfagas periódicas en lugar de un flujo de datos continuamente activo para que el hardware de red se pueda desactivar.

 

SERVICIOS DE UBICACIÓN EN SEGUNDO PLANO

 

En Swift, CLLocationManager proporciona un método alternativo para escuchar las actualizaciones de ubicación. StartMonitoringSignificantLocationChanges ayuda a seguir el movimiento para distancias más largas. El valor exacto se determina internamente y es independiente del filtro de distancia.

En la figura 16 se realiza un seguimiento del movimiento cuando la aplicación entre en segundo plano.Un comportamiento típico sería utilizar startMonitoringSignificantLocationChanges cuando la aplicación está en segundo plano (applicationDidEnterBackground) y startUpdatingLocation cuando va a estar en primer plano (applicationWillEnterForeground).

Figura 16: Control de la monitorización según el estado de la aplicación en Swift 

 

USO DE TIMERS, THREADS Y SERVICIOS DE UBICACIÓN

 

Los timers o threads se suspenden cuando se pone la aplicación en suspensión. Pero si se ha solicitado que la ubicación se actualice cuando la aplicación está en segundo plano, esta se despertará durante un tiempo infinitesimal cada vez que se recibe datos nuevos. Durante este corto periodo, los threads y timers también cobrarán vida nuevamente.

El peor de los casos sería si se realiza cualquier operación de red durante ese periodo, ya que esto además activará todas las antenas relacionadas con la carga de datos (es decir, WiFi, LTE / 4G / 3G).

 

REINICIAR DESPUÉS DE QUE LA APLICACIÓN HAYA SIDO FINALIZADA

 

Por último, pero no por ello menos importante, es posible que la aplicación se destruya si se realiza en segundo plano y otra aplicación necesita recursos. Si ese es el caso, cada vez que ocurre un cambio de ubicación se reiniciará la aplicación, pero tendrá que volver a iniciar la supervisión (Figura 17)

Figura 17: Reinicio de monitorización si la aplicación es finalizada en Swift

 

Referencias [1] Varish, Gaurav (2016). High Performance iOS Apps. — Recuperado de: http://shop.oreilly.com/ product/0636920034506.do

Públicado el 04/10/2017

Comparte este post: