面试专题

iOS 应用启动分为冷启动、热启动和预热启动三种类型。冷启动是最完整的流程，分为 Pre-main 阶段 和 main 阶段。

Pre-main 阶段：

Pre-main 阶段由 dyld（动态链接器）负责，从用户点击 App 图标到 main() 执行之前。主线程在内核 fork() 创建进程时同时创建，后续所有 Pre-main 工作都在主线程上执行。

1. 加载可执行文件：内核创建进程，使用 mmap() 将 Mach-O 文件映射到虚拟内存（惰性加载，只有实际访问的页才加载到物理内存）。解析 Mach-O Header（验证 Magic Number、CPU 架构匹配、文件类型识别）和 Load Commands（LC_SEGMENT_64 映射内存并设置权限、LC_LOAD_DYLIB 记录动态库依赖、LC_MAIN 计算入口地址等），最后验证代码签名。

2. 加载动态库（dyld）：dyld 从主程序 Mach-O 的 LC_LOAD_DYLIB 中读取依赖的动态库路径，按搜索规则查找动态库实际位置（优先从共享缓存中查找），使用 mmap() 映射到进程虚拟地址空间，验证代码签名，然后使用深度优先搜索递归加载每个动态库的依赖（每个库只加载一次）。最终按依赖关系构建初始化顺序——被依赖的库先于依赖方（如 Foundation 在 UIKit 之前）。如果 App 使用 Swift，此阶段还会加载 Swift 标准库（iOS 12.2+ 位于系统共享缓存，无需嵌入 App）。

3. Rebase & Bind：由于 ASLR（地址空间布局随机化），App 每次启动的加载地址不同，需要修正指针。Rebase（重定位）修正指向 Mach-O 内部的指针，将编译时地址加上 ASLR 偏移量（slide）；Bind（绑定）修正指向 Mach-O 外部的指针，查找符号表绑定到正确的外部符号地址（如 _objc_msgSend）。

4. ObjC Runtime 初始化：dyld 通过 _dyld_objc_notify_register 回调通知 Runtime，触发 _objc_init（map_images 回调）。从 Mach-O 的 __DATA 系列段（__DATA、__DATA_CONST、__DATA_DIRTY）读取类列表（__objc_classlist）、Category 列表（__objc_catlist）、协议列表等元数据；遍历 __objc_classlist 将所有类注册到全局类表（gdb_objc_realized_classes）；然后对非懒加载类（实现了 +load 方法的类）立即 realize——调用 realizeClassWithoutSwift 创建可读写的 class_rw_t 结构（编译期的 class_ro_t 是只读的），建立继承链（cls->superclass）和元类关系（cls->isa），初始化方法缓存 cache_t；懒加载类则延迟到首次收到消息时才 realize（objc_msgSend → lookUpImpOrForward 触发），执行相同的初始化流程。遍历 __objc_catlist 处理 Category：若对应类已 realize，立即将 Category 的方法、属性、协议附加到其 class_rw_t 上（方法插入到列表前面，实现"覆盖"效果）；若对应类尚未 realize，则暂存到 unattachedCategories 表，待类 realize 时再附加。

5. Swift Runtime 元数据注册：ObjC Runtime 完成后，dyld 触发 Swift Runtime 之前通过 _dyld_register_func_for_add_image 注册的回调，遍历所有已加载镜像中的 Swift section，将元数据记录的位置指针注册到 Runtime 的全局缓存中：__swift5_types（类型元数据）、__swift5_proto（协议遵循表）、__swift5_fieldmd（字段描述符）等。此阶段只做轻量的指针注册，并不解析和实例化元数据；真正的解析延迟到首次使用时（如首次 as? 触发协议遵循查找、首次 Mirror(reflecting:) 触发字段描述符解析、泛型类型首次实例化时创建完整的 type metadata）。

6. 调用 +load 方法：dyld 调用 Runtime 的 load_images 回调，通过函数指针直接调用（不经过 objc_msgSend），因此 Category 的 +load 不会覆盖主类的 +load，两者都会执行。调用顺序：父类优先于子类 → 类优先于 Category → 同一镜像内按编译顺序（Build Phases → Compile Sources）→ 不同镜像按依赖顺序（被依赖的库先执行）。所有 +load 在主线程串行调用，直接阻塞启动。

7. 执行 Initializers：dyld 遍历所有已加载镜像的 __DATA,__mod_init_func section 中的函数指针并调用。来源包括 C++ 静态构造函数（如 static std::string s = "hello"）和 __attribute__((constructor)) 标记的函数。执行顺序：按镜像依赖顺序（被依赖的库优先），同一镜像内按 带优先级的 constructor（数字小的先执行）→ C++ 构造函数 → 不带优先级的 constructor。

main 阶段：

1. main 函数：OC 中 main() 调用 UIApplicationMain（需手动创建 @autoreleasepool，因为此时 RunLoop 尚未启动）；Swift 中 @main 属性让编译器自动生成入口。

2. UIApplicationMain：创建 UIApplication 单例 → 创建 AppDelegate → 加载 Info.plist → 设置并启动主 RunLoop（调用 CFRunLoopRun() 进入主事件循环，通常长期运行、不主动返回）。注意：主 RunLoop 采用懒加载机制，首次调用 [NSRunLoop mainRunLoop] 时创建，在 UIApplicationMain 内部启动。

3. AppDelegate 回调（RunLoop 事件循环中）：加载 Main Storyboard → willFinishLaunchingWithOptions: → 状态恢复 → didFinishLaunchingWithOptions:

4. 首帧渲染（RunLoop 事件循环中）：创建 Window → 设置 rootViewController → viewDidLoad → viewWillAppear → layoutSubviews → drawRect → Core Animation 提交图层树 → Render Server 渲染 → GPU 合成 → 显示首帧

预热启动（iOS 15+）：

系统预测用户可能启动 App，提前在后台执行部分启动流程：

预热阶段已完成：加载可执行文件、加载动态库、Rebase & Bind、ObjC 类注册和 Category 处理、Swift Runtime 元数据注册

预热阶段未执行：+load 方法、Initializers（C++ 构造函数、__attribute__((constructor))）、main 阶段全部内容

可通过 ProcessInfo.processInfo.environment["ActivePrewarm"] == "1" 检测是否为预热启动，避免将后台预热时间计入用户感知的启动耗时。

→ App启动流程

测量方案对比：

实际工程中，通常结合使用：开发阶段用 Instruments 深度分析；线上用代码埋点 + MetricKit 双保险。

代码埋点方案：冷启动分为 Pre-main 和 main 两个阶段，需要在关键节点插入埋点：

Pre-main 阶段埋点：

main 阶段埋点：

为确保埋点的 +load 方法最先执行，推荐将埋点代码打包成动态 xcframework，在 Link Binary With Libraries 中排到最前面。动态库的 +load 天然先于静态库和主工程执行。

iOS 15+ 预热启动对统计的影响：预热启动时系统会提前创建进程并执行部分启动流程（dylib 加载、Rebase/Bind、Runtime 初始化），然后挂起等待用户点击。此时 sysctl 获取的 p_starttime 是预热时的时间，可能比用户实际点击早几小时，导致统计的启动时间异常偏大。处理方案：

1. 检测预热启动：在 +load 中检查环境变量 [NSProcessInfo.processInfo.environment[@"ActivePrewarm"] isEqualToString:@"1"]
2. 调整起点时间：预热启动时，以 +load 执行时间作为启动起点，而非进程创建时间
3. 分开统计：区分预热启动和正常启动的数据，避免数据污染

→ 启动优化-观测

一、Pre-main 阶段优化

Pre-main 阶段的优化核心思想是减少 dyld 需要处理的工作量。

1. 减少动态库数量

动态库每增加一个，dyld 就需要多执行一次 mmap 映射、代码签名验证、Rebase/Bind 和初始化。优化方案：

2. 优化 Rebase/Bind

Rebase 修正指向 Mach-O 内部的指针，Bind 修正指向外部的符号引用。两者的工作量与 Mach-O 中需要修正的指针数量成正比。优化方案：

3. 优化 +load 方法

所有 +load 在主线程串行调用，直接阻塞启动。优化方案：

4. 优化 Initializers

C++ 静态构造函数和 __attribute__((constructor)) 也在主线程同步执行。优化方案：

5. 二进制重排

App 的 Mach-O 会先通过 mmap() 映射到进程的虚拟地址空间，这一步不代表所有代码页都已经进入物理内存。启动过程中真正执行到某个函数时，如果该函数所在的代码页还没有驻留在物理内存中，就会触发 Page Fault（缺页中断），内核再从 App 二进制文件中读取该页内容并填充到物理页。

如果启动阶段调用的函数分散在不同的代码页中，冷启动时就可能产生较多 Page Fault。二进制重排将启动阶段调用的函数集中排列到相邻的代码页中，减少需要按需调入物理内存的离散代码页数量。

实现步骤：

1. 插桩收集：使用 Clang SanitizerCoverage（-fsanitize-coverage=func,trace-pc-guard）在每个函数入口插入回调
2. 生成 Order File：运行 App 收集启动阶段的函数调用顺序，生成函数排列文件
3. 链接器重排：通过 Xcode 的 Order File 配置项指定文件路径，链接器按照指定顺序排列函数
4. 验证效果：通过 Instruments 的 System Trace 观察 Page Fault 数量的变化

二、main 阶段优化

main 阶段从 main() 函数开始到首帧渲染完成，是开发者最能直接控制的阶段，通常也是优化的重点。

1. 启动任务分级管理

将 didFinishLaunching 中的初始化任务按优先级分级，而非全部同步执行：

2. 并行初始化

利用 GCD 并发队列将无依赖关系的初始化任务并行执行，充分利用多核 CPU。但需注意：涉及 UI 操作的初始化必须在主线程执行。

3. 利用 RunLoop 空闲时机

在 kCFRunLoopBeforeWaiting 时注册 Observer，将低优先级任务拆分为多个小任务，在 RunLoop 每次空闲时执行一批。这样既不阻塞启动，也不影响用户交互。

4. 延迟加载

→ 启动优化

1. 调用时机

• +load：在main函数执行之前，由dyld在加载Mach-O镜像时自动调用。只要类被编译进项目，无论是否被使用，+load都会被执行。
• +initialize：在类第一次收到消息时调用（懒加载）。如果一个类从未被使用过，它的+initialize永远不会被执行。

2. 调用方式

• +load：Runtime通过函数指针直接调用，不经过objc_msgSend消息发送机制。这意味着不会触发消息转发流程。
• +initialize：通过objc_msgSend调用，遵循完整的消息发送机制，包括方法查找、消息转发等。

3. Category行为

• +load：主类和所有Category的+load方法都会被执行，互不覆盖。
• +initialize：如果Category实现了+initialize，会覆盖主类的实现，只有Category的版本会被调用。

4. 继承行为

• +load：不会因继承关系而调用父类实现。如果子类没有实现+load，就不会调用任何+load。
• +initialize：如果子类没有实现，会调用父类的+initialize，这可能导致父类的实现被多次调用。

5. 对启动性能的影响

• +load：会阻塞App启动，过多的+load方法会显著增加启动时间。
• +initialize：延迟执行，不影响启动性能。

→ +load与+initialize的区别

+load方法的执行顺序遵循以下规则：

1. 父类优先于子类

• 如果存在继承关系，父类的+load一定先于子类执行
• Runtime会确保在调用子类的+load之前，其所有父类的+load都已执行完毕

2. 类优先于Category

• 所有类的+load方法执行完毕后，才会执行Category的+load
• 主类和Category的+load都会被调用，不会相互覆盖

3. 同级别按编译顺序

• 没有继承关系的类之间，按照编译顺序（Compile Sources中的顺序）执行
• 多个Category之间也是按编译顺序执行

4. 不同镜像按依赖关系

• 如果项目依赖多个动态库，会按照镜像的依赖关系顺序调用
• 被依赖的镜像中的+load先执行

→ +load与+initialize的区别

是的。如果子类没有实现+initialize，当子类首次收到消息时，会调用父类的+initialize实现。因此父类的+initialize可能因为不同子类的初始化而被多次调用，需要使用dispatch_once或类型检查来保护。

→ +load与+initialize的区别

应该在+load中执行。原因有三点：

1. +load天然只执行一次：Runtime保证每个类的+load只调用一次，且在串行加锁环境下执行，不需要dispatch_once保护。而+initialize可能因子类继承被多次调用，多次method_exchangeImplementations会导致swizzle失效，必须使用dispatch_once。

2. 线程安全：swizzling操作（class_addMethod + method_exchangeImplementations）不是原子的。+load在loadMethodLock保护下串行执行，天然避免竞争；+initialize可能在多线程环境下被调用，即使dispatch_once保护了入口，内部多步操作之间仍存在竞争窗口。

3. 调用顺序有保证：+load保证父类先于子类执行，对于继承链上的swizzle顺序非常重要。+initialize的调用顺序取决于哪个类先收到消息，不可控。

→ +load与+initialize的区别

不会执行。

// main.swift（手动管理入口时）
UIApplicationMain(
    CommandLine.argc,
    CommandLine.unsafeArgv,
    nil,
    NSStringFromClass(AppDelegate.self)
)

// 这行代码永远不会执行
print("This will never print")

原因：

• UIApplicationMain 创建 UIApplication 单例和 AppDelegate
• 内部调用 CFRunLoopRun() 启动主 RunLoop
• 主 RunLoop 进入无限循环，持续监听和处理事件（触摸、Timer、Source 等）
• 只有当 App 被系统终止时，RunLoop 才会退出，但此时进程已结束

→ App启动流程

loadView负责创建视图控制器的view属性。系统在访问self.view时，如果view为nil，会自动调用loadView。

默认行为：

• 如果有对应的Storyboard/XIB，从中加载视图
• 如果没有，创建一个空的UIView

需要重写的场景：当你想用自定义视图完全替换默认的self.view时：

override func loadView() {
    // 不要调用 super.loadView()
    let customView = MyCustomView()
    self.view = customView
}

注意：重写loadView时不要调用super.loadView()，否则会白白创建一个默认的UIView然后被丢弃。

→ 生命周期

iOS 13之前，modalPresentationStyle默认是.fullScreen，新页面完全覆盖旧页面，旧VC会从视图层级中移除，因此触发viewWillDisappear和viewDidDisappear。

iOS 13之后，默认值变为.automatic（通常表现为.pageSheet），新页面以卡片式呈现，底部仍可见旧页面的一部分，旧VC并未从视图层级移除，所以不会触发Disappear回调。

这会导致的实际问题：如果你在viewWillAppear/viewWillDisappear中做了成对的操作（如注册/注销通知、开始/停止定位），在iOS 13+上可能出现逻辑异常。

解决方案：

• 显式设置 vc.modalPresentationStyle = .fullScreen
• 或使用dismiss的completion回调来替代Disappear中的逻辑

→ 生命周期

layoutSubviews会在视图需要重新布局子视图时被系统调用。它不是立即调用的方法，而是在视图被标记为需要布局后，在后续布局周期中触发。

常见调用时机：

1. 视图第一次显示时：视图加入窗口并参与布局，系统会进行一次布局计算。
2. 当前视图的尺寸发生变化时：例如bounds变化，或frame.size变化。
3. 添加或移除子视图时：例如调用addSubview、removeFromSuperview后，父视图的子视图结构变化，父视图通常会重新布局。
4. 修改约束时：Auto Layout重新计算布局后，相关视图可能触发layoutSubviews。
5. 调用setNeedsLayout时：标记当前视图需要重新布局，在下一个布局周期调用。
6. 调用layoutIfNeeded时：如果当前视图或其子树存在待更新布局，会立即触发布局。
7. 设备旋转、窗口大小变化、Safe Area变化时：外层尺寸变化会导致视图层级重新布局。
8. UIScrollView滚动时：滚动会改变bounds.origin，因此UIScrollView可能频繁触发layoutSubviews。

需要注意的是，layoutSubviews的含义是"当前视图布局自己的子视图"。因此，当执行：

parentView.addSubview(childView)

更直接触发的是parentView的布局，因为父视图的子视图集合发生了变化；childView的layoutSubviews是否调用，取决于它自身是否也需要重新布局，例如它的bounds变化、内部还有子视图需要布局，或被显式调用了setNeedsLayout。

重要注意点：

• 不要直接调用layoutSubviews，应该调用setNeedsLayout（异步）或layoutIfNeeded（同步）
• layoutSubviews可能被调用多次，其中的操作要保证幂等性
• 在layoutSubviews中可以获取到准确的frame值，适合做依赖frame的布局计算

→ 生命周期

RunLoop 是 iOS/macOS 中用于管理线程的事件循环机制。它的核心作用是让线程在有任务时处理任务，没有任务时进入休眠状态，从而避免线程退出并节省 CPU 资源。

→ RunLoop

• 每个线程都有唯一对应的 RunLoop 对象
• 主线程和子线程的 RunLoop 都采用懒加载机制，在第一次获取时才创建
• 主线程的 RunLoop 由 UIApplicationMain 内部首次获取并启动（调用链：UIApplicationMain → GSEventRunModal → CFRunLoopRunSpecific）
• RunLoop 与线程是一一对应的，存储在一个全局字典（__CFRunLoops）中
• RunLoop 在第一次获取时创建，在线程结束时销毁

→ RunLoop

核心作用：实现事件源的隔离与优先级管理。

RunLoop 的 Mode 是一种事件分组机制，每个 Mode 内部包含独立的 Source0、Source1、Timer 和 Observer 集合。RunLoop 同一时刻只能运行在一个 Mode 下，只处理当前 Mode 中注册的事件源，其他 Mode 中的事件源不会被处理。

常见的 Mode：

• kCFRunLoopDefaultMode（NSDefaultRunLoopMode）：默认模式，App 正常运行时使用，处理 Timer、网络回调等常规任务。
• UITrackingRunLoopMode：界面追踪模式，当 UIScrollView 及其子类（UITableView、UICollectionView 等）滑动时，RunLoop 自动切换到此模式，专注处理 UI 追踪事件，保证滑动流畅。
• kCFRunLoopCommonModes（NSRunLoopCommonModes）：并不是真正的 Mode，而是一个标记集合，默认包含 DefaultMode 和 TrackingMode。将事件源添加到 CommonModes，等价于同时添加到所有被标记为 Common 的 Mode 中。
• UIInitializationRunLoopMode：App 启动时使用的模式，启动完成后不再使用。
• GSEventReceiveRunLoopMode：接收系统事件的内部模式（未公开模式，可能随系统版本变化），开发者一般不直接使用。

Mode 切换机制：

切换 Mode 时，RunLoop 需要先退出当前 Mode 的循环，再以新 Mode 重新进入。最典型的场景是 ScrollView 滑动：用户开始滑动时 RunLoop 从 DefaultMode 切换到 TrackingMode，停止滑动后切换回 DefaultMode。

→ RunLoop

严格来说，RunLoop 的运行可以分成外层启动循环和内层事件循环两层：

启动 API（外层）                     内层一次运行
────────────────────────────────────────────────────────
runMode:beforeDate:       ──调用一次──> CFRunLoopRunSpecific
CFRunLoopRun()            ──do-while──> CFRunLoopRunSpecific
[NSRunLoop run]           ──while(1)──> CFRunLoopRunSpecific
[NSRunLoop runUntilDate:] ──while未超时──> CFRunLoopRunSpecific

外层循环由具体启动 API 决定：runMode:beforeDate: 只运行一次；CFRunLoopRun() 会反复调用 CFRunLoopRunSpecific，但外层会检查返回值，所以可以被 CFRunLoopStop() 停止；[NSRunLoop run] 则是无条件 while(1) 反复运行，因此对 [NSRunLoop run] 来说，单纯调用 CFRunLoopStop() 只能停止当前这一轮内层运行，随后外层还会再次进入。

下面的流程图描述的是一次 CFRunLoopRunSpecific 调用内部的事件循环，也就是常说的内层循环：

┌─ CFRunLoopRunSpecific 入口 ──────────────────────────────
│  1. 通知 Observer：即将进入 RunLoop (kCFRunLoopEntry)
│
│  ┌─ __CFRunLoopRun do-while 循环 ─────────────────────
│  │  2. 通知 Observer：即将处理 Timer (kCFRunLoopBeforeTimers)
│  │  3. 通知 Observer：即将处理 Source0 (kCFRunLoopBeforeSources)
│  │  4. 处理 Blocks + 处理 Source0 事件（+ 如果有 Source0 被处理，再执行一次 Blocks）
│  │  5. 如果有 GCD 主队列消息就绪，跳转到步骤 9
│  │  6. 通知 Observer：即将进入休眠 (kCFRunLoopBeforeWaiting)
│  │  7. 线程休眠（mach_msg），等待被唤醒：
│  │     - Source1 (port-based)
│  │     - Timer 到时
│  │     - RunLoop 超时
│  │     - 被外部手动唤醒
│  │  8. 通知 Observer：从休眠中唤醒 (kCFRunLoopAfterWaiting)
│  │  9. 处理唤醒时收到的消息：
│  │      - 如果是 Timer 到时，处理 Timer
│  │      - 如果是 dispatch_async 到主队列，执行 block
│  │      - 如果是 Source1，处理 Source1
│  │  10. 处理 Blocks（步骤 9 中的回调可能通过 CFRunLoopPerformBlock 提交了新 block）
│  │  11. 根据条件判断：继续循环 → 回到步骤 2 / 退出循环 → 步骤 12
│  └──────────────────────────────────────────────────────
│
│  12. 通知 Observer：即将退出 RunLoop (kCFRunLoopExit)
└──────────────────────────────────────────────────────────

步骤 1：进入 RunLoop

CFRunLoopRunSpecific 函数首先通知 Observer kCFRunLoopEntry，表示 RunLoop 即将开始运行。AutoreleasePool 就是在这个时机创建的。随后进入 __CFRunLoopRun 的 do-while 循环。

步骤 2-3：循环开始，通知 Observer

每次循环开始时，依次通知 Observer kCFRunLoopBeforeTimers 和 kCFRunLoopBeforeSources，给外部一个在事件处理前做准备工作的机会。

步骤 4-5：处理 Blocks、Source0 与就绪检查

步骤 4 包含三个子步骤：先调用 __CFRunLoopDoBlocks 处理通过 CFRunLoopPerformBlock 提交的 block，然后调用 __CFRunLoopDoSources0 处理被标记为待处理的 Source0 事件，如果处理了 Source0 则再次调用 __CFRunLoopDoBlocks（因为 Source0 回调中可能又提交了新 block）。

步骤 5 中，RunLoop 快速探测 GCD 主队列的 mach port（dispatchPort）上是否有已到达但尚未处理的消息（超时为 0 的非阻塞检查）。如果有，跳过休眠直接跳到步骤 9 处理。

步骤 6-7：休眠阶段

在真正休眠之前，RunLoop 先通知 Observer kCFRunLoopBeforeWaiting。系统在这个时机做了三件重要的事：

1. 手势识别的回调：触摸事件被 Source1 接收后，UIGestureRecognizer 不会立即执行 action，而是等到 kCFRunLoopBeforeWaiting 时，由系统 Observer 统一触发 _UIGestureRecognizerUpdate，批量处理所有手势识别器的状态更新和 action 回调。

2. UIView/CALayer 的界面更新：setNeedsLayout、setNeedsDisplay 等只是标记"需要更新"。在 kCFRunLoopBeforeWaiting 时，Core Animation 的 Observer 统一执行布局（layoutSubviews）、绘制（drawRect:）和约束更新，通过 CATransaction 提交渲染事务给 Render Server。

3. AutoreleasePool 的释放与重建：释放旧池并创建新池，释放本轮循环中产生的 autorelease 对象。

随后，RunLoop 调用 mach_msg() 让线程进入内核态休眠，等待 Source1/Timer/超时/手动唤醒。

步骤 8-10：唤醒处理阶段

线程被唤醒后，先通知 Observer kCFRunLoopAfterWaiting，然后根据唤醒原因处理对应的事件：

• Timer：调用 __CFRunLoopDoTimers() 执行到期的 Timer 回调
• GCD 主队列：调用 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 执行 block
• Source1：调用 __CFRunLoopDoSource1() 处理（如触摸事件由 Source1 接收 IOKit 事件后分发）

步骤 10 再次调用 __CFRunLoopDoBlocks 处理步骤 9 中可能新提交的 block。

步骤 11-12：循环判断与退出

RunLoop 检查以下退出条件：

• 当前 Mode 是否为空（没有 Source/Timer/Observer）
• 是否超过了指定的运行时间
• 是否被 CFRunLoopStop() 停止
• stopAfterHandle 是否为 true 且已处理了事件（runMode:beforeDate: 模式）

不满足退出条件则回到步骤 2；满足则跳出 do-while，由 CFRunLoopRunSpecific 通知 Observer kCFRunLoopExit 后结束。

→ RunLoop

1. NSTimer 在滑动时失效问题

当 ScrollView 滑动时，RunLoop 从 NSDefaultRunLoopMode 切换到 UITrackingRunLoopMode，导致添加在 DefaultMode 下的 Timer 不被触发。有两种解决方案：

• 将 Timer 添加到 NSRunLoopCommonModes，使其同时在 DefaultMode 和 TrackingMode 下生效
• 使用 GCD Timer（dispatch_source_t），它不依赖 RunLoop Mode，不受模式切换影响

2. 子线程保活

子线程默认执行完任务就退出。通过给子线程的 RunLoop 添加事件源（如 Port）并启动 RunLoop，可以让线程持续存活等待任务。关键点：

• 必须向 RunLoop 添加 Source（如 NSPort），否则 CFRunLoopRunSpecific 入口的 __CFRunLoopModeIsEmpty 检查会直接返回，RunLoop 根本不会启动
• 不要使用 [NSRunLoop run]，它的外层 while(1) 无条件循环，无法被 CFRunLoopStop() 停止
• CFRunLoopRun() 也可以保活，并且能被 CFRunLoopStop() 停止，但它默认运行 DefaultMode，外层退出条件不如自定义循环灵活
• 应使用 while + runMode:beforeDate: 的可控循环方式，配合标志位来控制退出（Apple 官方文档推荐做法）

