原文链接：Is Type Aliases really necessary?

在日常 Swift 开发里，typealias 是一个高频出现的小工具：

它能让冗长的类型签名变短、让业务语义更突出，还会带来“零运行时开销”的错觉。

然而，当我们把它放到更大的团队协作、更长的生命周期里，抽象成本就悄悄出现了。

typealias 的编译期真相：一次名字替换

什么是 SIL？

SIL 是 Swift 编译器在生成机器码之前使用的中间语言，

我们观察 SIL 就能知道“某个语法糖到底有没有产生额外结构”。

验证 typealias 在 SIL 中的形态

先写一段最常规的代码：

typealias MyInt = Int

func add(_ a: MyInt, _ b: MyInt) -> MyInt {
    return a + b
}

用命令行导出 SIL：

swiftc -emit-sil main.swift

截取到的关键片段：

// add(_:_:)
sil @$s4main3addyS2iF : $@convention(thin) (Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
  %2 = builtin "add_Int32"(%0 : $Int, %1 : $Int) : $Int
  return %2 : $Int
}

可以看到：MyInt 完全消失了，只剩 Int。

结论：

typealias 不生成新的类型结构，也不产生运行时开销——它只是编译期的名字替换。

抽象成本：并不在 CPU，而在人脑

虽然机器眼里没有差异，但人眼和团队协同却会感受到 4 类成本：

过度使用导致“语义稀释”

typealias UserID   = String
typealias ProductID = String

func process(_ user: UserID, _ product: ProductID) { ... }

一眼望去，两个参数都是 String，但编译器不会阻止你把 user 和 product 传反，因为 UserID 与 ProductID 在类型系统里完全等价。

误导性语义

typealias Coordinates = (x: Int, y: Int)
let position: Coordinates = (10, 20)

看上去像“专用类型”，实则只是元组别名；如果后续需要扩展方法或协议，就会意识到它并不能像真正的 struct Coordinates 那样演进。

团队认知负担

typealias DataSource = [String: Any]

新人必须跳转到定义才能确认它到底是字典、数组还是自定义类型；在大型工程中，这种“跳转成本”积少成多。

缺乏强类型安全

typealias USD = Double
typealias EUR = Double

func convert(_ amount: USD) -> EUR {
    return amount * 0.85   // 编译器放行
}

let euros: EUR = convert(50)   // 不小心把 Double 直接塞进来也合法

如果想让 “不同货币不能混用” 在编译期就报错，需要真正的包装类型：

struct USD { let value: Double }
struct EUR { let value: Double }

func convert(_ amount: USD) -> EUR {
    return EUR(value: amount.value * 0.85)
}

此时混用会在编译阶段直接失败，安全等级提升。

正确使用姿势：收益最大化的 4 个场景

场景	示例	收益
① 提升可读性	typealias CompletionHandler = (Result<Data, Error>) -> Void	把复杂闭包浓缩成一句话，降低理解成本
② 简化重复签名	typealias DictionaryOfStringArrays = [String: [String]]	减少重复定义的样板代码，统一类型表达
③ 统一回调命名	typealias URLCallback = (URL) -> Void	多处声明回调时保持命名一致性，提升代码可维护性
④ 业务语义命名	typealias Age = Int、typealias Distance = Double	让“裸类型”（如 Int、Double）具备业务领域含义，增强代码自解释性

一句话原则：

当别名让代码更清晰、且不伪装成新类型时，用它；否则，用真正的类型。

小结 checklist

1. ✅ 编译期零开销——放心用。
2. ⚠️ 运行时没成本，但人脑有。
3. ⚠️ 需要区分语义 + 强类型时，用 struct / class 而不是 typealias。
4. ✅ 用来简化复杂签名、统一回调、业务命名，收益最大。

把 typealias 当成“命名工具”而非“类型设计工具”，就能同时享受到简洁代码与长期可维护性的双重红利。

Swift 6 不是一次“小步快跑”，而是 Apple 在并发安全、泛型系统、跨平台一致性与嵌入式场景四大方向的“集中爆发”。

版本回溯：从 Swift 5.1 → 6.0 的关键里程

Swift 版本	发布时间	关键特性	对 Swift 6.0 的影响
5.1	2019.09	Opaque Return Type（不透明返回类型）、Module Stability（模块稳定性）	为 SwiftUI 的声明式 DSL（领域特定语言）提供基础支持
5.5	2021.09	Async/Await（异步/等待）、Actors（Actor模型）、Sendable（可发送类型）	并发模型的雏形，为 6.0 全并发检查机制奠定基础
5.9	2023.09	Macro（宏）、Parameter Pack（参数包）	元编程能力大幅提升，间接推动 6.0 编译期检查优化
5.10	2024.03	Strict Concurrency for Globals（全局变量的严格并发检查）	为 6.0 默认启用全并发检查（如全局变量的线程安全验证）铺路

语言核心新特性

count(where:) — 内存友好的过滤计数

let logs = ["info", "warning", "error:404", "error:500"]
let errorCount = logs.count { $0.hasPrefix("error") }
// 无需创建临时 Array，O(n) 一次遍历

适用所有 Sequence，包括 Dictionary、Set。

Typed Throws — 精确错误契约

enum NetworkError: Error { case timeout, notFound }

func fetch(_ url: String) throws(NetworkError) -> Data {
    if url.isEmpty { throw .notFound }
    return Data()
}

do {
    let data = try fetch("")
} catch NetworkError.notFound {
    print("404")
}

注意：

• 只能声明一个具体类型；throws(any Error) 保持旧语义。
• 库作者需谨慎：新增 case 属于 binary-breaking。

Parameter Pack Iteration — 任意长度元组比较

Swift 5.9 引入了值/类型参数包，但无法遍历。Swift 6 补齐：

func == <each T: Equatable>(lhs: (repeat each T),
                            rhs: (repeat each T)) -> Bool {
    for (l, r) in repeat (each lhs, each rhs) {
        if l != r { return false }
    }
    return true
}

从此告别手写 2-6 个元素的 == 重载。

128-bit 整数

let huge: Int128 = 170_141_183_460_469_231_731_687_303_715_884_105_727
let bigger = huge &+ 1   // 不会溢出

标准库完全集成：*, /, Codable, Comparable 全部支持。

细粒度 import 访问控制

// 仅在当前文件可见
private import CompressionKit

// 防止把内部依赖泄漏到公共 API
internal import ImageProcessingKit

默认从 public 改为 internal，更好地封装层次化架构。

RangeSet — 不连续区间运算

let books = [Book(title: "A", rating: 90),
             Book(title: "B", rating: 70),
             Book(title: "C", rating: 95)]
let highRated = books.indices { $0.rating > 85 }
for b in books[highRated] { print(b.title) }   // A, C

RangeSet 支持 union, intersection, isSuperset(of:) 等集合运算。

非可复制类型三连击

SE 编号	能力	示例
0427	泛型 & 协议支持	struct Box<T: ~Copyable>
0429	部分消费	consuming func open() { notification.display()}只消费 notification
0432	switch 支持	switch consume item { ... }

struct Token: ~Copyable {
    let id: UUID
    consuming func invalidate() { /* 只可使用一次 */ }
}

防止“忘记释放文件句柄/密钥”一类资源泄露。

BitwiseCopyable — memcpy 级别的优化

编译器自动为平凡类型（无引用计数、无自定义 copy）合成：

@frozen
public enum LogLevel: ~BitwiseCopyable { case debug, error }

禁止推断时使用 ~BitwiseCopyable，避免 ABI 锁定。

C++ 互操作再升级

• Move-only 类型映射

  struct SWIFT_NONCOPYABLE Buffer { void* ptr; };

Swift 侧视为 ~Copyable。

• 虚函数动态派发

  class SWIFT_SHARED_REFERENCE Renderer {
  public:
      virtual void draw();
  };

Swift 可直接 renderer.draw()，支持多态。

• STL 容器

  std::optional<Int>, std::map<String, Int> 已开箱即用。

Embedded Swift — 零运行时 MCU 开发

swiftc -target armv7em-none-none-eabi \
       -O -embedded \
       -o firmware.elf main.swift

限制：

• 无 ARC、无动态派发、无标准库反射。
• 使用 Swift.Shims 中的裸指针与寄存器 API。

适合 Cortex-M, RISC-V 32/64。

调试与诊断

@DebugDescription

@DebugDescription
struct User: CustomDebugStringConvertible {
    let id: Int
    var debugDescription: String { "User #\(id)" }
}

LLDB 中 p user 直接打印 User #42。

显式模块加速 LLDB
开启 -explicit-module-build 后，调试器不再即时编译 Clang 模块，首条 po 提速 5-10 倍。

Foundation 统一 & Swift Testing

Foundation 跨平台

• macOS / iOS / Linux / Windows 同一套 Swift 实现。
• 新增 JSON5、Predicate、RecurrenceRule。
• FoundationEssentials 精简包去掉 i18n，裁剪 30% 体积。

Swift Testing 示例

import Testing

@Test("emoji count", arguments: ["🐶", "🐶🐱"])
func countEmojis(_ s: String) {
    #expect(s.count == s.unicodeScalars.count)
}

• 宏驱动，无需 XCTest。
• SPM 自动并行执行 XCTest + Swift Testing。

并发默认全面检查

• Region-Based Isolation（SE-0414）：编译器能证明“值不会逃逸当前任务”，无需手动 Sendable。
• 关键字 sending（SE-0430）：跨隔离域转移所有权。
• Global 变量限制：必须是 let、被 actor 隔离，或 nonisolated(unsafe)。
• 默认继承调用者隔离：减少 @MainActor 冗余。

小结 & 迁移建议

维度	建议
语言层面	优先启用 -swift-version 6，利用 typed throws、count(where:)精简代码。
并发	立即修复 Global is not concurrency-safe警告；将可变全局状态封装到 actor。
库作者	评估 public API 是否暴露 internal import依赖；谨慎使用 typed throws。
嵌入式	使用 -embedded构建 Demo，观察二进制大小；注意移除 Swift runtime 符号。
测试	新项目直接采用 Swift Testing；旧项目可并行运行 XCTest 逐步迁移。

原文：Swift Basics: The Real Difference Between let and var Explained with Examples

很多初学 Swift 的同学会把 let 和 var 的区别简单记忆成“常量 vs 变量”。

但在实际工程中，这条规则只是起点。选择 let 还是 var 会直接影响代码的安全性、可读性，甚至运行时性能。

基础语义：可变与不可变

• var：可变变量。值在生命周期内可以被重新赋值或修改。
• let：不可变绑定。一旦赋值，就不能再指向别的值。

// var 可以改
var score = 10
score += 5          // ✅ 11

// let 不能改
let pi = 3.14
pi = 3.1415         // ❌ Cannot assign to value: 'pi' is a 'let' constant

何时用 let，何时用 var？

官方社区的最佳实践：“先写 let，必要时再改成 var。”

这条规则背后的逻辑是：

1. 不可变数据天然线程安全，减少副作用；
2. 编译器可以做更多优化（如栈上分配、内联）；
3. 阅读代码的人无需担心值被中途篡改。

场景	推荐关键字
用户 ID、出生日期、API 返回的只读模型	let
计分器、计时器、用户输入框内容	var
SwiftUI 的 @State包装属性	var（因为框架会重新赋值）

示例：

let identityNumber = "12345678900"   // 一辈子不会变
var currentCity      = "Erzurum"     // 用户可能搬家

let 真的“绝对不变”吗？

答案是：取决于类型是值类型（Value Type）还是引用类型（Reference Type）。

引用类型（class）

class Person {
    var name: String
    init(name: String) { self.name = name }
}

let person = Person(name: "Turabi")
person.name = "Muhammed"   // ✅ 合法！

• person 这个“变量名”不能指向别的对象；
• 但对象内部的属性仍可以变动。

值类型（struct / enum）

struct Book {
    let title: String
}

let book = Book(title: "1984")
book.title = "The Art of War"   // ❌ Cannot assign to property: 'book' is a 'let' constant

• 值类型实例被 let 修饰后，整个实例及其所有属性都不可变；
• 如果想改属性，需要把实例声明为 var，或者把属性声明为 var。

小结与实战 Checklist

1. 默认用 let，除非编译器报错提示你需要可变性。
2. API 模型全部用 let，除非后端明确会推送增量更新。
3. UI 状态（如 @State 属性）用 var。
4. 多线程或并发场景，优先把数据设计成不可变，减少锁竞争。
5. 如果想让对象内部也不可变，考虑：
   • 把 class 改成 struct；
   • 或者把内部属性全部设为 let。

附：完整示例

// 1. 值类型：struct
struct Point {
    let x: Int
    let y: Int
}

let p = Point(x: 0, y: 0)
// p.x = 10   // ❌

// 2. 引用类型：class
class Counter {
    var value: Int = 0
}

let counter = Counter()
counter.value += 1   // ✅
// counter = Counter()   // ❌

选择 let 或 var 不仅是语法风格问题，更是设计决策。

当你写下 let 的那一刻，就向未来的维护者传递了“这里不会被意外修改”的承诺。

原文：QMastering Swift 6.2 Concurrency – A Complete Tutorial

背景：为什么需要 Swift Concurrency？

在 SwiftUI 出现之前，我们用 GCD（Grand Central Dispatch）做线程切换；

Swift 5.5 引入的 Actor、async/await 和 Task 把并发提升到了语言层面；

Swift 6.0 又带来了 Strict Concurrency 和数据竞争检查。

2025 年的 Swift 6.2（WWDC25） 再次出手，用两个开关把并发门槛降到“新手友好”级别：

新特性	作用
Default Actor Isolation = MainActor	所有自定义类型默认运行在主线程（MainActor），天生具备线程安全性
nonisolated nonsending by default = ON	nonisolated方法自动继承调用者的执行线程，无需手动标记线程上下文（如 @MainActor或 @AnyActor）

一句话总结：“先跑主线程，再按需后台，用 @concurrent 标记真正耗时的任务。”

回顾：async/await 与 Actor 基础

async / await 最小示例

class Model {
    func fetch() async throws -> Data {
        let (data, _) = try await URLSession.shared.data(from: url)
        return data
    }
}

• async 表示方法会 挂起（suspend）。
• await 是 挂起点，把线程让出来，等待结果返回后继续执行。

在 Swift 6.2 之前，没有隔离的 async 方法会随机跑在后台线程；从 6.2 开始，默认跑主线程，只有真正 I/O 的苹果 API（如 URLSession）才会切后台。

显式隔离：@MainActor & actor

@MainActor           // 整类跑主线程
@Observable
class WeatherVM {
    var forecast: Forecast?
    
    func reload() async throws {
        forecast = try await service.load()
    }
    
    nonisolated func heavy() async { ... } // 显式脱离主线程
}

actor ImageCache {   // 自定义隔离域，跑后台
    private var store: [URL: Image] = [:]
    
    func image(for url: URL) -> Image? { store[url] }
}

• @MainActor 等价于“UI 专属线程”。
• actor 自带互斥锁，适合可变共享状态（如缓存）。
• nonisolated 让某个方法脱离当前 Actor，继承调用者线程。

Swift 6.2 的两把“默认开关”

构建设置	Xcode 26 默认值	Apple 推荐值
Default Actor Isolation	MainActor	MainActor
nonisolated nonsending by default	OFF	ON

开启后：

1. 所有新建类型 自动 @MainActor，无需手写。
2. nonisolated 方法 默认 (nonsending)，即 继承调用者线程。
3. 只有用 @concurrent 宏标记的方法，才 强制跑后台。

// 默认 MainActor
class Model {
    func businessLogic() async { ... }          // 主线程
    
    nonisolated
    func helper() async { ... }                 // 继承调用者线程
    
    @concurrent
    func cpuIntensive() async { ... }           // 必跑后台
}

实战：线程流向分析题

题目：下面的 ConcurrentThread 各方法分别跑在哪条线程？

struct MainMaster: View {
    var body: some View {
        VStack { Text("Main Master") }
            .task {
                Task.detached {
                    let model = ConcurrentThread()
                    await model.firstMethod()
                }
            }
    }
}

class ConcurrentThread {
    func firstMethod() async {           // ①
        await secondMethod()
        await thirdMethod()
    }
    
    @concurrent
    func secondMethod() async {          // ②
        try? await Task.sleep(for: .seconds(1))
        await thirdMethod()
    }
    
    nonisolated
    func thirdMethod() async { ... }     // ③
}

4.1 执行顺序与线程

步骤	方法	线程	原因
①	firstMethod()	Main	类默认 @MainActor；Task.detached不影响隔离上下文
②	secondMethod()	后台	标记 @concurrent，强制方法在后台 Actor 运行
③-1	thirdMethod()	后台	由 ② 调用，且方法标记为 nonisolated(nonsending)，继承调用者（后台）的线程上下文
③-2	thirdMethod()	Main	由 ① 调用，继承调用者（MainActor）的线程上下文，因此运行在主线程

结论：await 只负责挂起和恢复；@concurrent 和 nonisolated 才是决定线程的关键。

Closure Capture：@Sendable vs sending

Swift 6 用 sending 取代 @Sendable，但概念不变：闭包跨线程时必须保证捕获的值是 线程安全 的。

经典错误

class MapManager { var response: MKLocalSearch.Response? }

class MapModel {
    let manager = MapManager()          // 非 Sendable
    
    func getResponse() {
        Task {                          // 隐式 @Sendable
            manager.response = ...      // ❌ 捕获 self，产生数据竞争
        }
    }
}

正确姿势

• 使用局部变量
• 或使用 @unchecked Sendable（仅当你真的知道安全）
• 或把类型标记 @MainActor，此时编译器自动视为 Sendable

常见坑：@Sendable 同步闭包

SwiftUI 部分 API（如 PhotosPicker）的 label 仍是 同步 @Sendable 闭包，内部不能调用 @MainActor 方法。

PhotosPicker(selection: $model.pickerItem) {
    if let image = model.imageDataToUI(cocktail) { // ❌
        Image(uiImage: image)
    }
}

解决

把值提前算好，再塞进闭包：

var body: some View {
    let image = model.imageDataToUI(cocktail)
    PhotosPicker(selection: $model.pickerItem) {
        if let image { Image(uiImage: image) }
    }
}

---

性能优化：只在需要时用 @concurrent

在 Structured Concurrency 里，子任务默认就在后台，不需要 @concurrent：

await withTaskGroup(of: Void.self) { group in
    for album in albums {
        group.addTask {          // 已自动后台
            await self.process(album)
        }
    }
}

但如果 process(album) 内部还有 大量 CPU 计算，再在 process 上加 @concurrent：

@concurrent
func process(_ album: Album) async { ... }

Instruments 前后对比：主线程瞬间从 100 % 降到 10 %。

总结：Apple 推荐的并发范式

阶段	做法	备注
默认	开启 Default Actor Isolation = MainActor	90% 代码直接跑主线程
需要后台	在方法上加 @concurrent	明确告诉编译器“这里耗时”
共享可变状态	用 actor	自动加锁保证状态安全
跨线程闭包	用局部变量或 Sendable	避免闭包捕获 self导致线程安全问题

一句话：“先跑主线程，再按需后台，用 @concurrent 标记真正耗时的任务。”

作为SwiftUI框架的核心概念之一，视图修改器（ViewModifier）为我们提供了一种优雅的方式来封装和重用视图的样式和行为。

这是视图修改器的源码

@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
extension View {

    /// Applies a modifier to a view and returns a new view.
    ///
    /// Use this modifier to combine a ``View`` and a ``ViewModifier``, to
    /// create a new view. For example, if you create a view modifier for
    /// a new kind of caption with blue text surrounded by a rounded rectangle:
    ///
    ///     struct BorderedCaption: ViewModifier {
    ///         func body(content: Content) -> some View {
    ///             content
    ///                 .font(.caption2)
    ///                 .padding(10)
    ///                 .overlay(
    ///                     RoundedRectangle(cornerRadius: 15)
    ///                         .stroke(lineWidth: 1)
    ///                 )
    ///                 .foregroundColor(Color.blue)
    ///         }
    ///     }
    ///
    /// You can use ``modifier(_:)`` to extend ``View`` to create new modifier
    /// for applying the `BorderedCaption` defined above:
    ///
    ///     extension View {
    ///         func borderedCaption() -> some View {
    ///             modifier(BorderedCaption())
    ///         }
    ///     }
    ///
    /// Then you can apply the bordered caption to any view:
    ///
    ///     Image(systemName: "bus")
    ///         .resizable()
    ///         .frame(width:50, height:50)
    ///     Text("Downtown Bus")
    ///         .borderedCaption()
    ///
    /// ![A screenshot showing the image of a bus with a caption reading
    /// Downtown Bus. A view extension, using custom a modifier, renders the
    ///  caption in blue text surrounded by a rounded
    ///  rectangle.](SwiftUI-View-ViewModifier.png)
    ///
    /// - Parameter modifier: The modifier to apply to this view.
    @inlinable nonisolated public func modifier<T>(_ modifier: T) -> ModifiedContent<Self, T>
}

首先要明确ViewModifier协议

@MainActor @preconcurrency
public protocol ViewModifier {
    associatedtype Body : View

    @ViewBuilder
    func body(content: Self.Content) -> Self.Body

    typealias Content
}

可以看出，必须有一个要修改的视图和修改的方法。

下面是一个推荐的示例

1 视图样式定义

struct BorderedCaption: ViewModifier {
    func body(content: Content) -> some View {
        content
            .font(.caption2)
            .padding(10)
            .overlay(
                RoundedRectangle(cornerRadius: 15)
                    .stroke(lineWidth: 1)
            )
            .foregroundColor(Color.blue)
    }
}

2 添加到视图view中，作为view的扩展

这样应用中的所有视图都可以像普通样式一样添加

extension View {
    func borderedCaption() -> some View {
        modifier(BorderedCaption())
    }
}

3 应用修改器

Image(systemName: "bus")
    .resizable()
    .frame(width:50, height:50)
Text("Downtown Bus")
    .borderedCaption()

如果你需要传递参数：

struct CustomPadding: ViewModifier {
    let amount: CGFloat
    
    func body(content: Content) -> some View {
        content.padding(amount)
    }
}

extension View {
    func customPadding(_ amount: CGFloat) -> some View {
        modifier(CustomPadding(amount: amount))
    }
}

其实SwiftUI 中每个 .padding(), .background(), .foregroundColor() 其实都是 视图修饰器 (modifier)

官方地址：developer.apple.com/documentati…

背景

用cocoapods管理的iOS项目中需要限制 release 分支直接push

经过一番Google，找到了git hooks限制的方法，但是看了很多文章，发现废话一堆，不能快速的解决我的问题

在这里记录一下

第一步，进入你项目的.git/hooks路径下

可以看到很多sample后缀文件，根据文件名，你可以猜到是控制git操作哪一步的，例如我要控制push，那么我就是修改pre-push那个文件

第二步修改pre-push

• 用编辑器打开，编辑这个文件

• cursour给写的

#!/bin/sh

remote="$1"
url="$2"

# Block pushing directly to release branches (e.g., release or release/*)
block_pattern='^refs/heads/release($|/)'

while read local_ref local_sha remote_ref remote_sha
do
if echo "$remote_ref" | grep -Eq "$block_pattern"; then
echo >&2 "检测到目标分支为受保护分支：$remote_ref"
echo >&2 "禁止直接 push 到 release 分支。请通过 Pull Request 或受保护流程合并。"
exit 1
fi
done

exit 0

• 文件编辑好后，把 .sample去掉，就会变成一个shell程序

第三步同步hooks

因为hooks是放在.git下面的，但是.git不能上传到远端，想要同步给其他人，还需要做以下操作

• 复制编辑好的 hooks文件夹到项目的根目录，文件夹名称为 .hooks
• 在podfile中随便找个地方写上这样一段命令 system("git config core.hooksPath .hooks")，在执行pod更新的时候，就会自动配置git config
• 以上就完成了git hooks的同步

参考文章

• git hooks
• 其他同步hooks的方法

一、核心概念与差异对比

1. abstract（抽象类）

• 作用：定义接口规范或部分实现，不可直接实例化。

• 特点：

  • 可包含抽象方法（无实现）和具体方法（有实现）。
  • 子类需实现所有抽象方法。
  • 可以有构造函数

• 代码示例：

  abstract class Animal {
    void makeSound(); // 抽象方法
    void sleep() => print("Sleeping"); // 具体方法
  }
  class Dog extends Animal {
    @override
    void makeSound() => print("Woof!"); // 必须实现抽象方法
  }
  

2. mixin（混入类）

• 作用：横向复用代码，突破单继承限制。

• 特点：

  • 无构造函数，不可实例化。
  • 字段必须初始化（late或初始值）。
  • 通过 with混入，支持多混入。

• 代码示例：

  mixin Logger {
    void log(String msg) => print("Log: $msg");
  }
  class Service with Logger {
    void work() => log("Working...");
  }
  

在 Flutter（Dart）开发中，mixin和 abstract是两种不同的代码复用机制，结合 with、extends和 implements关键字，可灵活实现代码结构设计。以下是详细对比和使用场景分析：

---

一、mixin 与 abstract 的核心区别

特性	mixin	abstract（抽象类）
定义方式	使用 mixin关键字声明	使用 abstract class声明
实例化	❌ 不能直接实例化	❌ 不能直接实例化
继承限制	无父类限制（默认继承 Object）	可被继承（extends）或实现（implements）
构造方法	❌ 不能有构造函数	✅ 可包含构造函数
方法实现	可包含具体方法和抽象方法	可包含具体方法和抽象方法
复用灵活性	通过 with混入多个类	单继承（extends），支持多接口实现（implements）
核心目的	横向复用功能（如添加共享行为）	定义统一规范（如接口契约或基础逻辑）

3. extends（继承）

• 作用：子类继承父类的属性和方法。

• 规则：

  • 单继承：仅能继承一个父类。
  • 子类可重写父类方法（@override）。

• 代码示例：

  class Vehicle {
    void move() => print("Moving");
  }
  class Car extends Vehicle {
    @override
    void move() => print("Driving on road");
  }
  

4. implements（接口实现）

• 作用：强制实现接口的所有成员（无论抽象或具体）。

• 规则：

  • 需覆写接口中所有公开成员。
  • 可同时实现多个接口。

• 代码示例：

  abstract class Flyer { void fly(); }
  class Bird implements Flyer {
    @override
    void fly() => print("Flying");
  }
  

5. with（混入关键字）

• 作用：将 mixin 或 mixin class的功能注入类中。

• 优先级：后混入的覆盖先混入的同名成员（线性化）。

  mixin A { void show() => print("A"); }
  mixin B { void show() => print("B"); }
  class C with A, B {} // C().show() 输出 "B"
  

---

二、组合使用场景与进阶技巧

1. abstract mixin（抽象混入类）

• 场景：强制子类实现特定方法，同时提供部分通用逻辑。

• 示例：

  abstract mixin class CacheHandler {
    void save(String key, dynamic data); // 抽象方法
    dynamic fetch(String key) {          // 具体方法
      // 通用读取逻辑
    }
  }
  class FileCache with CacheHandler {
    @override
    void save(String key, data) => ... // 必须实现
  }
  

2. mixin class（Dart 3.0+）

• 作用：类同时支持 extends和 with。

• 限制：不能使用 on、extends或 with子句。

  mixin class Encryptor {
    String encrypt(String text) => text.toUpperCase();
  }
  class Service with Encryptor {} // 混入
  class AdvancedEncryptor extends Encryptor {} // 继承
  

3. on关键字约束

• 作用：限制 mixin 仅能用于特定类的子类。

• 示例：

  class Animal {
    void eat() => print("Eating");
  }
  mixin Flyer on Animal { // 仅 Animal 子类可用
    void fly() {
      super.eat(); // 可调用 Animal 的方法
      print("Flying");
    }
  }
  class Bird extends Animal with Flyer {} // ✅
  

4. extends+ with+ implements顺序

• 语法顺序：extends→ with→ implements。

• 在 Dart 中，类定义的语法顺序是强制的：必须遵循 extends（继承）→ with（混入）→ implements（接口实现）的顺序。这是 Dart 语言设计的核心规则，违反此顺序会导致编译错误

• 示例：

  class Base {}
  mixin Logging {}
  interface class ServiceContract {}
  class MyService extends Base with Logging implements ServiceContract {}
  

---

三、关键机制解析

1. 方法冲突解决（线性化）

• 规则：从右向左覆盖，最后混入的优先级最高。

  class S { void run() => print("S"); }
  mixin A on S { void run() { super.run(); print("A"); }}
  mixin B on S { void run() { super.run(); print("B"); }}
  class C extends S with A, B {}
  C().run(); // 输出：S → A → B（B 覆盖 A 的调用链）
  

2. 状态生命周期管理（Flutter 示例）

• 场景：监听 Widget 生命周期。

  mixin LifecycleLogger<T extends StatefulWidget> on State<T> {
    @override
    void initState() {
      super.initState();
      print("Initialized");
    }
  }
  class HomePageState extends State<HomePage> with LifecycleLogger {}
  

3. 与工具类的区别

特性	mixin	工具类
实例化	❌ 禁止	❌ 禁止（静态方法）
方法依赖	可访问实例属性/方法	仅静态方法，无状态
适用场景	复用状态相关逻辑（如权限）	无状态工具（如字符串处理）

---

四、最佳实践与避坑指南

1. 避免滥用 mixin

   • 业务逻辑复用（如用户认证）优先使用 mixin，工具方法（如日期格式化）用静态类。

2. 字段初始化

   • mixin中的字段必须为 late或带初始值：

     mixin Validator {
       late String input;    // ✅ late 变量
       int maxLength = 100;  // ✅ 带初始值
     }
     

3. Dart 3.0 混入限制

   • 普通类（无修饰符）不可被混入，必须改用 mixin或 mixin class。

4. 接口实现 vs 混入

   • 需要完全覆写成员 → implements
   • 需要复用实现 → with

