核心是“控节奏”而非堆性能：服务端按帧聚合弹幕并二进制广播，客户端通过双缓冲池、分层canvas、空间索引与降级策略实现万人同屏流畅渲染。
WebSocket 和 Canvas 配合实现万人同屏弹幕，核心不是“堆性能”，而是“控节奏”——用服务端做弹幕调度、客户端做渲染节流与分层复用，把高频数据转为可控的视觉流。
服务端：按帧率下发弹幕，不发原始事件
直接推送每条弹幕到所有客户端会引发网络风暴和渲染雪崩。正确做法是服务端聚合+定时广播：
- 将弹幕按时间戳归入“逻辑帧”（如每 40ms 一帧，对应 25FPS），同一帧内的弹幕合并为一个 JSON 数组
- 使用 WebSocket 的 binaryType = 'arraybuffer' 发送紧凑格式（如 Protocol Buffers 或自定义二进制结构），比 JSON 小 60%+，降低带宽和解析开销
- 服务端维护每个客户端的“已同步帧序号”，支持断线重连时从最近关键帧恢复，避免漏播或重复
客户端：Canvas 渲染不直追 WebSocket 消息流
收到弹幕消息立刻 drawText() 是最大误区。真实做法是解耦“接收”“缓存”“调度”“绘制”四阶段：
- 用双缓冲弹幕池：一个数组存“待调度弹幕”，另一个存“当前活跃弹幕”；每帧只从待调度池中按优先级（如位置、密度）挑 10–20 条加入活跃池
- Canvas 使用 requestAnimationFrame 驱动固定帧率（如 60FPS），每次绘制前先清空上一帧的弹幕区域（非全 canvas.clearRect，而是仅擦除移动轨迹矩形区），再批量 draw
- 对超出屏幕的弹幕立即从活跃池移除，并复用其 DOM/Canvas 绘制对象（如预创建 100 个 TextMetrics 缓存 + 字体样式对象），避免频繁 new TextMetrics 或 font 设置
视觉优化：用图层分离和空间索引降负载
万人同屏≠万条同时显示。实际可见弹幕通常 ≤150 条。关键在“让看不见的不参与计算”：
- 将 Canvas 分为 3 层：背景层（静态）、弹幕层（动态）、UI 层（按钮/进度条）；弹幕层用 offscreenCanvas 预合成，再 composite 到主 canvas，减少主线程绘图压力
- 对活跃弹幕建立简单空间索引（如按 Y 区间分桶：0–100px、100–200px…），每帧只遍历当前视口所在桶，跳过明显不可见区域
- 启用 CSS will-change: transform 对弹幕容器做硬件加速（若用 DOM 方案），或对 Canvas 启用 webgl 上下文做粒子系统渲染（适合超大并发）
容错与降级：弱网下保体验不崩
真实网络不可能稳定。需内置降级策略：
- 客户端监测 WebSocket ping 延迟 >300ms 时，自动降低接收帧率（如从 25FPS → 10FPS），并暂停新弹幕入池，优先保证已有弹幕流畅滚动
- 当内存中待调度弹幕积压 >500 条，触发“密度裁剪”：丢弃同区域重叠率 >70% 的低优先级弹幕（如颜色浅、字号小、透明度高）
- 提供手动“精简模式”开关：关闭尾迹、禁用渐变字体、切换为 bitmap 字体，CPU 占用可下降 40%+
不复杂但容易忽略：真正卡顿往往来自字体回退（如 emoji fallback 到系统字体导致 layout thrashing）和未限制 canvas 像素尺寸（高清屏上 canvas.width/height 超过 4096 触发 GPU 降频）。上线前务必用 performance.memory 和 chrome://tracing 验证首屏渲染耗时与帧率稳定性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
