开发安卓App实时同步玩家绘图操作功能的实现方案咨询

技术选型建议 #

4人对局的并发量极低，无需选用过重的实时通信架构，两个落地性极强的方案可选：

• 基于现有后端扩展WebSocket能力：安卓端直接用OkHttp内置的WebSocket封装即可快速接入，所有消息走后端转发，开发成本最低，适合公网对局场景
• 基于UDP实现：如果做的是局域网对局，优先选UDP，甚至可以实现P2P直传，延迟比WebSocket低30%以上，适合对实时性要求高的场景

核心同步逻辑设计 #

禁止直接同步整张画布Bitmap，带宽占用极高、延迟大，完全不符合轻量同步的需求

• 先把所有绘图操作拆成最小可序列化单元，单个操作的字段如下：
  操作类型(落笔/移笔/抬笔/清空/选色/调笔触)、坐标(x,y)、色值、笔触宽度、时间戳、对局ID、操作者ID
• 绘图玩家每次触发触摸采样时，将对应操作序列化后（优先用Protobuf，体积比JSON小40%以上，序列化速度更快）发送到转发层
• 转发层（后端或P2P的中转逻辑）无需额外处理，直接把操作包转发给同局的其余3个玩家即可
• 其余玩家收到操作包后，按时间戳排序后直接调用本地绘图渲染逻辑执行即可，完全可以复用你现有本地绘图的代码，无需额外开发渲染逻辑

可落地的优化方案 #

• 做操作帧合并：每攒3~5个连续的移笔操作再打包发送，能大幅降低通信频次，不会影响同步流畅度，人手指触摸的采样率很高，无需每个坐标点都单独发包
• 弱网补偿：如果超过2s没收到当前绘图玩家的操作包，主动向对方请求最近100条未同步的操作增量，不要全量拉取画布，降低带宽消耗
• 时间戳校验：本地执行远端操作时如果遇到时间戳早于当前已渲染操作的旧包，直接丢弃即可，避免画布渲染错乱

安卓端适配注意事项 #

• 不要在onTouchEvent的UI线程直接执行发包逻辑，把操作扔到子线程消息队列处理，避免阻塞UI导致本地绘图卡顿
• 本地绘图、远端同步绘图的渲染逻辑抽成统一公共方法，保证两边渲染效果完全一致，避免出现同个操作两端画出来不一样的问题

内容的提问来源于stack exchange，提问作者Jose Carlos Garcia