5. 性能优化

   • 复杂 mixin优先使用 on约束，避免无关类误用。

---

以下是 Dart 中所有核心类修饰符的完整对比总结表，涵盖 mixin、abstract、mixin class及其他关键修饰符的特性与限制：

---

⚖️ Dart 类修饰符全面对比表

修饰符	允许实例化	允许继承 (extends)	允许实现 (implements)	允许混入 (with)	核心用途	典型场景
无修饰符	✅	✅（所有库）	✅（所有库）	❌（Dart ≥3.0）	默认灵活类	普通数据模型（如 UserModel）
abstract	❌	✅	✅	❌	定义规范或部分逻辑	接口契约（如 Repository）、共享基础逻辑（如 BaseWidget）
mixin	❌	❌	✅	✅	横向功能复用	跨类共享行为（如日志 Logger、验证 Validator）
mixin class	✅	✅	✅	✅	兼具类与混入能力	需同时支持继承和混入的通用逻辑（如 CacheHandler）
base	✅	✅（子类需修饰）	❌	❌	严格继承链	基础工具库（如 NetworkClient），防止外部实现破坏内部逻辑
interface	✅	❌	✅（所有库）	❌	纯接口契约	服务协议（如 Serializable）
final	✅	❌（外部库）	❌（外部库）	❌	完全封闭扩展	核心模型（如 AppConfig），禁止外部继承或实现
sealed	❌	❌（外部库）	❌（外部库）	❌	可穷举子类型	状态机（如 AuthState），支持编译器穷举检查

五、综合应用场景

场景	推荐机制	案例
跨组件共享状态逻辑	mixin+ on	页面生命周期监听（on State）
定义统一数据接口	abstract class	网络请求抽象层（DataFetcher）
功能模块组合	多 mixin+ with	电商应用（CartMixin+AuthMixin）
强制行为规范	implements	实现 Runnable接口（必须含 run()）

---

总结：

• abstract 定义规范，mixin 横向复用，with/extends/implements 明确代码关系。

• 关键决策：

  • 单继承 + 复用实现 → extends+ with

  • 多接口规范 → implements

  • 灵活功能组合 → mixin+ on约束

    合理组合这些机制，可显著提升 Flutter 项目的可维护性与复用性，同时规避 Dart 单继承的限制。

前沿技术周刊 是一份专注于技术生态的周刊，每周更新。本周刊深入挖掘高质量技术内容，为开发者提供持续的知识更新与技术洞察。

订阅渠道：【零一开源】、 【掘金】、 【RSS】

大厂在做什么

• 美团智能头盔研发实践系列02：软件功能篇

• 哔哩哔哩Android视频编辑页的架构升级

• 半年研发、1 周上线，1 秒 200 行代码爆发

• 2025 Google 开发者大会主旨演讲精华汇总

• 让AI读懂代码需求：大模型微调训练实践及端侧运行部署

• Taro on HarmonyOS 技术架构深度解析

• B站是如何实现原声视频翻译的

• 播放器音频后处理实践

码圈新闻

• 2025 年 AI 的落地程度远比我们想象的广

• 2025 Google 开发者大会 客户端要点速览

• OpenAI 首个开源模型已上线

• 一文看尽世界机器人大会

• GPT-5，重磅来袭！

深度技术

• 深入 ART Dex 加载流程，玩转 Android 通用脱壳点

• 万字长文解码如何玩转Prompt（附实践应用）

• 解密 Cursor：一位深度用户的原理探析与实验验证

• 解锁多模态大模型 InternVL2-2B：训练、微调与部署实战全攻略

• 小白都能看懂的RAG分块实战

新技术介绍

• Jetpack Compose 1.8 新增了 12 个新特性

• Flutter 3.35 发布，快来看看有什么更新吧

• TheRouter 1.3.0 版本发布，业界领先移动端全平台路由框架

• AI在实际生成环境中的提效实践

博客推荐

• Android: 适配 16KB 页面大小：提升应用性能并为用户提供更流畅的应用体验

• Android: 深入浅出Android的Context机制

• HarmonyOS: 鸿蒙ArkWeb加载优化方案详解

GitHub 一周推荐

• 其他: Qwen-Image

关于我们

【零一开源】 是一个 文章 和 开源项目 的分享站，有写博客或开源项目的也欢迎来提供投递。 每周会搜集、整理当前的新技术、新文章，欢迎大家订阅。

📜 引子：临安码农阁的卡顿之困

临安城「码农阁」的晨雾还没散，少年石惊弦就对着屏幕抓耳挠腮。他耗时三月打造的「江湖图谱」SwiftUI 应用，表面瞧着端的是华丽 —— 列表滑动如流云，按钮点击带光晕，可一加载百条门派数据，整个界面就像被点了「定身穴」，卡顿得让人心焦。

“小子，光有花架子可成不了顶尖码农。” 阁中长老风清扬负手而来，花白胡须下藏着笑意，“你这图谱招式虽炫，却犯了‘外强中干’的毛病 —— 内力（性能）跟不上，再好看也是白费。要破此局，得学‘内力探查术’（Instruments），方能揪出卡顿的病根。”

石惊弦眼睛一亮：“还请风长老赐教！”

在本篇武林秘闻录中，各位少侠将学到如下内容：

• 📜 引子：临安码农阁的卡顿之困
• 🛠️ 第一步：铸「分析之剑」—— 构建 Profiling 版本
• 📜 第二步：择「心法模板」—— 选对 Instruments 配置
• 🧐 第三步：观「经脉异动」—— 解读 Instruments 数据
  • 🔥 核心经脉：View Body Lane（View 体脉）
  • 📊 辅助经脉：View Properties 与 Core Animation Commits
  • ⚠️ 关键提醒：用真机而非「模拟器幻境」
• ⚡ 第四步：断「症结经脉」——Time Profiler（时间探查脉）
• 🎯 终章：勤练不辍，方能内力充盈

“且随我来，一步步教你如何用这‘探查术’，让你的 SwiftUI 应用内力充盈，运转如飞。”

🛠️ 第一步：铸「分析之剑」—— 构建 Profiling 版本

要施展「内力探查术」，第一步得让应用进入「实战状态」，而非平日的「拆招练习」。风清扬指着 Xcode 菜单栏：

“你平日用‘调试模式’（Debug）写代码，就像练武时放慢招式琢磨细节，虽方便却藏了不少冗余；要探查真实性能，得用‘发布模式’（Release）—— 这才是用户拿到手的‘实战版本’，招式经过优化，并无半分虚耗。”

具体操作如武林秘籍所载，有两种「起手式」：

1. 菜单栏点选「产品」>「分析」（Product > Profile）

2. 快捷键「Cmd + I」（风清扬捻须补充：“此乃高频快招，务必熟记，免得每次都翻菜单，误了探查时机”）

// 关键原理：通过 Product > Profile 或 Cmd+I 构建的应用

// 1. 自动切换为 Release 模式，开启与生产环境一致的优化

// 2. 去除 Debug 模式的冗余检查（如断言、日志），避免“假卡顿”

// 例：石惊弦之前在 Debug 模式下，加载1000条数据要2秒

// 切换到 Release 后，优化到0.3秒——可见 Debug 模式的性能问题未必是真问题

风清扬提醒：“曾有弟子见 Debug 模式卡顿就慌了神，熬夜改代码，结果 Release 模式下卡顿全消 —— 这便是没分清‘练习’与‘实战’的区别。若遇此情况，先看 Release 表现，再定是否要动手修改，此乃人间正道也。”

📜 第二步：择「心法模板」—— 选对 Instruments 配置

应用构建完成后，Instruments 会像展开一本「武功图谱」，弹出数十种探查模板。石惊弦望着满屏选项，一时不知该选哪个。

“莫慌，” 风清扬指点道，“SwiftUI 应用有专属‘心法模板’—— 就叫‘SwiftUI’模板。此模板早已整合了探查 View 重绘、动画提交、CPU 占用的全套法门，哪怕你要查的不是 SwiftUI 专属问题，用它也八九不离十。”

选好模板后，Instruments 主窗口如展开的「经脉图」，风清扬指着红色圆形按钮：“这是‘起探键’，点击后应用会启动，Instruments 会实时记录内力流转（性能数据）—— 你且试试，点击后滑动你的江湖图谱列表。”

石惊弦依言操作，屏幕上立刻跳出一条条彩色数据 lane（轨道），像极了武林中人运功时显现的经脉走向。

🧐 第三步：观「经脉异动」—— 解读 Instruments 数据

Instruments 记录的数据被分成了多条「经脉 lane」，风清扬从最关键的「View Body 经脉」讲起，如同拆解一套复杂的内功心法。

🔥 核心经脉：View Body Lane（View 体脉）

“这‘View Body 经脉’，记录的是 SwiftUI 视图的‘体’（body 属性）被重新计算的频率。” 风清扬指着 lane 上的波动线条，“SwiftUI 就像个内功高手，只有当数据（state）变化时，才会重新运转依赖该数据的 View 体脉；运转后再判断是否要重绘子视图 —— 若体脉频繁异动，便是‘内力虚耗’之兆。”

石惊弦凑近细看，发现自己的「门派列表项 View」在滑动时，体脉竟每秒波动十几次。风清扬问：“你这列表项，是否让所有子视图都依赖了整个门派数据模型？”

石惊弦点头：“是啊，我让每个列表项都绑定了整个 Clan 对象。”

“这便是症结！” 风清扬一拍桌子，“若只需显示门派名称，却让 View 依赖整个对象，哪怕只改了对象里的一个无关属性，View 体脉也会异动 —— 这叫‘牵一发而动全身’，纯属浪费内力。”

他接着指点「时间摘要」功能：“点击 lane 上的‘时间摘要’，能看到体脉运转的总时长、最短 / 最长 / 平均时长。若某个 View 体脉单次运转超过 16ms（屏幕刷新率 60fps 的极限），那必然会卡顿 —— 这就像一招出得太慢，敌人早躲开了。”

📊 辅助经脉：View Properties 与 Core Animation Commits

“这两条经脉平日用得少，但关键时刻能查漏补缺。” 风清扬指着另外两条 lane：

• View Properties 经脉：记录 SwiftUI 跟踪的视图状态（state）及其值。理论上能看出数据模型在体脉运转间的变化，但实际读起来如「天书」，除非你要精确定位数据异常，否则不必深钻。

• Core Animation Commits 经脉：记录「核心动画」（Core Animation）和 GPU 的工作量。若 View 体脉运转慢，这条经脉的「运力」也会变重 —— 就像内力运转不畅，周身气血也会淤积。

“这两条经脉不必单独看，只需结合 View Body 经脉 —— 若体脉慢、动画提交也重，那便是 View 体脉的问题拖累了全局；若体脉快、动画提交却重，那可能是 GPU 渲染的问题（比如图片过大），切记切记”

⚠️ 关键提醒：用真机而非「模拟器幻境」

风清扬突然严肃起来：“你方才用的是模拟器？此乃‘幻境’，其资源（CPU、内存）与真机‘江湖’天差地别 —— 模拟器里流畅，真机上可能卡顿；模拟器里卡顿，真机上可能更糟。探查性能，务必用真机，方能得真实内力情况！”

⚡ 第四步：断「症结经脉」——Time Profiler（时间探查脉）

“若说 View Body 经脉是‘看异动’，那‘Time Profiler 经脉’就是‘断症结’的关键。” 风清扬调出一条深色 lane，“它记录的是每段代码在哪个线程运转、运转了多久 —— 就像用‘内力探测器’，能精准找到哪条经脉（函数）阻塞了内力流转。”

石惊弦看着满屏的函数调用记录，面露难色：“这密密麻麻的，怎么找问题啊？”

“莫急，有三招‘过滤心法’，能让症结无所遁形。” 风清扬边说边调整设置：

1. Separate by thread（按线程拆分）：分清主线程（UI 线程）和子线程 ——UI 卡顿九成是主线程被占，此招能快速锁定主线程的问题。

2. Invert the call tree（反转调用树）：让最耗时的函数显示在最顶端 —— 就像把最拥堵的经脉先揪出来，不用一层层往下找。

3. Hide system libraries（隐藏系统库）：系统函数（如 UIKit、SwiftUI 底层代码）非你能改，隐藏后只看自己写的代码 —— 免得被无关经脉干扰。

// 以石惊弦的问题为例：

// 启用三招过滤心法后，Time Profiler 显示：

// 自己写的 func loadClanData() 函数在主线程运转了 800ms

// 进一步查看发现：他在该函数里直接解析 JSON 并更新 @State，且没开子线程

// 症结：主线程做了 heavy 操作（JSON 解析），导致 UI 卡顿

“这 Time Profiler 需多练才能熟练，” 风清扬笑道，“就像练‘听声辨位’，刚开始分不清方向，练多了一耳就能听出敌人在哪。你多调整几次设置，慢慢就有感觉了。”

🎯 终章：勤练不辍，方能内力充盈

石惊弦依着风清扬的指点，用 Time Profiler 找到 loadClanData() 的问题 —— 将 JSON 解析移到子线程，再用 DispatchQueue.main.async 更新 UI，重启应用后，列表滑动如流水般顺畅。

“长老，我这就把‘内力探查术’记下来，以后每次改完代码都测一测！” 石惊弦兴奋地说。

风清扬摇头：“不止如此。码农如侠客，招式再炫（UI 再美），若无内力支撑（性能），终难成顶尖高手。这 Instruments 虽好，却只是‘探查工具’—— 关键是你要懂自己的应用该如何运转：哪些慢是‘处理大数据的必经之路’，哪些慢是‘招式冗余的必改之病’。”

他望着窗外的朝阳，缓缓补充：“常练‘内力探查术’，不是为了每次都找问题，而是为了建立‘正常内力’的感觉 —— 就像侠客知道自己全力出招、收招该用多久，一旦慢了半分，立刻就知哪里出了问题。你练得越早、越勤，你的应用就越能在用户手中‘收发自如，行云流水’，这才是码农阁的真功夫。”

石惊弦恍然大悟，低头看着屏幕上流畅运转的江湖图谱，心中暗下决心：往后每写一段代码，必用 Instruments 探一探内力 —— 唯有如此，方能写出让用户称叹的好应用。

那么，列位微秃少侠们学到了吗？感谢观赏，我们下回不见不散！8-)

原文：Threads vs. Tasks in Swift Concurrency 链接：www.avanderlee.com/concurrency…

前言：别再问“它跑在哪个线程？”

在 GCD 时代，我们习惯用 DispatchQueue.global(qos: .background).async { ... } 或 DispatchQueue.main.async { ... } 来显式地把任务丢到指定线程。久而久之，形成了一种“线程思维”：

“这段代码很重，我要放到子线程。”

“这行 UI 代码必须回到主线程。”

Swift Concurrency（async/await + Task）出现以后，这套思维需要升级——系统帮你决定“跑在哪个线程”。我们只需关心“任务（Task）”本身。

线程（Thread）到底是什么？

• 系统级资源：由操作系统调度，创建、销毁、切换开销大。
• 并发手段：多线程可以让多条指令流同时跑。
• 痛点：数量一多，内存占用高、上下文切换频繁、优先级反转。

Swift Concurrency 的目标就是让我们 不再直接面对线程。

Task：比线程更高级的抽象

• 一个 Task = 一段异步工作单元。
• 不绑定线程：Task 被放进 合作线程池（cooperative thread pool），由运行时动态分配到“刚好够用”的线程上。
• 运行机制：
  1. 线程数量 ≈ CPU 核心数。
  2. 遇到 await（挂起点）时，当前线程被释放，可立即执行其他 Task。
  3. 挂起的 Task 稍后可能在另一条线程恢复。

代码示范：Task 与线程的“若即若离”

struct ThreadingDemonstrator {
    private func firstTask() async throws {
        print("Task 1 started on thread: \(Thread.current)")
        try await Task.sleep(for: .seconds(2))   // 挂起点
        print("Task 1 resumed on thread: \(Thread.current)")
    }

    private func secondTask() async {
        print("Task 2 started on thread: \(Thread.current)")
    }

    func demonstrate() {
        Task {
            try await firstTask()
        }
        Task {
            await secondTask()
        }
    }
}

典型输出（每次都可能不同）：

Task 1 started on thread: <NSThread: 0x600001752200>{number = 3, name = (null)}
Task 2 started on thread: <NSThread: 0x6000017b03c0>{number = 8, name = (null)}
Task 1 resumed on thread: <NSThread: 0x60000176ecc0>{number = 7, name = (null)}

解读：

• Task 1 在 await 时释放了线程 3；
• Task 2 趁机用到了线程 8；
• Task 1 恢复时，被安排到线程 7——前后线程可以不同。

线程爆炸（Thread Explosion）还会发生吗？

场景	GCD	Swift Concurrency
同时发起 1000 个网络请求	可能创建 1000 条线程 → 内存暴涨、调度爆炸	最多 CPU 核心数条线程，其余任务挂起 → 无爆炸
阻塞线程	线程真被 block，CPU 空转	用 continuation 挂起，线程立刻服务别的任务

因此，线程爆炸在 Swift Concurrency 中几乎不存在。

线程更少，性能反而更好？

• GCD 误区：线程越多，并发越高。
• 真相：线程 > CPU 核心时，上下文切换成本激增。
• Swift Concurrency 做法：
  • 线程数 = 核心数；
  • 用挂起/恢复代替阻塞；
  • CPU 始终在跑有效指令，切换开销极低。

实测常见场景（CPU-bound & I/O-bound）下，Swift Concurrency 往往优于 GCD。

三个常见误区

误区	正解
每个 Task 会新开一条线程	Task 与线程是多对一，由调度器动态复用
await会阻塞当前线程	await会挂起任务并释放线程
Task 一定按创建顺序执行	执行顺序不保证，取决于挂起点与调度策略

思维升级：从“线程思维”到“任务思维”

线程思维	任务思维
“这段代码要在子线程跑”	“这段代码是异步任务，系统会调度”
“回到主线程刷新 UI”	“用 @MainActor或 MainActor.run标记主界面任务”
“我怕线程太多”	“线程数系统自动管理，我专注业务逻辑”

小结

1. 线程是低层、昂贵的系统资源。
2. Task 是高层、轻量的异步工作单元。
3. Swift Concurrency 通过合作线程池 + 挂起/恢复机制，让线程数始终保持在“刚好够用”，既避免线程爆炸，又提升性能。
4. 开发者应把注意力从“线程”转向“任务”与“挂起点”。

当你下次再想问“这段代码跑在哪个线程？”时，提醒自己：

“别管线程，写正确的 Task 就行。”

原文：Async await in Swift explained with code examples

Swift 5.5 在 WWDC 2021 中引入了 async/await，随后在 Swift 6 中进一步完善，成为现代 iOS 开发中处理并发的核心工具。它不仅让异步代码更易读写，还彻底改变了我们组织并发任务的方式。

什么是 async？

async 是一个方法修饰符，表示该方法是异步执行的，即不会阻塞当前线程，而是挂起等待结果。

✅ 示例：定义一个 async 方法

func fetchImages() async throws -> [UIImage] {
    // 模拟网络请求
    let data = try await URLSession.shared.data(from: URL(string: "https://example.com/images")!).0
    return try JSONDecoder().decode([UIImage].self, from: data)
}

• async 表示异步执行；
• throws 表示可能抛出错误；
• 返回值是 [UIImage]；
• 调用时需要用 await 等待结果。

什么是 await？

await 是调用 async 方法时必须使用的关键字，表示“等待异步结果”。

✅ 示例：使用 await 调用 async 方法

do {
    let images = try await fetchImages()
    print("成功获取 \(images.count) 张图片")
} catch {
    print("获取图片失败：\(error)")
}

• 使用 try await 等待异步结果；
• 错误用 catch 捕获；
• 代码顺序执行，逻辑清晰。

async/await 如何替代回调地狱？

在 async/await 出现之前，异步操作通常使用回调闭包，这会导致回调地狱（Callback Hell）：

❌ 旧写法：嵌套回调

fetchImages { result in
    switch result {
    case .success(let images):
        resizeImages(images) { result in
            switch result {
            case .success(let resized):
                print("处理完成：\(resized.count) 张图片")
            case .failure(let error):
                print("处理失败：\(error)")
            }
        }
    case .failure(let error):
        print("获取失败：\(error)")
    }
}

✅ 新写法：线性结构

do {
    let images = try await fetchImages()
    let resizedImages = try await resizeImages(images)
    print("处理完成：\(resizedImages.count) 张图片")
} catch {
    print("处理失败：\(error)")
}

• 没有嵌套；
• 顺序清晰；
• 更易于维护和测试。

在非并发环境中调用 async 方法

如果你尝试在同步函数中直接调用 async 方法，会报错：

'async' call in a function that does not support concurrency

✅ 解决方案：使用 Task

final class ContentViewModel: ObservableObject {
    @Published var images: [UIImage] = []

    func fetchData() {
        Task { @MainActor in
            do {
                self.images = try await fetchImages()
            } catch {
                print("获取失败：\(error)")
            }
        }
    }
}

• Task {} 创建一个新的异步上下文；
• @MainActor 保证 UI 更新在主线程；
• 适用于 SwiftUI 或 UIKit。

如何在旧项目中逐步迁移？

Xcode 提供了三种自动重构方式，帮助你从旧回调方式迁移到 async/await：

✅ 方式一：Convert Function to Async

直接替换旧方法，不保留旧实现：

// 旧
func fetchImages(completion: @escaping (Result<[UIImage], Error>) -> Void)

// 新
func fetchImages() async throws -> [UIImage]

✅ 方式二：Add Async Alternative

保留旧方法，并添加新 async 方法，使用 @available 标记：

@available(*, deprecated, renamed: "fetchImages()")
func fetchImages(completion: @escaping (Result<[UIImage], Error>) -> Void) {
    Task {
        do {
            let result = try await fetchImages()
            completion(.success(result))
        } catch {
            completion(.failure(error))
        }
    }
}

func fetchImages() async throws -> [UIImage] {
    // 新实现
}

• 旧方法调用会提示警告；
• 支持逐步迁移；
• 不破坏现有代码。

✅ 方式三：Add Async Wrapper

使用 withCheckedThrowingContinuation 包装旧方法：

func fetchImages() async throws -> [UIImage] {
    try await withCheckedThrowingContinuation { continuation in
        fetchImages { result in
            continuation.resume(with: result)
        }
    }
}

• 无需改动旧实现；
• 适合第三方库或无法修改的代码。

async/await 会取代 Result 枚举吗？

虽然 async/await 让 Result 枚举看起来不再必要，但它不会立即消失。很多老代码和第三方库仍在使用 Result，但未来可能会逐步弃用。

迁移建议：先 async，再 Swift 6

• Swift 6 引入了更强的并发安全检查；
• 建议先迁移到 async/await，再升级到 Swift 6；
• 使用 @preconcurrency 和 @Sendable 等工具逐步迁移。

总结：async/await 带来的改变

特性	回调方式	async/await
可读性	差（嵌套）	好（线性）
错误处理	手动 Result	try/catch
并发控制	手动管理	结构化
测试难度	高	低
与 SwiftUI 集成	复杂	自然

SwiftUI 的声明式语法之所以优雅，一大功臣是隐藏在幕后的 ViewBuilder。它让我们可以在 body 或 HStack、VStack 等容器的闭包里随意组合多个视图，而无需手动把它们包进 Group 或 TupleView

ViewBuilder 是什么？

ViewBuilder 是一个 结果构建器（Result Builder），负责把 DSL（领域特定语言）中的多条表达式“构建”成单个视图。它最常出现的场景：

VStack {
    Image(systemName: "star")
    Text("Hello, world!")
}

我们并没有显式写 ViewBuilder.buildBlock(...)，却能在 VStack 的尾随闭包里放两个视图，这就是 @ViewBuilder 的魔力。

实际上，View 协议已经把 body 标记成了 @ViewBuilder：

@ViewBuilder var body: Self.Body { get }

所以下面这样写也完全合法：

var body: some View {
    if user != nil {
        HomeView(user: user!)
    } else {
        LoginView(user: $user)
    }
}

即使 if 的两个分支返回不同类型，ViewBuilder 也能通过 buildEither 等内部方法把它们擦除为 AnyView 或 _ConditionalContent，最终呈现出单一根视图。

给自己的 API 加上 @ViewBuilder：自定义容器

想让自定义容器也支持 DSL 语法？只需在属性或闭包参数前加 @ViewBuilder。

基本用法：把属性变成视图构建闭包

struct Container<Header: View, Content: View>: View {
    @ViewBuilder var header: Header
    @ViewBuilder var content: Content

    var body: some View {
        VStack(spacing: 0) {
            header
                .frame(maxWidth: .infinity)
                .padding()
                .foregroundStyle(.white)
                .background(.blue)

            ScrollView { content.padding() }
        }
    }
}

调用方式立即变得“SwiftUI 味儿”：

Container(header: {
    Text("Welcome")
}, content: {
    if let user {
        HomeView(user: user)
    } else {
        LoginView(user: $user)
    }
})

让 header 可选：两种做法

做法 A：带约束的扩展

extension Container where Header == EmptyView {
    init(@ViewBuilder content: () -> Content) {
        self.init(header: EmptyView.init, content: content)
    }
}

现在可以这样写：

Container {
    LoginView(user: $user)
}

做法 B：默认参数 + 手动调用闭包

struct Container<Header: View, Content: View>: View {
    private let header: Header
    private let content: Content

    init(@ViewBuilder header: () -> Header = EmptyView.init,
         @ViewBuilder content: () -> Content) {
        self.header = header()
        self.content = content()
    }

    var body: some View { ... }
}

优点：

• 不需要额外扩展；
• 可以在未来继续添加默认参数；
• 闭包在 init 就被执行，避免 body 反复求值带来的性能损耗。

多条表达式与隐式 Group

当闭包里出现多条顶层表达式时，ViewBuilder 会把它们当成 Group 的子视图。例如：

Container(header: {
    Text("Welcome")
    NavigationLink("Info") { InfoView() }
}, content: { ... })

实际上得到的是两个独立的 header 视图，各自撑满宽度，而不是一个整体。解决方式：

1. 在容器内部用显式 VStack 再包一层：

VStack(spacing: 0) {
    VStack { header }   // 👈 统一布局
        .frame(maxWidth: .infinity)
        .padding()
        .background(.blue)

    ScrollView {
        VStack { content }.padding()
    }
}

2. 或者在调用方显式组合：

private extension RootView {
    func header() -> some View {
        VStack(spacing: 20) {
            Text("Welcome")
            NavigationLink("Info") {
                InfoView()
            }
        }
    }
}

小建议：

如果函数/计算属性返回“一个整体”视图，最好显式用 VStack、HStack 等包装，而不是依赖 @ViewBuilder 隐式 Group。语义更清晰，布局也更稳定。

把 ViewBuilder 当“代码组织工具”

当 body 越来越复杂时，可以把子区域拆成私有的 @ViewBuilder 方法：

struct RootView: View {
    @State private var user: User?

    var body: some View {
        Container(header: header, content: content)
    }
}

private extension RootView {
    @ViewBuilder
    func content() -> some View {
        if let user {
            HomeView(user: user)
        } else {
            LoginView(user: $user)
        }
    }
}

注意：如果 header() 需要返回多个兄弟视图，则推荐返回显式容器，而不是 @ViewBuilder：

func header() -> some View {
    VStack(spacing: 20) { ... }
}

要点回顾

场景技巧 让属性支持 DSL在属性前加 @ViewBuilder 让参数支持 DSL在闭包参数前加 @ViewBuilder，并在 init 内手动执行 可选组件使用 EmptyView.init 作为默认值或约束扩展 多条表达式记住隐式 Group 行为，必要时显式包一层容器 代码组织用 @ViewBuilder 拆分 body，但根视图最好显式容器

结语

ViewBuilder 把 SwiftUI 的声明式语法推向了“像写普通 Swift 代码一样自然”的高度。当我们为自定义容器、可复用组件也加上 @ViewBuilder 时，API 就能与系统控件保持一致的体验，既易读又易维护。

下次写 SwiftUI 时，不妨问问自己：“这段代码能不能也让调用者用 ViewBuilder 的语法糖？” 如果答案是肯定的，就把 @ViewBuilder 加上去吧！

原文：Using Swift’s defer keyword within async and throwing contexts – Swift by Sundell

在日常 Swift 开发中，我们经常需要在多出口的函数里做清理工作：关闭文件句柄、归还数据库连接、把布尔值复原……如果每个出口都手写一遍，既啰嗦又容易遗漏。

Swift 提供了 defer 关键字，让我们可以把“善后逻辑”一次性声明在当前作用域顶部，却延迟到作用域退出时才执行。

本文将结合错误抛出（throwing）与并发（async/await）两个典型场景，带你彻底吃透 defer 的用法与注意点。

defer 基础回顾

defer { ... } 中的代码，会等到当前作用域（函数、闭包、do 块……）即将退出时执行，无论退出路径是 return、throw 还是 break。

最小示例：

func demo() {
    defer { print("最后才打印") }
    print("先打印")
    // 函数返回前，defer 里的内容一定执行
}

同步 + throwing 场景：避免重复清理

想象一个 SearchService，它通过 Database API 查询条目，必须先 open、后 close：

❌ 传统写法：分支重复

actor SearchService {
    private let database: Database

    func loadItems(matching searchString: String) throws -> [Item] {
        let connection = database.connect()

        do {
            let items: [Item] = try connection.runQuery(
                .entries(matching: searchString)
            )
            connection.close()          // 成功路径
            return items
        } catch {
            connection.close()          // 失败路径
            throw error
        }
    }
}

问题：

• 两处 close()，容易漏写。
• 如果再加 return 或 guard，分支会更多。

✅ 利用 defer：把 close 写在 open 旁边

func loadItems(matching searchString: String) throws -> [Item] {
    let connection = database.connect()
    defer { connection.close() }          // 一次声明，处处生效

    return try connection.runQuery(.entries(matching: searchString))
}

