回顾
在上篇文章,主要讲述
- 联网战斗的简介
- 网络传输协议
- 网络同步模型
- 网络拓扑模型
- 实现联网战斗的方案
- 实现时的一些重点处理
- 实现后的一些优化改进畅想
- 我的感悟
更详细的内容,请跳转:联网战斗同步实现
正文
之前实现了一版联网战斗方案,还比较粗糙,存在许多不足的地方。
秉承着 先实现,再持续交付、快速迭代 的理念。
由于实践的效果不是很好,所以需要做一版优化。
优化方案
总览:
- 轮询机制都改为即时
- 帧推送间隔时间修改
- 建立帧缓存机制
- 扩充操作帧上传时机
- 完善的统计机制
- 自动化工具完善
轮询机制改为即时
在捋清各个流程步骤时,发现有些轮询机制,会导致延迟的增高。
- 逻辑处的轮询
- 协议收发的轮询
轮询的作用是减轻各模块功能的压力,降低成本。
我个人是觉得,在实现功能的时候,对于这种可控性成本需求,先按最优版本实现,做出我们最优效果。
之后,再根据成本等问题,进行打折简化。
我们做好对比数据的提供,交由项目负责人决策。
帧推送间隔时间修改
之前,为了让客户端压力小一些,处于“饥饿”状态,服务器推帧间隔设置为 35ms。
但是,在有些模块进行逻辑处理依旧以 30帧/秒(固定间隔 33.3ms)处理数据。
会导致部分客户端逻辑 与 实际有差异,造成抖动。
因此,将帧推送间隔时间修改为 33ms,减缓抖动。
建立帧缓存机制[重点]
基础方案,过于依赖网络状况。
显然这样是不现实的,所以需要做一套帧缓存机制,来应对网络的波动。
释放帧的时机:
- 逻辑帧执行时
- 绘制帧执行时
- 逻辑帧执行时释放一次,绘制帧执行时根据需要补充释放
释放帧策略:
- 释放一次,每次释放一帧
- 可能导致帧积压,越来越卡
- 释放一次,每次释放帧数量可变
- 每次释放帧数量根据帧缓存池内帧数变化
- 释放多次,每次释放数量可变
- 缓存帧模式,缓存帧数量可配置
- 缓存帧模式,缓存一帧
- 如果缓存帧数量可配置,就需要做一个让所有配置相对平衡的策略;单做缓存一帧,可以更细致的制定策略
- 但是经用户体验,发现这个策略并没有比大锅饭更好,甚至更差。。
- 释放一次,每次释放所有帧
可配置缓存
第一版做的是可配置缓存。
缓存帧的数量可配,通过实际体验来决定具体缓存帧的数量。
(最开始设想是,先做成可配;之后再根据实际网络状况,动态修改配置缓存的帧数量,类似于流媒体领域的 JitterBuffer)
对于释放帧的数量方案是&#