实现 iOS 后台定位的两种方式

工作中碰到一个定位的应用场景：app需要在后台运行，实时上传用户地理位置。

苹果对iOS的规范性在提升了app的品质的同时也带来了对开发者的限制。翻阅了各种官方文档和资料，得出结论如下：

1、实现后台定位有2种方式：

standard location service（调用CLLocationManager的startUpdatingLocation）
significant-change location
service（调用CLLocationManager 的startMonitoringSignificantLocationChanges）

2、两者区别：

前者（startUpdatingLocation）是标准定位，想要在后台使用必须在info.plist文件中增加Required background modes属性，并选择App registers for location updates值。
前者（startUpdatingLocation）在后台运行时可能会因为资源问题被系统挂起（suspend）或终止（terminate），但一旦有更新会被唤起，但是当更新时系统任然资源紧张，则会被延迟调用委托。如果对于实时性要求高的可能不适合这个，很难控制用户机器性能状况。
前者（startUpdatingLocation）如果被用户手动关闭，就不会再被唤醒。
前者定位基于gps/基站/wifi定位，具体使用哪一种CoreLocation框架有一套自己的规则。
后者（startMonitoringSignificantLocationChanges）是使用基站定位的，所以设备一定要有电话模块，在plist中可以设置xx属性来限制可被下载安装的设备。
后者（startMonitoringSignificantLocationChanges）不管是在后台还是用户手动关闭都会被唤醒调用委托，只有3种方法可以阻止它的更新。（1）用户关闭定位服务（2）用户关闭对该app的定位服务（3）设备处于飞行模式或者无法开启必要的硬件（猜测是定位模块的硬件）。
后者（startMonitoringSignificantLocationChanges）什么时候更新呢？是在更换基站的时候更新。所以更新频率与基站密度有关。市区更新频率较郊区高。所以很多同学说没有更新是因为还在同一组基站范围内。
前者较后者耗电且精度高。

3、两者共性：

两者都更新位置信息时都回调相同的委托方法：-(void)locationManager:(CLLocationManager*)manager
didUpdateLocations:(NSArray *)locations;

4、上传信息：

由于后台任务只分配了有限时间执行必要的操作，所以如果在超时之前未完成（比如网络请求），app将会被终止。这里有一个方法，可以申请额外的10分钟让你执行想要的操作，申请后台任务：beginBackgroundTaskWithExpirationHandler（不详细说了，使用方法可以查一下资料）。

5、总结：

2种方式各有利弊，根据使用场景而决定，前台运行的app通常要求准确实时定位，并且运行时间有限，考虑用第一种标准定位，比如导航应用。如果移动速度快（距离变化明显），长时间定位（监控），可以考虑后者，比如打车应用。