Boute à la batterie lors de l'utilisation de Corelocation Suivi de l'emplacement significatif et CoreBluetooth

Question

Nous avons publié une application qui s'exécute en arrière-plan et utilise CoreBluetooth & CoreLocation Pour économiser automatiquement votre lieu de stationnement.

À un niveau élevé, notre application recherche juste un CoreBluetooth Débranchez l'événement et allume le GPS jusqu'à ce que nous obtenions une solution de localisation (précision <= 10m) ou 3 minutes maximum (cela pourrait se produire lorsque vous vous garez dans un parking souterrain sans couverture GPS). Nous utilisons ensuite une surveillance importante de l'emplacement pour relancer automatiquement notre application en cas de système terminant notre application.

Au cours de notre développement, nous n'avons jamais vu un problème de vidange de la batterie nous-mêmes, mais 75% de nos utilisateurs disent qu'ils voient une fuite importante de la batterie. 10% de nos bailleurs de fonds ont répondu au sondage, il est donc difficile de déterminer à quel point la ventilation est représentative, mais c'est un grand pourcentage de nos utilisateurs. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=30

Nous avons ensuite publié une mise à jour qui a permis aux utilisateurs de désactiver une surveillance importante de l'emplacement et 60% disent qu'en désactivant la surveillance importante de l'emplacement, le drain disparaît. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=42

Initialement, nous n'avons pas pu reproduire le problème de drainage, mais nous avons constaté que lorsque nous avons installé une application simple qui a allumé une surveillance importante de l'emplacement en conjonction avec trouver ma voiture plus intelligente, nous avons vu le drain reproduire par intermittence. Dans l'état de drainage, le téléphone n'entre pas d'hibernate. Ceci est indiqué par le temps d'utilisation (Paramètres-> Utilisation-> Temps depuis la dernière charge complète) Continue à augmenter même si le téléphone avait été endormi et que l'affichage est désactivé. Quelque chose empêche le système d'entrer Hibernate. La batterie s'écoule environ 15% par heure à ce stade. Ce drain apparaît par intermittence et semble s'éclaircir après une heure ou deux et revenir au hasard. Nous n'avons pas trouvé de moyen de reproduire le drain.

Nous pensons que le problème est causé par plusieurs clients appelant à CoreLocation. Nous avons demandé à quelques utilisateurs qui ont connu le problème pour essuyer leur téléphone et installer uniquement notre application de recherche plus intelligente. Seul avec juste cette application installée, le drain n'a pas exposé. Nous avons eu d'autres rapports selon lesquels notre application est utilisée avec Google Latitude ou Facebook, etc., c'est quand ils voient le drain. Ou s'ils vont tuer d'autres applications, le drain disparaît. Nous avons vu le drain persister à travers un cycle de puissance, sans aucune application lancée. Cela implique qu'il doit être un service au niveau du système qui empêche le système d'exploitation de dormir.

Même si nous pensons que le problème est causé par une condition raciale de plusieurs clients appelant à CoreLocation, nous n'avons jamais vu le problème se reproduire avec des applications qui n'utilisaient que CoreLocation. Nous avons même créé 4 ou 5 applications différentes qui accéderaient simultanément à CoreLocation et nous n'avons pas vu le drain se produire. Nous avons cependant vu le problème lorsque nous avions une application avec CoreLocation et une deuxième application avec Corelocation + CoreBluetooth. Il y a probablement très peu d'applications qui utilisent la combinaison Corelocation + CoreBluetooth, donc c'est potentiellement pourquoi plus de développeurs n'ont pas touché ce problème. Bien que nous soyons à perte d'expliquer comment Corelocation et CoreBluetooth interagissent pour provoquer ce drain et comment la deuxième application avec Corelocation entre dans l'équation. Étant donné que le drain a été intermittent, il est possible que ce soit juste un coup de chance que le problème ne s'est produit que lorsque nous testions avec Corelocation + CoreBluetooth.

Sur un iPhone 4s essuyé 5.0.1 avec seulement ces deux applications CTM1 et FMC installées, nous avons pu entrer par intermittence à l'état de drainage. Fait intéressant, le problème de drain semblait se produire beaucoup moins fréquemment sur un appareil essuyé, puis notre appareil normal. Malheureusement, nous n'avons vu l'état de drainage que quelques fois et sans pouvoir reproduire de manière fiable le drain, nous n'avons pas un bon état de contrôle pour travailler.

Nous avons déposé un rapport de bogue avec Apple et ouvert un incident de support technique, mais peut-être que la communauté Stackover peut également fournir un aperçu. Nous avons vu ce problème à la fois en 5.0.1 et en 5.1 Beta 3.

Ctm1http://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

FMChttp://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 vous voyez des erreurs de codage qui pourraient expliquer le drain, veuillez nous le faire savoir.

