企业官网建设流程全解析

简介：Android平台开发的一款网络连接质量测试工具源码，面向移动开发初学者与需要验证WiFi环境稳定性的测试人员，涵盖上传文件速度测试、下载文件速度测试与ping测试三大功能模块，界面可直观查看测试过程，测试结果支持保存到文件，核心实现涉及Apache HttpClient类库及对系统ping命令的封装调用，便于理解Android网络编程与命令行交互思路。压缩包共45个文件，以Java源码、XML配置布局及PNG界面资源为主，辅以JAR依赖库与工程配置文件，整体大小仅3.51MB，代码结构清晰、上手门槛低。目前已有1293人学习下载。借助这份源码，可以掌握HttpClient进行文件传输测速的写法、ping测试结果的解析处理、测试数据落盘存储，以及多分辨率屏幕适配与values目录资源组织方式，是一份适合作为课程设计或日常自测工具的实战参考。 搞Android开发的兄弟多半都经历过这种场面——现场报障说设备连不上WiFi，或者信号满格但网速慢得自闭。你带着笔记本跑过去，先看路由器后台，再拿手机下个测速软件，来回切工具折腾一下午。去年我在项目上被这类问题连续折腾几次后，索性用Android开发了一个WiFi网络测试小工具，把信号扫描、强度换算、延迟抖动、带宽测速这些日常排障手段集中到一部手机上，现场拿着就能直接开测。

这个工具适合三类人：无线网络验收与排障的工程人员，做IoT设备需要现场验证连接质量的开发者，以及想摸清家里WiFi底细的普通用户。核心功能我控制在四块：信号扫描分析、连接质量监控、下载/上传带宽测速、测试结果导出。功能不追求大而全，但每一块都奔着解决实际排障问题去。

1. 功能定位：这个工具到底解决什么问题

1.1 现场排障的痛点复盘

先回顾一下我为什么非要做这个工具。有次在现场排查设备频繁掉线的问题，初步判断是AP信号弱，但我手边只有一台手机和一个笔记本。拿手机看WiFi设置里的信号格数，只有四格和三格的区别；打开浏览器跑在线测速，结果受公网带宽影响很大，根本判断不了是局域网的问题还是外网的问题。最后来回换了好几个App，有的测延迟不准，有的不展示RSSI数值，折腾了很久才定位到是某台AP的信道和隔壁公司的网络冲突。

这个经历让我意识到，市面上缺少一个专注“无线侧”而不是“互联网侧”的测试工具。我们要回答的问题是：终端到AP这一段到底健不健康，信号强度多少、延迟抖不抖、丢包率多少、带宽能不能跑满。这些数据都应该在一台Android手机上直接拿到，不需要再背一台电脑。

1.2 四个核心功能模块

工具按模块划分成四块，每块负责一类指标：

• 信号扫描分析：列出周围所有可见SSID/BSSID，展示RSSI、频段、信道、加密方式，并给出信号等级和百分比换算。
• 连接质量监控：对当前连接的WiFi做连续延迟、抖动、丢包统计，目标默认是路由器网关，也可以自定义IP或域名。
• 带宽测速：分下载和上传两部分，用多并发连接做吞吐测试，结果实时显示。
• 测试记录导出：每次测试结束后生成CSV记录，包含时间戳、信号、各项网络指标，方便后续对比。

模块之间相互独立，测试记录模块负责汇总所有结果。这样做的优势在于排障时可以按需跑单项，不用每次都跑完整套流程，定位问题也更快。

2. 信号强度测试：扫描与RSSI换算

2.1 扫描API与权限适配细节

信号扫描用的是WifiManager的startScan()，然后注册BroadcastReceiver接收SCAN_RESULTS_AVAILABLE_ACTION，这是最经典的流程。Android 6.0开始扫描WiFi必须持有定位权限，Android 13（API 33）之后如果targetSdk升级到33，还需要额外的NEARBY_WIFI_DEVICES权限，属于“附近设备”权限组，同样要运行时申请。

权限这块很容易踩坑，尤其是Android 13。权限都授了，但getScanResults()还是返回空列表，大多数情况是定位服务没打开，或者NEARBY_WIFI_DEVICES没申请。我在工具里做了一个权限自检页面，把定位开关、定位权限、附近设备权限、WiFi开关状态一次性列出来，排障时能省很多时间。

扫描结果里的关键信息就三样：SSID（网络名）、BSSID（AP的MAC地址）、level（RSSI信号强度，单位是dBm，负数）。此外从Android P开始，ScanResult还带了wifiStandard，能区分是WiFi 5还是WiFi 6。看一下典型代码：

WifiManager wifiManager = (WifiManager) getApplicationContext() .getSystemService(Context.WIFI_SERVICE); wifiManager.startScan(); // 在 BroadcastReceiver 中处理结果 List<ScanResult> results = wifiManager.getScanResults(); for (ScanResult result : results) { String ssid = result.SSID; String bssid = result.BSSID; int rssi = result.level; int standard = result.wifiStandard; // 这里的 rssi 就是我们要的信号强度核心数据 }

