Unity WebRTC跨平台实时视频传输：从PC到Android的实战指南

1. 项目概述与核心价值

最近在做一个需要跨平台实时视频传输的项目，核心需求是在PC端（作为发送端）采集视频流，然后实时、低延迟地传输到Android移动设备（作为接收端）上进行渲染显示。这个场景在远程桌面、云游戏、AR/VR协同、工业远程操控等领域非常常见。经过一番技术选型，最终决定采用Unity引擎结合WebRTC开源库的方案来实现。为什么是它？因为WebRTC本身就是为实时音视频通信而生的标准，其P2P直连、低延迟、抗弱网的特性完美契合我们的需求，而Unity则提供了强大的跨平台渲染能力和便捷的交互开发环境，两者结合能让我们用一套代码逻辑覆盖PC和Android两端，极大地提升了开发效率。

这个“Unity WebRTC开源库实战”项目，就是要解决从零开始，将一个完整的视频流从PC端推送到Android端并流畅渲染出来的全过程。它不仅仅是调用几个API那么简单，涉及到Unity与原生WebRTC库的桥接、信令服务器的搭建、双端的网络协商、视频编解码器的选择与配置，以及在Android平台上特有的性能优化与兼容性处理。如果你正在寻找一个能跑通的、可落地的跨平台实时视频传输方案，并且对Unity和Android开发有一定基础，那么这篇指南将为你提供一条清晰的路径，避开我踩过的那些坑。

2. 技术选型与环境准备

2.1 为什么选择Unity + WebRTC开源库？

在决定技术栈时，我们对比了几种主流方案。首先是原生Android开发集成WebRTC SDK，虽然控制力最强，但需要分别维护PC（可能是C++/Qt等）和Android两套代码，开发成本高。其次是使用一些商业的实时通信云服务SDK，它们封装得很好，但往往定制性受限，且可能产生持续费用。Unity + WebRTC开源库的方案则找到了一个平衡点：Unity负责跨平台的UI渲染和业务逻辑，WebRTC负责底层的网络传输。Unity官方提供了 Unity Render Streaming 包，但它更偏向于云端渲染流式传输到网页端，对于我们需要在Android原生应用内渲染的场景，灵活度不够。因此，我们选择了社区维护的 Unity WebRTC 开源库（例如基于Google官方WebRTC库封装的版本），它允许我们更直接地控制WebRTC的会话建立和媒体流处理。

这里需要明确一点，我们使用的“Unity WebRTC开源库”通常指一个C#包装层，它通过P/Invoke调用底层用C++编写的WebRTC原生库（如libwebrtc）。这意味着你的项目环境中必须包含对应平台的WebRTC原生库。对于Windows PC（发送端）和Android（接收端），我们需要分别准备对应的原生库文件（.dll或.so）。

2.2 核心组件与工具清单

在开始动手之前，请确保你的开发环境包含以下组件：

1. Unity Hub & Unity Editor ：建议使用2021.3 LTS或2022.3 LTS版本，长期支持版更稳定。我们需要安装 Android Build Support 模块。
2. Unity WebRTC 开源库 ：可以从GitHub仓库（如 Unity-Technologies/com.unity.webrtc ）通过Unity Package Manager的Git URL方式添加，或者下载其Release包手动导入。 注意版本兼容性 ，库版本需要与你的Unity编辑器版本以及你计划使用的WebRTC原生库版本匹配。
3. WebRTC原生库 ：这是最关键的依赖。对于Windows平台，你需要预编译好的 webrtc.dll 和 webrtc.lib （或对应的CMake工程自行编译）。对于Android平台，你需要针对ARMv7、ARM64等架构编译好的 libwebrtc.so 动态库。通常开源库的Release页面会提供，或者有详细的编译指南。 一个巨大的坑 ：PC端和Android端的WebRTC库版本 必须严格一致 ，否则在交换SDP（会话描述协议）时很可能因为支持的编解码器或参数不匹配而失败。
4. 信令服务器 ：WebRTC建立P2P连接需要交换网络信息（SDP和ICE候选），这个过程需要信令服务器。我们可以用一个非常简单的Node.js + WebSocket服务器来实现，代码不超过100行。它的作用仅仅是“传话”，不处理音视频数据。
5. Android开发环境 ：确保JDK、Android SDK & NDK已正确安装，并在Unity的 Edit -> Preferences -> External Tools 中配置好路径。NDK版本也需要与WebRTC库的编译环境兼容。
6. 测试设备 ：一台Windows PC作为发送端，一部Android手机作为接收端。 强烈建议 使用有线网络连接PC，并将PC和手机连接到同一个局域网（Wi-Fi）下，这样可以排除复杂的NAT穿透问题，让初期调试更顺利。