优点：

• 逻辑集中，一眼可见“成对动作”。
• 任意新增提前退出（guard、throw）都不用再管 close()。

⚠️ 注意执行顺序：

connect() → runQuery() → 作用域结束 → close()。

“延迟”并不代表“立刻”，代码阅读时需要适应这种跳跃。

async/await 场景：状态复原与去重

并发代码里，defer 更显价值——异步函数可能在任意 await 点挂起并抛错，手动追踪所有出口几乎不现实。

复原布尔 flag

场景：防止重复加载，用 isLoading 标记。

❌ 传统写法：catch 里回写 flag

actor ItemListService {
    private let networking: NetworkingService
    private var isLoading = false

    func loadItems(after lastItem: Item) async throws -> [Item] {
        guard !isLoading else { throw Error.alreadyLoading }
        isLoading = true

        do {
            let request  = requestForLoadingItems(after: lastItem)
            let response = try await networking.performRequest(request)
            let items    = try response.decoded() as [Item]

            isLoading = false        // 成功路径
            return items
        } catch {
            isLoading = false        // 失败路径
            throw error
        }
    }
}

✅ defer 写法：一行搞定

func loadItems(after lastItem: Item) async throws -> [Item] {
    guard !isLoading else { throw LoadingError.alreadyLoading }
    isLoading = true
    defer { isLoading = false }       // 无论成功/失败都会执行

    let request  = requestForLoadingItems(after: lastItem)
    let response = try await networking.performRequest(request)
    return try response.decoded()
}

利用 Task + defer 做“去重”

需求：如果同一 lastItem.id 的加载任务已在进行中，直接等待现有任务，而不是重新发起。

actor ItemListService {
    private let networking: NetworkingService
    private var activeTasks: [Item.ID: Task<[Item], Error>] = [:]

    func loadItems(after lastItem: Item) async throws -> [Item] {
        // 1. 已有任务则等待
        if let existing = activeTasks[lastItem.id] {
            return try await existing.value
        }

        // 2. 创建新任务
        let task = Task {
            // 任务结束前一定清理字典
            defer { activeTasks[lastItem.id] = nil }

            let request  = requestForLoadingItems(after: lastItem)
            let response = try await networking.performRequest(request)
            return try response.decoded() as [Item]
        }

        // 3. 登记
        activeTasks[lastItem.id] = task
        return try await task.value
    }
}

要点：

• 一旦 Task 结束（无论正常返回还是抛错），defer 把字典条目删掉，防止内存泄漏。
• 因为 actor 的重入性（reentrancy），await 期间仍可接受新调用；通过字典+Task 实现“幂等”效果。

何时不要使用 defer

• 逻辑需要严格顺序时：defer 会在作用域最后执行，若必须与中间语句保持先后关系，则不适合。
• 过度嵌套：多层 defer 会让执行顺序难以一眼看出，阅读负担大。
• 性能极端敏感：defer 本质是隐藏的 try/finally，有微小开销，但通常可以忽略。

小结 checklist

场景是否推荐 defer 单一出口函数❌ 没必要 多出口、需清理资源✅ 强烈推荐 async/await 中状态复原✅ 强烈推荐 需要精确控制顺序❌ 慎用

一句话：defer 是“善后”利器，不是“流程”利器。

只要牢记“无论怎么退出，这段代码一定跑”，就能把它用得恰到好处。

在 weekly.fatbobman.com 订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本 查看更多的文章。加入 Discord 社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

我差点失去了巴顿（我的狗狗）

巴顿已经 13 岁了。尽管大多数时候他都表现出远超同龄狗狗的活力和状态，但随着年龄增长，各种健康问题也随之而来。不久前，巴顿被检查出肺动脉高压，医生给出了针对性的治疗方案。就在我为治疗似乎初见成效而欣慰时，上周一下午，巴顿突然无法站立，大量流口水，表现出明显的心脏不适。

当时正值下班高峰，为避免去专科医院途中耽误最佳治疗时机，我先带他到最近的宠物医院急救。两小时后转入心脏病专科医院时，巴顿已经意识模糊，状况十分危急。尤其是周二晚上，他的各项生命体征都在表明他即将离我们而去。万幸的是，凭借顽强的求生欲以及我和太太的呼唤，他最终挺了过来。

在宠物医院陪伴他的六天里，我时刻回想着过去十三年他陪伴我们全家的点滴，庆幸生命中能拥有和他一起生活的美好时光。看着他从前一天的活蹦乱跳到如今的虚弱无助，心中难过至极。

作为被医生和护士称赞具有超强生命力的宝宝，住院第四天，当意识逐渐恢复后，巴顿便表现出对家的渴望，不断向我和太太表示想要回家。在医生同意后，尽管很多指标仍不理想，昨天我还是将他接回了家。或许是熟悉的环境给了他更多力量，回家后的一天里，许多之前难以改善的健康指标都在快速好转。

虽然经历这次发病后，我和太太需要投入更多精力照顾他的生活起居，但只要能和他多在一起，一切都是值得的。

巴顿，你会好起来的！我和妈妈真的很爱你！

前一期内容｜全部周报列表

近期推荐

TextKit 2：未兑现的承诺 (TextKit 2 - The Promised Land)

TextKit 是苹果提供的文本排版与渲染框架，为开发者提供高层次 API，用于处理复杂的文字布局与交互。它的目标是让 iOS 与 macOS 应用能够更轻松地实现：文本渲染、富文本编辑与高性能的文本交互。

在四年前发布时，TextKit 2 被寄予厚望，号称“更简单、更高效、更优越”。然而在实际使用中却并未完全兑现承诺。作为 STTextView 与 Notepad.exe 的作者，Marcin Krzyżanowski 基于多年的实践，指出 TextKit 2 虽然架构优雅，但实现质量欠佳，尤其在文本编辑场景下问题突出。他认为，TextKit 2 也许并非构建现代文本 UI 的理想选择。

此外，Michael Tsai 也在他的博客中整理了相关讨论，感兴趣的读者可以进一步参与。

---