2.2 RSSI换算成百分比的算法

RSSI数值是一个负数，范围通常在-100 dBm到-30 dBm之间。直接用负数展示没问题，但很多非技术同事看不懂。换算成百分比更直观，业界常用公式是：

percentage = (rssi + 100) / 60 * 100

这个公式暗含一个假设：RSSI达到-40 dBm以上就认为信号满格，低于-100 dBm就认为信号0。从工程角度看，这个范围映射基本够用，但它只是“看起来舒服”的百分比，实际信号链路质量还跟具体芯片、天线、环境有关。同一台路由器，不同品牌手机在同一个位置测出的RSSI可能差5到10dBm，这是设备天线和射频调校的差异，不代表实际体验差那么多。

所以做报告导出时，我会把原始RSSI、百分比、设备型号一起记录下来，避免单纯看百分比误导判断。

2.3 扫描频率限制与优化方案

这里必须提醒一下：startScan()这个接口不是想调就调的。Android 9之后系统限制了扫描频率，30秒内只能发起4次，超出的请求会被静默丢弃，日志里会有类似rate too high的提示。很多人写了循环扫描，结果发现数据永远不更新，其实就是触发了限流。

我的做法是持续扫描模式下强制间隔8秒发起一次，单次扫描模式下只发起一次请求并在3秒内等待结果。两者都符合系统限制，也不会频繁唤醒无线网卡，功耗可控。另外，拿扫描结果时不能只取一次，系统会缓存上一次的扫描结果，要连续取两次并与时间戳对比，避免读到旧数据。

3. 延迟、抖动与丢包：连接质量监控

3.1 直接调ping有什么坑

延迟最直观的测法就是ping网关。Android系统自带/system/bin/ping，用Runtime.exec()拼参数执行，解析输出文本。比如：

ping -c 20 -W 1 192.168.1.1

输出里有两行很有用：一行是rtt min/avg/max/mdev，另一行是x% packet loss。直接用这组数据就能得到平均延迟、抖动指标（mdev）和丢包率。

但实际使用中会碰到几个坑。第一，部分设备的安全策略对普通应用调用ping有限制，尤其Android 10之后，非root进程发起ICMP可能被SELinux拦住，表现为命令执行了但拿不到输出，或者直接报错。第二，很多路由器和AP会屏蔽ICMP，ping不通不代表网络不通，不代表TCP连不上。所以我把ping作为默认手段之一，同时在界面上提供“TCP模式”选项，用TCP建连来测延迟。

3.2 基于TCP建连的延迟测量

TCP模式的核心思路是用Socket去连接目标IP的端口，通过计算三次握手完成耗时的均值来估算延迟。比如连192.168.1.1:443或者192.168.1.1:80，每轮连接之后关闭socket，重复20次取平均：

