OpenScreen 构建与发布完整指南如何快速编译、签名并分发这款免费开源录屏演示工具【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreenOpenScreen 是一款免费开源的屏幕录制与演示视频编辑工具支持 Windows、macOS 和 Linux 三大平台基于 Electron Rust 原生合成器构建GPU 加速渲染、无水印、无订阅。本文带你从源码编译、安装包打包、代码签名与公证一路走到完整的 CI/CD 发布流水线帮助你理解一个现代开源桌面应用是如何构建并分发到用户手中的。一、构建体系全景为什么 OpenScreen 的编译比普通前端项目复杂OpenScreen 不只是Vite Electron的组合。一次完整的安装包构建需要协调三类产物产物类别内容工具链前端与主进程React 渲染层、Electron 主进程、preload 桥接Node.js 22 TypeScript Vite原生捕获/合成助手屏幕捕获 helper、D3D11/Metal 合成器插件CMake MSVC / SwiftPM / Rust Cargo第三方运行时FFmpeg 动态库、Whisper 语音转写二进制CMake 预编译下载所有命令都集中在 package.json 的 scripts 中官方构建文档见 technical-documentation/engineering/build-and-packaging.md。二、编译前置条件三台机器的工具链清单通用Node.js 22.22.1 与 npm 10.9.4package.json#engines中已严格锁定版本然后执行npm ci安装依赖。WindowsVisual Studio C 生成工具、Windows SDK、CMake Ninja、Rust MSVC 工具链。macOS完整 Xcode仅 Command Line Tools 不够 Rust 工具链。LinuxCargo、CMake以及 Vulkan 驱动合成器渲染依赖无 GPU 时可回退 lavapipe 软件光栅化。⚠️ 一个关键坑原生插件compositor_view.node不提交进仓库在 Windows 上打包请始终用npm run build:win而不是泛化的npm run build——后者不会重编译原生插件且旧版插件会静默失效新特性不生效但不报错。打包前的守卫脚本 scripts/before-pack.cjs 会检查插件是否比 Rust 源码旧并在产物不完整时直接中止构建。三、从源码到安装包四条核心构建命令npm run dev # 开发模式Vite 热更新 启动 Electron npm run build:win # 捕获助手 → FFmpeg → 合成器插件 → 打包 NSIS 安装器 npm run build:mac # ScreenCaptureKit 助手 → 源码编译 FFmpeg(LGPL) → 打包 DMG npm run build:linux # AppImage / deb / pacman / rpm 四种格式打包阶段的瘦身技巧都写在 electron-builder.json5 中Vite 已预打包全部业务代码因此整个node_modules被排除约省 238 MB壁纸、字体、分割模型走extraResources而非塞进 asarelectronLanguages只保留 15 种受支持语言约省 20 MB。四、代码签名与公证让安装包被系统信任macOS 是签名最完整的一条路径。当 CI 中配置齐全部 Apple 凭据时每个 tag包括 RC 预发布都会执行Developer ID 签名 →notarytool公证 → staple 票据 → Gatekeeper 校验。涉及的仓库 Secrets 包括MAC_CERTIFICATE_P12、MAC_CSC_NAME、APPLE_ID、APPLE_TEAM_ID等缺任何一项则回退到 ad-hoc 签名。凭据轮换与细节见 technical-documentation/engineering/release-and-secrets.md。Windows 分两条路NSIS.exe目前未配置代码签名SmartScreen 会提示未知发布者而 Microsoft Store 的 AppX 包在微软认证流程中由微软签名——这是官方推荐的受信任通道。提交 Store 需配置 Entra ID 应用凭据AZURE_AD_APPLICATION_SECRET等且仅限稳定版提交RC 版本被明确排除避免未认证版本推送到所有用户机器。Linux 的签名等价物是依赖声明。各发行版包格式的depends列表在 electron-builder.json5 中手写并替换默认值例如补上libgbm1、libgomp1、xdg-desktop-portal再由 scripts/verify-linux-package.sh 在干净的发行版容器里真实安装并跑ldd验证防止开发机上能跑、干净机器上崩的发布事故。五、CI/CD 流水线15 个工作流的四层架构所有工作流位于.github/workflows/官方架构参考 technical-documentation/engineering/ci-workflows.md层级工作流触发条件Tier 1 应用 CIci.yml推送到 main / PRlint、类型检查、单测、Vite 构建冒烟Tier 2 发布构建build.yml任意v*tag 或手动 dispatchWindows NSIS AppX、macOS 双架构 DMG、Linux 四格式Tier 2.5 版本管理prerelease.yml/promote.yml手动触发切 RC → 晋升稳定版Tier 3 软件源Homebrew / WinGet / Nix / AUR稳定版发布后自动扇出Tier 4 自动化Discord 通知、诊断包等PR 事件 / 定时任务发布节奏release-please 风格的冻结分支契约prerelease.yml创建并冻结release/vX.Y.Z分支、打vX.Y.Z-rc.Ntag 并显式 dispatchbuild.ymlRC 通过手动 e2e 清单验证后promote.yml在分支上把版本改为稳定号、打稳定 tag、将版本同步 PR 合回 main再触发正式发布。build.yml的发布步骤会校验 tag 与package.json版本号一致防止用 main 分支的二进制发布旧版本号这类事故。产物流转各平台安装器上传为 30 天保留的 Actions 工件 →publish-release校验后发布为 GitHub Release同时生成latest.yml更新源与.blockmap差量块图供electron-updater做增量更新→ 稳定版事件自动触发四个软件源更新工作流。Linux 还有一条独立支线nix/package.nix 直接跑 Vite不经 electron-builder构建 Nix 包bump-nix-package.yml在稳定版发布后自动开 PR 更新版本与依赖哈希flake.nix 则提供nix develop开发外壳一条命令获得完整的 Node/Electron/原生构建环境。六、要点速查清单️编译锁定 Node 22.22.1npm ci后用平台专属build:*命令切勿用泛化build打包 Windows 产物签名macOS 全流程签名 公证含 RCWindows 信任通道走 Store 认证Linux 靠依赖声明 干净容器验证发布冻结release/vX.Y.Z分支 → RC 验证 → 晋升稳定版 → 自动扇出 Homebrew/WinGet/Nix/AUR关键文件electron-builder.json5打包与签名配置、.github/workflows/build.yml发布构建矩阵、scripts/before-pack.cjs打包前完整性守卫想动手试试克隆仓库git clone https://gitcode.com/gh_mirrors/opens/openscreen装好对应平台工具链后一条npm run build:linux或你的平台命令就能得到属于你自己的、带版本号签名的 OpenScreen 安装包。【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考