WebSocket传Protobuf二进制协议可显著降低移动端流量——需设binaryType='arraybuffer'、用protobuf-ts生成代码、加1字节类型ID、高频字段启用packed、整型优选sint32、禁用int64、大资源走CDN、校验包长、分片超50KB消息。
在HTML5中用WebSocket传Protobuf二进制协议，能显著降低移动端流量消耗——核心在于避开JSON文本膨胀和Base64编码冗余，直接走紧凑二进制通道。关键不是“能不能”，而是“怎么设对、怎么编、怎么防错”。
设置WebSocket为二进制通道
浏览器默认把send()发的普通对象转成文本帧，必须显式切换：
- 连接建立后立即执行：
socket.binaryType = 'arraybuffer'; - 发送前确保数据是
Uint8Array或ArrayBuffer，不能是字符串或Object - 服务端需识别并原样处理二进制帧（如FastAPI中检查
data["bytes"]字段）
前端集成Protobuf并生成轻量代码
不用手写序列化逻辑，靠工具链保证效率和一致性：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
.proto定义消息（如PlayerPosition { int32 x = 1; int32 y = 2; }），避免嵌套过深或大字段 - 选用
protobuf-ts（比protobuf.js更小，适合移动端）生成TS/JS类 - 发送时：
new PlayerPosition({x:100,y:200}).encode().finish()→ 得到Uint8Array - 接收后：
PlayerPosition.decode(new Uint8Array(event.data))→ 还原为JS对象
协议设计上专为省流优化
Protobuf本身省空间，但设计不当仍会浪费字节：
立即学习“前端免费学习笔记（深入）”；
- 每条消息头部加1字节类型ID（如
0x03表示位置同步），不用反射查类型，减少解析开销 - 高频小包（如每秒10次的位置更新）启用
repeated int32 x = 1 [packed=true];，压缩连续数值 - 整型字段优先用
sint32而非int32，负数编码更短；避免int64，JS精度丢失需转字符串处理 - 不传图片、音频等大资源，它们走CDN或分片上传，Protobuf只传控制指令和状态摘要
移动端特别要注意的健壮性措施
弱网下二进制出错难调试，需主动防御：
- 客户端校验消息长度：解码前检查
event.data.byteLength >= 3（最小合法包长），空包直接丢弃 - 开发期开启
protobuf-ts的严格模式，捕获字段缺失、类型错位等隐性错误 - 服务端返回错误时，用固定格式二进制错误包（如
[0xFF, 错误码]），前端统一拦截，不触发全局异常 - 对超50KB的消息自动分片，每片加2字节序号头，避免单帧过大导致TCP重传放大延迟
