在 Swift 开发中，值类型（Struct/Enum）与引用类型（Class）的选择不仅仅是语法习惯，更是一场关于 内存分配成本、线程安全 与 引用计数负担 的性能博弈。
以下是支撑性能取舍的四大核心原则：
1. 内存分配：栈（Stack）vs 堆（Heap）
内存分配的物理位置决定了初始化和销毁的“起跑线”。
- 值类型（栈分配） ：分配成本几乎为零。CPU 仅需移动栈指针即可完成。当函数执行结束，内存自动通过栈回退释放。
- 引用类型（堆分配） ：分配成本昂贵。系统必须在堆中寻找合适大小的连续空闲块，这个过程需要加锁（Locking）以保证多线程安全，且销毁时还涉及复杂的内存回收逻辑。
原则 1：对于生命周期短、数据结构简单的模型，优先使用 Struct 以规避堆分配开销。
2. 引用计数（ARC）的“隐形”重量
很多人误以为 Struct 没有 ARC 开销，这其实是一个常见的误区。
-
纯值类型：如果 Struct 内部全是
Int、Double等基础类型，它是真正的零 ARC 开销。 -
复合值类型：如果 Struct 内部包含
String、Array或Class成员，情况会变糟。每当你拷贝这个 Struct，其内部所有的引用成员都要执行一次retain。- 性能坑点：一个含有 5 个
String的 Struct，其拷贝成本比包含 5 个String的 Class 还要高，因为后者只需对 Class 实例本身执行一次retain。
- 性能坑点：一个含有 5 个
原则 2：如果一个数据结构包含超过 2 个引用类型成员，且需要频繁传递，考虑将其包装成 Class 或使用 Copy-on-Write 优化。
3. 写时拷贝（Copy-on-Write, COW）的权衡
Swift 的集合类型（如 Array, Dictionary）通过 COW 兼顾了值语义和性能。
-
机制：只有在数据真正发生修改时，才会触发昂贵的内存拷贝。如果只是传递（只读），它们和引用类型一样高效。
-
取舍：
- 如果你自定义的 Struct 非常庞大且需要频繁修改，手动实现 COW（利用
isKnownUniquelyReferenced）可以大幅提升性能。 - 如果没有 COW，频繁修改大 Struct 会导致 O(N) 的拷贝开销。
- 如果你自定义的 Struct 非常庞大且需要频繁修改，手动实现 COW（利用
原则 3：对于大数据量容器，利用 COW 保护值语义，避免无意义的完整内存拷贝。
4. 派发机制（Dispatch）与编译器优化
派发方式决定了方法调用的“路径长度”。
- 值类型：默认使用 静态派发（Static Dispatch） 。编译器在编译期就知道要执行哪段代码。这允许编译器执行内联优化（Inlining） ，将函数调用直接替换为函数体，消除调用开销。
- 引用类型：默认使用 动态派发（V-Table / Message Dispatch） 。运行时需要查表找地址，且由于存在多态和 Swizzling 的可能，编译器通常无法进行深度内联。
原则 4：追求极致响应速度的底层逻辑（如算法、数学运算）应锁定在 Struct/Enum 中，利用静态派发换取内联红利。
总结：取舍决策表
| 维度 | 倾向于使用 Struct (值类型) | 倾向于使用 Class (引用类型) |
|---|---|---|
| 数据大小 | 小型数据（如坐标、颜色） | 大型、复杂的数据结构 |
| 拷贝频率 | 高频传递但修改较少 | 修改频繁，或数据量大到拷贝成本过高 |
| ARC 压力 | 内部不含或少含引用类型 | 内部引用成员极多 |
| 继承需求 | 无需继承，仅需协议扩展 | 需要继承体系或与 OC 框架深度交互 |
| 同一性 | 关注“值”本身（1 就是 1） | 关注“对象”身份（唯一的实例） |
💡 深度启发：结构体中的引用计数“雪崩”
在构建混编系统时，最危险的实践是定义一个巨大的 Struct，里面塞满了各种 UIImage 和 NSString，然后在 for 循环中不断传递它。这会导致 CPU 周期大量空转在原子操作的 retain/release 上。
