实时白板与协作：Canvas同步、AI手写识别、智能图形识别、WebRTC数据通道同步状态

大家好，我是你们的老朋友。今天我们来聊一个非常有意思的话题——实时白板协作。

说实话，我在做音视频之前，一直觉得白板就是个画图工具。直到有一次，我给一个远程教育平台做方案，客户说：“你们能不能让老师和学生在白板上同时写字，而且延迟要低到感觉不到？” 我这才意识到，实时白板远不止是“画几笔”那么简单。

它背后涉及的技术栈，其实相当硬核：Canvas渲染、WebRTC数据通道、状态同步、AI识别……嗯，今天我们就一个一个拆开来看。

1. Canvas同步：不只是画线那么简单

先说说最基础的部分——Canvas同步。

你想想看，两个人在不同地点，同时在一块白板上画图。A画了一条线，B要立刻看到。这听起来简单，但实现起来坑不少。

我个人的习惯是，把每一次绘图操作抽象成一个“指令”。比如：

{
  type: 'draw',
  tool: 'pen',
  points: [{x: 100, y: 200}, {x: 105, y: 205}, ...],
  color: '#ff0000',
  width: 3,
  timestamp: 1690000000000
}

为什么这么做？因为直接同步Canvas的像素数据，带宽根本扛不住。你想想看，一个1920x1080的画布，每秒30帧，那数据量比视频还大。所以，我们只同步“操作指令”，每个客户端自己执行渲染。

这里有个坑，我曾经踩过——浮点数精度。不同浏览器对Canvas坐标的浮点数处理有细微差异，导致A画的线在B那边看起来“歪了一点点”。解决方案是：发送前对坐标做四舍五入，保留小数点后两位。

2. WebRTC数据通道：白板的“高速公路”

数据同步走什么通道？当然是WebRTC的数据通道（DataChannel）。

为什么不用WebSocket？因为WebRTC的数据通道是P2P的，延迟更低，而且不经过服务器中转。对于白板这种高频、小数据量的场景，再合适不过了。

我建议你使用有序、可靠模式。白板操作必须保证顺序，不然A先画了一条线，B后画了一个圆，结果B的圆先到了，A的线后到了，画面就乱了。

const dataChannel = peerConnection.createDataChannel('whiteboard', {
  ordered: true,    // 保证顺序
  reliable: true    // 保证可靠
});

但注意，可靠模式在弱网下会有重传，导致延迟增加。所以，对于高频的“笔迹点”，我建议做批量发送。比如每50ms收集一次点，打包发送。这样既减少了消息数量，又降低了重传概率。

3. 状态同步：谁才是“主人”？

多人协作时，最头疼的问题就是状态冲突。比如A和B同时画了一个圆，然后A又删除了它，但B没收到删除指令……嗯，画面就乱了。

我常用的方案是CRDT（无冲突复制数据类型）。简单说，就是每个操作都有一个唯一的ID，并且操作之间可以合并，不会产生冲突。

举个例子：

// 每个操作都有一个全局唯一的ID
{
  id: 'userA-1690000000000-001',
  type: 'draw',
  ...
}

当两个操作同时发生时，我们根据ID的大小决定谁先谁后。这样，即使网络延迟，最终所有客户端的状态也是一致的。

不过，CRDT实现起来比较复杂。如果你不想自己造轮子，可以使用Yjs或Automerge这类库。我在项目中用过Yjs，配合WebRTC数据通道，效果还不错。

4. AI手写识别：把“鬼画符”变成文字

白板上写写画画，如果能自动识别成文字，那体验就上了一个台阶。

AI手写识别，说白了就是时序数据分类。你把笔迹的点序列（x, y, time）输入给模型，模型输出对应的文字。

我推荐使用TensorFlow.js加载预训练模型，直接在浏览器端运行。这样不需要把笔迹上传到服务器，延迟低，还保护隐私。

// 加载手写识别模型
const model = await tf.loadGraphModel('model.json');

// 将笔迹点转换为模型输入
const input = preprocess(points);
const prediction = model.predict(input);
const text = decodePrediction(prediction);

这里有个经验：预处理非常关键。不同人的书写习惯不同，有的人写得大，有的人写得小。你需要对笔迹做归一化，缩放到固定大小，同时保持宽高比。

我曾经遇到过一个情况：用户写了一个“大”字，因为写得太大，模型识别成了“太”。后来我加了归一化，问题就解决了。

5. 智能图形识别：从“画圆”到“完美圆”

除了手写文字，白板上还经常画图形。比如画一个圆，但手抖画成了椭圆。这时候，智能图形识别就派上用场了。

我的做法是：检测笔迹的闭合性。如果用户画了一个近似闭合的曲线，我们就判断它可能是一个图形。然后，用Ramer-Douglas-Peucker算法简化曲线，再用最小二乘法拟合出最接近的几何图形（圆、矩形、三角形等）。

比如，如果检测到四个角点，且对边平行，就识别为矩形。如果检测到所有点到中心距离近似相等，就识别为圆。

识别完成后，把“手绘圆”替换成“完美圆”，同步给其他客户端。这样，大家看到的都是规整的图形，而不是歪歪扭扭的线条。

6. 整体架构：一张图看懂

说了这么多，我们来画一张图，把整个流程串起来。

从这张图可以看出，整个白板协作的核心就是：本地操作 -> 数据通道同步 -> 远端渲染。AI识别可以放在本地，也可以放在远端，取决于你的场景。

7. 避坑指南：我踩过的那些坑

最后，分享几个我实际项目中踩过的坑，希望能帮你少走弯路。

• Canvas重绘性能：如果每次收到远端操作都重绘整个Canvas，性能会非常差。我建议使用分层Canvas，一层画自己的笔迹，一层画远端的笔迹，只重绘变化的部分。
• 数据通道缓冲区溢出：如果短时间内发送大量数据，数据通道的缓冲区可能会满。需要监听bufferedAmount，当超过阈值时，暂停发送，等缓冲区清空再继续。
• 时间戳同步：不同客户端的系统时间可能不一致。我建议使用WebRTC的RTCStats获取NTP时间，或者干脆用逻辑时钟（Lamport时钟）来排序操作。
• AI模型加载时机：不要在页面加载时就加载AI模型，那样会阻塞渲染。我建议在用户第一次使用手写或图形识别时，再异步加载模型，并显示一个“加载中”的提示。

好了，关于实时白板与协作，今天就聊到这里。内容不少，但每个点都值得你深入去实践。记住，技术是死的，场景是活的。多从用户的角度思考，才能做出真正好用的产品。

---