源码分析 on Last Stand

Swift 面试：ARC 与内存管理源码解析

Tue, 16 Jun 2026 09:06:27 +0800

Swift 面试：ARC 与内存管理源码解析

Swift 面试里问 ARC，通常不是想听一句“自动引用计数”。真正要答清楚的是：对象头里有什么、strong / weak / unowned 到底差在哪里、编译器什么时候插入或消除 retain/release、为什么闭包会循环引用。

这篇文章按面试题展开。先给可以直接回答的版本，再把结论落到 Swift 源码里的对象布局、引用计数状态机和 SIL ARC 优化。

面试高频问题

Swift 的 ARC 和 Objective-C 的 ARC 有什么区别？
Swift 对象的引用计数存在哪里？
strong、weak、unowned 的底层差异是什么？
为什么 weak 在对象释放后会自动变成 nil？
为什么 unowned 访问已释放对象会崩溃？
闭包为什么容易造成循环引用？
编译器会如何优化 retain/release？
值类型是否完全不参与 ARC？
ARC 和 Copy-on-Write 有什么关系？

30 秒回答版

Swift ARC 是编译器和运行时共同完成的内存管理机制。

编译器在 SIL 阶段根据所有权语义插入 retain_value、release_value、strong_retain、strong_release 等引用计数指令，并通过 ARC 优化尽量消除冗余 retain/release。运行时负责真正维护对象的引用计数。

对原生 Swift 堆对象来说，对象头包含两部分：metadata 和 refCounts。源码里 HeapObject 的注释明确说 metadata 总是指向一个有效的 metadata 对象，refCounts 是 Swift heap object header 的非 Objective-C 成员。

objc4 类加载、read_images 与类实现化

Mon, 01 Jun 2026 19:50:12 +0800

objc4 类加载、read_images 与类实现化

本文解释 Objective-C runtime 从 dyld 通知镜像映射，到读取类、处理 future class、realize class、methodize class、附着 category 的主干流程。重点源码来自 runtime/objc-runtime-new.mm、objc-runtime-new.h、objc-os.mm、objc-class.mm 及相关测试。

作用核心结构关键流程测试视角

一、这条链路的作用

把 Mach-O 中的静态元数据变成运行时可用的类

编译器把类、元类、方法列表、协议列表、属性列表和 ivar 布局写入 Mach-O 的 Objective-C sections。这些数据起初主要是只读的 class_ro_t。runtime 加载镜像时要登记类名、修正 selector/protocol/class 引用，并在必要时分配可写的 class_rw_t。

延迟成本，同时保证消息发送能看到正确结构

大量类可以保持未 realized 状态，直到非懒加载、+load、消息发送、Swift 桥接或显式 API 需要它们。 realize 时才连接父类和元类、修正 ivar 偏移、初始化 cache、复制运行时标志，并把方法列表整理成可查找的形态。

简化理解：read_images 是“发现并登记”；readClass 是“读一个类声明并处理 future/remap”；realizeClassWithoutSwift 是“把类接入运行时继承图”；methodizeClass 是“准备方法/协议/属性并合并 category”。

二、核心类/结构和关键字段

结构	关键字段	作用
`objc_class`	`superclass`、`cache`、`bits`	类对象本体。`bits` 初始可指向 `class_ro_t`，realize 后指向 `class_rw_t` 并夹带 fast flags。
`class_ro_t`	`flags`、`instanceStart`、`instanceSize`、`name`、`baseMethods`、`ivars`	编译期只读描述。包含类名、方法、协议、属性、ivar 布局和 root/meta/future/realized 等 ABI 标志。
`class_rw_t`	`flags`、`ro_or_rw_ext`、`firstSubclass`、`nextSiblingClass`	运行时可写状态。保存 realized/initialized/constructing 等状态，并把类接入子类链。
`class_rw_ext_t`	`ro`、`methods`、`properties`、`protocols`	当类需要扩展列表时分配。category 附着后，方法/属性/协议列表通常进入这里。
`method_list_t`	`entsizeAndFlags`、`count`、方法条目	方法列表。加载时会 uniquing selector，必要时排序并标记 fixed-up。
`category_t`	`cls`、`instanceMethods`、`classMethods`、`protocols`、`instanceProperties`	分类元数据。目标类已 realized 时立即附着，否则暂存到 unattached categories。
`header_info`	`classlist`、`nlclslist`、`catlist`、`selrefs`、`protocolrefs`	一个 Mach-O 镜像的 ObjC 元数据索引。`objc-os.mm` 中 `addHeader` 负责创建或取出它。

类数据从 ro 切换到 rw

struct objc_class : objc_object {
 Class superclass;
 cache_t cache;
 class_data_bits_t bits; // 未实现时指向 class_ro_t，实现后指向 class_rw_t
};

struct class_rw_t {
 uint32_t flags; // RW_REALIZED、RW_FUTURE、RW_INITIALIZED 等
 explicit_atomic<uintptr_t> ro_or_rw_ext;
 Class firstSubclass;
 Class nextSiblingClass;
};

class_data_bits_t::safe_ro() 允许在并发 realize 场景下安全取出 ro。 setData() 则在 realization 或构造阶段把 objc_class::bits 改成 rw 指针，并设置 FAST_IS_RW_POINTER。

AFNetworking 源码导读

Sat, 02 May 2026 22:32:27 +0800

本文基于 AFNetworking 4.0.1（2020 年发布，仓库最后一次迭代）源码进行分析。AFNetworking 虽然已进入"稳定休眠"状态，但它作为 iOS 网络层的教科书级实现，其 NSURLSession 封装、HTTPS 校验、Multipart 流式上传、Method Swizzling 等设计思路至今仍值得每一位 iOS 工程师学习。源码仓库：AFNetworking/AFNetworking。

一、整体架构

AFNetworking 的整个库只有 7 个核心类，按职责划分为"核心会话"、“序列化”、“安全”、“可达性”、“UIKit 扩展"五个子模块（对应 CocoaPods Subspec 拆分）：

