红米note3的wifi断流/假死
日常使用note3的时，比如长时间浏览网页，点击一个链接会卡住不动，在等待十几秒之后才恢复。第一反应是不是网络不好？但是这种情况常常出现之后，对比其他的手机，比如价格更便宜的更低端的红米2， note3出现频率太高了些。严重影响到了日常的使用，且将这个现象称之为wifi“断流”或者“假死”。
如何证明这个手机“断流”“假死”的状况，用最简单的对照试验，排除网络状况不好的因素。在同一个网络状况下，同一地点、同一时间段，用数据包测试工具ping来测试两个手机。对比两个手机的测试统计数据。最好你可以把两个手机都还原到出厂状态。
先将两个手机的自动锁屏关掉，这样手机会常亮，将两个手机的上网其他程序都关闭，连接上wifi，打开一个终端管理器，保持终端管理器的前台运行，同时输入ping x.x.x.x （x.x.x.x为路由器地址）开始测试。
采集大量样本更有说服力，可以将测试时间延长，最后中止ping程序，会输出测试统计结果。中止方法（音量减小键 和 c 一起按），有的输入法有预输入框的，需要把c选中输出来。
好了来看一下我的结果，这种情况很容易复现，也就不截图了。看不懂结果的可以看最后的统计方式以及解释。
低端的红米2统计结果：
--- 172.16.1.1 ping statistics ---
288 packets transmitted, 288 received, 0% packet loss, time 287825ms
rtt min/avg/max/mdev = 1.708/16.491/61.316/5.387 ms
红米note3的统计结果：
--- 172.16.1.1 ping statistics ---
284 packets transmitted, 284 received, 0% packet loss, time 283361ms
rtt min/avg/max/mdev = 1.259/31.079/979.544/94.374 ms
统计方式以及解释
ping是一个数据包测试小工具，可以测试网络的连通速度，原理就是发一个包（互联网控制消息协议 缩写为icmp）到另外一个主机，然后主机返回一个包，计算往返时间差。
每发一个数据包，得到返回的数据包，然后输出时间差，比如这一条：
64 bytes from 172.16.1.1: icmp_seq=286 ttl=128 time=16.3 ms
发给172.16.1.1 64字节的数据包，往返时间为16.3ms，另外icmp_seq是icmp队列，每发一个出去就增加一个，给包计数。比如icmp_seq=286 表示这是发的第286个包。 ttl是time to life的缩写，每个一个hop减一，变成0就丢弃。现在只是往自己内网的路由发送数据包，路径一样忽略之。
看看红米2的统计信息
--- 172.16.1.1 ping statistics --- 288 packets transmitted, 288 received, 0% packet loss, time 287825ms rtt min/avg/max/mdev = 1.708/16.491/61.316/5.387 ms
翻译如下：
ping 172.16.1.1的统计
共发送了288个数据包，接到返回288个，0%的丢失率，统计时长 287825毫秒，
往返时间（ms）最小值：1.708 平均值：16.491 最大值：61.316 平均差：5.387 ms
最后一个平均差反应了数据变动程度，值越大，说明越不稳定。
现在看看红米note3的：
rtt min/avg/max/mdev = 1.259/31.079/979.544/94.374 ms
平均差达到了94！还是刚刚刷的稳定版，想比如红米2的5.387 ms 来说，红米note3网络稳定程度可见一斑，简直就是不稳定，不能忍。
- - -
一些网友的截图反应，这个mdev的值基本上在80-110之间。
有的网友问mdev正常值是多少，或者其他值的正常值是多少。因为每个人的网络环境不一样，没有什么正常不正常的值，最好拿个其他的手机比一下。你就能看到差距，因为比较之后可以排除网络的因素。这样才能证明手机的网络的稳定性与其他手机的差距。
能优化吗？我试了试已经出了小半年的note2，也是存在断流问题的。更新到最新系统，一样不稳定。至于说和无线路由兼容，无线网络协议都是向下兼容的，还有说什么草案的，感觉更扯。
- - -
关于与无线路由的兼容性问题，因为并不懂，今天听到专业的网友提到了，说标准和兼容分开的。也许意思就是大家做东西不一定就完全遵守标准吧，就像浏览器一样不兼容w3c的很常见吧。说可以直接和PC wifi direct连接测试，排除路由的兼容原因。
- - -
和一个自称做过此款芯片手机开发，知道mt6795 wifi断流问题的人通了邮件，他说，断流和wifi辅助定位/后台扫描周围wifi相关，可是关闭了定位服务依然会出现大的延时。因为辅助定位依靠扫描周围wifi功能的，所以怀疑有app后台扫描周围wifi。
开始观察延时的变化情况。
观察延时的值可以发现，是有规律的，会大概50几个（正常每个20ms）左右就会出现一个大延迟的情况。
试了300个。大于100ms的：
No. ms
050 - 389
110 - 246
169 - 1421
170 - 421
187 - 579
208 - 1034
229 - 1163
230 - 154
288 - 421
289 - 313
为了观察延时增加是否和扫描有关，于是，一边手动扫描wifi，同时ping网关，延时增加到数百上千的频率很高，似乎扫描周围wifi确实可以影响延时。