__weak typeof(self) weakSelf = self;
_thread = [[NSThread alloc] initWithBlock:^{
    [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
    while (weakSelf && !weakSelf->_stopped) {
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    }
}];
[_thread start];

3. 卡顿监控

利用 RunLoop Observer 监控主线程的运行状态。原理是：在子线程中用信号量等待主线程 RunLoop 的状态变化通知，如果等待超时（比如超过 50ms），且主线程处于 kCFRunLoopBeforeSources 或 kCFRunLoopAfterWaiting 状态，说明主线程在处理事件或刚唤醒后被阻塞，此时可以抓取堆栈进行分析。需要注意简单方案存在 kCFRunLoopBeforeWaiting 阶段的监控盲区，详见 卡顿-检测。

// 创建 Observer 监听所有状态变化
CFRunLoopObserverRef observer = CFRunLoopObserverCreate(
    kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, &runLoopObserverCallback, &context);
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

// Observer 回调中记录状态并发送信号
static void runLoopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    monitor->_activity = activity;
    dispatch_semaphore_signal(monitor->_semaphore);
}

// 子线程中等待信号量，超时即判定为卡顿
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    while (YES) {
        long result = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50 * NSEC_PER_MSEC));
        if (result != 0) {
            if (activity == kCFRunLoopBeforeSources || activity == kCFRunLoopAfterWaiting) {
                // 检测到卡顿，记录堆栈
            }
        }
    }
});

4. 利用 RunLoop 空闲时执行低优先级任务

在 RunLoop 即将进入休眠时（kCFRunLoopBeforeWaiting），注册 Observer 来执行不紧急的任务，如图片预加载、数据预处理、日志上报、缓存清理等。这样做的优势是不影响用户交互（只在空闲时执行），可以通过控制每次执行的任务数量来平衡性能。

CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(
    kCFAllocatorDefault, kCFRunLoopBeforeWaiting, YES, 0,
    ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
        // 每次 RunLoop 空闲时，从任务队列取出有限数量的任务执行
        NSUInteger count = MIN(maxTasksPerRound, tasks.count);
        for (NSUInteger i = 0; i < count; i++) {
            void(^task)(void) = tasks.firstObject;
            [tasks removeObjectAtIndex:0];
            task();
        }
    });
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

→ RunLoop

1. 循环引用：NSTimer/CADisplayLink 使用 target-action 模式会强引用 target，如果 target 又持有 timer 就形成循环引用，导致双方都无法释放。解决方案有三种：使用 Block API（iOS 10+）配合 weak-strong dance；使用 NSProxy 中间层弱引用 target 来打破引用环；或者改用基于 block 的 GCD Timer

2. RunLoop Mode 切换：NSTimer/CADisplayLink 依赖 RunLoop 驱动。当 ScrollView 滑动时，主线程 RunLoop 会从 kCFRunLoopDefaultMode 切换到 UITrackingRunLoopMode，添加在 DefaultMode 下的定时器就不会触发。解决方案是将 Timer 添加到 NSRunLoopCommonModes（同时覆盖 Default 和 Tracking 两个 Mode），或使用不依赖 RunLoop 的 GCD Timer

3. 子线程 RunLoop：子线程的 RunLoop 默认不启动，直接在子线程创建 NSTimer 不会触发。需要先把 Timer/Port 等事件源加入当前线程 RunLoop，再启动 RunLoop。CFRunLoopRun() 可以保活并能被 CFRunLoopStop() 停止，但默认运行 DefaultMode；更推荐使用 runMode:beforeDate: 配合条件判断来实现可控退出。不要直接使用 [[NSRunLoop currentRunLoop] run] 做可停止的保活方案，因为它的外层循环几乎无法退出。GCD Timer 不依赖 RunLoop，无此问题

4. 精度：NSTimer/CADisplayLink 的精度受 RunLoop 繁忙程度影响，主线程有耗时任务时回调会被延迟。NSTimer 支持设置 tolerance 属性，系统会据此合并多个 Timer 的触发时机以节省电量。GCD Timer 不依赖 RunLoop，精度最高，可以通过 leeway 参数精确控制允许的误差

5. 正确销毁：Timer 被添加到 RunLoop 后，RunLoop 会强引用 Timer，即使使用 Block API 打破了 timer 对 self 的强引用，timer 本身仍被 RunLoop 持有不会释放，Block API 的真正优势是让 self 能正常 dealloc，从而有机会在 dealloc 中调用 invalidate 来停止 timer。NSTimer/CADisplayLink 必须调用 invalidate 才能从 RunLoop 中移除并释放，且必须在 timer 所注册的 RunLoop 所在线程调用。GCD Timer 使用 dispatch_source_cancel 取消，但需注意不能对 suspended 状态的 dispatch_source_t 直接释放，否则会触发 EXC_BAD_INSTRUCTION 崩溃，需先 resume 再 cancel

→ Timer的注意事项

KVC（Key-Value Coding）是 Apple 通过 NSKeyValueCoding 协议提供的一种机制，允许通过字符串 key 间接访问对象属性，而不需要在编译期知道属性名。NSObject 默认遵循该协议，底层依赖 ObjC Runtime 的方法查找和实例变量访问能力。

setValue:forKey: 的查找流程：

以 [obj setValue:@"Tom" forKey:@"name"] 为例：

1. 查找 setter 方法：Runtime 按 setName: → _setName: 顺序查找 setter 方法，找到任意一个就通过 objc_msgSend 调用并结束
2. 检查是否允许直接访问实例变量：若没有找到 setter，调用类方法 +accessInstanceVariablesDirectly，默认返回 YES。若重写为 NO，直接进入步骤 4
3. 查找实例变量：按 _name → _isName → name → isName 顺序查找实例变量，找到则通过 object_setIvar 直接赋值
4. 异常处理：若以上步骤都未找到，调用 setValue:forUndefinedKey:，默认实现抛出 NSUndefinedKeyException

额外说明：对基本类型（int、float、BOOL 等）属性调用 setValue:nil forKey: 时，会触发 setNilValueForKey:，默认抛出 NSInvalidArgumentException。可以重写此方法设置默认值来避免崩溃。

valueForKey: 的查找流程：

以 [obj valueForKey:@"name"] 为例：

1. 查找 getter 方法：按 getName → name → isName → _name 顺序查找 getter 方法，找到则通过 objc_msgSend 调用。如果返回值是基本类型，会自动包装为 NSNumber 或 NSValue
2. 查找集合类代理方法：若没有找到 getter，检查是否实现了集合类代理方法。NSArray 模式需要同时实现 countOfName + objectInNameAtIndex:；NSSet 模式需要同时实现 countOfName + enumeratorOfName + memberOfName:。满足条件则返回对应的集合代理对象（NSKeyValueArray 或 NSKeyValueSet）
3. 检查是否允许直接访问实例变量：调用 +accessInstanceVariablesDirectly，若返回 NO 则直接进入步骤 5
4. 查找实例变量：按 _name → _isName → name → isName 顺序查找实例变量，找到则返回其值
5. 异常处理：若以上步骤都未找到，调用 valueForUndefinedKey:，默认实现抛出 NSUndefinedKeyException

Swift 中的差异：

Swift 中继承 NSObject 且属性标记为 @objc dynamic 的走同样的 ObjC Runtime 流程。而 Swift 原生的 KeyPath（如 \Person.name）是完全不同的机制——编译期类型安全，通过编译器生成的偏移量直接读写内存，不经过字符串解析和方法查找，性能更好但失去了运行时动态性。

→ KVC底层原理

KVO 的底层实现基于 isa-swizzling 机制。

1. 动态创建子类

当对某个对象调用 addObserver:forKeyPath:options:context: 时，Runtime 会检查是否已存在 NSKVONotifying_ClassName 子类，不存在则通过 objc_allocateClassPair 动态创建，并通过 objc_registerClassPair 注册。随后将对象的 isa 指针指向这个新的子类。

添加观察前：instance.isa → ClassName
添加观察后：instance.isa → NSKVONotifying_ClassName → ClassName（superclass）

2. 重写 setter 方法

动态子类会重写被观察属性的 setter 方法，将 setter 的 IMP 替换为 Foundation 内部的 _NSSetXXXValueAndNotify 系列函数。Foundation 根据属性类型选择对应的函数，例如对象类型用 _NSSetObjectValueAndNotify，int 用 _NSSetIntValueAndNotify 等。重写后的 setter 执行逻辑如下：

- (void)setName:(NSString *)name {
    [self willChangeValueForKey:@"name"];
    [super setName:name];  // 调用原始 setter
    [self didChangeValueForKey:@"name"];
}

3. 观察者的存储与通知

观察者信息存储在被观察对象的 observationInfo 属性中（声明在 NSObject 上）。它指向 Foundation 内部的 NSKeyValueObservationInfo 对象，其中维护了一组 NSKeyValueObservance 记录，每条记录包含 observer、keyPath、options、context。每次 addObserver: 时添加记录，removeObserver: 时移除记录。当 didChangeValueForKey: 被调用时，从 observationInfo 中找到该 keyPath 的所有观察记录，逐一调用观察者的 observeValueForKeyPath:ofObject:change:context: 完成通知。

4. 重写辅助方法

• 重写 class 方法：返回原始父类而非 NSKVONotifying_ 前缀的子类，对外隐藏 KVO 实现细节。因此 [person class] 返回 Person，但 object_getClass(person) 能获取到真实的 NSKVONotifying_Person
• 重写 dealloc：在对象销毁时执行 KVO 相关的清理工作
• 重写 _isKVOA：返回 YES，供 Runtime 内部判断这是 KVO 动态生成的类

补充要点：

• 直接修改实例变量（person->_name = @"Tom"）不会触发 KVO，因为绕过了 setter。但通过 KVC 的 setValue:forKey: 修改即使没有 setter 也会触发，因为 KVC 内部会自动调用 willChangeValueForKey: 和 didChangeValueForKey:
• 可以通过重写 automaticallyNotifiesObserversForKey: 返回 NO 来关闭自动 KVO，改为手动调用 willChangeValueForKey: / didChangeValueForKey: 控制通知时机，典型场景如合并多次变更为一次通知、添加条件判断只在值真正变化时才通知
• 集合类型属性（NSArray、NSSet 等）直接操作不会触发 KVO，需要通过NSObject上声明的 mutableArrayValueForKey: 等代理方法操作，代理方法会自动包裹 willChange:valuesAtIndexes:forKey: 和 didChange:valuesAtIndexes:forKey: 来触发通知

→ KVO底层原理

Block 本质是 OC 对象，不是普通函数指针。更准确地说，Block 是一个带有 isa 的 C 结构体对象，结构体内部保存了一个函数指针 FuncPtr，同时还保存了捕获的上下文变量。也就是说，Block 是"对象形式包装的函数指针 + 上下文"。

底层结构：

Block 在编译期会被转换成两个层次：

// 所有 Block 共有的对象头
struct __block_impl {
    void *isa;         // 指向具体 Block 类，说明 Block 是 OC 对象
    int Flags;
    int Reserved;
    void *FuncPtr;     // 指向 Block 代码体对应的 C 函数
};

// 某一个具体 Block 表达式生成的完整结构体
struct __main_block_impl_0 {
    struct __block_impl impl;         // 通用对象头
    struct __main_block_desc_0 *Desc; // Block 大小、copy/dispose 等描述信息
    int a;                            // 当前 Block 捕获的变量
};

例如：

int a = 10;
void (^block)(void) = ^{
    NSLog(@"%d", a);
};

编译后大致会变成：

static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
    int a = __cself->a;
    NSLog(@"%d", a);
}

调用 block() 时，实际是取出结构体中的 FuncPtr 并调用，同时把 Block 自身作为第一个参数传进去，所以函数内部可以通过 __cself 访问捕获变量。

Block 作为对象的继承链大致为：

__NSGlobalBlock__ / __NSStackBlock__ / __NSMallocBlock__
    → __NSGlobalBlock / __NSStackBlock / __NSMallocBlock
    → NSBlock
    → NSObject

因此 Block 可以响应 copy、class、description 等对象消息。

三种 Block 类型：

示例：

// 1. Global Block：不捕获局部自动变量
void (^b1)(void) = ^{
    NSLog(@"global");
}; // __NSGlobalBlock__

// 访问全局变量或 static 变量仍然通常是 Global Block
static int s = 10;
void (^b2)(void) = ^{
    NSLog(@"%d", s);
}; // __NSGlobalBlock__

// 2. Stack Block：捕获局部自动变量且未 copy
int a = 10;
NSLog(@"%@", [^{ NSLog(@"%d", a); } class]); // MRC 下常见为 __NSStackBlock__

// 3. Malloc Block：Stack Block 被 copy 到堆上
void (^b3)(void) = ^{
    NSLog(@"%d", a);
}; // ARC 下通常自动 copy 为 __NSMallocBlock__

在 ARC 下，Stack Block 很少直接暴露出来，因为编译器会在很多场景自动插入 copy，例如赋值给 __strong Block 变量或 copy 属性、Block 作为返回值、传给 GCD API、传给 Cocoa 中 usingBlock 风格的 API 等。Block 属性通常声明为 copy，本质目的就是把可能位于栈上的 Block 移到堆上，延长生命周期。

变量捕获规则：

局部自动变量是值拷贝：

int a = 10;
void (^block)(void) = ^{
    NSLog(@"%d", a);
};
a = 20;
block(); // 输出 10

因为 a 被拷贝进了 Block 结构体，之后外部 a 再变化，不会影响 Block 内部保存的副本。Block 内部也不能直接写 a = 30，因为修改副本对外部变量没有意义，编译器直接禁止这种语义。

static 局部变量捕获的是地址：

static int count = 0;
void (^block)(void) = ^{
    count++;
};

底层相当于 Block 结构体里保存 int *count，执行时通过指针修改同一份数据。

全局变量和静态全局变量通常不作为成员捕获，因为它们的地址本来就是全局可访问的，Block 执行函数里直接访问即可。

对象变量捕获：

对象类型变量捕获的是"对象指针的值"，但 Block copy 到堆上时还要处理引用关系：

NSMutableArray *array = [NSMutableArray array];
void (^block)(void) = ^{
    [array addObject:@"hello"]; // 可以修改对象内容
    // array = nil;             // 不能修改指针指向，除非 array 用 __block 修饰
};

如果捕获的是默认 __strong 对象，堆 Block 会强持有该对象；如果捕获的是 __weak 对象，Block 内部保存弱引用；如果是 __unsafe_unretained，则只保存裸指针。编译器会在 Block 描述信息中生成 copy / dispose 辅助函数，在 copy 时调用 _Block_object_assign，释放时调用 _Block_object_dispose。

__block 的底层原理：

__block 不是简单地让变量"按引用捕获"，而是把变量包装成一个 __Block_byref 结构体：

struct __Block_byref_a_0 {
    void *__isa;
    struct __Block_byref_a_0 *__forwarding;
    int __flags;
    int __size;
    int a;
};

初始时，__forwarding 指向栈上的自己：

栈上 byref 结构体
┌──────────────────────┐
│ __forwarding ──┐     │
│ a = 10         │     │
└────────────────┼─────┘
                 └──→ 自己

当捕获它的 Block 从栈 copy 到堆时，__block 变量对应的 byref 结构体也会被 copy 到堆上，并发生转发：

栈上 byref                         堆上 byref
┌──────────────────────┐          ┌──────────────────────┐
│ __forwarding ─────────────────→ │ __forwarding ──┐     │
│ a = 10（旧）          │          │ a = 10         │     │
└──────────────────────┘          └────────────────┼─────┘
                                                   └──→ 自己

之后无论在 Block 内部还是外部访问 a，都会被编译器转换为通过 a.__forwarding->a 访问。这样即使 Block 已经从栈移动到堆，所有访问仍然会落到堆上的同一份变量，保证读写一致。

__block int a = 10;
void (^block)(void) = ^{
    a = 20;
};
block();
NSLog(@"%d", a); // 20

如果 __block 修饰的是对象变量，ARC 下它默认仍然是强引用；__block 只解决"能否修改变量指针指向"的问题。

→ Block底层原理

Mach-O文件由三部分组成：

┌──────────────────────────┐
│           Header         │  ← 文件的"身份证"
├──────────────────────────┤
│       Load Commands      │  ← 文件的"目录"
├──────────────────────────┤
│            Data          │  ← 实际的代码和数据
└──────────────────────────┘

• Header（头部）：描述文件的基本信息，包括魔数（标识文件格式）、CPU类型、文件类型（可执行文件、动态库等）、Load Commands的数量等

• Load Commands（加载命令）：描述文件的布局和依赖关系，常见的Load Commands包括：

  • LC_SEGMENT_64：定义Segment的位置、大小和权限（如__TEXT、__DATA）
  • LC_LOAD_DYLIB：声明依赖的动态库（如Foundation、UIKit）
  • LC_SYMTAB：符号表的位置和大小
  • LC_DYSYMTAB：动态符号表信息
  • LC_MAIN：程序入口点（main函数地址）
  • LC_CODE_SIGNATURE：代码签名信息的位置

• Data（数据区）：实际存储代码和数据，按Segment和Section两级结构组织：

  • Segment（段）：内存映射的基本单位，定义内存保护属性（可读/可写/可执行）
  • Section（节）：数据组织的逻辑单位，同一Segment内的多个Section共享内存属性

  常见的Segment及其包含的Section：

  Segment	权限	包含的Section
  __PAGEZERO	不可访问	无（位于地址0x0起始的保护区域，任何对NULL指针的解引用都会访问到此区域，立即触发EXC_BAD_ACCESS崩溃）
  __TEXT	可读、可执行	__text（机器码）、__stubs（桩代码）、__cstring（C字符串）、__const（常量数据）、__objc_methname（ObjC方法名）、__swift5_typeref（Swift类型引用）
  __DATA_CONST	可读写→只读	__got（非延迟绑定指针）、__const（运行时常量）、__objc_classlist（ObjC类列表）、__swift5_proto（Swift协议描述符）
  __DATA	可读、可写	__data（已初始化全局变量）、__bss（未初始化全局变量）、__swift5_types（Swift类型元数据）、__la_symbol_ptr（延迟绑定指针）
  __DATA_DIRTY	可读、可写	运行时一定会修改的数据（单独分页以优化COW）
  __LINKEDIT	可读	符号表、字符串表、代码签名等链接信息

  注：__DATA_CONST和__DATA_DIRTY是iOS 13+对__DATA的细分优化，__DATA_CONST在启动完成后变为只读，可被多进程共享。

→ Mach-O的链接、装载与库

Segment（段）和Section（节）是Mach-O中组织数据的两级结构：

关系说明：

• Segment是Section的容器：一个Segment可以包含多个Section
• Segment是内存映射的基本单位：定义内存保护属性（可读/可写/可执行），页对齐（通常16KB）
• Section是数据组织的逻辑单位：同一Segment内的多个Section共享内存属性，存放特定类型的数据

示例：__TEXT Segment（可读、可执行）
├── __text Section      ← 编译后的机器码
├── __stubs Section     ← 动态库调用桩
├── __cstring Section   ← C字符串常量
└── __const Section     ← 常量数据

所有这些Section都继承__TEXT的权限：可读、可执行、不可写

→ Mach-O的链接、装载与库

iOS的代码签名机制要求所有可执行代码必须经过签名验证。App只能加载：

• 系统动态库（已由Apple签名）
• 嵌入App Bundle中的动态库（与App一起签名）

→ Mach-O的链接、装载与库

通常Bind开销更大：

• Rebase只需简单的加法运算（地址 + slide）
• Bind需要查找符号表，进行字符串比较

→ Mach-O的链接、装载与库

ObjC和Swift使用不同的符号命名规则（Name Mangling），主要区别如下：

符号示例对比：

Objective-C:
  +[MyClass doSomething]  →  +[MyClass doSomething]
  -[MyClass doSomething]  →  -[MyClass doSomething]
  类符号                   →  _OBJC_CLASS_$_MyClass

Swift:
  func foo()              →  $s4Main3fooyyF
  MyModule.MyClass        →  $s8MyModule7MyClassC...

ObjC的类名冲突问题：

由于ObjC符号不包含模块信息，不同库中的同名类会产生符号冲突：

• 静态链接时：链接器报错 duplicate symbol '_OBJC_CLASS_$_MyClass'
• 运行时（动态库）：ObjC Runtime注册类时发现同名，行为未定义

这就是为什么ObjC社区有类名前缀约定（NSObject、UIView、AFHTTPClient等）。

Swift符号的解析：

可以使用swift-demangle工具解析Swift符号：

$ swift demangle '$s4Main3fooyyF'
$s4Main3fooyyF ---> Main.foo() -> ()

$ swift demangle '$s4Main6PersonC4name3ageSSSi_tcfc'
... ---> Main.Person.init(name: String, age: Int)

→ Mach-O的链接、装载与库

XCFramework是Apple在Xcode 11引入的新格式，主要解决了传统Fat Framework的以下问题：

XCFramework的目录结构示例：

MyFramework.xcframework/
├── Info.plist                          # 描述所有变体的元信息
├── ios-arm64/                          # iOS真机
│   └── MyFramework.framework/
├── ios-arm64_x86_64-simulator/         # iOS模拟器（支持Intel和Apple Silicon Mac）
│   └── MyFramework.framework/
└── macos-arm64_x86_64/                 # macOS
    └── MyFramework.framework/

→ Mach-O的链接、装载与库

CocoaPods支持多种链接配置，主要通过Podfile中的选项控制：

→ Mach-O的链接、装载与库

→ Mach-O的链接、装载与库

mmap的核心优势：

1. 零拷贝（Zero-Copy）

   • 传统IO：磁盘 → 内核缓冲区 → 用户缓冲区（2次拷贝）
   • mmap：磁盘 ↔ 映射区域（直接访问，0次拷贝）
   • 减少CPU开销和内存占用

2. 按需加载（Lazy Loading）

   • 映射时不会立即加载整个文件
   • 只有访问到的页面才触发缺页中断，从磁盘加载
   • 适合处理大文件，内存占用与访问量成正比

3. 简化编程模型

   • 像操作内存一样操作文件
   • 无需管理缓冲区、处理分块读取
   • 随机访问无需seek

4. 多进程共享

   • MAP_SHARED映射的内存可被多个进程共享
   • iOS中主要用于App与Extension（Widget、Share Extension等）之间的数据共享

5. 崩溃上下文恢复

   • 预映射 ring buffer 适合记录崩溃前的 breadcrumbs、页面路径、网络摘要等轻量现场
   • 进程崩溃后，已写入映射页通常比用户态缓冲区更容易恢复
   • 但 mmap 不保证绝对持久化，完整 Crash Report 仍建议写独立文件

适用场景：

不适用场景：

→ mmap详解

可以。mmap只是建立虚拟地址映射，物理内存按需分配。只有访问到的页面才会加载到物理内存，系统会自动换出不常用的页面。

→ mmap详解

映射仍然有效。文件被删除后，映射区域仍可访问，数据保存在内存中，munmap后数据丢失，这是Unix文件系统的特性（引用计数）。

→ mmap详解

isa是NSObject底层结构体objc_object的第一个成员，是每个Objective-C对象与其类之间的连接。它指向对象所属的类对象（Class），类对象中包含了对象的元数据（方法列表、属性列表、协议列表等）。类对象同样有isa，类对象的isa则指向其对应的元类对象（Meta-Class），用于查找类方法。

isa是Objective-C动态消息派发的基石——当调用一个方法（如[obj doSomething]）时，运行时并不是直接跳转到函数地址，而是先通过对象的isa找到其所属的类对象，再在类对象的方法列表中查找对应的方法实现；找不到则沿superclass继承链向上回溯。没有isa，运行时就无从知道对象属于哪个类，也就无法完成任何方法查找，因此它是整个动态派发体系的起点和基础。

在传统的32位系统中，isa是一个普通的Class指针，直接指向对象所属的类对象。在64位系统上，苹果引入了Non-Pointer isa优化方案，将isa从一个单纯的指针改为联合体isa_t，利用位域技术将64位空间划分为多个字段，在存储类对象指针（shiftcls，33位）的同时，还额外存储了引用计数（extra_rc，19位）、是否有关联对象（has_assoc）、是否被弱引用（weakly_referenced）等元信息。通过这种优化，将原本需要约22~26字节存储的信息压缩到了8字节，对于运行时大量对象的场景，内存节省非常显著。

→ Objective-C底层原理-NSObject

isa链：

• 实例对象的isa指向类对象（查找实例方法）
• 类对象的isa指向元类对象（查找类方法）
• 元类对象的isa指向根元类（NSObject的元类）
• 根元类的isa指向自身，形成闭环

superclass继承链：

• 类对象继承链：SubClass → SuperClass → ... → NSObject → nil
• 元类继承链：SubClass元类 → SuperClass元类 → ... → 根元类 → NSObject类对象 → nil

注意：根元类的superclass指向NSObject类对象而非nil，这使得NSObject的实例方法可以作为类方法调用的兜底。例如调用[NSObject description]时，如果根元类中找不到+description，会沿superclass回溯到NSObject类对象，找到并执行-description。

→ Objective-C底层原理-NSObject

Tagged Pointer 和 Non-Pointer isa 都是苹果在64位系统上针对指针空间的优化，但优化的对象和层次不同：

Non-Pointer isa 优化的是已存在于堆上的对象的 isa 指针。对象仍然通过malloc分配在堆上，只是把 isa 的64位空间拆分为位域，在存储类指针的同时附带引用计数、关联对象标志等元信息。

Tagged Pointer 优化的是小值对象本身。对于NSNumber、短NSString、NSDate等值足够小的对象，直接将类型标签和数据值编码在"指针"的64位空间中，根本不在堆上分配对象。这个"指针"不指向任何内存，它本身就是数据（指针本身在栈上或寄存器中）。

Tagged Pointer 带来的性能收益比 Non-Pointer isa 更显著，因为它完全跳过了堆分配、引用计数管理和释放的全部流程。

Swift 中的对应： Swift 的值类型（Int、Double等）天然是栈分配的，不需要 Tagged Pointer。但在桥接为 OC 对象（如NSNumber）时仍会复用 Tagged Pointer 机制。此外，Swift 的String有自己的小字符串内联优化（15字节以内直接存储在结构体中），思路与 Tagged Pointer 一脉相承。

→ Objective-C底层原理-NSObject

弱引用：不支持。 Tagged Pointer 不是真正的堆对象，没有侧表（SideTable），也永远不会被释放，因此无法在weak_table中注册弱引用关系。运行时在创建弱引用时会通过isTaggedPointerOrNil()检查，如果是 Tagged Pointer 则直接返回原值，不做任何弱引用注册。

retain/release：空操作。 Tagged Pointer 没有引用计数的概念，运行时在执行retain和release时会先判断是否为 Tagged Pointer，如果是则直接返回，不做任何操作。dealloc也永远不会被调用。

这些特判是 Tagged Pointer 性能优势的重要来源——省去了引用计数的原子操作和侧表查找的开销。

→ Objective-C底层原理-NSObject

两者的底层结构体不同，但都以isa开头，这是Objective-C"万物皆对象"的基础。

