最近把一篇旧的 Android WebRTC + Go gRPC 对接记录重新整理成了脱敏后的工程复盘。
文章地址:
https://www.lodan.me/zh-cn/posts/golang-grpc-webrtc-android/
这次重点不是讲某个 API 怎么调,而是把边界拆清楚:
- Go/gRPC 信令层负责设备注册、会话控制、回调事件和 SDP/ICE 转发。
- Android 客户端负责权限、页面生命周期、本地音视频资源和 UI 状态同步。
- WebRTC PeerConnection 负责 offer/answer 、ICE candidate 、track add/remove 和连接状态。
- 排查问题时,日志至少要能串起 call id 、peer id 、signaling state 、ICE state 和 selected candidate pair 。
我现在的判断是:如果这些边界混在一起,线上问题很容易变成“看起来像网络问题”“看起来像设备问题”“看起来像 SDK 问题”。边界清楚以后,排查路径会直接很多。
想讨论一下:大家做 Android WebRTC 或 RTC Gateway 时,通常会把多少信令/状态逻辑放在客户端,多少放在本地网关或服务端?
文章地址:
https://www.lodan.me/zh-cn/posts/golang-grpc-webrtc-android/
这次重点不是讲某个 API 怎么调,而是把边界拆清楚:
- Go/gRPC 信令层负责设备注册、会话控制、回调事件和 SDP/ICE 转发。
- Android 客户端负责权限、页面生命周期、本地音视频资源和 UI 状态同步。
- WebRTC PeerConnection 负责 offer/answer 、ICE candidate 、track add/remove 和连接状态。
- 排查问题时,日志至少要能串起 call id 、peer id 、signaling state 、ICE state 和 selected candidate pair 。
我现在的判断是:如果这些边界混在一起,线上问题很容易变成“看起来像网络问题”“看起来像设备问题”“看起来像 SDK 问题”。边界清楚以后,排查路径会直接很多。
想讨论一下:大家做 Android WebRTC 或 RTC Gateway 时,通常会把多少信令/状态逻辑放在客户端,多少放在本地网关或服务端?