LLM 为何无法真正构建软件 (Why LLMs Can't Really Build Software)

在尝试过多个大模型产品后，我始终觉得 LLM 在软件开发中缺乏全局观——即使产品提供了再大的上下文窗口。而为什么会这样，我一直难以准确表述。Conrad Irwin 在本文中给出了清晰的解释：有效的软件工程依赖于一个持续迭代的循环，其核心是工程师能维护清晰的心理模型。

LLM 虽然能写代码、修改代码、运行测试，甚至参与调试，但它们无法维持稳定的上下文，因此难以收敛到正确的解。Conrad 认为，未来软件开发的形态将是“人类 + 智能体”的协作，但至少在当下，驾驶位依然牢牢掌握在人类手中。

---

SwiftUI 主菜单开发指南 (Working with the Main Menu in SwiftUI)

相较于 iOS/iPadOS，macOS 应用的开发者数量要少得多，因此尽管 SwiftUI 很早就支持了窗口菜单，仍然鲜有人熟练使用。随着 iPadOS 26 引入类似 macOS 的窗口化体验，开发者必须尽快掌握相关 API 以适配新系统。在本文中，Gabriel Theodoropoulos 对 SwiftUI 主菜单 API 进行了详细讲解。

---

Swift Argument Parser 隐藏技巧 (Hidden Gems in the Swift Argument Parser - Part I)

苹果的开源库 swift-argument-parser 大幅降低了 Swift 开发者在构建命令行工具时的参数解析难度，而且其中还隐藏着一些鲜为人知的功能。比如，所有基于 Argument Parser 的 CLI 工具都内置了 --generate-completion-script 命令，可为 Bash、Zsh、Fish 自动生成补全脚本。在本文中，Natan Rolnik 详细介绍了该功能的使用方法，并预告将在下一篇继续探索 Swift Argument Parser 更多的进阶特性。

---

Foundation Models 动态数据结构生成 (How to Generate Dynamic Data Structures With Apple Foundation Models)

关于如何使用 GenerationSchema 定义静态数据结构的资料已经不少，但利用 DynamicGenerationSchema 在 Apple Foundation Models 中支持动态数据结构的内容却相对稀缺。即便在 WWDC 2026 中，相关示例代码也过于简化，未能完整展现整个流程。Justin Searls 以鸡尾酒配方生成器为例，详细演示了如何在运行时构建动态 schema 并解析结果。此外，他还指出 OS 26 beta 5 的 API 已更新，但文档未及时同步，极易让开发者踩坑。

---

大型 SwiftUI 应用的导航与深度链接 (NavigationStack + Deep Linking in Large SwiftUI Apps)

尽管 SwiftUI 的导航 API 日趋成熟，但在大型应用中构建一个优雅、类型安全且易于维护的路由系统仍充满挑战。Wesley Matlock 分享了一套完整的架构方案：将所有导航路由建模为 Hashable + Codable 的枚举，通过单一数据源管理导航状态，实现了深度链接、状态恢复和调试工具的无缝集成。特别值得称道的是其"路由链"设计——深度链接不只是简单跳转，而是构建完整的导航路径，确保用户始终拥有清晰的返回路径。

工具

SwiftAgent - 优雅的 AI 代理框架

即便你的应用暂时用不到 Apple 的 Foundation Models，也不得不承认该框架的 API 设计优雅，充分展现了 Swift 语言的特色。Dennis Müller 开发的 SwiftAgent 正是深受这一设计理念启发的开源项目，它将 FoundationModels 的声明式 API 风格带到了跨平台 AI 代理开发中。

该项目通过 @Generable 宏实现类型安全的工具定义，提供零配置的代理循环，并支持多种 AI 适配器（目前已支持 OpenAI）。最令人印象深刻的是其对上下文管理的处理——清晰地分离用户输入与增强信息，以及通过 ResolvedToolRun 枚举实现编译时类型安全的工具调用追踪。对于想要在 Swift 应用中集成 AI 代理功能的开发者来说，SwiftAgent 提供了一条熟悉且优雅的实现路径。

往期内容

• 苹果首次在中国永久关闭了一家 Apple Store - #097
• Xcode 26 beta 4，要崩我们一起崩 - #096
• Blender 正在开发 iPad 版本 - #095
• F1：电影很好看，赛事很挣钱 - #094

THANK YOU

如果你觉得这份周报或者我的文章对你有所帮助，欢迎 点赞 并将其 转发 给更多的朋友。

在 weekly.fatbobman.com 订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本 查看更多的文章。加入 Discord 社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

由一个问题想到的：现象是UI操作在主线程但不在主队列，仍不安全

DISPATCH_WAIT_FOR_QUEUE

这段代码是 GCD（Grand Central Dispatch）中 dispatch_sync 同步操作的核心等待逻辑，负责处理线程阻塞、队列状态检查、死锁检测和优先级继承等关键机制。下面是对代码的逐部分解析：

---

1. 函数作用

__DISPATCH_WAIT_FOR_QUEUE__ 在同步提交任务时被调用，主要完成以下工作：

1. 死锁检测：检查当前线程是否已持有目标队列锁（避免死锁）。
2. 队列状态准备：根据队列类型（全局队列、主队列等）初始化等待上下文。
3. 线程阻塞：通过事件或信号量机制阻塞当前线程，直到任务完成。
4. 优先级继承：确保高优先级任务能及时执行。

---

2. 代码逐段解析

(1) 死锁检测

uint64_t dq_state = _dispatch_wait_prepare(dq);
if (unlikely(_dq_state_drain_locked_by(dq_state, dsc->dsc_waiter))) {
    DISPATCH_CLIENT_CRASH((uintptr_t)dq_state,
            "dispatch_sync called on queue "
            "already owned by current thread");
}

• _dispatch_wait_prepare：获取队列的当前状态（dq_state）。

• _dq_state_drain_locked_by：检查队列是否已被当前线程（dsc->dsc_waiter）锁定。

  • 如果是，触发 DISPATCH_CLIENT_CRASH（即著名的  “同步到当前队列死锁”  崩溃）。
  • 典型场景：在串行队列中同步提交任务到同一队列。

---

(2) 保存线程帧状态

_dispatch_thread_frame_save_state(&dsc->dsc_dtf);

• 作用：保存当前线程的调用栈帧信息，用于后续任务执行时的上下文恢复（尤其是主队列任务或跨线程执行时）。

---

(3) 队列类型判断与等待句柄初始化

if (_dq_state_is_suspended(dq_state) || _dq_state_is_base_anon(dq_state)) {
    dsc->dc_data = DISPATCH_WLH_ANON; // 匿名等待句柄
} else if (_dq_state_is_base_wlh(dq_state)) {
    dsc->dc_data = (dispatch_wlh_t)dq; // 队列作为等待句柄
} else {
    _dispatch_wait_compute_wlh(upcast(dq)._dl, dsc); // 计算层级队列的等待句柄
}

• DISPATCH_WLH_ANON：表示队列无关联的特定等待句柄（如全局队列）。
• dispatch_wlh_t：队列本身作为等待句柄（如主队列）。
• 层级队列：通过 _dispatch_wait_compute_wlh 计算父队列的等待句柄。

---

(4) 匿名等待句柄的特殊处理

if (dsc->dc_data == DISPATCH_WLH_ANON) {
    dsc->dsc_override_qos_floor = dsc->dsc_override_qos =
            (uint8_t)_dispatch_get_basepri_override_qos_floor();
    _dispatch_thread_event_init(&dsc->dsc_event); // 初始化线程事件
}

• QoS 优先级：记录当前线程的优先级基线（basepri_override_qos_floor）。
• 线程事件：初始化一个轻量级事件（dsc_event），用于线程阻塞和唤醒。

---

(5) 任务入队与阻塞等待

dx_push(dq, dsc, _dispatch_qos_from_pp(dsc->dc_priority));
_dispatch_trace_runtime_event(sync_wait, dq, 0);

if (dsc->dc_data == DISPATCH_WLH_ANON) {
    _dispatch_thread_event_wait(&dsc->dsc_event); // 阻塞当前线程
} else if (!dsc->dsc_wlh_self_wakeup) {
    _dispatch_event_loop_wait_for_ownership(dsc); // 事件循环等待（如主队列）
}

• dx_push：将任务（dsc）提交到目标队列（dq）。

• 阻塞方式：

  • 匿名队列：通过 _dispatch_thread_event_wait 阻塞线程（底层可能是 pthread_cond_wait 或自旋锁）。
  • 绑定队列（如主队列）：通过 _dispatch_event_loop_wait_for_ownership 进入事件循环等待。

---

(6) 唤醒后清理与优先级恢复

if (dsc->dc_data == DISPATCH_WLH_ANON) {
    _dispatch_thread_event_destroy(&dsc->dsc_event);
    // 恢复或提升优先级
    if (dsc->dsc_override_qos > dsc->dsc_override_qos_floor) {
        _dispatch_set_basepri_override_qos(dsc->dsc_override_qos);
    }
}

• 事件销毁：释放线程事件资源。
• 优先级继承：若任务执行期间优先级被提升（如高 QoS 任务），恢复线程的优先级。

3. 关键机制总结

机制	实现方式
死锁检测	检查队列是否已被当前线程锁定（_dq_state_drain_locked_by）。
线程阻塞	匿名队列用线程事件（dsc_event），主队列用事件循环（CFRunLoop）。
优先级继承	通过 dsc_override_qos 传递任务优先级，避免低优先级线程阻塞高优先级任务。
队列层级处理	递归计算父队列的等待句柄（_dispatch_wait_compute_wlh）。
调试支持	_dispatch_trace_runtime_event 记录运行时事件（如 Instruments 可观测）。

---

4. 性能与安全注意事项

1. 死锁风险：

   • 绝对避免在串行队列中同步提交任务到同一队列。

2. 优先级反转：

   • 低 QoS 线程同步调用高 QoS 任务时，GCD 会自动提升优先级（通过 dsc_override_qos）。

3. 主队列同步：

   • 若当前非主线程，会唤醒主线程执行任务；若当前是主线程，直接触发崩溃。

---

5. 扩展：如何优化同步调用？

• 减少 dispatch_sync 使用：优先使用 dispatch_async + 信号量。

• 避免全局队列同步：全局队列的线程竞争会增加开销。

• 主线程检查： if (pthread_main_np()) { block(); // 直接执行 } else { dispatch_sync(dispatch_get_main_queue(), block); }

dispatch_sync_f_slow 中的一段注释解析

Global concurrent queues and queues bound to non-dispatch threads always fall into the slow case, see DISPATCH_ROOT_QUEUE_STATE_INIT_VALUE

这段注释和代码片段涉及 GCD（Grand Central Dispatch）  的底层实现，特别是关于 全局并发队列（Global Concurrent Queues）  和 绑定到非调度线程的队列（queues bound to non-dispatch threads）  的慢速路径处理逻辑。下面是对其含义和背后机制的详细解析：

---

1. 关键概念解释

(1) Global Concurrent Queues（全局并发队列）

• 系统提供的预定义并发队列（如 DISPATCH_QUEUE_PRIORITY_DEFAULT）。

• 特点：

  • 由 GCD 管理，不绑定特定线程。
  • 任务可能在任何线程池中的线程执行。

(2) Queues Bound to Non-Dispatch Threads（绑定到非调度线程的队列）

• 某些队列可能绑定到非 GCD 管理的线程（如主线程或开发者手动创建的线程）。

• 典型例子：

  • 主队列（Main Queue） ：绑定到主线程（UI 线程）。
  • 自定义串行队列绑定到特定 pthread。

---

2. 为什么这些队列会进入 Slow Case（慢速路径）？

(1) 注释解析

// Global concurrent queues and queues bound to non-dispatch threads
// always fall into the slow case, see DISPATCH_ROOT_QUEUE_STATE_INIT_VALUE

• 含义：

  • 全局并发队列和绑定到非 GCD 线程的队列无法直接快速执行任务，必须走 _dispatch_sync_f_slow 路径。
  • 原因与队列的初始状态（DISPATCH_ROOT_QUEUE_STATE_INIT_VALUE）有关。

(2) 根本原因

• 全局并发队列：

  • 无固定线程绑定，任务可能被派发到任意线程，需额外同步机制。
  • 需要处理线程池竞争、优先级继承等复杂逻辑。

• 绑定到非调度线程的队列（如主队列）：

  • 任务必须在特定线程（如主线程）执行，需跨线程通信。
  • 例如：dispatch_sync 到主队列时，若当前已是主线程，需防死锁；若非主线程，需唤醒主线程执行。

---

3. 代码逻辑关联

在 _dispatch_sync_f_slow 中，以下代码触发慢速路径：

if (unlikely(!dq->do_targetq)) {
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

• 条件分析：

  • do_targetq 为 NULL 时，表示队列是终端队列（无进一步转发目标）。
  • 全局并发队列和绑定到非调度线程的队列均满足 !do_targetq，因此进入慢速路径。

---

4. 慢速路径的具体行为

(1) 全局并发队列

• 挑战：

  • 需从线程池中选择空闲线程。
  • 处理任务优先级（如 QOS 级别）。

• 实现：

  • 通过 __DISPATCH_WAIT_FOR_QUEUE__ 等待线程可用。
  • 可能触发线程唤醒或创建（如 pthread_workqueue）。

(2) 主队列（Main Queue）

• 挑战：

  • 必须确保任务在主线程执行。
  • 若当前是主线程，需防死锁（同步提交到当前队列）。

• 实现：

  • 通过 dsc.dsc_waiter 检查线程 ID。
  • 若线程不匹配，通过 libdispatch 的消息机制（如 Mach port）唤醒主线程。

---

5. 性能影响与优化

(1) 为什么慢速路径更耗时？

• 额外开销：

  • 线程状态切换（阻塞/唤醒）。
  • 锁竞争或信号量同步。
  • 优先级继承逻辑（如 dc_priority 处理）。

(2) 优化建议

• 避免频繁 dispatch_sync 到全局队列：

  • 改用 dispatch_async + 信号量（如 dispatch_semaphore_t）减少阻塞。

• 主队列的同步调用：

  • 检查当前是否已是主线程（避免无意义跳转）： if (pthread_main_np()) { block(); // 直接执行 } else { dispatch_sync(dispatch_get_main_queue(), block); }

---

6. 扩展：DISPATCH_ROOT_QUEUE_STATE_INIT_VALUE

• 定义：全局队列的初始化状态标志。

• 作用：

  • 标记队列为全局根队列，无法直接执行任务。
  • 强制走慢速路径以处理线程池和优先级。

---

总结

1. 全局并发队列和绑定到非 GCD 线程的队列因无法直接执行任务，必须进入 _dispatch_sync_f_slow。

2. 根本原因：

   • 全局队列需动态分配线程。
   • 绑定队列需跨线程通信（如主队列）。

3. 性能注意：

   • 同步调用到这些队列会有额外开销，需合理设计线程模型。

_dispatch_sync_f_slow 解析

DISPATCH_NOINLINE
**static** **void******
_dispatch_sync_f_slow(dispatch_queue_class_t top_dqu, **void** *ctxt,
    dispatch_function_t func, uintptr_t top_dc_flags,
    dispatch_queue_class_t dqu, uintptr_t dc_flags)
{

    dispatch_queue_t top_dq = top_dqu._dq;

    dispatch_queue_t dq = dqu._dq;

    **if** (unlikely(!dq->do_targetq)) {

    **return** _dispatch_sync_function_invoke(dq, ctxt, func);

    }

    pthread_priority_t pp = _dispatch_get_priority();

    **struct** dispatch_sync_context_s dsc = {
        .dc_flags    = DC_FLAG_SYNC_WAITER | dc_flags,
        .dc_func     = _dispatch_async_and_wait_invoke,
        .dc_ctxt     = &dsc,
        .dc_other    = top_dq,
        .dc_priority = pp | _PTHREAD_PRIORITY_ENFORCE_FLAG,
        .dc_voucher  = _voucher_get(),
        .dsc_func    = func,
        .dsc_ctxt    = ctxt,
        .dsc_waiter  = _dispatch_tid_self(),
    };
    _dispatch_trace_item_push(top_dq, &dsc);

    __DISPATCH_WAIT_FOR_QUEUE__(&dsc, dq);

    **if** (dsc.dsc_func == **NULL**) {
        // dsc_func being cleared means that the block ran on another thread ie.
        // case (2) as listed in _dispatch_async_and_wait_f_slow.
        dispatch_queue_t stop_dq = dsc.dc_other;
        **return** _dispatch_sync_complete_recurse(top_dq, stop_dq, top_dc_flags);
    }
    _dispatch_introspection_sync_begin(top_dq);
    _dispatch_trace_item_pop(top_dq, &dsc);
    _dispatch_sync_invoke_and_complete_recurse(top_dq, ctxt, func,top_dc_flags
        DISPATCH_TRACE_ARG(&dsc));

}

这段代码是 Grand Central Dispatch (GCD)  中 dispatch_sync 函数的底层实现之一（_dispatch_sync_f_slow），用于处理同步提交任务到队列的慢速路径（即无法直接执行任务时的复杂情况）。以下是对代码的逐部分解析：

---

1. 函数签名与参数

static void _dispatch_sync_f_slow(
    dispatch_queue_class_t top_dqu,  // 目标队列（外层队列）
    void *ctxt,                     // 任务上下文（block或函数参数）
    dispatch_function_t func,       // 要执行的任务函数
    uintptr_t top_dc_flags,         // 外层队列的标志位
    dispatch_queue_class_t dqu,     // 当前队列（实际执行队列）
    uintptr_t dc_flags              // 当前队列的标志位
)

• 作用：将任务同步提交到队列，确保任务在当前线程执行完成。
• 慢速路径：当任务无法直接执行时（如队列繁忙、死锁风险等），进入此函数。

---

2. 关键逻辑解析

(1) 直接执行检查

if (unlikely(!dq->do_targetq)) {
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

• 条件：如果队列没有目标队列（即队列是串行队列且无全局队列层级）。
• 行为：直接调用 _dispatch_sync_function_invoke 执行任务，无需排队。

---

(2) 同步上下文初始化

pthread_priority_t pp = _dispatch_get_priority();
struct dispatch_sync_context_s dsc = {
    .dc_flags    = DC_FLAG_SYNC_WAITER | dc_flags,  // 标记为同步等待者
    .dc_func     = _dispatch_async_and_wait_invoke,  // 实际执行函数
    .dc_ctxt     = &dsc,                            // 上下文指向自身
    .dc_other    = top_dq,                          // 外层队列（用于回溯）
    .dc_priority = pp | _PTHREAD_PRIORITY_ENFORCE_FLAG, // 线程优先级
    .dc_voucher  = _voucher_get(),                  // 线程优先级凭证
    .dsc_func    = func,                            // 用户任务函数
    .dsc_ctxt    = ctxt,                            // 用户任务上下文
    .dsc_waiter  = _dispatch_tid_self(),            // 当前线程ID
};

• dispatch_sync_context_s：保存任务执行所需的全部信息，包括：

  • 任务函数（dsc_func）和参数（dsc_ctxt）。
  • 线程优先级（dc_priority）和队列关联（dc_other）。
  • 同步标记（DC_FLAG_SYNC_WAITER）表示当前线程正在等待任务完成。

---

(3) 等待队列可用

_dispatch_trace_item_push(top_dq, &dsc);  // 记录调试信息
__DISPATCH_WAIT_FOR_QUEUE__(&dsc, dq);   // 阻塞等待队列可用

• __DISPATCH_WAIT_FOR_QUEUE__ ：

  • 检查队列状态，若队列繁忙或可能死锁，则阻塞当前线程。
  • 内部可能调用 pthread_cond_wait 或自旋锁（具体实现依赖系统）。

---

(4) 任务执行与完成

if (dsc.dsc_func == NULL) {
    // 任务已在其他线程执行完成（如队列层级转发）
    dispatch_queue_t stop_dq = dsc.dc_other;
    return _dispatch_sync_complete_recurse(top_dq, stop_dq, top_dc_flags);
}

// 正常执行路径
_dispatch_introspection_sync_begin(top_dq);
_dispatch_trace_item_pop(top_dq, &dsc);
_dispatch_sync_invoke_and_complete_recurse(top_dq, ctxt, func, top_dc_flags);

• 分支1：dsc_func == NULL

  • 表示任务已被其他线程执行（如队列层级转发），直接递归完成同步。

• 分支2：正常执行

  • 调用 _dispatch_sync_invoke_and_complete_recurse 执行用户任务，并递归处理队列层级。

---

3. 核心机制总结

1. 同步阻塞：

   • 当前线程会阻塞，直到任务执行完成（通过 __DISPATCH_WAIT_FOR_QUEUE__）。

2. 优先级继承：

   • 通过 dc_priority 继承队列的优先级，避免优先级反转。

3. 死锁检测：

   • 若检测到当前线程已在队列中执行任务（如 dispatch_sync 到当前串行队列），会触发崩溃（__DISPATCH_WAIT_FOR_QUEUE__ 内部处理）。

4. 队列层级处理：

   • 支持队列的层级转发（如提交到串行队列的任务可能在其目标队列执行）。

---

4. 与 dispatch_async 的区别

特性	dispatch_sync	dispatch_async
线程阻塞	调用线程阻塞，等待任务完成	立即返回，任务异步执行
上下文保存	需构造 dispatch_sync_context_s	构造 dispatch_continuation_s
性能开销	更高（线程切换/阻塞风险）	更低（无阻塞）
死锁风险	高（同步到当前串行队列会死锁）	无

---

5. 应用场景与注意事项

• 何时使用：

  • 需要立即获取结果或保证执行顺序时（如修改线程敏感数据）。

• 注意事项：

  • 避免在串行队列中同步提交任务到同一队列（死锁）。
  • 谨慎处理优先级，防止优先级反转。

dispatch_async的实现

dispatch_async 是 GCD（Grand Central Dispatch）的核心函数之一，用于异步提交任务到队列。它的实现涉及任务封装、队列调度、线程管理等多个环节。下面从源码层面逐步解析其工作原理（基于 libdispatch 开源代码）。

---

1. 函数入口与快速路径

入口函数

void dispatch_async(dispatch_queue_t dq, dispatch_block_t block) {
    dispatch_continuation_t dc = _dispatch_continuation_alloc();
    _dispatch_continuation_init(dc, dq, block, 0, DC_FLAG_CONSUME);
    _dispatch_continuation_async(dq, dc);
}

• 步骤：

  1. 分配任务容器（dispatch_continuation_t）：存储任务块（block）和上下文。
  2. 初始化任务：绑定队列和任务，设置标志位（如 DC_FLAG_CONSUME 表示自动释放 block）。
  3. 异步提交：调用 _dispatch_continuation_async 进入核心逻辑。

快速路径（Fast Path）

在 _dispatch_continuation_async 中，系统会尝试快速派发任务：

if (likely(!_dispatch_queue_try_acquire_async(dq))) {
    _dispatch_continuation_push(dq, dc); // 快速入队
    return;
}

• 条件：队列未满且无需线程切换（如并发队列有空闲线程）。
• 行为：直接压入队列的待执行任务链表（dq_items_head）。

---

2. 任务封装：dispatch_continuation_t

任务被封装为 dispatch_continuation_t 结构体：

struct dispatch_continuation_s {
    union {
        void *do_vtable;              // 函数指针表
        dispatch_function_t dc_func;  // 任务函数
    };
    void *do_ctxt;                    // 任务上下文（参数）
    void *do_next;                    // 下一个任务（链表指针）
    uintptr_t dc_flags;               // 标志位（如优先级、类型）
    dispatch_queue_t dc_queue;        // 目标队列
};

• 作用：将用户提交的 block 或函数指针转换为统一的任务对象。

---

3. 队列调度逻辑

(1) 串行队列（Serial Queue）

• 行为：

  • 任务按 FIFO 顺序执行。
  • 若队列空闲，唤醒一个线程处理；若繁忙，任务追加到链表尾部。

• 关键代码： _dispatch_thread_override_start(dq, dc); // 设置线程优先级 _dispatch_serial_queue_push(dq, dc); // 入队

(2) 全局并发队列（Global Queue）

• 行为：

  • 任务由线程池中的任意空闲线程执行。
  • 通过 pthread_workqueue 管理线程生命周期。

• 关键代码： _dispatch_root_queue_push(dq, dc, 1); // 提交到根队列

---

4. 线程管理与唤醒

(1) 线程池（Thread Pool）

• GCD 维护一组线程（基于 pthread_workqueue），根据系统负载动态调整数量。

• 线程创建： _dispatch_worker_thread2(pthread_priority_t priority) { while ((dc = _dispatch_queue_concurrent_drain_one(dq))) { _dispatch_continuation_redirect(dq, dc); // 执行任务 } }

(2) 唤醒机制

• 信号量/事件：通过 _dispatch_sema4_signal 或 kevent 唤醒休眠线程。
• 主队列：通过 mach port 或 CFRunLoop 唤醒主线程。

---

5. 优先级继承（QoS Propagation）

GCD 会根据任务的 QoS（Quality of Service）调整线程优先级：

qos = _dispatch_priority_to_qos(dc->dc_priority); // 获取任务 QoS
_dispatch_thread_override_start(dq, dc);          // 临时提升线程优先级

• 作用：避免低优先级线程阻塞高优先级任务（如 UI 更新）。

---

6. 慢速路径（Slow Path）

当队列繁忙或需要特殊处理时（如主队列任务），进入慢速路径：

if (unlikely(dq->dq_items_tail == NULL)) {
    _dispatch_queue_wakeup(dq); // 唤醒队列
}

---

7. 完整流程总结

1. 任务封装：Block → dispatch_continuation_t。

2. 队列选择：根据队列类型（串行/并发）选择调度策略。

3. 线程派发：

   • 并发队列：扔进线程池，由空闲线程处理。
   • 串行队列：按顺序执行，必要时唤醒线程。

4. 执行任务：调用 dc_func(dc_ctxt) 执行用户代码。

---

8. 关键优化点

场景	优化手段
高频小任务	合并为 dispatch_apply 或批量提交
主队列任务	避免阻塞，优先用 dispatch_async
线程爆炸风险	控制并发队列的 QoS 和线程上限

---

9. 与 dispatch_sync 的对比

特性	dispatch_async	dispatch_sync
线程阻塞	不阻塞	阻塞当前线程
任务存储	dispatch_continuation_t 链表	dispatch_sync_context_t 上下文
优先级继承	通过 QoS 传递	显式提升线程优先级
死锁风险	无	同步到当前队列会死锁

---

10. 调试技巧

• Instruments：使用 Dispatch 工具跟踪任务派发和线程使用。
• 符号断点：在 _dispatch_continuation_async 处断点，观察任务提交堆栈。

dx_push

dx_push 是 GCD（Grand Central Dispatch）底层用于将任务（continuation）压入队列的核心函数，其名称中的 dx 代表 "dispatch queue operation"。它的作用是将封装好的任务（dispatch_continuation_t）提交到目标队列（dispatch_queue_t），并根据队列类型（串行/并发）和状态决定是否唤醒线程执行任务。以下是详细解析：

---

1. 函数定义与参数

static inline void 
dx_push(dispatch_queue_t dq, dispatch_object_t dou, dispatch_qos_t qos)

• 参数：

  • dq：目标队列（如主队列、全局队列或自定义队列）。
  • dou：任务对象（通常是 dispatch_continuation_t，通过类型转换传入）。
  • qos：任务的服务质量（Quality of Service），用于优先级处理。

---

2. 核心逻辑解析

(1) 任务入队

dx_push 的最终目的是将任务添加到队列的任务链表中，其伪代码如下：

// 将任务添加到队列的链表中（FIFO）
dou._do->do_next = NULL;
if (dq->dq_items_tail) {
    dq->dq_items_tail->do_next = dou._do; // 追加到尾部
} else {
    dq->dq_items_head = dou._do;          // 第一个任务
}
dq->dq_items_tail = dou._do;

(2) 唤醒队列

如果队列处于空闲状态（无任务执行），需要唤醒线程处理新任务：

if (unlikely(os_atomic_load2o(dq, dq_items_head, acquire) == dou._do)) {
    _dispatch_queue_wakeup(dq, qos, /*allow_override=*/false);
}

• 条件：dq_items_head == dou._do 表示当前任务是队列中的唯一任务（即队列原先为空）。
• 行为：调用 _dispatch_queue_wakeup 触发线程唤醒。

---

3. 队列类型处理

dx_push 的具体实现因队列类型而异，通过宏定义动态分发：

#define dx_push(dq, dou, qos) \
        _dispatch_queue_push(dq, dou._dc, qos)

实际会调用队列的 dq_push 函数指针，指向队列类型的特定实现：

• 串行队列（Serial Queue） ：_dispatch_serial_queue_push
• 全局并发队列（Global Queue） ：_dispatch_root_queue_push
• 主队列（Main Queue） ：_dispatch_main_queue_push

---

4. 优先级继承（QoS Propagation）

在任务入队时，qos 参数用于处理优先级继承：

// 从 continuation 中提取 QoS
dispatch_qos_t qos = _dispatch_continuation_get_qos(dc);
// 传递给队列唤醒逻辑
_dispatch_queue_wakeup(dq, qos, /*allow_override=*/false);

• 作用：确保高优先级任务能及时唤醒线程执行（避免优先级反转）。

---

5. 底层依赖

dx_push 依赖以下关键函数：

函数	作用
_dispatch_queue_wakeup	唤醒队列关联的线程（或线程池）。
_dispatch_continuation_get_qos	从任务中提取 QoS 优先级。
os_atomic_load2o	原子操作读取队列状态。

---

6. 性能优化

• 原子操作：使用 os_atomic 宏保证线程安全（无锁设计）。
• 快速路径：队列非空时仅更新链表，避免额外唤醒开销。
• 动态派发：通过函数指针针对不同队列类型优化逻辑。

---

7. 与 dispatch_async 的关系

dx_push 是 dispatch_async 的底层支撑：

1. dispatch_async 封装任务为 dispatch_continuation_t。
2. 调用 dx_push 将任务压入队列。
3. 若队列空闲，触发线程唤醒。

---

8. 典型调用栈

dispatch_async()
  → _dispatch_continuation_async()
    → dx_push() 
      → _dispatch_root_queue_push() [全局队列]
      → _dispatch_serial_queue_push() [串行队列]

---

总结

• 核心作用：将任务安全地添加到队列的任务链表，必要时唤醒线程。

• 关键特性：

  • 线程安全的无锁设计（原子操作）。
  • 支持动态队列类型处理（串行/并发/主队列）。
  • 集成 QoS 优先级传递。

• 性能影响：高频调用时，入队操作的开销主要来自原子操作和内存访问。

dispatch_worker_thread和dispatch_worker_thread2的区别

_dispatch_worker_thread 与 _dispatch_worker_thread2 深度对比解析

在 libdispatch 的线程池实现中，_dispatch_worker_thread 和 _dispatch_worker_thread2 都是工作线程的入口函数，但设计目标和适用场景有显著差异。以下是基于 libdispatch 1271 版本的详细对比分析：

---

一、核心区别概览

特性	_dispatch_worker_thread	_dispatch_worker_thread2
应用场景	全局并发队列 (Global Concurrent Queues)	管理队列 (Management Queues)
任务类型	常规用户任务	系统级管理任务（定时器/事件源等）
线程行为	主动任务窃取	被动信号等待
生命周期	动态创建/销毁	常驻线程
优先级管理	QoS 继承	固定 QoS (UTILITY/BACKGROUND)
唤醒机制	内核级 pthread_workqueue	GCD 内部信号量

---

二、代码实现深度解析

1. _dispatch_worker_thread（常规工作线程）

static void _dispatch_worker_thread(void *context) {
    dispatch_queue_global_t dq = context;
    
    // 1. 设置线程QoS
    pthread_priority_t pp = _dispatch_get_priority();
    _dispatch_set_qos_class_self(pp);
    
    // 2. 任务处理循环
    while ((dc = _dispatch_queue_concurrent_drain_one(dq))) {
        _dispatch_continuation_invoke(dc); // 执行用户任务
        
        // 3. 任务窃取（Work Stealing）
        if (!_dispatch_queue_try_steal_item(dq)) {
            break;
        }
    }
    
    // 4. 线程回收
    os_atomic_dec2o(dq, dgq_thread_pool_size, relaxed);
    _dispatch_thread_recycle();
}

关键设计：

• 主动任务窃取：当本地队列为空时，尝试从其他队列窃取任务（_dispatch_queue_try_steal_item）
• 动态优先级：根据执行任务的 QoS 动态调整线程优先级
• 自动扩缩容：线程空闲超时（默认 30 秒）后自动销毁

---

2. _dispatch_worker_thread2（管理线程）

static void _dispatch_worker_thread2(void *context) {
    dispatch_mgr_q.dq_items_head = NULL;
    
    // 1. 固定线程优先级
    _dispatch_set_qos_class_self(QOS_CLASS_UTILITY);
    pthread_setname_np("com.apple.root.management-qos");
    
    // 2. 事件循环
    while (true) {
        // 3. 执行管理任务
        _dispatch_mgr_invoke();
        
        // 4. 信号量等待（最长60秒）
        dispatch_semaphore_wait(dq->do_suspend_cnt, 
            dispatch_time(0, 60 * NSEC_PER_SEC));
        
        // 5. 内存压力检测
        if (_dispatch_is_memory_pressure()) {
            _dispatch_mgr_compact();
        }
    }
}

关键设计：

• 常驻线程：永不退出的事件循环
• 低优先级：固定为 UTILITY/BACKGROUND QoS
• 被动唤醒：通过 GCD 内部信号量 (do_suspend_cnt) 触发
• 系统任务：处理定时器 (dispatch_source_timer)、事件源等

---

三、任务处理机制对比

任务获取方式

函数	任务获取逻辑
_dispatch_worker_thread	_dispatch_queue_concurrent_drain_one： - 原子操作弹出队首任务 - 支持并发安全的任务分配
_dispatch_worker_thread2	_dispatch_mgr_invoke： - 扫描管理队列链表 - 处理到期定时器 - 执行事件源回调

执行逻辑差异

---

四、线程生命周期管理

1. _dispatch_worker_thread 生命周期

// 线程回收逻辑（简化）
void _dispatch_thread_recycle() {
    if (idle_time > 30 * NSEC_PER_SEC) {
        _dispatch_thread_exit(); // 销毁线程
    } else {
        _dispatch_thread_cache_add(thread); // 加入缓存池
    }
}

• 缓存策略：空闲线程保留在 TLS 缓存池中
• 超时销毁：30 秒无任务自动销毁

2. _dispatch_worker_thread2 生命周期

// 无退出机制的事件循环
while (true) {
    // 永不退出
}

• 常驻设计：整个进程生命周期存在
• 数量固定：通常每个 QoS 级别 1-2 个线程

---

五、性能优化差异

_dispatch_worker_thread 优化

• 缓存亲和性：通过 thread_bind 绑定 CPU 核心
• 优先级继承：临时提升线程 QoS 匹配任务

void _dispatch_continuation_invoke(dispatch_continuation_t dc) {
    pthread_priority_t orig = pthread_get_priority();
    pthread_set_priority(dc->dc_priority); // 提升至任务QoS
    dc->dc_func(dc->dc_ctxt);
    pthread_set_priority(orig); // 恢复
}

_dispatch_worker_thread2 优化

• 批处理机制：单次唤醒处理多个到期定时器
• 内存压缩：定期清理空闲资源

void _dispatch_mgr_invoke() {
    // 批量处理到期定时器
    for (i = 0; i < BATCH_SIZE; i++) {
        _dispatch_timer_list_invoke(dq);
    }
}

---

六、应用场景示例

1. _dispatch_worker_thread 典型场景

// 用户提交的并发任务
DispatchQueue.global().async {
    downloadImage() // 最终由 _dispatch_worker_thread 执行
}

2. _dispatch_worker_thread2 典型场景

// 系统管理的定时器
let timer = DispatchSource.makeTimerSource()
timer.schedule(deadline: .now(), repeating: 1.0)
timer.setEventHandler { /* 由 _dispatch_worker_thread2 触发 */ }

---

总结：设计哲学差异

维度	_dispatch_worker_thread	_dispatch_worker_thread2
设计目标	最大化用户任务吞吐量	保障系统服务可靠性
资源策略	动态扩缩容（按需创建）	静态分配（常驻线程）
响应特性	低延迟任务执行	高可靠事件调度
优化方向	计算密集型任务优化	I/O 密集型任务优化

核心结论：
_dispatch_worker_thread 是面向用户任务的 弹性工作线程，而 _dispatch_worker_thread2 是支撑 GCD 内部基础设施的 系统服务线程。两者共同构成了 GCD 分层线程模型的核心支柱。

主线程通过 dispatch_sync 提交到自定义串行队列的执行机制深度解析

在 GCD 中，主线程通过 dispatch_sync 向自定义串行队列提交任务时，任务不会直接在主线程执行，而是由 GCD 动态选择线程执行。以下是关键场景的详细分析：

---

一、核心执行规则

1. 默认行为（最常见情况）

let customQueue = DispatchQueue(label: "com.example.serial")
DispatchQueue.main.async {
    dispatch_sync(customQueue) {
        print("执行线程: (Thread.current)") // 通常不在主线程
    }
}

• 执行线程：GCD 线程池中的工作线程（非主线程）
• 原因：避免阻塞主线程，由系统自动分配线程资源

2. 直接在主线程执行的唯一场景

当同时满足以下两个条件时，任务会在主线程同步执行：

// libdispatch 底层决策逻辑（简化）
if (提交线程 == 主线程 && 
    目标队列空闲 && 
    目标队列未绑定其他线程) {
    // 直接在当前线程（主线程）执行任务
    _dispatch_sync_function_invoke(dq, ctxt, func);
}

条件分解：

1. 提交线程是主线程
2. 自定义串行队列处于空闲状态（无正在执行的任务）
3. 队列未绑定到特定线程（默认状态）

---

二、技术原理深度分析

1. 队列状态检测（__DISPATCH_WAIT_FOR_QUEUE__）

当调用 dispatch_sync 时，GCD 会检查队列状态：

// queue.c
uint64_t dq_state = _dispatch_wait_prepare(dq);
if (unlikely(!dq->do_targetq && 
             !_dq_state_is_enqueued(dq_state) && 
             !_dq_state_has_waiter(dq_state))) {
    // 直接执行路径
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

• do_targetq == NULL：表示是终端队列（无层级）
• !_dq_state_is_enqueued：队列无等待任务
• !_dq_state_has_waiter：无线程正在等待队列

2. 线程绑定机制

自定义串行队列默认不绑定线程：

struct dispatch_queue_s {
    // ...
    uint16_t dq_is_thread_bound:1; // =0 表示未绑定
    pthread_t dq_thread;           // =NULL
};

• 当队列首次被执行时，GCD 会临时绑定到执行线程
• 绑定在任务完成后自动解除

GCD队列中 !dq->do_targetq 条件的深度解析

比如_dispatch_sync_f_slow中在判断!dq->do_targetq时，即如果参数中的队列是全局并发队列或者未绑定到dispatch线程的队列会直接在当前线程上执行

在 GCD 的底层实现中，!dq->do_targetq 是一个关键条件判断，它表示当前队列没有目标队列(target queue) 。这种状态在特定类型的队列中会出现，下面是全面解析：

一、do_targetq 的作用与意义

1. 队列层级结构

struct dispatch_queue_s {
    dispatch_queue_t do_targetq; // 指向目标队列的指针
    // ...其他字段...
};

• 目标队列(target queue) ：GCD 队列的核心设计，形成队列层级：

  • 自定义队列 → 全局队列 → 线程池
  • 队列的任务最终会转发到其目标队列执行

• 层级示例：

2. !dq->do_targetq 的含义

• 终端队列(Terminal Queue) ：队列层级的最底层
• 直接执行者：任务不再转发，由该队列直接处理
• 线程关联：队列直接绑定线程资源

二、出现 !dq->do_targetq 的三种队列类型

1. 全局并发队列(Global Concurrent Queues)

// 全局队列初始化
static void _dispatch_root_queue_init(dispatch_queue_global_t dq) {
    dq->do_targetq = NULL; // 明确设置为NULL
}

• 特征：

  • dispatch_get_global_queue() 获取的队列
  • 直接对接线程池，无上层队列

• 验证代码：

  let globalQueue = DispatchQueue.global()
  print(globalQueue.target === nil) // true
  

2. 主队列(Main Queue)

// 主队列初始化 (queue_internal.h)
DISPATCH_DECL_SUBCLASS(main_queue, lane);
struct dispatch_main_queue_s {
    DISPATCH_QUEUE_CLASS_HEADER(main_queue);
    // 隐含 do_targetq = NULL
};

• 特征：

  • dispatch_get_main_queue()
  • 直接绑定主线程，无目标队列

• 特殊行为：

  • 通过 mach port 与主线程 RunLoop 通信
  • 任务直接在主线程执行

3. 管理队列(Management Queues)

// 管理队列定义 (init.c)
static struct dispatch_queue_global_s _dispatch_mgr_q = {
    .do_targetq = NULL, // 无目标队列
    .dq_label = "com.apple.root.management-qos"
};

• 类型：

  • com.apple.root.management-qos
  • com.apple.root.management-overcommit-qos

• 作用：

  • 处理 GCD 内部任务（定时器、事件源）
  • 常驻线程执行系统级管理

三、技术原理深度分析

1. 队列状态机

当 !dq->do_targetq 时，队列进入终端状态：

2. 任务执行路径差异

void dx_push(dispatch_queue_t dq, dispatch_object_t dou) {
    if (dq->do_targetq) {
        // 转发到目标队列
        _dispatch_queue_push(dq->do_targetq, dou);
    } else {
        // 终端队列直接处理
        _dispatch_root_queue_push(dq, dou);
    }
}

3. 线程绑定机制

// 终端队列的线程绑定
if (!dq->do_targetq) {
    if (dq == &_dispatch_main_q) {
        bind_to_main_thread(); // 主队列绑主线程
    } else {
        bind_to_workqueue(); // 全局队列绑线程池
    }
}

四、实际场景验证

场景1：全局队列的任务执行

let globalQueue = DispatchQueue.global()
globalQueue.async {
    // 执行在随机工作线程
    print(Thread.current.name) // com.apple.root.default-qos
}

• 路径：全局队列（无targetq）→ 线程池直接执行

场景2：自定义队列的层级

let customQueue = DispatchQueue(label: "com.example", 
                              target: .global())
print(customQueue.target === nil) // false

• 路径：自定义队列 → 全局队列（targetq）→ 线程池

场景3：主队列特殊处理

DispatchQueue.main.async {
    print("Always on main thread")
}

• 路径：主队列（无targetq）→ mach port → 主线程RunLoop

五、性能影响与优化

1. 终端队列的优势

指标	有targetq队列	终端队列
任务延迟	多级转发(>200ns)	直接执行(~50ns)
内存占用	额外队列结构	无额外开销
线程切换	可能多次切换	最少切换

2. 使用建议

// 优先使用全局队列（终端队列）
DispatchQueue.global().async { /* 高性能任务 */ }

// 需要主线程时直接使用主队列
DispatchQueue.main.async { /* UI更新 */ }

// 避免不必要的中间队列
let redundantQueue = DispatchQueue(label: "unnecessary") 
// 增加转发开销

六、底层调试技巧

1. 检查队列层级

// 私有API调试（lldb）
(lldb) po [dispatchQueue _dispatchQueue]
// 输出中包含 "targetq = 0x0" 表示终端队列

2. 符号断点跟踪

# 跟踪任务入队路径
breakpoint set -n dx_push
breakpoint set -n _dispatch_root_queue_push

3. 性能分析

// 测量任务执行路径
CFAbsoluteTime start = CFAbsoluteTimeGetCurrent();
dispatch_sync(queue, ^{ /* 任务 */ });
CFTimeInterval elapsed = (CFAbsoluteTimeGetCurrent() - start) * 1000000; // 微秒
NSLog(@"执行耗时: %.2f μs", elapsed);

总结

!dq->do_targetq 是 GCD 中标识终端队列的关键条件：

1. 三种队列类型：

   • 全局并发队列
   • 主队列
   • 管理队列

2. 技术优势：

   • 直接对接执行资源（线程池/主线程）
   • 减少任务转发开销
   • 优化执行延迟

3. 设计哲学：

   • 终端队列作为调度系统的"叶节点"
   • 普通队列作为可组合的"中间节点"

理解这一机制有助于：

• 优化高性能并发代码
• 避免不必要的队列层级
• 深入调试 GCD 行为

_dispatch_sync_f_inline 源码深度解析

_dispatch_sync_f_inline 是 GCD 中 dispatch_sync 的快速路径（Fast Path） 实现，负责处理可以直接执行任务而不需要线程切换的优化场景。以下是基于 libdispatch 1271 版本的完整源码解析：

函数签名与位置

// queue_internal.h
static inline void
_dispatch_sync_f_inline(
    dispatch_queue_class_t dqu,   // 目标队列
    void *ctxt,                   // 任务上下文
    dispatch_function_t func,     // 任务函数
    uintptr_t dc_flags            // 标志位
)

---

源码逐段解析

1. 队列类型检查

dispatch_queue_t dq = dqu._dq;

// 检查是否是全局队列或主队列
if (unlikely(!dq->do_targetq)) {
    if (unlikely(dq == &_dispatch_main_q)) {
        // 主队列的特殊处理
        return _dispatch_sync_f_slow(dq, ctxt, func, 0, dq, dc_flags);
    }
    // 全局队列的快速路径
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

关键点：

• !dq->do_targetq 标识终端队列（全局队列/主队列）
• 主队列强制走慢速路径（避免死锁风险）
• 全局队列直接调用 _dispatch_sync_function_invoke

---

2. 快速路径条件检测

// 获取队列状态
uint64_t dq_state = _dispatch_wait_prepare(dq);

// 检查是否可直接执行
if (likely(_dq_state_drain_locked_by(dq_state, 0) &&
    !_dq_state_is_suspended(dq_state) &&
    _dq_state_is_base_wlh(dq_state)) 
{
    // 直接执行路径
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

条件分解：

1. _dq_state_drain_locked_by(dq_state, 0)

   • 队列未被任何线程锁定（空闲状态）

2. !_dq_state_is_suspended(dq_state)

   • 队列未被挂起（可执行状态）

3. _dq_state_is_base_wlh(dq_state)

   • 队列是基础等待句柄类型（可安全执行）

---

3. 线程绑定检查

// 检查队列是否绑定到当前线程
pthread_priority_t pp = _dispatch_get_priority();
if (likely(_dq_state_drain_locked_by(dq_state, _dispatch_tid_self()))) {
    // 当前线程已持有队列锁
    return _dispatch_sync_function_invoke(dq, ctxt, func);
}

场景分析：

• 当自定义串行队列已绑定到当前线程时
• 可安全直接执行（无线程切换开销）
• 例如：队列A → 同步执行 → 再次同步提交到队列A

---

4. 慢速路径回退

// 不满足快速路径条件时进入慢速路径
return _dispatch_sync_f_slow(
    dq,          // 目标队列
    ctxt,        // 上下文
    func,        // 任务函数
    0,           // 顶层队列标志
    dqu,         // 队列类
    dc_flags     // 标志位
);

触发条件：

1. 队列被其他线程锁定
2. 队列被挂起
3. 队列类型不支持直接执行
4. 死锁风险（如主队列同步提交）

---

关键子函数解析

1. _dispatch_sync_function_invoke

static void
_dispatch_sync_function_invoke(
    dispatch_queue_t dq, 
    void *ctxt, 
    dispatch_function_t func
) {
    // 1. 执行前准备
    _dispatch_thread_frame_push(dq);
    _dispatch_introspection_sync_begin(dq);
    
    // 2. 执行任务函数
    func(ctxt);
    
    // 3. 执行后清理
    _dispatch_introspection_sync_end(dq);
    _dispatch_thread_frame_pop(dq);
}

核心作用：

• 在当前线程直接执行任务
• 维护线程帧状态（用于调试和异常处理）
• 集成 Introspection 调试支持

---

2. _dispatch_wait_prepare

static inline uint64_t
_dispatch_wait_prepare(dispatch_queue_t dq)
{
    // 原子加载队列状态
    uint64_t dq_state = os_atomic_load2o(dq, dq_state, acquire);
    
    // 检查死锁风险
    if (unlikely(_dq_state_drain_locked_by(dq_state, _dispatch_tid_self()))) {
        DISPATCH_CLIENT_CRASH(dq_state, "dispatch_sync deadlock");
    }
    return dq_state;
}

关键机制：

• 原子操作：安全读取队列状态
• 死锁检测：当前线程已持有时立即崩溃

---

快速路径触发场景

1. 全局队列同步提交

// 全局队列直接执行
dispatch_sync(DispatchQueue.global()) {
    print("Execute on:", Thread.current) // 当前线程执行
}

执行路径：

1. !dq->do_targetq → 全局队列
2. _dispatch_sync_f_inline → _dispatch_sync_function_invoke

2. 空闲串行队列

let serialQueue = DispatchQueue(label: "com.example.idle")
Thread.sleep(0.1) // 确保队列空闲

// 满足快速路径条件
dispatch_sync(serialQueue) {
    print("Direct execution") // 当前线程执行
}

3. 已绑定线程的队列

let boundQueue = DispatchQueue(label: "com.example.bound")
boundQueue.async {
    // 常驻线程中同步提交
    dispatch_sync(boundQueue) {
        print("Executed on bound thread")
    }
}

---

性能优化分析

快速路径 vs 慢速路径

指标	快速路径	慢速路径
执行时间	50-100 ns	1-5 μs
线程切换	无	可能发生
内存分配	无额外分配	需创建同步上下文
适用场景	空闲队列/全局队列	繁忙队列/主队列

优化效果验证

// 快速路径执行统计
if (_dispatch_sync_f_inline_used) {
    _dispatch_perfmon_inc(DISPATCH_PERFMON_SYNC_FASTPATH);
}

• libdispatch 内部统计显示，80%+ 的 dispatch_sync 调用走快速路径

---

设计哲学总结

1. 零开销原则

   • 在安全条件下最大限度避免线程切换

   if (can_execute_directly) {
       run_task_now(); // 理想情况
   }
   

2. 层级化决策

1. 安全边界

   • 主队列强制慢速路径（死锁预防）
   • 原子状态检测保证线程安全

通过这种设计，GCD 在保证线程安全的前提下，为高频同步操作提供接近函数直接调用的性能。

_dispatch_barrier_sync_f_inline 源码深度解析

**static** **inline** **void******
_dispatch_barrier_sync_f_inline(dispatch_queue_t dq, **void** *ctxt,
    dispatch_function_t func, uintptr_t dc_flags)
{
    dispatch_tid tid = _dispatch_tid_self();

    **if** (unlikely(dx_metatype(dq) != _DISPATCH_LANE_TYPE)) {
        DISPATCH_CLIENT_CRASH(0, "Queue type doesn't support dispatch_sync");
    }

    dispatch_lane_t dl = upcast(dq)._dl;
    // The more correct thing to do would be to merge the qos of the thread
    // that just acquired the barrier lock into the queue state.
    //
    // However this is too expensive for the fast path, so skip doing it.
    // The chosen tradeoff is that if an enqueue on a lower priority thread
    // contends with this fast path, this thread may receive a useless override.
    //
    // Global concurrent queues and queues bound to non-dispatch threads
    // always fall into the slow case, see DISPATCH_ROOT_QUEUE_STATE_INIT_VALUE
    **if** (unlikely(!_dispatch_queue_try_acquire_barrier_sync(dl, tid))) {
        **return** _dispatch_sync_f_slow(dl, ctxt, func, DC_FLAG_BARRIER, dl,
    DC_FLAG_BARRIER | dc_flags);
    }

    **if** (unlikely(dl->do_targetq->do_targetq)) {
        **return** _dispatch_sync_recurse(dl, ctxt, func,DC_FLAG_BARRIER | dc_flags);
    }

    _dispatch_introspection_sync_begin(dl);
    _dispatch_lane_barrier_sync_invoke_and_complete(dl, ctxt, func
    DISPATCH_TRACE_ARG(_dispatch_trace_item_sync_push_pop(
    dq, ctxt, func, dc_flags | DC_FLAG_BARRIER)));
}

这是 GCD 中同步屏障（barrier sync）的核心实现，用于在并发队列上创建同步执行点。以下是逐行分析：

static inline void
_dispatch_barrier_sync_f_inline(dispatch_queue_t dq, void *ctxt,
        dispatch_function_t func, uintptr_t dc_flags)
{
    // 获取当前线程 ID（用于所有权跟踪）
    dispatch_tid tid = _dispatch_tid_self();

    // 1. 队列类型安全检查
    if (unlikely(dx_metatype(dq) != _DISPATCH_LANE_TYPE)) {
        DISPATCH_CLIENT_CRASH(0, "Queue type doesn't support dispatch_sync");
    }

关键组件解析

1. 队列类型验证

if (unlikely(dx_metatype(dq) != _DISPATCH_LANE_TYPE)) 

• 安全机制：确认队列支持屏障操作

• 崩溃条件：

  • 全局队列（DISPATCH_QUEUE_GLOBAL_ROOT_TYPE）
  • 主队列（DISPATCH_QUEUE_MAIN）
  • 其他非并发队列类型

• 设计意图：屏障只适用于自定义并发队列

---

    // 2. 转换为通道类型
    dispatch_lane_t dl = upcast(dq)._dl;
    
    // 3. 尝试快速获取屏障锁
    if (unlikely(!_dispatch_queue_try_acquire_barrier_sync(dl, tid))) {
        return _dispatch_sync_f_slow(dl, ctxt, func, DC_FLAG_BARRIER, dl,
                DC_FLAG_BARRIER | dc_flags);
    }

2. 通道类型转换

dispatch_lane_t dl = upcast(dq)._dl;

• upcast 宏：安全转换到内部通道类型
• dispatch_lane_t：实际执行屏障操作的底层结构

3. 快速路径：尝试获取屏障锁

_dispatch_queue_try_acquire_barrier_sync(dl, tid)

• 原子操作：使用 os_atomic_cmpxchg 尝试获取锁

• 成功条件：

  1. 队列未锁定 (DLOCK_STATE_LOCKED 未设置)
  2. 无挂起任务 (DLOCK_STATE_DRAINED)

• 性能优化：避免进入慢速路径

快速路径失败处理

_dispatch_sync_f_slow(dl, ctxt, func, DC_FLAG_BARRIER, dl, DC_FLAG_BARRIER | dc_flags);

• 慢速路径场景：

  • 队列已被锁定
  • 有待处理任务
  • 队列被暂停

• 处理逻辑：

  1. 将任务加入等待队列
  2. 阻塞当前线程
  3. 任务完成时唤醒

---

    // 4. 处理队列层级结构
    if (unlikely(dl->do_targetq->do_targetq)) {
        return _dispatch_sync_recurse(dl, ctxt, func,
                DC_FLAG_BARRIER | dc_flags);
    }

4. 队列层级处理

if (unlikely(dl->do_targetq->do_targetq))

• 场景：队列有多个层级（如自定义队列目标为全局队列）

• 处理函数：_dispatch_sync_recurse

• 递归逻辑： void _dispatch_sync_recurse(dispatch_lane_t lane, ...) { // 获取实际目标队列 dispatch_queue_t tq = lane->do_targetq;

      // 递归提交到最终队列
      _dispatch_barrier_sync_f(tq, ctxt, func, flags);
  }
  

• 设计目的：确保屏障作用于最终执行队列

---

    // 5. 执行屏障任务
    _dispatch_introspection_sync_begin(dl);
    _dispatch_lane_barrier_sync_invoke_and_complete(dl, ctxt, func
            DISPATCH_TRACE_ARG(_dispatch_trace_item_sync_push_pop(
                    dq, ctxt, func, dc_flags | DC_FLAG_BARRIER)));
}

5. 屏障任务执行

调试支持

_dispatch_introspection_sync_begin(dl);

• 作用：通知调试器同步操作开始
• 实现：记录线程状态和时间戳

核心执行函数

_dispatch_lane_barrier_sync_invoke_and_complete(dl, ctxt, func, ...)

• 执行流程： void _dispatch_lane_barrier_sync_invoke_and_complete(...) { // 执行任务 func(ctxt);

      // 释放屏障锁
      _dispatch_lane_non_barrier_complete(dl, 0);
      
      // 唤醒等待任务
      _dispatch_lane_wakeup(dl, 0, DISPATCH_WAKEUP_BARRIER_COMPLETE);
  }
  

• 屏障语义：

  1. 阻塞所有后续任务
  2. 允许之前任务完成
  3. 独占执行当前任务
  4. 完成后恢复并发执行

追踪支持

_dispatch_trace_item_sync_push_pop(...)

• 作用：记录屏障生命周期事件
• 输出：Instruments 中可见的屏障跟踪点

---

设计原理分析

1. 屏障同步状态机

2. 优先级处理策略

// 优先级继承实现（简化版）
void _dispatch_lane_barrier_sync_invoke(...) {
    // 保存当前QoS
    qos_t old_qos = _dispatch_get_qos();
    
    // 提升到队列最高QoS
    qos_t max_qos = _dispatch_queue_max_qos(dl);
    _dispatch_thread_override_start(max_qos);
    
    // 执行任务
    func(ctxt);
    
    // 恢复原始QoS
    _dispatch_thread_override_end(old_qos);
}

• 关键点：屏障执行时继承队列最高 QoS
• 目的：防止优先级反转

3. 与普通同步的区别

特性	普通 dispatch_sync	屏障 dispatch_barrier_sync
队列类型支持	所有队列	仅自定义并发队列
并发控制	无特殊控制	创建独占执行点
性能开销	低	中（需等待前置任务）
使用场景	简单同步	数据竞争保护
内部锁机制	轻量锁	屏障专用锁
优先级处理	继承当前线程	提升到队列最高

4. 死锁防护机制

// 死锁检测伪代码
if (dl->dq_state & DLOCK_OWNER_MASK == tid) {
    // 相同线程重入屏障
    _dispatch_sync_f_slow_deadlock(dl);
}

• 检测场景：同一线程递归调用屏障同步
• 处理方式：强制崩溃并生成诊断报告

---

典型使用场景

1. 线程安全数据结构

@interface ThreadSafeDictionary : NSObject
@property (nonatomic) NSMutableDictionary *storage;
@property (nonatomic) dispatch_queue_t queue;
@end

@implementation ThreadSafeDictionary
- (instancetype)init {
    self = [super init];
    _storage = [NSMutableDictionary new];
    _queue = dispatch_queue_create("com.dict.queue", DISPATCH_QUEUE_CONCURRENT);
    return self;
}

- (void)setObject:(id)obj forKey:(id)key {
    dispatch_barrier_sync(self.queue, ^{
        [self.storage setObject:obj forKey:key];
    });
}

- (id)objectForKey:(id)key {
    __block id result;
    dispatch_sync(self.queue, ^{
        result = [self.storage objectForKey:key];
    });
    return result;
}
@end

2. 资源初始化保护

static dispatch_once_t token;
static id sharedInstance;

id GetSharedInstance() {
    dispatch_barrier_sync(concurrentQueue, ^{
        if (!sharedInstance) {
            sharedInstance = create_instance();
        }
    });
    return sharedInstance;
}

---

性能优化点

1. 快速路径优化：

   • 使用 unlikely 提示编译器优化分支预测
   • 原子操作替代锁获取

2. 免锁执行： if (dl->dq_items_head == NULL && (dl->dq_state & DLOCK_STATE_DRAINED)) { // 直接执行无需入队 }

3. 线程局部缓存： if (_dispatch_queue_has_thread_cache(dl)) { return _dispatch_sync_invoke_and_complete(dl, ctxt, func); }

4. 屏障任务内联：

   • 直接调用 func(ctxt) 避免函数指针开销
   • 与上下文共同优化寄存器分配

---

总结

_dispatch_barrier_sync_f_inline 实现了 GCD 的同步屏障机制：

1. 安全验证：确保队列支持屏障操作
2. 快速路径：尝试原子获取屏障锁直接执行
3. 慢速路径：队列繁忙时阻塞等待
4. 层级处理：递归处理队列层级结构
5. 任务执行：在独占上下文中执行任务
6. 状态恢复：释放锁并唤醒等待任务

通过精心设计的快速路径和原子操作，在保证数据一致性的同时，最小化了同步屏障的性能开销，使开发者能在并发编程中安全高效地管理共享资源。

_dispatch_queue_try_reserve_sync_width源码解析

我们正在解析 _dispatch_queue_try_reserve_sync_width 函数，该函数在 libdispatch 的 queue.c 文件中，用于在同步提交任务时尝试保留队列的同步宽度（即队列的并发能力）。这个函数在同步提交任务到并发队列时被调用，目的是在不阻塞的情况下尝试获取一个执行槽位（slot），如果成功，则任务可以立即执行，否则需要走慢速路径（如阻塞等待）。函数签名：static bool_dispatch_queue_try_reserve_sync_width(dispatch_queue_class_t dqu)参数：dqu: 目标队列（封装了 dispatch_queue_t 或 dispatch_lane_t）返回值：bool: 如果成功保留一个同步宽度（即获取到一个执行槽位），则返回 true；否则返回 false。该函数主要用于并发队列（宽度大于1）的同步提交优化。在并发队列中，多个任务可以同时执行，但同步提交的任务需要独占一个执行槽位直到任务完成。函数通过原子操作来减少队列的可用宽度（即减少一个槽位），如果减少成功（即原子操作成功），则任务可以立即执行。下面是该函数的源码解析（基于 libdispatch 1271 版本）：

_dispatch_queue_try_reserve_sync_width 源码深度解析

_dispatch_queue_try_reserve_sync_width 是 GCD 中用于并发队列同步宽度管理的关键函数，负责在同步提交任务时尝试"预订"队列的执行槽位。以下是基于 libdispatch 1271 版本的完整源码解析：

函数签名与作用

static bool
_dispatch_queue_try_reserve_sync_width(
    dispatch_queue_class_t dqu  // 目标队列（封装类）
)

核心功能：

1. 尝试为同步任务预留并发执行槽位
2. 管理队列的"同步宽度"资源
3. 决定任务是否可立即执行或需要等待

---

源码逐段解析

1. 队列类型检查

c

复制

下载

dispatch_queue_t dq = dqu._dq;

// 仅适用于并发队列
if (unlikely(dq->dq_width == 1)) {
    // 串行队列无需宽度管理
    return true;
}

关键点：

• 串行队列（dq_width=1）直接返回成功
• 仅并发队列（dq_width > 1）需要同步宽度管理

---

2. 原子状态操作

c

复制

下载

// 加载当前队列状态
uint64_t old_state, new_state;
uint64_t dq_state = os_atomic_load2o(dq, dq_state, acquire);

do {
    // 计算当前可用同步宽度
    uint64_t sync_width = _dq_state_sync_width(dq_state);
    
    // 检查是否可预订槽位
    if (sync_width == 0) {
        // 无可用槽位
        return false;
    }
    
    // 尝试减少可用宽度
    new_state = dq_state - DISPATCH_QUEUE_SYNC_WIDTH_INTERVAL;
    old_state = dq_state;
} while (!os_atomic_cmpxchgv2o(dq, dq_state, 
                              old_state, new_state, &dq_state, acquire));

同步宽度机制：

• DISPATCH_QUEUE_SYNC_WIDTH_INTERVAL = 0x1000000

• 状态位布局：

  c

  复制

  下载

  | 63       32 | 31       24 | 23        0 |
  | 保留字段     | 异步计数    | 同步宽度     |  // dq_state
  

• 每次预订减少 0x1000000 相当于同步宽度减1

---

3. 宽度限制检查

c

复制

下载

// 获取最大同步宽度限制
uint16_t max_sync = _dispatch_queue_max_sync_width(dq);

// 检查是否超过限制
if (_dq_state_sync_width(new_state) > max_sync) {
    // 超过限制则回滚操作
    os_atomic_add2o(dq, dq_state, DISPATCH_QUEUE_SYNC_WIDTH_INTERVAL, relaxed);
    return false;
}

动态宽度计算：

c

复制

下载

static inline uint16_t
_dispatch_queue_max_sync_width(dispatch_queue_t dq) {
    // 基础宽度 = 队列并发能力 - 1（保留给异步任务）
    uint16_t width = dq->dq_width - 1;
    
    // 根据系统负载动态调整
    if (_dispatch_is_multiprocessor()) {
        return width * 2;  // 多核设备增加配额
    }
    return width;
}

---

4. 预订成功处理

c

复制

下载

// 成功预订后更新队列属性
if (_dq_state_sync_width(new_state) == 0) {
    // 同步宽度耗尽时标记队列
    _dispatch_set_basepri_override_qos_for_sync(dq, new_state);
}

return true;  // 预订成功

---

技术原理图解

同步宽度状态机

位域操作原理

c

复制

下载

// 同步宽度提取宏
#define _dq_state_sync_width(state) \
    ((uint16_t)((state) / DISPATCH_QUEUE_SYNC_WIDTH_INTERVAL))

// 状态更新示例
初始状态: 0x3000000  // 同步宽度=3
预订后:   0x2000000  // 同步宽度=2

---

使用场景分析

1. 快速路径提交

// dispatch_sync 中的快速路径检查
if (_dispatch_queue_try_reserve_sync_width(dq)) {
    // 宽度预订成功 → 直接执行任务
    _dispatch_sync_function_invoke(dq, ctxt, func);
} else {
    // 进入慢速路径
    _dispatch_sync_f_slow(...);
}

2. 并发控制场景

假设并发队列宽度=4：

let concurrentQueue = DispatchQueue(label: "com.example", attributes: .concurrent)

// 同时提交4个同步任务
for i in 0..<4 {
    concurrentQueue.sync {
        print("Task (i) started")
        Thread.sleep(1)
    }
}

// 第5个任务触发宽度耗尽
concurrentQueue.sync {
    print("This will wait") // 阻塞直到宽度释放
}

---

性能优化分析

原子操作优化

// 使用CMPSWP指令的无锁实现
while (!os_atomic_cmpxchgv2o(dq, dq_state, old_state, new_state, &dq_state, acquire));

• 避免互斥锁开销（约节省 20-50ns）
• 支持高并发场景下的争用管理

动态宽度调整

系统状态	最大同步宽度	行为
单核 CPU	dq_width - 1	严格限制同步任务占比
多核 CPU	(dq_width - 1) * 2	提高同步任务配额
低电量模式	dq_width / 2	减少资源争用

---

与屏障操作的交互

屏障期间的宽度管理

// 屏障执行时冻结同步宽度
if (_dq_state_has_barrier(dq_state)) {
    // 屏障活跃时不接受新同步预订
    return false;
}

屏障与同步宽度关系

错误处理与边界条件

1. 宽度泄漏检测

// 任务完成后必须释放宽度
void _dispatch_sync_complete_recurse(...) {
    // 释放预订的同步宽度
    os_atomic_add2o(dq, dq_state, DISPATCH_QUEUE_SYNC_WIDTH_INTERVAL, relaxed);
}

• 未释放会导致队列永久性宽度减少

2. 递归预订保护

if (_dq_state_drain_locked_by(dq_state, tid)) {
    // 当前线程已持有队列锁 → 允许递归预订
    return true;
}

3. 溢出保护

// 检查减法溢出
if (new_state > old_state) {
    DISPATCH_CLIENT_CRASH(old_state, "Sync width underflow");
}

---

设计哲学总结

1. 资源配额化
   将队列并发能力量化为可管理的"同步宽度"资源
2. 无锁优先
   使用原子操作而非互斥锁管理状态变更
3. 动态适应
   根据硬件能力和系统状态调整配额策略
4. 层级化控制

通过这种机制，GCD 在保证并发队列同步操作语义的同时，实现了高效的资源管理和任务调度，避免了同步任务过度消耗队列资源导致的性能下降。

GCD 串行队列串行执行保证机制深度剖析

GCD 通过精妙的状态管理和线程绑定机制保证串行队列（Serial Queue）的任务严格按 FIFO 顺序执行。以下是基于 libdispatch 源码的完整机制解析：

一、核心数据结构设计

1. 串行队列结构（dispatch_queue_s）

struct dispatch_queue_s {
    // 公共头部
    struct dispatch_object_s _as_do[0];
    
    // 串行性关键字段
    uint16_t dq_width;         // =1 (串行队列标志)
    struct dispatch_object_s *volatile dq_items_head; // 任务链表头
    struct dispatch_object_s *volatile dq_items_tail; // 任务链表尾
    
    // 状态管理
    uint64_t volatile dq_state; // 状态位掩码
    pthread_t dq_thread;        // 绑定线程指针
};

2. 状态位掩码（dq_state）

| 63-32         | 31-24       | 23-0          |
|---------------|-------------|---------------|
| 保留字段       | 挂起计数     | 活跃任务计数   |

• 活跃任务计数：0=空闲，1=任务执行中
• 挂起计数：>0 表示队列被挂起

---

二、任务提交处理流程

1. 任务入队（dx_push）

void dx_push(dispatch_queue_t dq, dispatch_object_t dou) {
    // 原子操作将任务添加到链表尾部
    _dispatch_queue_push_list(dq, dou._do, dou._do);
    
    // 检查是否需要唤醒队列
    if (os_atomic_load2o(dq, dq_items_head, acquire) == dou._do) {
        _dispatch_queue_wakeup(dq); // 唤醒队列执行
    }
}

链表操作保证顺序：

三、串行执行保障机制

1. 线程绑定与独占

static void _dispatch_lane_drain(dispatch_lane_t dq) {
    // 原子操作设置活跃状态
    uint64_t old_state = os_atomic_xchg2o(dq, dq_state, 
        DISPATCH_QUEUE_ACTIVE | DISPATCH_QUEUE_DRAIN_ACTIVE, acquire);
        
    // 绑定当前线程
    dq->dq_thread = pthread_self();
    
    // 任务处理循环
    while ((item = _dispatch_lane_pop_head(dq))) {
        _dispatch_continuation_invoke(item); // 执行任务
    }
    
    // 解绑线程
    dq->dq_thread = NULL;
}

关键操作：

1. 通过 os_atomic_xchg 原子设置活跃状态
2. 执行期间绑定当前线程到队列
3. 循环从链表头部取任务执行

2. 状态机保障

3. 同步提交死锁防护

void _dispatch_sync_f_inline(dispatch_queue_t dq, ...) {
    uint64_t dq_state = _dispatch_wait_prepare(dq);
    
    // 死锁检测：当前线程是否已持有队列
    if (unlikely(_dq_state_drain_locked_by(dq_state, tid))) {
        DISPATCH_CLIENT_CRASH(dq_state, "dispatch_sync deadlock");
    }
}

---

四、线程管理机制

1. 线程唤醒策略

void _dispatch_queue_wakeup(dispatch_queue_t dq) {
    if (dq->dq_thread) {
        // 已绑定线程：发送信号唤醒
        _dispatch_thread_event_signal(&dq->dsc_event);
    } else {
        // 未绑定：从线程池获取线程
        _dispatch_worker_thread2(dq);
    }
}

2. 线程绑定生命周期

五、关键源码函数解析

1. 任务提取（_dispatch_lane_pop_head）

static inline dispatch_object_t 
_dispatch_lane_pop_head(dispatch_lane_t dq)
{
    // 原子操作获取链表头
    dispatch_object_t head = os_atomic_load2o(dq, dq_items_head, acquire);
    
    if (!head) return NULL; // 队列空
    
    // 更新链表头
    dispatch_object_t next = head->do_next;
    os_atomic_store2o(dq, dq_items_head, next, relaxed);
    
    if (!next) {
        // 链表清空时重置尾部
        os_atomic_store2o(dq, dq_items_tail, NULL, relaxed);
    }
    
    return head;
}

原子操作保证：

• 多线程环境下安全操作链表
• 避免任务被重复提取

2. 状态检测（_dispatch_wait_prepare）

static inline uint64_t 
_dispatch_wait_prepare(dispatch_queue_t dq)
{
    uint64_t dq_state = os_atomic_load2o(dq, dq_state, acquire);
    
    // 检测死锁：当前线程是否持有队列
    pthread_t tid = _dispatch_tid_self();
    if (unlikely(_dq_state_drain_locked_by(dq_state, tid))) {
        DISPATCH_CLIENT_CRASH(dq_state, "Resource deadlock");
    }
    
    return dq_state;
}

---

六、执行流程全链路

七、性能优化设计

1. 快速路径优化

// 空闲队列直接执行
if (os_atomic_load2o(dq, dq_items_head, relaxed) == NULL) {
    _dispatch_sync_function_invoke(dq, ctxt, func);
    return;
}

2. 线程缓存

// 线程执行完成后缓存
void _dispatch_worker_thread2(void *context) {
    while (1) {
        // ...执行任务...
        
        if (idle_time > TIMEOUT) {
            _dispatch_thread_cache_add(thread); // 缓存线程
            break;
        }
    }
}

3. 优先级继承

void _dispatch_continuation_invoke(dispatch_continuation_t dc) {
    pthread_priority_t orig = pthread_get_priority();
    pthread_set_priority(dc->dc_priority); // 提升至任务QoS
    dc->dc_func(dc->dc_ctxt);
    pthread_set_priority(orig); // 恢复
}

---

八、特殊场景处理

1. 队列挂起（dispatch_suspend）

void dispatch_suspend(dispatch_queue_t dq) {
    // 原子增加挂起计数
    os_atomic_inc2o(dq, dq_suspension_cnt, relaxed);
    
    // 设置挂起状态位
    uint64_t old_state = os_atomic_or2o(dq, dq_state, 
        DISPATCH_QUEUE_SUSPENDED, acquire);
}

效果：

• 新任务加入链表但不执行
• 已执行任务继续完成

2. 队列恢复（dispatch_resume）

void dispatch_resume(dispatch_queue_t dq) {
    // 原子减少挂起计数
    if (os_atomic_dec2o(dq, dq_suspension_cnt, relaxed) == 0) {
        // 清除挂起状态
        os_atomic_and2o(dq, dq_state, ~DISPATCH_QUEUE_SUSPENDED, relaxed);
        
        // 唤醒队列执行
        if (os_atomic_load2o(dq, dq_items_head, acquire)) {
            _dispatch_queue_wakeup(dq);
        }
    }
}

---

九、设计哲学总结

1. 原子状态机
   通过 dq_state 位掩码管理队列生命周期状态： #define DISPATCH_QUEUE_IDLE 0x0000 #define DISPATCH_QUEUE_ACTIVE 0x0001 #define DISPATCH_QUEUE_SUSPENDED 0x0100

2. 线程绑定保证串行

1. 无锁链表操作 // 线程安全的链表操作 os_atomic_store2o(dq, dq_items_tail, tail, release); if (os_atomic_xchg2o(dq, dq_items_head, head, release) == NULL) { _dispatch_queue_wakeup(dq); }

2. 层级化异常处理

   • 死锁检测：同步提交到当前队列
   • 状态校验：挂起/活跃状态冲突
   • 线程安全：原子操作全覆盖

GCD 通过这种严谨的设计，在保证串行语义的前提下实现了高性能的任务调度，单队列任务派发延迟可控制在 100ns 以内，同时完美处理数万级任务排队场景。

gcd串行队列的target队列是全局并发队列吗

在GCD中，串行队列的目标队列（target queue）默认是全局并发队列吗？我们需要从GCD的队列层级设计来理解。在GCD中，所有的队列（除了主队列和全局并发队列）都有一个目标队列。当我们创建一个串行队列时，如果没有显式指定目标队列，那么它会有一个默认的目标队列。但是，这个默认的目标队列并不是全局并发队列，而是全局并发队列中的一个，具体取决于队列的优先级（Quality of Service, QoS）。在GCD内部，队列的层级结构如下：自定义队列（串行或并发） -> 全局并发队列（根据QoS） -> 线程池当我们创建一个串行队列时，GCD会根据队列的QoS属性将其目标队列设置为相应优先级的全局并发队列。例如，如果创建队列时指定了.userInitiated，那么它的目标队列就是dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0)。但是，从iOS 8开始，GCD引入了队列层级结构的变化，不再建议直接设置目标队列，而是使用dispatch_set_target_queue来设置优先级继承链。同时，从iOS 6开始，GCD不再允许将队列的目标队列设置为串行队列（除了主队列），以避免死锁问题。因此，对于问题“串行队列的target队列是全局并发队列吗？”的答案是：默认情况下，是的。但是，我们可以通过dispatch_set_target_queue函数改变目标队列（但必须是非串行队列，通常是全局并发队列或者我们自己创建的并发队列）。下面是一个简单的验证：1. 创建一个串行队列，不指定目标队列，然后获取其目标队列。2. 比较这个目标队列和全局并发队列。注意：在GCD中，我们不能直接比较两个队列指针是否相等，因为全局队列是共享的，但是同一个优先级的全局队列是唯一的。示例代码：dispatch_queue_t serialQueue = dispatch_queue_create("com.example.serial", DISPATCH_QUEUE_SERIAL);dispatch_queue_t targetQueue = dispatch_get_target_queue(serialQueue);dispatch_queue_t globalQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);但是，dispatch_get_target_queue在iOS 6之后已经被废弃，因为苹果不希望开发者改变队列的层级结构（可能会引起问题）。在废弃之前，我们可以这样验证。现在，我们可以通过私有方法或者运行时来查看，但这不推荐。根据官方文档和GCD的实现，串行队列的目标队列默认是一个全局并发队列（与队列的优先级相对应）。总结：- 串行队列的目标队列默认是全局并发队列（根据队列的QoS选择对应的全局队列）。- 我们也可以使用dispatch_set_target_queue将目标队列设置为另一个并发队列（但不能是串行队列，主队列除外）。- 主队列的目标队列是NULL，因为它是最高级别的队列，直接在主线程执行。因此，答案是肯定的，默认情况下，串行队列的目标队列是全局并发队列。

GCD 串行队列的目标队列（Target Queue）机制详解

在 GCD 中，串行队列的目标队列（target queue）默认是全局并发队列，但开发者可以自定义目标队列。这是 GCD 队列层级设计的核心机制，下面从源码层面全面解析：

一、目标队列的默认设置

1. 创建串行队列时的默认行为

// queue.c
dispatch_queue_t dispatch_queue_create(const char *label, dispatch_queue_attr_t attr) {
    // 创建队列对象
    dispatch_queue_t dq = _dispatch_queue_alloc();
    
    // 设置目标队列
    dq->do_targetq = _dispatch_get_root_queue(
        qos_class, 
        overcommit ? DISPATCH_QUEUE_OVERCOMMIT : 0
    );
    
    return dq;
}

关键函数：

• _dispatch_get_root_queue()：获取全局并发队列
• 默认规则：

2. QoS 继承机制

// 根据 QoS 选择全局队列
static dispatch_queue_global_t
_dispatch_get_root_queue(dispatch_qos_t qos, bool overcommit)
{
    // QoS 映射表
    static dispatch_queue_global_t _dispatch_root_queues[] = {
        [QOS_CLASS_USER_INTERACTIVE] = &_dispatch_root_queues[0],
        [QOS_CLASS_USER_INITIATED]   = &_dispatch_root_queues[1],
        [QOS_CLASS_DEFAULT]          = &_dispatch_root_queues[2],
        [QOS_CLASS_UTILITY]          = &_dispatch_root_queues[3],
        [QOS_CLASS_BACKGROUND]       = &_dispatch_root_queues[4]
    };
    return _dispatch_root_queues[qos];
}

QoS 继承规则：

队列创建参数	目标全局队列
未指定 QoS	DISPATCH_QUEUE_PRIORITY_DEFAULT
.userInteractive	QOS_CLASS_USER_INTERACTIVE
.userInitiated	QOS_CLASS_USER_INITIATED
.utility	QOS_CLASS_UTILITY
.background	QOS_CLASS_BACKGROUND

二、目标队列的作用机制

1. 任务转发流程

void dx_push(dispatch_queue_t dq, dispatch_object_t dou) {
    if (dq->do_targetq) {
        // 转发到目标队列
        _dispatch_queue_push(dq->do_targetq, dou);
    } else {
        // 终端队列直接处理
        _dispatch_root_queue_push(dq, dou);
    }
}

层级传递示例：

2. 执行资源隔离

// 全局队列线程分配
static void _dispatch_root_queue_poke(dispatch_queue_global_t dq) {
    // 不同 QoS 队列使用独立线程池
    _pthread_workqueue_additem(dq->dgq_pwq, ...);
}

资源隔离效果：

• 高 QoS 队列（如 userInteractive）使用专用线程池
• 避免低优先级任务阻塞高优先级任务

三、自定义目标队列

1. 修改目标队列 API

void dispatch_set_target_queue(
    dispatch_object_t object,
    dispatch_queue_t targetq
) {
    // 验证目标队列类型
    if (targetq->dq_width == 1 && targetq != &_dispatch_main_q) {
        DISPATCH_CLIENT_CRASH(0, "Cannot target serial queue");
    }
    
    // 原子更新目标队列
    os_atomic_store2o(object._dq, do_targetq, targetq, relaxed);
}

限制条件：

1. 禁止将目标设为其他串行队列（主队列除外）
2. 目标队列必须是并发队列或主队列

2. 使用场景示例

// 创建目标并发队列
let targetQueue = DispatchQueue(
    label: "com.example.target", 
    attributes: .concurrent
)

// 创建串行队列并设置目标
let serialQueue = DispatchQueue(label: "com.example.serial")
serialQueue.setTarget(queue: targetQueue)

// 验证层级
print(serialQueue.target === targetQueue) // true

四、主队列的特殊性

1. 主队列的目标队列

// 主队列初始化
struct dispatch_main_queue_s {
    DISPATCH_QUEUE_CLASS_HEADER(main_queue);
    // 隐含 do_targetq = NULL
};

特殊性质：

• 唯一没有目标队列的串行队列
• 直接绑定主线程执行
• 任务通过 RunLoop 机制执行

2. 主队列作为目标队列

let serialQueue = DispatchQueue(label: "com.example.serial")
serialQueue.setTarget(queue: DispatchQueue.main)

// 执行效果
serialQueue.async {
    print(Thread.isMainThread) // true
}

注意事项：

• 所有任务将在主线程执行
• 过度使用可能导致主线程卡顿

五、目标队列的运行时影响

1. 性能特征对比

目标队列类型	任务延迟	线程切换开销	适用场景
全局并发队列 (默认)	中等	中等	通用任务
自定义并发队列	低	低	专用任务池
主队列	高	无	UI 更新

2. 层级深度限制

#define DISPATCH_QUEUE_MAX_TARGET_DEPTH 32

void _dispatch_queue_push(dispatch_queue_t dq, dispatch_object_t dou) {
    // 检查队列层级深度
    uint8_t depth = _dispatch_queue_depth(dq);
    if (depth > DISPATCH_QUEUE_MAX_TARGET_DEPTH) {
        DISPATCH_CLIENT_CRASH(depth, "Queue target depth exceeded");
    }
}

• 最大允许 32 层队列嵌套
• 防止无限递归导致栈溢出

六、最佳实践建议

1. 推荐使用模式

// 创建专用并发队列作为目标
let ioQueue = DispatchQueue(
    label: "com.example.io", 
    attributes: [.concurrent, .qosUtility]
)

// 创建串行队列组
let decodingQueue = DispatchQueue(label: "com.example.decode", target: ioQueue)
let processingQueue = DispatchQueue(label: "com.example.process", target: ioQueue)

// 共享线程池
decodingQueue.async { decodeImage() }
processingQueue.async { processData() }

2. 避免的陷阱

// 错误示例：串行队列相互嵌套
let q1 = DispatchQueue(label: "q1")
let q2 = DispatchQueue(label: "q2")
q1.setTarget(queue: q2) // 崩溃：禁止串行队列互为目标

// 错误示例：循环引用
q1.setTarget(queue: q2)
q2.setTarget(queue: q1) // 崩溃：队列层级过深

七、底层原理总结

1. 默认目标：
   串行队列默认以全局并发队列为目标队列
2. 动态绑定：

1. 执行优化：

   • QoS 继承：任务优先级沿层级传递
   • 资源隔离：不同全局队列独立线程池
   • 层级限制：最大32层防滥用

2. 设计哲学：
   "组合优于继承"的队列设计，通过目标队列实现：

   • 资源共享（线程池）
   • 优先级控制
   • 执行策略复用

gcd串行队列的目标队列是全局并发队列，gcd如何将串行队列绑定到具体某一条线程呢

嗯，用户询问了关于GCD中串行队列的目标队列问题以及GCD如何将串行队列绑定到具体线程的问题。这是一个关于iOS/macOS多线程编程底层机制的深入问题，需要我结合GCD的原理和实现细节来回答。用户可能是一位iOS开发者，正在研究GCD的底层实现机制，或者遇到了串行队列线程绑定的问题。从问题的专业性来看，用户应该对GCD有较深的理解。我看到了很多搜索结果。根据1，GCD中的串行队列（Serial Queue）是依次执行添加的任务，一个队列同一时刻只能执行一个任务。每个串行队列中的任务运行在一个由各自串行队列维护的独立线程上。3提到串行队列异步执行时会开启一条新线程，任务按顺序执行。而46则解释了串行队列的特点：任务按FIFO顺序执行，前一个任务不完成，后一个任务不会开始。对于目标队列，16提到串行队列默认的目标队列是全局并发队列。但9更详细地解释了目标队列机制：GCD的队列层级结构中，自定义串行队列的目标队列默认是全局并发队列，任务最终会转发到其目标队列执行。关于串行队列绑定线程的机制，6提到了GCD的线程绑定原理：当串行队列首次被异步提交任务时，GCD会从线程池中分配一个线程并绑定到该队列。任务执行期间，队列的dq_thread字段会记录当前绑定的线程。任务完成后，线程不会立即销毁而是保留一段时间（默认30秒）以便复用。8补充了GCD线程池的管理细节：GCD维护一个线程池，线程池中的线程可以重用。当串行队列需要执行任务时，GCD会从线程池中取出空闲线程或创建新线程（如果无可用线程），并将该线程绑定到队列。任务执行完毕后，线程会回到线程池，等待下一次分配。我还注意到7解释了串行队列与线程的关系：串行队列异步执行时只开启一个线程，任务按顺序在该线程上执行。考虑设计一个结构清晰的回答，包括串行队列的目标队列机制、线程绑定原理、绑定过程详解、线程生命周期管理以及使用场景建议。准备用表格展示串行队列在不同场景下的线程绑定行为，以及使用mermaid图表展示串行队列的任务执行流程。在关键概念处适当加粗，并在回复时使用代码块展示GCD内部结构定义。在回答末尾添加一个总结表格，对比串行队列绑定线程的关键特性。

在 GCD（Grand Central Dispatch）中，串行队列的目标队列（Target Queue）机制与线程绑定是实现任务顺序执行的核心设计。下面从目标队列的默认行为和线程绑定原理两方面深入解析：

---

一、串行队列的目标队列机制

1. 默认目标队列：全局并发队列

• 层级关系：
  自定义串行队列创建时，默认的目标队列（do_targetq）是系统全局并发队列（Global Concurrent Queue），形成以下层级：

• 任务通过队列层级转发，最终由线程池执行169。
• QoS 继承：
  串行队列的 QoS（服务质量）由创建参数决定（如 .userInitiated），并传递给目标队列，确保高优先级任务优先调度69。

2. 自定义目标队列

• 允许的类型：
  开发者可通过 dispatch_set_target_queue() 修改目标队列，但仅允许并发队列或主队列：

  • 并发队列（如自定义 DISPATCH_QUEUE_CONCURRENT）：任务由多线程并行处理。
  • 主队列（dispatch_get_main_queue()）：任务强制在主线程执行69。

• 禁止场景：
  目标队列不能设为其他串行队列（主队列除外），否则会破坏串行语义6。

---

二、串行队列绑定线程的原理

1. 绑定触发条件

当串行队列首次收到异步任务（dispatch_async）时，GCD 执行以下步骤：

1. 从线程池获取空闲线程或创建新线程。
2. 将该线程与队列的 dq_thread 字段绑定（通过 pthread_t 记录）68。
3. 任务在绑定线程中顺序执行（FIFO）。

2. 绑定状态的原子管理

• 队列状态标识：
  通过 dq_state 的 DISPATCH_QUEUE_ACTIVE 标志位标记队列活跃状态68。

• 死锁防护：
  同步提交（dispatch_sync）时检测当前线程是否已绑定队列： if (dq->dq_thread == pthread_self()) { DISPATCH_CLIENT_CRASH("Deadlock on serial queue"); }

3. 线程生命周期

• 空闲超时释放：
  线程完成任务后保留 30 秒（默认），超时后解绑并销毁68。
• 复用优化：
  若 30 秒内有新任务提交，直接复用绑定线程（避免重复创建）8。

---

三、关键流程详解

1. 任务执行流程

2. 线程绑定与解绑

场景	行为	性能影响
首次异步提交	创建新线程并绑定	开销较高（~100μs）
连续提交任务	复用已绑定线程	接近零开销（~5μs）
超时无任务	解绑线程并销毁	释放内存资源

---

四、特殊场景与优化建议

1. 主队列的例外

• 主队列（dispatch_get_main_queue()）无目标队列（do_targetq = NULL），直接绑定主线程69。
• 任务通过 RunLoop 机制执行，不依赖线程池6。

2. 性能优化建议

1. 避免频繁创建队列：
   复用串行队列以减少线程绑定/解绑开销。
2. 控制队列优先级：
   高 QoS 队列（如 .userInteractive）绑定线程更易获取 CPU 资源8。
3. 谨慎使用 dispatch_sync：
   在已绑定线程的队列上同步提交会死锁（需检测当前线程）46。

---

五、总结：GCD 串行队列的设计哲学

机制	实现目标	技术手段
顺序执行	严格保证任务 FIFO	单线程绑定 + 原子状态管理
资源复用	减少线程创建开销	线程池 + 空闲超时释放
优先级控制	高 QoS 任务优先调度	QoS 继承至目标队列
死锁防护	防止同步提交死锁	线程绑定检测 + 队列状态机

通过目标队列转发和线程动态绑定，GCD 在保证串行语义的同时，实现了高效的线程复用与优先级管理，成为 iOS/macOS 多线程编程的核心基础。

GCD Barrier Sync 屏障效果实现机制深度解析

GCD 的屏障同步(dispatch_barrier_sync)通过精妙的状态管理和任务调度机制确保屏障效果，下面从核心原理、状态管理和任务调度三个维度全面解析其实现机制：

一、屏障效果的核心原理

1. 屏障语义定义

• 屏障前任务：并发执行
• 屏障任务：独占执行（隔离前后任务）
• 屏障后任务：屏障完成后并发执行

2. 实现三要素

要素	实现机制	作用
屏障前任务完成	活跃任务计数器	确保屏障前任务全部完成
屏障独占执行	屏障状态标志位	阻塞新任务执行
屏障后任务隔离	任务分类链表	分离屏障前后任务

---

二、状态管理：屏障状态机

1. 状态位掩码设计

c

复制

下载

// queue_internal.h
#define DISPATCH_QUEUE_STATE_BARRIER      0x100000000  // 屏障活跃标志
#define DISPATCH_QUEUE_ACTIVE_COUNT_MASK  0x0000FFFF   // 活跃任务计数器

2. 状态转换流程

3. 屏障状态检测

// 检查屏障是否可激活
static bool _dq_state_is_barrier_compatible(uint64_t dq_state) {
    return !(dq_state & DISPATCH_QUEUE_STATE_BARRIER) &&  // 无活跃屏障
           (dq_state & DISPATCH_QUEUE_ACTIVE_COUNT_MASK) == 0; // 无活跃任务
}

---

三、任务调度机制

1. 任务链表分离

struct dispatch_queue_s {
    // 普通任务链表
    dispatch_object_t dq_items_head;
    dispatch_object_t dq_items_tail;
    
    // 屏障任务专用链表
    dispatch_object_t dq_barrier_items;
};

• 屏障前任务：存入 dq_items_head/tail
• 屏障任务：存入 dq_barrier_items
• 屏障后任务：屏障完成后移入 dq_items_head/tail

2. 任务调度逻辑

void _dispatch_lane_drain(dispatch_lane_t dq) {
    // 步骤1：检查屏障状态
    if (dq_state & DISPATCH_QUEUE_STATE_BARRIER) {
        _process_barrier_tasks(dq); // 处理屏障任务
        return;
    }
    
    // 步骤2：处理普通任务
    while ((task = _dispatch_lane_pop_head(dq))) {
        _dispatch_continuation_invoke(task);
    }
    
    // 步骤3：检查屏障等待
    if (dq->dq_barrier_items) {
        _activate_barrier(dq); // 激活屏障
    }
}

3. 屏障激活流程

static void _activate_barrier(dispatch_lane_t dq) {
    // 原子操作设置屏障标志
    uint64_t new_state = old_state | DISPATCH_QUEUE_STATE_BARRIER;
    os_atomic_store2o(dq, dq_state, new_state, release);
    
    // 执行屏障任务
    dispatch_object_t barrier_task = dq->dq_barrier_items;
    _dispatch_continuation_invoke(barrier_task);
    
    // 清除屏障标志
    new_state &= ~DISPATCH_QUEUE_STATE_BARRIER;
    os_atomic_store2o(dq, dq_state, new_state, release);
}

---

四、关键保障机制

1. 屏障前任务完成保障

// 任务完成回调
void _dispatch_continuation_free(dispatch_continuation_t dc) {
    // 原子减少活跃计数
    os_atomic_dec2o(dq, dq_state, DISPATCH_QUEUE_ACTIVE_COUNT_DECREMENT, relaxed);
    
    // 检查是否可激活屏障
    if (new_active_count == 0 && dq->dq_barrier_items) {
        _dispatch_queue_wakeup(dq); // 唤醒屏障
    }
}

2. 屏障独占执行保障

void dx_push(dispatch_queue_t dq, dispatch_object_t dou) {
    if (dq_state & DISPATCH_QUEUE_STATE_BARRIER) {
        // 屏障活跃时阻塞新任务
        _dispatch_queue_block_new_tasks(dq, dou);
    } else {
        _dispatch_queue_push_list(dq, dou);
    }
}

3. 线程阻塞同步

// dispatch_barrier_sync_f_slow
void _dispatch_barrier_sync_f_slow(...) {
    // 创建同步上下文
    struct dispatch_sync_context_s dsc = {
        .dsc_waiter = _dispatch_tid_self(),
        .dsc_func = func,
        .dsc_ctxt = ctxt
    };
    
    // 阻塞当前线程
    _dispatch_thread_event_wait(&dsc.dsc_event);
    
    // 屏障完成后唤醒
    _dispatch_thread_event_signal(&dsc.dsc_event);
}

---

五、性能优化设计

1. 快速路径优化

// 快速路径：立即执行屏障
if (_dispatch_queue_try_acquire_barrier_sync(dl, tid)) {
    func(ctxt); // 直接执行
    _dispatch_release_barrier_sync(dl);
    return;
}

• 触发条件：

  1. 无活跃任务
  2. 无其他屏障
  3. CAS操作成功

2. 优先级继承

void _dispatch_continuation_invoke(dispatch_continuation_t dc) {
    pthread_priority_t orig = pthread_get_priority();
    pthread_set_priority(dc->dc_priority); // 提升至任务QoS
    dc->dc_func(dc->dc_ctxt);
    pthread_set_priority(orig); // 恢复
}

• 避免低优先级线程执行屏障导致优先级反转

3. 批处理优化

// 连续屏障合并
if (_dispatch_is_barrier_continuation(dc) && 
    _dispatch_is_barrier_continuation(next)) 
{
    _dispatch_continuation_group_async(dq, dc, next);
}

---

六、特殊场景处理

1. 递归屏障处理

concurrentQueue.async(flags: .barrier) {
    // 内部提交同步屏障
    concurrentQueue.sync(flags: .barrier) {
        // 允许执行：当前线程已持有屏障锁
    }
}

实现机制：

if (dl->dq_thread == tid && 
    (dq_state & DISPATCH_QUEUE_STATE_BARRIER)) 
{
    // 允许递归屏障
    return true;
}

2. 队列挂起处理

if (dq_state & DISPATCH_QUEUE_SUSPENDED) {
    // 延迟屏障执行
    _dispatch_queue_delay_barrier(dq, dc);
}

3. 全局队列屏障

// 全局队列强制慢速路径
if (!dq->do_targetq) {
    return _dispatch_barrier_sync_f_slow(dq, ...);
}

---

七、设计哲学总结

1. 状态驱动设计

2. 原子操作保障

// 屏障状态变更
os_atomic_cmpxchg2o(dq, dq_state, 
    old_state, 
    old_state | DISPATCH_QUEUE_STATE_BARRIER, 
    acquire
);

3. 分层处理策略

层级	机制	性能影响
快速路径	无锁执行	~100ns
慢速路径	线程阻塞	~5μs
异常处理	崩溃防护	防止死锁

通过状态机管理、原子操作保障和分层处理策略，GCD 在保证屏障语义的前提下，实现了高性能的屏障同步机制，使得在自定义并发队列上使用屏障的开销仅比普通同步操作高约 50%

drain的两种flavour和两种模式

/*

• Drain comes in 2 flavours (serial/concurrent) and 2 modes * (redirecting or not). * * Serial * ~~~~~~ * Serial drain is about serial queues (width == 1). It doesn't support * the redirecting mode, which doesn't make sense, and treats all continuations * as barriers. Bookkeeping is minimal in serial flavour, most of the loop * is optimized away. * * Serial drain stops if the width of the queue grows to larger than 1. * Going through a serial drain prevents any recursive drain from being * redirecting.
• • Concurrent * ~~~~~~~~~~ * When in non-redirecting mode (meaning one of the target queues is serial), * non-barriers and barriers alike run in the context of the drain thread. * Slow non-barrier items are still all signaled so that they can make progress * toward the dispatch_sync() that will serialize them all . * * In redirecting mode, non-barrier work items are redirected downward. * * Concurrent drain stops if the width of the queue becomes 1, so that the * queue drain moves to the more efficient serial mode. */

dispatch_worker_thread

dispatch_async核心函数_dispatch_continuation_async解析

dispatch_queue_t和dispatch_queue_class_t的关系

os_object_vtable&gcd中的vtable

**typedef** **struct** _os_object_vtable_s {
    _OS_OBJECT_CLASS_HEADER();
} _os_object_vtable_s;

**typedef** **struct** _os_object_s {
    _OS_OBJECT_HEADER(
    **const** _os_object_vtable_s *__ptrauth_objc_isa_pointer os_obj_isa,
    os_obj_ref_cnt,
    os_obj_xref_cnt);
} _os_object_s;

gcd中各子队列虚函数表初始化配置

DISPATCH_VTABLE_INSTANCE(queue,
// This is the base class for queues, no objects of this type are made
.do_type        = _DISPATCH_QUEUE_CLUSTER,
.do_dispose     = _dispatch_object_no_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_object_no_invoke,
.dq_activate    = _dispatch_queue_no_activate,
);


DISPATCH_VTABLE_INSTANCE(workloop,
.do_type        = DISPATCH_WORKLOOP_TYPE,
.do_dispose     = _dispatch_workloop_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_workloop_invoke,

.dq_activate    = _dispatch_queue_no_activate,
.dq_wakeup      = _dispatch_workloop_wakeup,
.dq_push        = _dispatch_workloop_push,
);

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_serial, lane,
.do_type        = DISPATCH_QUEUE_SERIAL_TYPE,
.do_dispose     = _dispatch_lane_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_lane_invoke,

.dq_activate    = _dispatch_lane_activate,
.dq_wakeup      = _dispatch_lane_wakeup,
.dq_push        = _dispatch_lane_push,
);

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_concurrent, lane,
.do_type        = DISPATCH_QUEUE_CONCURRENT_TYPE,
.do_dispose     = _dispatch_lane_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_lane_invoke,

.dq_activate    = _dispatch_lane_activate,
.dq_wakeup      = _dispatch_lane_wakeup,
.dq_push        = _dispatch_lane_concurrent_push,
);

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_global, lane,
.do_type        = DISPATCH_QUEUE_GLOBAL_ROOT_TYPE,
.do_dispose     = _dispatch_object_no_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_object_no_invoke,

.dq_activate    = _dispatch_queue_no_activate,
.dq_wakeup      = _dispatch_root_queue_wakeup,
.dq_push        = _dispatch_root_queue_push,
);

这段代码展示了 GCD 中不同队列类型的虚函数表（vtable）配置，是 GCD 多态队列系统的核心实现。下面我将详细解析每个队列类型的 vtable 定义及其作用：

---

1. 基础队列类型 (queue)

DISPATCH_VTABLE_INSTANCE(queue,
.do_type        = _DISPATCH_QUEUE_CLUSTER,  // 抽象基类标识
.do_dispose     = _dispatch_object_no_dispose, // 无需销毁操作
.do_debug       = _dispatch_queue_debug,    // 调试信息输出
.do_invoke      = _dispatch_object_no_invoke, // 无任务执行逻辑
.dq_activate    = _dispatch_queue_no_activate, // 无激活操作
);

• 角色：所有队列的抽象基类（不直接实例化）

• 关键特性：

  • 禁用销毁/调用/激活操作（空实现）
  • 仅提供调试接口
  • _DISPATCH_QUEUE_CLUSTER 标记为抽象类型

---

2. 工作循环队列 (workloop)

DISPATCH_VTABLE_INSTANCE(workloop,
.do_type        = DISPATCH_WORKLOOP_TYPE,   // 工作循环类型标识
.do_dispose     = _dispatch_workloop_dispose, // 自定义销毁逻辑
.do_debug       = _dispatch_queue_debug,    
.do_invoke      = _dispatch_workloop_invoke, // 任务执行入口
.dq_activate    = _dispatch_queue_no_activate,
.dq_wakeup      = _dispatch_workloop_wakeup, // 唤醒机制
.dq_push        = _dispatch_workloop_push,   // 任务入队实现
);

• 角色：GCD 事件处理核心（管理事件源/定时器）

• 关键特性：

  • 自定义任务执行逻辑 (_dispatch_workloop_invoke)
  • 特殊唤醒机制 (_dispatch_workloop_wakeup)
  • 专用入队实现 (_dispatch_workloop_push)
  • 典型应用：主队列、事件源队列

---

3. 串行队列 (queue_serial)

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_serial, lane,
.do_type        = DISPATCH_QUEUE_SERIAL_TYPE, // 串行队列标识
.do_dispose     = _dispatch_lane_dispose,   // 通道销毁逻辑
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_lane_invoke,    // 串行任务执行
.dq_activate    = _dispatch_lane_activate,  // 激活通道
.dq_wakeup      = _dispatch_lane_wakeup,    // 通道唤醒
.dq_push        = _dispatch_lane_push,      // 串行入队
);

• 角色：标准串行队列 (DISPATCH_QUEUE_SERIAL)

• 继承：基于 lane 的子类（队列通道）

• 关键特性：

  • 顺序任务执行 (_dispatch_lane_invoke)
  • FIFO 入队策略 (_dispatch_lane_push)
  • 通道级生命周期管理

---

4. 并发队列 (queue_concurrent)

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_concurrent, lane,
.do_type        = DISPATCH_QUEUE_CONCURRENT_TYPE, // 并发队列标识
.do_dispose     = _dispatch_lane_dispose,
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_lane_invoke,    // 并发任务执行
.dq_activate    = _dispatch_lane_activate,
.dq_wakeup      = _dispatch_lane_wakeup,
.dq_push        = _dispatch_lane_concurrent_push, // 并发入队
);

• 角色：标准并发队列 (DISPATCH_QUEUE_CONCURRENT)

• 关键差异：

  • 并行入队实现 (_dispatch_lane_concurrent_push)
  • 相同 _dispatch_lane_invoke 但内部支持并行
  • 注意：并发控制通过原子操作实现，非函数差异

---

5. 全局队列 (queue_global)

DISPATCH_VTABLE_SUBCLASS_INSTANCE(queue_global, lane,
.do_type        = DISPATCH_QUEUE_GLOBAL_ROOT_TYPE, // 全局根队列
.do_dispose     = _dispatch_object_no_dispose, // 禁止销毁（单例）
.do_debug       = _dispatch_queue_debug,
.do_invoke      = _dispatch_object_no_invoke, 
.dq_activate    = _dispatch_queue_no_activate,
.dq_wakeup      = _dispatch_root_queue_wakeup, // 根队列唤醒
.dq_push        = _dispatch_root_queue_push,   // 根队列入队
);

• 角色：全局队列 (dispatch_get_global_queue())

• 关键特性：

  • 单例模式（禁用销毁）
  • 直连线程池的入队 (_dispatch_root_queue_push)
  • 特殊唤醒机制 (_dispatch_root_queue_wakeup)
  • QoS 优先级支持（通过不同全局队列实例）

---

关键技术解析

1. 虚表宏机制

// 定义独立虚表
#define DISPATCH_VTABLE_INSTANCE(name, ...) \
const struct dispatch_##name##_vtable_s \
_dispatch_##name##_vtable = { __VA_ARGS__ }

// 定义继承虚表（C语言模拟OOP继承）
#define DISPATCH_VTABLE_SUBCLASS_INSTANCE(name, base, ...) \
const struct dispatch_##name##_vtable_s \
_dispatch_##name##_vtable = { \
._base = &_dispatch_##base##_vtable, \
__VA_ARGS__ \
}

• 继承实现：子类虚表包含基类虚表指针

• 多态调用： void dispatch_push(dispatch_queue_t q, void *item) { q->do_vtable->dq_push(q, item); // 动态分派 }

2. 队列操作函数指针

函数指针	作用	典型实现差异
dq_push	任务入队	串行/并发/全局队列逻辑不同
dq_wakeup	唤醒队列线程	工作循环/根队列有特殊实现
do_invoke	执行队列中的任务	工作循环有事件处理逻辑
do_dispose	对象销毁时的清理	全局队列无需清理
dq_activate	首次使用队列时的初始化	大多数队列需要激活

3. 类型标识符 (do_type)

类型常量	值	说明
_DISPATCH_QUEUE_CLUSTER	0x00010000	抽象基类
DISPATCH_WORKLOOP_TYPE	0x00020000	事件处理队列
DISPATCH_QUEUE_SERIAL_TYPE	0x00040000	串行队列
DISPATCH_QUEUE_CONCURRENT_TYPE	0x00080000	并发队列
DISPATCH_QUEUE_GLOBAL_ROOT_TYPE	0x00100000	全局根队列

---

设计思想总结

1. 多态分层：

   • 抽象基类 → 中间类型（workloop/lane）→ 具体队列类型
   • 每层增加特定功能

2. 职责分离：

   • 入队 (push) 与执行 (invoke) 解耦
   • 生命周期 (dispose) 与运行时逻辑分离

3. 性能优化：

   • 编译时绑定虚表（非动态查找）
   • 空操作函数减少条件判断
   • 全局队列特殊路径优化

4. 可扩展性：

   • 新增队列类型只需定义新虚表
   • 通过继承复用基础功能

这种设计使 GCD 能高效支持多种队列语义（串行/并发/全局），同时保持核心调度逻辑统一，是 C 语言实现面向对象系统的典范。

源码解析、DISPATCH_CLASS_DECL/DISPATCH_SUBCLASS_DECL

DISPATCH_CLASS_DECL(queue, QUEUE); DISPATCH_CLASS_DECL_BARE(lane, QUEUE); DISPATCH_CLASS_DECL(workloop, QUEUE); DISPATCH_SUBCLASS_DECL(queue_serial, queue, lane); DISPATCH_SUBCLASS_DECL(queue_main, queue_serial, lane); DISPATCH_SUBCLASS_DECL(queue_concurrent, queue, lane); DISPATCH_SUBCLASS_DECL(queue_global, queue, lane);

这段代码使用宏定义了 GCD 队列的类层次结构，是 GCD 类型系统的核心声明。以下是逐行解析：

---

1. 基础队列类型声明

DISPATCH_CLASS_DECL(queue, QUEUE);

• 作用：声明基础队列类型 dispatch_queue_s

• 展开后： typedef struct dispatch_queue_s dispatch_queue_s; typedef struct dispatch_queue_s *dispatch_queue_t;

• 特性：

  • 所有队列的抽象基类
  • 对应之前解析的 queue 虚表
  • QUEUE 参数表示类型分类

---

2. 通道基础类型声明

DISPATCH_CLASS_DECL_BARE(lane, QUEUE);

• 作用：声明队列通道基础类型 dispatch_lane_s

• 关键差异：DECL_BARE 表示不生成完整公共接口

• 展开后： typedef struct dispatch_lane_s dispatch_lane_s; // 注意：不生成 dispatch_lane_t 公共类型

• 设计意图：

  • lane 是内部实现细节（通道管理）
  • 避免用户直接操作通道结构体

---

3. 工作循环队列声明

DISPATCH_CLASS_DECL(workloop, QUEUE);

• 作用：声明工作循环队列 dispatch_workloop_s

• 展开后： typedef struct dispatch_workloop_s dispatch_workloop_s; typedef struct dispatch_workloop_s *dispatch_workloop_t;

• 特殊用途：

  • 管理事件源和定时器
  • 主队列的实际类型
  • 对应 workloop 虚表

---

队列继承体系声明

4. 串行队列子类

DISPATCH_SUBCLASS_DECL(queue_serial, queue, lane);

• 结构：子类名, 父类名, 实现基础

• 含义：

  • 创建 dispatch_queue_serial_s 类型
  • 继承自基础队列 (queue)
  • 基于通道实现 (lane)

• 内存布局： struct dispatch_queue_serial_s { struct dispatch_queue_s queue; // 继承父类 struct dispatch_lane_s lane; // 通道实现 };

---

5. 主队列声明

DISPATCH_SUBCLASS_DECL(queue_main, queue_serial, lane);

• 继承关系：主队列是串行队列的子类

• 特殊性质：

  • 全局单例（应用主线程）
  • 附加 GUI 相关特性（如 RunLoop 集成）

• 内存布局： struct dispatch_queue_main_s { struct dispatch_queue_serial_s serial; // 继承串行队列 // 主队列特有字段（如 GUI 链接） };

---

6. 并发队列子类

DISPATCH_SUBCLASS_DECL(queue_concurrent, queue, lane);

• 特点：

  • 直接继承基础队列 (queue)
  • 同样基于通道实现 (lane)

• 与串行队列的区别：

  • 不同的虚表配置（dq_push = _dispatch_lane_concurrent_push）
  • 原子操作实现并行性

---

7. 全局队列声明

DISPATCH_SUBCLASS_DECL(queue_global, queue, lane);

• 特殊性质：

  • 系统级共享队列（非用户创建）
  • 直接连接线程池

• 实现要点：

  • 使用特殊虚表（dq_push = _dispatch_root_queue_push）
  • 绕过通道直接调度到线程

---

宏定义解析

核心宏展开逻辑

// 类声明宏
#define DISPATCH_CLASS_DECL(name, kind) \
    typedef struct dispatch_##name##_s *dispatch_##name##_t; \
    typedef struct dispatch_##name##_s dispatch_##name##_s;

// 子类声明宏
#define DISPATCH_SUBCLASS_DECL(subname, supername, barname) \
    typedef struct dispatch_##subname##_s *dispatch_##subname##_t; \
    typedef struct dispatch_##subname##_s { \
        dispatch_##supername##_s as_super; \  // 父类实例
        dispatch_##barname##_s as_##barname; \ // 实现基础
    } dispatch_##subname##_s;

---

类型系统层次图

设计优势

1. 类型安全

   • 每种队列有独立类型
   • 编译时检查操作合法性

   // 示例：串行队列专用操作
   void dispatch_serial_special(dispatch_queue_serial_t q);
   

2. 二进制兼容

   • 通过包含父类结构体保证内存布局兼容
   • 父类指针可安全向下转换：

   void handle_queue(dispatch_queue_t dq) {
       if (dq->do_type == DISPATCH_QUEUE_SERIAL_TYPE) {
           dispatch_queue_serial_t serial = (dispatch_queue_serial_t)dq;
           // 安全操作
       }
   }
   

3. 多态扩展

   • 新增队列类型只需添加声明
   • 虚表机制自动支持动态派发

4. 性能优化

   • 静态类型减少运行时检查
   • 内存布局优化（父类在前保证快速访问）

---

使用场景示例

// 创建串行队列（实际返回 dispatch_queue_serial_t）
dispatch_queue_t serial = dispatch_queue_create("com.example", DISPATCH_QUEUE_SERIAL);

// 内部转换
dispatch_queue_serial_t serial_int = (dispatch_queue_serial_t)serial;

// 访问通道结构
dispatch_lane_t lane = &serial_int->as_lane;

// 执行通道级操作
_dispatch_lane_push(lane, task);

这种类型系统设计使 GCD 在保持 C 语言高效性的同时，实现了面向对象编程的灵活性和可扩展性，是系统级框架设计的典范。

gcd中的lane是什么概念

总结

lane是GCD队列实现中的一个重要内部机制，它使得队列能够支持任务优先级、队列状态管理以及高效的任务调度。通过将队列划分为多个lane，GCD能够更细粒度地控制任务的执行顺序和并发行为，从而提供灵活而高效的并发管理。在源码中，我们经常看到dispatch_lane_s作为队列的一个组成部分，而队列的虚函数表（vtable）中的操作函数（如push、wakeup）也是基于lane来实现的。理解lane有助于我们深入理解GCD队列的内部工作原理。

源码解析 dispatch_sync

**void******

dispatch_sync(dispatch_queue_t dq, dispatch_block_t work)
{
    uintptr_t dc_flags = DC_FLAG_BLOCK;
    **if** (unlikely(_dispatch_block_has_private_data(work))) {
        **return** _dispatch_sync_block_with_privdata(dq, work, dc_flags);
    }
    _dispatch_sync_f(dq, work, _dispatch_Block_invoke(work), dc_flags);
}

在Swift开发中，我们经常使用Codable协议轻松实现JSON数据与模型对象的自动转换。

但实际开发中常会遇到这种棘手问题：需要解码的模型中包含某些字段，但这些关键数据却不在当前接收到的JSON中。

本文将通过具体案例，深入探讨三种优雅解决方案及其适用场景。

问题的本质

假设我们有如下User模型：

struct User: Identifiable {
   let id: UUID
   var name: String
   var membershipPoints: Int
   var favorites: Favorites
}

struct Favorites: Codable { 
    var genre: String 
    var directorName: String 
    var movieIDs: [String] 
}

服务器返回的JSON数据只包含基础信息：

{
   "id": "7CBE0CC1-7779-42E9-AAF1-C4B145F3CAE9",
   "name": "John Appleseed",
   "membershipPoints": 192
}

而Favorites数据需要单独请求获取：

{
   "genre": "action",
   "directorName": "Christopher Nolan",
   "movieIDs": [
       "F028CAB5-74D7-4B86-8450-D0046C32DFA0",
       "D2657C95-1A35-446C-97D4-FAAA4783F2AA"
   ]
}

这时候直接使用Codable会出现什么问题？尝试解码时会因为缺少favorites字段导致崩溃。

方案一：可选属性（权宜之计）

最简单的解决办法是将favorites设为可选类型：

var favorites: Favorites?

优点：

• 实现简单，无需额外代码
• 编译器不会报错

缺点：

• 模型变得脆弱，容易产生未初始化状态
• 使用时必须频繁解包（user.favorites?.genre ?? "未知"）
• 无法保证数据完整性，可能导致后续逻辑错误

方案二：中间模型+数据合并（折中方案）

定义一个仅包含公共字段的Partial模型：

extension User {
   struct Partial: Decodable {
       let id: UUID
       var name: String
       var membershipPoints: Int
   }
}

网络请求时同时获取两部分数据：

func loadUser(id: UUID) async throws -> User {
   let (partialData, favoritesData) = try await Task.group {
       URLSession.shared.data(from: userURL(id))
       URLSession.shared.data(from: favoritesURL(id))
   }
   
   let partial = try JSONDecoder().decode(User.Partial.self, from: partialData)
   let favorites = try JSONDecoder().decode(Favorites.self, from: favoritesData)
   
   return User(
       id: partial.id,
       name: partial.name,
       membershipPoints: partial.membershipPoints,
       favorites: favorites
   )
}

优点：

• 保持原有模型完整性
• 明确区分不同来源的数据

缺点：

• 需要维护额外的中间模型
• 代码量增加约30%
• 异步合并逻辑稍显复杂

方案三：CodableWithConfiguration（完美方案）

利用Swift 5.7引入的CodableWithConfiguration特性：

extension User: DecodableWithConfiguration {
    // 告诉编译器：我需要一个 Favorites 作为解码配置
    typealias DecodingConfiguration = Favorites
    
    enum CodingKeys: CodingKey {
        case id, name, membershipPoints
    }
    
    init(from decoder: Decoder, configuration: Favorites) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        id = try container.decode(UUID.self, forKey: .id)
        name = try container.decode(String.self, forKey: .name)
        membershipPoints = try container.decode(Int.self, forKey: .membershipPoints)
        favorites = configuration
    }
}

向下兼容：iOS 15/16 也能用 自定义JSONDecoder扩展以支持配置传递：

extension JSONDecoder {
    private struct Wrapper<T: DecodableWithConfiguration>: Decodable {
        let value: T
        init(from decoder: Decoder) throws {
            let config = decoder.userInfo[.configKey] as! T.DecodingConfiguration
            value = try T(from: decoder, configuration: config)
        }
    }

    func decode<T: DecodableWithConfiguration>(
        _ type: T.Type,
        from data: Data,
        configuration: T.DecodingConfiguration
    ) throws -> T {
        userInfo[.configKey] = configuration
        return try decode(Wrapper<T>.self, from: data).value
    }
}

private extension CodingUserInfoKey {
    static let configKey = CodingUserInfoKey(rawValue: "configuration")!
}

使用时只需一行代码即可完成配置注入：

func loadUser() throws -> User {
    let favoriteData = """
    {
      "genre": "action",
      "directorName": "Christopher Nolan",
      "movieIDs": ["7CBE0CC1-7779-42E9-AAF1-C4B145F3CAE9"]
    }
""".data(using: .utf8)!
    let favorites: Favorites = try JSONDecoder().decode(Favorites.self, from: favoriteData)
    // ↓ 直接把 favorites 当 configuration 传进去
    let userData = """
        {
          "id": "7CBE0CC1-7779-42E9-AAF1-C4B145F3CAE9",
          "name": "John Appleseed",
          "membershipPoints": 192
        }
""".data(using: .utf8)!
    return try JSONDecoder().decode(
        User.self,
        from: userData,
        configuration: favorites
    )
}

do {
    let u = try loadUser()
    print(u)
}

技术对比与选择建议

特性	可选属性	中间模型	CodableWithConfiguration
实现复杂度	★☆☆☆☆	★★☆☆☆	★★★★☆
代码侵入性	低	中	高
运行时安全性	⚠️潜在风险	✅安全可靠	✅绝对安全
类型系统支持	无	部分	完整
iOS版本要求	全平台支持	全平台支持	iOS 17+/Swift 5.7+

推荐使用场景：

• 紧急修复：可选属性适合快速验证原型
• 团队协作：中间模型适合多人协作项目
• 生产环境：CodableWithConfiguration适合追求代码质量的长期项目

通过合理选择技术方案，我们可以在保证代码质量的同时，优雅地解决这类数据解码难题。每种方案都有其适用场景，关键是根据项目实际情况做出最佳权衡。

🔗 原文：RunLoop 实现原理 - 李峰峰博客

1、RunLoop 的概念

我们都知道，APP 运行过程中有一个很重要的线程，就是主线程。但是，一般线程执行完任务后就会退出，而 APP 需要持续运行，所以就需要一个机制使主线程持续运行并随时处理用户事件，在 iOS 里，程序的持续运行就是通过 RunLoop 实现的。

RunLoop 的作用：

• 保持程序持续运行； 程序一启动就会开启一个主线程，主线程开启之后会自动运行一个主线程对应的 RunLoop，RunLoop 保证主线程不会被销毁，也就保证了程序的持续运行；

• 处理 App 中的各种事件 比如：触摸事件，定时器事件等；

• 节省 CPU 资源，提高程序性能 程序运行起来时，当什么操作都没有做的时候，RunLoop 就告诉 CPU，现在没有事情做，我要去休息，这时 CPU 就会将其资源释放出来去做其他的事情，当有事情做的时候 RunLoop 就会立马起来去做事情；

在 iOS 中，NSRunLoop 是基于 CFRunLoopRef 的封装，提供了面向对象的 API，但是这些 API 不是线程安全的。CFRunLoopRef 是在 CoreFoundation 框架内的，它提供了纯 C 函数的 API，CFRunLoopRef 这些 API 都是线程安全的，Apple 在其文档上对 NSRunLoop 非线程安全的提示：

通常不将 RunLoop 类视为线程安全的，并且只能在当前线程的上下文中调用其方法。永远不要尝试调用在不同线程中运行的 RunLoop 对象的方法，因为这样做可能会导致意外的结果。

CFRunLoopRef 是开源的，源码下载地址：opensource.apple.com/tarballs/CF…

为了源码阅读更容易，便于理解 RunLoop 代码关键逻辑，本文所贴出的源码部分有删减，只留下了关键部分。

2、RunLoop 的数据结构

在 CoreFoundation 中，RunLoop 主要有 5 个类：

• CFRunLoopRef
• CFRunLoopModeRef
• CFRunLoopSourceRef
• CFRunLoopTimerRef
• CFRunLoopObserverRef

(1) CFRunLoopRef

NSRunLoop 是基于 CFRunLoopRef 封装的，提供了面向对象的 API，接下来看下 NSRunLoop（即 CFRunLoopRef）的数据结构：

typedef struct __CFRunLoop * CFRunLoopRef;

struct __CFRunLoop
{
    // ......

    // runloop 所对应线程
    pthread_t _pthread;

    //  存放所有标记为 common 的 mode
    CFMutableSetRef _commonModes;

    // 存放 common mode item 的集合(source、timer、observer)
    CFMutableSetRef _commonModeItems;

    // 当前所在 mode
    CFRunLoopModeRef _currentMode;

    // 存放 mode 的集合
    CFMutableSetRef _modes;

    // ......
};

根据以上源码可知，RunLoop 也是一个结构体，即 __CFRunLoop，并且可以看到其中几个关键的成员变量：

• _commonModes RunLoop 的内容发生变化时，RunLoop 会自动将 _commonModeItems 里的 Source/Observer/Timer 同步到 _commonModes 中所有 Mode 里。主线程的 RunLoop 中 kCFRunLoopDefaultMode 和 UITrackingRunLoopMode 都已经被标记为“Common”。 我们可以通过下面方法把一个 Mode 标记为 “Common”： CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);

• _commonModeItems 添加 mode item 的时候，如果 modeName 传入 NSRunLoopCommonModes，则该 mode item 会被保存到 RunLoop 的 _commonModeItems 中，例如： [[NSRunLoop mainRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

• _currentMode runloop 当前所在 mode

• _modes 存放 mode 的集合

也就是说，RunLoop 可以有多个 mode（CFRunLoopModeRef） 对象，但是同一时间只能运行某一种特定的 Mode。

CFRunLoop 对外暴露的管理 Mode 接口只有下面 2 个：

CFRunLoopAddCommonMode(CFRunLoopRef runloop, CFStringRef modeName);
CFRunLoopRunInMode(CFStringRef modeName, ...);

Mode 暴露的管理 mode item 的接口有下面几个：

CFRunLoopAddSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopAddObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopAddTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);
CFRunLoopRemoveSource(CFRunLoopRef rl, CFRunLoopSourceRef source, CFStringRef modeName);
CFRunLoopRemoveObserver(CFRunLoopRef rl, CFRunLoopObserverRef observer, CFStringRef modeName);
CFRunLoopRemoveTimer(CFRunLoopRef rl, CFRunLoopTimerRef timer, CFStringRef mode);

只能通过 mode name 来操作内部的 mode，当你传入一个新的 mode name 但 RunLoop 内部没有对应 mode 时，RunLoop 会自动创建对应的 CFRunLoopModeRef。对于一个 RunLoop 来说，其内部的 mode 只能增加不能删除。

(2) CFRunLoopModeRef

CFRunLoopModeRef 其实是指向 __CFRunLoopMode 结构体的指针，其源码如下：

typedef struct __CFRunLoopMode *CFRunLoopModeRef;

struct __CFRunLoopMode
{
    // ...

    // mode 的名称
    CFStringRef _name;

    // mode 是否停止
    Boolean _stopped;

    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    CFMutableArrayRef _observers;
    CFMutableArrayRef _timers;

    // ...

};

从以上源码可知，每个 mode 对象中，可以存储多个 source、observer、timer（source/observer/timer 被统称为 mode item）。

系统默认注册了 5 个 Mode:

• kCFRunLoopDefaultMode App的默认 Mode，通常主线程是在这个 Mode 下运行的，是大多数操作使用的模式。一般情况下，使用此模式来启动运行循环并配置输入源。

• UIInitializationRunLoopMode 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。

• UITrackingRunLoopMode 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。

• GSEventReceiveRunLoopMode 接受系统事件的内部 Mode。

• kCFRunLoopCommonModes 这是一个占位用的 Mode，作为标记 kCFRunLoopDefaultMode 和 UITrackingRunLoopMode 用，并不是一种真正的 Mode

(3) CFRunLoopSourceRef

CFRunLoopSourceRef 是事件源（输入源）。其分为 source0 和 source1：

• source0 非基于 port 的，接收点击事件，触摸事件等 APP 内部事件，也就是用户触发的事件。这种 source 是不能主动唤醒 RunLoop 的。 使用时，需要先调用 ： CFRunLoopSourceSignal(source) 将这个 Source 标记为待处理，然后再调用： CFRunLoopWakeUp(runloop) 来主动唤醒 RunLoop，让其处理这个事件。

• source1 基于 Port 的，能主动唤醒 RunLoop，通过内核和其他线程通信，接收分发系统事件；触摸硬件，通过 Source1 接收和分发系统事件到 Source0 处理。

关于 Port 内容后文会进行总结。

CFRunLoopSourceRef 源码如下：

typedef struct __CFRunLoopSource * CFRunLoopSourceRef;

struct __CFRunLoopSource
{
    // ...

    // source 的优先级，值为小，优先级越高
    CFIndex _order; /* immutable */

    // runloop 集合
    CFMutableBagRef _runLoops;

    // 联合体，表示 source 是 source0 还是 source1
    union {
        CFRunLoopSourceContext version0;  /* immutable, except invalidation */
        CFRunLoopSourceContext1 version1; /* immutable, except invalidation */
    } _context;

    // ...
};

(4) CFRunLoopObserverRef

CFRunLoopObserverRef 是观察者，每个 Observer 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。可以观测的时间点有以下几个：

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL << 0), // 即将进入Loop
    kCFRunLoopBeforeTimers  = (1UL << 1), // 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
    kCFRunLoopAfterWaiting  = (1UL << 6), // 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL << 7), // 即将退出Loop
};

CFRunLoopObserverRef 源码如下：
typedef struct __CFRunLoopObserver * CFRunLoopObserverRef;

struct __CFRunLoopObserver
{
    // ...

    // observer 对应的 runloop
    CFRunLoopRef _runLoop;

    // observer 观察了多少个 runloop
    CFIndex _rlCount;

    CFOptionFlags _activities;          /* immutable */

    // observer 优先级
    CFIndex _order;                     /* immutable */

    // observer 回调函数
    CFRunLoopObserverCallBack _callout; /* immutable */

    // ...
};

typedef void (*CFRunLoopObserverCallBack)(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info);

例如，监听 RunLoop 的状态：

// 创建observer
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
    switch (activity) {
        case kCFRunLoopEntry:
        NSLog(@"kCFRunLoopEntry");
        break;
        case kCFRunLoopBeforeTimers:
        NSLog(@"kCFRunLoopBeforeTimers");
        break;
        case kCFRunLoopBeforeSources:
        NSLog(@"kCFRunLoopBeforeSources");
        break;
        case kCFRunLoopBeforeWaiting:
        NSLog(@"kCFRunLoopBeforeWaiting");
        break;
        case kCFRunLoopAfterWaiting:
        NSLog(@"kCFRunLoopAfterWaiting");
        break;
        case kCFRunLoopExit:
        NSLog(@"kCFRunLoopExit");
        break;
        default:
        break;
    }
});
// 把 observer 添加到 RunLoop 中
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
// 释放
CFRelease(observer);

(5) CFRunLoopTimerRef

CFRunLoopTimerRef 是基于时间的触发器，我们常用的 NSTimer 其实就是 CFRunLoopTimerRef ，他们之间是 toll-free bridged 的，可以相互转换。其包含一个时间长度和一个回调(函数指针)。 当其加入到 RunLoop 时，RunLoop 会注册对应的时间点，当时间点到时，RunLoop 会被唤醒以执行那个回调。

总结： 一个 RunLoop 中，只能对应一个线程，但是可以包含多个 Mode，每个 mode，可以包含多个 source、observer、timer，其关系如下：

• RunLoop 启动时只能选择其中一个 Mode，作为 currentMode。
• 如果需要切换 Mode，只能退出当前 Loop，再重新选择一个 Mode 进入。
• 不同 Mode 的 Source0/Source1/Timer/Observer 能分隔开来，互不影响。
• 如果 Mode 里没有任何 Source0/Source1/Timer/Observer，RunLoop 会立马退出。

3、RunLoop 的执行流程

当 APP 没有任何任务的时候，RunLoop 会进入休眠，RunLoop 就告诉 CPU，现在没有事情做，我要去休息，这时 CPU 就会将其资源释放出来去做其他的事情。当下次有任务的时候，例如用户点击了屏幕，RunLoop 就会结束休眠开始处理用户的点击事件。所以，为了看到 RunLoop 执行流程，可以在点击事件里加个断点，查看 RunLoop 相关的方法调用栈：

根据上图发现，分析 RunLoop 执行流程，可以从 CFRunLoopRunSpecific、__CFRunLoopRun 函数入手，而对 CFRunLoopRunSpecific 函数的调用，可以在源码中找到，是在 CFRunLoopRun 函数中，源码如下：

void CFRunLoopRun(void) {   /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}

SInt32 CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    CHECK_FOR_FORK();
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}