实例对象的底层结构体是objc_object，内存从低地址到高地址依次是：

1. isa指针（8字节）：指向类对象，用于查找实例方法
2. 父类实例变量：按继承链从上到下依次排列
3. 本类实例变量：本类定义的成员变量
4. 内存对齐填充：编译器插入的padding字节，确保整体大小为指针大小的倍数

实例对象存储的是具体的数据值，同一个类可以创建无数个实例对象。

类对象的底层结构体是objc_class（继承自objc_object），内存结构为：

1. isa指针（8字节）：指向元类对象，用于查找类方法
2. superclass指针（8字节）：指向父类，建立继承链
3. cache：方法缓存，存储最近调用过的方法以提高调用效率
4. bits：指向类的元数据（class_rw_t → class_ro_t），包含方法列表、属性列表、协议列表、实例变量描述等

类对象存储的是类的描述信息，每个类在内存中只有唯一一份类对象。

→ Objective-C底层原理-NSObject

1. 实例头部不同：继承自NSObject的类头部是isa指针（兼容ObjC运行时），引用计数存储在isa的extra_rc位域和SideTable中；纯Swift类头部是HeapMetadata指针 + 8字节的InlineRefCountBits（bit 0-31 unowned计数，bit 32 isDeiniting，bit 33-62 strong计数，bit 63 UseSlowRC标志），默认内联存储无需查找外部结构，缓存更友好。当对象被weak引用时，bit 63置1，这8字节切换为指向HeapObjectSideTableEntry的指针，此后所有引用计数（strong、unowned、weak）由SideTable统一管理，该切换不可逆
2. 类型元数据结构不同：继承自NSObject的类的类对象是ObjC与Swift的混合结构——前半部分是标准的objc_class布局（isa/superclass/cache_t/class_data_bits_t → class_rw_t，包含ObjC可见的方法列表、属性列表、协议列表），后半部分追加了Swift的vtable（包含Swift可重写方法槽位，包括实例方法和可重写的class func）、typeDescriptor、协议一致性记录等，ObjC运行时只访问前半部分，Swift运行时访问后半部分，两者互不干扰；纯Swift类的ClassMetadata是纯Swift结构（kind/superclass/flags/instanceSize/vtable等），没有ObjC的cache_t和class_rw_t，vtable直接内嵌且同样可以包含实例方法和可重写的class func，整体更紧凑
3. 有无ObjC元类参与派发：继承自NSObject的类有ObjC元类（标准objc_class结构），@objc/dynamic类方法通过元类方法列表供objc_msgSend查找；普通Swift class func可在Swift vtable中派发。纯Swift类的Swift方法派发不依赖ObjC元类方法列表，可重写class func和实例方法统一放在vtable中
4. 方法派发：两者都支持vtable派发、静态派发和见证表派发。区别在于：继承自NSObject的类天然接入ObjC运行时，可使用@objc dynamic强制消息派发来支持Selector、method swizzling、KVO等能力；纯Swift类的Swift-only成员默认不走objc_msgSend，但ObjC可表示成员也可以显式@objc/dynamic桥接到消息派发，只是不会因此自动获得完整的NSObject/KVO语义

→ Swift底层原理-结构体、类和协议

1. 静态派发（Static Dispatch）：编译时确定调用地址，性能最优，可内联优化。适用于结构体/枚举的所有方法、final类和final方法、private方法、static func。函数地址在编译期直接嵌入调用指令中，不依赖任何派发表。

2. 虚函数表派发（V-Table Dispatch）：通过类元数据中的vtable查找函数指针。适用于类的实例方法（默认），以及可被子类override的class func；这点对纯Swift类和继承自NSObject的Swift类都成立。虚函数表内嵌在类的元数据结构中（继承自NSObject的类追加在objc_class布局之后，纯Swift类直接内嵌在ClassMetadata中），存储Swift可重写方法的函数指针，支持继承和方法重写。

3. 消息派发（Message Dispatch）：通过Objective-C的objc_msgSend进行动态查找。适用于Objective-C方法，以及Swift中显式@objc dynamic且ObjC可表示的成员；继承自NSObject的Swift类是最常见场景，因为它天然接入Selector、KVO、method swizzling等ObjC运行时能力。消息派发依赖ObjC运行时的方法缓存和方法列表，支持运行时替换实现。

4. 见证表派发（Witness Table Dispatch）：通过协议见证表查找函数指针。见证表属于协议一致性关系（类型-协议的组合），不存储在类型元数据内部，而是作为独立的全局符号写入Mach-O中——见证表本身（函数指针数组）在__DATA,__const段，协议一致性记录在__TEXT,__swift5_proto段。每个类型对每个协议都有独立的见证表，支持多协议组合。这样设计是因为一个类型可以遵循多个协议，如果都塞进类型元数据会导致结构不固定；独立存储后，类型元数据保持固定布局，见证表通过一致性记录间接关联。

协议方法的派发取决于调用上下文：

其中 泛型特化（Generic Specialization） 是Swift编译器的一项重要优化：当编译器能在编译期确定泛型参数的具体类型时，直接为该类型生成一个专用版本的函数，将泛型参数替换为具体类型，从而消除类型擦除和见证表查找的运行时开销。未特化时，编译器生成通用版本，使用类型擦除（将具体类型擦除为不透明指针），通过TypeMetadata和见证表在运行时间接操作，每次方法调用都要经过见证表间接跳转；特化后，等价于静态派发，可以内联，零运行时开销。

protocol Drawable {
    func draw()
}
struct Circle: Drawable {
    func draw() { print("Circle") }
}

// 泛型函数
func render<T: Drawable>(_ shape: T) {
    shape.draw()
}
// 调用处传入具体类型Circle
render(Circle())
// 编译器特化后，等价于直接生成了：
// func render_Circle(_ shape: Circle) {
//     shape.draw()  // 直接调用Circle.draw()，静态派发，可内联
// }

特化成功的条件：同模块内调用 + 开启编译优化（-O）可以特化；跨模块调用默认无法特化，除非函数标记了@inlinable；Debug模式（-Onone）不执行特化。

协议要求方法 vs 协议扩展方法的派发陷阱：

上述讨论的都是协议要求方法（在protocol声明体中定义的方法），它们会被编译器加入见证表，通过协议类型调用时使用见证表动态派发，能正确找到具体类型的实现。

协议扩展方法（在extension中定义但不在协议要求中的方法）不在任何派发表中，编译后只是Mach-O中的普通函数符号，所有调用都由编译器在编译期根据变量的声明类型静态绑定，属于静态派发。

→ Swift底层原理-结构体、类和协议

1. 栈提升（Stack Promotion）：当类实例满足条件（大小较小、不逃逸作用域、不包含内部堆引用）时，编译器将堆分配优化为栈分配，实现零ARC开销
2. 引用计数消除（RC Elimination）：通过数据流分析识别并删除成对的retain/release操作，比如短暂引用、不逃逸的函数参数等场景下消除冗余的ARC操作
3. 生命周期合并（Lifetime Merging）：追踪变量的词法作用域，当两个变量的生命周期不重叠时复用内存槽位，减少内存分配和释放次数

相比Objective-C，Swift编译器能进行更激进的ARC优化。ObjC的ARC优化相对保守，每次赋值和传递都会严格执行retain/release；而Swift编译器通过追踪RC Identity、数据流分析等手段，在保证正确性的前提下尽可能消除冗余的引用计数操作。

→ Swift底层原理-结构体、类和协议

// 方式一：协议类型参数
func drawA(_ shape: Shape) { shape.draw() }
// 方式二：泛型约束参数
func drawB<T: Shape>(_ shape: T) { shape.draw() }

两者的核心区别在于参数的底层表示不同。

方式一中，shape参数的类型是协议类型（存在类型），编译器会将传入的具体值包装进一个存在容器（Existential Container）。存在容器是一种固定大小的结构，布局为：24字节内联缓冲区（inlineBuffer[3]）+ 8字节类型元数据指针 + 8字节见证表指针，单协议时总大小40字节。如果具体类型大小 <= 24字节，值直接存在inlineBuffer中；超过24字节则堆分配，inlineBuffer[0]存堆指针。调用shape.draw()时，运行时从容器中取出见证表，通过函数指针间接跳转——这是见证表派发，无法内联优化。

方式二中，编译器可以进行泛型特化——当调用处的具体类型已知时，直接为该类型生成专用版本的函数，参数就是具体类型本身，没有存在容器的包装开销，shape.draw()变成静态派发，可以内联。

性能差异来自三个方面：存在容器的构造和拷贝开销（大值类型还涉及堆分配）、见证表的间接跳转开销、以及无法内联导致编译器丧失进一步优化的机会。

补充：当协议有类约束（AnyObject）时，使用更紧凑的类存在容器（8字节对象引用 + 见证表指针），不需要inlineBuffer。特殊情况下，Any类型是零协议约束的存在容器（共32字节），AnyObject是零协议约束的类存在容器（仅8字节）。

→ Swift底层原理-结构体、类和协议

这涉及到Swift的协议一致性（Protocol Conformance）查找机制。编译器会为每一对（类型, 协议）关系生成一条协议一致性记录，存储在Mach-O的__TEXT,__swift5_proto段中，记录该类型对该协议的见证表位置。

运行时通过swift_conformsToProtocol函数执行查找，流程分为四步：

1. 查缓存：首先检查全局一致性缓存（哈希表，key是(类型, 协议)对），命中则直接返回见证表地址
2. 扫描一致性记录：缓存未命中时，遍历所有已加载Mach-O镜像的__TEXT,__swift5_proto段，逐条匹配目标类型和协议
3. 处理条件一致性：如果记录标记为条件一致性（如extension Array: Equatable where Element: Equatable），递归检查泛型参数是否满足条件
4. 写入缓存：匹配成功后缓存结果，后续相同查询直接命中，开销接近O(1)

一致性记录使用RelativePointer（相对指针）而非绝对指针，存储偏移量而非绝对地址，无需dyld重定位，因此可以放在只读的__TEXT段中，只读页可在多进程间共享，节省内存。

这个机制不仅用于as?/as!转换，也用于泛型约束检查、协议类型赋值等所有需要确认"类型是否遵循协议"的场景。

→ Swift底层原理-结构体、类和协议

protocol Greeting {
    func sayHello()
}
extension Greeting {
    func sayHello() { print("Hello from protocol") }
    func sayGoodbye() { print("Goodbye from protocol") }
}
struct Person: Greeting {
    func sayHello() { print("Hello from Person") }
    func sayGoodbye() { print("Goodbye from Person") }
}

let greeter: Greeting = Person()
greeter.sayHello()     // ?
greeter.sayGoodbye()   // ?

greeter.sayHello()输出 “Hello from Person”，greeter.sayGoodbye()输出 “Goodbye from protocol”。

两个方法的行为不同，根本原因在于函数地址存储在哪里：

sayHello是协议要求方法（在protocol声明体中定义），编译器会在见证表中为它分配槽位。通过协议类型调用时，运行时从存在容器中取出见证表指针，找到Person.sayHello()的函数指针并跳转——这是动态派发，能正确找到具体类型的实现。

sayGoodbye是协议扩展方法（仅在extension中定义，不在协议要求中），它不在任何派发表中（不在见证表、不在虚函数表），编译后只是Mach-O __TEXT,__text段中的普通函数符号。编译器在编译期根据变量的声明类型Greeting直接绑定到扩展版本的函数地址，运行时没有任何机会"发现"Person还有自己的sayGoodbye()。

因此，如果希望具体类型的实现在通过协议类型调用时生效，必须将方法声明为协议要求（写在protocol声明体中），而不能仅在扩展中定义。

→ Swift底层原理-结构体、类和协议

Swift为每个（类型, 协议）组合生成独立的见证表（Witness Table），而不是把所有协议方法都塞进类型元数据中。对比两者的组织方式：

之所以不像虚函数表那样内嵌在类型元数据中，是因为一个类型可以遵循任意多个协议，每个协议一张见证表。如果都塞进类型元数据，元数据的大小就会随着遵循的协议数量变化，导致结构不固定——运行时无法用固定偏移量访问vtable等其他字段。独立存储后，类型元数据保持固定布局，见证表通过一致性记录间接关联即可。

→ Swift底层原理-结构体、类和协议

1. 词法分析（Lexer）：逐字符扫描源文件，将其切分为 Token 流（关键字、标识符、运算符、字面量等），剥离注释和空白但保留位置信息用于诊断
2. 语法分析（Parser）：将 Token 流组织为 AST（抽象语法树），每个节点对应一个语法结构（函数声明、if 语句、表达式等），此时类型信息尚未确定
3. 语义分析（Sema）：编译前端中最复杂的阶段，在 AST 上执行类型推断（基于约束求解器）、类型检查、重载决议、协议一致性检查、访问控制检查，产出类型标注 AST
4. SILGen：将类型标注 AST 降低为 Raw SIL——控制流结构转换为基本块和分支指令组成的 CFG，表达式转换为 SSA 形式的指令序列，保守插入所有必要的 retain/release
5. SIL 优化：分为两个阶段——Guaranteed Passes（无论优化级别都执行，负责诊断检查如确定初始化、排他性检查、所有权验证）和 General Passes（-O 下执行，负责 ARC 优化、泛型特化、去虚拟化、内联等性能优化），产出 Canonical SIL
6. IRGen：将 Canonical SIL 降低为 LLVM IR，SIL 类型映射为 LLVM 类型，堆分配指令转换为运行时函数调用（如 swift_allocObject），VTable/Witness Table 转换为全局常量数组
7. LLVM 优化与代码生成：LLVM 执行自身优化 Pass（指令合并、循环优化、向量化、寄存器分配等），生成目标平台机器码，最终由链接器链接为可执行文件或动态库

→ SIL

SIL（Swift Intermediate Language）是 Swift 编译器的中间表示，位于 AST 和 LLVM IR 之间。LLVM IR 是面向 C/C++ 等语言设计的通用低级中间表示，无法直接表达 Swift 的高级语义（如 ARC、值语义、泛型、协议见证表等）。SIL 保留了这些高级信息，使编译器能够在生成 LLVM IR 之前执行 Swift 特有的优化和安全检查。具体而言，SIL 解决了六个核心问题：

1. ARC 的 retain/release 冗余消除：SILGen 阶段会保守插入大量 retain/release，SIL 层通过数据流分析识别并消除配对的、不影响对象生命周期的冗余操作（LLVM IR 层面无法做到，因为 retain/release 在 LLVM IR 中只是普通函数调用）
2. 泛型性能开销消除：泛型默认通过值见证表间接操作，SIL 层的泛型特化 Pass 在编译期确定具体类型后，生成去泛型的特化版本，直接操作具体类型，避免间接调用
3. 协议动态派发优化：协议方法默认通过 Witness Table 间接派发，SIL 层的去虚拟化 Pass 在能确定具体类型时，将 witness_method（虚函数表派发） 间接调用替换为 function_ref 直接调用（静态派发），还可能触发内联等级联优化
4. 编译期诊断与错误检测：基于 SIL 完整的 CFG 和数据流信息，执行确定初始化检查（Definite Initialization）、不可达代码检测、switch 穷举检查等静态分析
5. 内存访问安全检查（Exclusivity Enforcement）：通过 begin_access / end_access 指令标记内存访问区间，在编译期检测重叠的排他性访问冲突，对编译期无法确定的情况插入运行时检查代码
6. 函数签名优化：分析参数和返回值的使用方式，执行死参数消除、Owned-to-Guaranteed 转换（省去不必要的 retain/release）、未使用返回值消除等精简

→ SIL

SSA（Static Single Assignment，静态单赋值）是一种 IR 设计范式，要求每个变量只被赋值一次，这使得编译器能高效地进行数据流分析和优化。OSSA（Ownership SSA）是从 Swift 5.1 开始在 SSA 基础上进一步引入的所有权模型，核心思想是每个非平凡的 SIL 值都有且仅有一个明确的"所有者"，所有权在编译期被静态验证。OSSA 定义了四种所有权类别：@owned（持有所有权，必须负责销毁或转移）、@guaranteed（借用语义，调用者保证存活，被调用者不得销毁）、@unowned（无主引用，不保证生命周期）、trivial（Int 等平凡类型，无需管理）。

在 OSSA 中，传统的 strong_retain / strong_release 被替换为语义更明确的 copy_value / destroy_value，并通过 begin_borrow / end_borrow 显式标记借用作用域。这使得编译器能够精确消除冗余的引用计数操作、实现更精确的生命周期管理（将销毁提前到最后一次使用之后），同时也是 consuming / borrowing 参数和 ~Copyable 类型等语言特性的底层基础。

→ SIL

虽然 SIL 是编译器内部表示，但开发者可以通过 swiftc -emit-silgen（Raw SIL）、-emit-sil（Canonical SIL）、-emit-sil -O（优化后 SIL）来查看生成结果，从而辅助多种实际场景：

• 分析内存分配方式：通过观察 alloc_stack（栈）、alloc_ref（堆）、alloc_box（闭包捕获提升到堆）等指令，判断值的实际分配位置
• 分析方法派发机制：观察 function_ref（静态派发）、class_method（vtable 派发）、witness_method（协议见证表派发）来确认方法的派发方式
• 验证编译器优化效果：对比优化前后的 SIL，确认 ARC 优化是否消除了冗余 retain/release、泛型是否被特化、虚函数调用是否被去虚拟化
• 指导性能调优：根据 SIL 中实际生成的指令，有针对性地使用 final/private（促进去虚拟化）、值类型（减少 ARC 开销）、@inlinable（跨模块内联）、Whole Module Optimization（跨文件优化）等手段
• 理解 Swift 语言行为：通过 SIL 观察 Optional 的枚举本质（switch_enum）、闭包捕获的 box 提升机制（alloc_box + partial_apply）、struct 与 class 的内存模型差异等底层实现细节

→ SIL

1. App体积显著减小

ABI稳定之前，每个Swift App都需要嵌入完整的Swift标准库（约10-15MB）。ABI稳定后（iOS 12.2+），Swift运行时内置于操作系统中，App不再需要打包这部分二进制，体积直接减小。

2. App启动速度提升

系统级Swift运行时被纳入dyld shared cache，多个App共享同一份物理内存页，无需每个App单独加载自己嵌入的运行时库，减少了启动时的动态库加载开销。

3. 预编译二进制框架的分发成为可能

这是三个机制协同作用的结果：

• ABI稳定保证了不同Swift版本编译的二进制可以正确链接
• 模块稳定性通过.swiftinterface让不同版本的编译器都能导入模块
• Library Evolution保证库可以独立于客户端更新而不破坏兼容性

在此之前，第三方框架只能以源码形式分发（如CocoaPods、SPM源码依赖），或者为每个Swift版本单独编译。现在可以直接分发.xcframework二进制产物，用户无需关心框架的编译环境。

4. 系统框架可以用Swift编写

Apple自身也受益于二进制兼容性。iOS系统更新时，系统框架的Swift代码可以独立升级，而不会破坏用户设备上已安装的App。这使得Apple可以逐步将系统框架从Objective-C迁移到Swift（如SwiftUI、Observation框架等）。

5. 跨团队协作效率提升

大型项目中不同团队可以独立编译各自的模块，产出预编译的二进制产物供其他团队使用，而不要求所有团队锁定同一个Xcode/Swift版本。这降低了CI/CD复杂度和Xcode升级的协调成本。

→ Swift二进制兼容性

编译插桩是编译器在生成代码时自动注入额外指令的技术，这些指令不改变程序逻辑，但能在运行时收集执行信息。插桩发生在 LLVM IR 层，通过 Instrumentation Pass 实现，对源码透明。

iOS 中的主要应用场景：

1. Sanitizer 运行时检测：ASan 在每次内存访问前插入边界检查（通过 Shadow Memory 追踪合法区域）；TSan 在内存访问和同步操作处插入记录指令检测数据竞争；UBSan 在可能触发未定义行为的操作前插入检查
2. 二进制重排：通过 SanitizerCoverage（-fsanitize-coverage=func,trace-pc-guard）在每个函数入口插入回调，收集启动阶段的函数调用顺序，生成 Order File 指导链接器将启动代码集中排列，减少 Page Fault
3. 代码覆盖率：-fprofile-instr-generate 在基本块边界插入计数器记录执行次数，-fcoverage-mapping 嵌入映射表关联计数器与源码位置，用于测试覆盖率统计
4. PGO（Profile-Guided Optimization）：先用插桩版本收集运行时热路径数据，再用 Profile 数据指导重新编译，优化分支预测、函数内联和基本块排布

插桩会带来运行时开销（ASan 约 2x、TSan 约 5-15x），因此通常仅在 Debug/测试环境使用。PGO 是例外——最终 Release 产物不包含插桩。

→ iOS编译原理

类型擦除（Type Erasure）是一种在运行时隐藏具体类型信息的技术，使得不同类型可以通过统一接口操作。

Swift 需要类型擦除的直接原因是 PAT（Protocol with Associated Types）协议的限制：当协议带有关联类型或 Self 约束时，它无法直接作为类型使用，因为编译器不知道关联类型的具体绑定，无法确定内存布局和方法签名：

protocol Container {
    associatedtype Item
    func add(_ item: Item)
    func get(at index: Int) -> Item
}

// 编译错误：Protocol 'Container' can only be used as a generic constraint
// because it has Self or associated type requirements
let containers: [Container] = []

编译器不知道 Item 到底是 String 还是 Int，就无法决定 add 方法接受什么参数、get 方法返回什么类型，也无法为容器中的值分配正确大小的内存。

类型擦除通过两种策略绕开这一限制：

1. 存在类型（any）：编译器为值创建存在容器，在运行时通过见证表间接派发，不需要在编译时知道具体类型
2. 手动包装器（AnyXxx<T>）：将协议层面的关联类型转化为泛型参数，AnyContainer<String> 是一个完整的具体类型，编译器能处理

→ 类型擦除

两者都是协议在类型层面的使用方式，核心区别在于谁知道具体类型以及何时确定。

存在类型（any P）：来自类型论的存在量词 ∃，表示"存在某个遵循协议 P 的类型，但不关心具体是哪个"。具体类型在运行时才确定，同一变量可以在不同时刻持有不同具体类型。底层通过存在容器（Existential Container）存储值，方法调用走协议见证表间接派发，有运行时开销：

// 存在类型：animals 数组中每个元素的具体类型可以不同
// 编译器不知道每个元素到底是 Dog 还是 Cat，运行时通过见证表派发
var animals: [any Animal] = [Dog(), Cat()]

// 同一变量可以在不同时刻持有不同类型
var pet: any Animal = Dog()
pet = Cat()  // 合法

不透明类型（some P）：来自全称量词 ∀，表示"有一个确定的具体类型遵循协议 P，但不告诉调用者是哪个"。具体类型在编译时就已确定，编译器可以静态派发和内联优化，零额外开销。但同一位置必须始终是同一种具体类型：

// 不透明类型：编译器知道返回的就是 Dog，但调用者只看到 "some Animal"
func makePet() -> some Animal {
    return Dog()
}

// 编译错误：所有返回路径必须返回相同的具体类型
func makeRandomPet() -> some Animal {
    if Bool.random() {
        return Dog()   // 返回 Dog
    } else {
        return Cat()   // 返回 Cat —— 类型不一致，编译失败
    }
}

Swift 5.6 引入 any 关键字使存在类型变为显式声明。在此之前，let x: Animal 就是存在类型，但语法上没有任何标记提醒开发者"这里有运行时开销"。any 的引入迫使开发者有意识地做选择：是用零开销的 some/泛型，还是用有开销但更灵活的 any。Swift 5.7 起，对于带有关联类型的协议，必须使用 any 才能作为存在类型。

→ 类型擦除

用 some（不透明类型）：当函数返回类型或属性类型需要隐藏具体实现，但始终返回同一种具体类型时。编译器知道具体类型，可以做静态派发和优化。典型例子是 SwiftUI 中的 var body: some View——编译器知道 body 每次返回的都是同一种 View 树结构：

struct ContentView: View {
    // some View：编译器知道 body 的具体类型是 VStack<TupleView<(Text, Button<Text>)>>
    // 但开发者不需要写出这个复杂类型，也不需要在每次修改 UI 时更新返回类型
    var body: some View {
        VStack {
            Text("Hello")
            Button("Tap") { }
        }
    }
}

用 any（存在类型）：当需要在同一容器中混合不同具体类型（异构集合），或者函数在不同条件下需要返回不同具体类型时：

protocol Shape {
    func area() -> Double
}

// 异构集合：Circle 和 Square 可以共存于同一数组
let shapes: [any Shape] = [Circle(radius: 5), Square(side: 3)]

// 动态返回不同类型
func randomShape() -> any Shape {
    Bool.random() ? Circle(radius: 1) : Square(side: 1)
}

用泛型约束 <T: P>：当集合中所有元素类型相同（同构集合），且需要最大化性能时。编译器可以进行泛型特化，为具体类型生成专用的函数副本，实现静态派发甚至内联：

// 泛型约束：所有元素必须是同一具体类型
// 调用 process([Circle(), Circle()]) 时，编译器为 Circle 生成专用版本
func process<T: Shape>(_ items: [T]) {
    for item in items {
        print(item.area())  // 特化后变为直接调用 Circle.area()，可内联
    }
}

// 这样调用会编译错误，因为 Circle 和 Square 不是同一类型
// process([Circle(radius: 5), Square(side: 3)])  // 错误

选择决策： some / 泛型约束 → 编译时确定，零开销，优先选择；any → 运行时确定，有开销，仅在需要异构能力时使用。

→ 类型擦除

Swift 标准库的 AnySequence、AnyCollection、AnyIterator 等类型擦除包装器内部采用的是 Box 模式——通过抽象基类 + 具体 Box 子类 + 公开包装器的三层结构。以 AnySequence 为例，简化后的内部结构如下：

// 第一层：抽象基类，泛型参数只有 Element，没有具体的序列类型 S
internal class _AnySequenceBox<Element> {
    func makeIterator() -> AnyIterator<Element> { fatalError() }
    // Sequence 协议的其他方法要求...
}

// 第二层：具体 Box 子类，持有具体序列类型 S
internal final class _SequenceBox<S: Sequence>: _AnySequenceBox<S.Element> {
    let _base: S
    
    init(_ base: S) { self._base = base }
    
    override func makeIterator() -> AnyIterator<S.Element> {
        return AnyIterator(_base.makeIterator())
    }
}

// 第三层：公开的类型擦除包装器
public struct AnySequence<Element>: Sequence {
    internal let _box: _AnySequenceBox<Element>
    
