Screendrop非破坏性编辑的工程秘密sidecar文件与原子文件事务如何做到零数据丢失【免费下载链接】ScreendropA beautiful screenshot screen recording Loom alternative - all native, self hostable and free.项目地址: https://gitcode.com/gh_mirrors/sc/ScreendropScreendrop 是一款原生 macOS 的截屏与录屏工具Loom 的免费替代品它的标注编辑器采用非破坏性编辑无论你在截图上画了多少箭头、打码了多少隐私原始像素始终原封不动。本文拆解它背后的两套核心机制——sidecar 旁路文件与原子文件事务看看零数据丢失到底是怎么工程化实现的。为什么截图加标注很容易把文件搞坏传统截图工具的做法是存即压扁flattening画一个箭头就把箭头像素直接画进图片里。这样带来两个麻烦想改就来不及了箭头画歪了只能撤销一旦保存标注就成了图片的一部分无法单独移动、删除想还原也没法原图像素已经被覆盖除非一开始就另存了一份。Screendrop 的答案很直接原图、渲染结果、编辑数据三者分开存放。sidecar 文件把原图和编辑内容拆开存每次编辑一张截图后Screendrop 会在同一目录下生成这样一组文件文件角色例子显示图你看到的渲染结果原图标注合成Screendrop_2026.pngbase 图未被触碰的原图每次编辑都从它重新渲染Screendrop_2026.base.pngsidecar 文档可再编辑的标注状态JSONScreendrop_2026.png.screendrop命名规则就写在 ScreenshotHistoryStore.swift 里显示图加一个.screendrop后缀就是 sidecar文件主干加.base就是原图备份。sidecar 的内容是一个带版本号的 JSON 文档结构定义在 AnnotationDocument.swift标注形状shapes、箭头吸附绑定bindings、背景/水印/透视等效果background以及它引用的 base 图文件名。正因为编辑状态是数据而不是像素重新打开截图时 Screendrop 能完整恢复你上次的所有标注继续修改。保存流程同样体现了非破坏的原则核心逻辑在 commitAnnotations首次编辑时才惰性备份 base 图不浪费磁盘用 base 原图 当前标注渲染出新的合成图合成图覆盖显示图sidecar 文档写到旁边下次再编辑时依然从 base 原图重新渲染——标注永远不会叠在旧标注上。如果把你画的标注全部删光并保存Screendrop 反而会走 removeAnnotations 把 base 原图还原回显示图位置并删除 sidecar——彻底回到截图刚拍下的样子。原子文件事务一次保存要么全成功要么全回滚问题在于一次保存要同时动三个文件base 图、显示图、sidecar。写到一半断电、磁盘满、权限出错就会留下半新半旧的残局。Screendrop 用一个 60 行的小工具类解决它——ScreenshotEditFileTransaction.swift整个流程分四步第 1 步暂存区staging在目标目录里创建一个.screendrop-save-UUID临时目录先把所有新文件复制进来new-0、new-1……。此刻磁盘上的原文件一个字节都没动。第 2 步备份现场把每个即将被覆盖的旧文件复制为original-0、original-1。从此无论后面发生什么旧数据都有退路。第 3 步正式安装逐个把暂存的新文件替换到目标位置。替换用的是replaceItemAt同卷原子替换目标不存在时用moveItem移动即落地见 install。第 4 步失败即回滚任何一步抛错就按逆序把已经动过的文件从备份还原如果还原本身也失败keepBackup为 true则保留整个暂存目录作为恢复文件并在错误信息里直接告诉用户恢复文件在哪里见 apply 的 catch 分支。这套设计的关键取舍是宁可多占一点临时空间也要保证任何时刻磁盘上要么全是旧状态、要么全是新状态不存在中间态。最后一道防线提交锁与失败时编辑器不关文件事务保证磁盘安全但应用层还要防住两个人同时保存。在 AnnotationEditorModel.commitEdits 中isCommitting标志位保证 Done、Save、Upload、关闭提示框等所有退出路径都走同一个提交入口且相互之间不能并发冲突提交失败时编辑器保持打开、改动不丢用户可以重试——而不是静默丢弃工作成果sidecar 文档先用.atomic选项写入临时文件再交给事务统一替换避免写出半个 JSON。配合前面暂存目录的保留恢复文件策略Screendrop 把数据丢失从一种可能变成了工程上被层层拦截的事件备份、回滚、恢复目录、不关编辑器四重保险。同样的思路也用于录屏与云端分享这套 sidecar 思想并不止于截图录屏工程每个录屏是一个非破坏性会话包.screendroprec屏幕原片、摄像头原片、事件数据光标/点击/按键各自独立存放编辑只改项目文档见 RecordingProject.swift云端分享上传视频后Screendrop 会追加尽力而为的云端 sidecar——标题、海报图、映射到剪辑后时间轴的字幕、拖动预览用的雪碧图见 CloudSidecarUploader.swift分享页随 sidecar 到达逐渐变丰富而主上传不受影响。小结Screendrop 用两个朴素的工程手段兑现了零数据丢失的承诺sidecar 旁路文件原图、渲染图、编辑数据三文件分离编辑永远是数据而非像素可反复修改、彻底还原原子文件事务暂存 → 备份 → 原子替换 → 逆序回滚 → 保留恢复文件让多文件保存要么整体成功、要么整体回退。这套方案代码量很小事务核心不到 70 行却是非破坏性编辑器里最容易被忽略、也最值钱的保险丝。【免费下载链接】ScreendropA beautiful screenshot screen recording Loom alternative - all native, self hostable and free.项目地址: https://gitcode.com/gh_mirrors/sc/Screendrop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Screendrop非破坏性编辑的工程秘密：sidecar文件与原子文件事务如何做到零数据丢失
Screendrop非破坏性编辑的工程秘密sidecar文件与原子文件事务如何做到零数据丢失【免费下载链接】ScreendropA beautiful screenshot screen recording Loom alternative - all native, self hostable and free.项目地址: https://gitcode.com/gh_mirrors/sc/ScreendropScreendrop 是一款原生 macOS 的截屏与录屏工具Loom 的免费替代品它的标注编辑器采用非破坏性编辑无论你在截图上画了多少箭头、打码了多少隐私原始像素始终原封不动。本文拆解它背后的两套核心机制——sidecar 旁路文件与原子文件事务看看零数据丢失到底是怎么工程化实现的。为什么截图加标注很容易把文件搞坏传统截图工具的做法是存即压扁flattening画一个箭头就把箭头像素直接画进图片里。这样带来两个麻烦想改就来不及了箭头画歪了只能撤销一旦保存标注就成了图片的一部分无法单独移动、删除想还原也没法原图像素已经被覆盖除非一开始就另存了一份。Screendrop 的答案很直接原图、渲染结果、编辑数据三者分开存放。sidecar 文件把原图和编辑内容拆开存每次编辑一张截图后Screendrop 会在同一目录下生成这样一组文件文件角色例子显示图你看到的渲染结果原图标注合成Screendrop_2026.pngbase 图未被触碰的原图每次编辑都从它重新渲染Screendrop_2026.base.pngsidecar 文档可再编辑的标注状态JSONScreendrop_2026.png.screendrop命名规则就写在 ScreenshotHistoryStore.swift 里显示图加一个.screendrop后缀就是 sidecar文件主干加.base就是原图备份。sidecar 的内容是一个带版本号的 JSON 文档结构定义在 AnnotationDocument.swift标注形状shapes、箭头吸附绑定bindings、背景/水印/透视等效果background以及它引用的 base 图文件名。正因为编辑状态是数据而不是像素重新打开截图时 Screendrop 能完整恢复你上次的所有标注继续修改。保存流程同样体现了非破坏的原则核心逻辑在 commitAnnotations首次编辑时才惰性备份 base 图不浪费磁盘用 base 原图 当前标注渲染出新的合成图合成图覆盖显示图sidecar 文档写到旁边下次再编辑时依然从 base 原图重新渲染——标注永远不会叠在旧标注上。如果把你画的标注全部删光并保存Screendrop 反而会走 removeAnnotations 把 base 原图还原回显示图位置并删除 sidecar——彻底回到截图刚拍下的样子。原子文件事务一次保存要么全成功要么全回滚问题在于一次保存要同时动三个文件base 图、显示图、sidecar。写到一半断电、磁盘满、权限出错就会留下半新半旧的残局。Screendrop 用一个 60 行的小工具类解决它——ScreenshotEditFileTransaction.swift整个流程分四步第 1 步暂存区staging在目标目录里创建一个.screendrop-save-UUID临时目录先把所有新文件复制进来new-0、new-1……。此刻磁盘上的原文件一个字节都没动。第 2 步备份现场把每个即将被覆盖的旧文件复制为original-0、original-1。从此无论后面发生什么旧数据都有退路。第 3 步正式安装逐个把暂存的新文件替换到目标位置。替换用的是replaceItemAt同卷原子替换目标不存在时用moveItem移动即落地见 install。第 4 步失败即回滚任何一步抛错就按逆序把已经动过的文件从备份还原如果还原本身也失败keepBackup为 true则保留整个暂存目录作为恢复文件并在错误信息里直接告诉用户恢复文件在哪里见 apply 的 catch 分支。这套设计的关键取舍是宁可多占一点临时空间也要保证任何时刻磁盘上要么全是旧状态、要么全是新状态不存在中间态。最后一道防线提交锁与失败时编辑器不关文件事务保证磁盘安全但应用层还要防住两个人同时保存。在 AnnotationEditorModel.commitEdits 中isCommitting标志位保证 Done、Save、Upload、关闭提示框等所有退出路径都走同一个提交入口且相互之间不能并发冲突提交失败时编辑器保持打开、改动不丢用户可以重试——而不是静默丢弃工作成果sidecar 文档先用.atomic选项写入临时文件再交给事务统一替换避免写出半个 JSON。配合前面暂存目录的保留恢复文件策略Screendrop 把数据丢失从一种可能变成了工程上被层层拦截的事件备份、回滚、恢复目录、不关编辑器四重保险。同样的思路也用于录屏与云端分享这套 sidecar 思想并不止于截图录屏工程每个录屏是一个非破坏性会话包.screendroprec屏幕原片、摄像头原片、事件数据光标/点击/按键各自独立存放编辑只改项目文档见 RecordingProject.swift云端分享上传视频后Screendrop 会追加尽力而为的云端 sidecar——标题、海报图、映射到剪辑后时间轴的字幕、拖动预览用的雪碧图见 CloudSidecarUploader.swift分享页随 sidecar 到达逐渐变丰富而主上传不受影响。小结Screendrop 用两个朴素的工程手段兑现了零数据丢失的承诺sidecar 旁路文件原图、渲染图、编辑数据三文件分离编辑永远是数据而非像素可反复修改、彻底还原原子文件事务暂存 → 备份 → 原子替换 → 逆序回滚 → 保留恢复文件让多文件保存要么整体成功、要么整体回退。这套方案代码量很小事务核心不到 70 行却是非破坏性编辑器里最容易被忽略、也最值钱的保险丝。【免费下载链接】ScreendropA beautiful screenshot screen recording Loom alternative - all native, self hostable and free.项目地址: https://gitcode.com/gh_mirrors/sc/Screendrop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考