Nous avons publié une application qui s'exécute en arrière-plan et utilise CoreBluetooth & CoreLocation pour enregistrer automatiquement votre emplacement de stationnement.
À un haut niveau de notre application semble juste pour un CoreBluetooth déconnecter de l'événement et allume le GPS jusqu'à ce que nous obtenir une position gps (précision <=10 m) ou 3 minutes max de temps (cela peut se produire lorsque vous vous garez dans un parking souterrain avec aucune couverture GPS). Nous utilisons alors le Lieu Significatif de Surveillance automatiquement re-lancement de notre application dans le cas du système de terminaison de notre application.
Au cours de notre développement, nous n'avons jamais vu un drain de batterie de question de nous-mêmes, cependant, 75% de nos utilisateurs disent qu'ils voient une importante consommation de la batterie. 10% de nos bailleurs de fonds ont répondu au sondage de sorte qu'il est difficile de déterminer la représentativité de la rupture, mais c'est un grand pourcentage de nos utilisateurs. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=30
Ensuite, nous avons publié une mise à jour qui permet aux utilisateurs de désactiver Lieu Significatif de Surveillance et de 60% affirment qu'en désactivant Lieu Significatif de Surveillance de la vidange s'en va. http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=42
Au départ, nous ne pouvions pas dupliquer le drain problème nous-mêmes, mais nous avons constaté que lorsque nous avons installé une application simple qui vient d'avoir sur l'importance de la Localisation de Surveillance en collaboration avec Trouver Ma Voiture plus Intelligente, nous avons par intermittence vu le drain se reproduire. Dans le drain de l'état le téléphone ne pas entrer en veille prolongée. Ceci est indiqué par la durée d'utilisation (Paramètres->Utilisation->Temps écoulé depuis la dernière charge complète) continue d'augmenter même si le téléphone avait été mis en veille et l'écran est éteint. Quelque chose empêche le système de saisie de mise en veille prolongée. La batterie se vide d'environ 15% par heure dans ce stade. Ce drain montre de façon intermittente et semble disparaître de lui-même au bout d'une heure ou deux et reviens au hasard. Nous n'avons pas trouvé un moyen de la fiabilité de reproduire le drain.
Nous pensons que le problème est causé par plusieurs clients à remettre en CoreLocation. Nous avons demandé à quelques utilisateurs qui ont vécu la question pour effacer le contenu de leur téléphone et n'installer que notre Trouver Ma Voiture plus Intelligente app. Seule avec cette application installée, le drain ne présentent pas de. Nous avons eu d'autres rapports que quand notre application est utilisée avec Google Latitude ou Facebook, etc, c'est quand ils voient le drain se produire. Ou si ils vont tuer d'autres applications, la vidange s'en va. Nous avons vu le drain persistent à travers un cycle d'alimentation, sans applications lancées. Ce qui implique qu'il a un système de niveau de service qui empêche les OS de dormir.
Même si nous pensons que le problème est provoqué par certaines condition de course de plusieurs clients appeler en CoreLocation, nous n'avons jamais vu la question à reproduire avec les applications que seulement utilisé CoreLocation. Nous avons même créé 4 ou 5 différentes applications simultanément accès CoreLocation et nous n'avons pas vu le drain se produire. Nous n'avons cependant voir le problème quand on a une application avec CoreLocation et une seconde application avec CoreLocation + CoreBluetooth. Il y a probablement très peu d'applications qui utilisent le CoreLocation + CoreBluetooth combinaison, donc potentiellement c'est pourquoi de plus en plus les développeurs n'ont pas touché par ce problème. Bien que nous sommes à une perte d'expliquer comment CoreLocation & CoreBluetooth interagissent pour provoquer ce drain et comment la seconde application avec CoreLocation vient dans l'équation. Depuis le drain a été intermittent, c'est possible que c'est juste un coup de chance que le problème ne s'est passé quand nous étions en essais avec CoreLocation + CoreBluetooth.
Sur une essuyé 5.0.1 iPhone 4S avec seulement ces deux applications CTM1 & FMC installé, nous avons pu par intermittence entrer dans le drain de l'état. Fait intéressant, le drain problème semble se produire moins fréquemment sur une essuyé appareil, puis notre normal de l'appareil. Malheureusement, nous n'avons vu la vidange de l'état d'un peu de temps et sans être en mesure de reproduire de manière fiable le drain nous n'avons pas un bon contrôle de l'état de travailler à partir.
Nous avons déposé un rapport de bug avec Apple et a ouvert un Incident de Support Technique, mais peut-être que le Stackover de la communauté peut également donner un aperçu. Nous avons vu ce problème à la fois en 5.0.1 et 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 vous voyez des erreurs de codage, pour la vidange s'il vous plaît laissez-nous savoir.
Une autre question nous a, si nous utilisons à la fois le GPS et le Lieu Significatif de Surveillance, est-il une raison d'appeler à l' stopMonitoringSignificantLocationChanges? En regardant les Régions l'échantillon de code qu'ils appellent stopMonitoringSignificantLocationChanges & startLocationUpdate sur l'entrée de premier plan et d' stopLocationUpdate & startMonitoringSignificantLocationChanges sur l'entrée d'arrière-plan, mais je me demandais si cela est nécessaire/recommandé/nécessaire?
Mise à jour:
Nous avons confirmé avec des Développeurs d'Apple Support Technique pour les applications utilisant à la fois le GPS et le Lieu Significatif de Surveillance de notre séquence de désactivation du Lieu Significatif de Surveillance avant d'activer le GPS de mise à jour est correcte.
Nous avons également confirmé que le drain question peut encore être vu dans le GM 5.1 et avec une re-compilation de Trouver Ma Voiture plus Intelligente de la demande à l'encontre de l'5.1 Cadres.
Mise à jour:
Il semble que la question est déclenché lorsque notre application est lancée à partir de l'arrière-plan en réponse à un Lieu Significatif de Surveillance de l'événement. Nous ne gérons pas ce scénario correctement dans notre exemple de code, mais nous le faisons dans notre application réelle.
Dans l'exemple de code, sur un arrière-plan de relance, nous allons tourner sur l'emplacement de mise à jour et depuis il n'y a pas un applicationDidEnterBackground appel, le GPS ne sera laissé sur.
Dans notre application, nous allons vérifier si nous avons été lancé à partir de l'arrière-plan par la recherche de la UIApplicationLaunchOptionsLocationkey drapeau, si nous commençons donc Important l'Emplacement de la Surveillance, sinon nous avons été lancé en premier plan et nous commençons la mise à Jour de Localisation.
Apple a obtenu de nouveau à nous, et a déclaré que l'utilisation d'un Lieu Significatif de Surveillance ne nécessite pas l'emplacement défini dans UIBackgroundModes tableau dans l'Info.plist. Nous avons retiré de cette entrée, et il semble que le drainage de la batterie de l'état n'est plus frappé. Nous avons encore bluetooth-central, dans la UIBackgroundModes liste. Pour le moment nous sommes pas pourquoi cette aide. Nous allons être en cours d'exécution peu plus d'expériences pour nous aider à mieux comprendre ce processus. Si quelqu'un a des suggestions s'il vous plaît laissez-nous savoir.
