后台定位上传的代码实践

上传人:xh****66 文档编号:57119050 上传时间:2018-10-19 格式:DOCX 页数:8 大小:303.77KB
返回 下载 相关 举报
后台定位上传的代码实践_第1页
第1页 / 共8页
后台定位上传的代码实践_第2页
第2页 / 共8页
后台定位上传的代码实践_第3页
第3页 / 共8页
后台定位上传的代码实践_第4页
第4页 / 共8页
后台定位上传的代码实践_第5页
第5页 / 共8页
点击查看更多>>
资源描述

《后台定位上传的代码实践》由会员分享,可在线阅读,更多相关《后台定位上传的代码实践(8页珍藏版)》请在金锄头文库上搜索。

1、后台定位上传的代码实践后台定位上传的代码实践前言 之前的文章说过 我现在做的是 LBS 定位的社交 APP 其中主要的一个功能就是能够实时定 位社交圈中各个成员的位置 后台实时上传位置则是非常重要的一个技术点 接下来就来说 说我关于这方面的实践经验 需求 先来看看实现这个功能的具体需求是什么 由于我们是实时定位的生活类社交 APP 所以我 们需要做到一下几点 1. 如果用户的位置在持续变化 则隔一段时间上报一次 由于我们希望能够实时的将用户的位置变化反馈在 APP 里 所以定时的上报是刚需 2. 如果用户的移动速度很慢 则隔一段距离上报一次 如果用户是低速率的状态(比如步行的移动速度大概就是

2、1m/s 左右) 这个时候如果还按(1) 中的方式来上报的话 由于变化太小 地图上的点会非常的密集 这种数据的意义不大(而且 如果要做轨迹服务的话 这些密集点都是必须有花掉的) 所以这时候我们按照距离间隔来上 报 3. 如果用户的位置在到达某处后没有变化 则不继续上报 我们只关心位置的变化 如果用户的位置没有变化或者变化很小 其实是不需要上报其位置 的(比如进入的公司 或者等一个很长时间的红灯) 这时候我们就不上报(以达到省电的目的) 4. 切换到后台也要能定位上报 后台上报是必须的 用户不可能一直运行着我们的 APP (iOS4 开始就支持了) 5. APP 因各种原因终止运行后(用户主动关

3、闭, 系统杀掉) 也要能定位上报 用户主动关闭 APP 的几率不大 但是因系统调度被杀掉的情况是很普遍的 这个时候我们也 要能够上报 (iOS7 开始已支持被杀掉后唤醒) 分析完需求 接下来就开始介绍如何实现 准备 首先做一些准备工作 在 target 的 Capabilities 选项中打开 Background Modes 并勾选 Location updates然后在 plist 中添加 NSLocationAlawaysUsageDescription 的键 在 value 中随便键入任何内容完成这两步 我们的前期工作就完成了 Background Modes 是 iOS7 带入的新功

4、能 而 NSLocationAlawaysUsageDescription 为了增强权限机制引入的提示描述 不添加这个的话 定 位功能可是使用不了的 代码 定位肯定要跟 CLLocationManager 打交道 所以我们先定义一个 CLLocationManager 的子类 并根据需求中的几点定义三个变量 interface MMLocationManager : CLLocationManager + (instancetype)sharedManager; property (nonatomic, assign) CGFloat minSpeed; /最小速度 property (non

5、atomic, assign) CGFloat minFilter; /最小范围 property (nonatomic, assign) CGFloat minInteval; /更新间隔 end 这里解释一下这几个参数 minSpeed 如果当前运动速度大于此值 则满足需求(1) 以时间为更新依据(minFilter) 如果当 前运动速度小于此值 则满足需求(2) 以范围为更新依据(minInteval) minFilter 最小的触发范围 用于需求(1) minInteval 更新间隔 用于需求(2) 接下来是初始化函数 - (instancetype)init self = super

6、 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 didUpd

