1. 项目概述为什么小游戏视频录制是个“技术活”作为一名Unity开发者当你把精心打磨的游戏成功发布到微信小游戏平台看着用户量蹭蹭上涨成就感自然爆棚。但很快运营和市场的同事就会找上门“咱们游戏里那个超酷的连招玩家想录下来分享到朋友圈或者视频号怎么实现” 或者你自己也想做游戏内的精彩时刻自动保存、用户UGC内容生成甚至是为游戏直播提供素材。这时“视频录制”这个功能就从“锦上添花”变成了“雪中送炭”。然而Unity开发微信小游戏视频录制远不是调用一个ScreenCapture.CaptureScreenshot那么简单。它横跨了Unity渲染、微信小游戏特殊环境、浏览器API、性能优化和平台规范等多个技术领域是一个典型的“牵一发而动全身”的复合型需求。核心难点在于微信小游戏本质上是一个运行在微信内的WebGL环境它没有原生操作系统如Android/iOS那样直接、高效的屏幕录制接口。你无法直接使用MediaRecorder这样的原生API一切都需要在WebGL的限制下通过Canvas和WebGL的纹理数据“绕路”实现。这个过程涉及到从Unity的渲染管线中“窃取”每一帧的画面将其转换为浏览器能处理的图像数据通常是RGBA像素数组然后通过一系列编码、压缩、存储操作最终生成一个视频文件。这其中的每一步都可能成为性能瓶颈或兼容性陷阱。比如全屏录制时巨大的内存开销、编码导致的帧率下降、不同安卓机型上的色彩空间差异、微信缓存策略导致的文件保存失败等等。因此一个“高效”的实现方案绝不仅仅是功能跑通更意味着在有限的微信小游戏运行环境下内存、CPU、线程模型实现稳定、流畅、低功耗的录制体验并且生成的视频文件要能顺利保存到用户的手机相册或通过微信接口分享出去。接下来我将结合多年的踩坑经验为你拆解从原理到实现的完整路径。2. 核心方案选型在WebGL的“围城”里找到出路面对微信小游戏视频录制我们首先得摒弃桌面端或原生平台的思维。这里没有FFmpeg命令行工具也没有系统级的AVFoundation或MediaCodec。我们的战场是浏览器环境武器库主要是JavaScript的MediaRecorderAPI、CanvasAPI以及WebAssembly带来的计算能力。2.1 主流技术路线对比目前在Unity WebGL包括微信小游戏适配后的环境中实现录屏主要有三条技术路径路径一基于Canvas2D与MediaRecorder API推荐用于2D/UI录制这是最“Web标准”的做法。原理是每一帧将Unity渲染的内容一个WebGL Canvas绘制到另一个隐藏的2D Canvas上然后使用MediaRecorder对这个2D Canvas的流进行录制。优点实现相对直接兼容性较好利用了浏览器自身的编码能力通常为VP8/VP9或H.264生成的WebM或MP4文件体积和质量比较均衡。缺点MediaRecorder在部分移动端浏览器尤其是低版本WebView上支持有限编码性能开销大录制高分辨率、高帧率内容时容易导致游戏卡顿。并且它无法直接录制WebGL的透明背景Alpha通道对于需要透明背景的合成场景不友好。路径二基于WebGL纹理与编码器库推荐用于高性能、自定义需求这是更底层、更灵活的方案。原理是每一帧从Unity的WebGL上下文中读取渲染缓冲区的像素数据gl.readPixels得到一个巨大的RGBA数组。然后在JavaScript侧或通过WebAssembly运行一个软编码器如libvpx用于VP8/VP9x264用于H.264将这些原始帧数据压缩成视频。优点性能控制粒度细可以自定义编码参数码率、关键帧间隔等理论上支持所有浏览器因为编码是自己做的可以处理带Alpha通道的视频。缺点实现复杂度极高需要集成和编译编码器库到WebAssembly内存占用大需要存储多帧原始数据用于编码JavaScript与WebAssembly间大量的数据交换readPixels的数据可能成为瓶颈。路径三利用平台特定能力微信小游戏扩展微信小游戏环境提供了一些原生能力的JS桥接虽然不直接提供录屏API但我们可以结合其他能力。例如可以先通过上述方法生成一系列帧图片PNG序列然后利用微信的wx.createVideo或文件系统API进行合成。或者对于“精彩时刻”这类需求可以预先在游戏逻辑中标记时间段录制时实际是“回放”游戏状态并重新渲染输出但这已属于游戏录像回放系统范畴。优点能与微信生态如保存到相册、分享深度结合。缺点非实时录制流程复杂对游戏架构有要求。实操心得对于大多数追求开发效率和稳定性的项目我强烈推荐改良后的路径一。即使用MediaRecorder但通过一系列优化手段如降低录制画布分辨率、使用requestVideoFrameCallback精准控制帧捕获时机、在Worker中处理编码来规避其性能问题。它能在90%的场景下提供足够好的体验。路径二更适合对视频质量、格式有硬性要求的专业场景如游戏宣传片制作工具内嵌于游戏中。2.2 Unity侧的准备工作渲染输出与桥接无论选择哪条路径Unity侧的核心任务都是一致的将每一帧渲染好的图像以一种高效的方式传递给JavaScript环境。创建渲染目标我们通常不直接录制主屏幕因为那可能包含Unity编辑器的UI或者不适合录制的元素。更专业的做法是创建一个专用的Camera其Target Texture指向一个RenderTexture。这个相机只渲染你希望录制的游戏内容如主游戏画面、UI层等。这样你可以自由控制录制的视口、分辨率、抗锯齿等效果。建立C#与JS的通信Unity WebGL通过[DllImport(“__Internal”)]调用JavaScript函数。我们需要暴露一个接口让JS能通知Unity“开始录制”、“结束录制”并在每一帧请求图像数据。传递图像数据最直接的方式是将RenderTexture的像素数据读取到byte[]然后通过System.Runtime.InteropServices.Marshal拷贝到JavaScript的HEAP8Emscripten提供的堆内存中。但请注意Texture2D.ReadPixels和GetRawTextureData是同步且耗时的操作必须谨慎使用。// C# 示例将RenderTexture数据写入到JS可访问的内存中 using System.Runtime.InteropServices; public class ScreenRecorder : MonoBehaviour { public Camera recordCamera; private RenderTexture renderTexture; private System.IntPtr textureDataPtr; private int dataSize; [DllImport(__Internal)] private static extern void ReceiveFrameData(System.IntPtr data, int width, int height); void Start() { // 创建RenderTexture分辨率可以是屏幕的1/2或1/4以提升性能 renderTexture new RenderTexture(960, 540, 24, RenderTextureFormat.ARGB32); recordCamera.targetTexture renderTexture; dataSize 960 * 540 * 4; // ARGB32格式每个像素4字节 } // 此方法由JS每帧调用 public void CaptureFrame() { // 临时激活RenderTexture并读取 RenderTexture.active renderTexture; Texture2D tempTex new Texture2D(960, 540, TextureFormat.ARGB32, false); tempTex.ReadPixels(new Rect(0, 0, 960, 540), 0, 0); tempTex.Apply(); RenderTexture.active null; // 获取字节数据并传递到JS byte[] byteArray tempTex.GetRawTextureData(); // 将C#数组数据复制到JS堆中这里简化了内存管理实际需使用Emscripten的堆 // 更优做法是使用Unity提供的Emscripten函数如emscripten_webgl_commit_frame // 此处仅为示意 GCHandle handle GCHandle.Alloc(byteArray, GCHandleType.Pinned); ReceiveFrameData(handle.AddrOfPinnedObject(), 960, 540); handle.Free(); Destroy(tempTex); } }关键优化点上述代码中的CaptureFrame每帧都创建和销毁Texture2D这是巨大的性能开销。实际项目中应该复用Texture2D对象并探索使用AsyncGPUReadbackWebGL 2.0支持或CommandBuffer进行异步读取避免阻塞渲染线程。对于微信小游戏由于环境限制更务实的做法是降低帧率如每秒录制15或30帧和分辨率。3. 高效录制的核心JavaScript侧实现与优化Unity侧准备好数据后重头戏就在JavaScript侧。我们的目标是构建一个稳定、高效的录制管线。3.1 构建录制管线假设我们采用基于Canvas2D和MediaRecorder的优化方案核心流程如下初始化Canvas与Context创建一个与录制分辨率匹配的canvas元素可设置为display: none。获取其2D上下文(canvas.getContext(2d))。获取图像数据并绘制在每一帧从Unity传递过来的内存地址或通过更高效的ImageBitmap中获取RGBA数据使用putImageData或drawImage将其绘制到2D Canvas上。// 假设unityFrameData是一个ImageBitmap对象由Unity通过createImageBitmap生成 function processFrame(unityFrameData) { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.drawImage(unityFrameData, 0, 0, canvas.width, canvas.height); }配置与启动MediaRecorder从Canvas获取MediaStream(canvas.captureStream(frameRate))然后使用MediaRecorder进行录制。这里需要仔细选择mimeType。const stream canvas.captureStream(30); // 30 FPS const mimeType MediaRecorder.isTypeSupported(video/webm;codecsvp9) ? video/webm;codecsvp9 : video/webm; // 降级选择 const mediaRecorder new MediaRecorder(stream, { mimeType: mimeType }); let recordedChunks []; mediaRecorder.ondataavailable (event) { if (event.data.size 0) { recordedChunks.push(event.data); } }; mediaRecorder.onstop () { // 录制完成处理数据 const blob new Blob(recordedChunks, { type: mimeType }); // 后续处理blob如保存或上传 }; mediaRecorder.start(1000); // 每1000ms触发一次ondataavailable3.2 性能优化实战技巧直接按上述流程做在移动端大概率会卡顿。以下是几个关键的优化点降低采样率与分辨率游戏运行在60FPS不代表录制也需要60FPS。对于分享用途30FPS甚至24FPS完全足够。同样录制分辨率可以设置为游戏渲染分辨率的1/2或1/4这能极大减少readPixels和drawImage的数据量。使用requestVideoFrameCallback(如果可用)这是一个新的API允许你在浏览器合成一帧视频包括Canvas之前或之后回调你的代码。用它来替代requestAnimationFrame进行帧捕获可以更好地对齐浏览器的渲染节奏避免丢帧或重复帧。在Web Worker中进行编码MediaRecorder的编码工作仍然在主线程。我们可以尝试将Canvas的流通过OffscreenCanvas和transferControlToOffscreen转移到Worker中在Worker里运行MediaRecorder。这能避免编码计算阻塞UI和游戏逻辑线程。不过微信小游戏对Worker的支持度和OffscreenCanvas的兼容性需要仔细测试。内存与GC优化避免在每一帧都创建新的ImageData或ArrayBuffer对象。复用内存池。及时释放不再需要的ImageBitmap对象调用.close()方法。分段录制与即时保存对于长时间录制不要等到最后才生成一个巨大的Blob。利用MediaRecorder.start(timeslice)参数定期如每10秒获取一个数据片段(Blob)立即通过微信文件系统API (wx.getFileSystemManager())保存到临时文件。最后再将这些文件合并。这能有效控制内存峰值。3.3 与微信小游戏环境集成录制完成的视频Blob需要落地到微信小游戏的文件系统中才能进一步操作。保存到临时文件使用wx.getFileSystemManager().writeFile()将Blob数据写入小游戏的用户临时文件路径wx.env.USER_DATA_PATH。注意这里写入的是二进制文件需要将Blob转换为ArrayBuffer。const fs wx.getFileSystemManager(); const tempFilePath ${wx.env.USER_DATA_PATH}/temp_record.webm; blob.arrayBuffer().then(buffer { fs.writeFile({ filePath: tempFilePath, data: buffer, encoding: binary, success: () console.log(视频临时保存成功), fail: console.error }); });保存到手机相册这是用户最需要的功能。需要使用微信的wx.saveVideoToPhotosAlbum接口。但注意该接口要求文件路径是本地临时文件路径即上一步保存的路径且需要用户授权scope.writePhotosAlbum。wx.saveVideoToPhotosAlbum({ filePath: tempFilePath, success: () { wx.showToast({ title: 已保存到相册 }); }, fail: (res) { if (res.errMsg.indexOf(auth deny) -1) { // 引导用户去设置页打开相册权限 wx.showModal({ title: 提示, content: 需要您授权保存到相册, success: (res) { if (res.confirm) wx.openSetting(); } }); } } });分享到朋友圈或聊天可以使用wx.shareAppMessage或wx.shareVideoMessage如果支持进行分享。通常需要先上传到微信服务器获取一个videoId或者分享临时文件路径。具体需查阅最新的微信小游戏分享API文档。4. 避坑指南与常见问题排查在实际开发中你会遇到各种各样的问题。下面是我总结的一些典型“坑”及其解决方案。4.1 性能与兼容性问题问题现象可能原因排查与解决思路录制开始后游戏严重卡顿FPS骤降。1.readPixels或数据传递同步阻塞主线程。2.MediaRecorder编码占用大量CPU。3. 内存频繁分配/回收触发GC。1.降低录制分辨率/帧率这是最有效的方法。2. 使用WebGL2的PIXEL_PACK_BUFFER进行异步读取如果环境支持。3. 检查是否在每帧都new了对象改为复用。4. 尝试在独立的requestVideoFrameCallback中处理捕获与游戏主循环解耦。在部分安卓机型特别是低端机上录制失败或花屏。1. 设备不支持选定的mimeType如vp9。2.WebGL上下文丢失或恢复机制未处理好。3. 内存不足ArrayBuffer分配失败。1.做好兼容性检测MediaRecorder.isTypeSupported()动态选择编码格式优先vp8再降级到无编码格式的webm。2. 监听webglcontextlost和webglcontextrestored事件在上下文丢失时暂停录制恢复后重新初始化。3. 录制前检查可用内存动态调整录制参数如进一步降低画质。录制的视频播放时绿屏、颜色异常或上下颠倒。1.WebGL与Canvas2D的像素格式和Y轴方向不一致。WebGL的readPixels默认左下角为原点而Canvas2D的putImageData默认左上角为原点。2. 色彩空间线性 vs sRGB未转换。1.翻转Y轴在将像素数据绘制到Canvas前手动翻转每一行数据或者使用ctx.scale(1, -1)和ctx.translate(0, -canvas.height)进行坐标系变换。2.颜色转换如果游戏使用线性空间渲染而录制输出需要sRGB需要在Shader中转换或后期处理。一个简单测试是录制一个纯灰色128,128,128画面看播放是否还是灰色。录制文件非常大。码率过高。MediaRecorder默认码率可能很高。目前MediaRecorder构造函数对码率的控制支持有限。如果文件体积是硬性要求可能需要考虑路径二软编码使用libvpx或x264并设置目标码率CRF或VBR模式。4.2 微信平台特定问题wx.saveVideoToPhotosAlbum提示“文件不存在”确保你保存的临时文件路径是正确的并且writeFile操作是同步或已成功回调后再调用保存。微信的文件系统是沙盒化的不能直接使用blob://或http://开头的路径。保存到相册成功但在手机相册里找不到部分安卓机型如小米、OPPO由于系统定制原因保存后需要手动刷新相册或等待媒体扫描器扫描。可以在保存成功后提示用户“视频已保存可能在相册的‘其他相册’或需要稍等片刻才能看到”。内存泄漏导致小游戏闪退长时间录制或频繁开始/结束录制如果ImageBitmap、ArrayBuffer、Blob等对象没有正确释放会导致内存持续增长。务必在对象不再使用时调用.close()对于ImageBitmap或将其引用置为null。使用微信开发者工具的“内存”面板进行快照对比查找泄漏点。iOS与安卓效果不一致iOS的WebKit引擎和安卓的Chrome/WebView内核在MediaRecorder的实现、Canvas绘制性能、垃圾回收策略上都有差异。必须进行真机跨平台测试。一个常见差异是iOS上canvas.captureStream的帧率可能不稳定。4.3 进阶优化使用WASM编码器如果你对视频质量和文件大小有极致要求并且团队有足够的技术储备集成WASM编码器是终极方案。这里以libvpxVP8/VP9编码为例简述步骤获取编码器库找到libvpx的Emscripten编译版本或者自己用Emscripten工具链编译。你会得到一个.wasm文件和一个JavaScript胶水代码文件。在Unity中集成将.wasm文件作为TextAsset导入Unity打包时放入StreamingAssets。在小游戏启动时通过wx.loadWasm或fetch加载并实例化。数据传递Unity将每一帧的RGB数据可能需要从ARGB转换传递到JavaScript。JS侧将数据拷贝到WASM模块的线性内存中。编码调用WASM模块中的编码函数传入帧数据。编码器会输出压缩后的视频数据块。封装将编码出的裸流如IVF格式的VP8数据封装成WebM容器。这需要在JS侧实现一个简单的WebM复用器Muxer将视频轨、音频轨如果有和元数据打包。生成文件将封装好的数据写入ArrayBuffer生成Blob后续步骤同上。这个过程非常复杂涉及音视频封装格式、编码参数调优等专业知识但带来的好处是完全可控的编码质量、支持Alpha通道、更好的跨平台一致性。除非必要不建议中小型项目轻易尝试。5. 完整实现流程与代码结构建议最后给出一个在Unity项目中组织录制功能的模块化建议确保代码可维护、可扩展。项目结构示例Assets/ ├── Plugins/WebGL/ (存放与JS交互的特定插件) ├── Scripts/ │ ├── ScreenRecorder/ │ │ ├── ScreenRecorder.cs (主控制器管理状态、分辨率、帧率) │ │ ├── RenderTextureCapturer.cs (负责从特定Camera捕获到RenderTexture) │ │ ├── IFrameDataExporter.cs (数据导出接口) │ │ └── WebGLFrameExporter.cs (实现IFrameDataExporter调用JS桥接) │ └── ... (其他游戏逻辑) └── WebGLTemplates/WeChatMiniGame/ (微信小游戏发布模板) ├── index.html ├── unityloader.js └── screen-recorder-bridge.js (包含所有JS端录制逻辑)核心交互时序游戏启动初始化ScreenRecorder创建隐藏的录制用Camera和RenderTexture。用户点击“开始录制”按钮C#调用JS的startRecording(width, height, fps)。JS端初始化Canvas、MediaRecorder并开始一个循环使用requestVideoFrameCallback或降频的setInterval每帧调用C#的CaptureFrame()。C#端的CaptureFrame()将当前RenderTexture的数据通过桥接传到JS。JS端接收到数据绘制到CanvasMediaRecorder将其编码成视频块。用户点击“结束录制”C#调用JS的stopRecording()。JS端停止MediaRecorder收集所有数据块生成Blob调用微信API保存到临时文件。提示用户“录制完成”并提供“保存到相册”或“分享”的按钮。一个重要的细节开始和结束录制的调用必须放在用户交互事件如按钮点击的回调里。因为浏览器的MediaRecorder和canvas.captureStream()API通常要求必须在用户手势触发user gesture的短时间内调用否则会被浏览器安全策略阻止。实现微信小游戏视频录制就像在螺蛳壳里做道场空间有限但要求颇高。从方案选型到性能优化再到平台适配每一步都需要精细的权衡和扎实的测试。希望这份指南能帮你避开我当年踩过的那些坑更顺畅地将这个提升用户体验和游戏传播性的重要功能落地。记住在移动Web环境下“先跑通再优化”是永恒的真理用最小的代价验证核心流程然后根据性能分析数据有的放矢地进行优化。 Unity微信小游戏视频录制：WebGL环境下的高性能实现方案
1. 项目概述为什么小游戏视频录制是个“技术活”作为一名Unity开发者当你把精心打磨的游戏成功发布到微信小游戏平台看着用户量蹭蹭上涨成就感自然爆棚。但很快运营和市场的同事就会找上门“咱们游戏里那个超酷的连招玩家想录下来分享到朋友圈或者视频号怎么实现” 或者你自己也想做游戏内的精彩时刻自动保存、用户UGC内容生成甚至是为游戏直播提供素材。这时“视频录制”这个功能就从“锦上添花”变成了“雪中送炭”。然而Unity开发微信小游戏视频录制远不是调用一个ScreenCapture.CaptureScreenshot那么简单。它横跨了Unity渲染、微信小游戏特殊环境、浏览器API、性能优化和平台规范等多个技术领域是一个典型的“牵一发而动全身”的复合型需求。核心难点在于微信小游戏本质上是一个运行在微信内的WebGL环境它没有原生操作系统如Android/iOS那样直接、高效的屏幕录制接口。你无法直接使用MediaRecorder这样的原生API一切都需要在WebGL的限制下通过Canvas和WebGL的纹理数据“绕路”实现。这个过程涉及到从Unity的渲染管线中“窃取”每一帧的画面将其转换为浏览器能处理的图像数据通常是RGBA像素数组然后通过一系列编码、压缩、存储操作最终生成一个视频文件。这其中的每一步都可能成为性能瓶颈或兼容性陷阱。比如全屏录制时巨大的内存开销、编码导致的帧率下降、不同安卓机型上的色彩空间差异、微信缓存策略导致的文件保存失败等等。因此一个“高效”的实现方案绝不仅仅是功能跑通更意味着在有限的微信小游戏运行环境下内存、CPU、线程模型实现稳定、流畅、低功耗的录制体验并且生成的视频文件要能顺利保存到用户的手机相册或通过微信接口分享出去。接下来我将结合多年的踩坑经验为你拆解从原理到实现的完整路径。2. 核心方案选型在WebGL的“围城”里找到出路面对微信小游戏视频录制我们首先得摒弃桌面端或原生平台的思维。这里没有FFmpeg命令行工具也没有系统级的AVFoundation或MediaCodec。我们的战场是浏览器环境武器库主要是JavaScript的MediaRecorderAPI、CanvasAPI以及WebAssembly带来的计算能力。2.1 主流技术路线对比目前在Unity WebGL包括微信小游戏适配后的环境中实现录屏主要有三条技术路径路径一基于Canvas2D与MediaRecorder API推荐用于2D/UI录制这是最“Web标准”的做法。原理是每一帧将Unity渲染的内容一个WebGL Canvas绘制到另一个隐藏的2D Canvas上然后使用MediaRecorder对这个2D Canvas的流进行录制。优点实现相对直接兼容性较好利用了浏览器自身的编码能力通常为VP8/VP9或H.264生成的WebM或MP4文件体积和质量比较均衡。缺点MediaRecorder在部分移动端浏览器尤其是低版本WebView上支持有限编码性能开销大录制高分辨率、高帧率内容时容易导致游戏卡顿。并且它无法直接录制WebGL的透明背景Alpha通道对于需要透明背景的合成场景不友好。路径二基于WebGL纹理与编码器库推荐用于高性能、自定义需求这是更底层、更灵活的方案。原理是每一帧从Unity的WebGL上下文中读取渲染缓冲区的像素数据gl.readPixels得到一个巨大的RGBA数组。然后在JavaScript侧或通过WebAssembly运行一个软编码器如libvpx用于VP8/VP9x264用于H.264将这些原始帧数据压缩成视频。优点性能控制粒度细可以自定义编码参数码率、关键帧间隔等理论上支持所有浏览器因为编码是自己做的可以处理带Alpha通道的视频。缺点实现复杂度极高需要集成和编译编码器库到WebAssembly内存占用大需要存储多帧原始数据用于编码JavaScript与WebAssembly间大量的数据交换readPixels的数据可能成为瓶颈。路径三利用平台特定能力微信小游戏扩展微信小游戏环境提供了一些原生能力的JS桥接虽然不直接提供录屏API但我们可以结合其他能力。例如可以先通过上述方法生成一系列帧图片PNG序列然后利用微信的wx.createVideo或文件系统API进行合成。或者对于“精彩时刻”这类需求可以预先在游戏逻辑中标记时间段录制时实际是“回放”游戏状态并重新渲染输出但这已属于游戏录像回放系统范畴。优点能与微信生态如保存到相册、分享深度结合。缺点非实时录制流程复杂对游戏架构有要求。实操心得对于大多数追求开发效率和稳定性的项目我强烈推荐改良后的路径一。即使用MediaRecorder但通过一系列优化手段如降低录制画布分辨率、使用requestVideoFrameCallback精准控制帧捕获时机、在Worker中处理编码来规避其性能问题。它能在90%的场景下提供足够好的体验。路径二更适合对视频质量、格式有硬性要求的专业场景如游戏宣传片制作工具内嵌于游戏中。2.2 Unity侧的准备工作渲染输出与桥接无论选择哪条路径Unity侧的核心任务都是一致的将每一帧渲染好的图像以一种高效的方式传递给JavaScript环境。创建渲染目标我们通常不直接录制主屏幕因为那可能包含Unity编辑器的UI或者不适合录制的元素。更专业的做法是创建一个专用的Camera其Target Texture指向一个RenderTexture。这个相机只渲染你希望录制的游戏内容如主游戏画面、UI层等。这样你可以自由控制录制的视口、分辨率、抗锯齿等效果。建立C#与JS的通信Unity WebGL通过[DllImport(“__Internal”)]调用JavaScript函数。我们需要暴露一个接口让JS能通知Unity“开始录制”、“结束录制”并在每一帧请求图像数据。传递图像数据最直接的方式是将RenderTexture的像素数据读取到byte[]然后通过System.Runtime.InteropServices.Marshal拷贝到JavaScript的HEAP8Emscripten提供的堆内存中。但请注意Texture2D.ReadPixels和GetRawTextureData是同步且耗时的操作必须谨慎使用。// C# 示例将RenderTexture数据写入到JS可访问的内存中 using System.Runtime.InteropServices; public class ScreenRecorder : MonoBehaviour { public Camera recordCamera; private RenderTexture renderTexture; private System.IntPtr textureDataPtr; private int dataSize; [DllImport(__Internal)] private static extern void ReceiveFrameData(System.IntPtr data, int width, int height); void Start() { // 创建RenderTexture分辨率可以是屏幕的1/2或1/4以提升性能 renderTexture new RenderTexture(960, 540, 24, RenderTextureFormat.ARGB32); recordCamera.targetTexture renderTexture; dataSize 960 * 540 * 4; // ARGB32格式每个像素4字节 } // 此方法由JS每帧调用 public void CaptureFrame() { // 临时激活RenderTexture并读取 RenderTexture.active renderTexture; Texture2D tempTex new Texture2D(960, 540, TextureFormat.ARGB32, false); tempTex.ReadPixels(new Rect(0, 0, 960, 540), 0, 0); tempTex.Apply(); RenderTexture.active null; // 获取字节数据并传递到JS byte[] byteArray tempTex.GetRawTextureData(); // 将C#数组数据复制到JS堆中这里简化了内存管理实际需使用Emscripten的堆 // 更优做法是使用Unity提供的Emscripten函数如emscripten_webgl_commit_frame // 此处仅为示意 GCHandle handle GCHandle.Alloc(byteArray, GCHandleType.Pinned); ReceiveFrameData(handle.AddrOfPinnedObject(), 960, 540); handle.Free(); Destroy(tempTex); } }关键优化点上述代码中的CaptureFrame每帧都创建和销毁Texture2D这是巨大的性能开销。实际项目中应该复用Texture2D对象并探索使用AsyncGPUReadbackWebGL 2.0支持或CommandBuffer进行异步读取避免阻塞渲染线程。对于微信小游戏由于环境限制更务实的做法是降低帧率如每秒录制15或30帧和分辨率。3. 高效录制的核心JavaScript侧实现与优化Unity侧准备好数据后重头戏就在JavaScript侧。我们的目标是构建一个稳定、高效的录制管线。3.1 构建录制管线假设我们采用基于Canvas2D和MediaRecorder的优化方案核心流程如下初始化Canvas与Context创建一个与录制分辨率匹配的canvas元素可设置为display: none。获取其2D上下文(canvas.getContext(2d))。获取图像数据并绘制在每一帧从Unity传递过来的内存地址或通过更高效的ImageBitmap中获取RGBA数据使用putImageData或drawImage将其绘制到2D Canvas上。// 假设unityFrameData是一个ImageBitmap对象由Unity通过createImageBitmap生成 function processFrame(unityFrameData) { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.drawImage(unityFrameData, 0, 0, canvas.width, canvas.height); }配置与启动MediaRecorder从Canvas获取MediaStream(canvas.captureStream(frameRate))然后使用MediaRecorder进行录制。这里需要仔细选择mimeType。const stream canvas.captureStream(30); // 30 FPS const mimeType MediaRecorder.isTypeSupported(video/webm;codecsvp9) ? video/webm;codecsvp9 : video/webm; // 降级选择 const mediaRecorder new MediaRecorder(stream, { mimeType: mimeType }); let recordedChunks []; mediaRecorder.ondataavailable (event) { if (event.data.size 0) { recordedChunks.push(event.data); } }; mediaRecorder.onstop () { // 录制完成处理数据 const blob new Blob(recordedChunks, { type: mimeType }); // 后续处理blob如保存或上传 }; mediaRecorder.start(1000); // 每1000ms触发一次ondataavailable3.2 性能优化实战技巧直接按上述流程做在移动端大概率会卡顿。以下是几个关键的优化点降低采样率与分辨率游戏运行在60FPS不代表录制也需要60FPS。对于分享用途30FPS甚至24FPS完全足够。同样录制分辨率可以设置为游戏渲染分辨率的1/2或1/4这能极大减少readPixels和drawImage的数据量。使用requestVideoFrameCallback(如果可用)这是一个新的API允许你在浏览器合成一帧视频包括Canvas之前或之后回调你的代码。用它来替代requestAnimationFrame进行帧捕获可以更好地对齐浏览器的渲染节奏避免丢帧或重复帧。在Web Worker中进行编码MediaRecorder的编码工作仍然在主线程。我们可以尝试将Canvas的流通过OffscreenCanvas和transferControlToOffscreen转移到Worker中在Worker里运行MediaRecorder。这能避免编码计算阻塞UI和游戏逻辑线程。不过微信小游戏对Worker的支持度和OffscreenCanvas的兼容性需要仔细测试。内存与GC优化避免在每一帧都创建新的ImageData或ArrayBuffer对象。复用内存池。及时释放不再需要的ImageBitmap对象调用.close()方法。分段录制与即时保存对于长时间录制不要等到最后才生成一个巨大的Blob。利用MediaRecorder.start(timeslice)参数定期如每10秒获取一个数据片段(Blob)立即通过微信文件系统API (wx.getFileSystemManager())保存到临时文件。最后再将这些文件合并。这能有效控制内存峰值。3.3 与微信小游戏环境集成录制完成的视频Blob需要落地到微信小游戏的文件系统中才能进一步操作。保存到临时文件使用wx.getFileSystemManager().writeFile()将Blob数据写入小游戏的用户临时文件路径wx.env.USER_DATA_PATH。注意这里写入的是二进制文件需要将Blob转换为ArrayBuffer。const fs wx.getFileSystemManager(); const tempFilePath ${wx.env.USER_DATA_PATH}/temp_record.webm; blob.arrayBuffer().then(buffer { fs.writeFile({ filePath: tempFilePath, data: buffer, encoding: binary, success: () console.log(视频临时保存成功), fail: console.error }); });保存到手机相册这是用户最需要的功能。需要使用微信的wx.saveVideoToPhotosAlbum接口。但注意该接口要求文件路径是本地临时文件路径即上一步保存的路径且需要用户授权scope.writePhotosAlbum。wx.saveVideoToPhotosAlbum({ filePath: tempFilePath, success: () { wx.showToast({ title: 已保存到相册 }); }, fail: (res) { if (res.errMsg.indexOf(auth deny) -1) { // 引导用户去设置页打开相册权限 wx.showModal({ title: 提示, content: 需要您授权保存到相册, success: (res) { if (res.confirm) wx.openSetting(); } }); } } });分享到朋友圈或聊天可以使用wx.shareAppMessage或wx.shareVideoMessage如果支持进行分享。通常需要先上传到微信服务器获取一个videoId或者分享临时文件路径。具体需查阅最新的微信小游戏分享API文档。4. 避坑指南与常见问题排查在实际开发中你会遇到各种各样的问题。下面是我总结的一些典型“坑”及其解决方案。4.1 性能与兼容性问题问题现象可能原因排查与解决思路录制开始后游戏严重卡顿FPS骤降。1.readPixels或数据传递同步阻塞主线程。2.MediaRecorder编码占用大量CPU。3. 内存频繁分配/回收触发GC。1.降低录制分辨率/帧率这是最有效的方法。2. 使用WebGL2的PIXEL_PACK_BUFFER进行异步读取如果环境支持。3. 检查是否在每帧都new了对象改为复用。4. 尝试在独立的requestVideoFrameCallback中处理捕获与游戏主循环解耦。在部分安卓机型特别是低端机上录制失败或花屏。1. 设备不支持选定的mimeType如vp9。2.WebGL上下文丢失或恢复机制未处理好。3. 内存不足ArrayBuffer分配失败。1.做好兼容性检测MediaRecorder.isTypeSupported()动态选择编码格式优先vp8再降级到无编码格式的webm。2. 监听webglcontextlost和webglcontextrestored事件在上下文丢失时暂停录制恢复后重新初始化。3. 录制前检查可用内存动态调整录制参数如进一步降低画质。录制的视频播放时绿屏、颜色异常或上下颠倒。1.WebGL与Canvas2D的像素格式和Y轴方向不一致。WebGL的readPixels默认左下角为原点而Canvas2D的putImageData默认左上角为原点。2. 色彩空间线性 vs sRGB未转换。1.翻转Y轴在将像素数据绘制到Canvas前手动翻转每一行数据或者使用ctx.scale(1, -1)和ctx.translate(0, -canvas.height)进行坐标系变换。2.颜色转换如果游戏使用线性空间渲染而录制输出需要sRGB需要在Shader中转换或后期处理。一个简单测试是录制一个纯灰色128,128,128画面看播放是否还是灰色。录制文件非常大。码率过高。MediaRecorder默认码率可能很高。目前MediaRecorder构造函数对码率的控制支持有限。如果文件体积是硬性要求可能需要考虑路径二软编码使用libvpx或x264并设置目标码率CRF或VBR模式。4.2 微信平台特定问题wx.saveVideoToPhotosAlbum提示“文件不存在”确保你保存的临时文件路径是正确的并且writeFile操作是同步或已成功回调后再调用保存。微信的文件系统是沙盒化的不能直接使用blob://或http://开头的路径。保存到相册成功但在手机相册里找不到部分安卓机型如小米、OPPO由于系统定制原因保存后需要手动刷新相册或等待媒体扫描器扫描。可以在保存成功后提示用户“视频已保存可能在相册的‘其他相册’或需要稍等片刻才能看到”。内存泄漏导致小游戏闪退长时间录制或频繁开始/结束录制如果ImageBitmap、ArrayBuffer、Blob等对象没有正确释放会导致内存持续增长。务必在对象不再使用时调用.close()对于ImageBitmap或将其引用置为null。使用微信开发者工具的“内存”面板进行快照对比查找泄漏点。iOS与安卓效果不一致iOS的WebKit引擎和安卓的Chrome/WebView内核在MediaRecorder的实现、Canvas绘制性能、垃圾回收策略上都有差异。必须进行真机跨平台测试。一个常见差异是iOS上canvas.captureStream的帧率可能不稳定。4.3 进阶优化使用WASM编码器如果你对视频质量和文件大小有极致要求并且团队有足够的技术储备集成WASM编码器是终极方案。这里以libvpxVP8/VP9编码为例简述步骤获取编码器库找到libvpx的Emscripten编译版本或者自己用Emscripten工具链编译。你会得到一个.wasm文件和一个JavaScript胶水代码文件。在Unity中集成将.wasm文件作为TextAsset导入Unity打包时放入StreamingAssets。在小游戏启动时通过wx.loadWasm或fetch加载并实例化。数据传递Unity将每一帧的RGB数据可能需要从ARGB转换传递到JavaScript。JS侧将数据拷贝到WASM模块的线性内存中。编码调用WASM模块中的编码函数传入帧数据。编码器会输出压缩后的视频数据块。封装将编码出的裸流如IVF格式的VP8数据封装成WebM容器。这需要在JS侧实现一个简单的WebM复用器Muxer将视频轨、音频轨如果有和元数据打包。生成文件将封装好的数据写入ArrayBuffer生成Blob后续步骤同上。这个过程非常复杂涉及音视频封装格式、编码参数调优等专业知识但带来的好处是完全可控的编码质量、支持Alpha通道、更好的跨平台一致性。除非必要不建议中小型项目轻易尝试。5. 完整实现流程与代码结构建议最后给出一个在Unity项目中组织录制功能的模块化建议确保代码可维护、可扩展。项目结构示例Assets/ ├── Plugins/WebGL/ (存放与JS交互的特定插件) ├── Scripts/ │ ├── ScreenRecorder/ │ │ ├── ScreenRecorder.cs (主控制器管理状态、分辨率、帧率) │ │ ├── RenderTextureCapturer.cs (负责从特定Camera捕获到RenderTexture) │ │ ├── IFrameDataExporter.cs (数据导出接口) │ │ └── WebGLFrameExporter.cs (实现IFrameDataExporter调用JS桥接) │ └── ... (其他游戏逻辑) └── WebGLTemplates/WeChatMiniGame/ (微信小游戏发布模板) ├── index.html ├── unityloader.js └── screen-recorder-bridge.js (包含所有JS端录制逻辑)核心交互时序游戏启动初始化ScreenRecorder创建隐藏的录制用Camera和RenderTexture。用户点击“开始录制”按钮C#调用JS的startRecording(width, height, fps)。JS端初始化Canvas、MediaRecorder并开始一个循环使用requestVideoFrameCallback或降频的setInterval每帧调用C#的CaptureFrame()。C#端的CaptureFrame()将当前RenderTexture的数据通过桥接传到JS。JS端接收到数据绘制到CanvasMediaRecorder将其编码成视频块。用户点击“结束录制”C#调用JS的stopRecording()。JS端停止MediaRecorder收集所有数据块生成Blob调用微信API保存到临时文件。提示用户“录制完成”并提供“保存到相册”或“分享”的按钮。一个重要的细节开始和结束录制的调用必须放在用户交互事件如按钮点击的回调里。因为浏览器的MediaRecorder和canvas.captureStream()API通常要求必须在用户手势触发user gesture的短时间内调用否则会被浏览器安全策略阻止。实现微信小游戏视频录制就像在螺蛳壳里做道场空间有限但要求颇高。从方案选型到性能优化再到平台适配每一步都需要精细的权衡和扎实的测试。希望这份指南能帮你避开我当年踩过的那些坑更顺畅地将这个提升用户体验和游戏传播性的重要功能落地。记住在移动Web环境下“先跑通再优化”是永恒的真理用最小的代价验证核心流程然后根据性能分析数据有的放矢地进行优化。