@catror 假设生产的速率是一定的，在 3F 的解法中：

每次生产出一个 Messsage (onNewMessage)，就调用一次 queue.push() 方法实现原子操作；另一个线程从 queue 中不断读取数据并发送

在 8F 的解法中：

每次生产一个 Message (onNewMessage)，就调用 send() 方法把这个 Message 整个发出去，如果需要等待，就一直阻塞在那里；这时因为发生了阻塞，实际上也就不会有新的 Message 产生

本质上，前者是 “生产不阻塞” 模式，后者是 “阻塞生产” 模式

我想了一下，对我的实际场景，两者都是可以的。但是 8F 的解法对生产的逻辑有一个要求：生产者要能感知到阻塞的发生，在阻塞结束后，测量一下阻塞了多少时间，然后下次生产新的实时数据，而不因为阻塞导致后续生产的数据实时性发生整体偏移

@catror 要避免的，就是 “只填消息的一部分进去”

@ho121 UDP 长度不够

如果消息比较短，UDP 就完全没问题了

***hotspot 确实很有用，我有一台备用机就专门干这事

让控制变量法更困难的是，每次只抽 5 道题作为试卷

@loading 亲，你来算下一共有多少种答案

@LnTrx Offline Render 是一个不错的关键字，可以搜到不少的离线渲染插件

不过一些 Offline Render 插件的描述也挺让人迷惑的，比如这个:

Offline Render is an easy to use, realtime capture plugin for Unity

看描述，还是无法区分它到底是实时的还是非实时的 (是否会跳帧)

那么问题来了：Unity 支持不跳帧的离线渲染吗？

@reus 并不是用 1s 的时间渲染 60 帧然后录屏，而是可以接受用 2s 的时间渲染 60 帧 (但是此时动画时间仍是 1s)

---

这个流程是不是有点奇怪？我再举个例子：

Unity 将画面输出给一个媒体服务器进行视频编码，一开始的 FPS 是 60 fps，Unity 已经执行了 1s
此时 Unity 到视频编码服务器之间的网络断了 1s，此时作为流水线的起点，Unity 程序应当暂停渲染，以保证传输管道不会溢出 (就好像在 Unity Editor 里按了暂停按钮一样)
当真实时间是 2.0s 时，动画时间在 1.0s ，网络恢复了，此时 Unity 不能跳帧；观众则会在画面卡了 1s 后，继续以正常速度观看到后续的动画

@param 对的，感觉 “不跳帧” 和大部分传统游戏的设计思路是相反的，不知道 Unity 是否支持

视频是固定帧率的，当性能问题出现时，希望 Unity 引擎会 “阻塞”

“阻塞” 消失时，Unity 中的时间不发生跳跃，而是继续渲染下一帧

@learningman @across
不是真的游戏，大致的应用场景，就是把 fbx 动画转视频 (在某个具体场景中进行渲染)

如果有一个 802.11g 的客户端接入了，而且在以 54 Mbp 全速传输，那么通信容量会被占满
但是如果这个 802.11g 客户端是空闲的，那么就对其它设备没有影响

实际上提交的时候，是能检测出用户所属的国内运营商的

这样 list 可以按照地区 /运营商来分化，但是感觉就比较复杂了

@sanmmmm 如果结果不稳定，那就降权，不包含在 tiny 版本的列表里

基准 -> 基准频率