`

android客户端同时加入wifi定位

阅读更多
在3.0 版本中,终于决定新加入了Wifi定位,虽然使用Wifi定位在原来的版本中一直都有,但更多使用的是系统的Wifi定位,在一些国产的手机上,Android系统的Wifi定位多数被阉割掉了,遇到手机不插入SIM卡,或者使用一些被阉割掉Wifi定位Android Pad,使用我们自己的Wifi定位似乎就是唯一的手段。

    先列一下对Wifi定位的一些基本问题,回答完问题后就可以动手Coding。
(1)Wifi定位是否要使用Cache?
(2)Wifi定位和已使用的基站定位的关系是什么?
(3)由于使用的是单MAC地址的Wifi定位,那么选取周围无线信号中哪个Wifi信号做定位?
(4)同一个Wifi MAC地址失败后,是否应该再进行重复的网络请求?

    第一个问题,Wifi定位如基站定位一样,需要使用Cache,但Cache时不能缓存信号强度。单点Wifi的原理十分简单,根据一个固定的Wifi MAC地址,通过收集到的该Wifi热点的位置,来返回其所在的位置。因为一个Wifi热点其能覆盖的范围一般不大,使用单点的Wifi MAC地址定位,只要位置收集得比较准确,一般精度还是很高的。信号强度不放入缓存,因为在Wifi能覆盖到的范围内,信号强度应该是连续变化的,如果取信号强度作为缓存的一个Key,缓存的命中率就太低了。

    第二个问题,不再单独启动一个线程来进行Wifi定位的轮询了,就放在与基站定位相同的模块中;当基站定位不能正常工作时,再使用Wifi定位。那么如何判断基站定位不能正常工作?取不到基站ID,或者取到错误的基站ID,这个需要在调试中得到验证。

    第三个问题,肯定使用信号最强的Wifi,作为定位的Wifi,这是最合理的,那么在取到的所有Wifi MAC地址的数组中,需要按信号强度进行一下排序,取出强度最大的那个。

    第四个问题,是一个相当关键的问题。我们目前Wifi的数据库并不十分完整,同时每天也会有很多新的Wifi设备被使用出来,那么一旦遇到我们数据库中没有的Wifi MAC地址,我们势必不能让定位的线程一直不停的请求下去,请求一个无法定位的Wifi MAC地址,请求多少遍也不可能返回定位结果。而且若不停的请求,势必对手机电池的消耗会非常大,因此当定位失败后,一定不能再去进行相同的请求。另一方面,如果是定位成功了,也同样无需对相同的Wifi MAC地址进行请求。(PS:我们其他的客户端曾经犯过这样的错误)

    开始动手写代码,很顺利,先把原来基站定位的代码结构Copy过来,还是使用保存上次Wifi MAC地址的方法来确定是否要做一个新的Wifi定位的请求。在判断无法使用基站定位时遇到一点经验。当使用Google Nexus One时,如果把手机SIM卡拔出,使用CellLocation的getCellLocation()方法,返回的值为null,那么当为null时就使用Wifi定位;但使用Moto的XT800,由于XT800是双模双待,当既不插GSM卡,也不插CDMA卡时,使用CellLocation的getCellLocation()方法,返回的值并不为null,并且还为CdmaCellLocation的子类。那么进一步取sid,nid和bid,结果发现所有的值都为0,那么此时也应该启动Wifi定位的异步任务。

    信号强度也比较有意思,使用Google Nexus One获得的一个ScanResult的List,已经是有序的,信号强度最大的排在最前面;但XT800确正好相反,也是有序的,但信号强度最小的确排在最前面。本想偷个懒,比较一下数组的第一位和最后一位哪个信号强度更大,就使用哪个,在这两款手机上就都没问题了。但后来为了避免万一有什么山寨的Android系统没排序怎么办呢?还是辛苦一点吧,使用Collections的sort()方法取出信号强度最大的一个Wifi MAC地址来进行定位。

    当然,单点的Wifi定位还是有相当的缺陷,其实信号强度的数值也并没有真正用起来,目前业内主流的Wifi定位应该还是多Wifi的定位,让我们尽快完成优化吧!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics