ios - tiempo - Descarga de la batería cuando se usa CoreLocation Monitorización de ubicación significativa y CoreBluetooth

duracion bateria airpods chinos

Question

Hemos lanzado una aplicación que se ejecuta en segundo plano y utiliza CoreBluetooth y CoreLocation para guardar automáticamente su ubicación de estacionamiento.

En un nivel alto nuestra aplicación solo busca un evento de desconexión CoreBluetooth y enciende el GPS hasta que obtengamos una corrección de ubicación (precisión <= 10m) o 3 minutos de tiempo máximo (esto podría ocurrir cuando estaciona en un estacionamiento subterráneo sin cobertura GPS ) A continuación, utilizamos la Supervisión de ubicación significativa para volver a iniciar automáticamente nuestra aplicación en caso de que el sistema finalice nuestra aplicación.

Durante nuestro desarrollo, nunca vimos un problema de pérdida de batería, sin embargo, el 75% de nuestros usuarios dice que ve un agotamiento significativo de la batería. El 10% de nuestros patrocinadores respondieron a la encuesta, por lo que es difícil determinar qué tan representativo es el colapso, pero es un gran porcentaje de nuestros usuarios. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=30

Luego lanzamos una actualización que permitía a los usuarios desactivar la monitorización de ubicación significativa y el 60% dice que al deshabilitar la monitorización de ubicación significativa, el drenaje desaparece. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=42

Inicialmente no pudimos duplicar el problema del drenaje nosotros mismos, pero descubrimos que cuando instalamos una aplicación sencilla que acababa de activar el Monitoreo de ubicación significativo junto con Encontrar mi coche más inteligente, intermitentemente vimos cómo se reproducía el desagüe. En el estado de drenaje, el teléfono no ingresa hibernate. Esto se indica mediante el tiempo de uso en (Configuraciones-> Uso-> Tiempo desde la última carga completa) que continúa incrementándose aunque el teléfono se haya puesto en reposo y la pantalla apagada. Algo impide que el sistema entre en hibernación. La batería drena aproximadamente 15% por hora en esta etapa. Este drenaje aparece intermitentemente y parece desaparecer después de una o dos horas y volver a aparecer al azar. No hemos encontrado una manera de reproducir el drenaje de forma confiable.

Creemos que el problema se debe a que varios clientes llaman a CoreLocation. Le pedimos a algunos usuarios que experimentaron el problema que borren su teléfono y solo instalen nuestra aplicación Find My Car Smarter. Solo con solo esta aplicación instalada, el dren no se exhibió. Hemos tenido otros informes de que cuando nuestra aplicación se usa con Google Latitude o Facebook, etc. es cuando ven que ocurre el desagüe. O si van y matan a otras aplicaciones, el drenaje desaparece. Hemos visto el drenaje persistir a través de un ciclo de encendido, sin aplicaciones iniciadas. Esto implica que tiene que ser un servicio de nivel de sistema que impida que el sistema operativo duerma.

Aunque creemos que el problema se debe a alguna condición de carrera de varios clientes que llaman a CoreLocation, nunca vimos que el problema se reprodujera con aplicaciones que solo usaban CoreLocation. Incluso creamos 4 o 5 aplicaciones diferentes que accederían simultáneamente a CoreLocation y no vimos la fuga. Sin embargo, vimos el problema cuando teníamos una aplicación con CoreLocation y una segunda aplicación con CoreLocation + CoreBluetooth. Probablemente haya muy pocas aplicaciones que utilicen la combinación CoreLocation + CoreBluetooth, por lo que es posible que esa sea la razón por la que más desarrolladores no han solucionado este problema. Aunque no podemos explicar cómo CoreLocation y CoreBluetooth interactúan para causar esta fuga y cómo la segunda aplicación con CoreLocation entra en la ecuación. Como la fuga fue intermitente, es posible que solo sea un golpe de suerte que el problema solo ocurrió cuando estábamos probando con CoreLocation + CoreBluetooth.

En un 5.0.1 iPhone 4S borrado con solo estas dos aplicaciones CTM1 y FMC instaladas, pudimos entrar intermitentemente en el estado de drenaje. Curiosamente, el problema del drenaje pareció ocurrir con mucha menos frecuencia en un dispositivo borrado que en nuestro dispositivo normal. Desafortunadamente, solo vimos el estado de drenaje unas cuantas veces y, sin poder reproducir de manera confiable el drenaje, no tenemos un buen estado de control para trabajar.

Hemos presentado un informe de error con Apple y abrimos un Incidente de soporte técnico, pero tal vez la comunidad de Stackover también puede brindar alguna información. Hemos visto este problema tanto en 5.0.1 como en 5.1 Beta 3.

CTM1 http://www.findmycarsmarter.com/files/CTM1.zip

On Going into the Background
    [locationManager stopUpdatingLocation];
    [locationManager stopUpdatingHeading];
    [locationManager startMonitoringSignificantLocationChanges];

On Re-entering Foreground
    [locationManager stopMonitoringSignificantLocationChanges];
    [locationManager startUpdatingLocation];
    [locationManager startUpdatingHeading];
On didUpdateToLocation
    //do nothing
On didUpdateHeading
    //do nothing

FMC http://www.findmycarsmarter.com/files/FMC.zip

