后台定位上传的代码实践

前言

之前的文章说过我现在做的是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 为了增强权限机制引入的提示描述不添加这个的话定位功能可是使用不了的

代码

定位肯定要跟 CLLocationManager 打交道所以我们先定义一个 CLLocationManager 的子类并根据需求中的几点定义三个变量


@interface MMLocationManager : CLLocationManager

+ (instancetype)sharedManager;

@property (nonatomic, assign) CGFloat minSpeed;     //最小速度
@property (nonatomic, assign) CGFloat minFilter;    //最小范围
@property (nonatomic, assign) CGFloat minInteval;   //更新间隔

@end

这里解释一下这几个参数

minSpeed 如果当前运动速度大于此值则满足需求(1) 以时间为更新依据(minFilter) 如果当前运动速度小于此值则满足需求(2) 以范围为更新依据(minInteval)
minFilter 最小的触发范围用于需求(1)
minInteval 更新间隔用于需求(2)

接下来是初始化函数

- (instancetype)init
{
    self = [super init];
    if ( self )
    {
        self.minSpeed = 3;
        self.minFilter = 50;
        self.minInteval = 10;

        self.delegate = self;
        self.distanceFilter  = self.minFilter;
        self.desiredAccuracy = kCLLocationAccuracyBest;
    }
    return self;
}

这里的默认值可以根据需求来调整

然后是位置更新后的处理逻辑其实也非常的简单

- (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations
{
    CLLocation *location = locations[0];

    NSLog(@"%@",location);

    //根据实际情况来调整触发范围
    [self adjustDistanceFilter:location];

    //上传数据
    [self uploadLocation:location];
}

而这个 adjustDistanceFilter 函数就是整个代码的核心会根据当前速度来动态的调整 distanceFilter 这个参数以满足我们的需求

/**
*  规则: 如果速度小于minSpeed m/s 则把触发范围设定为50m
*  否则将触发范围设定为minSpeed*minInteval
*  此时若速度变化超过10% 则更新当前的触发范围(这里限制是因为不能不停的设置distanceFilter,
*  否则uploadLocation会不停被触发)
*/
- (void)adjustDistanceFilter:(CLLocation*)location
{
//    NSLog(@"adjust:%f",location.speed);
    
    if ( location.speed < self.minSpeed )
    {
        if ( fabs(self.distanceFilter-self.minFilter) > 0.1f )
        {
            self.distanceFilter = self.minFilter;
        }
    }
    else
    {
        CGFloat lastSpeed = self.distanceFilter/self.minInteval;
        
        if ( (fabs(lastSpeed-location.speed)/lastSpeed > 0.1f) || (lastSpeed < 0) )
        {
            CGFloat newSpeed  = (int)(location.speed+0.5f);
            CGFloat newFilter = newSpeed*self.minInteval;
            
            self.distanceFilter = newFilter;
        }
    }
}

这里要注意到的是 distanceFilter 这个参数不能一直进行设置因为每次设置完以后再接下来的一秒以后会立即触发 didUpdateLocations 回调(系统的标准最短更新间隔是1秒即更新频率为1hz) 所以这里只有当变化超过10%的时候才会重置 distanceFilter

接下来为了能够正确的在被杀掉的情况下被唤醒我们还要做最后一步操作在 AppDelegate 的 didFinishLaunchingWithOptions 中加入下面的代码

if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey]) {
    
    if ( [[MMLocationManager sharedManager] respondsToSelector:@selector(requestAlwaysAuthorization)] )
    {
        [[MMLocationManager sharedManager] requestAlwaysAuthorization];
    }

    [[MMLocationManager sharedManager] startUpdatingLocation];
}

这是因为被杀掉的APP 在后台被系统唤醒时 launchOptions会包含 UIApplicationLaunchOptionsLocationKey**字段来进行标识这时我们再重新启动定位功能即可

至此满足我们需求的定位功能就完成了为此我写了一个demo来验证(使用模拟器然后选择Debug->Location->Freeway Drive) 结果如下

接下来我们会讨论一下相关的几个问题

讨论

为什么不用定时器来控制定位间隔

网上有很多教程是用NSTimer来实现的但是其实这样不是很好虽然定位的间隔是固定的但是耗电的问题无法解决后台会持续的更新定位无论当前的位置是否在更新当然如果你的使用场景就是要每隔一段时间来上传就可以使用定时器来处理

使用distanceFilter来处理会有些什么问题

由于distanceFilter=currentSpeed*minInteval 那么间隔的时间因为速度的变化而会有波动但是这个波动是在可接受范围的如果速度加快或者变慢那么下一次的更新时间则会相应的缩短或者变长但是因为我们是在真实生活环境中速度的变化不可能那么快所以这个误差是可以接受的另外我们对distanceFilter针对速度进行矫正因而总体来说间隔还是会保持在我们与其的范围内的

为什么不使用allowDeferredLocationUpdatesUntilTraveled:timeout:

allowDeferredLocationUpdatesUntilTraveled 是iOS6推出的一个新的API 看名字我们可以知道这个函数的作用是延迟位置更新直到移动了xx米或者时间超过了xx秒那么这个函数不正好满足了我们的所有要求么? 可是万万没想到事情并不是这样的这个函数并不好用

接下来是吐槽时间 ლ(⁰⊖⁰ლ)

为什么说这个函数不好用呢? 首先这个函数的要求很多我们来看看要这个函数起作用要满足哪些条件

必须iPhone5以及之后的硬件设备才支持
desiredAccuracy必须设置为 kCLLocationAccuracyBest 或者 kCLLocationAccuracyBestForNavigation
distanceFilter必须设置为 kCLDistanceFilterNone
只在APP运行在后台时生效前台运行时是不会进行延迟处理的
只有系统在 低功耗(Low Power State) 的时候 才有可能 生效

关于 Low Power State 在iOS中的描述我只在苹果官网的文档中找到部分定义

iOS is very good at getting a device into a low power state when it’s not being used. At idle, very little power is drawn and energy impact is low. When tasks are actively occurring, system resources are being used and those resources require energy. However, sporadic tasks can cause the device to enter an intermediate state—neither idle nor active—when the device isn’t doing anything. There may not be enough time during these intermediate states for the device to reach absolute idle before the next task executes. When this occurs, energy is wasted and the user’s battery drains faster.

据我简单的了解这个**Low Power State”只有在黑屏的状态下(不只是锁屏)才有可能触发只要有任何电量屏幕的操作(就连推送也算) 都会使APP退出这个状态同时如果在充电状态下也是无法进入的

我尝试在真机和模拟器上使用这个API 但结果APP还是以1HZ的频率在定位(设置了kCLDistanceFilterNone的原因)

虽然 locationManager:didFinishDeferredUpdatesWithError: 在指定的时间后成功的回调了但是结果还是没有deffer 于是我查了一下原来这个函数无法直接进行调试的因为: