网络检测 · App测完能看懂，才叫检测

结论：完全免费，没有内购，也没有广告。所有检测功能——包括一键检测、连续监测、路由追踪、DNS 解析检查和 Wi-Fi 信道分析——都不设付费墙。App 内没有开屏弹窗、没有信息流广告位，也不会为了推送广告索取额外权限。我们不在应用内向用户收取任何费用，后续如果推出可选的增值服务，会在更新说明里提前讲清楚，不会静默改变现有功能的使用条件。

结论：Android 8.0 及以上、iOS 14 及以上的设备都能安装。Android 侧对内存要求不高，2 GB 运行内存的设备也能正常跑完检测；iOS 侧支持 iPhone 与 iPad 通用版本。如果设备系统版本低于上述要求，安装时会被系统阻止，这不是 App 的限制，而是底层网络接口在旧系统上的行为不一致，强行适配会影响检测准确性，所以我们没有向下兼容。

结论：不读取、不存储、不上传你的通信内容。App 只做协议层面的探测——发送探测包、记录往返时间与时延波动，这个过程不涉及解析你的聊天记录、浏览记录或账号信息。检测结果默认只保存在本机，只有你主动点「导出报告」时才会生成一张图片，且由你自己决定发给谁。我们不在后台静默上传原始探测报文。想进一步了解可以看应用内的权限说明页，那里逐条列了每项权限的用途和拒绝后的影响。

结论：这是正常现象，测速结果受测速节点、接入方式、时段和无线环境四重影响。运营商宣传的带宽通常是接入线路的理论上限，而实测要经过无线信号衰减、路由器转发、测速服务器负载等环节。举个具体例子：同样是 500 Mbps 的宽带，用 5GHz 频段在路由器旁边测可能接近 400 Mbps，隔一堵墙用 2.4GHz 测可能只有 60 Mbps，两者都没「测错」，只是条件不同。建议固定同一接入方式、同一时段多测几次，看趋势而不是看单次数字。

结论：看用途。视频通话和在线游戏对抖动的敏感度高于延迟，网页浏览和下载对丢包更敏感。具体来说：延迟 30–60 ms 对绝大多数日常使用都够用；抖动超过 30 ms 时，通话会出现明显的「吞字」；丢包率持续高于 1% 时，网页会出现加载卡顿、图片加载不全。三项里如果只能修一项，优先修抖动和丢包，因为它们反映的是链路稳定性，而延迟高但稳定通常只是距离远。

结论：可以，而且比口头描述有效得多。报告里包含检测时间、接入方式、目标地址、各项数值和判断结论，运营商客服拿到后能快速判断是接入侧还是局端侧的问题。建议的做法是：在同一时段连续测三次，把三张报告一起发过去，说明「同一时段重复出现同样现象」，这样对方很难用「偶发波动」来回复。需要注意，报告反映的是检测当时的情况，不能替代运营商自己的专业诊断设备。

结论：安装包约 42 MB，安装后占用约 90 MB 左右；不检测时基本不耗电。App 没有常驻后台的监测服务，只有你主动点「开始检测」时才会调用网络接口，检测结束即释放。连续监测模式最长支持 10 分钟，期间会有持续的网络读写，耗电会略高于待机，但不会比看一集视频更费电。如果你不主动打开它，它是完全静止的。

结论：Android 侧在应用内检测更新或到本页重新下载安装包覆盖安装；iOS 侧通过 App Store 自动更新。更新不会清除本地保存的检测记录，因为记录存在独立的数据目录里。如果你跨大版本更新（比如 v2 升到 v3），第一次启动会做一次数据结构迁移，通常几秒钟完成。迁移期间请不要强行关闭 App，否则可能导致历史记录丢失。

结论：先排除三种常见干扰，再判断是不是 App 的问题。第一种是检测时后台有其他应用在占用网络，比如正在下载或同步照片；第二种是连接了 VPN 或代理，此时检测到的是代理链路而非本地链路；第三种是测速节点本身繁忙，建议换一个节点复测。排除之后如果结果仍然明显异常，可以在「设置 → 反馈」里提交检测记录，我们会排查是否是目标节点或探测策略的问题。我们不会为了让数字好看而调整算法。

结论：会有人看，而且我们优先处理带检测记录的反馈。反馈入口在应用内的「设置 → 意见反馈」，也可以直接发邮件到页面底部的客服邮箱。如果反馈的是功能异常，附上当时的检测记录和设备型号，能大幅缩短定位时间。功能建议我们都会记录，但不会承诺排期——做不到的事情我们不写进回复里。