声明：本文所用Unity版本为
2021.3.2f1c1。Mac使用的是MacBook Pro (16-inch, 2019)，CPU型号为2.3GHz 八核Intel Core i9。Windows所用CPU型号为11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz。
帧同步与时间
帧同步，游戏开发常见的同步方案。简单来说就是让各个客户端的逻辑部分，按照固定的速度进行心跳。在这里，时间就是控制每个客户端逻辑帧率的唯一变量。
在Unity开发中，因为帧同步需要定帧，所以最常见的定帧的方式有两种：使用Unity的FixUpdate，或着自己管理时间。
FixUpdate只需要把它的DeltaTime设置成所需要的时间即可，我们着重说第二种：自己管理时间。
double time; // 时间累积
double interval; // 逻辑帧间隔
void Update(float delta)
{
time += delta;
while (time >= interval)
{
time -= interval;
LogicTick(); // 逻辑帧心跳
}
}
正如上面代码展示，我们通过累积时间，每满足一次逻辑帧的帧率时间，就进行一次逻辑心跳，并将累积时间减去一个逻辑帧间隔时间。这里函数的参数，就可以传入UnityEngine.Time.deltaTime。
问题的出现
现在问题来了，当我实际去运行的时候，发现同样的一套代码所写的逻辑，mac端就是比windows端延迟感更明显。
为了查明问题，我专门实时显示了两端与服务器的RTT，结果发现RTT均在30ms以内，说明问题不在这里。
之后我才去监测二者每次逻辑心跳所对应的逻辑帧号与服务器帧号，结果大出意料：mac端的时间比windows端过得要慢，而且随着时间的累积效应，mac端会越来越卡（类似于延迟时间越来越大）。
对这个问题进行排查，我将问题定位到了UnityEngine.Time.deltaTime。从我们对时间的理解，当Time.timeScale为1时，Time.unscaledDeltaTime与Time.deltaTime与应当是一致的。但是当我们在某一个心跳函数内比较这两个值时会发现，Time.unscaledDeltaTime并不总是等于Time.deltaTime，时长会比这个大。而且每次出现不一致时，Time.deltaTime的值总是一样的。
所以最后，问题被锁定到了Time设置里的Maximum Allowed Timestep选项。
PS：其实我曾经一度以为是跨平台导致Unity底层提供的deltaTime出现了偏差。
Maximum Allowed Timestep的说明
关于Maximum Allowed Timestep这个配置的说明，Unity有一份官方的说明。结合我之前转发的Unity的函数执行顺序，我们可以简单理解为：
FixedUpdate在1次Update可能会执行N次，N约等于Time.deltaTime / Time.fixedDeltaTime。假如Time.deltaTime变大，会导致下一帧FixedUpdate的执行次数N变大，CPU的性能消耗变大，从而又会影响当前Update的耗时。这种糟糕的情况可能需要相当长的时间才能缓解过来。所以Maximum Allowed Timestep限制Time.deltaTime的最大值，N的最大值也固定了，防止出现“最坏”的情况。
解决方案
为了解决这个问题，我们所需要做的就是有一个方案能够替换掉Time.deltaTime。
为什么不使用Time.unscaledDeltaTime？因为在具体的项目中，我们依旧可能会用到Time.timeScale，所以一切从项目实际出发（如果你的项目无所谓，那就大胆用吧）。
下面给出我的解决方案：
private long _lastFrameTicks;
private const double Ticks2Second = 0.0000001;
private double _delta;
public double Delta => _delta * UnityEngine.Time.timeScale;
public void Tick()
{
long currFrameTicks = System.DateTime.Now.Ticks;
_delta = (currFrameTicks - _lastFrameTicks) * Ticks2Second;
_lastFrameTicks = currFrameTicks;
}
通过使用DateTime.Now.Ticks，计算两次心跳之间的时间间隔，再将时间间隔的单位转换为秒，即可作为delta时间去使用。
其实按照这个方案深入下去，依旧有很多点会决定我们Delta计算的正确性。比如这个Tick执行的时机，Unity内所有Update执行的顺序等。但是这些基本都不会影响我们帧同步内时间的累积计算：多个客户端同时开始帧同步运算，那么过去固定时间后，这些客户端的帧号一定是相同的，而不会出现开头我所描述的客户端帧号不一致的bug。
