我们发布了一个在后台运行的应用程序，该应用程序使用CoreBluetooth和CoreLocation自动保存您的 parking 位置。
在较高的级别上，我们的应用程序仅查找CoreBluetooth断开事件并打开GPS，直到获得定位信息(精度
在我们的开发过程中，我们从未遇到过电池耗电的问题，但是有75％的用户说他们看到了严重的电池耗电。我们有10％的支持者对民意调查做出了回应，因此很难确定细分的代表性，但这是我们用户的很大一部分。 http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=30
然后，我们发布了一个更新，该更新允许用户禁用“重要位置监视”，并且有60％的用户说，通过禁用“重要位置监视”可以消除浪费。 http://www.findmycarsmarter.com/forum/viewtopic.php?f=4&t=42
最初，我们无法自己复制排水问题，但是发现当我们安装了一个简单的应用程序并与“查找我的汽车更智能”功能一起启用了“重要位置监控”时，我们会间歇地看到排水现象。在耗尽状态下，电话不会进入休眠状态。即使手机已进入睡眠状态且显示屏已关闭，使用时间(设置->使用情况->上一次充满电后的时间)中的使用时间也会继续增加，以表明这一点。某些原因阻止系统进入休眠状态。在此阶段，电池每小时大约消耗15％的电量。排水管间歇性地出现，一两个小时后似乎会自行清除，然后再随机出现。我们还没有找到一种可靠的方法来消除这种浪费。
我们认为此问题是由多个客户端调用CoreLocation引起的。我们要求遇到此问题的一些用户删除手机，仅安装我们的“查找我的汽车更智能”应用程序。仅安装了此应用程序的用户就不会出现流失。我们还有其他报告说，当我们的应用程序与Google Latitude或Facebook一起使用时，就是他们看到耗尽的情况。或者，如果它们消失并杀死了其他应用程序，那么浪费将会消失。我们已经看到，耗电持续了整个电源周期，没有启动任何应用程序。这意味着它必须是防止OS休眠的系统级服务。
即使我们认为该问题是由多个客户端调用CoreLocation的某些竞争状况引起的，但我们从未见过仅使用CoreLocation的应用程序会重现该问题。我们甚至创建了4个或5个可以同时访问CoreLocation的不同应用程序，但我们没有发现消耗过多的情况。但是，当我们有一个带有CoreLocation的应用程序和另一个带有CoreLocation + CoreBluetooth的应用程序时，我们确实看到了问题。可能只有极少数的应用程序使用CoreLocation + CoreBluetooth组合，因此有可能这就是为什么更多开发人员没有解决此问题的原因。尽管我们无所适从地解释了CoreLocation和CoreBluetooth如何相互作用导致这种消耗，以及带有CoreLocation的第二个应用程序如何进入方程式。由于耗费是间歇性的，因此仅当我们在使用CoreLocation + CoreBluetooth进行测试时才发生此问题是偶然的。
在仅安装了这两个应用程序CTM1和FMC的删除5.0.1 iPhone 4S上，我们能够间歇地进入消耗状态。有趣的是，与普通设备相比，删除设备上的漏水问题似乎要少得多。不幸的是，我们只看到了几次排水状态，而无法可靠地重现排水，因此我们没有良好的控制状态。
我们已经向Apple提交了错误报告，并提出了技术支持事件，但也许Stackover社区也可以提供一些见解。我们已经在5.0.1和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];
如果您发现任何编码错误可能会导致浪费，请告诉我们。
如果我们同时使用GPS和重要位置监控，那么我们确实还有另一个问题，是否有理由调用
stopMonitoringSignificantLocationChanges？在查看Regions示例代码时，他们在进入前景时调用stopMonitoringSignificantLocationChanges和startLocationUpdate，在进入背景时调用stopLocationUpdate和startMonitoringSignificantLocationChanges，但是我想知道这是否是必需/建议/必需的？更新:
我们已与Apple开发人员技术支持确认，对于同时使用GPS和重要位置监视的应用程序，在启用GPS更新之前，关闭重要位置监视的顺序是正确的。
我们还确认，在GM 5.1中以及在5.1框架下重新编译的Find My Car Smarter应用程序中仍然可以看到排水问题。
更新:
当我们的应用程序从后台启动以响应重大位置监视事件时，似乎触发了该问题。实际上，在示例代码中我们无法正确处理这种情况，但是在实际的应用程序中却可以。
在示例代码中，在后台重新启动时，我们将打开位置更新，并且由于没有applicationDidEnterBackground调用，因此GPS将保持打开状态。
在我们的应用程序中，我们通过查找UIApplicationLaunchOptionsLocationKey标志来检查是否从后台启动了我们，如果是，则启动重要位置监视，否则，我们在前台启动，然后启动更新位置。
Apple再次与我们联系，并指出使用“重要位置监视”不需要在Info.plist的UIBackgroundModes数组中设置位置。我们删除了此条目，看来电池耗尽状态不再有效。在UIBackgroundModes列表中，我们仍然具有蓝牙中心。目前，我们尚不清楚这有何帮助。我们将进行更多实验，以帮助我们更好地理解这一点。如果有人有任何建议，请告诉我们。
最佳答案
归根结底，Apple建议从UIBackgroundModes中删除位置的建议解决了我们的电池消耗问题。
为了仍然在后台获取位置，我们必须将[locationManager startLocationUpdates]和[locationManager stopLocationUpdates]调用包装为:
[[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler];
[[UIApplication sharedApplication] endBackgroundTask:];