我构建了一个使用 WebRTC 和 React Native 的实时视频通话应用，但比我预期的更难

抱歉，我需要您提供要翻译的具体文本内容（除保留的来源链接外）。请粘贴文章的正文，我会按照要求将其翻译成简体中文并保留原有的格式。

介绍

大多数开发者都使用过 Zoom、Google Meet 或 WhatsApp 通话等应用。
但自己构建一个？那是完全不同的故事。

当我开始着手我的 React Native WebRTC 应用时，我想：“这只是视频流，对吧？”我大错特错。

当我意识到这不仅仅是另一个应用时

In a normal app:

You send a request → server responds

In WebRTC:

Two devices talk directly
No middleman.

Just two peers trying to:

• Discover each other
• Negotiate connection
• Exchange network details
• Stream audio/video in real-time

That’s when it hit me: this isn’t purely a frontend or backend problem.

WebRTC 实际做了什么

WebRTC（Web 实时通信）允许设备之间进行点对点的超低延迟通信。

• 你的手机可以直接将视频流传输到另一台设备，而无需通过服务器路由媒体。
• 内置加密确保通信安全。

强大，但也复杂。

我的 WebRTC 应用背后的架构

1. 客户端层（React Native）

• 捕获摄像头和麦克风
• 显示本地和远程视频
• 处理通话 UI

React Native 让在 iOS 和 Android 上构建跨平台应用更容易，同时仍然使用原生 WebRTC 性能。UI 是比较简单的部分。

2. 信令服务器（无名英雄）

“WebRTC 是点对点的，所以不需要服务器。” – 错误。

需要信令服务器来：

• 帮助用户相互发现
• 交换连接数据（SDP）
• 共享 ICE 候选

WebRTC 并未定义信令的工作方式，因此必须自行实现。在我的项目中，这成为了协调层。

3. 对等连接（核心引擎）

信令完成后：

• 创建对等连接
• 设备交换 Offer、Answer 和 ICE 候选

连接从服务器中转转变为直接的设备对设备通信。

4. NAT 穿透（隐藏的复杂性）

真实网络环境非常复杂。设备往往位于路由器、防火墙和 NAT 后面。WebRTC 使用：

• STUN 服务器 → 查找你的公网 IP
• TURN 服务器 → 当直接连接失败时中继数据

没有这些，很多连接根本无法工作。

5. 实时媒体流

一旦对等连接建立：

• 音视频流直接在对等方之间传输
• 媒体传输不涉及后端
• 延迟保持极低

这就是 WebRTC 被用于视频通话、实时协作和远程医疗应用的原因。

完整通话流程

1. 用户 A 发起通话。
2. 信令服务器向用户 B 发送 offer。
3. 用户 B 回应 answer。
4. 双方交换 ICE 候选。
5. 对等连接建立。
6. 媒体流直接在设备之间传输。

并不简单，但很美。

让这个项目具有挑战性的因素

1. 调试很痛苦

你不仅在调试函数，还在调试：

• 网络状态
• ICE 失败
• 连接协商

2. 异步混乱

所有事情都在事件中发生（offer、answer、candidate、stream）。错过一步 → 连接会悄然失败。

3. 文档分散

WebRTC 对初学者并不友好。你不可能“一次学会”；只能在使用中逐步体会。

这个项目教会我的事

在这个项目之前，我认为：“应用程序只关乎 API 和 UI。”
现在我知道还有一些系统存在于那一层之下。

关键要点

• 实时系统本质上与众不同。
• 架构比代码更重要。
• 网络知识被低估了。
• 点对点（P2P）强大但复杂。

从应用开发者到系统思考者

我不再问：“我该如何构建这个功能？”而是开始问：“沟通实际上是如何发生的？”

这种转变将开发者与工程师区分开来。

最终思考

构建 WebRTC 应用不仅仅是视频通话；更在于理解：

• 通信协议
• 网络行为
• 实时系统

一旦掌握这些，你就不再把应用视作屏幕，而是把它们视作系统。

链接

• GitHub:
• 作品集: