Performance analysis and optimization
查看所有标签
QA 提了个 Bug："玩家捡起钥匙后门没开。"
简单吧？大概是缺了个引用或者条件写错了。你打开工程，捡起钥匙，然后……门开了。在你机器上没问题。于是你问测试员复现步骤，他说"大约 30% 的概率出现，通常在存档/读档之后。"
现在你进入了调试地狱。在钥匙拾取事件、背包更新、任务进度检查、和门的解锁条件之间的链路某处，有东西间歇性地失败。但是哪一环？事件没触发？触发了但监听器没订阅？订阅了但条件评估为 false？条件是对的但门的状态在加载后是过期的？
Unity Asset Store 上每一个事件系统插件的描述里都写着"高性能"。就夹在"易于使用"和"完整文档"中间。但问题是——1ms 和 0.001ms 对人来说都很快，可一个比另一个慢了一千倍。当一个插件说"高性能"时，到底在说什么？跟什么比？怎么测的？
我以前也不在意这些。大多数人都不在意。接几个事件，游戏在开发机上跑得好好的，发布就完了。但后来我做了一个移动端项目，几百个实体各自监听多个事件，突然"高性能"就不再是营销打勾项了——而是 60 FPS 和幻灯片之间的区别。
这篇文章讲的是"高性能"对于事件系统到底应该意味着什么、为什么大多数实现达不到、以及 GES 如何通过 Expression Tree 编译实现接近零开销。用真实数据说话，不打太极。