注意 ：编译WebRTC原生库是一个耗时且容易出错的过程，对于初学者，强烈建议优先寻找社区提供的、与你选择的Unity WebRTC库版本匹配的预编译库，先让整个流程跑通，再考虑深度定制。

3. 项目架构与核心流程拆解

3.1 整体通信架构图

我们的系统是一个典型的WebRTC一对一通信模型，但角色是固定的：PC端是“Offer端”（发起方），Android端是“Answer端”（应答方）。数据流是单向的，从PC到Android。

[PC Unity应用] <---(信令: WS)---> [信令服务器] <---(信令: WS)---> [Android Unity应用]
       |                                                                       |
       |---(捕获本地视频)--> [VideoTrack] --(编码)--> [PeerConnection]          |
       |                                                                       |
       |<----------------------(P2P RTP媒体流)------------------------------>|
       |                                                                       |
       |                                                             [PeerConnection] --(解码)--> [VideoTrack] --(渲染)--> [Unity RawImage]

1. 信令通道建立 ：PC端和Android端分别通过WebSocket连接到同一个信令服务器。
2. 媒体捕获与编码（PC端） ：PC端使用Unity WebRTC库提供的 CameraCapture 或 ScreenCapture 组件，捕获摄像头或屏幕画面，生成视频帧，并创建 VideoStreamTrack 。
3. 创建PeerConnection（两端） ：两端分别创建 RTCPeerConnection 对象，这是WebRTC的核心，负责管理连接、编解码、网络传输。
4. 交换SDP与ICE（信令） ：
   • PC端创建 Offer （包含本地媒体信息和编解码器支持），通过信令服务器发送给Android端。
   • Android端收到 Offer 后，创建 Answer ，并通过信令服务器回传给PC端。
   • 同时，两端在发现本地和公网IP端口（ICE候选）后，也通过信令服务器交换这些信息。
5. 建立P2P连接 ：通过交换的SDP和ICE信息，两端尝试建立直接的UDP连接（在同一个局域网内很容易成功）。如果直连失败，会尝试通过STUN服务器获取公网地址，或通过TURN服务器中转。
6. 媒体流传输与渲染（Android端） ：P2P连接建立后，编码后的视频数据包通过RTP协议从PC端发送到Android端。Android端的 PeerConnection 收到数据后解码，将视频帧传递给关联的 VideoStreamTrack ，最终渲染到Unity的 RawImage 或 RenderTexture 上。

3.2 关键对象与生命周期管理

在Unity C#脚本中，我们需要重点管理以下几个核心对象：

• RTCPeerConnection ： 连接的生命周期管理器。创建时需要传入一个 RTCConfiguration 对象，用于配置ICE服务器（STUN/TURN）。务必在 OnDestroy 或应用退出时调用其 Close() 方法，释放资源。
• MediaStream / VideoStreamTrack ： 媒体流的容器和轨道。PC端将捕获的视频轨道添加到 PeerConnection 中；Android端从 PeerConnection 的 OnTrack 事件中获取远端传来的视频轨道。
• RTCDataChannel ： 虽然本项目主要传输视频，但 DataChannel 可以用于传输控制指令（如触摸事件、键盘输入），实现双向交互。它的创建和消息收发也是重要部分。

这些对象的创建、配置、事件订阅（如 OnIceCandidate ， OnTrack ）和销毁，必须放在Unity的主线程中执行，因为很多底层回调可能来自原生线程，需要通过 UnitySynchronizationContext 来调度回主线程，否则会导致Unity崩溃。这是Unity集成原生库时的一个经典陷阱。