    public init<S: Sequence>(_ base: S) where S.Element == Element {
        // 擦除发生在这里：_SequenceBox<Array<Int>> 向上转型为 _AnySequenceBox<Int>
        // 具体类型 Array<Int> 从类型签名中消失
        self._box = _SequenceBox(base)
    }
    
    public func makeIterator() -> AnyIterator<Element> {
        return _box.makeIterator()  // vtable 派发到子类的 override 实现
    }
}

类型擦除的发生过程：

1. _SequenceBox<Array<Int>> 持有具体的 Array<Int>，它继承自 _AnySequenceBox<Int>
2. 在 AnySequence.init 中，_SequenceBox<Array<Int>> 被赋给类型为 _AnySequenceBox<Int> 的 _box 属性——此时发生向上转型，泛型参数 Array<Int> 从类型签名中消失，只剩下 Element（即 Int）
3. 之后调用 _box.makeIterator() 时，通过 class 的虚方法表（vtable）派发到子类 _SequenceBox<Array<Int>> 重写的实现，该实现内部调用了 Array<Int>.makeIterator()

本质：利用面向对象的子类型多态——父类引用可以指向子类实例，具体类型信息藏在子类里，但父类的类型签名中只保留了泛型参数 Element，具体的序列类型 S 被继承层级"吞掉"了。

→ 类型擦除

存在类型在底层通过存在容器（Existential Container） 实现。当声明 any Animal 时，Swift 为每个值创建如下结构：

struct ExistentialContainer {
    void* valueBuffer[3];       // 值缓冲区（24字节）
    TypeMetadata* type;         // 类型元数据指针
    WitnessTable* witnessTable; // 协议见证表指针
};

三个组成部分各司其职：

1. 值缓冲区（Value Buffer，24字节）：如果具体类型的大小 ≤ 24 字节（如简单 struct），值直接内联存储在这里；如果超过 24 字节，则在堆上分配内存，缓冲区退化为存储堆指针。这是为什么小类型的存在类型性能比大类型好。

2. 类型元数据（Type Metadata）：指向具体类型的元数据，运行时通过它来执行内存分配、拷贝、销毁等操作。这让存在容器能够正确管理它"不认识"的具体类型的值。

3. 协议见证表（Protocol Witness Table）：类似 C++ 的虚表（vtable），存放协议中每个方法要求对应的函数指针。当你对 any Animal 调用 makeSound() 时，运行时通过见证表找到具体类型实现的那个函数，再进行间接调用。

性能开销来自三方面：

• 间接方法调用：每次方法调用都要通过见证表查函数指针再跳转，编译器无法内联
• 堆分配：大值类型（> 24 字节）会触发 malloc，带来分配和释放开销
• 多协议组合：当遵循多个协议时（如 any Hashable & Comparable），容器中包含多个见证表指针，开销随之增加

相比之下，some 和泛型约束在编译时确定具体类型，不需要存在容器，方法调用是静态派发可以内联，没有这些额外开销。

→ 类型擦除

泛型约束 <T: P> 在编译时就确定了 T 的具体类型，编译器在开启优化（-O）时会进行泛型特化（Generic Specialization）。以一个具体例子说明：

func process<T: Shape>(_ items: [T]) {
    for item in items {
        item.area()
    }
}

process([Circle(radius: 5), Circle(radius: 3)])  // 调用点：T = Circle

编译器看到 T = Circle，会生成等价于以下的特化版本：

// 编译器自动生成（等价逻辑，非真实代码）
func process_Circle(_ items: [Circle]) {
    for item in items {
        item.area()  // 直接调用 Circle.area()，静态派发
    }
}

特化后的优化链路：

1. 内存布局已知：Circle 的大小在编译时确定，直接按值操作，不需要值见证表
2. 方法地址已知：Circle.area() 的函数地址在编译时确定，直接 call 指令跳转，不需要查协议见证表
3. 可以内联：如果 Circle.area() 实现足够短，编译器将其函数体直接展开到循环内部，连函数调用开销都省了

而 any Shape 数组中每个元素的具体类型可能不同，编译器不可能为某一个类型特化，每次 item.area() 都必须查见证表间接跳转，也无法内联。

需要注意，泛型特化依赖编译器优化，Debug 模式（-Onone）下泛型同样走见证表派发，性能与 any 接近。关键区别在于泛型有能力被特化，而 any 在语义上就排除了这种可能。

→ 类型擦除

Codable 的底层不是运行时反射，也不是像很多 Objective-C 字典转模型框架那样在运行时遍历属性、拼字符串、做 KVC 赋值。它的核心机制是编译器合成 + 标准库协议抽象 + 具体 Encoder/Decoder 实现。Codable 本身只是 Encodable & Decodable 的协议组合，真正重要的是：类型声明遵循 Codable 后，只要它的存储属性也满足编解码条件，Swift 编译器就会在编译期自动生成 CodingKeys、encode(to:) 和 init(from:)。

编译器合成的代码本质上就是一份强类型的手写编解码逻辑。编码时，encode(to:) 会先通过 Encoder 获取合适的容器，比如对象结构用 keyed container，数组结构用 unkeyed container，单个值用 single value container，然后按照 CodingKey 把每个属性写进去；解码时，init(from:) 会通过 Decoder 获取对应容器，再根据属性类型读取数据。普通非可选属性会走 decode，字段缺失或类型不匹配会抛错；可选属性会走 decodeIfPresent，字段不存在或值为 null 时通常得到 nil。这也是为什么 Codable 的字段名和类型检查比纯字符串字典转换更安全。

Encoder / Decoder 只是标准库定义的抽象协议，它们不关心最终格式是 JSON、Plist 还是自定义二进制格式。真正负责格式转换的是 JSONEncoder、JSONDecoder、PropertyListEncoder 这类具体实现。以 JSON 为例，JSONEncoder 会创建内部 encoder，递归调用模型和子模型的 encode(to:)，把每一层写入内部的字典、数组或标量结构中，并通过类似 storage 栈的结构维护当前嵌套层级，最后再序列化成 Data。JSONDecoder 的方向相反：先把 Data 解析成 JSON 中间结构，再创建内部 decoder，递归调用目标类型及其子类型的 init(from:)，逐层恢复 Swift 对象。

所以，Codable 的本质是一套静态、类型安全、可组合的序列化机制。它把大部分机械性的字段映射代码交给编译器生成，把数据形态抽象成容器协议，再把具体格式交给不同的 Encoder/Decoder 实现。相比 Runtime 反射方案，它的优势是编译期约束更强、性能更可控、错误路径更清晰；解码失败时还能通过 DecodingError 和 codingPath 精确知道是哪个字段、哪一层嵌套出了问题。不过它也没那么"动态"，复杂字段映射、默认值、条件编码、扁平化或嵌套转换等场景，通常需要手写 CodingKeys、init(from:) 或 encode(to:) 来定制。

→ Codable底层原理

UIView 属于 UIKit，继承自 UIResponder，负责事件处理（触摸、手势）、响应链和 Auto Layout；CALayer 属于 Core Animation，继承自 NSObject，负责视觉内容的渲染（位图管理、圆角、阴影、边框、动画等）。每个 UIView 内部持有一个 CALayer，UIView 是这个 layer 的 delegate。两者分离的核心原因是职责分离：CALayer 可以在 iOS（UIKit）和 macOS（AppKit）间共享，平台特有的交互逻辑由各自的 View 层封装。

→ 布局方法详解

独立创建的 CALayer 修改可动画属性（backgroundColor、position、opacity 等）时会自动产生 0.25s 的过渡动画，这就是隐式动画。UIView 的 backing layer 之所以没有隐式动画，是因为 UIView 作为 layer 的 delegate，在 action(for:forKey:) 方法中返回了 NSNull，阻止了默认的动画行为。要为 UIView 添加动画，需要使用 UIView.animate 系列方法或显式的 CAAnimation。

→ 布局方法详解

Auto Layout 的核心是 Cassowary 约束求解算法。每个约束被转化为线性等式或不等式（view1.attr = m × view2.attr + c），所有约束组成线性方程组，每个视图有 x、y、width、height 四个未知数。Cassowary 使用单纯形法进行增量求解——修改一个约束不需要从头计算，只在已有解基础上增量更新。约束有优先级（1-1000），Required 必须满足，Optional 尽量满足，冲突时低优先级约束被打破。

→ 布局方法详解

setNeedsLayout 是异步标记方法，仅设置标志位，在下一个 RunLoop 周期才执行 layoutSubviews；layoutIfNeeded 是同步执行方法，如果存在待处理的布局标记，会立即触发 layoutSubviews。两者经常配合使用，比如约束动画中先修改约束（系统自动标记），再在动画 block 中调用 layoutIfNeeded 让布局变化被动画系统捕获。

→ 布局方法详解

• 视图首次被添加到视图层级并显示时
• 视图的 bounds 发生变化时（包括 frame.size 改变）
• 添加或移除子视图时
• UIScrollView 滚动时（contentOffset 变化导致 bounds.origin 变化）
• 设备旋转导致父视图大小变化时
• 调用 setNeedsLayout 后的下一个布局周期
• 调用 layoutIfNeeded 时（如果有待处理的布局标记）

其中添加子视图时，更直接触发的是父视图的布局；子视图自己的 layoutSubviews 是否调用，取决于它自身是否也需要重新布局。

→ 布局方法详解

// 正确写法
someConstraint.constant = 100
UIView.animate(withDuration: 0.3) {
    self.view.layoutIfNeeded()
}

// 错误写法
UIView.animate(withDuration: 0.3) {
    someConstraint.constant = 100
}

修改约束只是更新约束对象的值并标记视图需要布局，并不会产生可动画的属性变化。真正改变 frame 的是 layoutSubviews（由 layoutIfNeeded 触发）。动画系统只能捕获 block 内发生的可动画属性（如 frame）变化，所以必须在 block 内调用 layoutIfNeeded 来让 frame 变化发生在动画上下文中。

→ 布局方法详解

在 layoutSubviews 中修改约束会导致系统重新标记视图需要布局，从而再次触发 layoutSubviews，形成无限循环。约束的更新应放在 updateConstraints 中，通过 setNeedsUpdateConstraints 标记触发，这样约束更新在布局之前完成，不会产生循环依赖。

→ 布局方法详解

它们属于不同的更新阶段，互不影响。如果同时需要重新布局和重绘，需要分别调用两个方法。

→ 布局方法详解

• 约束阶段：从叶子节点到根节点（由内到外），先计算子视图的约束，再计算父视图
• 布局阶段：从根节点到叶子节点（由外到内），先布局父视图，再布局子视图
• 绘制阶段：从根节点到叶子节点（由外到内），先绘制父视图，再绘制子视图

约束阶段由内到外是因为父视图的布局可能依赖子视图的固有尺寸（intrinsicContentSize）；布局和绘制阶段由外到内是因为子视图的位置和大小依赖父视图的 bounds。

→ 布局方法详解

let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(label)
NSLayoutConstraint.activate([...])

// 此时 label.frame 为 .zero，因为布局尚未执行
print(label.frame)  // (0, 0, 0, 0)

// 调用 layoutIfNeeded 强制立即执行布局
view.layoutIfNeeded()
print(label.frame)  // 正确的值

添加约束后系统只是标记了视图需要布局，要在下一个 RunLoop 周期才会执行。调用 layoutIfNeeded 可以同步触发布局计算，之后就能获取到正确的 frame。

→ 布局方法详解

不会。setNeedsLayout 只是设置一个布尔标志位，多次调用和调用一次效果相同。系统在下一个 RunLoop 周期检查该标志位，只要为 YES 就调用一次 layoutSubviews，调用后标志位清零。这是 iOS 视图更新的合并机制，避免了不必要的重复计算。

→ 布局方法详解

硬件与系统层：

1. 触摸屏硬件检测到电容变化（电容式触摸屏通过感应手指的电荷变化来定位触摸点），IOKit.framework 接收硬件中断并生成 IOHIDEvent（Human Interface Device 事件）
2. SpringBoard（iOS 桌面管理程序，负责管理主屏幕、App 启动等）接收事件，根据当前前台 App 的信息判断事件应该转发给哪个进程
3. 通过 mach port（内核级进程间通信机制，比用户态的通知更高效）将 IOHIDEvent 转发给目标 App 进程
4. App 主线程 RunLoop 被唤醒。事件先由 Source1（基于 port，负责接收系统内核和其他进程的消息）回调接收，然后包装后交由 Source0（基于回调，处理 App 内部事件）进一步处理
5. 事件被封装为 UIEvent 对象，内部包含一个或多个 UITouch。每个 UITouch 对应一根手指，记录了触摸的位置、阶段（began/moved/ended）、时间戳等信息

Hit-Testing 阶段（自上而下）：

6. UIApplication 调用 sendEvent: 将事件交给 UIWindow
7. UIWindow 调用 hitTest:withEvent: 开始 Hit-Testing：从自身出发，对每个子视图先调用 pointInside:withEvent: 判断触摸点是否在 bounds 内，再逆序递归子视图的 hitTest:withEvent:（逆序是因为后添加的子视图在视觉上更靠前，应该优先响应），最终确定层级最深的可交互视图作为 Hit-Test View
8. Hit-Testing 过程中会跳过三类视图：hidden = YES、alpha <= 0.01、userInteractionEnabled = NO
9. Hit-Testing 只在 touch began 阶段执行一次，后续同一触摸序列的 moved/ended 直接发给已确定的 Hit-Test View，不会因为手指移动到其他视图区域而重新寻址

事件分发阶段（手势识别器优先）：

10. UIWindow 的 sendEvent: 在同一次 RunLoop 迭代中，先将触摸发送给 Hit-Test View 自身及其父视图链上所有关联的手势识别器
11. 然后再将触摸发送给 Hit-Test View 的 touchesBegan: 等方法。如果手势识别器设置了 delaysTouchesBegan = YES，系统会暂扣 began 及后续 moved 事件，等手势结果确定后再决定补发还是丢弃
12. 手势识别器的识别过程可能跨越多次 RunLoop 迭代，因为很多手势需要多个触摸事件才能判定（如 tap 需等到手指抬起，long press 需等待一段时间，swipe 需判断移动方向和速度）

手势识别结果：

13. 手势识别成功且 cancelsTouchesInView = YES（默认）：系统对 View 发送 touchesCancelled:，View 不再收到后续触摸事件，手势识别器的 action 被触发
14. 手势识别失败：View 继续正常接收后续触摸事件，手势识别器不产生任何 action

UIControl 特殊处理：

15. 如果 Hit-Test View 是系统内置控件（UIButton 等），父视图链上的手势识别器尝试从 Possible 状态转换时，系统会在 Hit-Test View 上调用 gestureRecognizerShouldBegin:（非手势代理方法）。内置控件对与自身交互冲突的父视图手势返回 NO（如 UIButton 阻止单击 tap，UISlider 阻止 swipe），手势识别器直接进入 Failed 状态，控件的 target-action 正常触发
16. UIControl 基类和自定义 UIControl 子类没有重写 gestureRecognizerShouldBegin: 实现，父视图链上的手势识别器正常识别成功后，cancel 掉控件的触摸，导致 target-action 无法触发

响应者链传递（自下而上）：

17. 以上所有能接收触摸事件的对象（UIView、UIViewController、UIWindow、UIApplication）都继承自 UIResponder，touchesBegan:withEvent: 等触摸回调方法正是 UIResponder 定义的。如果 Hit-Test View 不处理事件（触摸回调中调用了 super），事件通过 UIResponder 的 nextResponder 属性沿响应者链向上传递：Hit-Test View → 父 View → … → UIViewController → UIViewController 的父 VC（如有）→ UIWindow → UIApplication → UIApplicationDelegate
18. 链上任意响应者重写了触摸回调且未调用 super，传递终止。如果到达链末端仍无人处理，事件被丢弃

→ 响应者链与事件处理机制

UIButton：只触发按钮的 action，手势不会触发。 UIButton 重写了 gestureRecognizerShouldBegin:，对非自身视图上的单指单击 UITapGestureRecognizer 返回 NO，手势识别器直接进入 Failed 状态，按钮的 target-action 正常触发。

自定义 UIControl：手势会触发，控件的 action 不会触发。 UIControl 基类没有重写 gestureRecognizerShouldBegin:，父视图链上的手势识别器正常识别成功后，cancel 掉控件的触摸，导致 target-action 无法触发。解决方法是在自定义控件中重写 gestureRecognizerShouldBegin: 对冲突手势返回 NO。

→ 响应者链与事件处理机制

不会触发。 虽然 UIControl 重写了 touchesBegan:，但其内部实现会检查 touch.view 是否是自身——UITouch 的 view 属性在 Hit-Testing 阶段就已确定，指向 Hit-Test View。覆盖在上面的 UIView（默认 userInteractionEnabled = YES）会成为 Hit-Test View，即使 UIView 不处理事件、事件通过响应者链传回 UIButton 的 touchesBegan:，此时 touch.view 指向的是覆盖的 UIView，UIButton 不会启动 tracking 流程，action 无法触发。

解决方法是将覆盖视图的 isUserInteractionEnabled 设为 false，使其在 Hit-Testing 中被跳过，Hit-Test View 重新落到 UIButton 上。

→ 响应者链与事件处理机制

扩大按钮的点击区域：按钮太小不好点击时，重写 pointInside:withEvent:，将判定范围扩大到 bounds 之外（例如四周各扩大 10pt），不需要改变按钮的实际 frame。

子视图超出父视图 bounds 仍可点击：默认情况下父视图的 pointInside: 返回 NO 会导致 Hit-Testing 提前终止，子视图即使可见也无法响应。重写父视图的 hitTest:withEvent:，跳过 pointInside: 的限制，直接对子视图坐标转换后递归检查。

穿透遮罩层让下层响应：全屏半透明遮罩层覆盖在内容上，希望空白区域的点击穿透到下方。重写遮罩层的 hitTest:withEvent:，当命中的是自身时返回 nil（穿透），命中子视图时正常返回（遮罩上的关闭按钮等仍可交互）。

利用响应者链实现跨层级通信：UIApplication 的 sendAction:to:from:forEvent: 中 target 为 nil 时，action 会沿响应者链向上查找第一个能响应该 selector 的对象。可以用来实现深层嵌套 Cell 中的按钮事件传递给 ViewController，无需逐层 delegate 或闭包回调。

手势与控件冲突处理：父视图有拖动手势导致子按钮无法响应时，可以通过手势代理的 gestureRecognizer:shouldReceiveTouch: 排除 UIControl 区域，或设置 cancelsTouchesInView = NO 让手势和控件同时响应。

全局点击收起键盘：在根视图或 Window 上添加 UITapGestureRecognizer 并设置 cancelsTouchesInView = NO，点击空白区域时调用 endEditing: 收起键盘，同时不影响其他控件的正常交互。

→ 响应者链与事件处理机制

卡顿的本质是掉帧。iOS屏幕以固定频率刷新（60Hz设备为16.67ms一帧），每次VSync信号到来时，系统从帧缓冲区取出一帧画面显示。如果这一帧的渲染工作没有按时完成，屏幕只能重复显示上一帧，用户就会感知到不流畅。

从渲染管线的角度看，一帧画面的生成横跨三个执行阶段、两个VSync周期。先介绍下Core Animation维护的三棵并行图层树，渲染管线的数据就在它们之间流转：

• Model Tree（模型树）：开发者直接操作的图层属性（layer.position = ...），修改立即生效但不会立刻触发渲染。
• Presentation Tree（呈现树）：存在于App进程中，反映当前屏幕上实际显示的属性值。非动画时与Model Tree同步；动画过程中Model Tree已经是终点值，而Presentation Tree在layer.presentation()被调用时根据本地持有的动画描述信息实时计算当前插值（非Render Server回传）。命中测试（hit testing）应基于Presentation Tree而非Model Tree。
• Render Tree（渲染树）：存在于Render Server进程中的私有副本，是GPU实际渲染所依据的数据源。每次Commit Transaction时，Model Tree的变更通过IPC同步到Render Tree。Render Server在Render Tree上独立计算动画插值，与Presentation Tree各自独立但结果一致。

阶段一：App进程（CPU侧，主线程）

主线程在Handle Events阶段处理触摸事件、手势回调、Timer等，这些回调中的UI修改会立即写入Model Tree并将图层标记为dirty。随后RunLoop在即将休眠时（BeforeWaiting）触发CA::Transaction::commit()，进入Commit Transaction，依次经过四个子阶段：

• Layout：遍历Model Tree中dirty的图层，调用layoutSubviews()求解Auto Layout约束，将frame写回Model Tree。约束复杂度非线性增长，视图层级过深时Layout耗时急剧上升。
• Display：对需要重绘的图层调用draw(_:)，通过Core Graphics在CPU上生成位图（backing store），设置为Model Tree中图层的contents。重写draw(_:)会额外分配大块内存。
• Prepare：处理图片的延迟解码（PNG/JPEG → 位图）和格式转换。未提前在后台线程解码的大图会在这里阻塞主线程。
• Commit：Model Tree → Render Tree的同步点，同时也是Presentation Tree的更新时机。将dirty属性序列化，通过Mach Port（IPC）发送给Render Server更新Render Tree。非动画场景下Presentation Tree在此刻与Model Tree同步；动画场景下动画描述信息保留在App进程本地，后续layer.presentation()据此实时计算插值。图层数量越多，序列化开销越大。

阶段二：Render Server（独立进程）

Render Server（backboardd）接收图层树快照后，将变更合并到Render Tree。对于进行中的动画，直接在Render Tree上按动画曲线计算插值——从插值到渲染指令生成再到GPU提交的整个链路都由Render Server独立驱动，不依赖App进程主线程，这就是Core Animation动画不受主线程卡顿影响的原因。App进程侧的Presentation Tree也能反映动画实时状态，但并非Render Server回传，而是调用layer.presentation()时在App进程内根据相同的动画参数和时间基准本地计算的。动画过程中做命中测试必须使用layer.presentation()而非layer本身（Model Tree早已是终点值）。然后遍历Render Tree，处理图层排序（painter’s algorithm）、可见性剔除、离屏渲染判定，将合成操作翻译为Metal渲染指令（Draw Calls）提交给GPU。

离屏渲染是此阶段的关键性能杀手：cornerRadius + masksToBounds、无shadowPath的shadow、mask、groupOpacity等属性组合会触发离屏渲染，GPU需要分配额外的离屏缓冲区，产生上下文切换和额外的内存带宽开销。

阶段三：GPU渲染

GPU按图形管线依次执行：顶点处理（将CALayer的顶点从模型坐标系变换到屏幕坐标系）→ 图元装配（将顶点组装成三角形图元，一个矩形CALayer被拆成两个三角形，GPU原生只处理三角形）→ 光栅化（将三角形图元转换为离散的片段Fragment，每个Fragment对应一个像素位置并携带插值的纹理坐标）→ 片段着色（根据纹理坐标从纹理中采样颜色，即纹理映射；圆角裁剪、高斯模糊等效果需要更复杂的计算）→ 混合（半透明图层按Result = Source.RGB * Source.A + Dest.RGB * (1 - Source.A)公式叠加，不透明图层可跳过此步直接覆写）。结果写入帧缓冲区。GPU瓶颈主要来自过度绘制（多层半透明重叠导致像素被反复处理）、离屏Pass切换、大纹理上传占用总线带宽。

最终显示

VSync信号到来，前后缓冲区交换（双缓冲机制），屏幕显示新帧。

为什么掉帧？

三个阶段的时间预算是串行叠加的——CPU多消耗1ms，留给GPU的时间就少1ms。在60Hz设备上，CPU + Render Server + GPU的总耗时必须在一个VSync周期（16.67ms）内完成当前帧的准备工作。一旦任何环节超时，帧缓冲区在VSync到来时没有新数据，屏幕重复显示上一帧，即为掉帧。

常见的掉帧原因按瓶颈分类：CPU瓶颈（复杂布局计算、主线程同步IO、大量文本绘制、图片主线程解码）、GPU瓶颈（离屏渲染、过度绘制、超大纹理）、带宽瓶颈（高分辨率图片频繁上传GPU显存）。实际排查时，可通过Instruments的Time Profiler定位CPU热点，GPU Report / Core Animation工具检测GPU负载和离屏渲染，Metal System Trace分析带宽瓶颈。

→ 卡顿原理

卡顿检测方案可以从开发调试和线上监控两个维度来划分，共有6种主要方案，每种方案的原理、适用场景和局限性各不相同。

一、CADisplayLink帧率监控

CADisplayLink是一个与屏幕刷新率同步的定时器。其检测逻辑是：记录每次回调的时间戳，每累计1秒计算一次FPS。FPS低于预期（如低于55）说明存在掉帧。

局限性：

• 只能告诉你"掉帧了"，无法告诉你"哪段代码导致的"
• 主线程阻塞时CADisplayLink的回调本身也会被延迟

适用于开发阶段在悬浮窗实时展示帧率。

二、RunLoop Observer监控

RunLoop在每次循环中经历多个状态：BeforeTimers → BeforeSources → 处理Source0 → BeforeWaiting → 休眠 → AfterWaiting → 处理事件。如果主线程在 BeforeSources 或 AfterWaiting 状态停留过久，说明正在执行耗时任务。

检测方式是在子线程用信号量等待RunLoop状态变化，如果超过阈值（如100ms）仍未收到信号，则判定为卡顿，并通过向主线程发送SIGURG信号触发backtrace来采集主线程的真实堆栈。

需要注意的是，简单方案（单个 Observer，order=0）存在 kCFRunLoopBeforeWaiting 阶段的监控盲区——UI 布局/绘制、手势回调等系统 Observer 在该阶段执行的耗时无法被捕获。微信 Matrix 通过注册两个 Observer（order 分别为 LONG_MIN 和 LONG_MAX）来包裹所有系统 Observer，解决了这个问题。

适用于开发调试和线上监控。

三、子线程Ping方案

子线程每隔一段时间（如1秒）通过DispatchQueue.main.async向主线程派发一个任务，任务内容是将一个标志位设为true。子线程等待超时时间（如2秒）后检查标志位，如果主线程未能在超时时间内执行这个简单任务，说明主线程被阻塞了。

这种方案实现简单，但精度受限于超时阈值的设置，且需要额外实现堆栈采集。适用于线上监控。

四、Instruments系统工具

Instruments提供了三个与卡顿分析相关的核心工具：

• Time Profiler：CPU采样分析，通过调用树（Call Tree）定位耗时函数。关键技巧是开启"Invert Call Tree"（从叶子节点看起）和"Hide System Libraries"（隐藏系统库）
• Core Animation：检测GPU渲染问题，包括FPS、离屏渲染次数等
• System Trace：分析线程调度、锁竞争、I/O等系统级问题

