源码分析

本文基于 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["AFURLSessionManagerNSURLSession 代理总线"] B["AFHTTPSessionManagerHTTP 便利方法 GET/POST/..."] C["AFURLSessionManagerTaskDelegate每个 Task 的代理持有者"] end subgraph "序列化层 (Serialization)" D["AFHTTPRequestSerializerURL 编码 / 头部 / User-Agent"] E["AFJSONRequestSerializerAFPropertyListRequestSerializer"] F["AFStreamingMultipartFormDataAFMultipartBodyStream (流式上传)"] G["AFHTTPResponseSerializer+ JSON/XML/Image/PropertyList"] end subgraph "安全层 (Security)" H["AFSecurityPolicySSL Pinning (None/Certificate/PublicKey)"] end subgraph "可达性层 (Reachability)" I["AFNetworkReachabilityManager基于 SCNetworkReachability"] end subgraph "UI 扩展 (UIKit+AFNetworking)" J["UIImageView+AFNetworkingUIButton+AFNetworkingUIActivityIndicatorView+AFNetworking ..."] end B --> A A --> C A --> D A --> G A --> H A --> I D --> E D --> F J --> B 源码目录一览（AFNetworking 4.0.1）： ...

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["SessionDelegateURLSession 桥接"] 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 代码）： ...

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["IGListDiffPaul 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 源码目录结构： ...

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 社区广泛使用的一种模式。 ...

RxSwift 是 ReactiveX 在 Swift 上的实现，提供了一套完整的响应式编程框架。它通过 Observable 序列和操作符组合的方式，简化了异步编程、事件处理和数据流管理。本文基于 v6.10.2（2026年3月发布）源码进行分析。 一、整体架构 RxSwift 项目采用模块化设计，包含五个独立模块： graph TB subgraph "核心层" A["RxSwift核心响应式框架"] end subgraph "扩展层" B["RxCocoaUIKit/AppKit绑定"] C["RxRelayRelay封装"] 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 代码。 ...

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+WebCacheUIButton+WebCacheUIView+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["SDImageHEICCoderWebP/AVIF (插件)"] end subgraph "辅助层" F["SDImageTransformerSDWebImageCacheKeyFilterSDWebImageOptionsProcessorSDCallbackQueue"] end A -->|sd_setImageWithURL| B B --> C1 B --> C2 B --> D1 D1 --> D2 D2 --> E1 B --> F 源码目录结构： ...

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["makeConstraintsremakeConstraintsupdateConstraints"] 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/OffsetInset/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。 ...

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 源码文件结构： ...

TODO: 待补充

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 符号。 ...