对mmap的读性能和原生的RandomAccessFile的读性能做了一下对比，从时间上比较，耗时不足之前的400分之一。

直接读536870910大小的物理文件，耗时199532毫秒。
mmap之后，再按再同的频度读相同的数据，耗时484毫秒。

本以为在SSD下测试，RandomAccessFile的性能会好很多，跟mmap方式的差距也会减少，在windows的系统上实测结果大跌眼镜：
等了十分钟，位于SSD磁盘的半个G文件没读完。次数降两个数量级，即512M/100次，得到结果如下
[code]
直接读536870910/100大小的物理文件，耗时10499毫秒。
0: 读(77767859:9)=9(和:2415919095, 耗时:578ms)
1: 读(387167008:8)=8(和:2415919095, 耗时:562ms)
2: 读(457186802:2)=2(和:2415919095, 耗时:546ms)
3: 读(394128468:8)=8(和:2415919095, 耗时:530ms)
[/code]
SSD下的磁盘读比mmap后相差了1816倍，远低于在Linux服务器上的测试结果。

在Windows开发机的普通磁盘上测试结果，磁盘性能略好于SSD
[code]
直接读536870910大小的物理文件，耗时9923毫秒。
0: 读(177389691:1)=1(和:2415919095, 耗时:562ms)
1: 读(390411737:7)=7(和:2415919095, 耗时:578ms)
[/code]

备注一下测试过程和中间的内存和CPU的表现。

- 阅读剩余部分 -

用strace和perf的时候，直接把标准输出重定向到文件，发现无效。
把标准错误输出重定向到文件，才有效果。
比较奇怪，为什么strace和perf要把自己的输出用标准错误，而不是标准输出。

备忘一下重定向输出几个点
>覆盖式重定向。
>>追加式重定向。
1>代表重定向标准输出，1可以省略。
2>代表重定向标准错误。
1>&2代表把标准输出重定向到标准错误。

之前一直听到的说法：每次系统调用，都会导致一次上下文切换。
今天做了个简单测试，发现这种说法可能有问题。

测试分两步，先测试系统调用（System call）：

- 阅读剩余部分 -

持续投入了一段时间在Android的卫片离线地图上，经过了不少波折，简单总结一下。

- 阅读剩余部分 -

做互联网的，提到地图，就想到google，然后想到百度。
google的卫星地图在进行拼接的时候，每一块就这种图片：
http://mt3.google.cn/vt/[email protected]&hl=zh-CN&gl=CN&src=app&x=53975&y=24816&z=16&s=Galile
这个x、y是什么呢？就涉及到墨卡托投影，具体含义可以自行百度或google。

- 阅读剩余部分 -

上回书说到说mac地址，这次的其实还是同一个东东，只不过想自动收集周边的wifi及基站信息。
基站信息且不谈，wifi列表很有特点。
我的策略是当定位成功，发现离上次定位点超过50米时，记录下周边的wifi及基站列表。
用我的三星mega在城铁上测试，基站变化很及时，wifi列表存在刷新周期的问题：城铁跑了几公里，wifi列表取出来的还是同一批，这显然有问题。
临时用一个很低劣的手段处理：当发现本次的wifi列表跟上次完全相同时，忽略本次wifi列表采集。这样只会取位移变化达到条件时，第一条发现这批wifi的位置，相对来说更准确一些。
当然了，事情到这还没完。

- 阅读剩余部分 -