4. PC端（发送端）实现详解

4.1 视频捕获与轨道创建

在PC端的Unity场景中，我们通常有两种视频源选择：摄像头或屏幕。Unity WebRTC库提供了对应的封装。

// 示例：捕获主摄像头
private VideoStreamTrack CreateCameraTrack()
{
    // 1. 获取Unity的Camera组件
    Camera cam = Camera.main; // 或指定的摄像机
    // 2. 创建视频捕获器
    var capture = cam.CaptureStreamTrack(1280, 720, 30); // 宽，高，帧率
    // 3. 返回VideoStreamTrack
    return capture;
}

// 示例：捕获整个屏幕（适用于远程桌面）
private VideoStreamTrack CreateScreenTrack()
{
    // 注意：可能需要处理多显示器的情况
    var tracks = ScreenCapture.CaptureStreamTrack();
    // 通常返回一个Track列表，这里取第一个
    return tracks.Length > 0 ? tracks[0] : null;
}

关键参数解析 ：

• 分辨率（1280x720） ： 这是编码前的原始分辨率。更高的分辨率意味着更清晰的画面，但也会显著增加编码计算量和网络带宽消耗。需要根据实际网络带宽和Android端的解码能力权衡。从720p开始是个不错的选择。
• 帧率（30 fps） ： 实时视频通常需要至少15fps才能流畅，30fps是平衡流畅度和性能的常用值。游戏场景可能需要60fps。
• 编码器选择 ： 在创建 PeerConnection 时，可以通过SDP的编解码器优先级来指定。对于跨平台， H.264 是兼容性最广的选择，几乎所有Android设备都支持硬件解码。VP8/VP9虽然免专利费，但在一些旧款或低端Android设备上可能没有硬件解码支持，会加重CPU负担。

4.2 配置与创建PeerConnection

创建 RTCPeerConnection 是整个流程的核心。

private RTCPeerConnection CreatePeerConnection()
{
    RTCConfiguration config = new RTCConfiguration
    {
        // ICE服务器配置，用于NAT穿透
        iceServers = new[]
        {
            new RTCIceServer { urls = new[] { "stun:stun.l.google.com:19302" } }
            // 如果需要TURN服务器，在这里添加
            // new RTCIceServer { urls = new[] { "turn:your-turn-server.com:3478" }, username="user", credential="pass"}
        }
    };

    RTCPeerConnection pc = new RTCPeerConnection(ref config);

    // 订阅关键事件
    pc.OnIceCandidate = candidate =>
    {
        // 当发现一个ICE候选（本地/公网IP端口）时，通过信令服务器发送给对方
        signalingClient.SendCandidate(candidate);
    };
    pc.OnIceConnectionChange = state =>
    {
        Debug.Log($"ICE连接状态: {state}");
        // 状态包括：New, Checking, Connected, Completed, Failed, Disconnected, Closed
    };
    pc.OnNegotiationNeeded = () =>
    {
        // 当需要重新协商时（例如添加/移除轨道），触发创建Offer
        StartCoroutine(CreateOffer());
    };

    // 将本地视频轨道添加到PeerConnection
    VideoStreamTrack videoTrack = CreateCameraTrack();
    pc.AddTrack(videoTrack);

    return pc;
}

注意事项 ：

• STUN服务器 ： 免费的公共STUN服务器（如Google的）对于获取公网IP地址很有帮助，但在对称型NAT后或防火墙严格时可能失效。
• TURN服务器 ： 当P2P直连失败时，TURN服务器作为中继是最后的保障。 TURN流量会产生服务器带宽费用 ，且是系统延迟的主要来源。在开发测试阶段，确保两端在同一局域网下，可以暂时不配置TURN。
• OnNegotiationNeeded ： 这个事件很重要。我们在一开始添加视频轨道后，它会自动触发。我们需要在这个事件的回调里启动创建Offer的协程。

4.3 发起Offer与信令交换

当 OnNegotiationNeeded 触发后，PC端需要创建Offer并设置本地描述，然后将Offer通过信令发送给Android端。

