- 本发明所要解决的技术问题;
为克服?室外后台GPS定位功耗大导致的手机发热?的体验差现象,本发明创造提供一种?后台场景GPS高耗电拦截管控?的 省电技术。
- 本发明的技术方案;
2.1 前言 本发明方案的现象发现—根据大数据埋点模块; 本发明方案的现象分析与管控方案—根据于大数据分析; 本发明方案的实施—GPS功耗拦截策略; 故接下来进行一一阐述 2.2 大数据埋点模块 目的:为找出GPS功耗现象,作数据源收集; 采集数据源的原则是对可能使GPS功耗电流大的影响因素进行埋点; 例如当GPS进程可见时,记录进程类型和是否被管控,并统计获取到GPS定位数据的次数和触发联网的次数,平均电流等; 例如当GPS进程不可见时,记录进程类型和是否被管控,并统计获取到GPS定位数据的次数和触发联网的次数,平均电流等; PS:进程类型:导航类型、计步类型、社交类型、工具类型、游戏类型、视频类型等; 例如可以采用下述字段采集GPS功耗相关信息,即这里只要能体现出是埋点GPS功耗数据的思路即可
软件版本 | 应用 | 状态 | 是否被管控 | GPS使用时长 | GPS定位次数 | 联网次数 | 平均电流 | | | | | | | | | 2.3 大数据分析 目的:根据大数据埋点信息统计,统计出可能存在的功耗现象和查看优化管控后的效果; 1. 非导航或计步类型应用处于可见状态的GPS和联网使用情况分析; 2. 导航或计步类型应用处于可见状态的GPS和联网使用情况分析; 3. 非导航或计步类型应用处于不可见状态的GPS和联网使用情况分析; 4. 导航或计步类型应用处于不可见状态的GPS和联网使用情况分析; 例如我们可能得到如下表格数据:
软件版本 | 应用 | 状态 | 是否被管控 | GPS使用时长 | GPS定位次数 | 联网次数 | 平均电流 | v1.0 | com.test.demo | 灭屏后台不可见 | 否 | 10分钟 | 180次 | 150次 | 80mA | v1.1 | com.test.demo | 灭屏后台不可见 | 是 | 1分钟 | 0次 | 0次 | 10mA | v1.0 | com.test.demo | 亮屏后台不可见 | 否 | 10分钟 | 180次 | 160次 | 350mA | v1.1 | com.test.demo | 亮屏后台不可见 | 是 | 1分钟 | 0次 | 0次 | 266mA |
(注:上述数据只是填写数值方便理解用途,非真实数据) 通过大数据反馈我们可以发现问题,也可以在查看有无管控的优化效果。 我们观察到一些大数据中反馈的异常电流,在实验室进行使用测试和电流,我们得到如下: 1. 将实际使用中确实需要使用GPS的导航应用或计步类型的应用,且限制了GPS相关行为会影响到地图导航或计步准确的应用,应列为GPS管控白名单 2. 将非导航或计步类型且后台频繁调用GPS与联网的应用,且限制了GPS行为也不影响其功能正常使用的应用,带来不必要的电流增加,应列为GPS管控黑名单; 3. 一些定位属性为定位间隔为小于5分钟,定位类型为GPS定位应用,存在规律性高耗电现象; 综合上述我们制定了,下文描述的GPS功耗拦截策略 2.4 GPS功耗拦截策略 1. 进程不可见达1分钟后,不管黑名单应用是使用GPS定位或者网络定位,进行GPS定位拦截管控; 2. 进程不可见达1分钟后,白名单豁免,即不需要进行GPS 定位拦截管控; 3. 进程不可见达1分钟后,针对高耗电 GPS 定位类型,进行GPS 定位拦截管控; 4. 进程可见时立即执行恢复操作,解除GPS定位拦截管控; 具体GPS拦截管控措施如下: a. 拦截后台上报GPS消息,从而阻止进程收到定位信息可能的联网操作; b. 拦截后台上报地图围栏消息,从而阻止进程收到定位信息可能的联网操作; c. 拦截后台唤醒CPU; d. 在不关闭GPS开关情况下,下发停止定位状态位给GPS硬件,本状态位下发后,即使GPS开关显示为开启,但是实际上系统是无法收到任何定位数据,同时耗电详情中GPS统计也处于停止统计定位状态; 上述中还需考虑实际使用场景: 可见进程为导航或计步场景中,后台进程被GPS管控中,不能下发停止定位状态给GPS硬件,否则当前可见进程中的导航或定位场景,将无法获取到准确定位状态; 通过上面3个模块的介绍,接下来描述一个实际软件逻辑运行的实例,具体流程图见(附图1) 1. 在GPS定位系统中监听进程状态变化,即监听进程可见与不可见状态; 2. 当用户按Home键、Back键或灭屏待机时,进程处于不可见状态; 3. 判定当前使用定位的进程是否为白名单,若是则结束本次流程;若否则进入下一步; 4. 判定当前进程是否属于黑名单,若是则直接进入延时等待一分钟的逻辑,若否则继续下一步判断; 5. 判定当前进程是否为GPS高耗电类型,如之前描述GPS高耗电类型是指上文介绍的4种定位类型,但是属性为使用GPS类型且定位间隔小于5分钟;若是则直接进入延时等待一分钟的逻辑,若否表明当前定位类型不耗电,不需要进行省电管控,则可结束本次流程 6. 延时一分钟逻辑,出发点是:实际中还有这样一个场景,用户只是短暂退出界面,但是有可能又退回来界面继续操作; 7. 判定当前是否为不可见状态(第二次判定),若是则进行大数据埋点,?记录GPS使用情况,具体见对应模块描述,若否说明用户在这1分钟内又切回可见状态,不需要进行省电操作,故可以结束本流程; 8. 执行GPS拦截管控,?具体见模块描述; 9. 当进程处于可见状态,且需要撤销之前的GPS拦截管控状态,则需要实时恢复,并继续保持大数据埋点,记录GPS使用情况;
- 最后论述本发明的改进所带来的有益效果
目前本发明方案实施后,我司测试部输出了一组测试数据如下,测试数据表明本发明方案对功耗电流具有改善效果。 备注:不同应用的不同界面在不同场景下可能会存在不同GPS定位逻辑调用,所以GPS省电策略非常依赖测试角度和测试环境;故GPS测试数据结果在不同测试环境和手法下数据可能存在差异。
室外场景测试 | 无GPS?省电策略 | 有GPS?省电策略 | 电流优化大小 | 1.亮屏+开启GPS+连接WiFi 2. gps_plus.apk前台运行(前台定位场景) 3. GPS_DEMO后台运行(后台定位场景) | 370mA | 292mA | 78mA | 1.灭屏+开启GPS+连接WiFi 2. gps_plus.apk前台运行(前台定位场景) 3. GPS_DEMO后台运行(后台定位场景) | 31mA | 13mA | 18mA | 1.亮屏+开启GPS+连接WiFi 2.百度地图导航前台运行(前台导航场景) 3. GPS_DEMO后台运行(后台定位场景) | 559mA | 484mA | 75mA | 1.灭屏+开启GPS+连接WiFi 2.百度地图导航前台运行(前台导航场景) 3. GPS_DEMO后台运行(后台定位场景) | 105mA | 62mA | 43mA | 1.亮屏+开启GPS+连接WiFi 2.gps_plus.apk后台运行(前台定位场景) 3. 微信实时定位前台运行(后台定位场景) | 423mA | 354mA | 69mA | 1.亮屏+开启GPS+连接WiFi 2.gps_plus.apk前台运行(前台定位场景) 3. Keep跑步模式后台运行(后台定位场景) | 337mA | 317mA | 20mA | 综上所述:
- 其他GPS管控方案研究
这里还研究了传统的GPS管控的实现方法: 1. 保存进程注册监听GPS的引用; 2. 当进程处于不可见时,将GPS的引用注销; 3. 当进程处于可见时,将保存的GPS引用再次注册; 上述的方法是从整体角度对不可见的进程GPS进行限制管控,相当于被管控的应用从来没有注册监听过GPS。 但是该传统方案的缺点是: 1. 每次执行GPS注销和再次注册,函数执行过程中,需要设置进程锁、移除或创建GPS对象都需要对内存重新释放与申请,本发明方案只需条件判断,即可灵活切换GPS拦截和解除拦截,故效果执行的时间比本发明方案长; 2. 该传统方法和第三方进程在使用GPS注册与注销监听实现接口与一样的,故容易出现相同时刻同时调用,且系统不同时刻的运行状态不同,如果逻辑没考虑完全的情况下,往往容易带来死锁的现象。故开发设计中一些未知风险,会随着不同进程运行环境而不同,即存在一定风险; 3. 本发明方案是有针对性拦截限制一些耗电相关的操作,而非一棒子政策,直接代替第三方进程本身执行注销操作,故本发明方案是非为省电而省电,而是按需省电,打蛇打七寸的思路完成GPS功耗管控; 综合上述:本方案同传统方案相比较,GPS限制的颗粒度更细,更针对性,也更灵活,执行效率也最高,且采用拦截的方式无死锁方面的风险。 |