企业官网建设流程全解析

1. 项目概述：为什么要在 Android 手机上用 adblib 控制 Android 9 开发板？

你有没有遇到过这样的场景：手边只有一台 Android 手机，却需要临时调试一块刚焊好的 Android 9 开发板——没有电脑、没有 USB 线、开发板又没接显示器，连串口都得翻箱倒柜找转接器？这时候，如果手机能直接当“无线调试终端”用，通过 Wi-Fi 连上开发板执行adb shell、安装 APK、抓取 logcat、甚至重启系统，那整个嵌入式调试流程就从“等电脑开机→装驱动→配环境→连设备”压缩成“打开 App → 点一下连接 → 开始操作”。这不是设想，而是真实可行的轻量级远程 ADB 方案，核心就是Android 手机作为 ADB 客户端，通过 adblib 库实现纯 Java 层的 ADB 协议解析与 Wi-Fi 通信，直连运行 Android 9 的开发板。

这个方案的关键字非常明确：Android、adblib、ADB、Wi-Fi、Android 9。它不依赖 PC 端 adb server，不走传统adb connect <ip>:5555的命令行路径，而是把 ADB 协议栈“移植”进 Android App 内部，让手机自己完成设备发现、密钥认证、数据包封装与解包、流控管理等全套逻辑。尤其针对 Android 9（Pie）开发板，它的 ADB over Wi-Fi 实现已趋于稳定（adb tcpip 5555可靠），但默认只允许来自同一局域网的 TCP 连接，且需手动开启——而 adblib 正好补上了“手机端主动发起、免 root、无需预装调试桥接服务”的最后一环。适合三类人：嵌入式现场工程师（带一块板子跑客户现场，手机就是调试台）、教育场景教师（课堂演示时避免来回插拔线缆）、以及 Android 应用开发者（想绕过 Studio 直接在真机上快速验证底层服务行为）。它不是替代 Android Studio 的完整开发流，而是解决“最后一米”连接断点的务实工具。

我第一次在珠海某工业网关项目里用上这套方案，是为了解决客户产线测试工位无法接入 PC 的问题。开发板固定在金属机柜里，USB 口被封死，Wi-Fi 是唯一可用通道。当时试了五种方案：Termux + adb binary（失败，ARM64 adb 在 Android 11+ 上因 SELinux 策略拒绝执行）、第三方 ADB App（大多只支持 USB 或需 root）、自建 WebSocket 中继（延迟高、不稳定）……最后咬牙啃完 adblib 源码，硬是在一个 200 行核心逻辑的 Kotlin Activity 里跑通了shell:ps | grep zygote和install /sdcard/app-debug.apk。实测下来，从点击连接到返回进程列表，平均耗时 820ms（局域网千兆环境），比用电脑开 adb server 快 3 秒——因为省掉了 adb daemon 启动、端口监听、设备枚举三个环节。这不是炫技，是真正把调试动作从“准备阶段”压缩进“操作瞬间”。

2. 整体设计思路与技术选型依据

2.1 为什么放弃传统 adb 命令行，选择 adblib？

很多人第一反应是：“手机上装个 Termux，再pkg install android-tools不就完了？”——理论上成立，但实际踩坑极多。我在深圳一家车载中控厂商做驻场支持时，连续两周被这个问题卡住：他们用的是 Android 9.0 定制 ROM，SELinux 设置为 enforcing，而 Termux 安装的adb二进制文件被标记为u:r:untrusted_app:s0:c512,c768，无法绑定 5037 端口或发起 TCP 连接，报错Permission denied (os error 13)。即使降级到 Android 8.1，也常因/system/bin/adb被厂商移除或阉割导致command not found。更麻烦的是，adb connect命令本身依赖本地 adb server 进程维持长连接，而 Termux 的后台保活能力在国产 ROM（如 MIUI、EMUI）下极差，切到后台 30 秒内就被系统杀掉，连接直接中断。

adblib 的价值正在于此：它是一个纯 Java/Kotlin 编写的 ADB 协议实现库（GitHub star 1.2k+，最新版 v1.0.0），不依赖任何 native 二进制，所有协议解析、加密握手、数据分帧都在 JVM 层完成。它把 ADB 协议拆解为四个可插拔模块：

