用了几次安卓版的，感觉还不错，有时候一连来几辆车，可能会不太准，大部分时间还是比较准确的。
到站时间是实时变化的，前面堵车了时间也会延后，所以最大的意义也就是能够大概知道什么车什么时候到，比在哪儿一无所知的傻等要强一些；如果赶时间想要卡着点到什么地方，那还是地铁靠谱一点。
下一步希望能够多覆盖一些线路。然后感觉可以推出一个换乘查询的功能，比如计算一下所有的换乘站点和线路，看看从哪站下刚好可以赶上换乘的车，不用多等。
最理想的状况当然是每辆车都定点达到车站，不过在北京我觉得基本上可能性不大，除非在每条路上都划出公交车道。。。当然这样的话也不需要这个app了，直接在站牌上写上详细的时刻表就行了。
我们的安卓客户端里头需要加一个归属地显示的功能，要对比较多的号码进行归属地显示，实时查询还是慢了点，而且还要流量，只能通过本地数据库来查询。
做客户端的同事找了找资料，结果说不是人家的代码不开源就是数据文件格式不开放，无法自己生成，而且人家的数据文件也不小；如果直接把数据都放到安卓的SQLite数据库里头的话也很大，好几MB，而且查询起来也很慢，根本不可用。
于是俺就说那行吧，既然这样那就直接直接弄吧，手机号段都是连续的，这个可以利用一下。
首先假定有这样一些归属地的数据：
|
编号 |
区号 |
归属地 |
|
1 |
010 |
北京市 |
|
2 |
0311 |
河北省石家庄市 |
|
… |
全国一共大概应该有300多区号吧，这些数据可以放在一张表里头，这样先解决了固话归属地的问题，查起来速度应该也很快的。
然后再看手机的，比如说130这个号段的，1300000这个号段是北京的，1300311这个号段是石家庄的，那么就有一个叫130的二进制文件，每两个字节对应一个归属地的编号，也就是说130这个文件第0000个字节和0001个字节读出来转成一个int之后的值为1，然后去归属地表里查就可以知道是北京市；读第0311*2和0312*2+1个字节之后的值就是2，查出来归属地是石家庄的。这样的话每个手机归属地需要读一次文件和查一次数据库，但是读文件的时候是直接知道文件位移的，应该很快；数据库量小，查起来也很快，所以速度是有保障的。
再看数据文件大小，130有10000个号段，每个号段占2B，也就是说一共有20KB，全国13、15、18开头的三位数号段最多也就是30个，也就是说数据文件最多30个，大小最多600KB，再加上号段本来大部分是连续的，打包的时候可以压缩一下，估计可压缩率还是挺高的，压缩到100K以下都是有可能的。
其实总结以来就是一句话：把号段转成数字之后变成一个文件中的索引，这样就避免了查询。