后台定位上传实践
前言
我现在做的是LBS定位的社交APP 其中主要的一个功能就是能够实时定位社交圈中各个成员的位置后台实时上传位置则是非常重要的一个技术点 接下来就来说说我关于这方面的实践经验
需求
先来看看实现这个功能的具体需求是什么 由于我们是实时定位的生活类社交APP 所以我们需要做到一下几点
1. 如果用户的位置在持续变化 则隔一段时间上报一次
由于我们希望能够实时的将用户的位置变化反馈在APP里 所以定时的上报是刚需
2. 如果用户的移动速度很慢 则隔一段距离上报一次
如果用户是低速率的状态(比如步行的移动速度大概就是1m/s左右) 这个时候如果还按(1)中的方式来上报的话 由于变化太小 地图上的点会非常的密集 这种数据的意义不大(而且如果要做轨迹服务的话 这些密集点都是必须优化掉的) 所以这时候我们按照距离间隔来上报
3. 如果用户的位置在到达某处后没有变化 则不继续上报
我们只关心位置的变化 如果用户的位置没有变化或者变化很小 其实是不需要上报其位置的(比如进入的公司 或者等一个很长时间的红灯) 这时候我们就不上报(以达到省电的目的)
4. 切换到后台也要能定位上报
后台上报是必须的 用户不可能一直运行着我们的APP (iOS4开始就支持了)
5. APP因各种原因终止运行后(用户主动关闭, 系统杀掉) 也要能定位上报
用户主动关闭APP的几率不大 但是因系统调度被杀掉的情况是很普遍的 这个时候我们也要能够上报 (iOS7开始已支持被杀掉后唤醒)
分析完需求 接下来就开始介绍如何实现
准备
首先做一些准备工作
在target的Capabilities选项中打开Background Modes并勾选Location updates
然后在plist中添加NSLocationAlawaysUsageDescription的键 在value中随便键入任何内容
完成这两步 我们的前期工作就完成了Background Modes是iOS7带入的新功能 而NSLocationAlawaysUsageDescription为了增强权限机制引入的提示描述 不添加这个的话 定位功能可是使用不了的 之后我们要调用requestAlwaysAuthorization提示中就会显示这个描述
在评论中有朋友问起 为什么要使用requestAlwaysAuthorization而不使用requestWhenInUseAuthorization呢 我借用一张图来说明一下
简单来说 两者的区别在于前者支持Region Monitoring和Significant Location Changes而后者不支持
但其实还有一个非常重要的区别 就是前者支持程序被杀掉后的系统自动唤醒而后者不支持 这是非常重要的一个区别
定位肯定要跟CLLocationManager打交道 所以我们先定义一个CLLocationManager的子类 并根据需求中的几点定义三个变量
这里解释一下这几个参数
minSpeed如果当前运动速度大于此值 则满足需求(1) 以时间为更新依据(minFilter) 如果当前运动速度小于此值 则满足需求(2) 以范围为更新依据(minInteval)
minFilter最小的触发范围 用于需求(1)
minInteval更新间隔 用于需求(2)
接下来是初始化函数
这里的默认值可以根据需求来调整
然后是位置更新后的处理逻辑 其实也非常的简单
而这个adjustDistanceFilter函数 就是整个代码的核心 会根据当前速度来动态的调整distanceFilter这个参数 以满足我们的需求
这里要注意到的是distanceFilter这个参数不能一直进行设置 因为每次设置完以后 再接下来的一秒以后 会立即触发didUpdateLocations回调(系统的标准最短更新间隔是1秒 即更新频率为1hz) 所以这里只有当变化超过10%的时候才会重置distanceFilter
接下来 为了能够正确的在被杀掉的情况下被唤醒 我们还要做最后一步操作 在AppDelegate的didFinishLaunchingWithOptions中加入下面的代码
接下来我们会讨论一下相关的几个问题
讨论
为什么不用定时器来控制定位间隔
网上有很多教程是用NSTimer来实现的 但是其实这样不是很好 虽然定位的间隔是固定的 但是耗电的问题无法解决 后台会持续的更新定位 无论当前的位置是否在更新 当然 如果你的使用场景就是要每隔一段时间来上传 就可以使用定时器来处理
使用distanceFilter来处理 会有些什么问题
由于distanceFilter=currentSpeed*minInteval 那么间隔的时间因为速度的变化而会有波动 但是这个波动是在可接受范围的 如果速度加快或者变慢 那么下一次的更新时间则会相应的缩短或者变长 但是因为我们是在真实生活环境中 速度的变化不可能那么快 所以这个误差是可以接受的 另外我们对distanceFilter针对速度进行矫正 因而总体来说 间隔还是会保持在我们与其的范围内的
为什么不使用allowDeferredLocationUpdatesUntilTraveled:timeout:
allowDeferredLocationUpdatesUntilTraveled是iOS6推出的一个新的API 看名字我们可以知道这个函数的作用是延迟位置更新 直到移动了xx米或者时间超过了xx秒 那么这个函数不正好满足了我们的所有要求么? 可是万万没想到 事情并不是这样的 这个函数并不好用
接下来是吐槽时间 ლ(⁰⊖⁰ლ)
为什么说这个函数不好用呢? 首先 这个函数的要求很多 我们来看看要这个函数起作用要满足哪些条件
