统一控制与 RustDesk 远程性能对比：外网远程功能决定不做

我在做一个小工具叫统一控制（ UnitCtrl ），在电脑上看、控制家里的安卓，只走局域网（官网）。人在外面的时候，我一直用 RustDesk 远程。

用着用着有点嫌它：看不到画面到底晚了多少，也看不到刷新率。于是冒出个念头：干脆自己给统一控制做个外网远程，说不定能比它好？开工前先定了规矩：比 RustDesk 好就做，不如就算了。

怎么比：用同一把尺子

各家自己报的延迟算法不一样，不能直接比，所以我做了个笨办法：

• 远处那台安卓上开一个网页：一个毫秒时钟，上面一排黑白色块，是把当前的毫秒数编成二进制（第二排取反，用来自检读没读错）
• 电脑上用浏览器开同一个页面，和远程窗口并排放
• 每 0.5 秒截一次屏，程序读出截图里的两个条码一减，就是“从远端屏幕到我屏幕”的真实延迟。两台机器的时钟差另外量过，大约 33 毫秒，已经扣掉
• 两家轮流测：同一台电脑、同一台远端设备（没有硬件编码器，屏幕每秒最多 15 帧）、同一条网络（来回约 240 毫秒，带宽 1–3 Mbit/s ，晚上会抖）
• 页面三种：只有条码在变（像平时点点看看）、整屏都在动（像一直在滑）、一屏小字（看清晰度）。每组 25 张

结果

• 平时点点看看：RustDesk 中位数约 0.55 秒，最慢的 10% 约 0.86 秒；统一控制 0.84 秒 / 1.41 秒。RustDesk 赢
• 整屏一直在动：RustDesk 每秒只剩 2–3 帧，画面落后 20 多秒，而且越积越多；统一控制约 1.4 秒，一直稳着。这项我们赢，不过那台设备的 CPU 被测试页吃满了，这对 RustDesk 的软件编码最不利，不太公平
• 清晰度：同一屏小字，统一控制的笔画边缘锐度大约是 RustDesk 的 2.5 倍
• 网络变差的时候（带宽掉到约 1 Mbit/s ）：RustDesk 还是 0.5 秒左右；统一控制越积越多，最多落后 37 秒

为什么会这样

• RustDesk 把码率压得很低（实测约 0.2 Mbit/s ，VP9 ），还会按网络来回的时间主动降帧率和画质，所以网络又窄又抖的时候也稳
• 统一控制用硬件编码，码率高（约 1.2 Mbit/s ），画面清楚、整屏动起来也不崩；但它是为家里局域网设计的，网络一窄，多出来的画面就排在路上，手机这边看不到，也不会主动降码率
• 顺便翻了 RustDesk 的源码：它界面上“质量监测”里那个延迟，是一条测试消息在网络上来回一趟的时间，不包括编码、排队和解码。所以它显示 255 毫秒的时候，屏幕上实际晚了半秒多。这正是我当初嫌它的地方：数字是有，但不是眼睛看到的那个

结论

最常用的场景输了，网络一差还会崩，照开工前的规矩：不做了。专业的事交给专业的工具，外网远程继续用 RustDesk ，记得常更新。统一控制继续只做局域网，不经过云端。

这一趟也不算白忙：

1. 有了一套量“屏幕到屏幕”延迟的办法，一个网页加截图就行，谁都能拿去量自己的远程工具。测试页很短，有人要的话我回帖贴出来
2. 知道了统一控制的短板在哪：码率不会跟着网络降。局域网里一般碰不到，以后真要做再说

代码和测试脚本都是和 Claude 一起写的，我负责出主意和挑毛病。有想法回帖或者写信 [email protected] 都行。

只做小而美的软件和小游戏。免费，无广告，守护你的隐私——数据只留在你自己的设备上。