对于定位,这里指以获取经纬度为最终目的,并可能伴随下发普遍的信息点包括省、市、区、街道名或更加详细的兴趣热点名(即设备所处位置周边的餐饮点、场馆点、医疗点等信息)。

移动设备的定位目前主流的实现有:GPS 和 各种定位SDK(如高德、腾讯)。

文章结构:
GPS原理
定位SDK原理
定位的关键指标数据
经纬度坐标系
SDK定位失败原因
定位凭据权限限制的判断方法
SDK定位失败原因分布
定位成功率提升思路


#GPS原理

GPS定位是大部分移动设备都支持的定位方式。

设备内内置GPS模块,设备开启GPS功能后,会接收GPS卫星向地面发出的广播信息,信息中包卫星各自的空间信息、时间戳。

在三维空间中,最少已知与三个参考点的位置信息即可确认空间中另一点的位置信息,但由于GPS接收设备的定位算法中无线电信号传播速度以光速计,导致相应的对时间的精度要求是极高的,所以算法中要求再引入一颗卫星的数据即4颗定位卫星的数据来纠正精度误差。

详细原理可以点击这里

从数据IO上来看,GPS定位的数据输入是卫星位置信号,数据输入方式是被动接收,因为GPS卫星的广播是定时有间隔的;产出是算法计算后的经纬度。

所以这里也可以指出GPS定位方式的特点:

#####闪光点:

  • 精度高,是所有设备获取定位点信息的数据源头。

#####缺点:

  • 时间上需要等待卫星的广播信号,可能有延时。
  • 环境条件上受限,卫星信号受地形/建筑环境影响,可能接受不到。
  • 操作习惯上,移动设备受众如手机用户,可能没有意识要去开启GPS功能,会导致无法定位成功。

#定位SDK原理

为了解决GPS定位方式中的缺点,特别是对GPS功能开启与否无概念的用户习惯,现许多厂商推出了自己的定位SDK方案。

解决方案原理一般是这样被厂商描述的:

定位SDK使用当前设备的GPS、基站信号和WiFi信号生成定位依据,并将定位依据发送到厂商的定位服务器提供计算生成定位结果,返回给移动终端。

qq.lbs

这样的描述会让人产生以下疑问:

  1. 使用定位SDK还需要GPS信号?那前面所提到的问题仍得不到解决。
  2. 不启动GPS功能只能提供基站或WiFi信号时,经纬度从何而来?向运营商索取?

第一个问题,第三方的定位SDK并不一定需要GPS信号,只要提供三者任意一个即可。这里只能说是上面的表述不够严谨。

第二个问题,则是定位SDK原理的核心了。

当前的移动设备如果要正常联网,有两种途径:

  • 插上运营商有效激活的SIM卡,能够获取到移动基站的cID、CellID等信息;
  • 连接上WiFi,这样能获取到当前环境下各种WiFi接入点的mac地址、信号强度等信息;

定位SDK根据上面的两种信息,也就是定位凭据,经历了以下两个阶段:

  1. 前期定位凭据收集期
    收集定位凭据与经纬度,建设区配库。这时期经纬度数据的产出仍是GPS模块。
    这个阶段已经完成,早在前两年,大部分的应用在使用“附近的人”类似功能时都会检查是否开启GPS,只有开启才能够使用,这就是厂商前期收集定位凭据、建库、匹配的阶段。

  2. SDK功能稳定期/更新期
    现在处于这个时期,运营商基站的信息变更是相当固定不频繁的,WiFi环境也相对固定,毕竟由公司提供的WiFi或个人居家WiFi的变更周期普遍也不会少于1年。
    在这个阶段,应用的终端如果开启了GPS功能,则把GPS与定位凭据一块上发给厂商服务器,根据算法做出匹配、定位凭据更新维护等操作;如果应用的终端并未开启GPS,只要能提供定位凭据,根据前期的收集积累,也能给出当前终端的定位结果。
    在这个阶段经纬度数据产出则是云端库的算法结果了。不直接依赖GPS。

定位SDK的原理简单来说,就是总有人在终端使用应用时,总会开启GPS,把经纬度与收集的定位凭据一块发送到后台建库;供后来人在只有定位凭据的情况下也能获取到经纬度信息。

下图简单的示意了这个过程。
lbs.sdk

这样,定位SDK即可较完美的解决GPS定位所存在的问题。


#定位的关键指标数据

定位的关键指标要看定位的成功率、定位精度。

直接给出腾讯的数据截图吧..各大厂商的应该都差不多
lbs.data


#经纬度坐标系

经纬度还有坐标系?麻蛋呀…真有不同的坐标系。为毛?因为中国特色。

以GPS为代表的坐标系是地心坐标系,编号WGS-84。

以中国特色国家安全为由的坐标系又名火星坐标系,编号GCJ-02。目前腾讯定位/地图采用此坐标系。

还有更特别的如百度地图坐标系,是在火星坐标系上再加工的。额,呵呵了…

做LBS定位开发一定要搞清楚当前使用的坐标系!

做LBS定位开发一定要搞清楚当前使用的坐标系!

做LBS定位开发一定要搞清楚当前使用的坐标系!

重要的事情要多提多重复提。

