游戏卡顿白皮书 › L1 客户端游戏进程
主线程数据包处理瓶颈 Network processing on the main thread
原因 ID cg-net-mainthread · 主责 研发团队·客户端开发 · 配合 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
收到的数据包每帧只处理固定数量时，一下子涌来的数据包会不断顺延到下一帧。
起因 人多的地方每秒涌入数千条更新 → 结果 主线程受每帧处理量上限限制，读不完 → 画面表现 其他人的动作体现得越来越晚，而且是集中补上
- 症状
- 快进, 操作延迟
- 因素
- 停顿, 延迟
- 谁会遇到
- 特定地点/分线, 只有我
- 何时出现
- 人多的时候
- 负责方
- 主责 研发团队·客户端开发 · 配合 研发团队·服务器开发
- 研发团队要做的事
- 客户端：接收与解析放到单独的线程，同一对象的旧位置更新合并后只应用最新的。服务器：人多的地方降低远处角色的更新频率，减少发送量。
- 数值参考
- 处理不完的数据包不断堆积，几秒钟就足以积压 1 秒的量。
- 监控图上
- 随人数/负载上升 · 未处理的接收数据包数、从接收到应用的延迟
- 查看位置
- 让客户端把每帧没处理完、留下来的数据包数，以及数据包从到达到应用进游戏的延迟写进日志，和周围人数一起看
- 确认依据
- 人多的地方剩余数据包数和应用延迟持续增加，同一时刻 ping 和服务器的发送间隔正常
- 排除依据
- 没有应用延迟、数据包本身到得晚，是网络段的问题。帧耗时大幅上升，看“大规模同屏渲染负载”
- 确认手段
- 需要游戏服务器/客户端的日志和指标
出处
- Actor Priority in Unreal Engine Epic Games
带宽不足时，按与观察者的距离、距上次复制的时间给 Actor 排优先级，不会每次都复制全部 Actor - Replication Graph in Unreal Engine Epic Games
在线人数多、复制对象多的游戏（如 MMORPG）要按位置分组、只发送需要的对象，才能避免服务器 CPU 瓶颈
相关原因
同一层：L1 客户端游戏进程
其他层中同样导致“快进”的原因
查看含图示和实验的原卡片