联网战斗同步优化

回顾

在上篇文章，主要讲述

1. 联网战斗的简介

• 网络传输协议
• 网络同步模型
• 网络拓扑模型

2. 实现联网战斗的方案
3. 实现时的一些重点处理
4. 实现后的一些优化改进畅想
5. 我的感悟

更详细的内容，请跳转：联网战斗同步实现

正文

之前实现了一版联网战斗方案，还比较粗糙，存在许多不足的地方。
秉承着 先实现，再持续交付、快速迭代 的理念。
由于实践的效果不是很好，所以需要做一版优化。

优化方案

总览：

1. 轮询机制都改为即时
2. 帧推送间隔时间修改
3. 建立帧缓存机制
4. 扩充操作帧上传时机
5. 完善的统计机制
6. 自动化工具完善

轮询机制改为即时

在捋清各个流程步骤时，发现有些轮询机制，会导致延迟的增高。

• 逻辑处的轮询
• 协议收发的轮询

轮询的作用是减轻各模块功能的压力，降低成本。
我个人是觉得，在实现功能的时候，对于这种可控性成本需求，先按最优版本实现，做出我们最优效果。
之后，再根据成本等问题，进行打折简化。
我们做好对比数据的提供，交由项目负责人决策。

帧推送间隔时间修改

之前，为了让客户端压力小一些，处于“饥饿”状态，服务器推帧间隔设置为 35ms。
但是，在有些模块进行逻辑处理依旧以 30帧/秒（固定间隔 33.3ms）处理数据。
会导致部分客户端逻辑 与 实际有差异，造成抖动。

因此，将帧推送间隔时间修改为 33ms，减缓抖动。

建立帧缓存机制[重点]

基础方案，过于依赖网络状况。
显然这样是不现实的，所以需要做一套帧缓存机制，来应对网络的波动。

释放帧的时机：

• 逻辑帧执行时
• 绘制帧执行时
• 逻辑帧执行时释放一次，绘制帧执行时根据需要补充释放

释放帧策略：

• 释放一次，每次释放一帧
  • 可能导致帧积压，越来越卡
• 释放一次，每次释放帧数量可变
  • 每次释放帧数量根据帧缓存池内帧数变化
• 释放多次，每次释放数量可变
• 缓存帧模式，缓存帧数量可配置
• 缓存帧模式，缓存一帧
  • 如果缓存帧数量可配置，就需要做一个让所有配置相对平衡的策略；单做缓存一帧，可以更细致的制定策略
  • 但是经用户体验，发现这个策略并没有比大锅饭更好，甚至更差。。
• 释放一次，每次释放所有帧

可配置缓存

第一版做的是可配置缓存。
缓存帧的数量可配，通过实际体验来决定具体缓存帧的数量。
（最开始设想是，先做成可配；之后再根据实际网络状况，动态修改配置缓存的帧数量，类似于流媒体领域的 JitterBuffer）
对于释放帧的数量方案是&#