由以上源码可知：

• 默认底层是通过 CFRunLoopRun 开启 RunLoop 的，并且超时时间设置的非常大：1.0e10，可以理解为不超时。
• 我们也可以通过 CFRunLoopRunInMode 函数设置自定义启动方式，可以自定义超时时间、mode。

然后进入 CFRunLoopRunSpecific 函数，这是 RunLoop 的核心逻辑：

SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) { {
    
    /// 首先根据modeName找到对应mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(rl, modeName, false);
    
    /// 1. 通知 Observers: RunLoop 即将进入 loop。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
    
    /// __CFRunLoopRun中 具体要做的事情
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
    
    /// 11. 通知 Observers: RunLoop 即将退出。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
    
    return result;
}

static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {

    int32_t retVal = 0;
    do {

        // 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
        
        // 3. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);

        // 4. 处理block
        __CFRunLoopDoBlocks(rl, rlm);

        // 5. 处理Source0
        Boolean sourceHandledThisLoop = __CFRunLoopDoSources0(rl, rlm, stopAfterHandle);
        // 如果处理Source0的结果是true
        if (sourceHandledThisLoop) {
            // 再次处理block
            __CFRunLoopDoBlocks(rl, rlm);
        }

        Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);

        // 6. 如果有Source1 (基于port) 处于ready状态，直接处理这个Source1然后跳转去处理消息。
        if (__CFRunLoopWaitForMultipleObjects(NULL, &dispatchPort, 0, 0, &livePort, NULL)) {
            // 如果有Source1, 就跳转到handle_msg
            goto handle_msg;
        }

        // 7. 通知 Observers: RunLoop 的线程即将进入休眠(sleep)
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
        __CFRunLoopSetSleeping(rl);
    
        // 调用mach_msg等待接受mach_port的消息。线程将进入休眠, 等待别的消息来唤醒当前线程：
        // 一个基于 port 的Source 的事件。
        // 一个 Timer 到时间了
        // RunLoop 自身的超时时间到了
        // 被其他什么调用者手动唤醒
        __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
        
        
        __CFRunLoopUnsetSleeping(rl);
        // 8. 通知Observers: 结束休眠, RunLoop的线程刚刚被唤醒了
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);

        
    // 收到消息，处理消息。
    handle_msg:;
        if (/* 被timer唤醒 */) {
            // 01. 处理Timer
            __CFRunLoopDoTimers(rl, rlm, mach_absolute_time())
        } else if (/* 被gcd唤醒 */) {
            // 02. 处理gcd
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
        } else {  // 被Source1唤醒
            // 处理Source1
            sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls) || sourceHandledThisLoop;
        }
        
        // 9. 处理Blocks
        __CFRunLoopDoBlocks(rl, rlm);
        
        // 10. 设置返回值, 根据不同的结果, 处理不同操作
        if (sourceHandledThisLoop && stopAfterHandle) {
            // 进入loop时参数说处理完事件就返回。
            retVal = kCFRunLoopRunHandledSource;
        } else if (timeout_context->termTSR < mach_absolute_time()) {
            // 超出传入参数标记的超时时间了
            retVal = kCFRunLoopRunTimedOut;
        } else if (__CFRunLoopIsStopped(rl)) {
             // 被外部调用者强制停止了
            retVal = kCFRunLoopRunStopped;
        } else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
            // source/timer/observer一个都没有了
            retVal = kCFRunLoopRunFinished;
        }

        // 如果没超时，mode里没空，loop也没被停止，那继续loop。
    } while (0 == retVal);

    return retVal;
}

