问FindObjectsByType和FindObjectsOfType有什么区别？

EN

当您想知道API中某个特定添加项的基本原理时，最好从相关更新的发布说明开始。我发现这个是搜索“统一查找对象类型”做的

脚本:添加:新增的Object.FindObjectsByType()函数，作为Object.FindObjectsOfType()的一个可能更快的替代方案。这个新函数让用户可以选择是否由InstanceID对返回的对象集合执行昂贵的排序，而不是总是让它执行，这样会浪费不必要的时间。有关详细信息，请参阅Object.FindObjectsByType()和Object.FindObjectsOfType()的脚本文档。

这与添加FindFirstObjectByType和FindAnyObjectByType的原理类似。，这是在同一更新(2021.3.18)中引入的。

我怀疑这些增加表明，在引擎盖下，统一改变了开放场景中的游戏对象及其组件存储在内存中的方式，或者是用于搜索它们的加速结构，这种方式使得以无序的方式获得游戏对象的速度大大加快，但以稳定/一致的顺序得到它们的速度更慢。因为对于许多常见的用例，我们不关心顺序，这让开发人员在合适的时候选择快速的方法。

但是，他们不能仅仅改变现有函数的行为，因为这可能是旧代码的一个重大变化，因为旧的方法以稳定的顺序返回对象--对正在开发中的试图更新其版本的项目造成了极大的破坏，或者谁知道有多少第三方资产和插件在资产商店或教程中没有得到积极维护。因此，他们保持了旧函数的原样，并为新代码提供了一个新的更加明确的API。

如果在将来的统一版本中，旧的FindObjectOfType/FindObjectsOfType API被废弃，或者自动升级到等效的新版本，或者被用于生成编译器警告，那么我就不会感到惊讶了--这样，开发人员就会被提示检查每个调用站点，以确定这种情况是否需要稳定排序，让他们根据需要显式地选择快速路径或慢路径(如果有必要，可以重构他们的方法，以便能够采用快速路径)。团队可能会给一些时间去战斗--在采取这一步骤之前测试新的API或稳定引擎的其他部分，或者给资产开发人员自愿更新的时间，以便在旧API最终被废弃时最小化警告垃圾邮件和干扰。不过，这只是我的猜测。

tl;dr:没有理由继续使用旧的FindObjectsOfType API。新代码应该只使用更显式的FindObjectsByType API，尽可能使用更快的FindObjectsSortMode.None选项。

在确实需要稳定排序的情况下，传递FindObjectsSortMode.InstanceID会使需求变得明确，因此很明显，您不会像FindObjectsOfType那样偶然地走慢路。