我们的桌面应用无需机器人即可捕获会议,并将其流式传输到云端。数月来,录制引擎一直是产品中最难保证可靠性的部分。我们修复了一类边缘情况,发布上线,结果下一周又冒出新的问题。根本原因不同,模式却相同。该引擎运行在我们 Electron 应用的渲染进程中。我们尝试过显而易见的修复方法:更严格的生命周期管理、把工作移出主线程、将其与 React 的渲染周期隔离。每一项改动都有边际改善,但没有一项解决真正的问题。渲染进程根本不是进行实时音视频捕获的正确场所。捕获引擎无法容忍 GC 停顿、节流,或浏览器运行时为保持响应所做的任何其他事情。
于是我们转向原生方案:macOS 上使用 Screen Capture Kit,Windows 上使用 libobs,并用一个共享的 Swift 层将它们串联起来。将原生运行时桥接到 React 通常意味着手工编写原生插件绑定。如果 Swift 中的每个 @Published 属性都能自动变成 React 中的 Jotai atom 会怎样?这正是我们内部工具 Atomic 所做的。
在 macOS 上,我们从三个独立来源接收原始样本缓冲区,并自行组装文件。在 Windows 上,捕获、混音、编码和封装作为单一图运行。我们使用 Windows Graphics Capture(WGC)作为主要方法,如果它未能及时交付帧,我们会回退到 Bit Blt。我们还会检测全黑帧,并在录制过程中切换方法。
第 30 分钟崩溃最多只损失最后一秒。片段同时写入本地存储和云端。如果网络中断,片段会保留在本地,连接恢复后上传自动继续。桌面录制曾是我们最常见的技术支持工单来源之一。现在它只是应用中一个"正常工作"的无聊部分。
来源: Hacker News · 由HeadlinesBriefing整理摘要