Instruments只能在开发阶段使用，无法部署到线上。

五、MetricKit（iOS 13+）

MetricKit是苹果提供的系统级性能收集框架，特点是零额外开销（数据由系统底层收集）。iOS 13支持每日回调性能指标（如卡顿时间分布直方图），iOS 14+增加了诊断数据回调，可以获取卡顿堆栈（MXCallStackTree）和滚动卡顿率（scrollHitchTimeRatio）。

MetricKit的数据来自真实用户设备，具有很高的参考价值，但不是实时的（每日回调一次），适合用于长期趋势监控而非实时问题定位。

六、Sentry ANR V2（帧延迟分析）

Sentry ANR V2 是一种基于帧延迟（Frame Delay）分析的卡顿检测方案，其核心创新是能够区分完全阻塞和非完全阻塞两种卡顿类型，从而标注堆栈的可信度。

检测架构：

Sentry 的检测由三个组件协作完成：

1. SentryFramesTracker：通过 CADisplayLink 回调，持续记录每一帧的实际渲染耗时。当帧耗时超过慢帧阈值（60Hz 下约 16.67ms）时，将该帧标记为延迟帧，并记录其延迟时长和时间戳。
2. SentryDelayedFramesTracker：存储所有延迟帧的信息，提供按时间区间查询帧延迟的能力。核心 API getFramesDelay(startTimestamp, endTimestamp) 返回两个关键值：
   • delayDuration：时间区间内所有延迟帧的超时部分累加（即每帧实际耗时减去期望耗时的总和）
   • framesContributingToDelayCount：贡献了延迟的帧数量
3. SentryANRTrackerV2：Watchdog 线程，将超时时间（默认2秒）分成5份，每份检查一次帧延迟。根据帧延迟数据判定卡顿类型。

判定逻辑：

Watchdog 线程每 0.4秒（2秒/5）检查一次：

1. 调用 getFramesDelay 获取最近一个检测周期内的帧延迟数据
2. 判定规则：
   - framesContributingToDelayCount == 1 且 delayDuration >= 2秒
     → Fully Blocking（完全阻塞）
   - framesContributingToDelayCount > 1 且 delayDuration > 2秒 × 99%
     → Non-Fully Blocking（非完全阻塞）
   - 其他情况 → 正常，继续监控

两种卡顿类型的区别：

Fully Blocking（完全阻塞）:
0s                                    2s
|-------------------------------------|
|     一个函数A一直占据主线程            |
|     CADisplayLink回调无法触发          |
|     整个周期只产生了1帧延迟            |
                                      └── 采集堆栈 → 指向函数A → 可信

Non-Fully Blocking（非完全阻塞）:
0s        0.5s    0.8s   1.2s   1.5s   2s
|---------|-------|------|------|-------|
|  函数A   |函数B  |函数C  |函数D  |函数E  |
|  慢帧    |慢帧   |慢帧   |慢帧   |慢帧   |
|  5帧都贡献了延迟，累加超过99%阈值       |
                                       └── 采集堆栈 → 指向函数E → 不可信

99%阈值的设计考量：即使应用卡顿0.5秒，中间渲染了约5帧，再卡顿0.5秒，用户仍然有机会响应输入（如点击返回）。此时帧延迟约为97%。只有帧延迟超过99%时，应用才真正"看起来卡住了"。

Sentry的核心价值：它并没有解决堆栈采集时机问题（所有基于超时采集的方案都无法完美解决），而是通过 framesContributingToDelayCount 这个指标让开发者知道：

• 值为1 → Fully Blocking → 堆栈可信，可以直接定位问题
• 值大于1 → Non-Fully Blocking → 堆栈仅供参考，需要结合周期性采样或火焰图进一步分析

七、堆栈采集时机问题与优化

所有基于"超时采集堆栈"的方案（RunLoop Observer、子线程Ping、Sentry ANR等）都面临一个共性问题：超时那一刻采集的堆栈不一定是真正的卡顿元凶。

问题场景（阈值2秒）：

0s                   1.9s  2.0s  2.1s
|---------------------|-----|-----|
|      函数A (1.9s)    |函数B|
                            ↑
                      超时触发采集 → 堆栈指向函数B

但真正的"元凶"是函数A（占了1.9秒）

检测机制是"定时检查"而非"持续监控"，只能在超时那一刻拍一张堆栈快照，无法回溯之前的执行情况。针对这个问题，有以下优化策略：

策略1：周期性采样

不再只在超时时采集一次堆栈，而是在整个检测期间持续高频采集。例如每100ms采集一次主线程堆栈，保留最近N个样本（如50个，覆盖5秒窗口）。当检测到卡顿时，分析这些样本中出现频率最高的调用路径，频率越高越可能是真正的卡顿原因。适用于灰度/测试环境，由于需要持续高频采集堆栈（通过SIGURG信号+backtrace），CPU开销较大，不适合线上全量开启。

策略2：堆栈聚合分析

周期性采样会产生大量堆栈数据，直接上报既浪费带宽又难以阅读。堆栈聚合是对采样数据的二次处理：将多个堆栈样本按调用路径去重，统计每条路径的出现次数，按频率降序排列。聚合后的数据量大大减少，可以直接上报服务端，也可以进一步生成火焰图进行可视化分析。

策略3：退火算法

退火算法解决的是另一个问题：降低检测本身带来的性能损耗。当主线程持续卡顿时（如死锁或超长计算），子线程的检测循环会不断触发堆栈采集，而每次采集的堆栈都是相同的，这些重复采集毫无价值，反而会加剧性能问题。

退火算法的核心思想：当连续检测到相同堆栈时，按斐波那契数列递增检测间隔（1→1→2→3→5→8→13…）；当堆栈发生变化时，重置间隔为1。

退火算法的三个核心优势：

• 避免重复写入：同一个卡顿问题只记录一次，减少存储和上报开销
• 降低CPU负担：主线程已经卡死的情况下，子线程不再频繁采集堆栈，避免雪上加霜
• 线上友好：配合周期性采样使用，可以在保持检测精度的同时将性能开销控制在可接受范围内

策略4：火焰图可视化

火焰图是聚合数据的可视化形式。横轴表示时间占比（或采样次数占比），纵轴表示调用栈深度。函数在横轴上越宽，说明它的采样频率越高，也就越可能是性能瓶颈。火焰图本身不产生运行时开销，它只是对已有采样数据的后处理。通常在服务端将上报的聚合堆栈数据转换为火焰图格式，供开发者在Web平台上查看。

策略5：区分堆栈可信度（Sentry思路）

通过帧延迟分析中的 framesContributingToDelayCount 指标，将卡顿报告标记为"堆栈可信"或"堆栈仅供参考"：

• Fully Blocking（贡献延迟帧数 = 1）：整个检测周期只有一帧没完成渲染，堆栈采集时主线程大概率还在执行同一个函数，堆栈准确
• Non-Fully Blocking（贡献延迟帧数 > 1）：多个函数累积导致的卡顿，超时时刻采集的堆栈只是其中一个，不一定是最耗时的

这种策略的好处是不增加额外的采样开销（基于已有的 CADisplayLink 帧回调数据），同时让开发者对每份卡顿报告有一个预期：Fully Blocking 类型可以直接根据堆栈修复问题，Non-Fully Blocking 类型需要结合周期性采样、火焰图等手段做进一步分析。

→ 卡顿检测

卡顿的原因可以从 CPU瓶颈 和 GPU瓶颈 两个维度来分析，对应的优化方案也围绕这两个方向展开。

一、CPU瓶颈导致的卡顿

CPU阶段的工作集中在App进程的主线程上，包括事件处理、布局计算、文本渲染、图片解码和图层树提交。任何一个环节耗时过长，都会推迟Core Animation在RunLoop BeforeWaiting阶段的渲染事务提交，导致掉帧。

1. 主线程阻塞

主线程承担着事件处理、UI更新、动画执行、系统回调等职责，原则上只应做UI相关的轻量级工作。但实际开发中，以下操作经常阻塞主线程：

• 耗时计算：复杂数据处理、算法运算直接在主线程执行
• 文件I/O：主线程同步读写文件（如 Data(contentsOf:)）
• 数据库操作：主线程执行数据库查询或写入
• 同步网络请求：主线程发起同步HTTP请求

解决方案——任务异步化：将耗时操作移到后台线程，完成后回主线程更新UI。可以使用GCD的不同QoS队列（userInitiated用于计算密集型、utility用于I/O操作、background用于低优先级任务），也可以使用Swift Concurrency的async/await和TaskGroup实现并行处理。

解决方案——任务拆分与调度：当某些工作必须在主线程执行时（比如大量Cell更新），可以将大任务拆分成小块，每处理一批后通过DispatchQueue.main.async让出主线程，在下一个RunLoop周期继续执行。也可以利用RunLoop Observer在BeforeWaiting阶段以最低优先级执行预加载等延迟任务。对于高频触发的操作（如scrollViewDidScroll），使用CADisplayLink节流，将多次请求合并为每帧最多执行一次。

解决方案——去重与条件更新：使用Debounce合并短时间内的多次更新请求（如搜索输入框）；使用条件判断跳过值未变化的更新；检查视图可见性，只对屏幕上可见的视图执行更新。

2. 锁竞争

后台线程持有锁执行耗时操作时，主线程请求同一把锁会被阻塞，直到后台线程释放锁才能继续。

解决方案——使用读写锁：用pthread_rwlock_t或GCD并发队列+barrier实现读写分离，允许多个读操作并发执行，写操作独占。推荐使用GCD barrier方式，代码更简洁且不易出错。

解决方案——减少锁粒度：将一把粗粒度的大锁拆分为多把细粒度锁，让操作不同数据的线程不互相阻塞。对于简单的计数器等场景，使用os_unfair_lock这种轻量级锁。

解决方案——使用串行队列替代锁：用串行DispatchQueue保证数据访问的线程安全，避免手动管理锁。

3. 复杂布局计算

大量Auto Layout约束、频繁的layoutSubviews调用、深层的视图嵌套都会导致布局计算耗时。Auto Layout的时间复杂度随约束数量增长，在复杂页面中可能成为瓶颈。

解决方案——预计算与缓存：在后台线程预先计算布局信息（如文本高度、Cell高度），将结果缓存起来供主线程直接使用。对于TableView/CollectionView，预计算并缓存每个Cell的高度，避免滚动时重复计算。

解决方案——手动布局替代Auto Layout：在性能敏感的场景（如高频滚动的Cell），使用手动frame计算替代Auto Layout约束。

解决方案——使用第三方布局库：Texture（AsyncDisplayKit）的Flexbox布局在后台线程执行，性能优于Auto Layout；IGListKit的自动Diff算法只更新变化的Cell。

4. 图片解码

图片文件（PNG/JPEG）是压缩格式，GPU需要位图（Bitmap）才能渲染。默认情况下，UIImage加载图片时不会立即解码，而是在Core Animation Commit Transaction的Prepare阶段才在主线程进行解码。一张1000x1000的RGBA图片解码后占4MB内存，大图的解码开销显著。

解决方案——异步解码：在后台线程提前进行图片解码。可以通过创建CGContext并绘制图片来强制触发解码，也可以使用ImageIO的kCGImageSourceShouldCacheImmediately选项立即解码，或使用UIGraphicsImageRenderer进行解码。

解决方案——图片降采样：当显示尺寸远小于原图尺寸时（如4000x4000的图显示在100x100的视图上），使用ImageIO的CGImageSourceCreateThumbnailAtIndex按目标尺寸加载，避免解码和存储完整原图。一张4000x4000的图片原本需要64MB内存，降采样到100x100后只需40KB。

解决方案——多级缓存：建立内存缓存（NSCache，快速访问但容量有限）→ 磁盘缓存（文件系统，持久化但需要解码）→ 网络请求的三级缓存架构。内存缓存应设置countLimit和totalCostLimit，并监听内存警告及时清理。

解决方案——使用成熟的图片库：SDWebImage、Kingfisher、Nuke等第三方库已经集成了异步解码、降采样、多级缓存、渐进式加载、预取等所有优化策略，推荐直接使用。

5. 文本渲染

复杂富文本、大量文本的排版和渲染在CPU端开销较大，包括字体查找、字形排版、行断行计算等。

解决方案——文本缓存：使用NSCache缓存计算好的NSAttributedString，避免重复创建。

解决方案——异步文本计算：使用TextKit在后台线程进行文本排版（NSTextStorage + NSLayoutManager + NSTextContainer），计算完成后回主线程显示。YYText等第三方库提供了成熟的异步文本布局和渲染方案。

二、GPU瓶颈导致的卡顿

Render Server将图层树翻译为Metal渲染指令后提交给GPU，由GPU执行实际的像素渲染并将结果写入帧缓冲区。GPU瓶颈主要来自离屏渲染和过度绘制。

1. 离屏渲染

离屏渲染是GPU无法一次性完成渲染时，需要先渲染到离屏缓冲区再合成到帧缓冲区的过程。额外的缓冲区创建、上下文切换、合成操作以及对GPU渲染流水线的打断，都带来了性能开销。

常见触发条件：cornerRadius + masksToBounds（圆角裁剪）、未指定shadowPath的阴影、layer.mask遮罩、allowsGroupOpacity组透明度、UIBlurEffect毛玻璃效果。

圆角优化方案：

• 只设置cornerRadius不设置masksToBounds——圆角仅作用于backgroundColor和border，不裁剪contents和子图层，不触发离屏渲染。适用于纯色背景的控件。
• 使用云服务裁剪——让服务端或CDN在URL参数中处理圆角（如阿里云OSS的?x-oss-process=image/rounded-corners,r_20），客户端直接显示已处理的图片，零GPU开销。
• CPU预处理圆角——在后台线程使用UIBezierPath + UIGraphicsImageRenderer裁剪出圆角图片，然后直接显示。把GPU的裁剪操作提前到CPU阶段，代价是增加CPU开销和额外内存。
• 封装RoundedImageView组件——将上述逻辑封装为自定义ImageView，自动在后台处理圆角，对外提供简单接口。

阴影优化方案：

• 指定shadowPath——明确告诉系统阴影的形状（如UIBezierPath(rect:)或UIBezierPath(roundedRect:cornerRadius:)），避免系统遍历像素计算轮廓。需要在layoutSubviews中同步更新。
• 使用预制的阴影图片——用设计好的9-patch阴影图片代替实时计算的阴影，GPU直接渲染静态图片。

遮罩优化方案：

• 使用预渲染图片——在后台线程用Core Graphics将遮罩效果预先应用到图片中，生成一张已裁剪的位图。不适合遮罩形状动态变化的场景。
• 使用blend mode——在draw(_:)方法中通过Core Graphics混合模式实现遮罩效果，避免使用layer.mask。

透明度优化：

• 关闭allowsGroupOpacity，让子视图独立计算透明度。
• 将透明度应用到backgroundColor（如UIColor.white.withAlphaComponent(0.5)），而非视图的alpha属性。

毛玻璃优化：

• 使用云服务处理——网络图片的模糊效果让CDN处理（如OSS的?x-oss-process=image/blur,r_50,s_50）。
• 使用静态模糊图片——背景不变时，在后台用CIGaussianBlur生成模糊图片代替实时模糊。
• 降低模糊区域分辨率——先缩小截图再模糊后放大，减少计算量。
• 控制UIVisualEffectView的大小和数量——尽量在小区域使用。

2. shouldRasterize光栅化

shouldRasterize是主动触发离屏渲染的优化手段：将复杂图层渲染为位图缓存，后续帧直接使用缓存。适用于内容不频繁变化的复杂视图（如带阴影和圆角的卡片），本质是空间换时间。需要设置rasterizationScale = UIScreen.main.scale避免Retina屏幕模糊。如果内容频繁变化，缓存会不断失效重建，反而更慢。

三、TableView/CollectionView列表场景优化

列表滚动是用户最敏感的交互场景，每帧16.67ms内需要完成可见Cell计算、复用/创建、内容配置和渲染提交。

Cell复用：正确注册Cell并使用dequeueReusableCell(withIdentifier:for:)，在prepareForReuse中重置状态并取消进行中的异步任务（如图片加载）。

高度缓存：预计算所有Cell高度并缓存到字典中，避免滚动时重复计算。也可以设置estimatedRowHeight配合automaticDimension，在willDisplay中缓存实际高度供后续使用。如果所有Cell高度相同，直接设置固定rowHeight性能最好。

异步渲染：将Cell的文本、图形等复杂内容在后台线程绘制到位图（使用UIGraphicsImageRenderer），回主线程后直接赋值给layer.contents。每次配置新Item时取消上一次的渲染任务，避免复用Cell显示错乱。

预加载：实现UITableViewDataSourcePrefetching协议，在prefetchRowsAt中预加载即将显示的Cell的图片等资源，在cancelPrefetchingForRowsAt中取消已不需要的预加载。也可以自定义预加载范围（如可见区域前后各10个Cell）。

减少视图层级：过多的子视图会增加布局和渲染开销。可以将多个子视图合并绘制到单个CALayer上（异步绘制为位图），减少GPU的图层合成压力。

Diff更新：使用UITableViewDiffableDataSource或IGListKit的Diff算法，只更新实际变化的Cell，避免reloadData导致全量刷新。

快速滚动优化：检测滚动状态，快速滚动时只显示占位内容，停止滚动后再渲染完整内容。

分页加载：监听滚动位置，在接近底部时异步加载下一页数据，使用insertRows增量更新而非全量刷新。

卡顿检测方案（CADisplayLink、RunLoop Observer、子线程Ping、Instruments、MetricKit、Sentry ANR V2）以及堆栈采集时机问题的优化策略，详见上方「Q: 如何检测iOS应用的卡顿？有哪些检测方案？」。

→ 卡顿原理 · 卡顿检测 · 主线程优化 · 图片优化 · 离屏渲染 · TableView优化

从程序内存布局的角度，iOS应用的内存分为以下区域：

• 栈区（Stack）：存储局部变量、函数参数和返回地址，由系统自动管理，先进后出
• 堆区（Heap）：存储动态分配的对象实例，通过引用计数管理
• 全局/静态区（BSS/Data）：存储全局变量和静态变量，程序启动时分配
• 常量区（Rodata）：存储字符串常量等只读数据
• 代码区（Text）：存储编译后的机器码

从系统内存管理的角度，iOS将内存分为三类：

Memory Footprint = Dirty Memory + Compressed Memory

这是iOS衡量应用内存使用的核心指标。Clean Memory不计入footprint，因为系统可以随时回收。当footprint超过系统限制时，应用会被终止。优化内存主要关注减少Dirty Memory。

→ iOS中的内存管理

内存分配差异：

值类型的逃逸：当值类型需要在创建它的函数作用域之外存活时，编译器会将其分配到堆上。常见场景包括：被逃逸闭包捕获、被存储到堆上的属性中、通过函数返回值逃逸。

协议类型变量的隐式堆分配：Swift中将值类型赋值给协议类型变量时（如let shape: Shape = Circle()），会通过存在容器（Existential Container）包装。存在容器内有24字节的内联缓冲区，小于等于24字节的值直接内联存储，超过则触发堆分配。这意味着即使是值类型，通过协议类型持有时也可能产生堆分配开销——这是Objective-C中不存在的场景（ObjC的协议类型本质上只是id指针）。

写时拷贝（Copy-on-Write）：Swift对Array、Dictionary、Set等集合类型实现了写时拷贝优化。赋值时多个变量共享同一份底层存储，只有在修改时才触发真正的拷贝，兼顾了值语义的安全性和性能。

ARC实现差异：

Swift编译器的ARC优化：

1. 栈提升（Stack Promotion）：通过逃逸分析，当编译器证明对象不会逃逸出当前函数时，将堆分配优化为栈分配，完全消除ARC开销

2. 引用计数消除（RC Elimination）：编译器分析引用的生命周期，消除不必要的retain/release配对。例如函数内部的临时引用、连续赋值等场景

3. 内联引用计数：纯Swift类的引用计数直接存储在对象头部，无需查找SideTable，原子操作更高效

→ iOS中的内存管理 → 值类型和引用类型的区别

引用计数是iOS管理堆内存的核心机制：

• 每个对象维护一个引用计数器
• 当有新的强引用指向对象时，计数+1
• 当强引用被移除时，计数-1
• 当计数变为0时，对象被销毁并释放内存

Objective-C对象的引用计数采用两级存储策略：

1. isa内嵌存储（小引用计数）： 在Non-Pointer isa模式下，extra_rc字段直接存储引用计数减1后的值。arm64架构下为19位，最多可表示524288的引用计数。

2. 侧表存储（大引用计数）： 当extra_rc溢出时，has_sidetable_rc标记为1，引用计数转存到SideTable结构体中的RefcountMap哈希表中，支持任意大小的引用计数。对于传统指针isa（32位系统），引用计数也存储在侧表中。

纯Swift类的引用计数直接存储在对象头部的RefCount字段中，无需SideTable，访问更高效。

→ iOS中的内存管理 → Objective-C底层原理-NSObject → Swift底层原理-结构体、类和协议

使用weak的场景：

• delegate属性，避免循环引用
• IBOutlet连接的UI控件（已被父视图强引用）
• Block中引用self时，配合strong-weak dance

→ iOS中的内存管理

循环引用：两个或多个对象相互强引用，导致引用计数永远无法归零，造成内存泄漏。

常见场景：

1. 两个对象互相持有对方
2. Block捕获self，而self又持有Block
3. delegate使用strong修饰
4. NSTimer被target强引用

解决方案：

1. 使用weak或unowned打破循环
2. Block中使用__weak/[weak self]
3. 在适当时机手动断开引用（如viewDidDisappear中invalidate timer）

→ iOS中的内存管理

A: weak通过Runtime的SideTable + weak_table + weak_entry三层结构实现。

数据结构层面：系统维护一个固定大小的SideTable数组（StripedMap），通过对象地址哈希取模定位到其中一个SideTable。由于对象数量远大于SideTable数量，多个对象会映射到同一个SideTable——这样设计的核心目的是分散锁竞争，每个SideTable拥有独立的os_unfair_lock，不同SideTable上的操作可以并行执行。每个SideTable内含一个weak_table_t——这是一个以对象地址为key的开放寻址哈希表（线性探测，用mask做快速取模，用max_hash_displacement限制探测范围）。表中每个weak_entry_t对应一个被弱引用的对象，记录了指向该对象的所有弱引用指针地址（≤4个时内联存储，超过则切换为动态哈希表）。

创建 weak 引用：编译器将__weak id weakPtr = obj转换为objc_initWeak(&weakPtr, obj)，内部调用storeWeak。storeWeak通过对象地址哈希定位SideTable并加锁，然后调用weak_register_no_lock在weak_table中查找或创建该对象的weak_entry，将&weakPtr添加到entry的referrers中，并设置对象isa中的weakly_referenced标志位。

读取 weak 引用：编译器将id obj = weakPtr转换为objc_loadWeakRetained(&weakPtr)，内部通过无锁的do-while重试循环读取指针并尝试rootTryRetain()，成功则返回对象（调用方稍后release），失败且*location已被置nil则返回nil。

对象析构时清理：dealloc → rootDealloc（检查isa标志位）→ 慢速路径 → clearDeallocating_slow → weak_clear_no_lock。该函数查找对象的weak_entry，遍历所有弱引用指针执行*referrer = nil，最后移除该entry。

→ weak详解

典型代码如下：

__weak typeof(self) weakSelf = self;
view.action = ^{
    [weakSelf action];
};

和：

__weak typeof(self) weakSelf = self;
view.action = ^{
    __strong typeof(weakSelf) strongSelf = weakSelf;
    [strongSelf action];
};

两者都能避免Block强持有self导致的循环引用。区别在于：直接使用weakSelf是每次使用时读取弱引用；转成strongSelf是先从弱引用中取出对象并强持有，在当前作用域内复用这个稳定对象。

底层上，[weakSelf action]并不是直接对裸指针发消息。ARC通常会把一次weak读取转换为类似逻辑：

id tmp = objc_loadWeakRetained(&weakSelf);
objc_msgSend(tmp, @selector(action));
objc_release(tmp);

objc_loadWeakRetained会从weak引用位置读取对象，并尝试retain成功后返回，保证这一次消息发送期间对象不会释放。如果对象已经在释放或weak引用已被清零，则返回nil。

而strongSelf写法大致是：

id strongSelf = objc_loadWeakRetained(&weakSelf);
objc_msgSend(strongSelf, @selector(action));
objc_release(strongSelf); // 作用域结束时由ARC插入

如果Block里只有一次weakSelf访问，两种写法底层差异很小，通常都会读取一次weak引用。strongSelf版本只是把这次读取结果保存为局部强引用，保活范围更明确。

如果Block里多次访问：

[weakSelf step1];
[weakSelf step2];
[weakSelf step3];

通常会发生多次weak读取，每次都可能调用类似objc_loadWeakRetained的逻辑。

id tmp1 = objc_loadWeakRetained(&weakSelf);
objc_msgSend(tmp1, @selector(step1));
objc_release(tmp1);

id tmp2 = objc_loadWeakRetained(&weakSelf);
objc_msgSend(tmp2, @selector(step2));
objc_release(tmp2);

id tmp3 = objc_loadWeakRetained(&weakSelf);
objc_msgSend(tmp3, @selector(step3));
objc_release(tmp3);

strongSelf写法则只读取一次weak引用：

id strongSelf = objc_loadWeakRetained(&weakSelf);

objc_msgSend(strongSelf, @selector(step1));
objc_msgSend(strongSelf, @selector(step2));
objc_msgSend(strongSelf, @selector(step3));

objc_release(strongSelf);

→ weak详解

A: 这依赖于对象析构时Runtime的主动清理机制，完整调用链如下：

-[NSObject dealloc]
  → _objc_rootDealloc → rootDealloc()
    ├── 快速路径：isa标志位全为false（无弱引用/关联对象/SideTable引用计数）→ 直接free
    └── 慢速路径：object_dispose → objc_destructInstance
          → clearDeallocating() → clearDeallocating_slow()
                ├── weak_clear_no_lock()  // 清理弱引用
                └── refcnts.erase()       // 清理SideTable引用计数

关键在于rootDealloc()中的快速路径判断：通过检查isa中的weakly_referenced标志位，只有该标志为true时才会走慢速路径进入weak_clear_no_lock。

weak_clear_no_lock的具体操作：

1. 以对象地址为key，在weak_table中通过哈希查找对应的weak_entry
2. 根据entry的out_of_line_ness标志判断使用内联数组还是动态数组
3. 遍历所有弱引用指针地址，校验*referrer == referent后执行*referrer = nil
4. 从weak_table中移除该entry