• AdbConnection：负责 TCP Socket 建立、超时控制、重连策略；
• AdbDevice：抽象设备状态（online/offline）、序列号、产品名等元数据；
• AdbCommand：封装host:features、host:transport:<serial>、shell:等标准 ADB 命令构造逻辑；
• AdbStream：处理双向数据流，自动识别OKAY/FAIL响应头，支持shell流式输出和sync文件传输。

最关键的是，它完全绕开了adb server这一中间层。传统流程是：Client → adb server（5037）→ Device；而 adblib 是 Client → Device（直接 TCP），相当于把 server 的核心逻辑“压扁”进了客户端。这带来三个硬性优势：

1. 无依赖：不需预装 adb、不需 root、不需修改系统属性；
2. 低延迟：少一次进程间通信（IPC），实测shell:ls /命令端到端耗时降低 40%；
3. 可控性强：可精确捕获每个数据包的收发时间、重传次数、密钥协商失败原因，便于现场排障。

提示：adblib 并非万能。它不支持adb backup（需 full backup 权限）、不支持adb reverse（Android 5.0+ 引入，需 kernel 支持），也不处理adb key的持久化存储（需 App 自己实现~/.android/adbkey读写）。这些限制恰恰是选型时必须清醒认知的边界。

2.2 为什么锁定 Android 9 开发板？版本兼容性如何落地？

Android 9 是 ADB over Wi-Fi 的分水岭版本。在此之前（Android 7.0–8.1），Wi-Fi ADB 存在两个致命缺陷：一是adb tcpip <port>命令执行后，设备仅监听 IPv4 地址，若开发板启用 IPv6（如某些 Rockchip 方案），手机可能因 DNS 解析优先返回 IPv6 地址而连接失败；二是密钥认证流程存在 race condition，多次快速重连易触发device unauthorized状态，需手动点击授权弹窗——而开发板无屏幕，根本无法确认。

Android 9 修复了上述问题：

• adb tcpip默认同时监听0.0.0.0:5555和[::]:5555，兼容双栈；
• 引入adb pair机制（虽本项目未用，但说明协议栈已成熟）；
• 授权弹窗逻辑下沉至adbd进程内部，支持adb connect时自动接受已知公钥（需提前将手机公钥注入开发板/data/misc/adb/adb_keys）。

我们实测了 7 款主流 Android 9 开发板（RK3399、i.MX8MQ、Allwinner H6、Amlogic S905X2、Qualcomm QCS605、MTK MT8167、Exynos 5422），全部可通过adb tcpip 5555正常启用 Wi-Fi 调试。其中 5 款（RK3399、i.MX8MQ、H6、S905X2、QCS605）出厂即开放ro.adb.secure=0，无需额外设置；另 2 款（MT8167、Exynos）需在build.prop中添加persist.service.adb.enable=1并重启。特别注意：所有测试均关闭 SELinux（setenforce 0），这是工业场景常见做法，若必须保持 enforcing，则需为adbd添加net_admincapability（adb shell su -c 'setcap cap_net_admin+ep /system/bin/adbd'），否则 Wi-Fi 绑定会失败。

注意：adblib 对 Android 版本无强依赖，它只与 ADB 协议版本交互。Android 9 使用 ADB 协议 v40（对应adb version 1.0.40），而 adblib v1.0.0 完全兼容该协议。我们曾用同一套手机 App 成功连接 Android 11 开发板（协议 v41），仅需调整AdbConnection中的MAX_PAYLOAD_SIZE从 256KB 改为 4MB（Android 11 允许更大 payload），证明其协议扩展性良好。

2.3 Wi-Fi 连接模式选型：直连 vs 路由器中继，哪种更适合开发板场景？

开发板调试场景中，Wi-Fi 连接方式只有两种：手机与开发板直连（Wi-Fi Direct 或 Ad-hoc），或两者接入同一路由器（Infrastructure 模式）。我们实测对比了三种拓扑：

结论很清晰：首选“同一企业路由器”模式。原因有三：

1. 开发板固件无需修改：绝大多数 Android 9 开发板默认启用 DHCP Client，插上网线或连 Wi-Fi 后自动获取 IP，无需烧写新镜像；
2. 规避 Wi-Fi Direct 兼容性黑洞：Android 9 对 Wi-Fi Direct 的P2P_DEVICE_DISCOVERED广播支持不一致，小米/华为手机常收不到开发板广播，而路由器模式完全不涉及 P2P 协议栈；
3. IP 可预测，利于自动化：通过路由器 DHCP 保留功能，可将开发板 MAC 地址绑定固定 IP（如192.168.1.100），手机 App 启动时直接连接该地址，省去设备发现环节。

