兄弟，你这套不用WebRTC的自定义远程桌面方案能跑通已经很厉害了！但延迟卡顿确实是这类实时流场景的老大难——我之前在做类似的自定义流传输项目时踩过不少坑，结合你用的技术栈，给你整理了几个针对性的优化方向，每个点都是实操性很强的：

一、捕获端（ScreenCaptureKit）：从源头减少数据量和阻塞 #

• 精准控制捕获范围：如果不需要全屏远程，用SCStreamConfiguration的sourceRect指定只捕获目标区域（比如排除任务栏），或者用cropRect裁剪无关内容，直接减少后续编码的像素数据量。
• 平衡捕获帧率与性能：通过minimumFrameInterval设置合理的帧率上限（比如1/30对应30fps，非专业场景足够流畅），不要盲目追60fps——高帧率会极大增加编码和传输压力，反而容易导致丢帧卡顿。
• 避免捕获线程阻塞：SCStreamDelegate的didOutputSampleBuffer回调是在捕获线程执行的，绝对不要在这个回调里做编码、网络请求等耗时操作，要把CVPixelBuffer快速丢到专门的编码串行队列，让捕获线程立刻回到工作状态，不然会直接导致捕获丢帧。

二、编码端（VideoToolbox）：低延迟优先的H.264编码配置 #

• 强制低延迟编码规则：
  • 关闭B帧：设置kVTCompressionPropertyKey_AllowFrameReordering为false，B帧依赖前后帧参考，会增加编码延迟和传输复杂度，实时场景完全不需要。
  • 开启实时模式：设置kVTCompressionPropertyKey_RealTime为true，告诉VideoToolbox优先保证编码速度和低延迟，而非极致的压缩率。
  • 选用低延迟Profile：指定kVTCompressionPropertyKey_ProfileLevel为kVTProfileLevel_H264_Baseline_AutoLevel，Baseline Profile专为实时通信优化，解码复杂度更低。
• 控制比特率：根据捕获分辨率设置合理的平均比特率（比如1080p30fps设为6-8Mbps，720p30fps设为3-5Mbps），过高的比特率会增加传输压力，过低会导致画面模糊。同时可以设置kVTCompressionPropertyKey_MaxBitRate限制峰值比特率，避免突发数据量阻塞传输。
• 拉满硬件编码：确保kVTCompressionPropertyKey_HardwareAccelerated设为true（默认开启，但最好显式指定），VideoToolbox的硬件编码比软件编码快数倍，能大幅降低编码耗时。

三、传输端（SignalR）：让帧数据“跑”得更快 #

• 强制用WebSockets传输：在Swift和JS的HubConnectionBuilder里明确指定传输方式为WebSockets，禁用Server-Sent Events或Long Polling——这两种 fallback 方式的延迟比WebSockets高一个量级。
• 用流式传输替代单帧发送：不要给每个编码后的帧单独调用SendAsync，改用SignalR的流式传输功能：Mac端通过InvokeAsync发送连续的帧流，服务器端接收后直接转发给Web客户端，Web客户端用stream方法接收。流式传输能减少单帧消息的协议开销，更适合连续的实时流场景。
• 服务器端做“纯转发”：SignalR服务器的逻辑要极简，收到Mac端的帧数据后立刻转发给所有Web客户端，不要做任何缓存、解析或其他耗时操作——哪怕是几毫秒的阻塞，积累起来都会变成明显延迟。
• 调整心跳与超时：把keepAliveInterval设为10秒左右，serverTimeout设为30秒，既保证连接稳定性，又不会因为频繁心跳占用带宽。

四、解码渲染端（WebCodecs+Canvas）：减少浏览器侧的等待 #

• 低延迟解码配置：初始化VideoDecoder时，设置optimizeForLatency: true，并指定低延迟的H.264 codec（比如avc1.42E01E对应Baseline Profile），告诉浏览器优先保证解码速度和低延迟。
• 渲染环节零等待：
  • 解码后的VideoFrame要立刻渲染到Canvas，不要缓存，渲染完成后马上调用frame.close()释放资源，避免内存堆积阻塞解码队列。
  • 用requestAnimationFrame对齐浏览器刷新周期：把解码后的帧暂存到一个小队列，然后在requestAnimationFrame回调里取出渲染，这样能和浏览器的60Hz刷新同步，避免画面撕裂和额外延迟。
• 匹配Canvas与帧尺寸：提前把Canvas的宽高设置为和捕获的帧尺寸完全一致，不要让浏览器在渲染时动态缩放——GPU缩放会增加额外的渲染耗时，还可能导致画面模糊。

五、整体流程：端到端的协同优化 #

• 端到端时间戳追踪：给每个帧加唯一的时间戳（用ScreenCaptureKit样本buffer的presentationTimeStamp即可），编码、传输、解码全链路携带这个时间戳。Web端可以用它计算从捕获到渲染的总延迟，定位哪个环节拖了后腿；Mac端也可以用输入事件的时间戳和帧时间戳对齐，减少鼠标光标与画面的不同步。
• 零拷贝数据流转：尽量避免在各环节做不必要的内存拷贝：比如ScreenCaptureKit的CVPixelBuffer直接传给VideoToolbox编码，编码后的CMBlockBuffer直接转成Swift的Data发送，Web端接收二进制数据后直接传给EncodedVideoChunk——每多一次拷贝，就多几毫秒的延迟。
• 输入事件极速处理：Web端捕获鼠标/键盘事件后，立刻通过SignalR发送，不要攒批量；Mac端收到输入事件后，用CGEventPost等API直接模拟输入，不要做额外的校验或等待，确保用户操作能立刻反馈到画面上。

六、定位瓶颈的小技巧 #

• 在每个环节加耗时统计：比如Mac端记录捕获开始、编码开始/结束、发送完成的时间；Web端记录收到消息、解码开始/结束、渲染完成的时间，用这些数据就能精准定位是捕获慢、编码卡还是传输延迟高。
• 用工具排查：Mac端用Instruments的Time Profiler分析捕获和编码线程的耗时；Web端用Chrome DevTools的Performance面板查看解码、渲染的耗时，以及SignalR的消息传输延迟。

建议先从关闭B帧、调整捕获帧率、开启WebCodecs低延迟这几个最容易上手的点试起，应该能看到明显的延迟下降；如果还有问题，再用监控工具定位具体的瓶颈环节针对性优化。