整个清理过程在SideTable锁的保护下进行，保证了与其他线程的storeWeak、objc_loadWeakRetained等操作的线程安全。

→ weak详解

A: 两者都不增加引用计数，核心区别在于：

• weak：对象释放后自动置nil，必须声明为Optional，有注册/清理的额外开销。适用于对象可能随时被释放的场景（如delegate）。
• unowned：对象释放后不置nil，不需要Optional。默认的unowned(safe)在访问已释放对象时触发确定性崩溃（而非野指针），依赖Swift对象头中的unowned引用计数实现"僵尸状态"检测。适用于确定被引用对象生命周期 >= 当前对象的场景。

→ weak详解

A: 两者在对象布局、弱引用存储方式和置nil时机上都有显著差异。

对象布局不同：OC对象以isa开头，引用计数溢出时才存入SideTable；纯Swift类以HeapObject为基础，包含metadata（等效isa）和InlineRefCounts（8字节，内联编码strong/unowned引用计数）。

弱引用存储路径不同：

• OC：对象地址 → StripedMap哈希 → SideTable → weak_table → weak_entry，weak指针直接指向对象
• Swift：首次创建weak引用时，Runtime分配HeapObjectSideTableEntry（包含完整引用计数和对象指针），将对象的InlineRefCounts替换为指向该entry的指针。weak变量存储的是entry指针而非对象指针，读取时需通过entry间接获取对象

置nil时机不同：

• OC：对象dealloc时同步遍历weak_entry将所有弱引用指针置nil
• Swift：延迟置nil——dealloc时不主动清理，而是在下一次读取weak变量时检查strong count是否为0，如果已释放则返回nil

native vs non-native：编译器根据类的继承关系在编译期决定路径——纯Swift类走上述HeapObject路径，继承自NSObject或OC类的Swift类则退回到OC的SideTable + weak_table路径，行为与OC weak完全一致。

→ weak详解

Autorelease Pool（自动释放池）是iOS内存管理中的一种延迟释放机制。当对象被标记为autorelease时，它不会立即释放，而是被注册到当前的autoreleasepool中，等到池销毁时统一调用release。

释放机制：

// 立即释放 - 方法结束时释放，不经过autoreleasepool
NSObject *obj = [[NSObject alloc] init];

// 延迟释放 - 等待autoreleasepool销毁
NSString *str = [NSString stringWithFormat:@"hello"];

在现代ARC代码中，编译器会进行"autorelease elision"优化，进一步减少autorelease对象的数量，因此大部分对象都是立即释放的。

@autoreleasepool {}的底层是通过AutoreleasePoolPage类实现的：

数据结构特点：

• 每个page大小为4096字节（一个虚拟内存页），约可存储505个对象指针
• 多个page通过parent/child指针形成双向链表
• page内部是一个栈结构，next指针指向栈顶
• 每个线程有独立的autoreleasepool（通过TLS存储hotPage）

POOL_BOUNDARY（哨兵对象）：

• 值为nil，是一个特殊标记
• 每次进入@autoreleasepool {时，push一个POOL_BOUNDARY
• 退出}时，从栈顶开始对每个对象调用release，直到遇到对应的POOL_BOUNDARY
• 这种设计支持autoreleasepool的嵌套使用

@autoreleasepool {        // push POOL_BOUNDARY_1
    NSString *a = ...;    // push a
    @autoreleasepool {    // push POOL_BOUNDARY_2
        NSString *b = ...; // push b
    }                      // pop到POOL_BOUNDARY_2，释放b
}                          // pop到POOL_BOUNDARY_1，释放a

autorelease操作流程：

1. 调用autorelease：对象调用autorelease方法，实际执行objc_autorelease()
2. 获取当前page：通过TLS获取当前线程的hotPage
3. 添加对象：
   • 快速路径：page有空间，直接存入next位置，next++
   • 慢速路径：page已满，创建新page作为child节点
4. 释放时机：作用域结束时调用objc_autoreleasePoolPop()，逐个release直到遇到POOL_BOUNDARY

主线程的autoreleasepool由RunLoop自动管理：

• kCFRunLoopEntry：创建pool
• kCFRunLoopBeforeWaiting：释放旧池、创建新池（autorelease对象在此释放）
• kCFRunLoopExit：释放pool

→ iOS中的内存管理

当应用收到didReceiveMemoryWarning内存警告时，开发者通常会尝试清理缓存来释放内存。但需要注意避免"先解压再释放"的陷阱。

iOS的内存压缩机制会将长时间未访问的Dirty Memory压缩。如果你在收到内存警告时遍历并释放这些已压缩的数据，系统必须先将其解压才能释放。这意味着清理操作会先临时增加内存使用（解压后的数据比压缩的更大），然后才能释放——可能适得其反地加剧内存压力，同时CPU使用率急剧上升可能造成卡顿。

推荐使用NSCache替代手动缓存管理。NSCache是Apple推荐的缓存方案，它内部实现了对内存压力的智能响应——系统内存紧张时自动清理部分内容，且优先清理未压缩的、访问频率低的数据，避免了手动管理可能带来的问题。

→ iOS中的内存管理

检测工具：

1. Instruments - Leaks：检测循环引用导致的内存泄漏
2. Instruments - Allocations：分析内存分配情况，查找内存增长点
3. Memory Graph Debugger：Xcode内置，可视化查看对象引用关系
4. MLeaksFinder（第三方）：运行时自动检测UIViewController泄漏

排查步骤：

1. 使用Memory Graph查看对象引用关系，找到循环引用
2. 检查delegate是否使用了weak
3. 检查Block中是否正确处理了self
4. 检查Timer、NotificationCenter是否正确移除
5. 使用Instruments的Allocations追踪内存增长

→ iOS中的内存管理

Coffman 死锁四个必要条件是：互斥、持有并等待、不可抢占、循环等待。破坏任一即可：

• 破互斥：用读写锁、无锁结构、值类型
• 破持有并等待：一次性申请所有资源，或 tryLock + 回退
• 破不可抢占：加锁超时、可取消任务
• 破循环等待：全局加锁顺序（最常用，如按地址排序）

→ 死锁

sync 把 block 排到队列尾部，阻塞当前线程等它完成。主队列是串行的，如果调用方当前就在主线程，主线程就会卡在 sync，而主队列需要等当前任务完成才能调度这个 block，形成循环等待。

不死锁的情况：在子线程调用 main.sync（当前线程不是主队列的执行线程，可以阻塞等待）。

→ 死锁

1. GCD 串行队列对自身 sync

   这是最经典的场景。比如主线程调用 DispatchQueue.main.sync {}，或者某个自定义串行队列正在执行任务时又调用同一个队列的 queue.sync {}。因为串行队列一次只能执行一个任务，当前任务不结束，后面的 sync block 就无法执行；而当前任务又在等待 sync block 完成，于是形成死锁。

   // 主线程执行时会死锁
   DispatchQueue.main.sync {
       updateUI()
   }
   
   let queue = DispatchQueue(label: "cache.queue")
   queue.async {
       queue.sync {     // 同一个串行队列 sync 自己
           saveCache()
       }
   }
   

2. 锁的循环等待

   线程 A 持有 lockA 后等待 lockB，线程 B 持有 lockB 后等待 lockA。这同时满足"持有并等待"和"循环等待"两个条件，是最标准的死锁模型。多把锁没有统一加锁顺序时尤其容易出现。

   let lockA = NSLock()
   let lockB = NSLock()
   
   DispatchQueue.global().async {
       lockA.lock()
       lockB.lock()     // 等线程 B 释放 lockB
   }
   
   DispatchQueue.global().async {
       lockB.lock()
       lockA.lock()     // 等线程 A 释放 lockA
   }
   

3. 非递归锁的同线程重入

   NSLock、默认 pthread_mutex_t、os_unfair_lock 都不是递归锁。同一线程已经持有锁后，如果调用链再次进入同一把锁，就会卡住。例如 public 方法加锁后调用另一个也会加同一把锁的 public 方法。修复时通常把公共逻辑抽到不加锁的 private 方法，或者在确实需要递归语义时使用 NSRecursiveLock。

   final class Store {
       private let lock = NSLock()
   
       func update() {
           lock.lock()
           defer { lock.unlock() }
           reload()       // reload 内部再次 lock
       }
   
       func reload() {
           lock.lock()    // 同一线程重入 NSLock，死锁
           defer { lock.unlock() }
       }
   }
   

4. 用 DispatchSemaphore.wait() 把异步接口同步化

   常见于把网络请求、Core Bluetooth、WKWebView evaluateJavaScript、delegate 回调等异步接口包装成同步返回。如果调用方所在队列正在 wait()，而 signal() 又必须回到同一条串行队列执行，就会永远等不到信号。现代 Swift 代码应优先用 async/await 或 continuation 做桥接。

   func syncFetch() -> Data? {
       let sem = DispatchSemaphore(value: 0)
       var result: Data?
   
       asyncFetch { data in
           DispatchQueue.main.async {
               result = data
               sem.signal()
           }
       }
   
       sem.wait()        // 如果在主线程调用，main.async 无法执行
       return result
   }
   

5. FMDB / Core Data 嵌套队列

   FMDB 的 inDatabase: / inTransaction: 和 Core Data 的 performAndWait: 本质上都可能依赖串行队列同步执行。如果在同一个数据库队列或同一个 NSManagedObjectContext 的 performAndWait: 内部再次调用同步 API，就等价于串行队列 sync 自身。

   context.performAndWait {
       updateObject()
   
       context.performAndWait {   // 同一个 context 嵌套同步执行
           saveObject()
       }
   }
   

6. 持锁时调用外部回调、发通知或派发同步任务

   锁内执行用户闭包、通知回调、delegate、KVO 等不可控代码非常危险。外部代码可能反向调用当前对象，也可能申请另一把锁，从而形成重入死锁或跨线程循环等待。正确做法是锁内只读写共享状态、生成快照，锁外再执行回调。

   final class EventCenter {
       private let lock = NSLock()
       private var observers: [() -> Void] = []
   
       func notify() {
           lock.lock()
           observers.forEach { $0() }  // 回调里可能再次调用 add/notify
           lock.unlock()
       }
   
       func add(_ observer: @escaping () -> Void) {
           lock.lock()
           observers.append(observer)
           lock.unlock()
       }
   }
   

7. +initialize、+load 或初始化路径中的跨类依赖

   Objective-C runtime 在执行 +initialize 时有内部锁保护。如果类 A 初始化时触发类 B，类 B 初始化又反向依赖类 A，在多线程同时触发时可能形成死锁。初始化逻辑应保持简单，只初始化自己，跨模块依赖挪到首次使用或显式启动流程中。

   @implementation ClassA
   + (void)initialize {
       [ClassB warmup];   // A 初始化依赖 B
   }
   @end
   
   @implementation ClassB
   + (void)initialize {
       [ClassA warmup];   // B 初始化又反向依赖 A
   }
   @end
   

8. 主线程等待后台线程持有的锁，最终触发 watchdog

   这种情况未必是经典 Coffman 死锁，但用户感知等价：主线程卡在 os_unfair_lock_lock、pthread_mutex_lock、semaphore_wait 等位置，后台线程持锁执行长耗时任务，导致界面长时间无响应，最终被系统 watchdog 强杀。

   let lock = NSLock()
   
   DispatchQueue.global().async {
       lock.lock()
       Thread.sleep(forTimeInterval: 10)   // 持锁做长耗时任务
       lock.unlock()
   }
   
   DispatchQueue.main.async {
       lock.lock()                         // 主线程长时间等待
       lock.unlock()
   }
   

9. 异常处理或 signal handler 中再次申请锁

   崩溃采集、signal handler、异常处理路径如果调用 malloc、NSLog、Objective-C runtime、dyld 等非 async-signal-safe API，可能在所有线程被挂起或原线程已持锁时再次申请同一把锁，造成采集链路自身死锁。

   void handleSignal(int sig) {
       // 错误示例：NSLog / malloc / Objective-C runtime 都不是 signal-safe
       NSLog(@"crash signal: %d", sig);
   }
   

10. Swift Concurrency 误用

    actor 的可重入设计能减少传统锁死锁，但不代表不会卡死。常见风险包括：在 actor 中用信号量同步等待异步任务、Task 之间互相等待、把传统锁和 actor 隔离混用、在 MainActor 上等待需要回到主线程完成的任务。新并发代码要避免"同步等异步"，并保持锁、actor、队列的边界清晰。

    @MainActor
    func loadSync() {
        let sem = DispatchSemaphore(value: 0)
    
        Task { @MainActor in
            updateUI()
            sem.signal()
        }
    
        sem.wait()   // MainActor 被阻塞，Task 无法继续执行
    }
    

→ 死锁

死锁治理不是简单写几条编码规范，而是一套闭环：事前降低引入概率，事中及时发现并保留现场，事后完成归因、修复和防劣化。规范、Lint、Code Review 属于事前准入；线上监控、抓栈、分型、灰度验证和规则回灌，才构成完整治理。

事前：预防与准入

1. 选择更安全的并发模型

   新 Swift 代码优先使用 actor、async/await、@MainActor、值类型、copy-on-write 或串行队列封装状态，减少共享可变状态和显式锁的暴露面。锁越少，形成循环等待的机会越少。

2. 统一加锁顺序，破坏循环等待

   如果一段代码可能同时拿多把锁，必须定义全局顺序，比如按模块层级、资源 id、对象地址排序。所有代码都按同一顺序加锁、反向释放，避免线程 A 拿 A 等 B、线程 B 拿 B 等 A。

3. 缩短临界区，避免持有并等待

   临界区只做共享状态读写，不做 I/O、网络、数据库大事务、图片解码、复杂计算，也不在持锁时等待另一个锁、队列、信号量或异步任务。能先准备数据再加锁提交，就不要锁住整个流程。

4. 锁内不调用外部代码

   不在锁内调用用户闭包、delegate、通知、KVO、block 回调或可被子类重写的方法。锁内复制快照，锁外再回调。这样可以避免外部代码重入当前对象，也避免把当前锁和调用方内部锁串成不可控依赖。

5. 避免同步等待异步结果

   不把异步 API 包成 sem.wait() 或 DispatchGroup.wait() 的同步 API，尤其不能在主线程或回调所在串行队列上等待。需要桥接旧接口时优先用 withCheckedContinuation，让调用方通过 await 挂起，而不是阻塞线程。

6. 建立团队红线和 Code Review 清单

   明确禁止主线程 semaphore.wait()、禁止串行队列 sync 自身、禁止 performAndWait 嵌套、禁止持锁发通知、禁止 +initialize 跨类依赖。凡是引入多把锁、信号量、条件变量、performAndWait 的改动，都应作为并发风险重点审查，并通过 SwiftLint、pre-commit、TSan CI、Swift 严格并发检查等工具落地。

事中：检测、保护与现场保留

1. 建立主线程卡死监控

   通过 RunLoop observer、主线程 ping、MetricKit、Sentry App Hangs 或自研卡死监控判断主线程是否长时间无响应。卡死发生时要抓全线程堆栈、线程状态、队列 label、CPU 使用情况和关键寄存器。

2. 等待必须有超时和失败路径

   对信号量、条件变量、跨线程等待尽量设置超时；能用 tryLock 的地方，用失败回退代替无限等待。超时不是为了吞掉问题，而是为了避免主线程永久阻塞，并记录锁等待耗时、线程 id、队列 label、业务上下文。

3. 主线程路径特殊保护

   主线程不应该等待后台长任务或不可控锁。必须回主线程的同步封装要先判断是否已经在主线程；UI 状态用 @MainActor 约束，避免后台线程拿 UI 锁或主线程等待后台锁。

4. 高风险封装加断言和埋点

   数据库队列、缓存锁、同步桥接层可以记录当前队列 label、线程 id、锁等待耗时，并在 Debug 下断言"不能从同一队列同步进入"。线上则控制采样，避免监控本身引入性能问题。

5. 监控链路自身要安全

   卡死和崩溃采集路径不能调用 malloc、NSLog、Objective-C runtime、dyld 等非 async-signal-safe API，避免在所有线程被挂起时引入二次死锁。

事后：归因、修复与防劣化

1. 先区分死锁、死循环和单纯耗时

   死锁通常表现为相关线程 CPU 接近 0，线程状态处于 WAITING/BLOCKED，栈顶常见 __psynch_mutexwait、semaphore_wait_trap、dispatch_sync_wait、os_unfair_lock_lock。死循环通常 CPU 高，线程处于 running；单纯耗时则可能有 I/O、计算或主线程大任务堆栈。

2. 做全线程堆栈聚合和死锁图分析

   只看主线程不够，必须找到"主线程在等谁、那个线程又在等谁"。能拿到锁 owner 时，可以建立"线程等待锁、锁被线程持有"的有向图，判定是否存在环路。不能自动判环时，也要通过队列 label、锁函数、业务栈聚合定位高频调用链。

3. 按根因修复并补测试

   修复不应只是在某处加超时。要回到根因：统一锁顺序、拆掉同步等待、缩短临界区、把锁内回调挪到锁外、把嵌套 performAndWait 改成异步或分层 API。能复现的死锁要补单元测试、并发压力测试或 TSan 测试任务。

4. 灰度验证和指标回看

   修复后通过灰度观察卡死率、watchdog 崩溃率、App Hang 数量、受影响页面和版本分布。死锁类问题要看趋势而不是单点，因为它通常依赖时序，低频但影响严重。

5. 把事故复盘回灌到准入体系

   把事故复盘变成工程规则：SwiftLint / pre-commit 禁止危险 API，用 CI 跑 TSan Job，把高风险并发 API 列入 Code Review checklist，并在基础库中提供安全封装，减少业务层直接操作锁、信号量和同步队列的机会。

→ 死锁

**自旋锁（Spin Lock）**在等待锁时不会让线程休眠，而是持续忙等（busy-wait），不断检查锁是否可用。优点是没有线程切换开销，临界区极短时性能好；缺点是等待期间持续占用 CPU。

OSSpinLock 被废弃是因为在 iOS 的线程调度机制下会触发优先级反转（Priority Inversion）：

1. 低优先级线程获取了自旋锁，开始执行临界区
2. 高优先级线程需要同一把锁，开始自旋等待（忙等，持续占用 CPU）
3. 中优先级线程抢占了低优先级线程的 CPU 时间（中 > 低），导致低优先级线程迟迟无法执行完释放锁
4. 结果：高优先级线程空转浪费 CPU，低优先级线程分不到时间片无法释放锁，形成类似死锁的活锁

这个问题的关键在于：自旋锁的忙等让高优先级线程霸占了 CPU，而调度器因为高优先级线程"正在运行"而不会调度低优先级线程，锁就永远释放不了。

替代方案：

• os_unfair_lock（推荐）：等待时线程会被内核挂起而非忙等，且系统会进行优先级继承
• pthread_mutex：支持优先级继承（Priority Inheritance）——当高优先级线程等待锁时，系统临时提升持锁的低优先级线程的优先级，让它尽快完成并释放锁
• NSLock：底层基于 pthread_mutex，同样支持优先级继承
• Actor：Swift Concurrency 运行时自动处理优先级问题

→ 多线程

读写锁（Readers-Writer Lock）的核心需求是：允许多个线程同时读取，但写操作必须独占访问。使用自定义并发队列 + dispatch_barrier_async是最常见的实现方式：

• 读操作通过dispatch_sync提交到并发队列，多个读操作可以并发执行
• 写操作通过dispatch_barrier_async提交，barrier会等待前面所有任务完成后独占执行，完成后后续任务才能继续

class ReadWriteStore {
    private let queue = DispatchQueue(label: "com.example.rwlock", attributes: .concurrent)
    private var _data: Any?

    func readData() -> Any? {
        queue.sync {
            _data
        }
    }

    func writeData(_ data: Any?) {
        queue.async(flags: .barrier) {
            self._data = data
        }
    }
}

→ 多线程

逐一分析：

• 串行队列 + sync：任务在当前线程执行（sync 不开新线程），一个执行完才执行下一个
• 串行队列 + async：开启一条新线程，任务在该线程上按顺序执行。注意只开一条，因为串行队列同一时间只执行一个任务
• 并发队列 + sync：任务在当前线程执行（sync 不开新线程），虽然是并发队列但因为 sync 会阻塞等待，效果等同于串行执行
• 并发队列 + async：开启多条新线程并发执行，这是最常用的并发场景
• 主队列 + sync：如果在主线程调用会死锁；如果在子线程调用则不会死锁，任务在主线程执行
• 主队列 + async：任务在主线程上串行执行，常用于回到主线程更新 UI

→ 多线程

→ 多线程

Actor 的优势：

传统多线程中，开发者需要手动选择锁、管理加锁/解锁时机，一旦遗漏就会产生数据竞争，而且这类 bug 往往难以复现和调试。Actor 从语言层面解决了这个问题：

• 编译时安全：从 actor 外部访问其可变状态必须使用 await，忘记了编译器直接报错，而不是等到运行时崩溃才发现
• 无需手动加锁：actor 内部的状态自动受到隔离保护，不需要开发者编写任何锁相关代码，消除了忘记解锁、死锁等人为错误
• 消除数据竞争：Swift 6 的严格并发检查 + Actor + Sendable 三者配合，可以在编译期消除数据竞争（Data Race Safety）
• 比锁更高层次的抽象：锁保护的是"代码段"，开发者需要记住哪些代码需要加锁；Actor 保护的是"数据"，只要数据在 actor 内部，就自动是安全的
• 可组合性好：多个 actor 之间通过 await 交互，不会出现传统锁的嵌套死锁问题（得益于 actor 的可重入设计）

结构化并发的优势：

在 GCD 时代，异步任务一旦通过 dispatch_async 派发出去，就与创建它的上下文完全脱离了关系，这带来了几个问题：

1. 任务泄漏：派发出去的任务没有所有者，无法确保它一定会完成或被取消，容易产生资源泄漏
2. 取消困难：需要手动持有 DispatchWorkItem 引用并调用 cancel()，而且子任务不会自动取消
3. 错误处理分散：每个闭包回调都需要独立处理错误，错误无法自动向上传播
4. 生命周期不可控：闭包捕获了 self 等引用，异步任务的生命周期可能超过预期

结构化并发（async let、TaskGroup）通过将任务的生命周期绑定到作用域来解决这些问题。

→ 多线程

1. 检查 receiver 是否为 nil，如果是则直接返回
2. 通过 isa 找到 receiver 的类对象
3. 在类对象的方法缓存（cache_t）中查找方法
4. 如果缓存命中，直接调用方法实现（IMP）
5. 如果缓存未命中，在类对象的方法列表中查找
6. 如果找到，缓存方法并调用
7. 如果未找到，沿着 superclass 链向上查找
8. 如果最终未找到，进入消息转发流程

→ runtime

第一阶段：动态方法解析（Dynamic Method Resolution）

Runtime 调用类方法 +resolveInstanceMethod:（实例方法缺失时）或 +resolveClassMethod:（类方法缺失时），开发者可以在方法内部通过 class_addMethod 动态添加方法实现。如果返回 YES 且成功添加了方法，Runtime 会重新发送消息。

第二阶段：快速转发（Fast Forwarding）

如果动态方法解析未处理，Runtime 调用实例方法 -forwardingTargetForSelector:，开发者返回一个备用对象来接收该消息。Runtime 会直接对备用对象执行 objc_msgSend，不涉及 NSInvocation 的创建，因此效率很高。但限制是无法修改消息的参数、返回值，也无法将消息转发给多个对象。

第三阶段：完整转发（Normal Forwarding）

如果快速转发返回 nil，Runtime 先调用 -methodSignatureForSelector: 获取方法签名（返回 nil 则直接崩溃），再调用 -forwardInvocation:，传入封装了完整调用信息的 NSInvocation 对象。开发者可以自由修改参数、更换 target、转发给多个对象、保存调用信息以供后续使用。性能开销最大，但灵活性最高。

三个阶段都未处理时，Runtime 调用 doesNotRecognizeSelector: 抛出 unrecognized selector 异常。

→ runtime

• 在 +load 中执行
• 若放在 +load 中，通常天然只执行一次，dispatch_once 主要用于防御性编程；
• 先尝试 class_addMethod，避免交换父类方法
• swizzled 方法中用 swizzled 方法名调用原实现

→ runtime

1. 字典转模型

利用 class_copyIvarList 获取类的所有成员变量，结合 KVC 自动完成字典到模型的映射。这是 MJExtension、YYModel 等框架的核心思路。

2. 防止数组越界崩溃

通过 Method Swizzling hook NSArray 类簇的私有子类（__NSArrayI）的 objectAtIndex: 方法，在调用前增加边界检查，越界时返回 nil 而非崩溃。建议仅在 Release 环境下启用保护，Debug 环境仍抛出异常以便尽早发现问题。

3. 无侵入埋点统计（AOP）

通过 Method Swizzling hook UIViewController 的 viewDidAppear: 等生命周期方法，在不修改业务代码的情况下自动为所有页面添加 PV 统计，实现 AOP 风格的埋点。埋点逻辑集中在一个 Category 中，与业务代码完全解耦。

4. 多播代理

利用消息转发（完整转发阶段）实现一对多的消息分发，让多个对象同时监听同一个事件源。可基于 NSProxy（透明代理）或 NSObject 子类（更灵活）实现。

→ runtime

NSProxy 和 NSObject 都是 Objective-C 的根类，但设计目的不同：NSObject 是绝大多数 OC 类的根类，提供了完整的对象生命周期管理和消息处理机制；NSProxy 是专门为消息转发设计的抽象基类，子类必须重写 methodSignatureForSelector: 和 forwardInvocation:。

消息转发流程差异：

• NSObject：收到未知消息后，依次经历三个阶段——动态方法解析（resolveInstanceMethod:）→ 快速转发（forwardingTargetForSelector:）→ 完整转发（methodSignatureForSelector: + forwardInvocation:）。只有三个阶段都未处理，才会抛出 unrecognized selector 异常
• NSProxy：收到消息后跳过动态解析和快速转发，直接进入完整转发阶段（methodSignatureForSelector: → forwardInvocation:）。这也是为什么 NSProxy 子类只需要重写这两个方法就能完成代理

内省方法表现差异：

NSObject 自身实现了 isKindOfClass:、respondsToSelector: 等方法，当外界对代理对象调用这些方法时会直接处理并返回结果，消息不会转发给真实对象，外界可以识别出它只是一个代理。而 NSProxy 几乎没有实现任何方法，包括 isKindOfClass: 在内的消息都会进入转发流程，最终由真实对象来回答，外界无法区分代理和真实对象。

// --- NSObject 子类做代理 ---
DogProxyA *proxyA = ...;  // 继承自 NSObject，内部持有一个 Dog 实例

