Swift代码优化中是否应避免使用any？泛型与存在类型性能对比

在学习some与any的区别时，常看到使用any可能引发性能问题，相关建议是除非必须，否则优先使用some。但我遇到一种场景：遵循“尽量避免存在类型”的规则会让代码显得怪异。示例代码如下：

protocol DogDelegate {
    func didBark()
    func willBark()
}

struct Dog<D: DogDelegate> {
    var delegate: D?  // << Making this `(any DogDelegate)?` would look so much better

    func bark() {
        delegate?.willBark()
        print("Woof!")
        delegate?.didBark()
    }
}

我的应用中有一个类似代理的属性，用于对函数进行可选定制，可让调用者略微“修改”吠叫逻辑。若追求极致性能，此场景下是否优先选择泛型？还是说any的性能损耗极小，即便数组中有百万个Dog实例也不会产生显著性能下降？

回答 #

• 明确any的性能损耗来源：any作为存在类型，主要开销来自两个方面——如果是值类型实现协议会触发值装箱，以及方法调用时的动态派发（运行时才确定具体调用的方法）。但你的场景里代理是可选类型，且调用的是无参方法，单步开销非常小。
• 极致性能场景下的选择：如果你的Dog实例真的达到百万级，同时bark方法的调用频率极高（比如每秒数千次甚至更多），泛型版本确实能避免动态派发的开销——因为泛型是静态派发，编译期就能确定方法调用的具体实现。但代价是Dog变成带泛型参数的结构体，使用时必须明确指定泛型类型，代码复杂度会上升。
• 常规场景下的最优选择：如果只是百万实例，但bark的调用频率没有极端高，any的性能损耗几乎可以忽略。单个动态方法调用的开销是纳秒级的，百万次调用的总开销也远达不到影响用户体验的程度。而且(any DogDelegate)?的写法更简洁，代码可读性和可维护性更强。

实际开发中，除非你已经通过性能分析工具确认这部分代码是性能瓶颈，否则优先选择更简洁的any版本——过早优化反而会增加代码维护成本。

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