一、真实案例：列表 diff 热路径里的 ARC 风暴 背景（真实发生过） iOS 列表 diff（类似 SwiftUI / UICollectionView diff） 数据量：几千到上万 每次刷新

一句话结论（先给你直觉） 所以在热路径里，weak 往往是最慢的。 一、三种引用的真实成本模型 1️⃣ 强引用（strong） 做了什么 retain / release 多线程下是原子操作 成本特征

一句话总览（结论先行） 下面一个一个说清楚。 1️⃣ ARC retain/release 成为热路径 发生机制 closure 是 heap object self 被捕获 → retain 每次执

一句话结论（先给你记忆锚点） 如果你看到 swift_retain / swift_release 排到 Time Profiler 前几名，一定不是“ARC 太慢” ，而是代码结构在逼 ARC 工作

一、先给你一张「症状 → 根因」速查表（很实用） Instruments 症状 最可能类别 swift_retain / swift_release 占比高 ARC objc_msgSend / wi

我用真实工作流 + 典型案例来回答：我是如何用 Instruments 发现“反直觉瓶颈”，以及怎么解掉的。 一、先说一个核心心法（非常重要） 换句话说： Instruments 是用来推翻直觉的，不

一句话先给结论 不是所有 heap allocation 都是坏的，坏的是：可避免 + 高频 + 在循环里。 一、Allocations 里我主要看哪几个维度？ 1️⃣ 分配频率（Rate）比总量重要

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，只要类是

Hyperlane is a lightweight and high-performance Rust HTTP server library designed to simplify networ

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 处理 代价：可能有额外