NikoDesk v1.0.5

NikoDesk 1.0.5 / build 14. The native protocol stays at 1.5.0.

下面的内容都是在同一台 Mac 的两个身份之间、经私服中继、用这份源码的开发构建验证的。本版没有任何一项在两台设备之间跑过。

更新前先看

• 输入正确密码即可连接，不再需要被控端点击确认。 被控端的默认规则由"只允许点击"改为"密码或点击"。有效密码指应用显示的一次性密码，以及设置并允许后的永久密码。密码错误或没有密码时，仍在被控端弹出确认。
• 从 1.0.4 及更早版本更新的设备都会变成这个规则，包括之前选的是"只允许点击"的设备：那是当时的默认值，没有被保存下来。想保持每次都点击，更新后到"高级设置 → 安全"里重新选一次"只允许点击访问"。
• 终端、摄像头、端口隧道、语音四项仍需各自的批准。
• macOS 包仍是 ad-hoc 签名：换上新版后，屏幕录制和辅助功能授权会失效，需要在 Mac 上重新授予。不要在无法到场、也没有其他远控入口的情况下更新被控 Mac。

画面切换卡顿

反馈的问题：用 1.0.3 控制一台 5K 的 Mac，解锁、进入全屏这类整屏变化非常卡。查到两件事，都没有被确认为那次会话的原因。

硬件编码器可能在一次运行里再也回不来。 采集重启后，Mac 的硬件编码器最初几帧不出数据。连续 3 次空结果（60 帧时只要 50 毫秒）就会让应用放弃硬件编码，改用软件编码，直到应用重启。一份 1.0.3 的会话日志里，90 秒内四次采集重启之后，H.265 被标记为不可用，5K 画面改用软件 AV1 编码，至少持续了半小时。那四次重启是同一台 Mac 上的测试造成的，不是用户操作；但任何一次重启都可能触发，主控端的"刷新画面"也算。

现在 macOS 的硬件编码器要连续 30 次空结果才会被放弃。压力测试（60 帧上限下 14 次尺寸切换）启动了 24 个编码器，出现过连续 3 次空结果，也就是旧版本放弃的位置，全程保持 H.265。

每一帧都带着全部 5120×2880 像素。 硬件编码器只有平均码率，没有单帧大小上限。一次本机测试里，另一路 5K 画面占着上行，反复整窗变化让画面落后 7.2 秒、每秒约 5 帧；同样条件下 3840×2160 中位落后 4.1 秒，2560×1440 中位落后 16 毫秒、最大 1.5 秒。之后链路不忙时，原始大小的画面也能保持在 20 毫秒以内。

新增：控制中心 → 传输画面大小

主控告诉被控端自己能显示多宽的画面，被控的 Retina Mac 在显卡上把采集缩到接近这个宽度。显示模式、窗口布局、坐在那台 Mac 前的人看到的东西都不变。

• 按本机屏幕（默认）：主控屏幕宽 3840 像素时，5K 的 Mac 发 3840×2160，56% 的像素。
• 更小：远端的标准大小：每个点一个像素。5K 的 Mac 是 2560×1440，25% 的像素。
• 远端原始大小：显示器的全部像素。

按设备保存。会话中切换会重启一次采集，本机测到 0.2–0.3 秒。

限制

• 两端都要 1.0.5，被控端要是带 Retina 屏的 Mac。Windows 被控端会忽略这个请求。
• 只有缩放后长宽都是整偶数像素时才缩，否则保持原始大小。14 寸 MacBook Pro（1512×982 点）对 1920 宽的主控没有可用的缩放档。
• 主控上报的是它最大的那块屏幕。Mac 主控上报像素尺寸，所以设为"看起来像 2560×1440"的 4K 屏会上报 5120，拿到原始大小。
• 多个主控同时连接时取最宽的请求。旧版本主控不发请求，拿到的是其他主控要的大小。
• 指针图像不随画面缩放；在标准大小下，它相对画面大了一倍。
• 编码器仍没有单帧上限。像素少了，大帧会变小，但不会消失。
• 启用这种缩放后，"远端分辨率 → 匹配本机像素"没有可做的事，按钮不可用。

修复

• 更新包下载在写盘过程中超时或被取消时，报告的是无关的文件错误，现在报告真正的原因。

发布流程

• macOS 构建会在一个只有标准 Library 目录的全新主目录里启动它刚构建出的应用；核心没启动、应用没保持运行或日志里有崩溃，构建就失败。

验证与边界