7、ateLoca tions:(NSArray *)locations CLLocation *location = locations0; NSLog(“%“,location); /根据实际情况来调整触发范围 self adjustDistanceFilter:location; /上传数据 self uploadLocation:location; 而这个 adjustDistanceFilter 函数 就是整个代码的核心 会根据当前速度来动态的调整 distanceFilter 这个参数 以满足我们的需求 /* * 规则: 如果速度小于 minSpeed m/s 则把触发范围设定为 50

8、m * 否则将触发范围设定为 minSpeed*minInteval * 此时若速度变化超过 10% 则更新当前的触发范围(这里限制是因为不能不停的设置 distanceFilter, * 否则 uploadLocation 会不停被触发) */ - (void)adjustDistanceFilter:(CLLocation*)location / NSLog(“adjust:%f“,location.speed); if ( location.speed 0.1f ) self.distanceFilter = self.minFilter; else CGFloat lastSpeed

9、= self.distanceFilter/self.minInteval; if ( (fabs(lastSpeed- location.speed)/lastSpeed 0.1f) | (lastSpeed Location-Freeway Drive) 结果如下接下来我们会讨论一下相关的几个问题讨论 为什么不用定时器来控制定位间隔 网上有很多教程是用 NSTimer 来实现的 但是其实这样不是很好 虽然定位的间隔是固定的 但是耗电的问题无法解决 后台会持续的更新定位 无论当前的位置是否在更新 当然 如果 你的使用场景就是要每隔一段时间来上传 就可以使用定时器来处理 使用 distance

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

11、ationUpdatesUntilTraveled 是 iOS6 推出的一个新的 API 看名字我们可以知 道这个函数的作用是延迟位置更新 直到移动了 xx 米或者时间超过了 xx 秒 那么这个函数 不正好满足了我们的所有要求么? 可是万万没想到 事情并不是这样的 这个函数并不好用接下来是吐槽时间 () 为什么说这个函数不好用呢? 首先 这个函数的要求很多 我们来看看要这个函数起作用要 满足哪些条件 必须 iPhone5 以及之后的硬件设备才支持 desiredAccuracy 必须设置为 kCLLocationAccuracyBest 或者 kCLLocationAccuracyBestFo

12、rNavigation distanceFilter 必须设置为 kCLDistanceFilterNone 只在 APP 运行在后台时生效 前台运行时是不会进行延迟处理的 只有系统在低功耗(Low Power State)的时候才有可能生效 关于 Low Power State 在 iOS 中的描述 我只在苹果官网的文档中找到部分定义iOS is very good at getting a device into a low power state when its not being used. At idle, very little power is drawn and energy

13、 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 stateneither idle nor activewhen the device isnt doing anything. There may not be enough time during these inte

14、rmediate states for the device to reach absolute idle before the next task executes. When this occurs, energy is wasted and the users battery drains faster. 据我简单的了解 这个*Low Power State”只有在黑屏的状态下(不只是锁屏)才有可能触发 只要有任何电量屏幕的操作(就连推送也算) 都会使 APP 退出这个状态 同时 如果在充电状 态下 也是无法进入的 我尝试在真机和模拟器上使用这个 API 但结果 APP 还是以 1HZ

15、的频率在定位(设置了 kCLDistanceFilterNone 的原因) 虽然 locationManager:didFinishDeferredUpdatesWithError:在指定的时间后成功的回调了 但 是结果还是没有 deffer 于是我查了一下 原来这个函数无法直接进行调试的 因为: 不支持模拟器 deferredLocationUpdatesAvailable 用于检测设备是否支持 模拟器会返回 NO 不支持真机调试 因为调试时 Xcode 会阻止程序休眠 导致程序无法进入低功耗状态 结论就是这个东西连调试都没办法 所以我也没有那么多时间跑到外面去测试这个东西 况且使用我上述的方法已经基本可以满足需求 所以我已放弃继续研究这个 API 了 因为 就算使用了这个东西 也仅仅是锦上添花而已 如果有哪些同学知道如何正确的使用这个东西 请留言告诉我 万分感谢!【编辑推荐】1.值得收藏!神级代码编辑器 Sublime Text 全程指南 2.问题记录:iOS 用户行为统计代码的剥离 3.微信“死亡代码“如今成其手中的敲诈工具 4.3 年代码总结分享 5.关于烂代码的那些事

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号