前几天有个朋友在群里问：Unity 游戏要上线应用商店，商店需要演示视频，有没有能在移动端直接录屏、还能顺手生成 GIF 的插件？我第一反应就是 Natcorder。这个插件我用了快两年，录屏、拍照、GIF 三件事全都能干，而且不需要 GPU Readback，CPU 直接编码，兼容性比同类方案好不少。如果你也在做移动端录屏需求，或者想给游戏加个"保存精彩瞬间"的功能，这篇应该能帮你少踩几个坑。
标题里写的是"录频"，但实际开发里我们一般叫"录屏"或者"屏幕录制"，核心就是把 Unity 的渲染画面编码成视频文件。Natcorder 最实用的地方在于：它不像原生方案那样需要写 Android 和 iOS 两套代码，一套 C# 接口全搞定。下面我按自己的实战顺序，从选型、原理到三个功能的完整实现，把踩过的坑和优化经验一起写出来。
1. 为什么移动端录屏我最终选了 Natcorder
先说结论：不管你是要录屏、拍照还是生成 GIF，Natcorder 都能在纯 Unity 环境下完成，不需要额外接入原生 SDK。这对中小团队和个人开发者特别友好，因为它意味着你只需要维护一份代码，就可以同时覆盖 Android 和 iOS。
1.1 移动端录屏方案对比：RenderTexture、原生 API 与 Natcorder
Unity 里做录屏，常见的路子有三条：
RenderTexture + Texture2D.ReadPixels 逐帧读回：思路简单，但性能消耗极大。每次 ReadPixels 都是一次 GPU 到 CPU 的同步拷贝，在移动端很容易造成明显的掉帧。录 720p 都会卡，更别提 1080p 了。
Android MediaProjection / iOS ReplayKit 原生方案：性能好，但需要写原生代码，还要处理生命周期、权限弹窗、不同机型兼容。如果你想快速做一个跨平台的功能模块，这条路的成本是成倍增加的。
Natcorder 插件方案：它在底层封装了不同平台的原生编码器，但在 Unity 层暴露的是统一的 C# 接口。原理上不再走 GPU Readback，而是直接通过底层 API 获取原生纹理句柄进行编码，速度快很多。同时它还内置了音频录制功能，可以同步录系统声音和麦克风声音。
1.2 Natcorder 的底层原理：CPU 编码与原生纹理句柄
Natcorder 最大的亮点在于它绕过了"把像素从 GPU 拷贝到 CPU"这个瓶颈。传统的 ReadPixels 方案是：GPU 渲染完一帧 → 拷贝到 CPU 内存 → CPU 编码写入文件。这个过程每一帧都会造成 GPU 停顿，移动端尤其明显。
Natcorder 的做法是拿到当前帧在 GPU 上的原生纹理指针，然后交给底层的硬件编码器直接处理，整个流程不经过 CPU 的像素拷贝。这就是为什么它在移动端依然能保持比较好的帧率表现，也是我最终选择它的核心原因。
注意：Natcorder 最新版本是 2.x，API 和 1.x 相比有一定改动。下文所有代码均基于 2.x 版本，如果你在用旧版本，请注意字段名的差异。
2. 先搞懂 Natcorder 的工作机制再动手
Natcorder 的操作逻辑其实很有规律，概括起来就是四个字：配置、开始、喂帧、结束。但这里面的细节如果不搞清楚，很容易写出"录出来是黑屏"或者"视频没有声音"这种问题。
2.1 IClock 与 IRecorder：两个核心抽象
Natcorder 把录制的整个过程抽象成两部分：
IClock：负责统一管理录制过程中的时间戳。你需要传入一个时间源给 Recorder，Recorder 会按照这个时钟的节奏去接收帧数据。Natcorder 自带
RealtimeClock，它从创建开始就以真实时间进行计时。如果你希望在录屏过程中，视频时间流逝和真实世界完全同步（比如 1 秒真实时间对应 1 秒视频时间），RealtimeClock 就是首选。IRecorder：负责把每一帧图像/音频数据编码到文件中。不同的编码格式对应不同的 Recorder 类型。录 MP4 用
MP4Recorder，录 GIF 用GIFRecorder，拍照用JPGRecorder。
它们的配合关系是这样的：你创建一个 Recorder，传入一个 IClock；然后在游戏循环中不断把当前帧的图像（以及采集到的音频）喂给 Recorder；最后调用Dispose，Recorder 会完成编码并生成最终文件。
2.2 音频录制的关键：AudioRecorder 与音频适配器
如果你只是录画面，可能觉得音频部分可有可无。但实际上，应用商店的演示视频、玩家分享的精彩操作，没有声音体验感会大打折扣。Natcorder 在音频录制上的设计也很统一：也是通过AudioRecorder+IClock的组合，把OnAudioFilterRead或AudioListener的数据喂进 Recorder。
这里有一个比较关键的细节：Unity 的音频回调是在音频线程中触发的，Recorder 的Append方法需要跨线程调用。Natcorder 在底层做了线程安全处理，只要你不是在极端情况下频繁创建销毁 Recorder，基本不会遇到崩溃问题。不过，我还是建议你在正式项目里做好音频回调的判空保护，尤其是在切换场景时。
2.3 录制文件去哪了？路径与持久化
录屏完成后的文件，Natcorder 会写入应用的持久化路径。iOS 上通常就是 App 沙盒的 Documents 或 Library 目录，Android 上则是应用私有目录，也可能是公共 Movies/Pictures 目录（取决于你的配置）。
如果你需要让玩家在相册里直接看到录好的视频，就需要在 Android 上触发一次媒体扫描，或者把文件复制到公共目录。Natcorder 本身不负责这件事，需要你自己接原生逻辑或引入第三方插件来搞定。我在项目里通常只是把文件路径返回给上层，由运营层决定是否要弹分享面板。
3. 手写录屏模块：从 CameraRecorder 到 MP4 文件
接下来是重点。我们直接写代码实现录屏功能。这里我会分步骤拆解：先改造工程结构，再给出完整代码，最后讲几个容易忽略的坑。
3.1 从零搭建录制脚本：CameraRecorder 完整实现
先看这个脚本的核心结构。我用的是 Natcorder 2.x 的CameraRecorder，它可以直接附加在 Camera 上，自动采集相机的画面。核心代码如下：
using System.Collections; using System.IO; using UnityEngine; using NatSuite.Recorders; using NatSuite.Recorders.Clocks; using NatSuite.Recorders.Inputs; public class ScreenRecorder : MonoBehaviour { [Header("录制设置")] public int videoWidth = 1280; public int videoHeight = 720; public int frameRate = 30; public int bitRate = 2_000_000; // 2Mbps private CameraRecorder cameraRecorder; private AudioRecorder audioRecorder; private RealtimeClock clock; private MP4Recorder mp4Recorder; private bool isRecording; public void StartRecording() { if (isRecording) return; // 1. 创建真实时间时钟 clock = new RealtimeClock(); // 2. 创建 MP4 编码器，支持最高 1080p mp4Recorder = new MP4Recorder( videoWidth, videoHeight, frameRate, bitRate ); // 3. 创建 CameraRecorder，采集主相机画面 cameraRecorder = new CameraRecorder( mp4Recorder, clock, Camera.main ); // 4. 需要录音就创建 AudioRecorder audioRecorder = new AudioRecorder( mp4Recorder, clock, AudioSettings.outputSampleRate, (int)AudioSettings.speakerMode ); isRecording = true; } public void StopRecording() { if (!isRecording) return; // 结束录制：CameraRecorder 和 AudioRecorder 会各自停止 cameraRecorder.Dispose(); audioRecorder.Dispose(); // 完成编码，拿到文件路径 var filePath = mp4Recorder.FinishWriting(); Debug.Log($"录制完成，文件路径：{filePath}"); isRecording = false; } private void Update() { if (isRecording && cameraRecorder != null) { // 手动提交画面帧（CameraRecorder 会在 OnRenderImage 中自动提交， // 这里主要是确保在非渲染管线场景下也有帧数据） cameraRecorder.CommitFrame(); } } }这里有一个细节要说明：CameraRecorder内部其实已经通过OnRenderImage自动提交帧了。我这里的CommitFrame只是为了一些特殊情况做保障（比如渲染管线被改、或者相机不渲染时），日常使用中你会发现即使不写 Update 里的提交也能正常工作。但写上总归更稳妥。
3.2 为什么用 MP4Recorder 而不是别的格式
Natcorder 支持多种 Recorder，最常用的就是MP4Recorder和GIFRecorder。视频文件用 MP4 几乎是唯一合理选择，原因是：
- MP4 是 H.264/HEVC 编码的标准容器，Android、iOS 系统级播放器原生支持
- MP4 有硬件编码加速，功耗比 GIF 小很多
- MP4 可以同时包含视频轨和音频轨，GIF 不行
如果你只是做"保存到相册"这种需求，MP4 是完全够用的。GIF 的真正用途通常是聊天表情包、论坛发帖、或者看重体积短小的场景。
3.3 切换录制目标的技巧：从 MP4 到 GIF 的 Recorder 封装
因为 MP4 和 GIF 在 Natcorder 中都是 Recorder 的实现，所以只要你把上层代码泛化到IRecorder层级，就可以非常方便地在两种录制模式之间切换。
private IRecorder recorder; private IClock activeClock; public void StartRecording(VideoFormat format) { activeClock = new RealtimeClock(); if (format == VideoFormat.MP4) recorder = new MP4Recorder(1280, 720, 30, 2_000_000); else if (format == VideoFormat.GIF) recorder = new GIFRecorder(320, 240, 12, 1); // 后续统一使用 recorder.AppendFrame / recorder.FinishWriting }这个泛化思路很重要，它会让你后续扩展代码时省很多事。比如以后想支持 H.265，你只需要 new 出对应的 Recorder 类型即可，不用动上层逻辑。
3.4 隐藏的坑：相机朝向、分辨率比例和内存占用
录屏最容易出现的问题，就是录出来的视频方向不对、画面被拉伸、以及内存突然涨了一大截。
相机朝向：移动端竖屏游戏比较常见。如果你的游戏是竖屏（如 1080x1920），录制分辨率也设置成 1080x1920（即宽高比为 9:16），录出来的视频就是正的。如果你设置成了 1920x1080，会导致画面被旋转 90 度或者裁切。解决方法是根据屏幕方向动态设置录制分辨率。
分辨率比例：我建议录制分辨率和屏幕显示分辨率保持一致。如果你强制设置一个不同宽高比的 Resolution，Natcorder 会直接截取中间区域，而不是等比缩放。我在项目里是这么处理的：
int screenWidth = Screen.width; int screenHeight = Screen.height; // 保证录出来的视频也是竖屏 int recordWidth = screenHeight > screenWidth ? 720 : 1280; int recordHeight = screenHeight > screenWidth ? 1280 : 720;内存占用：MP4 编码器在初始化时会分配一定量的缓冲。分辨率越大，缓冲越大，内存占用也越高。在低端 Android 机上，一次录 10 分钟的 1080p 视频，内存峰值可能到 300MB 以上，风险不小。所以除非必要，不要无脑上 2K、4K 录制。
提示：在实际项目里，我更推荐把录制分辨率控制在 720p，并主动设置 bitRate 在 2-4Mbps。这个档位在绝大多数移动端设备上都能获得不错的画质和体积平衡，也几乎不会对游戏性能产生明显影响。
4. 拍照与 GIF 动图：两个"小而实用"的扩展功能
录屏是最基础的能力，但项目里真正频繁被用到的，往往是拍照和 GIF 这两个轻量功能。前者用于生成静态分享图，后者用于快速产出低体积的动态素材。两个功能都基于 Natcorder，实现起来也不难，但细节各有讲究。
4.1 拍照实现：JPGRecorder 与 ReadPixels 的正确打开方式
很多人一看到"Natcorder 能拍照"就以为会像录屏一样直接截取当前帧。其实 Natcorder 的拍照实现，本质上是走了一个简化版的"帧提交"流程，再用 JPGRecorder 编码成 JPG 文件。但 JPGRecorder 并不是视频编码器，它的核心接口是Readback，原理上和录屏有所不同。
如果你想手动实现拍照功能，也可以不走 JPGRecorder，直接用 Unity 的Texture2D.ReadPixels加EncodeToJPG。但要注意：ReadPixels必须在相机渲染后立刻调用，并且需要设置ReadPixels的 Rect 和屏幕朝向一致。Natcorder 的JPGRecorder则帮你处理了这些底层细节。
using NatSuite.Recorders; public void TakeScreenshot() { // 这里用 JPGRecorder 只是为了证明 Natcorder 支持 var jpgRecorder = new JPGRecorder(); // 拍照逻辑：从当前相机画面读取像素 StartCoroutine(CaptureScreenshot(jpgRecorder)); } private IEnumerator CaptureScreenshot(JPGRecorder jpgRecorder) { yield return new WaitForEndOfFrame(); var texture = ScreenCapture.CaptureScreenshotAsTexture(); // 如果你不转存 JPGRecorder，可以直接用 texture.EncodeToJPG() byte[] jpgBytes = texture.EncodeToJPG(); File.WriteAllBytes(Application.persistentDataPath + "/capture.jpg", jpgBytes); Destroy(texture); jpgRecorder.Dispose(); }上面的写法走的是 Unity 原生ScreenCapture，流程最简单，适合大多数拍照需求。JPGRecorder 在 Natcorder 2.x 中主要面向"需要把 JPG 送入统一 Recorder 管线"的场景，日常拍照我反而不建议绕道。
4.2 GIF 动图制作：定制化输出尺寸与延迟
GIF 的实现和视频类似，但有几个参数特别重要：尺寸、帧率、延迟。
- 尺寸：GIF 是索引色，每帧存储成本很高，尺寸过大会让文件膨胀得厉害。常规的分享场景，320x240 到 480x360 就足够了。
- 帧率：GIF 一般不追求高帧率，8-12 FPS 在人眼视觉上已经很连贯，而且低帧率可以直接减少帧数量，显著降低文件大小。
- 延迟值：GIF 的播放节奏由帧延迟控制，Natcorder 的
GIFRecorder会基于IClock自动设置延迟，所以你只需要控制提交帧的节奏即可。
using NatSuite.Recorders; using NatSuite.Recorders.Clocks; var gifClock = new RealtimeClock(); // 320x240，12 FPS，延迟 1（越低越快） var gifRecorder = new GIFRecorder(320, 240, 12, 1); // 假设你有一个相机画面源 var gifInput = new CameraInput(gifRecorder, gifClock, Camera.main); // 开始录 3 秒 StartCoroutine(RecordGifForSeconds(gifRecorder, gifInput, 3f));GIFRecorder构造函数的第四个参数就是延迟。这个值你不需要手动去算，它遵循 GIF 规范的单位（单位是 1/100 秒，1 表示每帧 0.01 秒）。但实际使用时，如果发现生成的 GIF 播放速度过快，可以适当调高这个值（比如 5 或 8）。我通常习惯把延迟设为 1，配合 12 FPS 用起来观感最自然。
4.3 GIF 录制中的相机输入：避免黑屏的三个检查点
GIF 录制最容易翻车的场景就是"录完发现是黑屏"。我排查下来，95% 的原因出在以下三个点：
- CameraInput 是否在 LateUpdate 中提交帧：GIFRecorder 本身不会主动抓帧，它需要你手动把帧喂进去。CameraInput 会自动处理，前提是你别把它附着在一个被禁用/没有 RenderTexture 的相机上。
- 相机 culling mask 是否为空：如果相机只渲染 "Nothing" 层，那采集到的纹理自然是全黑。
- 屏幕方向是否切换：在竖屏和横屏切换时，之前的 RenderTexture 会被释放，导致后续帧采集失败。解决办法是在 OnRectTransformDimensionsChange 或方向变更回调里重建采集器。
提示：录制 GIF 时，如果相机使用的是 HDR 渲染管线，需要确保 RenderTexture 的格式是 ARGB32 或 RGBA32，否则会导致颜色异常。
5. 移动端真机踩坑：从包体到性能的实战记录
计划很完美，但现实总是会在真机上给你一巴掌。以下是我在移动端接入 Natcorder 后遇到的一些高频问题，以及对应的解决经验。
5.1 性能开销到底有多大：一局 6 分钟的实测数据
我在一个中等特效的中型手游项目里做过测试，机型为骁龙 870 平台的 Android 手机，录制设置为 720p、30 FPS、2Mbps。结论是：
- CPU 占用增加约 10%-15%：主要是视频编码的软件部分和音频采集的开销。
- 帧率下降约 2-4 帧：在个别复杂场景会掉 5 帧以上，但日常副本完全可接受。
- 内存增加约 80-120MB：其中包括编码器缓冲和纹理拷贝的临时内存。
- 温度上升速度加快：长时间录制半小时以上，手机会明显发热。
所以我的建议是：不要把录屏功能直接开放给所有玩家常驻开启，而是做成"主动点击开始/结束"的按钮。这样既满足了分享需求，又避免了后台常驻录制的性能损失。
5.2 压后台后录制的行为：你应该知道的限制
Android 和 iOS 在 App 退到后台后，渲染会被系统暂停。如果你此时没有处理，录屏会直接写入一坨黑帧或卡在最后一帧。Natcorder 不会自动感知前后台切换，你需要自己在OnApplicationPause里做处理：
private void OnApplicationPause(bool pauseStatus) { if (pauseStatus && isRecording) { // 暂停录音，但不要立即 FinishWriting，因为可能用户马上切回来 audioRecorder.Dispose(); // 或者实现一个 Pause 逻辑 } else if (!pauseStatus && isRecording) { // 恢复录音：重新创建音频适配器 audioRecorder = new AudioRecorder(mp4Recorder, clock, AudioSettings.outputSampleRate, (int)AudioSettings.speakerMode); } }在 iOS 上，退后台后如果超过一定时间没回到前台，系统可能直接杀掉 App。这种情况下，录制的临时文件可能会残留，需要再启动时清理掉。
5.3 安卓与 iOS 的差异：权限、路径与相册可见性
Android 权限：如果你要让录制的文件出现在相册，需要申请WRITE_EXTERNAL_STORAGE（Android 10 以下）或使用 MediaStore API（Android 10+）。Natcorder 本身只管写文件到指定路径，不负责相册注册。
iOS 相册：iOS 需要申请NSPhotoLibraryAddUsageDescription权限，并且写完后要调PHPhotoLibrary保存。Natcorder 也不会自动做这一步，需要你自己接一下。
路径差异：iOS 沙盒路径每次启动可能变化，所以不要把录制路径写死在内存里，建议每次从Application.persistentDataPath读取拼接。
5.4 提升录制体验的额外技巧：分辨率、码率与首帧延迟
这里分享几个我在实际项目里总结的优化点：
- 首帧延迟优化：MP4Recorder 创建后创建编码器需要一定时间，表现为"点了录制按钮，要过一两秒才开始录"。解决办法是采用"预热"策略：在玩家进入战斗前预创建 Recorder，等真正开录时直接 Append。我自己测试，预热后首帧编码时间几乎为 0。
- 码率自适应：如果你想尽量保证画质，可以根据当前网络或设备性能调整码率，而不是拍死一个固定值。通常 720p 30FPS 在 1.5-4Mbps 之间都算合理。
- 分帧采集：如果你的游戏画面经常超过 30FPS，比如跑到 60FPS，可以用
frameRate参数告诉编码器期望帧率，编码器会按这个节奏抽帧，不会导致视频文件变成慢动作或快动作。
5.5 应该避开的坑：纹理销毁、重复提交与长视频文件
下面这几个问题是我在不同客户项目里都见过的，属于高频翻车点：
纹理销毁顺序：用CameraInput录屏时，如果中途释放了 RenderTexture，但没有同步移除 CameraInput，会导致下一帧提交空纹理，录出的视频会出现花屏或黑块。正确做法是：先 Dispose 掉输入源，再释放 RenderTexture。
重复提交：如果同一个 Recorder 被两个 CameraInput 同时使用（比如主相机和 UI 相机都加了组件），会导致画面撕裂或文件损坏。解决办法是统一用一个CameraRecorder，或者手动控制以免重复 Append。
长视频文件：MP4 录制超过 30 分钟，部分 Android 机型会出现"文件头损坏导致无法播放"的情况。实际上这是 FAT32 或某些多媒体库的 4GB 文件大小限制。解决办法是按时长自动分段录制：每 20 分钟结束当前 Recorder，创建一个新的，并拼接文件列表。
6. 从录屏到产品化：完整流程与优化经验
如果你只是演示用，录屏功能能跑通就够用了。但要在正式游戏里做成一个玩家可用、体验良好的功能，还有不少细节要打磨。
6.1 如何把录屏从"功能"变成"产品"
好用的分享功能，通常包含这些环节：
- 录制前：告诉玩家即将录制的时长上限（比如最长 30 秒），避免无意识录太久产生超大文件。
- 录制中：显示一个明确的录制状态 UI（红点+计时），并提供"停止并保存"和"取消录制"两个操作。
- 录制后：生成预览图或视频预览，让玩家决定是否保存/分享。
- 分享到社交平台：iOS 用
UIActivityViewController，Android 用 Intent 发送文件。这里可能需要额外的原生桥接插件。
Natcorder 只负责"生成文件"，上面这些流程都需要你自建。我见过有的项目把预览和分享都做了，有的只做了"录制完自动弹系统分享面板"。就看你的运营需求。
6.2 降低文件大小的方法：为何你的 GIF 比视频还大
有一个很容易踩的坑：你觉得 GIF 肯定比视频小，结果录出来 5MB 的 GIF，同场景视频才 2MB。原因在于 GIF 是索引色，不支持高效压缩，而且逐帧存储全图。优化方法只有三板斧：
- 缩小尺寸：320x240 起步，不要超过 480x360。
- 降低帧率：8 FPS 足够，12 FPS 是上限。
- 减少延迟值：延迟值越小，播放节奏越快，看起来越流畅，但文件也会偏大，需要在两者间取平衡。
如果这样压缩后文件仍然太大，那就别用 GIF 了，改用短 MP4 视频，体验会好很多。
6.3 录制模块的架构拆分：与游戏主循环解耦
最后聊一下产品级架构。我不建议把录屏逻辑跟游戏业务代码耦合在一起，而是单独做一个RecordingManager，通过事件对外广播录制状态。
public static class RecordingManager { public static event System.Action<string> OnRecordingFinished; public static event System.Action<float> OnRecordingTimeUpdated; private static ScreenRecorder recorder; public static void Start() { recorder = new GameObject("ScreenRecorder").AddComponent<ScreenRecorder>(); recorder.StartRecording(); } public static void Stop() { recorder.StopRecording(); Object.Destroy(recorder.gameObject); } }这样一个全局管理器，可以在战斗、剧情、UI 界面上任意调用，只要你做好开始和结束的配对，不重复触发即可。实际项目中，我一般还会在 UI 上绑定快捷键（比如同时按两个键触发录制隐藏调试面板），方便测试。
6.4 你的真正需求是"录屏 + 拍照 + GIF"，还是只要其中两个？
在接入 Natcorder 前，建议先明确你到底需要几个能力。很多项目一开始说"录屏、拍照、GIF 全都要"，但做完了发现，玩家用得最多的只有录屏，拍照和 GIF 的调用率极低。
如果你追求最小成本，那只需录屏（MP4）就够了。拍照可以直接用 Unity 的ScreenCapture.CaptureScreenshotAsTexture，GIF 也可以等真有需求再加上。Natcorder 好就好在，它是一个全流程打通的基础能力，你随时可以在已有工程上增加新的 Recorder 类型，不需要动底层架构。
从工程角度来看，我的建议是：先花一个晚上把录屏跑通，再对照官方 Demo 把拍照和 GIF 的代码分别看看，理解它们的参数差异，然后按需接入。当你把这三个能力都沉淀成一套统一的录制管理器后，后续任何业务方要"精彩时刻""录制回放""截图分享"，你都能很快给出方案。