项目	结果
采集缩放	要 3840 得 3840×2160；要 2560 或最小值得 2560×1440；要原始得 5120×2880。显示器全程是 2560 点宽。带着已保存请求重新登录，第一帧就是 3840×2160；该主控离开后，下一个主控看到 5120×2880
指针位置	每次尺寸切换后向画面的不同位置发送指针坐标，再从系统读回，五次都落在预期位置
缩放规则	对十种真实 Mac 点尺寸、九种请求的单元测试：结果都是整偶数像素，点尺寸精确，除非显示器没有更多像素，否则不小于请求
整屏变化（90% 画质、60 帧上限、占屏幕 64% 的窗口每 2 秒整体变化、各 20 秒、各一次）	原始大小：解码 32.9 帧/秒，超过 250 毫秒的间隔 14 次，画面中位落后 17 毫秒、最大 954 毫秒。3840 宽：33.8、20 次、14 和 17 毫秒。2560 宽：33.5、20 次、15 和 17 毫秒。帧率和间隔没有改善，只有最大延迟不同，而第二次原始大小的测试最大也只有 20 毫秒。测试期间同一台 Mac 上有另一个远控会话在采集和编码同一块屏幕
硬件编码器	见上文
密码规则	被控端用默认设置、无人点击：一次性密码登录并收到画面；从未允许过的永久密码被拒；错误密码被拒。明确选了"只允许点击"时，正确密码不能登录
回归	Flutter Niko 1022 通过 / 2 跳过，stock 1001 通过 / 6 跳过；Rust Niko 过滤回归全部通过

未验证：Windows 和 Android 主控；Windows 被控端；设备之间的帧率和延迟；控制中心里的选择器，以及会话开始时自动发出的请求（包括主控怎样读自己的屏幕尺寸）；两个主控同时连接；从已安装的 1.0.3 或 1.0.4 更新后的行为。

详见 docs/RELEASE-1.0.5.md。

发布后补测与更正（10-05）

第一次跨设备会话。 两端都是 1.0.5，屏幕宽 3024 像素的 Mac 控制那台 5K 的 Mac。被控端日志显示：收到 3024 的请求，采集 3200×1800，全程硬件 H.265；连接建立 42 毫秒后登录完成，没有点击的余地。

更正上面"画面切换卡顿"里的一个说法。 "另一路 5K 画面占着上行"不是原因。那台 5K 的 Mac 所在的网络把从中继过来的数据压在总量约 4.4 Mbit/s，发往中继的数据不受限（实测 46 Mbit/s 以上）。那台 Mac 被控时，画面走的是不受限的方向；本机测试的两端都在那台 Mac 上，画面要从受限方向回来。7.2 秒、4.1 秒这些延迟是 4.4 Mbit/s 的链路对那两种画面大小的表现，不代表从别处控制那台 Mac 的体验。是谁在限速没有查明；中继程序本身经另一条路能转发 46 Mbit/s。

绕开受限方向后重测（90% 画质、60 帧上限、整窗每 2 秒变化一次、15 秒）：

画面	解码帧率	超过 100 毫秒的间隔	最长间隔	延迟中位 / 最大
5120×2880	49.7	4 次	184 毫秒	21 / 46 毫秒
3200×1800	54.0	0 次	70 毫秒	20 / 38 毫秒

也就是说，在带得动的链路上，缩小画面是"略顺一些、码率省一半"（目标 8.9 对 16.5 Mbit/s），不是之前数字暗示的"能用和不能用"的差别。

"每秒约 10 帧新画面"的上限没有再出现。 只有 NikoDesk 会话在连时，同一台 Mac 的采集每秒收到 75 帧新画面。10-04 那次，另一个远控软件当时也开着会话。

"操作流畅"是几种常用模式里帧率最低的。 它请求的是均衡画质，而会话会把均衡画质固定在 30 帧：同一条链路上解码 27.3 帧/秒，自定义 60 帧上限是 53.9。本版之后已改为请求 60 帧上限（在 nightly 里）。在 1.0.5 上请用"自定义"并把帧率设为 60。

Packages and boundaries

All seven platform packages are provided with SHA256SUMS. macOS ARM64: DMG and updater ZIP, ad-hoc signed without Developer ID notarization. Windows x64: portable EXE/ZIP and separate setup-validation EXE/ZIP, unsigned. Android ARM64: controller APK signed with the NikoDesk release key, versionCode 14.

The Mac updater validates and stages the ZIP for manual installation. Real cross-device sessions, frame rate and latency, background recovery and ToDesk comparisons remain separate acceptance work.