Swift

1️⃣ 现象 在 Time Profiler 中，你看到： 频繁调用 → CPU 占用高 → 热路径性能下降 通常出现在： class 实例频繁创建 / 传递 闭包捕获 / 临时对象 协议存在类型 /

1️⃣ Time Profiler 用途：分析 CPU 使用和函数调用热点。 解决问题： 找出 热函数（hot path） 判断函数调用是否过多、循环热点 看 泛型调用、动态派发、CoW 是否频繁发生

1️⃣ 优先使用 泛型 + 值类型 值类型方法（struct / enum）默认静态派发 泛型函数在类型已知时也会被编译器 特化和内联 示例： 泛型 T 已知 → 静态派发 静态派发 → 内联 + 去

1️⃣ 现象示例 为什么看似“多态”却不是？ 协议扩展默认实现是在 静态派发（Static Dispatch） 即便 p 类型是协议类型，也不会调用结构体 S 自己的方法（除非 S 显式实现 foo）

1️⃣ final class 对派发的影响 特点 final class 表示 类不能被继承 所有方法也就无法被子类重写 编译器可以静态派发（直接调用函数指针） 即使方法不是 final，只要类是

1️⃣ 典型示例 调用： addGeneric → 编译器知道 T = Int → 可静态分发 → 高性能 addExistential → 编译器只知道是 NumericProtocol → 动态派

1️⃣ 静态派发（Static Dispatch） 特点 编译期确定调用目标函数 零开销（没有额外指针查找） LLVM 可以进一步 内联、向量化、优化 CoW 一定是静态派发的情况 场景 示例 说明

1️⃣ 函数设计：让函数小而热 原则：函数越小，越容易被内联 实践： 好处： square 很小 → 易于内联 调用方看到函数体 → 可生成特化版本 2️⃣ 泛型设计：类型约束明确 + 避免抽象过深

1️⃣ 问题现象 假设你写了一个跨模块泛型库： 2️⃣ 原因分析 （1）泛型特化受限 Swift 泛型特化（Generic Specialization） 机制： 编译器会为 具体类型 T 生成专门实

1️⃣ @inlinable 定义 告诉 编译器和模块外调用方： 常用于 库函数/框架函数，允许跨模块内联 特点 函数体 会暴露在模块接口中（即 public 或 internal 可见） 编译器可选

1️⃣ 泛型函数（Generic Function） 本质特点 编译期已知类型 调用时 T 是具体类型（Int、Double…） 编译器可以 生成特化版本 → 去掉动态派发 LLVM 可以做 内联、S

1️⃣ 泛型特化是什么 泛型本质：func foo<T>(x: T) 在编译时 T 是未知类型 → 生成“通用代码” → 运行时通过 动态派发 / type metadata 处理 代价：可能有额外

1️⃣ 值类型（struct + mutating） 安全性 天然线程安全：每个线程拿到的是 struct 的 独立副本，互不干扰。 快照语义：读写不会影响其他线程的数据副本。 CoW 注意：如果 s

1️⃣ 值语义的优势和成本 优势： 安全：不会意外被其他对象修改 可预测：状态总是清晰、易于回溯（快照） 线程安全：读多写少不需要锁 成本： 频繁拷贝：大型 struct 或数组每次修改可能触发 Co

1️⃣ 传递方式优化 （1）用 inout 避免不必要拷贝 inout 直接在调用者的内存上操作。 注意：调用者的 data 会被写入，函数内修改会影响外部。 （2）使用指针或 UnsafeMutab

1️⃣ 栈分配 vs 堆分配 栈（stack） ： 生命周期短，跟随作用域。 访问快，自动释放。 常见：局部变量、函数参数（非闭包捕获）。 堆（heap） ： 生命周期由引用计数控制（ARC）。 访问

下面我用 真实可遇到的场景 给你拆。 一、真实场景 1：大 struct + 频繁传参（最常见） ❌ struct 翻车版本 为什么慢？ Packet 是值类型 每次 process(packet)

一、CoW 的核心假设（先记住） 一旦现实不满足这个假设，CoW 就会崩。 二、最常见的 CoW 性能灾难场景 1️⃣ “读-写交错”的大数组流水线 问题在哪里？ data 被遍历（只读视图） 同时又

下面我按 「劣势点 → 为什么 → 什么时候会明显」 来拆。 一、Swift 在大规模数据处理里的常见性能劣势 1️⃣ ARC 开销更重（Swift > Objective-C） 表现 retain

一、集合 & 值语义陷阱（最常见） 1️⃣ for x in array { ... array.append(...) } 为什么危险 每次 append 都可能触发 COW 实际是 O(n²) +