Unity中FindObjectsOfType<T>()的实现原理及性能慢因探究

作为常年泡在Unity相关问题里的老鸟，我来给你拆解下FindObjectsOfType<T>()的门道——毕竟这玩意儿可是性能优化里绕不开的坑。

底层实现逻辑（C++层面） #

Unity用C++实现核心引擎逻辑，FindObjectsOfType<T>()的运作流程大概是这样的：

• 全局对象容器：Unity会把场景中所有活跃的GameObject、Component统一维护在一个全局的对象集合里（底层不是简单的数组，但有连续存储的特性，方便遍历）。
• 自定义类型系统匹配：Unity没有直接用C++原生的RTTI（运行时类型信息），而是自己搞了一套更灵活的类型识别体系，适配它的组件继承规则。调用这个方法时，引擎会遍历整个全局对象列表，逐个检查对象的类型是否是T或者T的派生类。
• 状态过滤：默认只会返回activeInHierarchy为true的对象，当然你也可以通过传入FindObjectsInactive参数来调整过滤规则。

为什么官方说它性能较慢？ #

你的猜测方向是对的，核心问题就是全量遍历+类型检查的组合拳：

• 遍历成本：不管你要找的是多么小众的组件类型，它都会把整个全局对象列表过一遍。场景里的对象、组件越多，这个遍历的时间就越长。
• 类型匹配开销：虽然Unity的自定义类型系统比C++原生RTTI高效，但每一个对象都要做派生类的匹配检查——这不是O(1)的操作，当对象数量大的时候，累计的开销就很可观了。
• 跨语言转换成本：Unity的C# API只是上层包装，最终要把C++层面的对象指针转换成C#的托管对象，这个转换过程在返回大量结果时，也会额外消耗性能。
• 无默认缓存：每次调用FindObjectsOfType<T>()都会重新执行一遍遍历和检查，如果你在Update这类高频函数里调用，性能问题会被直接放大。

为啥Unity不做更高效的优化？ #

其实是灵活性和性能的trade-off：

• 如果给每个类型单独维护一个索引列表，确实能做到O(1)的查找速度，但会大幅增加对象生命周期的维护成本——比如一个Component同时属于多个父类类型，要加入多个列表；对象被激活、禁用、创建、销毁时，都要同步更新这些列表，逻辑复杂度会飙升。
• 考虑到Unity场景的动态性（随时可能新增、删除对象），维护实时的类型索引需要额外的同步逻辑，反而可能在高频操作场景下拖慢整体性能。

内容的提问来源于stack exchange，提问作者Tolstenko