private IEnumerator CreateOffer()
{
    var op = pc.CreateOffer();
    yield return op;

    if (!op.IsError)
    {
        var offerDesc = op.Desc;
        yield return StartCoroutine(SetLocalDescription(offerDesc));
        // 将offerDesc序列化（如转为JSON）后，通过信令服务器发送
        signalingClient.SendOffer(offerDesc);
    }
    else
    {
        Debug.LogError($"创建Offer失败: {op.Error.message}");
    }
}

private IEnumerator SetLocalDescription(RTCSessionDescription desc)
{
    var op = pc.SetLocalDescription(ref desc);
    yield return op;
    if (op.IsError)
    {
        Debug.LogError($"设置本地描述失败: {op.Error.message}");
    }
}

信令客户端（ signalingClient ）的实现就是一个简单的WebSocket客户端，负责与Node.js信令服务器通信，发送 offer 、 answer 、 candidate ，并接收对方发来的对应消息。收到Android端的 answer 后，PC端需要调用 SetRemoteDescription 。

5. Android端（接收端）实现详解

5.1 接收Offer并创建Answer

Android端的Unity应用启动后，同样先创建 RTCPeerConnection （配置与PC端类似，但通常只接收轨道，不添加本地轨道），并连接信令服务器。当收到PC端发来的Offer时：

// 在信令消息处理中
if (message.type == "offer")
{
    StartCoroutine(HandleOffer(message.sdp));
}

private IEnumerator HandleOffer(string offerSdp)
{
    RTCSessionDescription offer = new RTCSessionDescription
    {
        type = RTCSdpType.Offer,
        sdp = offerSdp
    };

    // 1. 设置远端描述（PC端的Offer）
    var opSetRemote = pc.SetRemoteDescription(ref offer);
    yield return opSetRemote;
    if (opSetRemote.IsError) { /* 处理错误 */ }

    // 2. 创建Answer
    var opCreateAnswer = pc.CreateAnswer();
    yield return opCreateAnswer;
    if (!opCreateAnswer.IsError)
    {
        var answerDesc = opCreateAnswer.Desc;
        // 3. 设置本地描述（自己的Answer）
        yield return StartCoroutine(SetLocalDescription(answerDesc));
        // 4. 将Answer发送回PC端
        signalingClient.SendAnswer(answerDesc);
    }
}

5.2 接收视频轨道与渲染

这是Android端最核心的部分。视频轨道通过 OnTrack 事件传递过来。

// 在创建PeerConnection时订阅OnTrack事件
pc.OnTrack = (RTCRtpTransceiver transceiver) =>
{
    // 这个回调可能在非主线程触发
    UnityMainThreadDispatcher.Instance().Enqueue(() =>
    {
        if (transceiver.Receiver.Track is VideoStreamTrack videoTrack)
        {
            // 获取到了远端的视频轨道！
            SetupRemoteVideo(videoTrack);
        }
    });
};

private void SetupRemoteVideo(VideoStreamTrack videoTrack)
{
    // 1. 创建一个Unity的RawImage用于显示
    // 假设在场景中已经有一个RawImage组件，赋值给remoteScreenRawImage
    if (remoteScreenRawImage == null)
    {
        GameObject go = new GameObject("RemoteVideo");
        remoteScreenRawImage = go.AddComponent<RawImage>();
        // ... 设置RectTransform等
    }

    // 2. 将VideoStreamTrack渲染到RawImage的Texture上
    // 关键步骤：VideoStreamTrack需要初始化一个渲染目标
    videoTrack.InitializeReceiver(remoteScreenRawImage.texture.width, remoteScreenRawImage.texture.height);
    // 或者，更常见的做法是，VideoStreamTrack会提供一个Texture，我们将其赋值给RawImage
    StartCoroutine(UpdateVideoTexture(videoTrack));
}

private IEnumerator UpdateVideoTexture(VideoStreamTrack videoTrack)
{
    while (videoTrack.IsAlive)
    {
        // 等待新的一帧
        yield return new WaitForEndOfFrame(); // 或者使用videoTrack的更新事件
        // 获取当前视频帧对应的Texture
        Texture tex = videoTrack.Texture;
        if (tex != null)
        {
            remoteScreenRawImage.texture = tex;
        }
    }
}