graph TB
subgraph "核心会话层 (NSURLSession 封装)"
A["AFURLSessionManager
NSURLSession 代理总线"]
B["AFHTTPSessionManager
HTTP 便利方法 GET/POST/..."]
C["AFURLSessionManagerTaskDelegate
每个 Task 的代理持有者"]
end
subgraph "序列化层 (Serialization)"
D["AFHTTPRequestSerializer
URL 编码 / 头部 / User-Agent"]
E["AFJSONRequestSerializer
AFPropertyListRequestSerializer"]
F["AFStreamingMultipartFormData
AFMultipartBodyStream (流式上传)"]
G["AFHTTPResponseSerializer
+ JSON/XML/Image/PropertyList"]
end
subgraph "安全层 (Security)"
H["AFSecurityPolicy
SSL Pinning (None/Certificate/PublicKey)"]
end
subgraph "可达性层 (Reachability)"
I["AFNetworkReachabilityManager
基于 SCNetworkReachability"]
end
subgraph "UI 扩展 (UIKit+AFNetworking)"
J["UIImageView+AFNetworking
UIButton+AFNetworking
UIActivityIndicatorView+AFNetworking ..."]
end
B --> A
A --> C
A --> D
A --> G
A --> H
A --> I
D --> E
D --> F
J --> B

源码目录一览（AFNetworking 4.0.1）：

Swift 面试：泛型、协议与派发源码解析

Tue, 16 Jun 2026 09:06:27 +0800

Swift 面试：泛型、协议与派发源码解析

Swift 面试里，泛型和协议经常不是单独问语法，而是连着问：Swift 中函数派发机制有哪几种？泛型是编译期还是运行期机制？协议调用为什么可能慢？some 和 any 为什么性能不同？Protocol Witness Table 到底是什么？

这篇文章按面试题展开，把答案落到 Swift 编译器里的 Generic Signature、Generic Specializer、SIL 调用指令、Protocol Witness Table、class vtable 和 Devirtualize 优化。

面试高频问题

Swift 中函数派发机制有哪几种？
直接派发、class vtable 派发、witness table 派发、Objective-C 消息派发分别适用于什么场景？
function_ref、class_method、witness_method、objc_method 在 SIL 里分别代表什么？
如何用 swiftc -emit-silgen / swiftc -emit-sil -O 观察派发指令？
dynamic / @objc dynamic 会怎样影响派发？
如何用代码对比泛型、some、any 的派发和性能差异？
Swift 泛型是运行时泛型还是编译期泛型？
Generic Signature 是什么？它保存哪些信息？
泛型特化为什么能提升性能？
Protocol Witness Table 是什么？
协议方法调用什么时候是静态派发，什么时候是动态派发？
some Protocol 和 any Protocol 的本质区别是什么？
final、private、具体类型为什么有利于优化？
协议扩展里的方法一定是动态派发吗？
class_method 和 witness_method 有什么区别？
面试里如何解释“Swift 既强调协议，又强调性能”？

30 秒回答版

Swift 函数派发面试不要只答“静态派发和动态派发”。更完整的分类是：直接派发、class vtable 派发、protocol witness table 派发、Objective-C 消息派发，再补充优化器可能把动态调用去虚拟化成直接调用。

Objective-C 消息发送 objc_msgSend 与慢速查找入口

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime dispatch

Objective-C 消息发送：objc_msgSend 与慢速查找入口

Objective-C 的方法调用本质上是一次以 receiver 和 SEL 为键的动态派发。在 arm64 上，objc_msgSend 先用少量汇编完成 nil/tagged pointer 判断和方法缓存查找；只有缓存未命中时，才进入 C++ 慢路径 lookUpImpOrForward，沿类层级查找、触发动态解析、填充缓存或进入消息转发。

入口：runtime/Messengers.subproj/objc-msg-arm64.s 慢路径：runtime/objc-runtime-new.mm 缓存：runtime/objc-cache.mm 测试：test/msgSend.m

作用

objc_msgSend(id self, SEL _cmd, ...) 是 Objective-C 实例方法和类方法调用的公共派发入口。编译器把 [obj method:arg] 形式的调用降低为对 objc_msgSend 的调用；真正执行哪个 IMP 由运行时根据接收者的实际类、选择子和当前方法缓存决定。

动态派发

同一个 SEL 可以在不同类上命中不同 IMP，体现多态。

缓存加速

大多数热路径只扫描类的 cache_t，命中后直接尾调用 IMP。

语义兼容

nil 接收者返回零值；tagged pointer 通过标签映射到伪类继续派发。

扩展入口

未找到实现时支持 +resolve... 和完整的 forwarding 机制。

Alamofire源码导读

Sat, 02 May 2026 22:32:27 +0800

Alamofire 是 Swift 社区最广泛使用的 HTTP 网络库，由 Alamofire Software Foundation 维护，在 GitHub 已收获 42k+ star。它在 URLSession 之上构建了一整套链式 API、拦截器、认证、证书校验、重试与响应序列化等能力。本文基于最新版本 v5.11.2（2026 年 4 月发布）源码进行分析，覆盖 Swift 6 严格并发、async/await、WebSocket、OfflineRetrier 等最新特性。

一、整体架构

Alamofire 采用中央调度 + 状态机 + 协议导向的设计，核心角色分工清晰：

graph TB
subgraph "入口层"
AF["AF
(Session.default)"]
end
subgraph "调度层"
S["Session
统一调度器"]
SD["SessionDelegate
URLSession 桥接"]
end
subgraph "请求层"
R["Request (基类)
状态机 + 生命周期"]
DR["DataRequest"]
DLR["DownloadRequest"]
UR["UploadRequest"]
DSR["DataStreamRequest"]
WSR["WebSocketRequest"]
end
subgraph "拦截层"
RA["RequestAdapter
请求改写"]
RR["RequestRetrier
失败重试"]
RI["RequestInterceptor
= Adapter + Retrier"]
end
subgraph "服务层"
RS["ResponseSerializer
响应序列化"]
STE["ServerTrustEvaluating
证书/公钥校验"]
EM["EventMonitor
事件监控"]
MP["MultipartFormData
表单编码"]
end
subgraph "系统层"
US["URLSession / URLSessionTask"]
end
AF --> S
S --> SD
S -->|创建| R
R --> DR & DLR & UR & DSR & WSR
S -.使用.-> RI
RI -.= .-> RA & RR
R -.序列化.-> RS
SD -.校验.-> STE
S -.通知.-> EM
UR -.构建.-> MP
SD <-->|delegate| US
R -->|执行| US

源码目录（Source/，总计约 17000 行纯 Swift 代码）：

Swift 面试：值语义、COW 与集合源码解析

Tue, 16 Jun 2026 09:06:27 +0800

Swift 面试：值语义、COW 与集合源码解析

Swift 的 Array、String、Dictionary 都表现为值类型，但它们不可能每次赋值都完整复制底层存储。面试官问值语义和 COW，真正想看的是你能不能说清楚：值语义是语言语义，COW 是性能实现；集合表面是 struct，底层经常共享引用存储；写入前靠唯一性检查决定是否复制。

这篇文章从面试题出发，把结论落到 Swift 标准库源码里的 Array buffer、String guts、Dictionary storage 和 isKnownUniquelyReferenced。

面试高频问题

Swift 的 struct 为什么常说是值语义？
Array 赋值时一定会复制底层元素吗？
Copy-on-Write 的触发条件是什么？
isKnownUniquelyReferenced 检查的到底是什么？
Array、ContiguousArray、ArrayBuffer、Storage 是什么关系？
String 为什么不能用整数下标随机访问？
String.Index 为什么不是一个简单的 Int？
Dictionary 也是 COW 吗？
ArraySlice 为什么可能持有原数组存储？
值类型里包含 class 引用，还算值语义吗？

30 秒回答版

Swift 的值语义是说：从语言使用者角度看，赋值、传参、修改不会意外影响另一个值。但这不等于底层每次都立即复制。

标准库集合通常用 Copy-on-Write 实现：多个值可以共享同一份堆上 buffer；只有当某个值要写入时，才检查底层 buffer 是否唯一引用。如果唯一，就原地修改；如果不唯一，就复制一份新 buffer 再修改。

所以：

值语义：用户看到的是独立值
COW：实现上先共享，写入前再判断是否复制
ARC：维护底层 buffer 的引用计数
isUnique：让 COW 判断能否原地修改

面试可以这样回答：

Swift 的 Array 是 struct，但它内部持有引用语义的 storage。赋值时通常只复制结构体里的引用；真正写入时通过唯一性检查决定是否复制底层 storage。这让 Array 同时具备值语义和接近引用共享的性能。

objc4 方法缓存 cache_t / bucket_t 技术讲解

Mon, 01 Jun 2026 19:50:12 +0800

objc4 方法缓存 cache_t / bucket_t 技术讲解

本文基于当前仓库中的 runtime/objc-cache.mm、 runtime/objc-runtime-new.h、runtime/objc-runtime-new.mm 以及 cache flush 相关测试，说明 Objective-C runtime 如何把一次慢速方法查找变成后续的快速 objc_msgSend cache hit。

一、方法缓存的作用

Objective-C 消息发送以 (Class, SEL) 为核心输入。完整方法查找需要处理类实现、父类链、动态方法解析、转发和分类变更等逻辑，代价高于一次普通函数调用。cache_t 是挂在每个 objc_class 上的 IMP cache，用 SEL 作为 key，缓存最终应该调用的 IMP。

加速热路径命中时 objc_msgSend 不进入 runtime 慢路径，直接由 bucket 中的 IMP 跳转。

缓存继承结果子类未实现某 selector 时，也可以把父类找到的 IMP 缓存在子类 cache 中。

支持动态变更分类加载、添加方法、交换实现等操作会触发 cache flush，避免继续调用旧 IMP。

cache 不是方法列表本身，也不是权威数据源。它是一个可丢弃、可重建的性能结构；扩容时甚至不会搬迁旧条目，而是让后续消息重新填充热点 selector。

二、核心结构

`bucket_t`：一个 selector 到 IMP 的槽位


字段	`_sel` 保存 selector，`_imp` 保存编码后的 IMP。arm64 上 IMP 在前，其他架构通常 SEL 在前，以贴合汇编 fast path 和指针认证需求。
`sel()`	以 relaxed atomic 读取 selector。空槽的 selector 为 0。
`imp(base, cls)`	读取并解码 IMP。arm64e 可使用 ptrauth，部分配置使用 class 指针 XOR，未编码配置则直接返回。
`set<Atomic, Encoded>()`	写入一个 bucket。写入顺序被精心安排，保证无锁读取者不会看到“新 SEL + 旧 IMP”的错误组合。

`cache_t`：每个类上的哈希表


`_bucketsAndMaybeMask`	保存 buckets 指针，有些 64 位配置还把 mask 打包进高位；preoptimized cache 也用低位 marker 复用这个字段。
`_mask` / 内联 mask	bucket 数量始终为 2 的幂，`mask = capacity - 1`，哈希后用按位与得到起始槽。
`_occupied`	已占用动态 bucket 数。插入成功后递增；换表时清零。
`_flags`	保存若干快速路径标记，例如 metaclass、C++ ctor/dtor、默认 alloc 或 RR 等，具体位定义在 `objc-runtime-new.h`。
关键方法	`insert`、`eraseNolock`、`destroy`、`copyCacheNolock`、`maybeConvertToPreoptimized`、`preoptFallbackClass`。

`preopt_cache_t`：dyld shared cache 预构建的常量 cache


`fallback_class_offset`	预优化查找未覆盖时继续查找的类，相对当前 class 地址保存。
`shift` / `mask`	用于计算预优化 entries 下标。`capacity()` 返回 `mask + 1`。
`occupied`	预优化 cache 中的有效条目数量。
`has_inlines`	标记是否存在内联 selector；方法列表变更时需要更谨慎地禁用这类 cache。
`entries[]`	每项保存 selector offset 和 IMP offset，而不是直接保存完整指针。

三、实现原理

动态 cache 是一个开放寻址哈希表。cache_hash(sel, mask) 用 selector 地址和 mask 得到起始槽；冲突时调用 cache_next 继续探测。不同架构的探测方向不同：部分架构递增并使用 end marker， arm64 递减并通过 mask 回绕。

IGListKit源码导读

Sat, 02 May 2026 22:32:27 +0800

IGListKit 是 Instagram（Meta）开源的一款数据驱动的 UICollectionView 框架，旨在构建快速、灵活的列表。它的核心思想是将每个数据对象映射为独立的 Section Controller，通过高效的 O(n) Diff 算法自动计算数据变化并应用最小化更新，避免手动调用 performBatchUpdates 或 reloadData。本文基于 v5.2.0 源码（2026年2月发布）进行分析。

一、整体架构

IGListKit 采用分层架构，核心由三大模块构成：

graph TB
subgraph "使用层"
A["UIViewController"]
end
subgraph "适配层"
B["IGListAdapter"]
C["IGListAdapterDataSource"]
end
subgraph "控制层"
D["IGListSectionController"]
E["IGListBindingSectionController"]
end
subgraph "更新层"
F["IGListAdapterUpdater"]
G["IGListUpdateCoalescer"]
H["IGListUpdateTransaction"]
end
subgraph "Diff层 (IGListDiffKit)"
I["IGListDiff
Paul Heckel算法"]
J["IGListDiffable协议"]
end
subgraph "视图层"
K["UICollectionView"]
end
A --> B
B --> C
B --> D
D --> E
B --> F
F --> G
F --> H
H --> I
I --> J
B --> K

源码目录结构：

Swift 面试：并发、async/await 与 Actor 源码解析

Tue, 16 Jun 2026 09:06:27 +0800

Swift 面试：并发、async/await 与 Actor 源码解析

Swift Concurrency 面试经常从 async/await 问起，但真正的重点是：Task 是结构化并发的执行单元，await 是显式暂停点，Actor 通过隔离和串行执行器保护状态，Sendable 则约束跨并发边界传递的数据。

这篇文章按面试题展开，把结论落到 Swift 标准库和编译器源码里的 Actor、GlobalActor、MainActor、AsyncLet、TaskGroup、Sendable 和 ActorIsolation。

面试高频问题

async/await 和 GCD 的关系是什么？
await 到底表示线程阻塞还是任务暂停？
Task、async let、TaskGroup 有什么区别？
Actor 如何保证数据隔离？
MainActor 是什么，为什么 UI 更新要回到 MainActor？
GlobalActor 和普通 Actor 有什么区别？
Sendable 解决什么问题？
Task.detached 为什么要慎用？
Actor 之间调用为什么需要 await？
Swift Concurrency 是编译器机制还是运行时机制？

30 秒回答版

Swift Concurrency 是编译器、标准库和运行时共同完成的并发模型。

async/await 不是对 GCD 的简单语法糖。await 表示当前异步任务可能在这里暂停，把执行权交还给调度器；等异步结果可用时，再从 continuation 恢复。它不应该理解成“阻塞当前线程等待”。

Actor 是一种受隔离保护的引用类型。Actor 内部可变状态只能在 actor 隔离域内访问；跨 actor 访问必须异步，编译器会插入隔离检查。运行时通过 executor 保证同一 actor 的隔离状态不会被多个任务同时进入。

Objective-C Category 装载与附加机制

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime

Category 装载与方法、协议、属性附加

Category 的本质不是“修改类结构体”，而是在镜像加载和类实现化时，把分类携带的方法列表、协议列表、属性列表合并到目标类或元类的可变列表视图中。objc4 同时要处理未实现类、stub class、dyld 预附加列表、方法缓存失效和 +load 顺序。

runtime/objc-runtime-new.mm runtime/objc-runtime-new.h runtime/objc-loadmethod.mm test/category.m 等测试

作用

扩展类行为

分类把实例方法挂到类，把类方法挂到元类，让现有类获得新 selector 或覆盖既有 selector。

扩展反射信息

分类的协议和属性参与 class_copyProtocolList、class_getProperty 等运行时查询。

保持加载顺序

后加载的分类应优先被方法查找看到，所以列表附加采用“前插”。

支持动态镜像

bundle、共享缓存、stub class 和未实现类都能在不同时间点接收分类。

关键结论：分类附加不是把方法逐个复制进类定义，而是把 method_list_t、protocol_list_t、property_list_t 这类“列表”挂到 class_rw_ext_t 的数组视图前端。

实现原理总览

Mach-O 镜像

__objc_catlist / __objc_catlist2 中保存 category_t *。runtime 通过 header_info 知道分类来自哪个镜像。

→

分类分流

目标类未实现则暂存到 unattachedCategories；目标类已实现则立即 attachCategories。

→

列表前插

attachLists 把新增列表放在旧列表前面，方法查找和反射会先看到分类列表。

依据：load_categories_nolock 分流逻辑见 runtime/objc-runtime-new.mm:3585-3717；列表前插见 runtime/objc-runtime-new.h:2021-2105。

Kingfisher源码导读

Sat, 02 May 2026 22:32:27 +0800

Kingfisher 是一款纯 Swift 图片下载和缓存库，支持 iOS、macOS、tvOS、watchOS 和 visionOS 全平台。当前最新版本为 8.8.0（2026年3月），已全面适配 Swift 6 严格并发模型。本文基于 v8.x 源码进行分析。

一、整体架构

Kingfisher 采用协议导向的模块化设计，核心由四大组件构成：

graph TB
subgraph "UI层"
A["UIImageView.kf / KFImage"]
end
subgraph "管理层"
B["KingfisherManager"]
end
subgraph "功能层"
C["ImageDownloader"]
D["ImageCache"]
E["ImageProcessor"]
end
subgraph "存储层"
F["MemoryStorage.Backend
(NSCache)"]
G["DiskStorage.Backend
(FileManager)"]
end
A -->|"retrieveImage"| B
B -->|"下载"| C
B -->|"缓存"| D
B -->|"处理"| E
D --> F
D --> G

源码目录结构：

Sources/
├── General/ # KingfisherManager, KingfisherOptionsInfo, Resource, Source
├── Networking/ # ImageDownloader, SessionDelegate, ImagePrefetcher
├── Cache/ # ImageCache, MemoryStorage, DiskStorage
├── Image/ # ImageProcessor, 图片格式处理, 滤镜
├── Extensions/ # UIKit/AppKit 扩展 (ImageView+Kingfisher, UIButton+Kingfisher)
├── SwiftUI/ # KFImage, KFAnimatedImage, ImageBinder
├── Views/ # AnimatedImageView
└── Utility/ # 辅助工具类

二、命名空间设计 — KingfisherWrapper

Kingfisher 使用 kf 命名空间来避免对系统类型的污染，这是 Swift 社区广泛使用的一种模式。

Swift 面试：编译流程、Runtime 与元数据源码解析

Tue, 16 Jun 2026 09:06:27 +0800

Swift 面试：编译流程、Runtime 与元数据源码解析

Swift 面试里问编译流程和 Runtime，通常不是想听一串名词，而是想看你能不能把 源码 -> AST -> SIL -> 优化 -> IRGen -> LLVM -> Runtime Metadata 串起来。

这篇文章按面试题展开，把答案落到 Swift 编译器源码里的 SILGen、SILOptimizer、IRGen、Metadata、Value Witness Table、Protocol Witness Table 和 HeapObject。

面试高频问题

Swift 源码从 .swift 到机器码经历哪些阶段？
AST、SIL、LLVM IR 分别负责什么？
为什么 Swift 需要 SIL，而不是直接生成 LLVM IR？
SILGen 做什么？SILOptimizer 做什么？
IRGen 为什么要生成 Metadata 和 Witness Table？
Swift Runtime Metadata 保存了哪些信息？
Value Witness Table 是什么？
Protocol Witness Table 和 class vtable 有什么区别？
class、struct、enum 在 Runtime 表示上有什么差异？
HeapObject 和 Metadata 有什么关系？

30 秒回答版

Swift 编译流程可以简化为：

Objective-C +load 调度：load_images 与 call_load_methods

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime

+load 调度：从 load_images 到 call_load_methods

这页解释 objc4 如何在 dyld 映射镜像后发现、排队并调用 Objective-C 的 +load。重点是类与分类的顺序、父类优先、递归和重入处理，以及 runtimeLock 与 loadMethodLock 的边界。

入口：dyld callback 队列：loadable_classes / loadable_categories 调度：call_load_methods 测试：load*.m

作用

+load 是 Objective-C 运行时在类或分类被装入进程时主动调用的类方法。它不依赖消息发送触发，也早于普通的 +initialize。objc4 的任务不是简单遍历所有方法并调用，而是在 dyld 映射镜像、runtime 完成类注册和分类附着后，按照语言语义和装载依赖稳定地调用。

装载时机

dyld 通过 _dyld_objc_register_callbacks 注册 runtime 回调。镜像映射后先走 map_images，随后 load_images 处理该镜像中的非懒加载类和分类。

顺序语义

类 +load 必须父类优先；所有当前可调用的类 +load 先于分类 +load；分类必须等宿主类已经完成自己的 +load。

重入安全

+load 内部可能 dlopen 新镜像，再次进入 load_images。objc4 让内层调用只排队，真正调用由最外层 call_load_methods 收尾。

实现原理

objc4 将 +load 分成“发现”和“调用”两阶段。发现阶段需要持有 runtimeLock，因为它要读取和实现类、解析分类、查找元类方法列表。调用阶段释放 runtimeLock，只持有递归的 loadMethodLock，因为用户代码可能执行任意 Objective-C 行为并重新映射镜像。

RxSwift源码导读

Sat, 02 May 2026 22:32:27 +0800

RxSwift 是 ReactiveX 在 Swift 上的实现，提供了一套完整的响应式编程框架。它通过 Observable 序列和操作符组合的方式，简化了异步编程、事件处理和数据流管理。本文基于 v6.10.2（2026年3月发布）源码进行分析。

一、整体架构

RxSwift 项目采用模块化设计，包含五个独立模块：

graph TB
subgraph "核心层"
A["RxSwift
核心响应式框架"]
end
subgraph "扩展层"
B["RxCocoa
UIKit/AppKit绑定"]
C["RxRelay
Relay封装"]
end
subgraph "工具层"
D["RxBlocking
阻塞操作"]
E["RxTest
测试工具"]
end
B --> A
C --> A
D --> A
E --> A

源码目录结构：

RxSwift/
├── Concurrency/ # 并发工具（AsyncLock等）
├── Disposables/ # 资源释放（DisposeBag、CompositeDisposable等）
├── Extensions/ # Swift扩展
├── Observables/ # Observable实现（Create、Map、Filter、Merge等）
├── Observers/ # Observer实现（AnonymousObserver、ObserverBase等）
├── Platform/ # 平台适配（原子操作、锁等）
├── Schedulers/ # 调度器（MainScheduler、SerialDispatchQueueScheduler等）
├── Subjects/ # Subject实现（PublishSubject、BehaviorSubject等）
├── SwiftSupport/ # Swift语言支持
├── Traits/ # 特化序列（Single、Completable、Maybe、Infallible）
├── Observable.swift # Observable基类
├── ObservableType.swift # Observable协议
├── ObserverType.swift # Observer协议
├── Event.swift # 事件枚举
├── Disposable.swift # Disposable协议
├── Binder.swift # UI绑定
├── AnyObserver.swift # 类型擦除Observer
└── Reactive.swift # .rx命名空间

语言构成： 纯 Swift 实现，100% Swift 代码。

+initialize 懒初始化与并发状态机

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime 懒初始化并发等待 fork safety

+initialize 懒初始化与并发状态机

+initialize 是 Objective-C 运行时在类第一次被真正使用时触发的类级初始化钩子。 objc4 的实现重点不是“调用一个方法”，而是用每个类的递归初始化锁、元类上的状态位、线程本地的初始化列表和 fork 子进程保护规则，保证父类优先、单线程执行、并发可等待、重入不死锁。

作用

+initialize 的语义是：在某个类或其子类第一次收到会触发初始化的消息前，运行时先给该类发送一次 +initialize。这让类可以延迟建立全局状态、注册方法、准备缓存或执行只依赖本类的初始化逻辑。

懒触发

objc_getClass() 只查找类，不触发初始化；普通消息发送、部分运行时查询、autorelease 返回值路径和弱引用相关路径可能需要先完成初始化。

父类优先

子类开始初始化前，运行时递归确保父类已经初始化，避免类层次中间被并发线程插入造成死锁。

一次完成

同一类只有一个线程真正发送 +initialize；其他线程要么等待，要么在同一初始化线程重入时直接放行。

实现原理

objc4 把 +initialize 做成一个按需进入的并发状态机：消息查找路径发现目标类未初始化时，先把类 realize，再释放 runtimeLock，进入 initializeNonMetaClass()。后者用父类递归、每类递归锁、元类状态位和线程本地初始化列表协调所有线程。真正执行用户代码的线程设置 INITIALIZING，发送 +initialize，最后在 @finally 中切换到 INITIALIZED；其他线程通过同一把类锁等待状态稳定。

这个设计的核心约束是单调性：类状态只从“未初始化”前进到“初始化中”，再前进到“已初始化”。即使 +initialize 抛异常，状态机也会完成收尾；即使发生重入，只有当前初始化线程能绕过等待；即使 fork 发生在多线程初始化期间，子进程也只允许 trivial 初始化继续，其他自定义初始化会主动终止。

核心类/结构状态字段

初始化状态存在类对象的元类标志位里。源码注释明确约束：初始时 RW_INITIALIZING 和 RW_INITIALIZED 都未设置；初始化中只设置前者；完成后清除前者并设置后者；两者永不同时为真，且 RW_INITIALIZED 一旦设置就不会清除。

SDWebImage源码导读

Sat, 02 May 2026 22:32:27 +0800

SDWebImage 是 iOS 生态中历史最悠久、最流行的异步图片下载缓存库，由 Olivier Poitrey 在 2009 年创建，如今由社区维护。截至 2026 年 4 月，GitHub Star 数已超过 25.6k，最新稳定版本为 5.21.7（2026 年 2 月）。5.21 系列引入了 HDR 图片编解码支持，并持续完善线程安全和 iOS 26 的兼容性。本文基于 master 分支源码（Objective-C 实现）进行分析。

一、整体架构

SDWebImage 采用协议导向 + 责任链的模块化设计，核心由五大子系统构成：Manager 协调层、Cache 缓存层、Downloader 下载层、Coder 编解码层和 UI 扩展层。

graph TB
subgraph "UI 扩展层"
A["UIImageView+WebCache
UIButton+WebCache
UIView+WebCache"]
end
subgraph "管理层"
B["SDWebImageManager"]
end
subgraph "缓存层 SDImageCache"
C1["SDMemoryCache
(NSCache + NSMapTable)"]
C2["SDDiskCache
(NSFileManager)"]
end
subgraph "下载层"
D1["SDWebImageDownloader"]
D2["SDWebImageDownloaderOperation
(NSOperation)"]
end
subgraph "编解码层 SDImageCodersManager"
E1["SDImageIOCoder"]
E2["SDImageGIFCoder"]
E3["SDImageAPNGCoder"]
E4["SDImageHEICCoder
WebP/AVIF (插件)"]
end
subgraph "辅助层"
F["SDImageTransformer
SDWebImageCacheKeyFilter
SDWebImageOptionsProcessor
SDCallbackQueue"]
end
A -->|sd_setImageWithURL| B
B --> C1
B --> C2
B --> D1
D1 --> D2
D2 --> E1
B --> F

源码目录结构：

objc4 Selector / SEL 注册、唯一化与方法名查找

Mon, 01 Jun 2026 19:50:12 +0800

Selector / SEL 注册、唯一化与方法名查找

在 objc4 中，SEL 的关键价值不是承载一段复杂对象，而是把方法名字符串 “驻留”为全进程唯一的指针。注册、镜像加载 fixup、方法列表排序、方法查找和消息缓存都建立在这个事实上：同名 selector 最终拥有同一个地址，因此比较 selector 可以退化为一次指针比较。

作用

统一方法名身份 编译器、Mach-O 镜像、动态注册 API 和运行时内部方法列表都可能产生方法名。selector 唯一化后，同一个方法名只对应一个 SEL。

让查找足够便宜 方法列表和缓存查找不需要反复比较字符串。命中条件基本都是 method.name == sel 或 bucket.sel == _cmd。

支撑 dyld 预优化 共享缓存中的 selector 可以由 dyld 提供内建唯一值；未优化镜像在 _read_images 中被 runtime 修正到唯一值。

对外头文件把 SEL 声明为不透明类型：typedef struct objc_selector *SEL;。但在当前实现中，runtime 会把 selector 当成方法名 C 字符串指针使用，sel_getName() 直接把 SEL 转回 const char *。

核心结构、函数与字段


`SEL`	公开为不透明 selector 指针，实际唯一值是某个方法名字符串的地址。来源：`runtime/objc.h`。
`namedSelectors`	`ExplicitInitDenseSet<const char *>`，保存非 dyld 内建 selector 的唯一字符串指针。来源：`runtime/objc-sel.mm`。
`selLock`	保护 selector 表。`sel_registerName()` 自行加锁；镜像加载和方法列表 fixup 常在外层持锁后调用 `sel_registerNameNoLock()`。
`_sel_searchBuiltins()`	在支持预优化时向 dyld 查询共享缓存内建 selector，优先返回 dyld 已唯一化的值。
`sel_registerName()`	注册并返回 selector；若已存在则返回既有唯一值；会复制传入字符串。
`sel_lookUpByName()`	只查找，不创建。未注册返回 `NULL`，测试 `test/sel.m` 明确覆盖该行为。
`method_t::name`	方法条目的 selector 字段。方法列表 fixup 后，这个字段应是唯一化的 `SEL`。
`cache_t` / `bucket_t`	消息缓存以 `SEL` 为 key，桶保存 `SEL + IMP`，hash 直接来自 selector 地址。

实现原理

selector interning 的核心是“先按名字查找唯一槽，再把槽里的字符串地址作为 SEL 返回”。对 dyld 共享缓存内建 selector，runtime 先问 dyld；对普通 selector，runtime 使用 namedSelectors 保存唯一字符串。

SnapKit源码导读

Sat, 02 May 2026 22:32:27 +0800

SnapKit 是 iOS / macOS 社区最广泛使用的 Auto Layout DSL 库，由 Robert Payne 等人维护，目前在 GitHub 已收获 20k+ star。它在 NSLayoutConstraint 之上构建了一整套链式、类型安全、面向协议的声明式约束语法。本文基于 v5.7.1（2025 年 2 月发布，最后 master commit 2025-05-08 19f59a6）源码进行分析，代码总量不足 3500 行，却用一个分级的 Builder 链路，把 NSLayoutConstraint 那套冗长的 API 封装成了今天我们习惯的 make.left.equalTo(x).offset(10)。

一、整体架构

SnapKit 的核心设计可以用一句话概括：用编译期强约束的链式 Builder，驱动一个延迟构建的 ConstraintDescription，最终在闭包结束后一次性生成 NSLayoutConstraint 并激活。

graph TB
subgraph "DSL 入口层"
V["UIView / NSView / UILayoutGuide"]
SNP["view.snp
(ConstraintViewDSL)"]
MK["makeConstraints
remakeConstraints
updateConstraints"]
end
subgraph "Builder 链（阶段化构建器）"
CM["ConstraintMaker
(属性起点 make.left)"]
CME["ConstraintMakerExtendable
(追加属性 .top.right)"]
CMR["ConstraintMakerRelatable
(关系 equalTo/greaterThan)"]
CMED["ConstraintMakerEditable
(multipliedBy/offset/inset)"]
CMP["ConstraintMakerPrioritizable
(priority)"]
CMF["ConstraintMakerFinalizable
(labeled)"]
end
subgraph "描述 & 协议层"
DESC["ConstraintDescription
(懒加载装配)"]
TARGETS["Target 协议族
Relatable/Constant/Offset
Inset/Multiplier/Priority"]
ATTR["ConstraintAttributes
(OptionSet 位运算)"]
end
subgraph "约束层"
C["Constraint
(封装一组 LayoutConstraint)"]
LC["LayoutConstraint
(NSLayoutConstraint 子类)"]
ITEM["LayoutConstraintItem
(UIView/UILayoutGuide)"]
end
subgraph "系统层"
NSLC["NSLayoutConstraint.activate"]
end
V -->|扩展属性| SNP
SNP --> MK
MK -->|创建| CM
CM -->|返回| CME
CME -->|继承| CMR
CMR -->|equalTo| CMED
CMED -->|继承| CMP
CMP -->|priority| CMF
CM -.写入.-> DESC
CME & CMR & CMED & CMP & CMF -.读写.-> DESC
DESC -.lazy 构建.-> C
C --> LC
C -.关联对象.-> ITEM
DESC -.使用.-> ATTR
CMR -.类型匹配.-> TARGETS
C --> NSLC

源码目录（`Sources/`，约 3500 行）

Sources/
├── ConstraintView.swift # typealias UIView/NSView → ConstraintView
├── ConstraintLayoutGuide.swift # typealias UILayoutGuide/NSLayoutGuide
├── ConstraintLayoutSupport.swift # typealias UILayoutSupport
├── Typealiases.swift # LayoutRelation / LayoutAttribute / LayoutPriority
├── ConstraintConfig.swift # interfaceLayoutDirection 全局开关
│
├── ConstraintView+Extensions.swift # view.snp 入口（含 snp_ 老别名）
├── ConstraintLayoutGuide+Extensions.swift # guide.snp 入口
├── UILayoutSupport+Extensions.swift # topLayoutGuide.snp（iOS 11 前）
├── ConstraintViewDSL.swift # makeConstraints / remake / update / remove
├── ConstraintLayoutGuideDSL.swift # LayoutGuide 版 DSL
├── ConstraintLayoutSupportDSL.swift # LayoutSupport 版 DSL
├── ConstraintDSL.swift # DSL 协议 + 属性定义（left/top/edges/...）
│
├── ConstraintMaker.swift # 属性起点（make.left / make.edges / ...）
├── ConstraintMakerExtendable.swift # 可追加属性（.top.right）
├── ConstraintMakerRelatable.swift # equalTo / lessThanOrEqual / greaterThanOrEqual
├── ConstraintMakerRelatable+Extensions.swift # equalToSuperview 闭包版
├── ConstraintMakerEditable.swift # multipliedBy / dividedBy / offset / inset
├── ConstraintMakerPrioritizable.swift # priority(...)
├── ConstraintMakerFinalizable.swift # labeled(...) + .constraint
│
├── ConstraintAttributes.swift # OptionSet 属性位图
├── ConstraintRelation.swift # equal / lessThanOrEqual / greaterThanOrEqual
├── ConstraintPriority.swift # required/high/medium/low
├── ConstraintDescription.swift # Builder 中间态 + lazy Constraint
├── ConstraintItem.swift # (target, attributes) 二元组（弱引用）
├── LayoutConstraintItem.swift # UIView/UILayoutGuide 统一协议
├── ConstraintInsets.swift # UIEdgeInsets typealias
├── ConstraintDirectionalInsets.swift # NSDirectionalEdgeInsets（iOS 11+）
│
├── ConstraintRelatableTarget.swift # 可作为 equalTo 参数的类型标记
├── ConstraintConstantTarget.swift # constant 目标 + 属性→CGFloat 的派发
├── ConstraintOffsetTarget.swift # offset 目标
├── ConstraintInsetTarget.swift # inset 目标（含标量→insets 转换）
├── ConstraintDirectionalInsetTarget.swift # 方向 insets 目标
├── ConstraintMultiplierTarget.swift # multiplier 目标
├── ConstraintPriorityTarget.swift # priority 目标（Int/Float/UILayoutPriority）
│
├── Constraint.swift # 真正的约束对象 + activate/deactivate
├── LayoutConstraint.swift # NSLayoutConstraint 子类，回指 Constraint
├── Debugging.swift # LayoutConstraint.description 美化
└── PrivacyInfo.xcprivacy # 隐私清单

核心设计思想

模式	作用	源码体现
阶段化 Builder（Staged Builder / Step Builder）	通过继承链控制链式调用的合法顺序，让 `make.left.offset(10).equalTo(...)` 这类非法组合在编译期报错	`ConstraintMaker → Extendable → Relatable → Editable → Prioritizable → Finalizable`
协议 + 类型擦除（POP）	让 `Int / Float / CGFloat / CGSize / CGPoint / UIEdgeInsets / UIView / ConstraintItem` 等异构类型可以统一作为 `equalTo` / `offset` / `priority` 的参数	`Constraint*Target` 协议族
OptionSet 位运算	用 32 位整型表达「属性集合」，`.edges = [.left, .top, .right, .bottom]` 这类聚合用位或实现，避免反复建数组	`ConstraintAttributes`
Associated Object	在不污染 `UIView` 原类的前提下，为每个 View 绑定「它持有的 SnapKit Constraint 集合」和「snp.label」	`LayoutConstraintItem.constraintsSet` + `ConstraintDSL.setLabel`
Lazy 求值	`ConstraintDescription.constraint` 是 `lazy var`，闭包执行结束前只是收集参数，真正的 `Constraint` 构造和 `NSLayoutConstraint` 生成都推迟到最后	`ConstraintDescription.constraint`
跨平台 typealias	通过一组 typealias 把 iOS / macOS / tvOS 的 `UIView`/`NSView`、`UIEdgeInsets`/`NSEdgeInsets`、`UILayoutPriority`/`NSLayoutConstraint.Priority` 等抹平	`ConstraintView.swift` / `Typealiases.swift`

二、DSL 入口：`view.snp`

SnapKit 没有像 Masonry 那样污染 UIView 的命名空间，而是通过一个命名空间结构体暴露 DSL。

objc4 Protocol 结构、注册与查询

Mon, 01 Jun 2026 19:50:12 +0800

1. Protocol 的作用

在 objc4 中，Protocol * 并不是一个只有名字的轻量句柄，而是运行时管理的一类 Objective-C 对象。它承载协议名、继承的协议列表、必需/可选方法列表、实例/类属性列表等元数据。类、分类和协议自身都可以引用这些对象。

对外 API 位于 runtime/runtime.h 的 “Working with Protocols” 区域，例如 objc_getProtocol、objc_copyProtocolList、protocol_conformsToProtocol、 protocol_getMethodDescription、objc_allocateProtocol 与 objc_registerProtocol。 runtime/Protocol.mm 中的 @implementation Protocol 则把老式 Objective-C 消息转接到这些 C API。

关键心智模型：编译器把协议写进镜像的 __objc_protolist 等段；runtime 在 _read_images 中发现并安装协议；后续所有查询都尽量通过“协议名 => 胜出的协议对象”来回到唯一的、当前有效的定义。

2. 核心结构

当前实现中的底层结构定义在 runtime/objc-runtime-new.h。公开的 Protocol * 在实现里经常通过 newprotocol(p) 转成 protocol_t * 使用。

// runtime/objc-runtime-new.h，保留关键字段并加注释
typedef uintptr_t protocol_ref_t; // 尚未 remap 的 protocol_t *

struct protocol_t : objc_object {
 const char *mangledName; // 协议的运行时名字；Swift v1 可能是 mangled 名
 struct protocol_list_t *protocols; // 该协议继承/组合的其他协议
 method_list_t *instanceMethods; // @required 实例方法
 method_list_t *classMethods; // @required 类方法
 method_list_t *optionalInstanceMethods; // @optional 实例方法
 method_list_t *optionalClassMethods; // @optional 类方法
 property_list_t *instanceProperties; // required instance properties
 uint32_t size; // 磁盘结构大小；用于判断尾部字段是否存在
 uint32_t flags; // fixed-up、canonical 等运行时标志

 // 以下字段不是所有磁盘协议结构都有，访问前必须看 size。
 const char **_extendedMethodTypes; // 扩展类型编码
 const char *_demangledName; // Swift demangled 名称缓存
 property_list_t *_classProperties; // 类属性列表
};

struct protocol_list_t {
 uintptr_t count; // 历史原因：count 是指针宽度
 protocol_ref_t list[0]; // 变长数组；元素可能需要 remap
};

关键字段与方法


`mangledName`	全局协议表的 key。`objc_getProtocol` 先按原名查，再查 dyld 预优化表，再尝试 Swift v1 mangled 等价名。
`protocols`	协议继承关系。`protocol_conformsToProtocol` 会递归遍历它；`protocol_copyProtocolList` 只复制直接继承项。
四个方法列表	按 required/optional 与 instance/class 分成四组。`protocol_copyMethodDescriptionList` 只返回当前协议直接声明的方法，不包含父协议。
`size`	兼容小协议或旧 ABI 的关键字段。`protocolSmall.m` 手工构造较小结构，验证访问尾部字段前必须判定字段是否存在。
`flags`	高位用于 `PROTOCOL_FIXED_UP_*` 与 `PROTOCOL_IS_CANONICAL`，标记是否已修正以及共享缓存中的 canonical 定义。

`Protocol` 类

runtime/Protocol.h 只暴露不可直接使用的 @interface Protocol； Protocol.mm 中 -conformsTo:、-name、-isEqual: 分别调用 protocol_conformsToProtocol、protocol_getName 与 protocol_isEqual。

Swinject源码导读

Sat, 02 May 2026 22:32:27 +0800

Swinject 是一款轻量级的 Swift 依赖注入（Dependency Injection）框架，灵感来自 .NET 的 Ninject。它通过类型安全的方式管理对象之间的依赖关系，将对象的创建和使用解耦。本文基于 v2.8.3 源码进行分析。

一、整体架构

Swinject 的核心设计围绕**注册-解析（Register-Resolve）**模式展开，整个框架仅约 20 个源码文件，代码极为精简。

graph TB
subgraph "组织层"
A["Assembler"]
B["Assembly (Protocol)"]
end
subgraph "核心层"
C["Container"]
D["Resolver (Protocol)"]
end
subgraph "注册层"
E["ServiceEntry<Service>"]
F["ServiceKey"]
end
subgraph "作用域层"
G["ObjectScope"]
H["InstanceStorage (Protocol)"]
end
subgraph "存储实现"
I["TransientStorage"]
J["GraphStorage"]
K["PermanentStorage"]
L["WeakStorage"]
end
subgraph "包装器"
M["Lazy<Service>"]
N["Provider<Service>"]
end
A -->|"管理"| B
B -->|"assemble(container:)"| C
C -->|"实现"| D
C -->|"存储注册信息"| E
E -->|"由 ServiceKey 索引"| F
E -->|"关联"| G
G -->|"创建"| H
H --- I
H --- J
H --- K
H --- L
C -->|"延迟解析"| M
C -->|"每次新建"| N

源码文件结构：

Tagged Pointer 对象实现讲解

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime internals

Tagged Pointer 对象

Tagged Pointer 是一种“指针即对象”的表示法：对象没有堆内存，类信息和 payload 直接编码在指针位中。objc4 对它提供了创建、取 tag、取 payload、取类、消息发送、禁用和混淆等完整路径。

目录作用实现原理核心宏、结构、函数关键流程测试视角源码依据

作用

减少堆分配

小整数、短字符串、日期、索引路径等小对象可以直接塞进指针。NSNumber 的小整数就是典型例子，test/taggedNSPointers.m 验证了 NSNumber numberWithInt:1234 是 tagged pointer。

保留对象语义

虽然指针不指向对象内存，它仍能接收消息、查询类、作为字典 key/value，并通过 Foundation/CF 桥接。运行时把 tag 映射到真实 Class 后，继续走常规方法缓存查找。

绕开生命周期表

test/taggedPointers.m 验证 retain、release、autorelease、weak store/load 对 tagged pointer 不产生真实引用计数或弱引用表负担。它们本质上是立即值，不需要释放。

**一句话：**Tagged Pointer 把“对象身份”改成“位编码值”。运行时需要做的，是在所有需要对象元数据的地方识别它，并把 tag 翻译成类。

实现原理

objc4 在 64 位平台启用 tagged pointer。runtime/objc-config.h 中 SUPPORT_TAGGED_POINTERS 对 __LP64__ 为 1；非 64 位平台关闭。tag 标记位在大多数平台使用 MSB，macOS x86_64 使用 LSB。arm64 还使用 split tagged pointer 布局。

Texture源码导读

Sat, 02 May 2026 22:32:27 +0800

TODO: 待补充

objc4：isa_t、nonpointer isa、引用计数与 SideTable

Mon, 01 Jun 2026 19:50:12 +0800

isa_t、nonpointer isa、引用计数与 SideTable

本文基于 objc4 仓库中的 runtime 源码和相关测试，解释 Objective-C 对象头里的 isa_t 如何同时承载类信息、引用计数、弱引用/关联对象标记，以及这些信息何时转移到 SideTable。

作用
实现原理与位布局
核心结构和关键字段方法
关键流程
测试如何约束行为

1. 作用

传统 Objective-C 对象的第一个机器字是 isa，直接保存类指针。objc4 在支持 SUPPORT_NONPOINTER_ISA 的平台上把这个机器字扩展为 isa_t：低位和高位保存状态，中间区域保存类信息。这样一次对象头访问就能拿到类、内联引用计数、是否有弱引用、是否有关联对象、是否可能有 C++ 析构等信息。

为什么要 nonpointer isa

对象绝大多数时候引用计数很小，把计数放进 isa 可让 retain/release 走原子 CAS 快路径，避免进入全局散列表和锁。

为什么仍需要 SideTable

isa 空间有限。引用计数溢出、raw isa 对象、弱引用表，以及 deallocating 状态的兼容存储，都需要 SideTable。

raw isa 的存在原因

类对象始终使用 raw pointer isa；某些类通过 instancesRequireRawIsa() 或运行时配置禁用 nonpointer isa；测试 rawisa.m 还覆盖了 __DATA,__objc_rawisa 段禁用 nonpointer isa 的场景。

fishhook 源码导读

Sat, 02 May 2026 22:32:27 +0800

fishhook 由 Facebook 于 2013 年开源，用于在运行时动态重绑定（rebind）Mach-O 中被 dyld 绑定的 C 符号，是 iOS/macOS 逆向与底层埋点（malloc 追踪、双 close 检测、网络 socket 拦截、NSLog 重定向等）领域的"瑞士军刀"。

一、fishhook 是什么

一句话定义：fishhook 通过修改 Mach-O 镜像中 __DATA(_CONST) 段里 __la_symbol_ptr / __nl_symbol_ptr 两个 Section 中的函数指针，把对外部 C 符号（如 open、close、NSLog）的调用重定向到自定义的替换函数，同时保留原函数指针供回调使用。

它提供的能力类似 macOS 上 DYLD_INTERPOSE 宏（编译期 interpose），但：

运行时生效：不需要重新编译依赖库，随时可以在 App 启动后对系统库的 C 函数下钩子；
支持动态加载的 image：注册后对后续 dlopen 加载的 image 同样生效；
对业务零侵入：不改 App 本身的代码段，也不破坏符号表，只是重写 GOT/stub 里的一个指针。

但它也有非常明确的能力边界：

能力	是否支持
Hook 通过 `dyld` 动态绑定的外部 C 函数（libSystem、CoreFoundation 里的 C API、`objc_msgSend` 等）	是
Hook Objective-C 方法（`-[NSString length]`）	否（要用 Method Swizzling）
Hook 当前 image 内部的 C 函数（静态链接、`static`、内联）	否（它不走 `__la_symbol_ptr`，直接是段内相对寻址）
Hook Swift 方法（除非显式 `@_cdecl`）	否
Hook 已经解析并内联到寄存器里的符号（如 LTO 后消失的符号）	否

记住这条原则：fishhook 的作用域 = 被 dyld 绑定为"间接符号"（Indirect Symbol）的 C 符号。

Objective-C weak 指针作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime zeroing weak SideTable weak_table_t

Objective-C weak 指针：作用与实现原理

__weak 的核心价值是“引用对象但不拥有对象”：它不会增加引用计数；当对象开始销毁时，runtime 会把所有指向它的 weak 槽位自动写成 nil，避免野指针。这一页按 objc4 源码中的真实路径解释它如何登记、读取、搬迁和清零。

1. weak 的作用

不拥有对象__weak id x = obj; 不会 retain obj，所以不会延长对象生命周期。

自动归零对象销毁时，所有保存该对象地址的 weak 变量会被 runtime 写成 nil。

读时短暂保活读取 weak 时，runtime 会先尝试 retain，再 autorelease，保证表达式使用期间对象不被并发释放。

拒绝无效目标目标正在 dealloc 或类不支持 weak 时，形成 weak 引用会失败或崩溃，取决于入口函数。

**一句话模型：**strong 指针管“拥有关系”，weak 指针管“可观察关系”。delegate、反向引用、缓存回调对象通常适合 weak，因为它们不应该阻止真实所有者释放对象。

2. 运行时数据模型

weak 表不是全局一把大表直接裸用，而是挂在分片的 SideTable 上。runtime 用对象地址选择某个 SideTable，在该表内维护引用计数辅助信息和 weak 表，并用同一把锁保护它们。

CocoaPods 源码导读：从下载到工程集成

Sat, 02 May 2026 22:32:27 +0800

本文是系列第三篇，基于 CocoaPods 1.16.2 源码。上一篇我们停在 Analyzer 产出 AnalysisResult，本文继续走完 download_dependencies → validate_targets → generate_pods_project → integrate_user_project → write_lockfiles 这五个阶段。

上一篇：从命令到依赖求解 · 首篇：架构总览

一、全景：从 spec 到可编译的工程

先把本文要走的流程重新放一遍，让你带着地图读代码：

flowchart TB
A[AnalysisResult] --> B[download_dependencies]
B -->|per pod| B1[PodSourceDownloader]
B1 -->|命中| C1[Downloader::Cache]
B1 -->|未命中| C2[cocoapods-downloader
Git/HTTP/SVN/...]
C2 --> C3[rsync → Pods/<name>/]
B -->|per pod| B2[PodSourceInstaller]
B2 --> B3[PodSourcePreparer
prepare_command]
B2 --> B4[PodDirCleaner
按 spec.source_files 裁剪]
B --> D[validate_targets
TargetValidator#validate!]
D --> E[generate_pods_project]
E --> E1[ProjectCacheAnalyzer
增量识别要重生成的 target]
E --> E2[SinglePodsProjectGenerator#generate!]
E2 --> E21[FileReferencesInstaller]
E2 --> E22[PodTargetInstaller]
E2 --> E23[AggregateTargetInstaller]
E2 --> E24[xcconfig / modulemap / umbrella / info.plist / dummy.m]
E --> E3[PodsProjectWriter#write!
写盘前触发 Podfile post_install]
E --> F[integrate_user_project]
F --> F1[create_workspace
写 .xcworkspace]
F --> F2[deintegrate_removed_targets]
F --> F3[TargetIntegrator#integrate!
xcconfig / frameworks / scripts]
F --> G[write_lockfiles]
G --> G1[Podfile.lock]
G --> G2[Pods/Manifest.lock]
G --> H[perform_post_install_actions
plugin post_install hook]

对应的 Installer#install! 片段：

objc4 Autorelease 一页讲透

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime guide

Autorelease 的作用和实现原理

一句话：autorelease 是“延迟一次 release”的机制。对象先被登记到当前线程的自动释放池中，等池子 pop 时再统一发送 release，从而让返回值和临时对象可以跨过当前语句或当前函数继续存活一小段时间。

核心文件：runtime/NSObject.mm 数据结构：AutoreleasePoolPage 线程隔离：TLS hot page 边界标记：POOL_BOUNDARY

先建立正确心智模型

autorelease pool 不是一堆对象的容器类。 在 objc4 里，它更像每个线程私有的一条栈。栈里放两类指针：普通对象指针，以及表示池边界的 POOL_BOUNDARY。每次 push 池，就压入一个边界并返回这个边界地址作为 token。每次 autorelease 对象，就把对象指针压到 hot page 的 next 位置。pop 时拿 token 找到边界，把边界之上的对象按后进先出的顺序逐个 objc_release。

它解决什么问题

**返回 +0 对象：**被调用方可以返回一个“当前调用者可用，但不归调用者拥有”的对象。
**批量释放临时对象：**循环、事件回调、线程入口可以用池边界控制临时对象峰值。
兼容手动引用计数：retain 表示拿所有权，release 表示交回所有权，autorelease 表示稍后自动交回。
**配合 ARC 优化：**运行时和编译器会尝试消除返回值中的多余 retain/autorelease。

一张图看懂栈变化

假设外层池中 autorelease 了 A，又进入内层池 autorelease 了 B、C。内层 pop 只释放 B、C，不影响外层 A。

push 外层

CocoaPods 源码导读：从命令到依赖求解

Sat, 02 May 2026 22:32:27 +0800

本文是系列第二篇，基于 CocoaPods 1.16.2 源码。我们从 bin/pod 进场，走完 CLAide 的命令分发、Podfile 的 DSL 求值、Analyzer 的七步分析、Resolver + Molinillo 的回溯求解，最后交付 AggregateTarget/PodTarget 给下一篇讲的下载与集成。

上一篇：架构总览 · 下一篇：从下载到工程集成

运行示例贯穿全文：pod install --repo-update

一、`bin/pod`：16 行的入口

CocoaPods 的可执行文件非常薄，核心逻辑全在 require 'cocoapods' 之后的 Pod::Command.run：

# CocoaPods/bin/pod : 24
if $PROGRAM_NAME == __FILE__ && !ENV['COCOAPODS_NO_BUNDLER']
 ENV['BUNDLE_GEMFILE'] = File.expand_path('../../Gemfile', __FILE__)
 require 'rubygems'
 require 'bundler/setup'
 $LOAD_PATH.unshift File.expand_path('../../lib', __FILE__)
elsif ENV['COCOAPODS_NO_BUNDLER']
 require 'rubygems'
 gem 'cocoapods'
end

STDOUT.sync = true if ENV['CP_STDOUT_SYNC'] == 'TRUE'
require 'cocoapods'

if profile_filename = ENV['COCOAPODS_PROFILE']
 # 开 ruby-prof 做性能剖析
 # ...
 reporter.new(RubyProf.profile { Pod::Command.run(ARGV) }).print(io)
else
 Pod::Command.run(ARGV)
end

这里有两个工程化细节值得留意：

Objective-C 关联对象 Associated Objects 作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime Associated Objects objc-references.mm

关联对象 Associated Objects 作用与实现原理

关联对象让调用方在不改类布局、不新增 ivar 的情况下，把一组 key - value 挂到任意 Objective-C 对象上。 objc4 的实现不是把字段塞进对象内存，而是用一张运行时全局表保存“对象地址、key、关联值和内存管理策略”的映射。

入口 APIobjc_setAssociatedObject
objc_getAssociatedObject

核心存储AssociationsHashMap
ObjectAssociationMap

值封装ObjcAssociation
policy + value

清理时机objc_destructInstance
objc_disposeClassPair

作用与使用边界

关联对象主要服务于分类、框架扩展、运行时补充状态等场景：调用方只有对象指针和一个稳定 key，就能为对象保存额外值。这避免了修改类的 ivar 布局，也让分类可以模拟“存储属性”。

适合做什么

给现有类或分类补充少量状态。
把辅助对象、回调 block、缓存值挂到宿主对象。
用唯一地址作为 key，避免和其他调用方冲突。

不适合做什么

高频读写的核心数据结构。
需要类型系统和对象布局明确表达的状态。
清空他人关联值，尤其是随意调用 objc_removeAssociatedObjects。

运行时代价

每次访问都需要全局关联表查询。
set / get / remove 通过 AssociationsManagerLock 串行保护表。
对象析构时可能需要额外释放所有关联值。

**关键结论：**关联对象是“外置 side table”，不是对象内的 ivar。对象只保存一个“可能有 associated objects”的快速标记，真正的 key/value 在全局表里。

CocoaPods 源码导读：架构总览

Sat, 02 May 2026 22:32:27 +0800

本系列基于 CocoaPods 1.16.2（2026 年 4 月）源码进行分析。源码仓库由 15 个 Ruby Gem 组成，本文先从整体架构与职责拆分讲起，再以 pod install --repo-update 为主线绘制全景执行图，串起后续两篇专题的切入点。

系列目录：

架构总览（本文）

从命令到依赖求解

从下载到工程集成

一、CocoaPods 不是单一仓库

很多人以为 CocoaPods 就是一个 Ruby 项目，其实官方仓库 CocoaPods/CocoaPods 只是入口，真正的能力被拆成 15 个独立 gem，每个 gem 只做一件事。用 gem dependency cocoapods 会看到这样的依赖拓扑：

graph TB
subgraph "入口"
A["bin/pod
(CocoaPods gem)"]
end
subgraph "命令行框架"
B["CLAide
Command/Arg/Option DSL"]
end
subgraph "领域模型"
C["Core
Podfile/Podspec/Source/Lockfile"]
end
subgraph "依赖求解"
D["Molinillo
回溯式 SAT 求解器"]
end
subgraph "下载"
E["cocoapods-downloader
Git/HTTP/SVN/Hg/SCP"]
end
subgraph "Xcode 工程读写"
F["Xcodeproj
pbxproj/xcconfig/workspace"]
G["Nanaimo
ASCII plist 解析"]
end
subgraph "插件与子命令"
H["cocoapods-plugins"]
I["cocoapods-trunk
cocoapods-search
cocoapods-try
cocoapods-deintegrate"]
end
subgraph "辅助"
J["cork
彩色输出"]
K["nap
轻量 HTTP 客户端"]
end
A --> B
A --> C
A --> D
A --> E
A --> F
F --> G
A -.加载.-> H
H -.调用.-> I
A --> J
I --> K

各 gem 的一句话职责：

Objective-C KVC 作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

Key-Value Coding / Foundation behavior with objc4 runtime support

Objective-C KVC：从字符串 key 到对象读写

KVC 的核心价值是：把“访问某个属性或实例变量”抽象成 valueForKey:、setValue:forKey: 这样的字符串协议。读完这一页，你应该能说清楚它解决什么问题、Foundation 大致怎样查找成员，以及 objc4 runtime 在消息发送、元数据查询、ivar 直写和内存管理上提供了哪些支撑。

适合第一次系统理解 KVC 标注 objc4 / Foundation 边界含关键流程和注释代码

1. KVC 到底有什么用

平时你写 person.name 或 [person name]，访问目标在编译期就固定了。 KVC 允许你在运行时才决定要访问哪个成员：[person valueForKey:@"name"]。这使得对象、字典、表单、序列化、绑定和调试工具可以用同一套字符串 key 访问模型对象。

动态访问

运行时才知道字段名时，用字符串 key 读取或写入对象。

统一映射

JSON、表单、数据库行、UI 绑定都可以映射到对象属性。

批量和路径

valueForKeyPath: 能沿着 department.manager.name 连续取值。

Objective-C KVO 作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime reading note

KVO：从“属性变化通知”到 runtime 动态子类

KVO（Key-Value Observing）让一个对象在另一个对象的某个 key path 变化时收到回调。在这个 objc4 仓库里，Foundation 的 KVO 主体代码不在源码中；但 runtime 暴露了 KVO 需要的关键能力：复制类、切换对象的 isa、判断 ivar 内存语义，并保证这些操作在初始化、弱引用和并发加载场景下安全。

入口：addObserver 核心：动态子类通知：will/didChange 底层：objc_duplicateClass

阅读路线

KVO 解决什么问题
实现原理总览
objc4 中的关键支撑
核心类和关键方法
关键流程
带注释代码片段
使用边界和排错

1. KVO 的作用：把“状态变化”变成可订阅事件

普通属性赋值只改变对象内部状态，调用者不知道“谁关心这个变化”。KVO 把某个 key path 的变化包装成标准事件：被观察对象负责发出变化，观察者在 observeValueForKeyPath:ofObject:change:context: 中接收。

解耦

观察者不需要改写被观察对象的业务代码，只注册感兴趣的 key path。

统一格式

变化以 change 字典传递，可包含旧值、新值、变化类型等。

自动拦截

对 KVC/KVO 兼容的 setter，Foundation 可自动在 setter 前后发通知。

手动通知

复杂派生属性或批量变化可用 willChangeValueForKey: 和 didChangeValueForKey: 明确包围。

runtime/hashtable2.mm 作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime NXHashTable 集合结构

runtime/hashtable2.mm 作用与实现原理

这个文件实现了旧 NeXT/Objective-C runtime 暴露的 NXHashTable：一个可存放任意指针或整数数据的哈希集合。它不保存 key-value 对；需要映射关系时，runtime 另用 maptable.mm 的 NXMapTable。

一遍读懂

它用 callback 决定“怎么 hash、怎么判等、怎么释放”。
每个 bucket 是一条很短的冲突链。
bucket 中只有 1 个元素时直接存指针，避免额外分配。
元素数超过 bucket 数时扩容并重算位置。
删除会把 2 个元素的 bucket 收缩回单指针形态。

1. 它解决什么问题

NXHashTable 是 runtime 内部和兼容 API 使用的通用集合容器。调用者传入一组 NXHashTablePrototype，告诉表如何处理元素：hash(info, data) 计算哈希，isEqual(info, a, b) 判断相等，free(info, data) 在销毁或 reset 时释放元素。这样同一套表结构可以存指针、字符串，或“结构体首字段作为 key”的对象。

**关键不变量：**如果两个元素被 isEqual 判为相等，它们的 hash 必须一致；而且参与 hash 的内容不能在入表后变化。否则扩容重排后会找不到元素。

2. 数据结构：一层数组 + 小冲突链

NXHashTable保存 prototype、元素总数、bucket 数组和可透传给 callback 的 info。

runtime/maptable.h 作用与实现原理

Mon, 01 Jun 2026 19:50:12 +0800

objc4 runtime NXMapTable 开放寻址哈希表 runtime/maptable.h

runtime/maptable.h 作用与实现原理

runtime/maptable.h 定义了 Objective-C runtime 里旧 NeXT 风格的 NXMapTable：一个通用的 key - value 指针映射表。它不拥有业务对象，只负责把指针或整数形式的 key 映射到指针或整数形式的 value，并通过回调把“怎么 hash、怎么比较、释放时怎么处理”交给调用方决定。

存储模型连续桶数组，每个桶是 {key, value}。

冲突处理开放寻址 + 线性探测。

扩容阈值元素数超过桶数的 75% 后翻倍重哈希。

runtime 用途类名表、协议表、future class 表、少量 meta 到 non-meta 映射。

阅读路径

它解决什么问题
和 hashtable2 的区别
核心数据结构
Prototype 回调机制
查找、插入、删除、扩容流程
带注释核心代码
runtime 中的实际使用
必须记住的约束

1. 它解决什么问题

runtime 需要维护很多“名字到结构体指针”“元类到类”“未来会出现的类名到占位 Class”的映射。这些映射发生在启动、加载镜像、注册类、查找协议等低层路径上，不能依赖 Objective-C 容器对象。 NXMapTable 就是一个 C 接口的轻量哈希表。

它是什么

一个 void * key 到 void * value 的映射表。key 和 value 可以是指针，也可以把整数强转成指针使用。

Cocos 引擎 iOS 渲染管线深度解析：从 CADisplayLink 到屏幕呈现

Wed, 08 Jul 2026 19:00:15 +0800

Cocos 引擎 iOS 渲染管线深度解析：从 CADisplayLink 到屏幕呈现

引言

在移动端图形开发中，理解渲染管线的底层实现是走向高级工程师的必经之路。Cocos Creator 作为主流的跨平台游戏引擎，其 iOS Metal 后端的渲染实现采用了现代化的 FrameGraph 架构，结合脏状态追踪、资源池化等优化手段，是一份极佳的学习样本。

本文基于对 Cocos 引擎 gfx-metal 模块的源码分析，梳理从 CADisplayLink 帧回调触发到最终 GPU 呈现的完整渲染链路，并深入解读各阶段的关键实现细节。

整体架构概览

在深入时序之前,先理清核心模块的职责分工：

模块	文件	职责
IOSPlatform	`IOSPlatform.mm`	iOS 平台入口，持有 `CADisplayLink` 驱动渲染循环
RenderPipeline	`RenderPipeline.cpp`	管线编排器，遍历相机并调度 Flow/Stage
ForwardFlow	`ForwardFlow.cpp`	前向渲染流程，决定渲染策略
ForwardStage	`ForwardStage.cpp`	前向渲染阶段，收集渲染对象并填充 UBO
RenderQueue	`RenderQueue.cpp`	渲染队列，对可渲染对象排序
FrameGraph	`FrameGraph.cpp`	帧图调度器，负责 Pass 编译、排序、合并和执行
CCMTLDevice	`MTLDevice.mm`	Metal 设备抽象，管理 Swapchain 和 Queue
CCMTLSwapchain	`MTLSwapchain.mm`	交换链，管理 `CAMetalLayer` 和 drawable
CCMTLCommandBuffer	`MTLCommandBuffer.mm`	命令缓冲区封装，核心渲染编码入口
CCMTLRenderCommandEncoder	`MTLRenderCommandEncoder.h`	渲染编码器，含脏状态追踪优化

完整渲染时序图

以下 Mermaid 时序图展示了从屏幕刷新信号到最终呈现的五个阶段：

源码分析 on Last Stand

Swift 面试：ARC 与内存管理源码解析

Swift 面试：ARC 与内存管理源码解析

面试高频问题

30 秒回答版

objc4 类加载、read_images 与类实现化

objc4 类加载、read_images 与类实现化

一、这条链路的作用

把 Mach-O 中的静态元数据变成运行时可用的类

延迟成本，同时保证消息发送能看到正确结构

二、核心类/结构和关键字段

类数据从 ro 切换到 rw

AFNetworking 源码导读

一、整体架构

Swift 面试：泛型、协议与派发源码解析

Swift 面试：泛型、协议与派发源码解析

面试高频问题

30 秒回答版

Objective-C 消息发送 objc_msgSend 与慢速查找入口

Objective-C 消息发送：objc_msgSend 与慢速查找入口

目录

作用

动态派发

缓存加速

语义兼容

扩展入口

Alamofire源码导读

一、整体架构

Swift 面试：值语义、COW 与集合源码解析

Swift 面试：值语义、COW 与集合源码解析

面试高频问题

30 秒回答版

objc4 方法缓存 cache_t / bucket_t 技术讲解

objc4 方法缓存 cache_t / bucket_t 技术讲解

一、方法缓存的作用

二、核心结构

bucket_t：一个 selector 到 IMP 的槽位

cache_t：每个类上的哈希表

preopt_cache_t：dyld shared cache 预构建的常量 cache

三、实现原理

IGListKit源码导读

一、整体架构

Swift 面试：并发、async/await 与 Actor 源码解析

Swift 面试：并发、async/await 与 Actor 源码解析

面试高频问题

30 秒回答版

Objective-C Category 装载与附加机制

Category 装载与方法、协议、属性附加

目录

作用

扩展类行为

扩展反射信息

保持加载顺序

支持动态镜像

实现原理总览

Mach-O 镜像

分类分流

列表前插

Kingfisher源码导读

一、整体架构

二、命名空间设计 — KingfisherWrapper

Swift 面试：编译流程、Runtime 与元数据源码解析

Swift 面试：编译流程、Runtime 与元数据源码解析

面试高频问题

30 秒回答版

Objective-C +load 调度：load_images 与 call_load_methods

+load 调度：从 load_images 到 call_load_methods

目录

作用

实现原理

RxSwift源码导读

一、整体架构

+initialize 懒初始化与并发状态机

+initialize 懒初始化与并发状态机

目录

作用

实现原理

核心类/结构状态字段

SDWebImage源码导读

一、整体架构

`bucket_t`：一个 selector 到 IMP 的槽位

`cache_t`：每个类上的哈希表

`preopt_cache_t`：dyld shared cache 预构建的常量 cache

源码目录（`Sources/`，约 3500 行）

二、DSL 入口：`view.snp`

`Protocol` 类

一、`bin/pod`：16 行的入口