long start = System.nanoTime(); try (Socket socket = new Socket()) { socket.connect(new InetSocketAddress(host, port), 2000); long delayMs = (System.nanoTime() - start) / 1_000_000; // 记录 delayMs，计算均值 } catch (IOException e) { // 超时或拒绝，按丢包处理 }

这里有几个细节要注意：connect的超时建议设成2秒，目标无响应时不用干等；每轮一定要新建socket，因为测的就是握手成本；目标端口优先选80或443，这两个端口几乎不会主动拒绝连接。实测下来TCP建连延迟比ping略高1到3毫秒，因为多了端口和TCP栈的处理，这个偏差在无线环境下可以忽略。

3.3 抖动和丢包率的统计口径

抖动反映的是网络稳定性。简单做法是取连续N次延迟，计算相邻两次差值的绝对值，再取平均，单位毫秒。经验值如下：

丢包率统计要注意统计窗口。连续的10到20个包比较合适，太少偶然性大，太多测试时间太长。每个包超时1秒，举个例子，如果20个包里有两个超时，丢包率就是10%。这个丢包率在视频通话、在线会议场景是致命的，但看网页浏览可能感受不出来，所以要结合场景去判断。

4. 带宽测速：下载和上传的实现

4.1 下载测速中容易被忽略的变量

下载测速的逻辑很直观：从服务器下载一个固定大小的文件，记录耗时，相除得到速度。但直接跑会有一堆变量干扰结果。

服务器位置选择是第一个大坑。如果用公网测速点，出口带宽、运营商链路质量都会叠加进来，测出来的不光是你WiFi的问题。我的做法是默认提供两个测速目标：一个局域网内的HTTP服务（比如路由器后台的静态文件），一个公网测速点，跑完之后分开展示，方便区分是本段WiFi的问题还是出口链路的问题。

文件大小也是关键。TCP慢启动导致连接建立后前几百KB速度上不去，如果测试文件只有几百KB，测出来的速度会严重偏低。建议下载文件至少5MB，并抽中间稳定区间计算，而不是从头到尾平均。我这里用并发连接的方式进一步贴近真实使用场景：开4个线程同时下载，每个线程拉不同请求范围，最后把各线程速度相加。

核心伪代码大概是这样：

ExecutorService pool = Executors.newFixedThreadPool(4); List<Future<Long>> futures = new ArrayList<>(); for (int i = 0; i < 4; i++) { futures.add(pool.submit(() -> downloadChunk(url, i, chunkSize))); } long totalBytes = 0; for (Future<Long> f : futures) { totalBytes += f.get(); } double speedMbps = totalBytes * 8.0 / 1024 / 1024 / elapsedSeconds;

4.2 上传测速的模拟请求构造

上传测速不需要在服务端放文件，直接在客户端生成固定大小的内存数据，用HTTP POST发给服务端接口。数据内容用随机字节填充，避免服务器缓存命中导致虚高。客户端发出一个预期的Content-Length，服务端接收完计算耗时返回。实现时可以用HttpURLConnection或OkHttp的异步上传，数据块大小默认4MB，同样用2到4个并发流。

上传时要注意Android主线程不能做网络操作，代码要放线程池或者协程里跑。另外WiFi对上传的功率控制比较敏感，穿墙场景下上传速度比下载掉得厉害，这是无线链路本身特性，不是工具的问题。报告里最好把下载和上传分开记录，方便对比。

4.3 避免测速数据失真

测速结果不稳定的情况，我建议多测几轮取中位数，而不是取最大值。有一次测试某款手机，单轮下载速度波动30%，连跑5轮之后中位数收敛到稳定值。另外测试过程中尽量关闭后台联网应用，尤其是云同步和视频缓存这类占带宽的进程，它们会让数值明显偏低。如果发现结果始终跑不满，先看手机当前的链路速率（link speed），这个值在WifiInfo直接能拿到，如果链路速率只有几十Mbps，那带宽跑不上去就是正常的无线衰减，不是工具算法问题。

5. 真机适配与常见问题排查

5.1 扫描结果为空的两大元凶

我在测试阶段遇到最多的求助就是“扫描不到任何WiFi”。排下来九成是两种情况：一是定位权限没开，二是定位服务本身被关掉了。Android的WiFi扫描结果从系统层面就和定位绑定，只要定位服务关闭，getScanResults()返回空列表，而且在很多ROM上不会给出任何错误提示。

另一个易错场景是自定义ROM或极简ROM把WiFi扫描的底层驱动裁剪了。这个没有代码层面的通用解法，只能在工具里收集错误日志和系统属性，快速判断是权限问题还是ROM问题。

5.2 Android 13权限适配

如果你把targetSdk升到33，一定要检查NEARBY_WIFI_DEVICES权限。它在Manifest里声明后还要运行时申请，否则WiFi扫描接口照样返回空。更隐蔽的是，部分国产ROM对这个权限的处理方式不一致，同是Android 13系统，有的机型申请一次就能用，有的机型还要额外打开“附近设备”开关。工具的自检页面就专门排查这个，用户一眼能看出差哪个权限。

5.3 厂商ROM的后台限制

国产ROM的后台管理非常激进，工具切到后台之后WiFi扫描会被系统直接冻结。排障时经常遇到这种情况：工具在后台跑着连续监控，过几分钟切回来发现数据中断了。解决思路是把工具加入电池优化白名单，并且申请前台服务，让系统知道这是一个正在运行的测量任务。申请前台服务时需要指定一个可见的通知，说明正在测试网络。

5.4 测速数据失真怎么定位

测速结果偏低时，我一般按这个顺序排查：先看信号强度和当前链路速率，如果链路速率本身只有几十Mbps，那带宽跑不上去就是正常的；再看目标服务器是不是在局域网内，公网测速会受到运营商出口限制；最后再拿另一台手机做对比测试，排除被测设备本身的问题。这个排查顺序已经用在实际项目里很多次，每次都很快能定位到问题层级。

6. 一些个人体会和后续扩展方向

整套工具从原型到能用，我最深的体会是：无线测试工具的核心不是代码多炫，而是数据口径统一、可复现、可对比。同一个指标，前后两次测试的统计方式必须完全一致，不然报告就没有参考价值。这也是我坚持把原始RSSI、测试时间、设备型号、系统版本都落进CSV的原因——有了这些元数据，后续做问题回溯才靠谱。

后续如果继续扩展，我计划加入AP频段占用分析、信道干扰热力图，以及针对快速漫游切换的连续丢包监控。如果读者在实际开发中遇到了权限适配或者扫描限流方面的问题，欢迎一起交流，这些坑真的只有踩过才知道。

本文还有配套的精品资源，点击获取