最近在做一个实时对战类的 CocosCreator 项目用 WebSocket 做通信是跑不掉的。项目上线前做压力测试当在线人数一多各种问题就冒出来了消息延迟、客户端卡顿、甚至偶发的连接断开。这逼得我不得不停下来好好把 WebSocket 这一块从里到外梳理和优化了一遍。今天就把这次“填坑”和“优化”的实战经验整理出来希望能帮到遇到类似问题的朋友。1. 背景痛点实时游戏通信的那些“坑”在实时性要求高的游戏里比如 MOBA、棋牌或者实时策略游戏网络通信的稳定和高效是生命线。直接用原生的 WebSocket虽然简单但很快就会遇到下面几个典型问题消息丢失与乱序网络波动时客户端可能收不到服务端的某条消息或者后发的消息先到了。对于战斗指令、位置同步这类数据乱序或丢失直接导致游戏逻辑错乱。高并发下的性能瓶颈当服务器同时向大量客户端广播消息比如全服公告、大范围技能特效时原生 WebSocket 的发送队列可能堵塞造成消息堆积客户端感受到的就是“卡顿”。心跳包的开销与误判为了保持连接活跃和检测死连接需要定时发送心跳包。固定频率的心跳在网络空闲时是浪费在消息密集时又可能加重负担。心跳超时时间的设置也是个难题设短了容易误判正常连接为断开设长了又无法及时清理死连接。内存泄漏隐患在 CocosCreator 中我们习惯用EventDispatcher来监听和派发网络消息。如果监听事件后在节点销毁或场景切换时没有正确移除监听就会导致回调函数无法被垃圾回收内存一点点被吃掉时间一长客户端就可能崩溃。这些问题单靠 CocosCreator 自带的网络模块或者一个简单的 WebSocket 封装是搞不定的需要一套更系统的解决方案。2. 技术选型为什么是“原生WebSocket 自定义协议”面对这些问题首先得选对技术栈。常见的有几种方案原生 WebSocket优点是标准、轻量、无依赖。缺点是功能基础断线重连、心跳、二进制协议等都需要自己实现。Socket.IO功能强大自动重连、心跳、房间管理一应俱全。但它体积相对较大协议也相对复杂对于追求极致性能和包体大小的游戏来说可能有点“重”。通信协议JSON 方便调试但体积大Protobuf体积小、序列化快是性能首选但需要维护.proto文件增加了一些复杂度。结合我们项目的需求实时对战、高并发、包体敏感我最终选择了原生 WebSocket Protobuf的方案。理由如下性能可控原生 WebSocket 最底层没有额外开销。Protobuf 能极大压缩消息体积减少网络传输时间。灵活性高所有逻辑重连、心跳、分片都可以自己定制完美契合游戏业务。包体友好相比引入完整的 Socket.IO只引入 Protobuf 的运行时库要小得多。当然这意味着我们要自己造不少轮子但换来的优化效果是显著的。3. 核心实现一个健壮的 WebSocket 封装类光说不练假把式直接上代码。下面是一个用 TypeScript 实现的、带自动重连和状态管理的 WebSocket 封装类核心部分。// NetworkManager.ts export class NetworkManager { private ws: WebSocket | null null; private reconnectAttempts: number 0; private readonly maxReconnectAttempts: number 5; private reconnectTimer: number 0; private isManualClose: boolean false; // 是否手动关闭 private eventTarget: cc.EventTarget new cc.EventTarget(); // 连接服务器 public connect(url: string): void { if (this.ws this.ws.readyState WebSocket.OPEN) { console.warn(WebSocket is already connected.); return; } this.isManualClose false; this.ws new WebSocket(url); this.ws.onopen this.onOpen.bind(this); this.ws.onmessage this.onMessage.bind(this); this.ws.onerror this.onError.bind(this); this.ws.onclose this.onClose.bind(this); } private onOpen(): void { console.log(WebSocket connected.); this.reconnectAttempts 0; // 重置重连计数 this.eventTarget.emit(connected); this.startHeartbeat(); // 连接成功开始心跳 } private onMessage(event: MessageEvent): void { // 这里处理接收到的二进制数据假设是Protobuf编码 const arrayBuffer event.data; // 1. 解码Protobuf消息 // const msg YourMessage.decode(new Uint8Array(arrayBuffer)); // 2. 根据消息类型派发到具体的游戏逻辑事件 // this.eventTarget.emit(msg_type_${msg.type}, msg.data); // 示例派发一个网络消息事件 this.eventTarget.emit(network-message, arrayBuffer); } private onError(): void { console.error(WebSocket error.); this.eventTarget.emit(error); } private onClose(): void { console.log(WebSocket closed.); this.stopHeartbeat(); this.eventTarget.emit(disconnected); // 非手动关闭则尝试重连 if (!this.isManualClose) { this.scheduleReconnect(); } } // 自动重连逻辑 private scheduleReconnect(): void { if (this.reconnectAttempts this.maxReconnectAttempts) { console.error(Max reconnect attempts reached.); this.eventTarget.emit(reconnect-failed); return; } this.reconnectAttempts; // 重连间隔采用指数退避策略如 1s, 2s, 4s, 8s... const delay Math.min(1000 * Math.pow(2, this.reconnectAttempts - 1), 30000); console.log(Will reconnect in ${delay}ms. Attempt ${this.reconnectAttempts}); this.reconnectTimer setTimeout(() { this.connect(this.ws?.url || ); // 重新连接 }, delay); } // 发送消息 public send(data: ArrayBuffer | string): boolean { if (this.ws this.ws.readyState WebSocket.OPEN) { this.ws.send(data); return true; } console.warn(WebSocket is not open. Message not sent.); return false; } // 手动关闭 public close(): void { this.isManualClose true; this.stopHeartbeat(); if (this.ws) { this.ws.close(); } if (this.reconnectTimer) { clearTimeout(this.reconnectTimer); } } // 与CocosCreator事件系统集成提供on/off接口 public on(event: string, callback: Function, target?: any): void { this.eventTarget.on(event, callback, target); } public off(event: string, callback?: Function, target?: any): void { this.eventTarget.off(event, callback, target); } // 心跳相关私有方法 private heartbeatInterval: number 0; private lastPongTime: number 0; private startHeartbeat() { /*...*/ } private stopHeartbeat() { /*...*/ } }与 CocosCreator EventDispatcher 的深度集成 这个封装类的妙处在于它内部使用了一个cc.EventTarget实例。这样游戏中的任何脚本如PlayerCtrl,BattleScene都可以像监听本地事件一样监听网络事件彻底解耦网络层和业务逻辑层。// 在某个Component中 import { networkManager } from ./NetworkManager; // 假设是单例 onLoad() { // 监听连接成功事件 networkManager.on(connected, this.onConnected, this); // 监听具体的网络消息事件 networkManager.on(network-message, this.handleNetworkMessage, this); // 监听断开事件 networkManager.on(disconnected, this.onDisconnected, this); } onDestroy() { // 非常重要在节点销毁时移除监听防止内存泄漏 networkManager.off(connected, this.onConnected, this); networkManager.off(network-message, this.handleNetworkMessage, this); networkManager.off(disconnected, this.onDisconnected, this); }4. 性能优化实战分片与动态心跳消息分片策略 当需要传输大的二进制数据比如一个大的配置文件、角色自定义数据时直接发送一个巨大的 WebSocket 消息会阻塞通道影响其他实时指令。我们的做法是分片。// 发送端将大数据分片 public sendLargeData(data: Uint8Array, chunkSize: number 1024): void { const totalChunks Math.ceil(data.length / chunkSize); const messageId Date.now(); // 简单生成一个消息ID for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize, data.length); const chunk data.slice(start, end); // 封装分片协议消息ID | 当前分片索引 | 总分片数 | 数据 const header new ArrayBuffer(12); // 假设头部长12字节 const headerView new DataView(header); headerView.setUint32(0, messageId, true); headerView.setUint16(4, i, true); headerView.setUint16(6, totalChunks, true); // ... 可以加入校验和等 // 合并头部和分片数据然后发送 const packet this.mergeArrayBuffer(header, chunk); this.send(packet); } } // 接收端重组分片需要在NetworkManager的onMessage中实现分片缓存和重组逻辑这相当于把一大卡车货拆成多个小货车依次运输不会堵住高速公路WebSocket 通道。动态心跳间隔算法 固定心跳比如每秒一次不智能。我们的策略是当业务消息频繁时延长心跳间隔当连接空闲时恢复较短间隔及时探测连接健康度。动态心跳间隔计算公式示例 基础间隔T_base 5000ms (5秒) 上一次收到业务消息到现在的时间T_idle 动态间隔T_heartbeat T_base min(T_idle * 0.5, 30000) // 空闲越久下次心跳间隔越长但不超过35秒实现上每次收到任何业务消息就重置一个lastActivityTime戳。心跳定时器触发前根据当前时间与lastActivityTime的差值动态计算下一次心跳的等待时间。这样在战斗激烈、消息频发时心跳几乎不占额外带宽在挂机场景又能保持合理的探测频率。5. 避坑指南内存泄漏与兼容性内存泄漏检测 CocosCreator 开发网页版Chrome DevTools 是我们的好帮手。定期做一次内存快照对比是发现泄漏的黄金方法。打开 Chrome DevTools进入Memory标签。在游戏运行前点击Take heap snapshot拍一张快照。进行一系列可能导致泄漏的操作比如反复进入退出战斗场景。操作完成后点击Collect garbage(垃圾桶图标)然后拍第二张快照。在第二张快照的视图下拉菜单中选择Comparison与第一张快照对比。关注(closure)、EventListener、Array等对象的增量。如果某个你自己的类如NetworkManager、Player的实例数量只增不减那很可能就是泄漏了。通常问题就出在事件监听没有off。安卓 WebView 兼容性 一些旧的或定制化的安卓 WebView 内核对 WebSocket 的支持可能不完整。我们遇到过在游戏切到后台后WebSocket 连接被强制断开且不会触发onclose事件的情况。 解决方案是增加一个“前端心跳超时”检测。即使 WebSocket 的onclose没触发如果长时间比如心跳超时时间的2倍没收到任何服务器消息包括心跳回复我们也主动判定为连接断开触发重连逻辑。6. 效果验证压测数据说话优化不能凭感觉。我们用 JMeter 模拟了 1000 个并发用户持续发送小消息如移动指令和偶尔的大消息如分片数据。优化前原生WebSocket固定心跳平均延迟~220ms消息吞吐量 (QPS)~4500在持续高压下出现约 5% 的消息延迟超过 500ms。优化后封装类动态心跳分片平均延迟~150ms(下降约32%)消息吞吐量 (QPS)~6200(提升约38%)高延迟消息比例降至 1% 以下。客户端内存增长曲线变得平缓长时间运行无崩溃。这些数据证明我们的优化方向是有效的特别是动态心跳和分片策略显著平滑了网络流量减少了不必要的开销和阻塞。单元测试与Clean Code为了保证封装类的可靠性我们为关键函数写了单元测试使用 Jest 或 Mocha。// NetworkManager.test.ts describe(NetworkManager, () { let networkManager: NetworkManager; beforeEach(() { networkManager new NetworkManager(); }); test(should reconnect up to max attempts, () { // 模拟连接失败验证重连逻辑和次数限制 // ... 使用Jest的timer mocks }); test(should not reconnect after manual close, () { networkManager.connect(ws://test); networkManager.close(); // 验证重连定时器被清除且不会触发重连 }); test(event listeners should be added and removed correctly, () { const callback jest.fn(); networkManager.on(test-event, callback); networkManager.emit(test-event); // 假设有emit方法用于测试 expect(callback).toHaveBeenCalledTimes(1); networkManager.off(test-event, callback); networkManager.emit(test-event); expect(callback).toHaveBeenCalledTimes(1); // 次数不应增加 }); });遵循 Clean Code 原则我们将大的onMessage函数按消息类型拆分成多个小的处理函数每个函数职责单一。重连、心跳、分片重组等逻辑也都封装成独立的私有方法并通过清晰的注释说明其意图。总结与思考这次对 CocosCreator WebSocket 通信的深度优化让我体会到对于实时游戏网络层绝不仅仅是“连通就行”。它需要像设计游戏关卡一样精心考虑流量控制、异常处理和资源管理。封装一个健壮的网络管理器是项目后期稳定的基石。一定要记得在组件的onDestroy或onDisable里off掉网络事件监听这是避免 CocosCreator 项目内存泄漏的最高频注意事项。最后抛出一个我们正在思考的进阶问题也欢迎大家讨论如何设计一个消息优先级系统来应对战斗同步场景比如玩家的移动指令高频率、可丢弃旧状态和技能释放指令关键、必须可靠到达的优先级肯定不同。是否需要在发送队列里做文章还是说在协议层就给消息打上优先级标签让服务器和客户端协同处理期待听到你的想法。