基本原理 ：WEBGRTC +PC 一致：可参考：
https://blog.csdn.net/H913402408/article/details/159466164?spm=1001.2014.3001.5501https://blog.csdn.net/H913402408/article/details/159466164?spm=1001.2014.3001.5501
在开发 Unity WebGL 项目时，如果你曾尝试通过 `unityInstance.SendMessage` 来处理高频的视频流数据，想必一定被那种“掉帧”和“卡顿”折磨过：数据拷贝开销大：每传递一帧视频数据（通常是 byte 数组或 Base64 字符串）；频繁的字符串或数组转换会瞬间产生大量垃圾回收（GC）压力；效率低。
传统的通信方式在面对海量数据时显得力不从心，而最近探索出的“共享显存”方案，则彻底打开了新世界的大门。只能说 ：嗯~~， 很香。
通信原理：
Unity WebGL 底层基于 Emscripten，它与浏览器的 JS 共享同一块内存堆。简单来说，我们不需要把像素数据传给 JS，而是把 Unity 中 Texture 的显存地址（ID）传给 JS。JS 拿到这个 ID 后，可以直接将其绑定到 WebRTC 的 VideoTrack 上。
获取纹理 ID：
RenderTexture rt = new RenderTexture(1280, 720, 0, RenderTextureFormat.ARGB32); rt.Create(); System.IntPtr texturePtr = rt.GetNativeTexturePtr(); // 将 ptr 转换为 int 传给 JS (视平台架构而定，通常是 32位或64位) int textureId = texturePtr.ToInt32();优势总结：
-零拷贝：数据始终在 GPU 显存中，JS 只是充当了“接线员”。
-高性能：即使是 4K 视频流，也能保持极高的帧率。
-低延迟：省去了中间环节，端到端延迟显著降低。
最后：
这种“显存共享”的思路，不仅适用于 WebRTC，对于任何需要在 Unity 和 DOM 之间高频交换图像数据的场景（如 OpenCV 图像处理、外部摄像头接入），都是极佳的解决方案。
注：外部摄像头，Unity内部相机流双视频流轨道，均已测试实现，完全可行。