由以上源码可知，RunLoop 内部是一个 do-while 循环；当调用 CFRunLoopRun() 时，线程就会一直停留在这个循环里；直到超时或被手动停止，该函数才会返回。

RunLoop 执行流程可用下面这张图概括： 通过上面的执行流程可以发现，RunLoop 处理了很多次 Block，即调用了很多次 __CFRunLoopDoBlocks，那这里处理的 Block 到底是什么 Block 呢？ 前面提到了 __CFRunLoop 结构体中的一些常见成员，其实还有两个和 Block 相关的成员：

struct __CFRunLoop {
    // ...

    struct _block_item *_blocks_head; // 存放 CFRunLoopPerformBlock 函数添加的 Block 的双向链表的头指针
    struct _block_item *_blocks_tail; // 存放 CFRunLoopPerformBlock 函数添加的 Block 的双向链表的尾指针

    // ...
};

_blocks_head 和 _blocks_tail 就是用于存放 CFRunLoopPerformBlock 函数添加的 Block 的，可见 RunLoop 是将添加的 Block 任务保存在双向链表中的。

我们可以通过 CFRunLoopPerformBlock 将一个 Block 任务加入到 RunLoop：

void CFRunLoopPerformBlock(CFRunLoopRef rl, CFTypeRef mode, void(block)( void));

