Electron 录制引擎为何要重写为 Swift?

Rebuilding our Electron meeting-recording engine in Swift

Electron 录制引擎为何要重写为 Swift?

我们的桌面应用无需机器人即可捕获会议并流式传输到云端。过去几个月,录制引擎是产品中最难稳定的部分:修复一类边缘情况,发布后下一周又出现新问题。引擎原本运行在 Electron 的渲染进程中,我们尝试了生命周期管理、主线程外移、隔离 React 渲染循环等方案,但收效甚微。根本问题在于:渲染进程不适合实时音视频捕获,无法容忍 GC 暂停或浏览器运行时的节流。于是我们转向原生方案:macOS 使用 ScreenCaptureKit,Windows 使用 libobs,并通过共享的 Swift 层统一接口。我们开发了内部工具 Atomic,将 Swift 的 @Published 属性自动映射为 React 的 Jotai atom,实现全反应式、类型安全且无需胶水代码的桥接。macOS 和 Windows 的捕获引擎架构迥异,我们分别处理了多时钟同步、音频驱动采样率欺骗等复杂问题,并采用 fragmented MP4 确保崩溃时录制文件不丢失。整个重写仅耗时两个月,现在录制功能已变得可靠而‘无聊’。

不是所有事情都适合放在渲染进程中,有时你必须走向原生。
  1. losteric

    我真的很难以接受 AI 生成的文字。除了感觉被冒犯之外,那种文风读起来实在太累人了……那种营销式的铺垫和揭晓,加上重复,只有在少量使用时才有效。

  2. blululu

    我很好奇,那些让 Claude 写这篇文章的‘驯兽师’们,能不能也让 Claude 提供一些性能数据,比如应用大小、RAM 占用和 CPU 利用率。随着内存压力越来越大,我真的很希望 AI 赋能的软件开发能把 500MB 的网站和 1GB 的 Electron 应用转化为高性能的软件。代理式编程(Agentic coding)在写 SwiftUI 界面和写 React 方面的能力其实差不多。所以,软件社区或许真有机会把生产力提升转化为高性能代码。如果能知道这个项目花了多少时间/精力,以及最终用户在速度和占用空间方面获得的原始收益,那就更有意思了。

  3. insane_dreamer

    > 这就是 macOS 引擎复杂性的由来。

    你好,Claude。

同日更多故事

2026-08-21