I Recorded 50 Hours of Screen Content with 8 Different Tools

# 我用8种不同工具记录了50小时的屏幕内容

记录了50小时，测试了8种工具，3个操作系统。文件大小从2GB到47GB不等，为相同内容。CPU使用率从3%到40%不等。

这些数字告诉你屏幕录制软件比大多数创作者意识到的要重要得多。我已经制作了六年的技术教程，上个月我在三台不同的机器上录制了53小时的屏幕内容。当录制在90分钟的时候损坏时，你不仅会失去影像——你还会失去心理状态、完美的解释以及让那次录制特别的自发清晰度。

这不是一个我测试每个工具20分钟的评论。我经历了内核恐慌、重置音频设置的Windows更新和Linux显示服务器迁移等情况。我录制过4K游戏图像、快速文本输出的终端会话以及在一台显示代码而另一台显示文档的多显示器工作流程。每个工具都以不同的方式让我失望，而有些根本没有失败过。

背景：我为什么要记录这么多内容

我的工作日围绕为三个不同平台创建开发者教程。一个客户希望制作显示Visual Studio工作流程的Windows特定内容。另一个需要跨平台的命令行教程，在Mac和Linux上工作完全一样。第三个则发布需要高帧率捕捉Unity和Unreal Engine游戏开发内容。

这意味着我不仅仅是在录制——我是带着限制条件进行录制的。一个30分钟的教程可能需要90分钟的原始素材，考虑到错误、重复解释以及复杂序列的多次拍摄。我需要捕获系统音频、麦克风输入，有时需要同时捕获两者。如果我的猫在键盘上走过，或者Windows决定安装更新，我需要确保录制不会中断。

技术要求很快就变得具体。当我录制终端会话时，我需要确保每个字符都可见——没有压缩伪影将`rm -rf`变成`rm -r#`。当我捕获游戏引擎视口时，我需要至少60帧每秒，否则最终编辑时运动看起来会卡顿。当我展示基于浏览器的工具时，我需要光标看起来清晰，而不是模糊的块，让人不清楚我点击的是哪个按钮。

六个月前，在一次灾难性的录制失败后，我开始跟踪详细的指标。我花了两个小时录制一个复杂的Docker网络教程，解释子网配置和容器通信模式。录制看起来成功——软件显示了一个47GB的文件。当我在编辑器中打开它时，视频已经损坏，无法恢复。73分钟之后的每一帧都是绿色的像素。

那次失败让我错过了最后期限，并教会我“以前能用”并不是一种测试方法。我需要有关哪些工具实际上能经受住现实使用模式的数据，而不仅仅是哪些工具的市场营销文案最佳。

三种工具同时失败的那天

2月14日。我记得这个日期，因为我试图在完成一个情人节项目的同时还要满足客户的最后期限。我在三台机器上运行三种不同的屏幕录制——一台Windows桌面捕获游戏画面，一台MacBook Pro录制设计工作流程，还有一台Linux工作站展示服务器配置。

所有三种录制预计运行大约45分钟。我以前在没有问题的情况下做过这个，用我信任了几个月的工具。我启动了所有三种录制，开始我的演示，进入了能够产生良好教程内容的专注状态。

Windows机器首个失败。我正在讲解Unity中的纹理优化，31分钟时录制软件崩溃。没有警告，没有错误消息——就消失了。应用程序从任务栏中消失。当我重新打开它时，没有恢复文件，没有自动保存，什么都没有。关于法线贴图压缩和mipmap生成的详细解释，31分钟的内容，就这样消失了。

我还不知道Windows的失败，因为我专注于Mac录制。那一段录制持续到38分钟，结果出现了彩色转圈。录制软件冻结了。计时器停止更新。我仍然可以移动鼠标和切换应用程序，但录制工具完全锁住了。我强制退出了它。结果文件损坏——它播放前12分钟，然后跳到一个冻结的画面，持续了剩下的时间。

Linux的录制实际上完成了。我完成了47分钟的服务器配置教程，停止了录制，软件报告成功。文件大小看起来正确，为8.3GB。我把它复制到我的NAS进行备份。当我当晚打开它开始编辑时，我发现音频完全不同步。开始时还算正常，但到20分钟时，我的声音在描述的事情还要等8秒才会出现在屏幕上。到最后，音视频不同步超过15秒。

三种录制，三种不同的失败模式，三种不同的工具。那天我停止了对任何单一解决方案的信任，并开始了这个系统的测试项目。

性能数据：重要的数字

我在相同硬件上用每种工具录制了相同的30分钟教程片段八次。内容是一个Python网页抓取教程——大量终端输出、浏览器交互和代码编辑。以下是我测量的结果：

文件大小的变化是荒谬的。Camtasia的47.3GB文件包含与Windows Game Bar的2.1GB文件相同的视觉信息。两者都是30fps的1080p。两者都捕获了相同的30分钟内容。不同之处在于，Camtasia以无压缩格式录制，旨在进行编辑，而Game Bar使用的是硬件加速的H.264编码。

CPU使用率则讲述了不同的故事。Kazam在6核处理器上的40% CPU使用率意味着它消耗了两个完整核心仅用于录制。在那次录制期间，我可以听到笔记本风扇转动起来。系统感觉迟缓。当我在录制时尝试编译代码，编译耗时是正常的3倍。

Windows Game Bar的3% CPU使用率是硬件编码的结果。GPU的专用视频编码器处理压缩，剩余CPU可以用于其他任务。在后台运行Docker容器构建的同时，我录制了同样的教程——录制完美，构建按正常时间完成。

丢帧是无声的杀手。ShareX的3帧丢失可能听起来不重要，但这些丢帧发生在我演示一个打印了数百行的脚本时。丢帧使文本看起来在跳跃，一次跳过几行。在最终视频中，观众无法清晰阅读输出。

Kazam的127帧丢失使录制变得不可用。视频不断卡顿。鼠标移动不平滑。窗口过渡看起来很卡顿。这不是一次性的巧合——我测试了Kazam三次，每次都有丢帧。

洞察：数据没有显示的内容

“最好的录制工具是那个可以被忽视的工具。你应该在开始后30秒内忘记自己在录制。”

这是改变我评估屏幕录制软件方式的洞察。那张表中的数字很重要，但它们并不能捕捉到使用每个工具的认知负担。

OBS Studio的界面最复杂。有场景、源、过滤器和音频混合器。第一次打开时，你会看到一个空白界面。