[proxyA bark];                               // ✅ bark 未实现，触发转发 → Dog 处理
[proxyA isKindOfClass:[Dog class]];          // ❌ 返回 NO — NSObject 自身实现了该方法，直接返回，不会转发
[proxyA respondsToSelector:@selector(bark)]; // ❌ 返回 NO — 同上

// --- NSProxy 子类做代理 ---
DogProxyB *proxyB = ...;  // 继承自 NSProxy，内部持有一个 Dog 实例

[proxyB bark];                               // ✅ 转发 → Dog 处理
[proxyB isKindOfClass:[Dog class]];          // ✅ 转发 → Dog 回答 YES
[proxyB respondsToSelector:@selector(bark)]; // ✅ 转发 → Dog 回答 YES

→ runtime

实例方法和类方法：可以添加。 Category中定义的方法会在运行时被合并到类对象的class_rw_t方法列表中（类方法则合并到元类的class_rw_t中）。需要注意的是，Category的方法会被插入到方法列表的前面，如果定义了与类本身同名的方法，运行时会先找到Category的方法并执行，表现上像是"覆盖"了原方法，但原方法仍然存在于列表中，并没有被真正替换或删除。

实例变量：不能添加。 这要从类对象的元数据存储结构说起。Objective-C运行时采用三层架构来组织类对象的元数据：objc_class → class_rw_t → class_ro_t。其中class_rw_t是运行时可读可写的数据层，存储了方法列表、属性列表、协议列表等运行时可动态修改的信息；而class_ro_t是编译时生成的只读数据层，存储了类的实例变量列表（ivars）和实例大小（instanceSize）等在编译期就已固化的信息。

关键在于：实例变量信息存储在只读的class_ro_t中，编译后无法修改。而Category是在运行时加载的，如果允许它修改实例变量布局，就会改变instanceSize和ivars，导致所有已创建对象的内存结构失效，引发内存安全问题。因此Category只能添加行为（方法），不能修改结构（实例变量）。不过可以通过Runtime提供的关联对象（Associated Objects）机制间接实现存储功能。

→ Objective-C底层原理-NSObject

分类在编译期的结构体 category_t 中没有 ivar_list，因此无法直接添加实例变量。但可以通过 关联对象（Associated Objects） 间接实现：

#import <objc/runtime.h>

static const void *kNameKey = &kNameKey;

@implementation UIView (Extension)

- (void)setName:(NSString *)name {
    objc_setAssociatedObject(self, kNameKey, name, OBJC_ASSOCIATION_COPY_NONATOMIC);
}

- (NSString *)name {
    return objc_getAssociatedObject(self, kNameKey);
}

@end

关联对象的存储结构：

关联对象并不存储在对象本身的内存中，而是由 Runtime 维护的一个全局哈希表（AssociationsManager → AssociationsHashMap）管理。其结构为：

AssociationsHashMap: { 对象指针 → ObjectAssociationMap }
ObjectAssociationMap: { key → ObjcAssociation(policy, value) }

• objc_setAssociatedObject：以对象指针为 key 在全局哈希表中找到（或创建）对应的 ObjectAssociationMap，再以传入的 key 存储 value 和内存管理策略
• objc_getAssociatedObject：按相同路径取出 value
• objc_removeAssociatedObjects：移除该对象的所有关联对象
• 当对象 dealloc 时，Runtime 会自动检查并清理其所有关联对象，不会造成内存泄漏

→ runtime

iOS 中有两套反射机制：

Objective-C Runtime 反射：提供完整的动态反射能力。通过 Runtime API 可以在运行时获取类的属性列表、方法列表、成员变量列表、协议列表等元数据，还可以动态创建类、添加方法、修改方法实现（Method Swizzling）、通过字符串创建对象（NSClassFromString）等。元数据存储在类对象的 class_rw_t / class_ro_t 结构中。只支持 ObjC 类（继承自 NSObject 的对象）。

Swift Mirror 反射：提供有限的只读内省能力。通过 Mirror(reflecting:) 可以在运行时获取任意 Swift 值的类型名称、存储属性名和值、displayStyle（struct/class/enum/optional 等），还可以通过 superclassMirror 遍历类的继承链。底层依赖编译器在 Mach-O 中生成的元数据（__swift5_fieldmd、__swift5_reflstr 等）。支持所有 Swift 类型（struct、class、enum、tuple），但不能修改属性、不能获取方法列表、不能动态调用方法。

核心区别：OC 反射追求最大灵活性（可读可写可改），Swift 反射追求编译时安全（只读内省）。对于继承自 NSObject 的 Swift 类，两套系统可以共存，但 OC Runtime 只能看到 @objc 标记的属性和方法。

→ iOS反射

Mirror 的底层依赖 Swift 编译器在 Mach-O 中生成的反射元数据。主要涉及以下几个 Section：

• __swift5_fieldmd（Field Descriptor）：存储每个类型的字段描述信息，包括字段数量和每个字段的名称引用、类型引用
• __swift5_reflstr（Reflection Strings）：存储字段名称的字符串常量
• __swift5_types（Type Descriptor）：存储类型的描述信息，包括类型名称、泛型参数、字段数量、Field Descriptor 的相对偏移
• __swift5_typeref（Type References）：存储字段类型的 Mangled Name 引用

创建 Mirror(reflecting: value) 时，Swift Runtime 首先通过值的类型元数据指针找到 Type Descriptor，再通过其中的 Field Descriptor 引用定位到字段描述信息。然后逐一读取字段名称（从 __swift5_reflstr）和字段偏移量（从元数据中的 Field Offset Vector），最终从值的内存地址加上偏移量处读取字段值，构建出 Mirror.Child 数组。

如果值的类型遵循了 CustomReflectable 协议，Mirror 会优先调用 customMirror 属性获取自定义的反射结果，跳过默认的元数据反射流程。

→ iOS反射

核心思路是利用 Runtime API 获取模型类的所有属性（或成员变量），然后遍历这些属性，从字典中取出对应 key 的值，通过 KVC 赋值给模型对象。

基本实现步骤：

1. 调用 class_copyPropertyList（或 class_copyIvarList）获取类的属性列表
2. 遍历属性列表，通过 property_getName 获取属性名
3. 以属性名为 key 从字典中取值
4. 通过 setValue:forKey:（KVC）将值设置到模型对象上
5. 调用 free 释放属性列表的内存

实际的 JSON 转模型框架（如 MJExtension、YYModel）还需要额外处理：类型转换（如字符串转数字）、嵌套模型递归转换、数组中的模型类型识别（通过约定的类方法返回数组元素类型）、属性名与 JSON key 的映射关系、NSNull 处理等。YYModel 为了追求性能，还使用了 objc_msgSend 直接调用 setter 而非 KVC，并且缓存了属性的类型信息避免重复解析。

→ iOS反射

NSClassFromString 将字符串转换为 Class 对象，常用于以下场景：

1. 路由系统：组件化架构中，模块间通过 URL → 类名字符串 → NSClassFromString → 创建对象的方式实现解耦
2. 动态加载：根据配置或服务端下发的类名，动态创建不同的视图控制器或策略对象
3. 避免硬依赖：当需要使用某个类但不想直接 import 它的头文件时（如可选依赖的 SDK）

注意事项：

• 如果类不存在，返回 nil，不会崩溃，因此必须做非空判断
• Swift 类的命名空间：Swift 类在 Runtime 中的名称包含模块名前缀（如 MyApp.MyViewController），使用 NSClassFromString 时必须传入完整的 "模块名.类名" 格式，否则返回 nil。如果 Swift 类标记了 @objc(CustomName)，则使用括号中的名称
• 不要在性能敏感的路径中频繁调用，因为涉及全局类表的哈希查找

→ iOS反射

• #include：C/C++的文本包含，可能重复包含，需要自己写 include guard 或 #pragma once
• #import：Objective-C的文本包含，会自动防止同一个头文件被重复包含
• #import "..."：优先找当前引用者所在目录和用户头文件路径，常用于项目内部头文件
• #import <...>：不找当前引用者目录和 Quoted 路径，常用于系统库、第三方库、Framework
• @import：导入 Clang Module，不是简单复制头文件，支持模块缓存、宏隔离和自动链接 Framework

→ Objective-C中import详解

不是的。#import <Framework/Header.h>在启用Modules后会自动转换为Module引用，#import "FrameworkHeader.h"通过Header Map映射后也可能触发Module引用。

→ Objective-C中import详解

Clang Module的作用：

Clang Module是一种现代化的代码组织和引用机制，将头文件预编译成高效的二进制格式（.pcm文件），编译器可以直接加载使用，而不需要每次重新解析文本形式的头文件。

解决的核心问题：

1. 编译效率问题：传统#include/#import每次编译都需要重新解析头文件。Module只需编译一次，结果被缓存为.pcm文件，可被多个源文件复用。

2. 宏污染问题：传统方式中，头文件A定义的宏会影响后续引入的头文件B。Module提供了隔离性，内部的宏不会泄露到外部，反之亦然。

3. 编译顺序依赖：传统方式下，头文件的引入顺序可能影响编译结果。Module是独立的编译单元，不受引入顺序影响。

4. 手动链接问题：使用@import时会自动链接对应的Framework，无需在Build Phases中手动添加。

5. PCH文件的局限性：

   • PCH只能有一个，Module支持多个独立缓存
   • PCH只支持线性依赖，Module支持DAG形式的依赖
   • PCH修改任何头文件需要全部重新生成，Module的增量编译更高效

→ Objective-C中import详解

PCH 是一个单一的预编译文件，包含了所有放入其中的头文件的完整 AST。当 PCH 中的任何头文件发生修改时：

1. 整个 PCH 需要重新生成
2. 所有依赖这个 PCH 的源文件都需要重新编译

这就是 PCH 的主要缺点之一。解决方案：

• 只将几乎不会修改的头文件放入 PCH
• 项目自己的头文件不要放入 PCH
• 考虑迁移到 Clang Modules，它的增量编译更加高效

→ Objective-C中import详解

CocoaPods 默认不会为静态库 Pod 生成 modulemap。启用方式：

use_modular_headers!                          # 全局启用
pod 'AFNetworking', :modular_headers => true  # 特定 Pod 启用
use_frameworks!                               # 构建为 Framework，自动支持

实现机制：

• use_frameworks!：将 Pod 构建为 Framework，Framework 本身就支持 Module（设置 DEFINES_MODULE = YES，modulemap 在 Framework 目录结构中）
• use_modular_headers!：Pod 仍然是静态库（.a），CocoaPods 会生成 module.modulemap 和 Umbrella Header，然后在使用方的 xcconfig 中添加 -fmodule-map-file 编译器标志指向该 modulemap。这样 Pod 自身的 DEFINES_MODULE 保持为 NO，但使用方仍能以 Module 方式引用

→ Objective-C中import详解

CocoaPods 在执行 pod install 时会：

1. 在 Pods/Headers/Public/ 目录下为每个 Pod 的公开头文件创建符号链接
2. 在生成的 xcconfig 文件中添加 HEADER_SEARCH_PATHS，将 ${PODS_ROOT}/Headers/Public 等路径加入搜索范围

HEADER_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Headers/Public" "${PODS_ROOT}/Headers/Public/AFNetworking"

当你写 #import "AFNetworking.h" 时：

1. Clang 首先在 includer 所在目录查找，找不到
2. 然后遍历 SearchDirs 数组，在 ${PODS_ROOT}/Headers/Public/AFNetworking/ 目录中找到符号链接
3. 通过符号链接定位到实际的头文件

→ Objective-C中import详解

id obj = nil;           // 对象为空
Class cls = Nil;        // 类为空
void *ptr = NULL;       // C 指针为空

// nil 的特殊之处：向 nil 发送消息是安全的，不会崩溃
[nil doSomething];      // 什么都不发生，返回 0/nil/NO

// NSNull 用于集合中占位
NSArray *arr = @[@"a", [NSNull null], @"c"];  // 中间位置表示"空"

向 nil 发消息不会崩溃是 Objective-C 的一个重要特性，但这也意味着某些 bug 会"静默失败"而不暴露。

@implementation MyClass

// @synthesize：自动生成（现代 OC 默认行为，通常不需要显式写）
@synthesize name = _name;  // 指定成员变量名为 _name

// @dynamic：不自动生成，常用于 Core Data 的 NSManagedObject 子类
@dynamic createdAt;

@end

现代 Objective-C（Xcode 4.4+）中，@property 会自动合成 getter/setter 和带下划线的成员变量，一般不需要显式写 @synthesize。

通常结果一样。 关键原因是 [super class] 的消息接收者仍然是 self（当前对象），只是方法查找从父类开始。

// B 继承自 A
@implementation B
- (void)test {
    NSLog(@"%@", [self class]);   // B
    NSLog(@"%@", [super class]);  // B（不是 A！）
}
@end

super 的本质是：消息接收者仍然是 self，但告诉编译器从父类的方法列表开始查找。NSObject 的 -class 方法执行时拿到的 self 仍然是当前对象，所以可以根据这个对象的 isa 获取真实类型，返回结果自然还是 B。

如果当前类重写了 -class，[self class] 和 [super class] 就可能不同，因为 [super class] 会跳过当前类的方法实现。

NSString *a = @"hello";
NSString *b = [NSString stringWithFormat:@"hello"];

a == b;                      // ❌ 可能为 NO（比较指针地址）
[a isEqualToString:b];       // ✅ YES（比较字符串内容）

== 比较的是指针地址，isEqualToString: 比较的是字符串内容。对于常量字符串，编译器可能会做字符串驻留（string interning），使 == 偶尔返回 YES，但这是不可靠的实现细节，不能依赖。

NSMutableArray *mutable = [@[@1, @2, @3] mutableCopy];
NSArray *immutable = [mutable copy];  // 不可变副本
NSMutableArray *mutableCopy = [mutable mutableCopy];  // 可变副本

对于不可变对象调用 copy，实际上是浅拷贝（返回自身，不产生新对象，因为不可变对象本身就是安全的）。对于可变对象调用 copy，则是深拷贝（产生不可变副本）。

self.name = @"Tom";   // 调用 setter 方法，走属性修饰符逻辑（如 copy）
_name = @"Tom";       // 直接访问成员变量，不走 setter

原则：

• 外部访问 → 必须用 self.xxx
• 初始化方法（init）中 → 用 _xxx（避免触发子类重写的 setter）
• dealloc 中 → 用 _xxx
• 其他内部方法 → 一般用 self.xxx（保证 KVO 和懒加载正常工作）

在 Block 捕获场景下：

→ static关键字详解

不会。核心原因在于 static 改变了变量的链接属性（Linkage）：

• 不加 static：全局变量默认具有 external linkage，符号被导出到全局符号表。如果两个 .m 文件定义了同名全局变量，链接器在合并所有 .o 文件时会发现重复符号，报 duplicate symbol 错误。
• 加了 static：链接属性变为 internal linkage，编译器将其标记为本地符号（Local Symbol），不会导出到全局符号表。每个文件中的同名变量在符号表中是各自独立的条目，链接器不会尝试合并它们，在内存中也是各自独立的存储空间。

→ static关键字详解

根本原因：Swift 以模块（而非源文件）作为基本的编译和可见性单元。

在 Xcode 中，每个 Build Target（App 或 Framework）就是一个模块。同一模块内的所有 .swift 文件共享统一的命名空间，编译器会将它们作为一个整体进行分析。

Swift 的默认访问级别是 internal，其定义就是"模块内可见"。因此：

• 你在 FileA.swift 中定义的 class MyClass（未标注访问级别）
• 在同模块的 FileB.swift 中可以直接使用，无需 import

→ Swift中import详解

核心区别只有两点：

1. 可导入的模块类型不同

   • @import：只能导入 Clang Module（需要 module.modulemap 定义）
   • import：既能导入 Swift 模块（.swiftmodule），也能通过 ClangImporter 导入 Clang 模块

2. Swift 支持声明级别导入

   // Swift 可以只导入特定类型，用于解决命名冲突
   import class UIKit.UIViewController
   import struct Darwin.size_t
   

   @import 只能导入整个模块或子模块，无法精确到单个类型。

相同点：

• 都在语义分析阶段处理（不是预处理器）
• 都支持自动链接
• 都支持子模块导入
• 都享受模块缓存带来的编译加速

→ Swift中import详解

1. 模块定义方式

   • Clang Module：需要手写 module.modulemap 文件定义模块结构
   • Swift Module：编译器自动将公开 API 序列化，无需额外配置

2. 模块文件格式

   • Clang Module：.pcm（Precompiled Module），只包含 AST 和类型信息
   • Swift Module：.swiftmodule，除 AST 外还包含 SIL 和内联函数体，支持跨模块优化

3. ABI 稳定性

   • Clang Module：.pcm 是二进制格式，强依赖编译器版本，无法跨版本共享
   • Swift Module：额外提供 .swiftinterface 文本格式，支持 Library Evolution，可跨编译器版本使用

4. 互操作性

   • Swift 通过 ClangImporter 可以直接解析 Clang Module（.pcm 和 module.modulemap）
   • Clang 无法直接解析 .swiftmodule 格式。OC 导入 Swift Framework 时，实际是通过 Xcode 自动生成的 module.modulemap（引用 -Swift.h 头文件）来实现，本质上 Clang 读取的仍是 OC 头文件

→ Swift中import详解

Copy-on-Write（写时拷贝，COW）是 Swift 为了在值语义和性能之间取得平衡而采用的重要优化。按照值语义，Array、Dictionary、Set 这类值类型在赋值后应该彼此独立；但如果每次赋值都立刻深拷贝整份数据，大数组、大字典的成本会非常高。COW 的思路是：赋值时先共享底层存储，真正发生修改时再拷贝。

以数组为例：

var array1 = [1, 2, 3, 4, 5]
var array2 = array1      // 此时不深拷贝，array1 和 array2 共享底层存储

array2.append(6)         // 修改 array2 时才触发拷贝

表面上 array1 和 array2 都是值类型变量，但标准库集合通常不是把所有元素都直接塞进栈上的变量本身。更接近真实情况的是：外层的 Array 是一个很小的结构体，里面保存指向堆上 buffer/storage 的引用，以及元素数量、容量等元信息。赋值时复制的是这个小结构体，因此两个数组变量暂时指向同一块堆存储。

当执行 append、remove、下标赋值等修改操作时，集合会先检查底层存储是否被多个变量共享。简化实现类似：

struct MyArray<Element> {
    private var storage: ArrayStorage<Element>

    mutating func append(_ element: Element) {
        if !isKnownUniquelyReferenced(&storage) {
            storage = storage.copy()
        }

        storage.append(element)
    }
}

isKnownUniquelyReferenced(&storage)：它用来判断某个 class 实例形式的底层存储是否只有当前这一个强引用。如果是唯一引用，说明没有其他值共享这块 buffer，可以直接原地修改；如果不是唯一引用，说明还有其他变量也看着同一份数据，必须先复制一份新的 storage，再在新 storage 上执行修改。

所以 COW 的执行过程可以概括为四步：

1. 创建变量：array1 持有一块堆上的底层 buffer。
2. 赋值复制：array2 = array1 只复制外层结构体，底层 buffer 仍然共享。
3. 修改前检查：array2.append 进入 mutating 方法，检查 storage 是否唯一引用。
4. 必要时拷贝：如果 storage 被共享，先复制 buffer；如果 storage 唯一，直接原地修改。

→ 值类型和引用类型的区别

Swift 宏解决的是编译期代码生成问题：让开发者可以在源码层面声明一段"会生成 Swift 代码的代码"，由编译器在类型检查前展开成真正的 Swift 源码，再继续走正常的类型检查、SIL 生成和优化流程。

在 Swift 宏出现之前，Swift 虽然已经有不少元编程工具，但它们各自都有明显边界：

• @propertyWrapper 只能包住属性，适合给单个属性增加读写行为，比如 @State、@Published，但它不能给类型生成新方法、不能让类型自动遵循协议，也不能批量改写其他成员。
• @resultBuilder 主要用于把闭包里的表达式收集成 DSL，例如 SwiftUI 的 ViewBuilder，但它只作用在闭包内部，无法改造一个类型声明。
• Mirror 和 KeyPath 属于运行时反射或半反射能力，性能、类型安全和可维护性都不适合大量生成样板代码。
• Codable 这类自动合成能力以前属于编译器魔法，只有 Swift 编译器内部能实现，普通开发者无法写出同等能力。
• Sourcery、SwiftGen 这类工具虽然能生成代码，但它们在编译器之外运行，往往只能做文本级处理，缺少 Swift 语法树上下文，和 IDE、增量编译、诊断系统结合也不够自然。

Swift 宏的价值就在于：它把"编译器才能做的源码变换"开放给了开发者，同时仍然保留 Swift 的强类型、作用域、诊断和 IDE 展开体验。它不是运行时反射，也不是字符串模板，而是基于 SwiftSyntax 的语法树变换。

→ Swift 宏

两者都叫"宏"，但本质完全不同。

Objective-C 的 #define 是 C 预处理器能力，本质是纯文本替换。它发生在编译器真正理解代码之前，输入和输出都是 token 或字符串片段。预处理器并不知道 Swift/Objective-C 类型系统，不理解作用域，也不关心替换后的代码有没有副作用。

Swift 宏发生在 Swift 编译流程内部，源码先被解析成语法结构，编译器遇到宏调用后，把相关语法节点交给宏插件，宏插件返回新的 Swift 语法片段，再由编译器继续做类型检查。因此 Swift 宏的输入输出是语法树到语法树，不是字符串到字符串。

几个关键差异：

• 执行阶段不同：#define 是预处理阶段；Swift 宏是在编译中、类型检查前展开。
• 操作对象不同：#define 操作文本；Swift 宏操作 SwiftSyntax 语法节点。
• 类型安全不同：#define 替换时完全不知道类型；Swift 宏的声明签名会参与 Swift 类型检查，展开结果也必须是合法 Swift 代码。
• 卫生性不同：#define 没有卫生性，容易变量名冲突、重复求值；Swift 宏有部分卫生机制，可以通过 context.makeUniqueName 生成唯一名字，并要求附加宏通过 names: 声明生成的外部名字。
• 调试体验不同：#define 展开结果对 IDE 和调试器不友好；Swift 宏可以通过 Xcode 的 Expand Macro 查看展开后的代码，也可以用诊断系统定位错误。
• 运行模型不同：#define 属于预处理器；Swift 第三方宏以独立编译器插件进程运行，通过 JSON-RPC 与 swiftc 通信。

→ Swift 宏

Swift 宏从语法形式上主要分为两类：独立宏（Freestanding Macro）和附加宏（Attached Macro）。

独立宏以 # 开头，不依附在某个已有声明上。它又可以分为表达式宏和声明宏：

• 表达式宏用于生成一个表达式，例如 #stringify(1 + 2) 可以展开成 (1 + 2, "1 + 2")。
• 声明宏用于生成声明，例如 SwiftUI 的 #Preview 可以展开成预览所需的类型声明。

附加宏以 @ 开头，附着在一个已有声明上，根据 role 决定它能生成或改写什么：

• peer：在被标注声明的同级位置生成新声明。比如给 completionHandler 风格方法生成一个 async 重载。
• member：给类型内部新增成员。比如 @Observable 生成 _$observationRegistrar、access、withMutation 等辅助成员。
• accessor：给属性生成访问器。比如 @ObservationTracked 改写属性的 getter/setter，用于依赖收集和变更通知。
• memberAttribute：给类型里的成员批量添加属性。比如 @Observable 给存储属性加 @ObservationTracked。
• extension：生成扩展，通常用于让类型自动遵循协议。Swift 5.10 之后，协议遵循相关能力合并到 extension role。
• body：生成或替换函数体。Swift Testing 的 @Test、追踪日志类宏都可能使用这类能力。
• preamble：在函数体开头插入代码，适合做轻量日志、埋点、权限检查等前置逻辑。

一个宏可以同时拥有多个 role。@Observable 就是典型例子：它不是一个单一动作，而是同时使用 member、memberAttribute、extension 等能力，把普通 class 改造成可观察对象。

→ Swift 宏

Swift 宏的大致执行流程是：

1. 编译器读取源文件，把源码解析成 Swift 语法结构。
2. 编译器在类型检查前遇到宏调用，例如 #stringify 或 @Observable。
3. swiftc 启动或复用对应的宏插件进程。
4. 编译器通过 JSON-RPC 把宏调用节点、被标注声明节点等语法信息发送给插件。
5. 宏插件使用 SwiftSyntax 分析输入语法，构造新的 ExprSyntax、DeclSyntax 等结果。
6. 插件把展开后的 Swift 代码片段返回给编译器。
7. 编译器把结果拼回源码对应位置，再继续类型检查、生成 SIL、优化和产物。

这里最重要的点是：宏在类型检查前展开。因此宏实现里看到的是语法，不是已经解析完成的类型语义。

例如宏可以看到某个属性写成：

var name: String
var createdAt: Date
var items: [Item]

但它拿到的主要是 VariableDeclSyntax、TypeSyntax 这类语法节点。它知道源码里写了 String、Date、[Item] 这些字面语法，但不能像编译器类型检查器那样可靠判断：

• Item 到底是哪一个模块里的类型；
• T 最终会被推导成什么具体类型；
• 某个类型是否真的遵循 Codable、Sendable 或自定义协议；
• 某个表达式重载解析后会调用哪个函数。

所以，宏适合基于声明形状生成代码，比如"这个 struct 有哪些属性"、“这个函数最后一个参数是不是叫 completion”、“这个属性有没有显式类型标注”。但它不适合做复杂的类型系统推理，例如"如果属性类型遵循某协议就生成 A，否则生成 B"。

工程上常见做法是：宏负责生成样板代码，真正依赖类型系统的行为交给泛型约束、协议扩展、运行时值或编译器后续类型检查处理。换句话说，宏负责把代码写出来，类型系统负责证明这些代码是否合法。

→ Swift 宏

第三方宏不是直接嵌在 swiftc 进程里运行，而是以独立的编译器插件进程运行。这样设计主要有三个原因。

第一是安全。宏本质上是编译期可执行代码，第三方宏包完全可以包含任意 Swift 逻辑。如果直接运行在编译器进程里，风险非常大。独立进程配合沙盒机制，可以限制宏插件的文件、网络等能力。Xcode 首次使用第三方宏时出现 Trust & Enable，就是在提醒开发者：你正在允许这个包在编译期执行代码。

第二是崩溃隔离。宏作者写错代码、触发崩溃、死循环，都不应该把整个 swiftc 进程直接带崩。独立进程可以把故障限制在插件侧，编译器可以给出更明确的失败信息。