可以看出添加 Block 任务的时候，是绑定到某个 runloop mode 的。调用上面的 api 之后，runloop 在执行的时候，会通过如下 API 执行对应 mode 中所有的 block：

__CFRunLoopDoBlocks(rl, rlm);

需要注意的是，CFRunLoopPerformBlock 不会主动唤醒 RunLoop，添加完 Block 之后可以使用 CFRunLoopWakeUp 来主动唤醒 RunLoop。

4、RunLoop 与线程的关系

CFRunLoop 是基于 pthread 来管理线程的，苹果不允许直接创建 RunLoop，它只提供了两个自动获取的函数：CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 这两个函数内部的逻辑大致如下：

// 获得当前线程的 RunLoop 对象，内部调用 _CFRunLoopGet0 函数
CFRunLoopRef CFRunLoopGetCurrent(void) {
    CHECK_FOR_FORK();
    CFRunLoopRef rl = (CFRunLoopRef)_CFGetTSD(__CFTSDKeyRunLoop);
    if (rl) return rl;
    return _CFRunLoopGet0(pthread_self());
}

// 查看_CFRunLoopGet0方法
CF_EXPORT CFRunLoopRef _CFRunLoopGet0(pthread_t t) {
    // 如果为空则t设置为主线程
    if (pthread_equal(t, kNilPthreadT)) {
    t = pthread_main_thread_np();
    }
    __CFLock(&loopsLock);
    // 如果不存在 RunLoop，则创建
    if (!__CFRunLoops) {
        __CFUnlock(&loopsLock);
    CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorSystemDefault, 0, NULL, &kCFTypeDictionaryValueCallBacks);
    // 根据传入的主线程获取主线程对应的 RunLoop
    CFRunLoopRef mainLoop = __CFRunLoopCreate(pthread_main_thread_np());
    // 保存主线程 将主线程-key 和 RunLoop-Value 保存到字典中
    CFDictionarySetValue(dict, pthreadPointer(pthread_main_thread_np()), mainLoop);
    if (!OSAtomicCompareAndSwapPtrBarrier(NULL, dict, (void * volatile *)&__CFRunLoops)) {
        CFRelease(dict);
    }
    CFRelease(mainLoop);
        __CFLock(&loopsLock);
    }
    
    // 从字典里面取 RunLoop：将线程作为 key 从字典里获取 RunLoop
    CFRunLoopRef loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    __CFUnlock(&loopsLock);
    
    // 如果 RunLoop 为空，则创建一个新的 RunLoop，所以 RunLoop 会在第一次获取的时候创建
    if (!loop) {  
    CFRunLoopRef newLoop = __CFRunLoopCreate(t);
        __CFLock(&loopsLock);
    loop = (CFRunLoopRef)CFDictionaryGetValue(__CFRunLoops, pthreadPointer(t));
    
    // 创建好之后，以线程为 key，RunLoop 为 value，一对一存储在字典中，下次获取的时候，则直接返回字典内的 RunLoop
    if (!loop) { 
        CFDictionarySetValue(__CFRunLoops, pthreadPointer(t), newLoop);
        loop = newLoop;
    }
        // do not release run loops inside the loopsLock, because CFRunLoopDeallocate may end up taking it
        __CFUnlock(&loopsLock);
    // 线程结束是销毁 loop
    CFRelease(newLoop);
    }
    // 如果传入线程和当前线程相同
    if (pthread_equal(t, pthread_self())) {
        // 注册一个回调，当线程销毁时，顺便也销毁对应的 RunLoop
        _CFSetTSD(__CFTSDKeyRunLoop, (void *)loop, NULL);
        if (0 == _CFGetTSD(__CFTSDKeyRunLoopCntr)) {
            _CFSetTSD(__CFTSDKeyRunLoopCntr, (void *)(PTHREAD_DESTRUCTOR_ITERATIONS-1), (void (*)(void *))__CFFinalizeRunLoop);
        }
    }
    return loop;
}

通过源码分析可以看出，线程和 RunLoop 之间是一一对应的，其关系是保存在一个 Dictionary 字典里。 所以我们创建子线程 RunLoop 时，只需在子线程中获取当前线程的 RunLoop 对象即可 [NSRunLoop currentRunLoop]。如果不获取，那子线程就不会创建与之相关联的 RunLoop，并且只能在一个线程的内部获取其 RunLoop。 当通过调用 [NSRunLoop currentRunLoop] 方法获取 RunLoop 时，会先看一下字典里有没有子线程对应的 RunLoop，如果有则直接返回 RunLoop，如果没有则会创建一个，并将与之对应的子线程存入字典中。当线程结束时，RunLoop 会被销毁。

Runloop 与线程的关系总结：

• 每条线程都有唯一的一个与之对应的 RunLoop 对象；
• RunLoop 保存在一个全局的 Dictionary 里，线程作为 key，RunLoop 作为 value
• 调用 [NSRunLoop currentRunLoop] 方法获取 RunLoop 时，会先看一下字典里有没有子线程对应的 RunLoop，如果有则直接返回 RunLoop，如果没有则会创建一个，并将对应关系保存到字典里。
• 主线程的 RunLoop 已经自动创建好了，子线程的 RunLoop 需要主动创建；
• RunLoop 在第一次获取时创建，在线程结束时销毁；

5、Runloop 的启动与退出

(1) 创建 Runloop

无法直接创建 RunLoop，但是 RunLoop 在第一次获取时自动创建，获取 RunLoop：

Foundation
// 获得当前线程的 RunLoop 对象
[NSRunLoop currentRunLoop]; 
// 获得主线程的 RunLoop 对象
[NSRunLoop mainRunLoop]; 

Core Foundation
// 获得当前线程的 RunLoop 对象
CFRunLoopGetCurrent(); 
// 获得主线程的 RunLoop 对象
CFRunLoopGetMain(); 

(2) 启动 Runloop

Apple 把 Runloop 启动方式分成了三种:

• 无条件地（Unconditionally）
• 有时间限制（With a set time limit）
• 指定 Mode（In a particular mode）

这三种方式分别对应下面三个方法：

- (void)run;
- (void)runUntilDate:(NSDate *)limitDate;
- (BOOL)runMode:(NSRunLoopMode)mode beforeDate:(NSDate *)limitDate;

• 第 1 种方式，本质就是在 NSDefaultRunLoopMode 模式下无限循环调用 runMode:beforeDate: 方法，在此期间会处理来自输入源的数据；
• 第 2 种方式，本质也是在 NSDefaultRunLoopMode 模式下无限循环调用 runMode:beforeDate: 方法，区别在于它达到指定的超时时间后就不会再调用，在此期间会处理来自输入源的数据。
• 第 3 种方式，Runloop 只会运行一次，达到指定超时时间或者第一个 input source 被处理，则 Runloop 就会退出，这个方法会阻塞当前线程，直到返回结果（YES：输入源被处理或者达到指定的超时值，NO：没有启动成功）。

(3) 退出 Runloop

相较于 Runloop 的启动，它的退出就比较简单了，只有两种方法:

• 设置超时时间
• 手动结束

针对前面提到的第 2、3 中启动方式，可以直接设置超时时间控制退出。如果想要手动退出，可以使用下面函数，其参数就是 Runloop 对象：

void CFRunLoopStop(CFRunLoopRef rl)

但是 Apple 文档中在介绍利用 CFRunLoopStop() 手动退出时提到:

The difference is that you can use this technique on run loops you started unconditionally.

这里的解释非常容易产生误会，如果在阅读时没有注意到 exit 和 terminate 的微小差异就很容易掉进坑里，因为在 run 方法的文档中还有这句话:

If you want the run loop to terminate, you shouldn't use this method

也就是说，前面三种 Runloop 启动方式，对应退出方式如下：

• run 无法退出

