Drenaje de la batería al usar CoreLocation Monitoreo de Ubicación significativa y CoreBluetooth

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

A un alto nivel, 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

Durante nuestro desarrollo nunca vimos un problema de drenaje de la batería nosotros mismos, sin embargo, el 75% de nuestros usuarios dicen que ven un drenaje 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 desglose, 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 deshabilitar la ubicación significativa Monitoreo y el 60% dice que al deshabilitar el Monitoreo 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 simple que solo activaba el Monitoreo de Ubicación Significativo junto con Find My Car Smarter, vimos intermitentemente que el drenaje se reproducía. En el estado de drenaje el teléfono no entra en hibernación. Esto está indicado por el tiempo de uso en (Configuración- > Uso- > Tiempo desde la última carga completa) continúa aumentando a pesar de que el teléfono se había puesto en reposo y la pantalla está apagada. Algo impide que el sistema entre en hibernación. La batería se agota alrededor del 15% por hora en esta etapa. Este drenaje aparece intermitentemente y parece despejarse después de una hora o dos y volver al azar. No hemos encontrado una manera de reproducir la fiabilidad del drenaje.

Creemos que el problema es causado por múltiples clientes llamando a CoreLocation. Pedimos a algunos usuarios que experimentaron el problema que limpiaran su teléfono y solo instalaran nuestra aplicación Find My Car Smarter. Solo con solo esta aplicación instalada, el drenaje no exhibió. Hemos tenido otros informes que cuando nuestra aplicación se utiliza con Google Latitude o Facebook, etc es cuando ven que se produce el drenaje. O si van y matan otras aplicaciones, el desagüe desaparece. Hemos visto que el drenaje persiste a través de un ciclo de energía, sin aplicaciones lanzadas. Esto implica que tiene ser un servicio a nivel de sistema que impide que el sistema operativo duerma.

Aunque creemos que el problema es causado por 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 accedían simultáneamente a CoreLocation y no vimos que se produjera el drenaje. Sin embargo, vimos el problema cuando teníamos una aplicación con CoreLocation y una segunda aplicación con CoreLocation + CoreBluetooth. Probablemente hay muy pocas aplicaciones que utilizan la combinación CoreLocation + CoreBluetooth, por lo que potencialmente es por eso que más desarrolladores no han golpeado este problema. Aunque estamos en una pérdida para explicar cómo CoreLocation & CoreBluetooth interactúan para causar este drenaje y cómo la segunda aplicación con CoreLocation entra en la ecuación. Dado que el drenaje era intermitente, es posible que sea solo una casualidad que el problema solo ocurriera cuando estábamos probando con CoreLocation + CoreBluetooth.

En un borrado 5.0.1 iPhone 4S con solo estas dos aplicaciones CTM1 y FMC instaladas pudimos entrar intermitentemente en el estado de drenaje. Curiosamente, el problema del drenaje parecía ocurrir con mucha menos frecuencia en un dispositivo borrado que en nuestro dispositivo normal. Desafortunadamente, solo vimos el estado del drenaje unas pocas 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 abierto un Incidente de Soporte Técnico, pero tal vez el La comunidad Stackover también puede proporcionar 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, háganoslo saber.

Otra pregunta que tuvimos, si estamos usando tanto GPS como Monitoreo de Ubicación Significativo, es que hay una razón para llamar stopMonitoringSignificantLocationChanges? Mirando el código de ejemplo de las Regiones que llaman stopMonitoringSignificantLocationChanges & startLocationUpdate al entrar en primer plano y stopLocationUpdate & startMonitoringSignificantLocationChanges al ingresar el fondo, pero me pregunto si esto es necesario/recomendado/requerido?

Actualización:

Hemos confirmado con el Soporte Técnico del Desarrollador de Apple que para las aplicaciones que usan GPS y Monitoreo de Ubicación Significativa, nuestra secuencia de desactivar el Monitoreo de Ubicación Significativa antes de habilitar la actualización de GPS es correcta.

, también Hemos confirmado que el el problema de drenaje todavía se puede ver en el GM 5.1 y con una aplicación Find My Car Smarter recompilada contra los marcos 5.1.

Actualización:

Parece que el problema se desencadena cuando nuestra aplicación se inicia en segundo plano en respuesta a un evento de Monitoreo de Ubicación Significativo. En realidad no manejamos este escenario correctamente en nuestro código de ejemplo, pero lo hacemos en nuestra aplicación real.

En el código de ejemplo, en un relanzamiento en segundo plano activaremos la actualización de ubicación y desde allí no es una solicitud de identificación de llamada de fondo, el GPS se dejará encendido.

En nuestra aplicación comprobamos si nos lanzaron desde el fondo buscando la bandera UIApplicationLaunchOptionsLocationKey, si es así, comenzamos a Monitorear la Ubicación Significativa, de lo contrario, nos lanzaron en primer plano y comenzamos a actualizar la ubicación.

Apple nos respondió y declaró que el uso de Monitoreo de Ubicación Significativa no requiere la ubicación establecida en UIBackgroundModes array en el INFO.plist. Eliminamos esta entrada y parece que el estado de drenaje de la batería ya no se golpea. Todavía tenemos bluetooth-central en la lista de UIBackgroundModes. Por el momento no tenemos claro por qué esto ayuda. Vamos a hacer más experimentos para ayudarnos a entender esto mejor. Si alguien tiene alguna sugerencia por favor háganoslo saber.