Une autre question que nous avions, si nous utilisons à la fois un GPS et une surveillance importante de l'emplacement, est-ce une raison d'appeler stopMonitoringSignificantLocationChanges? En regardant l'exemple de code des régions qu'ils appellent stopMonitoringSignificantLocationChanges & startLocationUpdate En entrant au premier plan et stopLocationUpdate & startMonitoringSignificantLocationChanges En entrant dans les antécédents, mais je me demande si cela est nécessaire / recommandé / requis?

Mise à jour:

Nous avons confirmé avec le support technique du développeur Apple que pour les applications utilisant à la fois le GPS et la surveillance de l'emplacement significative que notre séquence de désactivation de la surveillance de l'emplacement significative avant d'activer la mise à jour GPS est correcte.

Nous avons également confirmé que le problème de drainage peut encore être vu dans le GM 5.1 et avec une application de récompilation de récompilation de ma voiture contre les frameworks 5.1.

Mise à jour:

Il semble que le problème soit déclenché lorsque notre application est lancée à partir de l'arrière-plan en réponse à un événement de surveillance de localisation important. En fait, nous ne gérons pas correctement ce scénario dans notre exemple de code, mais nous le faisons dans notre application réelle.

Dans l'exemple de code, sur une relance d'arrière-plan, nous allons activer la mise à jour de l'emplacement et comme il n'y a pas d'appel ApplicationDidenerBackground, le GPS sera laissé.

Dans notre application, nous vérifions si nous avons été lancés à partir de l'arrière-plan en recherchant le drapeau UIApplicationLaunchOptionsLocationKey, si c'est le cas, nous commençons une surveillance importante de l'emplacement, sinon nous avons été lancés au premier plan et nous commençons à mettre à jour l'emplacement.

Apple est revenu vers nous et a déclaré que l'utilisation d'une surveillance importante de l'emplacement ne nécessite pas l'emplacement défini dans le tableau UIBackgroundModes dans le PLIST Info.plist. Nous avons supprimé cette entrée et il semble que l'état de vidange de la batterie ne soit plus touché. Nous avons encore Bluetooth-Central dans la liste UibackgroundModes. Pour le moment, nous ne savons pas pourquoi cela aide. Nous allons exécuter d'autres expériences pour nous aider à mieux comprendre cela. Si quelqu'un a des suggestions, veuillez nous le faire savoir.

Answer 1

À la fin de la journée, la suggestion d'Apple de retirer l'emplacement d'UibackgroundModes a résolu notre problème de vidange de la batterie.

Afin d'obtenir encore des emplacements en arrière-plan, nous avons dû envelopper le [locationManager startLocationUpdates] & [locationManager stopLocationUpdates] appels avec:

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

Answer 2

Vous pouvez déboguer l'état de l'application en utilisant tout son de signal répétitif. Assurez-vous simplement que vous n'avez pas mis «Plays Audio» dans les exigences des modes d'arrière-plan pour ce test. Si votre application fonctionne - vous entendrez que cette application sonne même en arrière-plan. Si l'application est suspendue - vous n'entendrez rien. Il s'agit probablement d'une méthode la plus simple pour détecter que l'application n'est pas correctement suspendue.

L'utilisation de Profiler pour le débogage de ce problème est problématique car beaucoup de choses fonctionnent en mode de débogage lorsque l'appareil connecté à l'ordinateur. Surtout des choses sauvant de puissance.

Assurez-vous également de tout faire correctement en réponse à des changements d'emplacement importants. Si vous démarrez les mises à jour de l'emplacement - assurez-vous d'avoir réglé de la minuterie (pendant 3 minutes, par exemple), qui arrête les mises à jour de l'emplacement. Quoi qu'il en soit, l'iOS tuera votre application, même si elle a commencé les mises à jour de l'emplacement de la réponse aux modifications d'emplacement importantes. Peu importe ce que vous avez commencé en réponse - l'application sera tuée en 10 minutes si elle est toujours en cours d'exécution - faites attention aux journaux des accidents - un tel événement y sera enregistré.

De plus, vérifiez tous vos code et Libs tiers - peut-être que certains d'entre eux deviennent GPS et l'utilisent pour quelque chose. Principalement paranoïaque, mais peut se produire à des fins de ciblage analytique et publicitaire.

Answer 3

Les applications compatibles CoreLocation sont généralement faites pour le mode d'arrière-plan, de sorte qu'il peut fonctionner en arrière-plan, il est certainement utilisé plus de batterie, car ma suggestion essaie toujours d'arrêter le service de localisation alors qu'il n'est pas nécessaire.

LocationManager StopUpdatingLocation];

Ensuite, selon vos besoins, alors commencez en conséquence,

Merci