关键点与坑 ：

• 线程安全 ： OnTrack 回调很可能不在Unity主线程。直接在其中操作Unity对象（如 RawImage ）会导致崩溃。 必须 使用一种机制将操作派发回主线程，例如使用一个简单的 UnityMainThreadDispatcher 单例，它内部维护一个主线程的 Action 队列。
• Texture初始化 ： 不同的Unity WebRTC库版本， VideoStreamTrack 渲染到Texture的方式可能有差异。有些需要你提前创建一个 RenderTexture 并传入，有些则会在内部创建并提供一个 Texture 属性。务必查阅你所使用库的文档和示例。
• 解码器兼容性 ： 确保Android端的 PeerConnection 能够解码PC端发送的编码格式。在SDP交换阶段，双方会协商出一个共同的编解码器。如果Android端没有对应的硬件解码器，会 fallback 到软件解码，可能导致CPU占用过高、发热和卡顿。

6. 信令服务器的简易实现

信令服务器的作用是让两个互不知情的客户端交换连接信息。我们用Node.js和 ws 库快速实现一个。

// signaling-server.js
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

let clients = [];

wss.on('connection', (ws) => {
    console.log('新的客户端连接');
    clients.push(ws);

    ws.on('message', (message) => {
        const data = JSON.parse(message);
        // 广播消息给所有其他客户端（简单的一对一模型，实际需根据房间号配对）
        clients.forEach(client => {
            if (client !== ws && client.readyState === WebSocket.OPEN) {
                client.send(JSON.stringify(data));
            }
        });
    });

    ws.on('close', () => {
        console.log('客户端断开连接');
        clients = clients.filter(client => client !== ws);
    });
});

console.log('信令服务器运行在 ws://localhost:8080');

这个服务器极其简单，只是把任何客户端发来的消息原样转发给其他所有客户端。在实际项目中，你需要引入“房间”的概念，让两个想要连接的客户端加入同一个房间，只进行房间内的消息转发。PC端和Android端在启动时，需要连接到这个服务器的地址（例如 ws://你的PC内网IP:8080 ）。

7. Android平台专项优化与打包部署

7.1 性能优化要点

在Android设备上运行实时视频解码渲染，性能是首要挑战。

1. 使用硬件解码器 ： 确保SDP协商结果使用的是 H.264 编解码器，并且Android端的 PeerConnection 配置允许硬件解码。这通常在WebRTC原生库编译时就已经决定。你可以通过Android的 MediaCodec API来验证是否启用了硬件解码。
2. 控制分辨率与帧率 ： 在Android端，可以根据设备性能（通过 SystemInfo 判断）动态请求PC端发送不同质量的视频流。这可以通过 RTCRtpSender 的 SetParameters 方法，或是在重新协商Offer/Answer时实现。
3. 渲染优化 ：
   • 使用 RawImage 而非 RenderTexture 到 Material 的方式，通常更高效。
   • 确保视频渲染的GameObject层级尽可能简单，避免不必要的UI元素叠加和重绘。
   • 在 Update 中频繁获取和设置Texture是昂贵的，最好使用 VideoStreamTrack 提供的回调或事件来驱动纹理更新。
4. 功耗与发热 ： 长时间运行视频解码非常耗电。除了使用硬件解码，还可以在应用失去焦点（ OnApplicationPause ）时暂停视频流接收或降低帧率，在恢复时再恢复。

7.2 打包配置与权限

在Unity中打包Android APK前，需要进行关键配置：

1. Player Settings :
   • Other Settings :
     • Scripting Backend : 如果WebRTC原生库是 il2cpp 编译的，则必须选择 IL2CPP 。
     • Target Architectures : 勾选 ARMv7 和 ARM64 。确保你导入的 libwebrtc.so 库文件包含了对应的架构。
   • Configuration :
     • Internet Access : 设置为 Require 。