我们曾为某安防摄像头客户部署该方案，其产线使用 Ubiquiti UniFi 路由器。我们在控制器后台为每块开发板配置 DHCP 保留（MAC → 192.168.1.101~192.168.1.150），手机 App 启动后按序 ping 这 50 个地址，首个响应者即为目标设备。实测 50 台并发连接，平均发现时间 2.1s，成功率 100%。这比扫描整个 C 段（254 个地址）快 12 倍，且不产生网络风暴。

3. 核心细节解析与实操要点

3.1 adblib 集成：Gradle 依赖、权限声明与初始化陷阱

集成 adblib 到 Android 项目并非简单添加一行implementation。由于它基于 Java NIO 和java.net.Socket，在 Android 10+ 上需特别处理网络权限与线程模型。以下是经过 12 个不同 Android 版本（8.0–13）实测验证的最小可行配置：

第一步：添加依赖与仓库
在项目根目录build.gradle中确保包含 Maven Central：

allprojects { repositories { google() mavenCentral() // 必须！adblib 发布于 Maven Central } }

在模块app/build.gradle中添加：

dependencies { implementation 'com.github.williamd1984:adblib:1.0.0' // 注意：不要添加 'androidx.core:core-ktx' 等无关依赖，adblib 无 androidx 依赖 }

第二步：声明必要权限
AndroidManifest.xml中必须声明：

<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <!-- Android 12+ 需要查询网络状态 --> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> <!-- 用于获取当前 Wi-Fi SSID，辅助判断是否在同一网络 -->

注意：无需ACCESS_FINE_LOCATION。早期文档误传 adblib 需定位权限来扫描 Wi-Fi，实则它只用WifiManager.getConnectionInfo().getIpAddress()获取本机 IP，与位置无关。我们在 OPPO Find X5（Android 12）上移除该权限后，连接成功率仍为 100%，但应用商店审核通过率提升 40%。

第三步：初始化 adblib 并规避主线程阻塞
adblib 的AdbConnection构造函数会尝试解析adb version字符串（用于协议协商），若在主线程调用，可能因 DNS 查询卡顿。正确做法是：

// 在 Application 或 MainActivity.onCreate() 中 val adbConnection = AdbConnection( host = "192.168.1.100", // 开发板 IP port = 5555, timeoutMs = 5000 ) // 但绝不在此处调用 adbConnection.connect() // 而是交给协程或 HandlerThread lifecycleScope.launch { try { adbConnection.connect() // 此处才真正建立 TCP 连接 // 连接成功回调 } catch (e: Exception) { // 处理 Connection refused / Timeout 等 } }

我们曾因在onCreate()直接调用connect()导致 MIUI 13 系统 ANR（Application Not Responding），日志显示main thread blocked on socket.connect()。根源是 MIUI 的ConnectivityManager在弱网下会延长 DNS 超时至 10s。解决方案是：所有connect()、executeCommand()必须在 IO 线程执行，推荐使用lifecycleScope.launch(Dispatchers.IO)。

3.2 设备认证流程详解：如何绕过“device unauthorized”弹窗？

这是整个方案最易卡壳的环节。当你执行adbConnection.connect()后，adblib 会发送host:track-devices命令，若开发板返回offline或unauthorized，说明密钥未配对。传统做法是“用电脑连 USB，弹窗点允许”，但开发板无屏，此路不通。

根本解法是预注入公钥。Android ADB 认证本质是 RSA 密钥交换：手机生成密钥对（adbkey/adbkey.pub），将公钥内容写入开发板/data/misc/adb/adb_keys文件，adbd进程启动时自动加载。adblib 本身不生成密钥，需 App 自行实现。

我们采用以下轻量方案（无需 root）：

1. 在手机 App 首次启动时，用KeyPairGenerator生成 2048 位 RSA 密钥对；
2. 将公钥（PEM 格式，-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----）保存至Context.getExternalFilesDir(null)/adbkey.pub；
3. 通过adbConnection.executeCommand("shell:echo '$pubKey' >> /data/misc/adb/adb_keys")写入开发板。

但此命令需shell权限，而unauthorized状态下adbd拒绝执行任何shell命令。破局点在于：adb connect命令本身会触发一次密钥交换握手，即使未授权，adbd也会返回设备公钥。adblib 的AdbDevice类提供了getPublicKey()方法，可提取该公钥。

实操步骤：

// 步骤1：建立未认证连接 adbConnection.connect() // 此时设备状态为 unauthorized val device = adbConnection.getDevices().firstOrNull { it.serial == "192.168.1.100:5555" } val devPubKey = device?.getPublicKey() // 获取开发板公钥（非手机公钥！） // 步骤2：用开发板公钥加密手机私钥，构造认证请求 val encryptedPrivKey = encryptWithRsa(devicePrivateKey, devPubKey) // 步骤3：发送认证请求（adblib 不内置此逻辑，需手动构造 ADB 数据包） val authPacket = buildAuthPacket(encryptedPrivKey) adbConnection.send(authPacket)

实操心得：我们最终放弃手动构造认证包，改用更鲁棒的方案——在开发板固件编译阶段，将手机公钥硬编码进adb_keys。具体是在device/rockchip/rk3399/BoardConfig.mk中添加：

ADDITIONAL_DEFAULT_PROPERTIES += ro.adb.secure=0 # 将手机公钥存为 assets/adbkey.pub，编译时复制到 /data/misc/adb/adb_keys PRODUCT_COPY_FILES += \ device/rockchip/rk3399/adbkey.pub:root/adbkey.pub

然后在init.rc中添加：

on property:sys.boot_completed=1 exec - /system/bin/sh -c "cp /adbkey.pub /data/misc/adb/adb_keys; chmod 600 /data/misc/adb/adb_keys"

这样每块开发板上电即完成认证，手机 App 连接成功率从 65% 提升至 100%。

3.3 核心命令封装：shell、install、logcat 的差异化实现

adblib 提供了基础executeCommand()方法，但直接调用shell:ls /会返回原始字节流，需自行处理\r\n换行、UTF-8 解码、流结束标识。我们封装了三层 API：

第一层：同步命令（适合短时操作）

fun AdbConnection.execShellSync(command: String): String { val response = executeCommand("shell:$command") return String(response.data, Charsets.UTF_8).trim() } // 示例：val result = adbConnection.execShellSync("getprop ro.build.version.release") // 返回 "9"

第二层：流式 Shell（适合长命令，如 top、logcat）

fun AdbConnection.execShellStream( command: String, onOutput: (String) -> Unit, onError: (String) -> Unit ) { val stream = executeCommand("shell:$command") val reader = BufferedReader(InputStreamReader(stream.inputStream)) Thread { try { var line: String? while (reader.readLine().also { line = it } != null) { onOutput(line!!) } } catch (e: IOException) { onError(e.message ?: "Stream closed") } }.start() } // 示例：adbConnection.execShellStream("logcat -t 100", ::println) // 抓取最近 100 行日志

第三层：APK 安装（处理 sync 协议）
install命令需走 ADB 的sync协议（非shell），adblib 的AdbSync类已封装。关键点是：

• APK 文件必须先 push 到/data/local/tmp/（开发板有写权限）；
• 再执行install /data/local/tmp/app.apk；
• 最后清理临时文件。

我们封装为：

suspend fun AdbConnection.installApk(apkFile: File) { val tmpPath = "/data/local/tmp/${apkFile.name}" // Step 1: Push APK via sync AdbSync(this).push(apkFile, tmpPath) // Step 2: Install val installResult = executeCommand("shell:pm install -r $tmpPath") if (!installResult.data.contains("Success".toByteArray())) { throw RuntimeException("Install failed: ${String(installResult.data)}") } // Step 3: Clean up executeCommand("shell:rm $tmpPath") }

注意：pm install在 Android 9 上默认拒绝安装来自/data/local/tmp/的 APK（安全策略），需在开发板执行adb shell settings put global verifier_verify_adb_installs 0关闭验证。我们将其写入开发板启动脚本，确保每次开机生效。

4. 实操过程与核心环节实现

4.1 开发板端完整配置清单（Android 9）

配置开发板是整个链路的基石。我们整理出一份经 7 款芯片平台验证的最小可行配置清单，所有操作均通过adb shell（USB 连接首次配置）完成：

1. 启用 Wi-Fi 并连接路由器

# 连接到指定 SSID（假设路由器 SSID 为 "Factory-WiFi"，密码 "12345678"） adb shell svc wifi enable adb shell am startservice -n com.android.settings/.wifi.WifiSettings # 注：此命令仅触发 UI，实际需用 wpa_cli 配置（推荐） adb shell wpa_cli -i wlan0 add_network adb shell wpa_cli -i wlan0 set_network 0 ssid '"Factory-WiFi"' adb shell wpa_cli -i wlan0 set_network 0 psk '"12345678"' adb shell wpa_cli -i wlan0 enable_network 0 adb shell wpa_cli -i wlan0 save_config

2. 获取并固化 IP 地址

# 查看当前 IP（通常为 DHCP 分配） adb shell ifconfig wlan0 | grep "inet addr" # 若需静态 IP（如 192.168.1.100），修改 init.rc 或使用： adb shell su -c 'setprop dhcp.wlan0.ipaddress 192.168.1.100' adb shell su -c 'setprop dhcp.wlan0.gateway 192.168.1.1' adb shell su -c 'setprop dhcp.wlan0.dns1 192.168.1.1' # 重启网络服务 adb shell svc wifi disable && adb shell svc wifi enable

3. 开启 ADB over Wi-Fi 并加固认证

# 关键：关闭 adb 安全检查（Android 9 默认开启） adb shell su -c 'setprop service.adb.root 1' adb shell su -c 'setprop persist.sys.usb.config adb,mtp' adb shell su -c 'setprop ro.adb.secure 0' # 启用 TCP 模式（端口 5555） adb shell su -c 'setprop service.adb.tcp.port 5555' adb shell su -c 'stop adbd && start adbd' # 验证：adb shell getprop service.adb.tcp.port 应返回 5555

4. 预置 ADB 公钥（永久生效）

# 创建 adb_keys 目录（若不存在） adb shell su -c 'mkdir -p /data/misc/adb' # 将手机公钥（已生成）写入（假设公钥内容为 "AAAAB3NzaC1..."） adb shell su -c 'echo "AAAAB3NzaC1..." > /data/misc/adb/adb_keys' adb shell su -c 'chmod 600 /data/misc/adb/adb_keys' # 重启 adbd 生效 adb shell su -c 'stop adbd && start adbd'

5. 关闭 SELinux（工业场景必需）

# 永久关闭（修改 fstab 或 kernel cmdline） adb shell su -c 'setenforce 0' adb shell su -c 'getenforce' # 应返回 Permissive # 若需永久生效，在 BoardConfig.mk 中添加： # BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive

实操心得：我们曾为某医疗设备客户配置 RK3399 开发板，因忘记执行setenforce 0，导致adbd无法绑定 5555 端口，错误日志为avc: denied { name_bind } for ... scontext=u:r:adbd:s0。排查耗时 3 小时，最终在dmesg中发现 SELinux 拒绝记录。教训是：所有 Android 9 开发板调试前，第一件事就是adb shell getenforce，非 Permissive 状态一律不进行后续操作。

4.2 手机端 App 核心代码实现（Kotlin）

以下是一个精简但完整的AdbController类，涵盖连接、命令执行、日志抓取三大功能，已在 Android 8.0–13 全系列机型实测通过：

class AdbController(private val context: Context) { private lateinit var adbConnection: AdbConnection private var isConnecting = false fun connectToDevice(ip: String, port: Int = 5555) { if (isConnecting) return isConnecting = true lifecycleScope.launch(Dispatchers.IO) { try { adbConnection = AdbConnection(ip, port, 5000) adbConnection.connect() // 验证连接状态 val devices = adbConnection.getDevices() if (devices.isEmpty()) { throw Exception("No device found") } val device = devices.first() if (device.state != AdbDevice.State.ONLINE) { throw Exception("Device state: ${device.state}") } withContext(Dispatchers.Main) { // 连接成功回调 onConnected(device.serial) } } catch (e: Exception) { withContext(Dispatchers.Main) { onError(e.message ?: "Connect failed") } } finally { isConnecting = false } } } fun execShellCommand(command: String, callback: (String) -> Unit) { lifecycleScope.launch(Dispatchers.IO) { try { val response = adbConnection.executeCommand("shell:$command") val output = String(response.data, Charsets.UTF_8).trim() withContext(Dispatchers.Main) { callback(output) } } catch (e: Exception) { withContext(Dispatchers.Main) { callback("Error: ${e.message}") } } } } fun startLogcat(callback: (String) -> Unit) { val process = ProcessBuilder("logcat", "-v", "time", "-b", "main", "-b", "system") .redirectErrorStream(true) .start() val reader = BufferedReader(InputStreamReader(process.inputStream)) Thread { try { var line: String? while (reader.readLine().also { line = it } != null) { withContext(Dispatchers.Main) { callback(line!!) } } } catch (e: IOException) { withContext(Dispatchers.Main) { callback("Logcat stopped: ${e.message}") } } }.start() } }

关键细节说明：

• lifecycleScope确保协程随 Activity 生命周期自动取消，避免内存泄漏；
• ProcessBuilder启动logcat是为了获得更完整的日志（adblib 的shell:logcat会受adbd输出缓冲区限制，常截断）；
• 所有网络操作严格限定在Dispatchers.IO，UI 更新在Dispatchers.Main，符合 Android 最佳实践。

4.3 网络连通性自检与故障定位工具

现场调试最怕“连不上”，却不知卡在哪一环。我们内置了一套四层自检工具，按顺序执行：

我们将其封装为NetworkDiagnoser类，用户点击“诊断”按钮后，自动按序执行并高亮失败项。例如，若 L2 失败，界面显示：“❌ 端口不可达：开发板未启用 ADB over Wi-Fi，请执行adb shell setprop service.adb.tcp.port 5555 && adb shell stop adbd && adb shell start adbd”。

实操心得：在东莞某工厂部署时，客户反馈“App 连不上”，我们远程指导其运行 L1 检查，发现ping丢包率 100%。进一步排查发现，开发板 Wi-Fi 模块固件版本过旧（v2.1），升级至 v3.4 后问题解决。这说明：硬件层问题永远优先于软件层，自检工具必须从最底层开始。

5. 常见问题与排查技巧实录

5.1 连接超时（TimeoutException）的 5 种根因与对策

TimeoutException是最高频报错，表面看是网络慢，实则涉及 5 个独立子系统。我们按发生概率排序并给出对策：

1. 开发板adbd未监听 Wi-Fi 端口（概率 45%）

• 现象：ping通，但telnet 192.168.1.100 5555拒绝连接；
• 根因：service.adb.tcp.port未设置或adbd未重启；
• 对策：

  adb shell getprop service.adb.tcp.port # 应返回 5555 adb shell getprop init.svc.adbd # 应返回 running # 若非 running，强制重启 adb shell su -c 'stop adbd && start adbd'

2. 手机与开发板不在同一子网（概率 25%）

• 现象：ping不通，ipconfig显示手机 IP 为192.168.43.x（热点），开发板为192.168.1.x（路由器）；
• 根因：手机连了自身热点，而非目标路由器；
• 对策：在 App 启动时强制检查：

  val wifiManager = context.getSystemService(Context.WIFI_SERVICE) as WifiManager val ip = wifiManager.connectionInfo.ipAddress val subnet = ip shr 8 // 192.168.1.100 → 192.168.1 if (subnet != 192 * 0x10000 + 168 * 0x100 + 1) { Toast.makeText(context, "请连接 Factory-WiFi 网络", Toast.LENGTH_LONG).show() }

3. Android 12+ 后台网络限制（概率 15%）

• 现象：App 切后台后连接失败，前台正常；
• 根因：Android 12 引入RESTRICTED_BACKGROUND_ACTIVITY_STARTS，限制后台启动 Service；
• 对策：在AndroidManifest.xml中为AdbService添加：

  <service android:name=".AdbService" android:exported="false" android:foregroundServiceType="specialUse" />

  并在启动时调用startForegroundService()。

4. adblib 超时参数过小（概率 10%）

• 现象：在弱网环境（如工厂车间）偶发超时；
• 根因：默认timeoutMs = 5000不足以应对高延迟；
• 对策：动态调整超时：

  val rtt = calculateRtt("192.168.1.100") // 自定义 ping 工