Hemos lanzado una aplicación que se ejecuta en segundo plano y utiliza CoreBluetooth & CoreLocation para guardar automáticamente su ubicación de estacionamiento.Descarga de la batería al utilizar CoreLocation Monitorización de ubicación significativa y CoreBluetooth
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 de 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 una fuga significativa 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 supervisió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 se reprodujera el problema con las 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 & 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 frotado con solo estas dos aplicaciones CTM1 & 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 & 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 hay algún error de codificación que podría explicar para el drenaje por favor háganos saber.
Otra pregunta que tuvimos, si usamos ambos GPS & Monitoreo de ubicación significativo, ¿hay alguna razón para llamar al stopMonitoringSignificantLocationChanges? Mirando el código de muestra de Regions, llaman al stopMonitoringSignificantLocationChanges & startLocationUpdate al ingresar al primer plano y stopLocationUpdate & startMonitoringSignificantLocationChanges al ingresar el fondo, pero me pregunto si esto es necesario/recomendado/requerido.
Actualización:
Hemos confirmado con Apple desarrollador de Soporte Técnico para aplicaciones que utilizan tanto el GPS de seguimiento significativo & ubicación que nuestra secuencia de apagar significativo punto de vigilancia antes de activar la actualización del GPS es correcta.
También hemos confirmado que el problema de drenaje aún se puede ver en GM 5.1 & con una aplicación Recopilada Find My Car Smarter contra los Frameworks 5.1.
Actualización:
Parece que el problema se desencadena cuando nuestra aplicación se inicia desde el fondo en respuesta a un evento significativo lugar de vigilancia. 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á encendido.
En nuestra aplicación comprobamos si fuimos lanzados desde un segundo plano buscando el indicador UIApplicationLaunchOptionsLocationKey, si es así comenzamos a realizar una monitorización de ubicación significativa; de lo contrario, nos lanzamos en primer plano y comenzamos a actualizar la ubicación.
Apple nos respondió 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.
he vuelto a trabajar esto por lo que no sale como una publicidad de un producto velada. Preferiríamos que coloque sus detalles de contacto y enlaces a su aplicación en su perfil y derivar personas allí. – Kev
Hay un perfilador adecuado para el drenaje de la batería en Instruments. –
¡Eso es fantástico! – Kjuly