2. 导入原生库 ： 将编译好的 libwebrtc.so 文件（可能还有其它依赖的.so文件）放入项目的 Assets/Plugins/Android/libs/[architecture]/ 目录下。例如， Assets/Plugins/Android/libs/arm64-v8a/libwebrtc.so 。
3. AndroidManifest.xml ： 确保包含了必要的权限。你可以通过Unity创建一个自定义的AndroidManifest模板。

   <!-- Assets/Plugins/Android/AndroidManifest.xml -->
   <manifest ...>
       <uses-permission android:name="android.permission.INTERNET" />
       <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
       <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
       <!-- 如果使用摄像头，则需要摄像头权限 -->
       <!-- <uses-permission android:name="android.permission.CAMERA" /> -->
       <application ...>
           ...
       </application>
   </manifest>
   

4. Proguard混淆 ： 如果启用了Proguard（Minify），需要在 proguard-user.txt 中添加规则，防止WebRTC相关的C#和Java类被混淆或优化掉，否则可能导致运行时找不到方法而崩溃。

7.3 真机调试与日志查看

在Android真机上调试WebRTC问题，查看日志至关重要。

1. Unity日志 ： 使用 adb logcat -s Unity 命令过滤Unity产生的日志。
2. WebRTC原生日志 ： WebRTC库本身会输出大量调试信息。你需要在初始化 PeerConnection 时，通过设置 RTCConfiguration 中的 enableLogging 为 true ，并指定日志级别。更底层的日志可能需要修改WebRTC原生库的编译参数，使其输出到 logcat 。一个常见的方法是，在Android端的C#代码中，通过 [DllImport("libwebrtc")] 调用一个设置日志回调的函数，将日志重定向到Unity的 Debug.Log 。
3. 网络检查 ： 使用 adb shell netstat 或 adb shell ifconfig 检查设备的网络状态。确保手机和PC在同一个网段，防火墙没有阻止UDP端口（通常范围是50000-65535）。

8. 常见问题排查与实战心得

8.1 连接建立失败问题排查表

8.2 实战心得与技巧

1. 版本锁定是生命线 ： Unity版本、Unity WebRTC包版本、WebRTC原生库版本，这三者的组合必须经过测试验证。记录下能稳定工作的版本号，不要轻易升级。升级任何一部分，都可能需要重新编译或适配其他部分。
2. 从最简单开始 ： 最初不要追求高分辨率和高帧率。先用最低配置（如320x240@15fps）让整个流程（信令->连接->显示）先跑通。然后再逐步提高参数，观察性能和稳定性变化。
3. 善用日志和工具 ：
   • 在PC端，可以使用 chrome://webrtc-internals （如果是在基于Chromium的浏览器中测试类似逻辑）来查看详细的WebRTC统计信息，这是一个非常好的学习工具。
   • 在Unity中，将关键步骤（如 OnIceCandidate 、 OnTrack ）和SDP字符串都打印出来，便于分析。
4. 模拟网络环境测试 ： 使用网络模拟工具（如Clumsy on Windows）在PC端制造丢包、延迟和抖动，测试Android端视频的鲁棒性。WebRTC的抗弱网能力很强，但你需要知道它的表现边界。
5. 关于TURN服务器 ： 对于最终要部署在公网的应用，TURN服务器是必须的。你可以使用开源的 coturn 项目自建，也可以使用云服务商提供的TURN服务。自建时需要注意UDP和TCP（如果需要）端口的放行。
6. 内存管理 ： Unity WebRTC的C#包装对象和底层C++对象之间存在引用。即使C#对象被GC回收，底层对象可能还在。务必在 MonoBehaviour 的 OnDestroy 方法中，手动调用 PeerConnection 的 Close() 方法和 Track 的 Dispose() 方法，防止内存泄漏和原生崩溃。

这个从PC到Android的Unity WebRTC视频传输方案，打通了之后就是一个强大的基础框架。在此基础上，你可以扩展音频传输、数据通道传输控制指令、实现一对多广播、加入房间管理、增加UI控制界面（如切换分辨率、暂停流）等功能。每一步的深入，都可能遇到新的挑战，但解决问题的过程，正是从“能用”到“好用”的必经之路。