如果坐标系混乱了,精度及定位会出现较大的偏差,通常是定位结果偏移了一条街。如下图:

同样表示万利达大厦,当地心坐标系的经纬度用在了采用火星坐标系的腾讯地图上时,则落到了街对面的深圳大学操场了。汗…

coordinate_wrong


#SDK定位失败原因

由定位SDK原理,一个定位流程是这样子的:

####* 收集定位凭据–>发起网络请求–>云计算分析–>网络回包经纬度数据

也可以预想定位失败的原因会有这样的情况:

1.网络失败

无网络,这种情况一般是不计入定位失败的情况的。

假网络链接,如运营商/WiFi截持,举个例子是在公共WiFi环境下,设备显示边上WiFi,但只能连上该WiFi设备的登录页面,要求你输入手机号及验证码才能真正连网。这类假连接可以通过ping或网络请求前后的头信息(HOST)来比较。

ConnectionTimeout SocketTimeout NoResponse UnkownHost等常见的网络异常,没有很好的解决办法。

2.定位凭据无效

定位凭据无效分两种可能

一种是能获取到定位凭据,但该定位凭据是不可用的;如大城市里存在非法基站乱给用户发广告短信的那种,由于假基站的设备信息过于简单重复率高、或可移动性出现并流动在多个城市,造成云端计算时无法准确给出定位结果则判定该凭据非法。

特点:可被动恢复,用户上班或回家后连上正常的网络环境(基站点)即可恢复。

一种是由于权限限制等其它原因导致无法正常获取到定位凭据。如现在的Android设备相当多的安全软件会限制应用使用定位权限、甚至小米、华为的手机及新版本的Android M都可以在应用运行时提示、改变权限许可状态,导致获取到空的定位凭据。如下面这位用户所遇到的就是这个情景:
lbsDataInvalid

特点:需主动恢复,需要用户能意识到是手机的设定问题而非应用的问题,门槛较高。

3.云数据未匹配,待新数据填充(404)

如运营商在西藏等偏远地区刚新树起一个基站,农村范围一大片地区可能就只有你家有WiFi最近还换了WiFi路由器了。

这种情况只能等待厂商将设备当前的基站或WiFi信息填充更新才能返回有效。

4.设备的其它错误

出现的概率很小,如果内存不足等原因,不应计入定位失败的指标中去。


#定位凭据权限限制的判断方法

这里的权限限制不包括GPS受限,因为定位SDK并不强行要求GPS开启,这里只指无法获取到基站、WiFi的信息。

基站信息被禁判断方法:

  1. 使用移动网络,网络正常

    不是移动网络的环境还有WiFi;使用移动网络且网络正常则把无SIM卡或SIM卡已经过期给排队掉了。

  2. 无法获取到基站的CellID等信息。在Android上表现即为TelephonyManager.getCellLocation()返回为空。

该方法只能提供一种佐证,但不能做为直接证据证明权限受限,因为有碰到SIM卡正常但CellLocation返回为空的,我也无法解释。


#SDK定位失败原因分布

给出一份当时某个版本的定位失败原因分布统计吧。

该统计是以应用的发起次数为分母,每次请求结果是失败的数量为分子的分析。

rate


#定位成功率提升思路

有了数据就可以为成功率的提升提供解决方向。

其实,当SDK和应用如果做得足够好,成功率的提升只是一个数字 KPI而已,提升的过程锻炼的是思维的方式方法,对编程的能力提高并无很大作用。

思路为:

#######静态监控

  1. 扫描代码,对定位接口的滥用提出bug修改。这里的滥用是指定位接口要收拢统一,不能不同业务开发各自实现,保证逻辑上是同一套运用,避免重复踩坑。

  2. 代码运行时检测,要求连续定位的业务必须重写连续失败的回调方法。

    根据上报的日志发现,在连续定位的业务(导航)中,连续定位失败还连续发定位请求,这是不合理的。合理的做法应该是定位失败超过阀值时,直接提示用户失败,并检查设备网络设置等,而非一直重复发起请求。

    解决这个问题,要求在程序设计提供连续失败的接口,在Debug版本运行时检测对未实现该接口的连续定位业务,直接抛异常提示,督促开发重视解决,这样保证程序开发的规范性,也节省用户电量、流量。

#######运营监控及改进

其实根本一点就是减少定位失败量的上报。

  1. 仔细跟进业务的失败率情况。

    发现应用主界面中有个Tab切换会引起定位请求,为了是老板需求中的搜索结果要与位置相关…一看代码,每次发起定位请求根本不设频率的好嘛!!!麻蛋!!!

    解决:限定请求频率,特别是失败后的请求间隔。

  2. 大层面上减少失败的定位请求

    从上面的失败原因统计中,可以看出大头是定位凭据非法,非法中权限又占大头,所以可以设定当用户使用移动网络但又失败且获取不到CellID等基站信息时,对定位频率做限制。

下面看下改进前后的成功率提升情况图:

横轴是应用版本发布后的第1天到第8天

纵轴是应用版本定位的成功率

raisRate


写文章是一件辛苦的事…又是一份不应错过的闲情….
你来过,就拍个照片吧…
你做过,就留字为证吧…
你想过,那赶紧落定吧…
时间越来越短,越来越少,越来越快,
嗯,就这样吧…回去睡觉了..