第三是演进和复用。宏插件可以作为 Swift Package 的一个 .macro target 独立编译和分发，业务 target 只依赖暴露宏声明的普通 library target，不需要直接接触 SwiftSyntax 细节。

但这个模型也带来工程代价：

• 编译器需要启动插件进程，并通过 JSON-RPC 通信，宏用得多会增加编译耗时。
• 第三方宏通常依赖 swift-syntax，而 swift-syntax 主版本要和 Swift 编译器版本匹配，升级 Xcode 时容易牵一发动全身。
• 企业 CI 上必须管理宏的信任和供应链安全，锁定 Package.resolved，谨慎使用 --skip-macro-validation。
• 宏插件本身不进入 App 运行时产物，但它会影响编译期行为，因此 code review 不能只看业务代码，也要看宏实现。

→ Swift 宏

@Observable 是理解 Swift 宏非常好的系统案例。开发者只写：

@Observable
class UserViewModel {
    var name: String = ""
    var age: Int = 0
}

宏展开后，类会被改造成一个可被 Observation 框架追踪的对象。简化来看，它做了几类事情。

第一，生成观察所需的隐藏成员。比如添加 _$observationRegistrar，以及 access(keyPath:)、withMutation(keyPath:_:) 这类辅助方法，用于记录读取和包裹写入。

第二，给存储属性加追踪能力。@Observable 会通过 memberAttribute 给属性加上类似 @ObservationTracked 的标注，而 @ObservationTracked 本身又是 accessor 宏，会把普通存储属性改写成带 getter/setter 的形式。

第三，让类型遵循框架协议。宏会生成扩展，让类型遵循 Observable，使它能进入 SwiftUI/Observation 的依赖追踪体系。

简化展开类似：

class UserViewModel {
    @ObservationIgnored
    private let _$observationRegistrar = ObservationRegistrar()

    @ObservationTracked
    var name: String = "" {
        get {
            access(keyPath: \.name)
            return _name
        }
        set {
            withMutation(keyPath: \.name) {
                _name = newValue
            }
        }
    }

    private var _name: String
}

extension UserViewModel: Observable {}

这个例子体现了宏的组合能力：@Observable 不是简单生成一段代码，而是同时使用了 member、memberAttribute、extension 等 role，并配合另一个 accessor 宏改写属性访问。它把过去可能依赖 runtime、KVO、属性包装器和手写样板代码的机制，迁移到了编译期生成的强类型 Swift 代码。

→ Swift 宏

Swift 宏能力很强，但不应该把它当成普通函数、协议或泛型的替代品。主要风险有四类。

第一是编译性能。第三方宏需要编译宏插件、启动插件进程、和编译器通信，还要解析和生成 SwiftSyntax。少量宏问题不大，但如果在大型项目里大量使用复杂宏，clean build 和增量编译都会受到影响。

第二是版本耦合。swift-syntax 的版本必须和 Swift 编译器版本匹配。Xcode 升级后，宏包依赖的 swift-syntax 如果还停留在旧主版本，可能直接编译失败。团队需要把 Xcode、Swift tools version、swift-syntax、宏库版本一起管理。

第三是可读性和调试成本。宏会让源文件中"看见的代码"少于"实际参与编译的代码"。如果宏生成很多复杂逻辑，后续排查问题时必须频繁查看展开结果。宏 API 设计不好时，调用端会显得简洁，维护端却非常痛苦。

第四是安全与供应链风险。宏是编译期执行代码，第三方宏包本身需要被信任。企业项目里要锁定依赖版本，对宏实现做 code review，避免随意跳过宏校验。

不适合写宏的场景包括：

• 普通函数、泛型、协议扩展就能清楚表达的逻辑。
• 只是为了少写几行代码，但会显著降低可读性的场景。
• 需要大量类型语义推理的场景，例如依赖"某个泛型实参最终是否遵循某协议"来决定生成不同代码。
• 生成代码过于复杂，且调用方很难通过 Expand Macro 理解实际行为的场景。
• 性能敏感的大型工程中，高频、复杂、无法明确 names: 的宏。

适合写宏的场景通常有共同特征：样板代码重复、生成规则稳定、输入可以从语法结构判断、展开结果容易解释，并且生成代码能显著改善调用端 API。 例如模型代码、测试断言、依赖注入样板、Mock/Spy 生成、预览声明、属性访问追踪等。

→ Swift 宏

→ Objective-C与Swift区别

WAL（Write-Ahead Logging）是SQLite的一种日志模式。与默认的回滚日志模式不同，WAL将修改先写入WAL文件而不是直接修改数据库文件。核心优势是读写可以并发执行——读取者看到的是最近一次提交前的一致性快照，写入者的操作不会阻塞读取。iOS上推荐使用WAL模式以获得更好的并发性能。

→ iOS中的数据库

NSManagedObjectContext内部维护了注册对象的缓存、变更追踪等状态，这些状态不是线程安全的。跨线程访问会导致数据竞争（data race），引发崩溃或数据损坏。Core Data提供了mainQueueConcurrencyType和privateQueueConcurrencyType两种并发模式，并通过perform(_:)方法确保操作在正确的队列上执行。

→ iOS中的数据库

没有索引时，数据库只能从第一行开始逐行扫描直到最后一行（全表扫描，O(N)）。索引本质是一棵独立的B-Tree，将被索引列的值按顺序组织成树形结构。由于B-Tree每个节点可容纳数百个Key，树高度极低（百万级数据通常只有34层），查找任意值只需34次节点比较即可定位，时间复杂度O(log N)。例如100万行数据，全表扫描最坏需要100万次比较，B-Tree查找只需约20次。不该建索引的情况：低选择性的列（如is_deleted只有0和1，索引无法有效缩小范围）、数据量很小的表（全表扫描本身就很快）、写多读少的表（每次写入都要维护索引B-Tree）、频繁更新的列（每次UPDATE都触发索引重排）、以及查询条件中对列使用了函数的情况（如WHERE LOWER(name) = 'test'，索引存的是原始值无法命中）。

→ iOS中的数据库

Realm使用mmap将数据文件映射到进程的虚拟地址空间。Realm对象的属性访问实际上是通过计算属性直接读取mmap区域中对应偏移量的数据，不需要将数据从磁盘复制到中间缓冲区再复制到对象属性中。这消除了传统ORM的"读取行 → 解析 → 创建对象 → 赋值属性"的多次内存拷贝过程。

→ iOS中的数据库

UserDefaults每次写入都需要将整个plist字典重新序列化并写入磁盘，时间复杂度与总数据量成正比。MMKV基于mmap内存映射和protobuf序列化，使用增量追加写入策略——新数据直接追加到文件末尾，单次写入时间与写入数据量成正比，与总数据量无关。同时mmap减少了频繁文件IO和用户态拷贝，已写入映射页的数据由内核管理，进程崩溃后通常比普通用户态缓冲更容易恢复；但它不等于强持久化，关键数据仍需要校验、重放或合适的同步策略。

→ iOS中的数据库

OSI七层模型从下到上依次为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。TCP/IP四层模型将其简化为：网络接口层（对应物理层+数据链路层）、网络层、传输层、应用层（对应会话层+表示层+应用层）。

各层核心作用：

• 物理层：比特流的物理传输，定义电气特性、传输介质（光纤、双绞线）
• 数据链路层：帧的封装与MAC寻址，负责相邻节点间的可靠传输（Ethernet、Wi-Fi）
• 网络层：路由选择与IP寻址，负责跨网络的端到端数据包传输（IP、ICMP、ARP）
• 传输层：端到端的可靠数据传输，提供进程级通信（TCP、UDP）
• 应用层：为应用程序提供网络服务（HTTP、DNS、FTP）

→ 计算机网络

以一次HTTP请求为例，发送方封装过程：

1. 应用层：构造HTTP请求报文（请求行 + 请求头 + 请求体），作为原始数据交给传输层
2. 传输层：在应用层数据前添加TCP首部（源端口、目的端口、序列号、确认号等），封装为TCP段（Segment）。如果数据超过MSS（通常1460字节），会进行分段
3. 网络层：在TCP段前添加IP首部（源IP、目的IP、TTL、协议类型等），封装为IP数据包（Packet）。如果超过MTU（通常1500字节），会进行分片
4. 数据链路层：在IP数据包前后添加帧头（源MAC、目的MAC、类型）和帧尾（FCS校验序列），封装为帧（Frame）
5. 物理层：将帧转换为比特流（电信号或电磁波）通过物理介质传输

接收方执行完全相反的解封装过程：物理层还原为帧 → 数据链路层校验FCS并剥离帧头帧尾 → 网络层校验并剥离IP首部 → 传输层校验并剥离TCP首部、重组数据 → 应用层解析HTTP报文。

这种分层机制的核心价值在于各层独立演进：应用层可以换协议（HTTP→gRPC），传输层可以换协议（TCP→UDP），只要接口契约不变，其他层不受影响。

→ 计算机网络

三次握手过程：

1. 第一次：客户端发送SYN报文（SYN=1, seq=x），进入SYN_SENT状态
2. 第二次：服务端收到SYN后，发送SYN+ACK报文（SYN=1, ACK=1, seq=y, ack=x+1），进入SYN_RCVD状态
3. 第三次：客户端收到SYN+ACK后，发送ACK报文（ACK=1, seq=x+1, ack=y+1），双方进入ESTABLISHED状态

三次握手的目的是同步双方的序列号和确认号，并交换TCP窗口大小信息。

为什么不是两次？假设客户端发送的一个SYN报文在网络中滞留，客户端超时后重发SYN并成功建立连接、传输数据、关闭连接。此后，滞留的SYN到达服务端，服务端误以为是新连接请求，返回SYN+ACK。如果只有两次握手，服务端就会直接进入ESTABLISHED状态，分配资源等待数据，但客户端并不会发送数据，造成资源浪费。三次握手中，客户端不会对这个过期的SYN+ACK进行确认，服务端收不到ACK就不会建立连接。

→ 计算机网络

四次挥手过程：

1. 第一次：客户端发送FIN报文，表示不再发送数据，进入FIN_WAIT_1
2. 第二次：服务端收到FIN，回复ACK，进入CLOSE_WAIT。此时服务端可能仍有数据要发送
3. 第三次：服务端数据发送完毕，发送FIN报文，进入LAST_ACK
4. 第四次：客户端收到FIN，回复ACK，进入TIME_WAIT状态，等待2MSL后关闭

需要四次挥手的原因是TCP是全双工的，每个方向都需要单独关闭。客户端发送FIN只表示自己不发了，服务端可能还有数据要发，所以服务端的ACK和FIN分开发送。

TIME_WAIT等待2MSL的原因：

• 确保最后的ACK到达服务端：如果ACK丢失，服务端会重发FIN，客户端需要在TIME_WAIT期间内能重新发送ACK
• 让旧连接的报文在网络中消失：防止旧连接中残留的报文干扰新连接（新连接可能复用相同的四元组）

→ 计算机网络

TCP通过多种机制保证可靠传输：

1. 序列号与确认应答：每个字节都有唯一的序列号，接收方通过ACK确认已接收到的数据。发送方如果在超时时间内未收到ACK，就会重传数据
2. 滑动窗口：实现流量控制。窗口大小由接收方通过TCP头部的窗口大小字段通告，发送方根据窗口大小控制发送速率，避免接收方缓冲区溢出
3. 拥塞控制：包含四个算法：
   • 慢启动：连接建立初期，cwnd从1个MSS开始，每收到一个ACK翻倍（指数增长）
   • 拥塞避免：cwnd达到ssthresh后，每个RTT增加1个MSS（线性增长）
   • 快速重传：收到3个重复ACK时，立即重传丢失的报文段，不用等待超时
   • 快速恢复：快速重传后，ssthresh=cwnd/2，cwnd=ssthresh+3，直接进入拥塞避免
4. 校验和：TCP首部包含校验和字段，用于检测传输过程中的数据错误

→ 计算机网络

适用场景：

• TCP：文件传输、网页浏览、邮件——需要可靠传输的场景
• UDP：视频流、DNS查询、实时游戏——对实时性要求高、能容忍少量丢包的场景

→ 计算机网络

幂等性是指同一请求执行多次，效果与执行一次相同。GET是幂等的（多次查询结果一致），POST是非幂等的（多次创建会产生多个资源）。

→ 计算机网络

HTTP/1.1：

• 持久连接（Keep-Alive）：默认复用TCP连接
• 管道化（Pipelining）：可连续发送多个请求，但响应必须按顺序返回，存在队头阻塞
• 分块传输编码、Host头部支持虚拟主机

HTTP/2：

• 二进制分帧层：将HTTP消息分割为更小的帧
• 多路复用：一个TCP连接上并行交错发送多个请求和响应，解决了HTTP层的队头阻塞
• 头部压缩（HPACK）：使用静态表、动态表和Huffman编码压缩请求头
• 服务器推送：服务端可主动推送资源
• 流优先级：客户端可指定请求优先级

HTTP/3：

• 基于QUIC协议（UDP之上），避免了TCP层的队头阻塞（TCP丢包会阻塞所有流）
• 内置TLS 1.3，加密默认开启
• 0-RTT连接建立：已知服务器可在第一个数据包中携带应用数据
• 连接迁移：使用Connection ID而非四元组标识连接，网络切换无需重新建立连接

→ 计算机网络

断点续传基于HTTP/1.1的**范围请求（Range Request）**实现。

核心头部：

• Range: bytes=1024-2047：请求指定字节范围
• Content-Range: bytes 1024-2047/10240：返回内容在整个资源中的位置
• Accept-Ranges: bytes：服务端声明支持范围请求
• If-Range：携带ETag或Last-Modified，条件性发起范围请求

流程：

1. 首次请求时，服务端返回 Accept-Ranges: bytes 和 ETag
2. 下载中断后，客户端记录已下载字节数和ETag
3. 恢复时发送 Range: bytes=已下载- 和 If-Range: ETag值
4. 如果ETag匹配（资源未变），服务端返回 206 Partial Content，客户端从断点继续
5. 如果ETag不匹配（资源已变），服务端返回 200 OK，客户端重新下载

大文件分片上传同理：将文件切分为固定大小的分片，逐片上传，记录进度，中断后从未完成的分片继续，最后合并。

→ 计算机网络

核心区别：HTTP 是明文的应用层协议；HTTPS 本质上仍然是 HTTP，只是在 HTTP 与 TCP 之间增加了 TLS/SSL 安全层，即 HTTPS = HTTP + TLS。因此 HTTPS 传输的是加密后的 HTTP 报文。

HTTPS 主要解决 HTTP 的三个安全问题：

1. 机密性：HTTP 请求头、请求体、响应内容都是明文；HTTPS 使用 AES、ChaCha20 等对称加密算法加密应用数据，即使被抓包也无法直接读取内容。
2. 身份认证：HTTP 无法确认对端是否是真正的服务器；HTTPS 通过服务端证书链验证域名、有效期、CA 签名和吊销状态，确认客户端访问的确实是目标站点。
3. 完整性：HTTP 报文可能被中间人篡改；HTTPS 使用哈希、MAC 或 AEAD 认证标签校验数据，篡改会在解密或校验时被发现。

HTTPS 的一次请求流程可以概括为：

1. DNS 解析：客户端先解析域名，得到服务器 IP。
2. TCP 三次握手：建立可靠的 TCP 连接，这一步与 HTTP 相同。
3. TLS 握手：在 TCP 连接之上建立安全通道，核心目标是完成参数协商、身份认证、密钥交换。以 TLS 1.3 的 ECDHE 握手为例：
   • ClientHello：客户端发送支持的 TLS 版本、密码套件列表、客户端随机数（Client Random），以及 ECDHE 临时公钥等密钥交换参数。
   • ServerHello：服务端从客户端支持的能力中选择 TLS 版本和密码套件，返回服务端随机数（Server Random）和服务端 ECDHE 临时公钥。
   • 证书认证：服务端发送证书链，客户端校验证书是否过期、域名是否匹配、CA 签名是否合法、证书是否被吊销，以确认服务端身份。
   • 密钥生成：客户端和服务端分别用"自己的 ECDHE 私钥 + 对方的 ECDHE 公钥"计算出相同的 Pre-Master Secret，再结合 Client Random、Server Random 派生出会话密钥。这个会话密钥不会在网络中直接传输。
   • Finished 校验：双方用派生出的密钥校验握手消息摘要，确认握手过程未被篡改，并切换到加密通信。
4. 加密传输 HTTP 数据：握手完成后，后续 HTTP 请求和响应都使用会话密钥进行对称加密传输。

→ 计算机网络

WebSocket连接建立涉及三个层面：TCP连接 → TLS握手（wss场景）→ WebSocket握手。

WebSocket握手（HTTP Upgrade）：

1. 客户端发送HTTP GET请求，携带特殊头部：
   • Upgrade: websocket / Connection: Upgrade：请求协议升级
   • Sec-WebSocket-Key：16字节随机值的Base64编码
   • Sec-WebSocket-Version: 13
2. 服务端返回 101 Switching Protocols，携带 Sec-WebSocket-Accept
3. Sec-WebSocket-Accept 的计算：SHA1(Sec-WebSocket-Key + “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”) 的Base64编码

这个验证机制的目的不是安全性，而是：

• 确认服务端确实理解WebSocket协议
• 防止HTTP缓存代理将握手响应缓存并复放
• 阻止非WebSocket客户端意外建立WebSocket连接

WebSocket与HTTP的关系：WebSocket和HTTP是平级的应用层协议。WebSocket仅在握手阶段"借用"了HTTP（通过Upgrade机制），一旦连接建立（收到101），底层TCP连接就不再承载HTTP报文，改为承载WebSocket帧。两者共用80/443端口，这使得WebSocket可以穿透大多数防火墙和代理。

WebSocket帧格式：采用紧凑的二进制格式，帧头仅2-14字节（HTTP头部通常几百字节到几KB）：

关键字段：

• FIN：1位，标记消息最后一帧
• Opcode：4位，帧类型（0x1=文本, 0x2=二进制, 0x8=关闭, 0x9=Ping, 0xA=Pong）
• MASK：1位，客户端→服务端必须为1
• Payload Length：7位（可扩展至16位或64位）
• Masking Key：4字节（MASK=1时存在）

客户端帧必须掩码的原因：防止缓存投毒攻击（Cache Poisoning）。恶意网页中的JavaScript通过WebSocket向目标服务器发送精心构造的数据，如果中间存在不理解WebSocket协议的HTTP代理，代理可能将WebSocket帧误认为HTTP请求/响应并缓存。掩码使得每次发送的帧在比特层面都不同，让代理无法将其与HTTP流量混淆。掩码算法：masked_payload[i] = original_payload[i] XOR masking_key[i % 4]。这不是加密（Masking Key是明文传输的），纯粹是协议层面的安全防护。

→ 计算机网络

这三者都可以用于实时通信或流式传输，但定位不同：

SSE 适合"服务端持续推送，客户端只接收"的场景。它基于普通HTTP，浏览器原生支持 EventSource，并且自带断线重连和事件ID追踪，所以实现简单、代理友好。但它只能服务端到客户端单向传输，且只支持文本数据。

WebSocket 适合"双方都要频繁发送消息"的场景。握手阶段通过HTTP Upgrade建立连接，之后就不再传输HTTP报文，而是传输WebSocket帧。它支持全双工通信和二进制数据，实时性强，但自动重连、心跳、鉴权续期、消息确认等通常需要业务自己实现。

Streamable HTTP 可以理解为一种渐进式的HTTP流式传输设计，MCP协议用它替代旧的HTTP+SSE传输方案。核心思想是：简单场景就是普通HTTP请求/响应，复杂场景再按需升级为SSE流式响应。

Streamable HTTP主要解决旧HTTP+SSE方案的几个问题：

• 部署更简单：旧方案通常要维护POST请求通道和SSE推送通道，Streamable HTTP可以只暴露一个HTTP端点。
• 简单请求更轻量：不需要为了一个普通请求先建立SSE长连接，可以直接返回JSON。
• 负载均衡更友好：请求可以独立路由，不强依赖长连接亲和性。
• 恢复能力更自然：每个请求都有明确边界，失败后可以按请求粒度重试或恢复。

选择建议：

• 只需要服务端单向推送：优先选SSE，例如AI流式输出、通知、日志推送。
• 需要双向高频实时交互：选WebSocket，例如聊天、协同编辑、实时游戏。
• 以HTTP请求/响应为主，部分请求需要流式返回：选Streamable HTTP，例如MCP工具调用、Agent执行进度、流式模型输出。

→ 计算机网络

当应用程序需要将域名解析为IP地址时：

1. 本地缓存查找：浏览器DNS缓存 → 操作系统DNS缓存（macOS/iOS使用mDNSResponder）→ hosts文件。任一层命中则直接返回
2. 查询本地DNS服务器（递归查询）：向LocalDNS发起递归查询请求，LocalDNS自身有缓存则返回
3. 查询根DNS服务器（迭代查询）：LocalDNS向根服务器查询，根服务器返回TLD服务器地址
4. 查询TLD DNS服务器：LocalDNS向.com TLD服务器查询，返回权威DNS服务器地址
5. 查询权威DNS服务器：LocalDNS向权威服务器查询，返回最终的IP地址
6. 返回并缓存：结果返回给应用程序，同时按TTL缓存

递归查询 vs 迭代查询：

• 递归查询：客户端只发一次请求，DNS服务器负责追查到底（客户端→LocalDNS）
• 迭代查询：DNS服务器返回"下一步去找谁"（LocalDNS→根/TLD/权威）

→ 计算机网络

DNS劫持是指攻击者篡改DNS解析过程，使域名被解析到错误的IP地址。

常见劫持方式：

• LocalDNS劫持：运营商篡改解析结果，插入广告或使用缓存服务器
• DNS欺骗：攻击者监听DNS查询报文，抢先伪造响应（UDP无身份验证，先到先得）
• 路由器DNS劫持：入侵路由器修改DNS服务器设置
• hosts文件篡改：恶意软件修改本地hosts文件
• DNS缓存投毒：向LocalDNS注入伪造记录，影响所有用户

防御手段：

对于iOS开发，HTTPDNS + 证书校验是最实用的组合方案。

→ 计算机网络

Socket 是操作系统提供的网络通信 API，应用程序通过 Socket 间接使用 TCP/IP 协议栈。TCP Socket 使用 SOCK_STREAM，特点是面向连接、可靠、有序、基于字节流。一个 TCP Socket 连接通常可以用五元组标识：(协议, 本地IP, 本地端口, 远端IP, 远端端口)。

服务端流程：

1. socket() 创建监听 Socket：创建一个 TCP 套接字，典型参数是 socket(AF_INET, SOCK_STREAM, 0)。返回值是文件描述符，后续的监听、收发、关闭都围绕这个 fd 操作。
2. bind() 绑定地址和端口：服务端需要绑定固定端口，例如 80、443、8080，客户端才能通过这个地址找到服务端。常见写法是绑定 INADDR_ANY，表示监听本机所有网卡。
3. listen() 开始监听：将 Socket 从主动模式切换为被动模式，开始等待客户端连接。此时内核会维护两个队列：**SYN队列（半连接队列）**保存已收到 SYN、已回复 SYN+ACK、等待客户端 ACK 的连接；**Accept队列（全连接队列）**保存三次握手已完成、等待应用层 accept() 取走的连接。
4. accept() 取出已完成连接：accept() 从 Accept 队列中取出一个已完成三次握手的连接，返回一个新的已连接 Socket。如果队列为空，默认会阻塞等待。
5. send()/recv() 收发数据：服务端通过 accept() 返回的新 Socket 与这个客户端通信，监听 Socket 本身不负责数据传输。
6. close()/shutdown() 关闭连接：close() 关闭文件描述符，在没有其他引用时触发 TCP 四次挥手；shutdown() 可以只关闭读端或写端，例如 shutdown(fd, SHUT_WR) 表示半关闭，自己不再发送数据但仍可接收数据。

客户端流程：

1. socket() 创建客户端 Socket：客户端同样创建一个 TCP Socket。
2. connect() 发起连接：客户端指定服务端 IP 和端口调用 connect()，内核会自动分配临时端口，并触发 TCP 三次握手。
3. 三次握手完成：握手成功后，客户端的 connect() 返回；服务端内核把该连接放入 Accept 队列，等待服务端应用调用 accept() 取走。
4. send()/recv() 收发数据：连接建立后，TCP 是全双工的，客户端和服务端可以同时发送和接收数据。
5. close() 关闭连接：任意一方关闭连接都会触发 TCP 连接释放流程，典型情况下对应四次挥手。

关键点：

• accept() 不负责三次握手：三次握手由内核在 connect() 触发后完成，accept() 只是从已完成连接队列中取出连接。
• 监听 Socket 和已连接 Socket 不同：监听 Socket 继续负责接收新连接；accept() 返回的新 Socket 专门负责和某个客户端通信。
• TCP 是字节流协议：send() 不保证一次把数据全部写完，recv() 也不保证一次读到完整消息，可能出现粘包/拆包；应用层需要通过定长、分隔符或长度前缀等方式定义消息边界。
• 高并发服务需要 I/O 多路复用：一个服务端会有一个监听 Socket 和大量已连接 Socket，通常使用 select/poll/epoll/kqueue 监控多个 fd，而不是为每个连接都创建一个线程。

→ 计算机网络

TCP是字节流协议，没有消息边界。发送方两次 send("Hello") 和 send("World")，接收方一次 recv() 可能读到 "HelloWorld"（粘包），也可能分多次读到 "Hel"、"loWorld"（拆包）。

产生原因：

• 发送方：Nagle算法将多个小包合并发送
• 接收方：应用程序读取速度与数据到达速度不同步
• MSS/MTU限制：大消息被TCP分成多个段

解决方案：

实践中**长度前缀（TLV格式）**最常用：先读取固定长度的头部解析出消息体长度，再精确读取对应字节数。

→ 计算机网络

I/O多路复用允许一个线程同时监控多个Socket，当某个Socket有数据可读/可写时再去处理，避免了"一连接一线程"模型的高开销。

三种机制对比：

epoll高效的核心：内核通过回调机制维护就绪列表，epoll_wait()只返回有事件的Socket，不需要每次遍历全部连接。

epoll两种触发模式：

• LT（水平触发）：只要缓冲区有数据，每次 epoll_wait() 都通知。编程简单，不容易丢数据
• ET（边缘触发）：仅在状态变化时通知一次。高性能但编程复杂，必须一次读完所有数据，配合非阻塞I/O是Nginx等高性能服务器的标准做法

macOS/iOS使用kqueue作为高性能I/O多路复用机制，功能与epoll类似。

→ 计算机网络

选择建议：