On Going into the Background
    [btleManager stopScan];
    [locationManager stopUpdatingLocation];
    [locationManager stopUpdatingHeading];
    [locationManager startMonitoringSignificantLocationChanges];

On Re-entering Foreground
    [locationManager stopMonitoringSignificantLocationChanges];
    [locationManager startUpdatingLocation];
    [locationManager startUpdatingHeading];        
    [btleManager scanForPeripheralsWithServices:nil options:nil];
On didUpdateToLocation
    //do nothing
On didUpdateHeading
    //do nothing
On centralManagerDidUpdateState
    [btleManager scanForPeripheralsWithServices:nil options:nil];
On didDiscoverPeripheral
    [btleManager connectPeripheral:device options:nil];
On didConnectPeripheral
    //update log
On didDisconnectPeripheral
    //initiate reconnect
    [btleManager connectPeripheral:device options:nil];

Si ve algún error de codificación que pueda explicar el drenaje, avísenos.

Otra pregunta que tuvimos, si estamos usando GPS y Monitoreo de Ubicación Significativo, ¿hay alguna razón para llamar stopMonitoringSignificantLocationChanges ? Al mirar el código de muestra de Regions llaman stopMonitoringSignificantLocationChanges & startLocationUpdate al ingresar a primer plano y stopLocationUpdate & startMonitoringSignificantLocationChanges al ingresar el fondo, pero me pregunto si esto es necesario / recomendado / requerido.

Actualizar:

Hemos confirmado con el Soporte técnico para desarrolladores de Apple que, para las aplicaciones que utilizan GPS y Monitoreo de ubicación importante, nuestra secuencia de desactivación del Monitoreo de ubicación significativo antes de permitir la actualización del GPS es correcta.

También confirmamos que el problema del drenaje aún se puede ver en GM 5.1 y con una aplicación compilada Recopilar mi coche más inteligente contra los Frameworks 5.1.

Actualizar:

Parece que el problema se desencadena cuando nuestra aplicación se inicia desde el fondo en respuesta a un evento de Monitorización de ubicación significativa. En realidad, no manejamos este escenario correctamente en nuestro código de muestra, pero lo hacemos en nuestra aplicación real.

En el código de muestra, en un relanzamiento de fondo, activaremos la actualización de ubicación y, dado que no hay una llamada a applicationDidEnterBackground, el GPS se dejará activado.

En nuestra aplicación, verificamos si fuimos lanzados desde un segundo plano buscando el indicador UIApplicationLaunchOptionsLocationKey, si es así, comenzamos el Monitoreo de Ubicación Significativo; de lo contrario, nos lanzamos en primer plano y comenzamos a Actualizar la Ubicación.

Apple volvió a nosotros y afirmó que el uso de la supervisión de ubicación significativa no requiere la ubicación establecida en la matriz UIBackgroundModes en Info.plist. Eliminamos esta entrada y parece que el estado de agotamiento de la batería ya no se activa. Todavía tenemos bluetooth-central en la lista UIBackgroundModes. Por el momento no tenemos claro por qué esto ayuda. Vamos a ejecutar algunos experimentos más para ayudarnos a entender esto mejor. Si alguien tiene alguna sugerencia por favor háganos saber.

Answer 1

Al final del día, la sugerencia de Apple de eliminar la ubicación de UIBackgroundModes solucionó el problema de pérdida de batería.

Para poder obtener ubicaciones en segundo plano, tuvimos que ajustar las [locationManager startLocationUpdates] y [locationManager stopLocationUpdates] con:

[[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler];
[[UIApplication sharedApplication] endBackgroundTask:];

Answer 2

Las aplicaciones habilitadas para CoreLocation generalmente están hechas para el modo en segundo plano, por lo que pueden ejecutarse en segundo plano, sin duda requieren más batería, ya que mi sugerencia es intentar detener el servicio de ubicación cuando no sea necesario.

[locationManager stopUpdatingLocation];

luego, de acuerdo con su requerimiento, comience en consecuencia,

Gracias

Answer 3

Puede depurar el estado de la aplicación usando cualquier señal repetitiva. Solo asegúrate de no poner "reproduce audio" en los requisitos de los modos de fondo para esta prueba. Si su aplicación está en ejecución, escuchará que esta aplicación incluso suena en segundo plano. Si la aplicación está suspendida, no escuchará nada. Este es probablemente el método más simple para detectar que la aplicación no se ha suspendido correctamente.

Usar Profiler para la depuración de este problema es problemático porque muchas cosas funcionan de manera diferente en el modo de depuración cuando el dispositivo está conectado a la computadora. Especialmente cosas de ahorro de energía.

Además, asegúrese de hacer todo lo correcto en respuesta a los cambios de ubicación significativos. Si inicia actualizaciones de ubicación, asegúrese de haber configurado algún temporizador (por ejemplo, 3 minutos) que apague las actualizaciones de ubicación. De todos modos, el iOS matará su aplicación, incluso comenzó las actualizaciones de ubicación de la respuesta a los cambios de ubicación significativos. No importa lo que hayas comenzado en respuesta: la aplicación se eliminará en 10 minutos si todavía está ejecutándose; presta atención a los registros de fallos; dicho evento se registrará allí.

Además, verifique todos los códigos y libs de terceros: quizás algunos de ellos giren el GPS y lo utilicen para algunas cosas. Mayormente paranoico, pero puede ocurrir con objetivos analíticos y publicitarios.