• runUntilDate: 只能通过设置超时时间进行退出

• runMode:beforeDate: 可以通过设置超时时间或者使用 CFRunLoopStop 方法来退出

CFRunLoopStop() 函数只会结束当前的 runMode:beforeDate: 调用，而不会结束后续的调用，这也就是为什么 Runloop 的文档中说 CFRunLoopStop() 可以 exit(退出) 一个 Runloop，而在 run 等方法的文档中又说这样会导致 Runloop 无法 terminate(终结)。

如果既让 Runloop 长时间运行，又要在必要时刻手动退出 Runloop，Apple 官方文档提供了推荐方式：

BOOL shouldKeepRunning = YES;        // global
NSRunLoop *theRL = [NSRunLoop currentRunLoop];
while (shouldKeepRunning && [theRL runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]);

在对应线程中通过如下逻辑退出 Runloop：

shouldKeepRunning = NO;
CFRunLoopStop(CFRunLoopGetCurrent());

6、RunLoop 的底层实现

(1) RunLoop 与 mach port

Apple 将 iOS 系统大致划分为下面 4 个层次： Darwin 的架构如下：

Darwin 是 macOS 和 iOS 操作环境的操作系统部分，Darwin 是一种类 Unix 操作系统（即 Unix 衍生出的系统，在一定程度上继承了原始 Unix 特性），Darwin 的内核是 XNU，XNU 是 Apple 开发的用于 macOS、iOS、tvOS、watchOS 操作系统的内核，XNU 是 X is Not Unix 的缩写。它是一个宏内核 BSD 与微内核 Mach 混合内核，以期将两者的特性兼收并蓄，同时拥有两种内核的优点。

关于 iOS 系统架构相关更多内容，可以看下我的这篇博客：《深入解析 iOS 系统架构》

Mach： Mach 是一个由卡内基梅隆大学开发的计算机操作系统微内核，Mach 核心之上可平行运行多个操作系统，XNU 内核以一个被深度定制的 Mach 内核作为基础。Mach 提供了诸如处理器调度、IPC (进程间通信)等少量且不可或缺的基础 API。在 Mach 中，所有东西都是“对象”，进程（在 Mach 中称为任务）、线程和虚拟内存都是对象。但是，在 Mach 架构中，对象间不能相互调用，对象间通信只能通过消息传递。“消息”是 Mach 中最基础的概念，消息在两个端口 (port) 之间传递，这就是 Mach 的 IPC (进程间通信) 的核心。

BSD： XNU 中的 BSD 代码来自 FreeBSD 内核，FreeBSD 是一种开放源代码的类 Unix 的操作系统，基于 BSD Unix 的源代码派生发展而来。BSD 层确保了 Darwin 系统的 UNIX 特性，真正的内核是 Mach，但是对外部隐藏。BSD 提供了更高层次的抽象 API，例如：基于 Mach 的任务之上的 Unix 进程模型、文件系统、网络协议栈等相关 API。

I/O Kit： I/O Kit 为设备驱动提供了一个面向对象(C++)的一个框架，框架提供每种设备驱动需要的常见特性，以使驱动程序可以用更少的时间和代码完成。

用户态与内核态： 内核控制着操作系统最核心的部分，为了防止应用程序崩溃而导致的内核崩溃，内核与应用程序之间需要进行严格的分离。基于软件的分离会产生巨大的开销，因此现代的操作系统都是依靠硬件来分离。分离的结果就是用户态与内核态。

用户态和内核态的切换有两种类型：

• 自愿转换：比如系统调用；
• 非自愿转换：当发生异常、中断或处理器陷阱的时候，代码的执行会被挂起，并且保留发生错误时候的完整状态。控制权被转交给预定义的内核态错误处理程序或中断服务程序。

在 XNU 中，系统调用有四种类别：

• BSD 系统调用
• Mach 陷阱
• 机器相关调用
• 诊断调用

Mach 消息的发送和接收都是通过同一个 API 函数 mach_msg() 进行的，这个函数在用户态和内核态都有实现。mach_msg() 函数调用了一个 Mach 陷阱（trap），在用户态调用 mach_msg_trap() 会引发陷阱机制，切换到内核态，在内核态中，内核实现的 mach_msg() 会完成实际的工作，如下图： RunLoop 的核心就是基于 mach port 的，其进入休眠时调用的函数是 mach_msg()，RunLoop 调用这个函数去接收消息，如果没有别人发送 port 消息过来，内核会将线程置于等待状态。

前面提到的 source1 就是基于 mach port 的，它用来接收系统事件。当对应系统事件发生后（例如用户点击了屏幕），最终会通过 mach port 将事件转发给需要的 App 进程。随后苹果注册的那个 source1 就会触发回调，RunLoop 被唤醒，APP 开始处理对应事件。

(2) RunLoop 输入源

Runloop 作为线程的入口用来响应传入事件，Runloop 从两种不同类型的源接收事件：

• 输入源（Input Source） 用于传输异步事件，通常是来自另一个线程或者其他程序的消息。输入源将异步事件传递给相应的处理程序，并调用 runUntilDate: 方法（在线程的关联 NSRunLoop 对象上调用）退出。

• 定时器源（Timer Source） 提供同步事件，预定的时间或者固定的时间间隔重复执行，计时器源将事件传递给其处理程序，但不会导致 Runloop 退出。

输入源（Input Source） 创建输入源时，可以将其分配给 Runloop 的一种或多种 mode。一般情况下应该在默认模式下运行 Runloop，但也可以指定自定义 mode。如果输入源不在当前监视的 mode 下，则它生成的任何事件都将保留，直到 Runloop 以正确的 mode 运行，输入源主要有：基于的端口的输入源、自定义输入源、Perform Selector 源。

基于的端口的输入源（Port-based Source） 监听应用程序的 Mach 端口，由内核自动发出信号，对应源码中的 source1。

Cocoa 和 Core Foundation 都提供了创建基于的端口输入源相关的对象和函数，如果使用 Cocoa 提供的相关方法，不需要直接创建输入源，可以使用 NSPort 相关的方法来创建一个 Port 对象，并将该对象添加到 Runloop 中，该 Port 对象会负责创建和配置输入源。使用 Core Foundation 函数实现稍微复杂些，我们需要手动的创建 Port 和它的 Runloop 源。使用 CFMachPortRef, CFMessagePortRef, 或者 CFSocketRef 函数来创建适当地对象。

例如：

- (void)testsource1 {
    // 声明两个端口
    NSPort *mainPort = [NSMachPort port];
    NSPort *threadPort = [NSMachPort port];
    // 设置线程的端口的代理回调为自己
    threadPort.delegate = self;
    
    // 给主线程 Runloop 加一个端口
    [[NSRunLoop currentRunLoop]addPort:mainPort forMode:NSDefaultRunLoopMode];
    
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 子线程
        // 给子线程添加一个 Port，并运行子线程中的 Runloop
        [[NSRunLoop currentRunLoop] addPort:threadPort forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
        
    });
    
    // 2 秒后，从主线程向子线程发送一条消息
    NSString *s1 = @"hello";
    NSData *data = [s1 dataUsingEncoding:NSUTF8StringEncoding];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        
        NSMutableArray *array = [NSMutableArray arrayWithArray:@[mainPort,data]];
        // 发送一条消息
        // 参数：date(发送时间)、msgid(消息标识)、components(发送消息附带参数)、reserved(预留参数，暂时用不到)
        [threadPort sendBeforeDate:[NSDate date] msgid:1000 components:array from:mainPort reserved:0];
        
    });
}

// 这个 NSMachPort 收到消息的回调，注意这个参数，可以先给一个id
- (void)handlePortMessage:(id)message
{
    NSLog(@"收到消息了，线程为：%@",[NSThread currentThread]);
    NSArray *array = [message valueForKeyPath:@"components"];
    NSData *data =  array[1];
    NSString *s1 = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
    NSLog(@"%@",s1);
}

打印结果：

RunLoopTest[10368:5612468] 收到消息了，线程为：<NSThread: 0x6000015acf80>{number = 6, name = (null)}
RunLoopTest[10368:5612468] hello

自定义输入源（Custom input Source） 监听自定义事件源，必须从另一个线程手动发信号通知自定义源，对应源码中的 source0。 可以使用 CoreFoundation 中 CFRunLoopSourceRef 相关的函数来创建自定义输入源，可以使用多个回调函数配置自定义输入源，CoreFoundation 在必要时候调用这些函数来配置 source，处理传入的事件，并在从 Runloop 中移除 source 时将其移除。 除此之外，还需要定义事件的传递机制，这部分是运行在单独的线程上，负责向输入源提供数据并在适当的时候发出信号，事件的传递机制可自行定义。

例如：

@implementation ViewController{
    CFRunLoopRef _runLoopRef;
    CFRunLoopSourceRef _source;
    CFRunLoopSourceContext _source_context;
}

- (void)viewDidLoad {
    [super viewDidLoad];
    [self testsource0];
}

- (void)testsource0 {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{

        NSLog(@"starting thread.......");
        
        _runLoopRef = CFRunLoopGetCurrent();
        // 初始化_source_context。
        bzero(&_source_context, sizeof(_source_context));
        // 这里创建了一个基于事件的源，绑定了一个函数
        _source_context.perform = fire;
        //参数
        _source_context.info = "hello";
        
        // 创建一个source
        _source = CFRunLoopSourceCreate(NULL, 0, &_source_context);
        
        // 将 source 添加到当前 RunLoop 中去
        CFRunLoopAddSource(_runLoopRef, _source, kCFRunLoopDefaultMode);
        
        // 开启 RunLoop 第三个参数设置为 YES，执行完一次事件后返回
        CFRunLoopRunInMode(kCFRunLoopDefaultMode, 9999999, YES);
        
        NSLog(@"end thread.......");
    });
    
    
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        
        if (CFRunLoopIsWaiting(_runLoopRef)) {
            NSLog(@"RunLoop 正在等待事件输入");
            // 添加输入事件
            CFRunLoopSourceSignal(_source);
            // 唤醒线程，线程唤醒后发现由事件需要处理，于是立即处理事件
            CFRunLoopWakeUp(_runLoopRef);
        }else {
            NSLog(@"RunLoop 正在处理事件");
            // 添加输入事件，当前正在处理一个事件，当前事件处理完成后，立即处理当前新输入的事件
            CFRunLoopSourceSignal(_source);
        }
    });
    
}

static void fire(void* info) {
    NSLog(@"我现在正在处理后台任务");
    printf("%s",info);
}

@end

打印结果：

RunLoopTest[10630:5649707] starting thread.......
RunLoopTest[10630:5649457] RunLoop 正在等待事件输入
RunLoopTest[10630:5649707] 我现在正在处理后台任务
RunLoopTest[10630:5649707] end thread.......

Perform Selector 源（Cocoa Perform Selector Source） 除了基于端口的源外，Cocoa 还定义了一个自定义输入源，允许在任何线程上 Perfrom Selector。与基于端口的源一样，Perfrom Selector 请求在目标线程上序列化，缓解了在一个线程上运行多个方法时可能出现的许多同步问题。与基于端口的源不同的是，Perform Selector 源在 Perfrom Selector 后会从 Runloop 中删除自己。

在另一个线程上 Perfrom Selector 时，目标线程必须具有活动的 Runloop。这意味对于我们创建的子线程，需要显式创建 Runloop。由于主线程的 Runloop 是自动创建的，所以可以在 applicationDidFinishLaunching：方法后随时 Perfrom Selector。Runloop 每次循环时，Runloop 都会处理所有的 Perfrom Selector 调用，而不是在每次循环时都只处理一个。

在其他线程上 Perfrom Selector 的相关方法：

// 在主线程的下一个 Runloop 周期中，执行指定的选择器。这些方法允许您选择阻塞当前线程，直到执行选择器结束。
performSelectorOnMainThread:withObject:waitUntilDone:
performSelectorOnMainThread:withObject:waitUntilDone:modes:

// 对拥有 NSThread 对象的任何线程执行指定的选择器。这些方法允许您选择阻塞当前线程，直到执行选择器结束。
performSelector:onThread:withObject:waitUntilDone:
performSelector:onThread:withObject:waitUntilDone:modes:

// 在下一个 Runloop 周期和指定时长延迟(可选)后，在当前线程上执行指定的选择器。由于它要等到下一个 Runloop 周期来执行选择器，所以这些方法提供了一个来自当前执行代码的自动最小延迟，多个选择器时会按照顺序依次执行。
// performSelector:afterDelay: 方法内部会创建一个 Timer 并添加到当前线程的 RunLoop 中。所以如果当前线程没有 RunLoop，则这个方法会失效
performSelector:withObject:afterDelay:
performSelector:withObject:afterDelay:inModes:

// 取消使用 performSelector:withObject:afterDelay: 或 performSelector:withObject:afterDelay:inModes: 发送的到当前线程的消息
cancelPreviousPerformRequestsWithTarget:
cancelPreviousPerformRequestsWithTarget:selector:object:

计时器源（Timer Source） 定时器源在预定时间内同步地将事件传递给线程，定时器可以让线程在对应时刻通知自己执行一些事务，尽管定时器是基于时间的通知方式，但是并不是真的时间机制。就像输入源，定时器在 Runloop 中也是和特定 Mode 相关联的。如果定时器没有处在 Runloop 正在监视的 Mode 中的话，该定时器是不会触发的。必须要等到 Runloop 在定时器支持的 Mode 中运行时，该定时器才会正常运行。如果定时器被触发时机正好是在 Runloop 执行任务中，那么这个定时器源的相关事件只有在 Runloop 下一次运行循环时才能被执行。如果 Runloop 停止运行，那么该定时器源的事件将永远没办法执行。

反复执行的定时器会根据它的触发时间自动配置，并不是真实的触发时间。例如，一个定时器设置的是每 5 秒触发一次，在真实时间上可能是有点延迟的，如果真实时间的延迟大于定时器触发时间的话，那么这次触发时机将被错过。

创建定时器源，可以使用下面两个方法：

scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:
scheduledTimerWithTimeInterval:invocation:repeats:

上面这两个方法创建了定时器并添加到当前线程的默认 mode (NSDefaultRunLoopMode)中，但是也可以通过 NSRunLoop 的下面的实例方法来将 NSTimer 对象添加到其他 mode 中： addTimer:forMode:

例如，下面两种实现方式效果是一样的：

/// 分开处理，我们可以通过更多的自定义方式来处理timer，比如添加到不同的NSDefaultRunLoopMode。
NSDate *futureDate = [NSDate dateWithTimeIntervalSinceNow:1.0];
NSTimer *myTimer = [[NSTimer alloc] initWithFireDate:futureDate interval:0.1 target:self selector:@selector(timedothing:) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:myTimer forMode:NSDefaultRunLoopMode];

/// 将创建和调度同时进行
[NSTimer scheduledTimerWithTimeInterval:0.2 target:self selector:@selector(timedothing:) userInfo:nil repeats:YES];

7、RunLoop 目前的应用

(1) AutoreleasePool

• RunLoop 的进入的时候会调用 objc_autoreleasePoolPush() 创建新的自动释放池。
• RunLoop 的进入休眠的时候会调用 objc_autoreleasePoolPop() 和 objc_autoreleasePoolPush() 销毁自动释放池、创建一个新的自动释放池。
• RunLoop 即将退出时会调用 objc_autoreleasePoolPop() 释放自动自动释放池内对象。

(2) 事件响应

苹果注册了一个 Source1 (基于 mach port 的) 用来接收系统事件，当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 IOKit.framework 生成一个 IOHIDEvent 事件并由 SpringBoard 接收。SpringBoard 只接收按键(锁屏/静音等)、触摸、加速、接近传感器等几种 Event，随后用 mach port 转发给需要的 App 进程。随后苹果注册的那个 Source1 就会触发回调，并调用 _UIApplicationHandleEventQueue() 进行应用内部的分发。

_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。

(3) 手势识别

当上面的 _UIApplicationHandleEventQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。

苹果注册了一个 Observer 监测 BeforeWaiting (Loop 即将进入休眠) 事件，这个 Observe r的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的 GestureRecognizer，并执行 GestureRecognizer 的回调。

当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。

(4) 界面更新

当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay 方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。

苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。

这个函数内部的调用栈大概是这样的：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
    QuartzCore:CA::Transaction::observer_callback:
        CA::Transaction::commit();
            CA::Context::commit_transaction();
                CA::Layer::layout_and_display_if_needed();
                    CA::Layer::layout_if_needed();
                        [CALayer layoutSublayers];
                            [UIView layoutSubviews];
                    CA::Layer::display_if_needed();
                        [CALayer display];
                            [UIView drawRect];

(5) 定时器

NSTimer 其实就是 CFRunLoopTimerRef，他们之间是 toll-free bridged 的。一个 NSTimer 注册到 RunLoop 后，RunLoop 会为其重复的时间点注册好事件。例如 10:00, 10:10, 10:20 这几个时间点。RunLoop 为了节省资源，并不会在非常准确的时间点回调这个Timer。Timer 有个属性叫做 Tolerance (宽容度)，标示了当时间点到后，容许有多少最大误差。

如果某个时间点被错过了，例如执行了一个很长的任务，则那个时间点的回调也会跳过去，不会延后执行。就比如等公交，如果 10:10 时我忙着玩手机错过了那个点的公交，那我只能等 10:20 这一趟了。

(6) PerformSelector

当调用 NSObject 的 performSelecter:afterDelay: 后，实际上其内部会创建一个 Timer 并添加到当前线程的 RunLoop 中。所以如果当前线程没有 RunLoop，则这个方法会失效。

当调用 performSelector:onThread: 时，实际上其会创建一个 Timer 加到对应的线程去，同样的，如果对应线程没有 RunLoop 该方法也会失效。

performSelector:withObject: 只是发消息，不会有 Timer ，所以不会有上面的问题，在子线程调用，不需要开启 Runloop

(7) 关于 GCD

根据前面 RunLoop 的执行流程可以知道，GCD 也是可以唤醒 RunLoop 的，GCD 由子线程返回到 主线程，只有在这种情况下才会触发 RunLoop，会触发 RunLoop 的 Source 1 事件：

dispatch_async(dispatch_get_main_queue(), ^{
    NSLog(@"main queue");
});

当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会向主线程的 RunLoop 发送消息，RunLoop 会被唤醒，并从消息中取得这个 block，并在回调 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE() 里执行这个 block。但这个逻辑仅限于 dispatch 到主线程，dispatch 到其他线程仍然是由 libDispatch 处理的。

(8) 关于网络请求

iOS 中，关于网络请求的接口有如下几层： CFSocket 是最底层的接口，只负责 socket 通信。

• CFNetwork 是基于 CFSocket 等接口的上层封装，ASIHttpRequest 工作于这一层。

• NSURLConnection 是基于 CFNetwork 的更高层的封装，提供面向对象的接口，AFNetworking 工作于这一层。

+ NSURLSession 是 iOS7 中新增的接口，表面上是和 NSURLConnection 并列的，但底层仍然用到了 NSURLConnection 的部分功能 (比如 com.apple.NSURLConnectionLoader 线程)，AFNetworking 2 和 Alamofire 工作于这一层。

下面主要介绍下 NSURLConnection 的工作过程。

通常使用 NSURLConnection 时，你会传入一个 Delegate，当调用了 [connection start] 后，这个 Delegate 就会不停收到事件回调。实际上，start 这个函数的内部会会获取 CurrentRunLoop，然后在其中的 DefaultMode 添加了 4 个 Source0 (即需要手动触发的 Source)。其中 CFMultiplexerSource 是负责各种 Delegate 回调的，CFHTTPCookieStorage 是处理各种 Cookie 的。

当开始网络传输时，我们可以看到 NSURLConnection 创建了两个新线程：com.apple.CFSocket.private 和 com.apple.NSURLConnectionLoader。其中 CFSocket 线程是处理底层 socket 连接的。NSURLConnectionLoader 这个线程内部会使用 RunLoop 来接收底层 socket 的事件，并通过之前添加的 Source0 通知到上层的 Delegate。 NSURLConnectionLoader 中的 RunLoop 接收来自底层 CFSocket 的 Source1 通知。当收到通知后，在合适的时机向 Delegate 线程 RunLoop 发送 CFMultiplexerSource 等 Source0 通知，同时唤醒 Delegate 线程的 RunLoop 来让其处理这些通知。接收到 CFMultiplexerSource 通知后，Delegate 线程的 RunLoop 执行对应 Delegate 回调。

8、Runloop 开发中的使用场景

唯一需要显式运行 Runloop 是在创建子线程时。主线程的 Runloop 已自动创建并运行。对于子线程，需要自行判断是否需要 Runloop，如果需要，则开发者自行创建。例如，下列操作需要启动 Runloop：

• 使用端口或自定义输入源与其他线程通信。
• 在子线程上使用计时器。
• 调用 performSelector… 相关方法。
• 线程保活，以执行周期性任务。

以下是在实际开发是，Runloop 的一些使用场景：

(1) 线程保活

当子线程中的任务执行完毕后，线程就被会被立刻销毁。如果 APP 中需要经常在子线程中执行任务，频繁的创建和销毁线程，会造成资源的浪费，这时候我们就可以使用 Runloop 来让该线程长时间存活而不被销毁，实现如下：

KeepAliveThread.h
typedef void (^KeepAliveThreadTask)(void);

@interface KeepAliveThread : NSObject

// 在子线程执行任务
- (void)executeTask:(KeepAliveThreadTask)task;

// 结束线程
- (void)stop;

@end

KeepAliveThread.m
@interface KeepAliveThread()

@property (nonatomic, strong) NSThread *thread;
@property (nonatomic, assign) BOOL shouldKeepRunning;

@end

@implementation KeepAliveThread

#pragma mark - Public methods
- (instancetype)init {
    if (self = [super init]) {
        self.shouldKeepRunning = YES;
        
        __weak typeof(self) weakSelf = self;
        
        self.thread = [[NSThread alloc] initWithBlock:^{
            [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
            
            while (weakSelf && weakSelf.shouldKeepRunning) {
                [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
            }
        }];
        
        [self.thread start];
    }
    return self;
}

- (void)executeTask:(KeepAliveThreadTask)task {
    if (!self.thread || !task) return;
    [self performSelector:@selector(p_executeTask:) onThread:self.thread withObject:task waitUntilDone:NO];
}

- (void)stop {
    if (!self.thread) return;
    
    [self performSelector:@selector(p_stop) onThread:self.thread withObject:nil waitUntilDone:YES];
}

- (void)dealloc {
    [self stop];
}

#pragma mark - Private methods
- (void)p_stop {
    self.shouldKeepRunning = NO;
    CFRunLoopStop(CFRunLoopGetCurrent());
    self.thread = nil;
}

- (void)p_executeTask:(KeepAliveThreadTask)task {
    task();
}

@end

(2) 保证 Timer 正常运行

创建 Timer 有下面两种方式，两种实现方式是等价的：

// 方式 1
NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerUpdate) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
[timer fire];

// 方式 2
[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerUpdate) userInfo:nil repeats:YES];

当滑动 UIScrollView 时，主线程的 RunLoop 会切换到 UITrackingRunLoopMode 这个 Mode，执行的也是 UITrackingRunLoopMode 下的任务（Mode 中的 item），而 Timer 是添加在 NSDefaultRunLoopMode 下的，所以 Timer 任务并不会执行，只有当 UITrackingRunLoopMode 的任务执行完毕，Runloop 切换到 NSDefaultRunLoopMode 后，才会继续执行 Timer。解决方法很简单，我们只需要在添加 Timer 时，将 mode 设置为 NSRunLoopCommonModes 即可：

NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerUpdate) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
[timer fire];

如果是在子线程中使用 Timer，由于子线程的 Runloop 并不会自动创建，所以必须在子线程中创建并启动 Runloop，否则 Timer 无法正常运行，创建并启动 Runloop 方法：

[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

由于子线程中不会涉及到 UI 更新，所以无需再主动将 Timer 添加到 NSRunLoopCommonModes 下。

(3) 利用 Runloop 优化 UITableView 加载图片时滑动卡顿问题

UITableView 滚动时，主线程的 Runloop 会切换到 UITrackingRunLoopMode 这个 Mode，我们可以在 NSDefaultRunLoopMode 中设置图片，避免一边滑动一边设置 image 引起的卡顿问题：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    UITableViewCell *cell = ...
    // ......
    // 在 NSDefaultRunLoopMode 下设置图片
    [self performSelector:@selector(p_loadImgeWithIndexPath:)
                       withObject:indexPath
                       afterDelay:0.0
                          inModes:@[NSDefaultRunLoopMode]];
    // ......
    return cell;
}

- (void)p_loadImgeWithIndexPath:(NSIndexPath *)indexPath{
    
    UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];
    
    // 子线程下载图片
    [ImageDownload loadImageWithUrl:@"xxxx" success:^(UIImage *image) {
        // 回到主线程刷新UI
        dispatch_async(dispatch_get_main_queue(), ^{
            cell.imageView.image = image;
        });
    }];
}

(4) 利用 Runloop 监控卡顿

根据 Runloop 的执行流程可以发现，Runloop 对我们业务逻辑的处理时间在两个阶段：

• kCFRunLoopBeforeSources 和 kCFRunLoopBeforeWaiting 之间
• kCFRunLoopAfterWaiting 之后

所以，如果主线程 Runloop 处在 kCFRunLoopBeforeSources 时间过长，也就是迟迟无法将任务处理完成，顺利到达 kCFRunLoopBeforeWaiting 阶段，说明发生了卡顿。

同样的，如果 Runloop 处在 kCFRunLoopAfterWaiting 时间过长，也是发生了卡顿。

所以，如果我们要利用 Runloop 来监控卡顿的话，就要关注 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 两个阶段，一般卡顿时间超过 250ms 会被明显感知，所以，可以以连续 5 次卡顿时长超过 50ms 可以认为发生卡顿，或者根据需要调整统计阀值。以下是通过 Runloop 监听卡顿的一个例子：

@interface LagMonitor() {
    int timeoutCount;
    CFRunLoopObserverRef runLoopObserver;
    @public
    dispatch_semaphore_t dispatchSemaphore;
    CFRunLoopActivity runLoopActivity;
}

@end

@implementation LagMonitor

#pragma mark - Interface
+ (instancetype)shareInstance {
    static id instance = nil;
    static dispatch_once_t dispatchOnce;
    dispatch_once(&dispatchOnce, ^{
        instance = [[self alloc] init];
    });
    return instance;
}

// 开始监控
- (void)beginMonitor {
    NSLog(@"开始监控");
    if (runLoopObserver) {
        return;
    }
    
    // 创建信号量，注意这里信号量为 0
    dispatchSemaphore = dispatch_semaphore_create(0);
    // 创建 Observer
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                              kCFRunLoopAllActivities,
                                              YES,
                                              0,
                                              runLoopObserverCallBack,
                                              &context);
    // 将 Observer 添加到主线程的 RunLoop
    CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    
    // 在子线程持续监控
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (YES) {
            /**
             信号量 P 操作，成功的话信号量会 - 1，这里超时时间为 50ms，即等待 50ms 后还没成功就返回失败
             操作成功，信号量 - 1，返回值为 0；操作失败，返回值非 0
             由于初始信号量为 0，这里会阻塞，直到 runLoopObserverCallBack 函数中对信号量做了 V 操作，即 RunLoop 状态发生改变的时候。
             */
            long semaphoreWait = dispatch_semaphore_wait(self->dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 50 * NSEC_PER_MSEC));
            if (semaphoreWait != 0) {
                // 发生超时，说明 RunLoop 保持在一个状态的时间超过了 50ms
                if (!self->runLoopObserver) {
                    self->timeoutCount = 0;
                    self->dispatchSemaphore = 0;
                    self->runLoopActivity = 0;
                    return;
                }
                // 如果是在 BeforeSources 或 AfterWaiting 这两个状态持续时间达到超时时间，就代表发生了卡顿
                if (self->runLoopActivity == kCFRunLoopBeforeSources || self->runLoopActivity == kCFRunLoopAfterWaiting) {
                    // 出现五次出结果
                    if (++self->timeoutCount < 5) {
                        continue;
                    }
                    // 发生了卡顿，可以使用 PLCrashReporter 等收集堆栈并上报
                    NSLog(@"发生了卡顿，");
                }
            }
            self->timeoutCount = 0;
        }
    });
    
}


// 结束监控
- (void)endMonitor {
    NSLog(@"结束监控");
    if (!runLoopObserver) {
        return;
    }
    CFRunLoopRemoveObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    // 释放 Observer
    CFRelease(runLoopObserver);
    runLoopObserver = NULL;
}

#pragma mark - Private
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) {
    LagMonitor *lagMonitor = (__bridge LagMonitor*)info;
    lagMonitor->runLoopActivity = activity;
    
    dispatch_semaphore_t semaphore = lagMonitor->dispatchSemaphore;
    // 对信号量进行 V 操作，信号量 + 1
    dispatch_semaphore_signal(semaphore);
}

@end

上面只是统计卡顿的基础版本，如果真的使用到项目中上面逻辑还有不少需要优化的地方，例如：

• 避免多次重复上报同一个卡顿堆栈
  • 可以先将堆栈保存到内存中，以堆栈栈顶函数为特征，如果相同认为整个堆栈是同一个，不重复上报。
• 准确定位真正卡顿的堆栈
  • 假如主线程有三个任务，只有第一个是引起卡顿的任务，当开始上报卡顿时获取到的堆栈可能是后两个不耗时的任务的堆栈。这种情况可以每 50ms 甚至更短时间获取一次堆栈，只保留最近一定数量（例如最近 20 个）堆栈信息，当发生卡顿时相同堆栈数量最多的堆栈就是真正引起卡顿的堆栈。

目前也有一些比较成熟的卡顿监控方案，例如：matrix。

🔗 原文链接：
RunLoop 实现原理 - 李峰峰博客
📢 作者声明：
转载请注明来源