1. WebRTC初探：从零认识这个实时通信的“瑞士军刀”

各位同学好，我是老张。在Android开发这行摸爬滚打了十来年，WebRTC是我近几年研究最深的技术之一。今天咱们就来聊聊，这个让浏览器和App能直接视频通话的神奇框架——WebRTC。

说实话，我第一次接触WebRTC是在2015年。当时有个项目需要在Android端实现视频通话，我第一反应是“完了，又要自己搞音视频编解码、网络穿透那一套”。后来同事说“试试WebRTC吧”，我才发现原来已经有这么成熟的解决方案了。

1.1 WebRTC到底是什么？

WebRTC，全称Web Real-Time Communication。说白了，就是让两个设备之间能直接传输音视频数据，不需要中间服务器转发。你想想看，微信视频、Zoom会议、Google Meet，底层用的都是类似的技术。

它的核心能力就三个：

• 音视频采集与播放——打开摄像头、麦克风，把画面和声音抓取出来
• 数据传输——点对点传输，延迟极低
• 网络穿透——即使你在公司内网、对方在家庭WiFi，也能建立连接

1.2 发展史：从Gmail到全球标准

WebRTC的历史，其实挺有意思的。我简单梳理一下关键节点：

时间	事件	我的评价
2010年	Google收购GIPS公司	GIPS是做音视频引擎的，Google看中了它的技术
2011年	Google开源WebRTC	当时很多人觉得Google疯了，把这么好的技术免费开放
2013年	Chrome和Firefox首次实现互通的视频通话	我记得当时在开发者大会上演示，全场鼓掌
2017年	W3C发布WebRTC 1.0候选推荐标准	终于有了官方规范，不用再猜API怎么用了
2021年	WebRTC成为W3C正式推荐标准	十年磨一剑，现在已经是实时通信的事实标准

为什么会发展这么快？我个人觉得，核心原因是“刚需”。远程办公、在线教育、社交娱乐，哪个不需要实时视频？而WebRTC恰好解决了最头疼的网络穿透和编解码问题。

1.3 核心API概览：你只需要掌握这几个

WebRTC的API其实不多，但每个都很关键。我把它分成三组：

1.3.1 媒体流相关

• MediaStream——代表一路音视频数据。比如你打开摄像头，得到的就是一个MediaStream
• MediaStreamTrack——MediaStream里的一个轨道，可以是音频轨道或视频轨道

嗯，这里要注意：一个MediaStream可以包含多个Track。比如你可以同时采集摄像头画面和屏幕共享画面，合成一个流发出去。

1.3.2 连接管理相关

• RTCPeerConnection——这是核心中的核心。它负责管理点对点连接，包括协商、传输、状态维护
• RTCSessionDescription——描述一次连接的参数，包括编解码器、IP地址、端口等
• RTCIceCandidate——网络候选地址。因为设备可能有多个网卡、多个IP，ICE协议会找出最优路径

1.3.3 数据传输相关

• RTCDataChannel——除了音视频，你还可以传任意二进制数据。比如聊天消息、文件、游戏状态

我曾经在一个项目中用DataChannel传输白板数据，延迟只有几十毫秒，体验非常好。

1.4 知识体系全景图

下面这张图，是我自己整理的WebRTC知识体系。你看一遍，心里就有谱了：

1.5 Android上的应用场景

在Android平台上，WebRTC的应用场景非常广泛。我挑几个典型的说说：

1. 视频会议App——这是最直接的应用。比如Zoom、腾讯会议的移动端，底层都用了WebRTC
2. 在线教育——一对一辅导、小班课，需要低延迟的音视频互动
3. 远程医疗——医生和患者视频问诊，对画质和稳定性要求很高
4. 社交娱乐——直播连麦、语音聊天室
5. IoT设备——比如智能门铃、摄像头，通过WebRTC把画面推送到手机

1.6 为什么选择WebRTC？

你可能会问：市面上那么多实时通信方案，为什么偏偏选WebRTC？

我的理由有三点：

• 免费且开源——没有授权费，代码随便改
• 跨平台——Android、iOS、Web、桌面端，一套API搞定
• 生态成熟——Google持续维护，社区活跃，遇到问题基本都能搜到答案

当然，它也不是完美的。比如信令部分需要自己实现，网络穿透在某些极端网络环境下还是会失败。但总体来说，WebRTC是目前最靠谱的实时通信方案，没有之一。

---

好了，第一章就到这里。WebRTC的世界很大，咱们慢慢探索。记住：技术是死的，思路是活的。多动手、多踩坑，才能真正掌握它。