基础 on Last Stand

App启动流程

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

启动类型概览

iOS应用启动分为三种类型：

启动类型	描述	特点
冷启动（Cold Launch）	App完全不在内存中，需要从头开始加载	耗时最长，需要完整执行所有启动流程
热启动（Warm Launch）	App在后台被挂起（Suspended），重新进入前台	最快，只需恢复App状态，不需要重新创建进程
预热启动（Pre-warm Launch）	系统预测用户可能启动App，提前在后台执行部分启动流程	iOS 15+引入，介于冷启动和热启动之间

graph LR
subgraph "冷启动（耗时最长）"
A1[创建进程] --> A2[加载dylib]
A2 --> A3[Rebase/Bind]
A3 --> A4[+load]
A4 --> A5[main]
A5 --> A6[首帧渲染]
end
subgraph "预热启动（iOS 15+）"
B1[系统提前完成（后台）:
创建进程 → 加载dylib → Rebase/Bind] --> B2[用户点击后执行:
+load → main → 首帧渲染]
end
subgraph "热启动（最快）"
C1[唤醒进程] --> C2[WillEnterForeground]
C2 --> C3[DidBecomeActive]
C3 --> C4[恢复UI]
end

一、冷启动（Cold Launch）

冷启动是最完整的启动流程，也是启动优化的主要关注点。

冷启动流程概览

flowchart TD
Start([App 冷启动流程]) --> PreMain
subgraph PreMain["Pre-main 阶段"]
direction TB
A[加载可执行文件] --> B[加载动态库
（包括 Swift Runtime）]
B --> C[Rebase & Bind]
C --> D[ObjC Runtime 初始化
（类注册、Category 附加）]
D --> D2[Swift Runtime 元数据注册
（类型元数据、协议遵循表）]
D2 --> D3[调用 +load 方法]
D3 --> E[执行 Initializers
（C++静态构造函数、__attribute__）]
end
PreMain --> MainPhase
subgraph MainPhase["main 阶段"]
direction TB
F[main函数] --> G[UIApplicationMain]
G --> H[AppDelegate回调]
H --> I[首帧渲染
（创建Window、RootViewController、首屏UI）]
end
MainPhase --> End([启动完成])

Pre-main 阶段

Pre-main阶段是指从用户点击App图标到main函数执行之前的过程，这个阶段主要由dyld（动态链接器）负责。

Block底层原理

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

基础概念

Block 是 Apple 在 C 语言基础上扩展的语法特性（也称为 Closure / 闭包），它允许将一段代码和其执行时需要的上下文环境封装为一个可传递的对象。Block 在 Objective-C 和 C/C++ 中均可使用，是 GCD、动画 API、回调等场景的核心机制。

// Block 的声明与调用
void (^myBlock)(NSString *) = ^(NSString *name) {
 NSLog(@"Hello, %@", name);
};
myBlock(@"World");

一个核心问题是：Block 是函数指针还是对象？ 答案是——Block 本质上是一个 OC 对象。它的底层是一个包含 isa 指针的 C 结构体，满足 OC 对象的基本条件；同时它也包含一个函数指针（FuncPtr），指向 Block 实际执行的代码。因此可以说，Block 是一个用对象形式包装了函数指针和捕获变量的特殊 OC 对象。

底层数据结构

通过 clang -rewrite-objc 可以将 Block 语法转换为 C++ 代码，观察其底层结构。这个转换虽然不完全等同于最终编译产物，但准确反映了 Block 的数据布局和调用机制。

编译器转换示例

对以下源码：

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

Clang 会将其转换为如下结构：

Codable底层原理

Mon, 08 Jun 2026 23:06:52 +0800

Codable 是 Swift 4 引入的序列化方案，官方定位是替代 Objective-C 时代的 NSCoding、以及各种第三方字典转模型框架（MJExtension、YYModel、JSONModel 等）。与运行时反射方案不同，Codable 通过"编译器自动合成 + 标准库协议抽象 + 具体格式实现"三层解耦，在编译期就把类型与序列化逻辑绑定好，兼具类型安全、性能和扩展性。

本文基于以下 Swift 源码展开分析：

协议定义：swift/stdlib/public/core/Codable.swift
编译器合成：swift/lib/Sema/DerivedConformanceCodable.cpp、DerivedConformanceCodingKey.cpp
Foundation 实现：swift-corelibs-foundation/Sources/Foundation/JSONEncoder.swift、JSONDecoder.swift、PropertyListEncoder.swift

整体架构

在开始深入之前，先建立整体印象。Codable 可以拆成三层角色：

用户类型层：业务中的 struct / class / enum，声明遵循 Codable
标准库与编译器层：标准库定义 Encodable / Decodable / Encoder / Decoder 等协议，编译器为符合条件的类型合成 encode(to:) 和 init(from:)
格式实现层：Foundation 或第三方提供具体 Encoder / Decoder，负责把容器操作落到 JSON、Plist、BSON 等格式上

flowchart LR
subgraph L1[用户类型层]
A[struct / class / enum
声明遵循 Codable]
end
subgraph L2[标准库与编译器层]
B[Encodable / Decodable
协议要求]
C["编译器合成
encode(to:) / init(from:)"]
D[Encoder / Decoder
容器协议]
B --> C
C --> D
end
subgraph L3[格式实现层]
E[JSONEncoder / JSONDecoder
PropertyListEncoder / 第三方实现]
F[Data / 字符串 / 其他格式]
E --> F
end
A -->|conforms to| B
D -->|由具体类型实现| E

核心思想是：标准库只定义"如何描述一个可编码类型"和"编码器需要提供什么能力"，具体的格式（JSON、Plist、BSON…）由 Foundation 或第三方实现。用户类型只需要遵循协议，剩下的由编译器在 SIL 层自动生成。

KVC底层原理

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

基础概念

KVC（Key-Value Coding，键值编码）是 Apple 提供的一种通过字符串 key 间接访问对象属性的机制，定义在 NSKeyValueCoding 协议中，NSObject 默认遵循该协议。

// 直接访问
person.name = @"Tom";
NSString *name = person.name;

// KVC 访问
[person setValue:@"Tom" forKey:@"name"];
NSString *name = [person valueForKey:@"name"];

KVC 的核心价值在于：通过字符串动态访问属性，不需要在编译期知道属性名。这使得字典转模型、序列化/反序列化、Interface Builder 的 Runtime Attributes 等场景成为可能。

setValue:forKey: 的底层流程

当调用 [obj setValue:value forKey:@"name"] 时，Runtime 按照以下顺序查找：

flowchart TD
A["setValue:forKey:@'name'"] --> B{"查找 setter 方法"}
B -->|"找到"| C["调用 setter"]
B -->|"未找到"| D{"accessInstanceVariablesDirectly
返回 YES?"}
D -->|"YES"| E{"按顺序查找实例变量
_name → _isName → name → isName"}
D -->|"NO"| F["调用 setValue:forUndefinedKey:
默认抛出 NSUndefinedKeyException"]
E -->|"找到"| G["直接设置实例变量值"]
E -->|"未找到"| F

第一步：查找 setter 方法

Runtime 按以下顺序查找 setter 方法：

KVO底层原理

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

基础概念

KVO（Key-Value Observing，键值观察）是 Apple 基于 KVC 实现的一种观察者模式，允许对象监听另一个对象特定属性的变化。当被观察对象的属性值发生改变时，观察者会收到通知。

// 注册观察
[person addObserver:self
 forKeyPath:@"name"
 options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
 context:nil];

// 接收通知
- (void)observeValueForKeyPath:(NSString *)keyPath
 ofObject:(id)object
 change:(NSDictionary<NSKeyValueChangeKey, id> *)change
 context:(void *)context {
 if ([keyPath isEqualToString:@"name"]) {
 NSLog(@"name changed: %@ → %@", change[NSKeyValueChangeOldKey], change[NSKeyValueChangeNewKey]);
 }
}

// 移除观察
- (void)dealloc {
 [person removeObserver:self forKeyPath:@"name"];
}

KVO 的底层实现原理：isa-swizzling

KVO 的核心实现机制是 isa-swizzling（isa 指针替换）。当对象被添加观察者时，Runtime 会在运行时动态创建该对象所属类的一个子类，并将对象的 isa 指针指向这个新的子类。

完整流程

flowchart TD
A["addObserver:forKeyPath:"] --> B["Runtime 动态创建子类
NSKVONotifying_ClassName"]
B --> C["重写被观察属性的 setter 方法"]
B --> D["重写 class 方法
返回原始类"]
B --> E["重写 dealloc 方法"]
B --> F["重写 _isKVOA 方法
返回 YES"]
C --> G["将对象的 isa 指向
NSKVONotifying_ClassName"]
G --> H["当属性值改变时"]
H --> I["调用 willChangeValueForKey:"]
I --> J["调用原始 setter 方法"]
J --> K["调用 didChangeValueForKey:"]
K --> L["通知所有观察者"]

第一步：动态创建子类

当首次对某个类的实例调用 addObserver:forKeyPath:options:context: 时，Runtime 会：

Mach-O的链接、装载与库

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

本文深入介绍iOS/macOS开发中的Mach-O文件格式、动态库与静态库，帮助理解程序的链接、装载过程，以及Rebase/Bind的底层原理。

一、基础概念

在深入学习之前，先了解几个核心概念。

1.0 从源代码到可执行文件

一段源代码要变成可执行文件，需要经历以下几个阶段：

flowchart TB
A["源代码 (.m/.swift)"] --> B["预处理
展开宏、处理#import/#include"]
B --> C["编译
源代码 → 汇编代码"]
C --> D["汇编
汇编代码 → 目标文件(.o)"]
D --> E["链接
目标文件 + 库 → 可执行文件"]
E --> F["可执行文件"]

1.1 什么是符号（Symbol）

符号是程序中函数、变量、类等实体的名称标识。当你写下一个函数调用时，编译器需要知道这个函数在哪里，符号就是用来定位它的。

// 这段代码中包含多个符号
void myFunction(void) { // 定义了符号 _myFunction
 NSLog(@"Hello"); // 引用了外部符号 _NSLog
}

int globalVar = 10; // 定义了符号 _globalVar

符号分为两类：

已定义符号：在当前编译单元（即当前源文件编译生成的.o文件）中有具体代码或数据定义的符号（如上例中的 _myFunction 和 _globalVar）
未定义符号：当前编译单元只是引用，实际定义在其他编译单元或库中的符号（如上例中的 _NSLog），需要在链接时解析

1.2 什么是链接（Linking）

链接是将多个编译后的目标文件（.o）组合成一个可执行文件的过程。链接器的核心工作是符号解析——把所有"未定义符号"与其他编译单元中的"已定义符号"关联起来。

flowchart LR
subgraph 输入
A["main.o
已定义: _main
未定义: _foo"]
B["foo.o
已定义: _foo
未定义: _NSLog"]
C["Foundation
已定义: _NSLog"]
end
A --> D["链接器
符号解析"]
B --> D
C --> D
D --> E["可执行文件
所有符号已解析"]

符号解析的过程

链接器会遍历所有输入的目标文件和库，执行以下步骤：

Objective-C与Swift区别

Fri, 08 May 2026 13:07:14 +0800

语言设计

Objective-C

是C的超集，在C的基础上添加了Smalltalk风格的消息传递机制
对象间交互不通过调用方法而是发送消息，以实现面向对象编程和超高的动态性
动态性由 Objective-C Runtime 系统支持，可以在运行时修改类结构、方法交换等，详见 Runtime
弱类型语言，核心类型id可以指向任何Objective-C对象

Swift

从很多现代化语言中汲取精华，是一门偏重于安全、性能的现代化语言
Swift 也有自己的运行时系统（Swift Runtime），但设计哲学完全不同，更强调编译期优化
强类型语言，编译器在编译阶段进行严格的类型检查

语法特性

Objective-C

语法冗长，需要显式声明类型
命名通常较长且需要添加前缀避免冲突
需要单独的.h和.m文件声明接口和实现
引用其他文件/模块必须要import（Objective-C中import详解）
协议不支持默认实现
泛型是"轻量级泛型"，仅用于编译时类型检查，运行时类型信息会被擦除

Swift

语法简洁，强大的类型推断减少冗余的类型声明
有命名空间（模块）的存在避免命名冲突
不需要单独的头文件声明接口
默认情况下变量必须初始化
引用同模块的其他文件不需要import（Swift中import详解）
协议支持默认实现、支持拓展，支持关联类型以实现泛型协议
值类型也可以遵守协议
泛型在编译时进行类型特化优化，支持完整的泛型元编程

内存管理

Objective-C

大部分都是引用类型，依赖引用计数管理内存
ARC在编译时自动插入retain、release、autorelease调用
64位系统使用优化的isa（Non-pointer isa），通过位域在isa中嵌入引用计数（extra_rc字段），溢出时使用SideTable存储
实例变量（ivar）会被Runtime自动初始化为0/nil

Swift

引用类型也是依赖引用计数管理内存
存在大量的值类型，例如结构体、枚举、数组、字典等
非逃逸的值类型的内存存在栈区由系统进行自动管理
纯Swift类的引用计数直接存储在对象头部的RefCount字段中，无需SideTable，访问更高效
编译器在编译时就确保了初始化，不需要运行时统一清零

拓展：值类型和引用类型的区别拓展：iOS中的内存管理

性能对比

Objective-C

基于消息传递机制本质上是动态派发，运行时查找方法实现，有一定开销
ARC管理引用计数也有开销
引用类型内存存在堆区，内存管理的性能开销会比栈区多很多

Swift

方法派发尽可能使用静态派发（如对final类/方法、私有方法、值类型方法的调用）
编译器可以内联优化，速度接近C
- 内联优化：比如A方法调用B方法，B方法调用C方法，代码编写调用A方法时编译器通过内联直接调用C方法的实现
值类型内存分配在栈区，性能开销相对较小
虽然值类型是深拷贝，Swift为了优化值类型性能引入写时拷贝（Copy-on-Write）机制，值类型只在写操作发生深拷贝，其他时候都是浅拷贝

安全性

Objective-C

弱类型（动态类型）占主导
核心类型id可以指向任何Objective-C对象
编译器几乎不做类型检查，会有运行时崩溃的风险（如向不响应某消息的对象发送该消息）
nil消息发送不会崩溃但可能导致逻辑错误，不容易感知
局部变量不会自动初始化，可能包含栈上的垃圾数据（未定义行为）

Swift

可选类型强制处理空值，编译器强制解包检查
强类型和编译时检查阻止了大量常见错误
变量必须初始化后才能使用，编译器在编译阶段强制检查，消除未定义行为
强制初始化使编译器能更精确地追踪变量生命周期，带来更多优化机会
数组越界等操作会在运行时触发明确的崩溃，便于定位问题

编程范式

Objective-C

主要是面向对象编程（OOP）
通过继承实现代码复用
依赖Runtime实现面向切面编程（AOP），如Method Swizzling

Swift

拥抱多范式，对函数式编程、面向协议编程（POP）、声明式编程很友好
通过协议扩展提供默认实现，协议组合替代多继承
值类型（struct/enum）也可以遵循协议，不再局限于类

拓展：OOP、POP与AOP

iOS中import详解

Mon, 08 Jun 2026 23:06:52 +0800

源码版本说明：本文涉及的源码基于 LLVM/Clang 23.0.0 开发版本（llvm-project main分支，commit: 301c0d91b558，2026-01-16）。不同版本的实现细节可能略有差异，但核心机制保持一致。

在Objective-C开发中，头文件引用是日常开发中最基础的操作之一。本文将从Clang编译器的角度，深入讲解iOS中各种import方式的区别、底层查找原理以及最佳实践。

引用方式	语法示例	适用场景
#include	`#include "Header.h"`	C/C++传统方式
#import	`#import "Header.h"`	Objective-C项目内部引用
#import	`#import <Framework/Header.h>`	系统/第三方Framework
@import	`@import Foundation;`	Clang Modules方式
PCH	Prefix Header文件	预编译公共头文件

#include vs #import

#include的工作原理

#include是C/C++中的头文件引用方式，它的工作原理非常简单：预处理器会将目标头文件的内容原封不动地复制粘贴到当前文件中。

这种方式存在一个问题：重复引用。如果多个文件都include了同一个头文件，或者存在循环引用，会导致编译错误。传统的解决方案是使用Include Guard：

// Header.h
#ifndef HEADER_H
#define HEADER_H
// 头文件内容
#endif

现代编译器还支持#pragma once指令，功能相同但更简洁：

// Header.h
#pragma once
// 头文件内容

#import的增强

#import是Objective-C对#include的封装和增强。它在#include的基础上增加了一层判重逻辑，自动防止同一个头文件被重复引用。

// BClass.m
#import "AClass.h"
#import "AClass.h" // 第二次import会被自动忽略

双引号 vs 尖括号

在日常开发中，我们经常会看到两种不同的引用方式：

#import "MyClass.h" // 双引号形式
#import <UIKit/UIKit.h> // 尖括号形式

它们的核心区别在于搜索路径的范围不同：

Objective-C底层原理 - NSObject

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

本文将深入探讨Objective-C中所有对象的基类NSObject的底层实现原理，涵盖对象本质、isa指针机制、Tagged Pointer、引用计数、内存布局等核心概念。

NSObject 的本质：C 结构体

在Objective-C的底层实现中，NSObject的本质是一个C结构体。在苹果运行时源码中可以看到：

// 底层运行时定义
struct objc_object {
 Class isa; // 指向对象所属类的指针
};

// 类型别名定义
typedef struct objc_object NSObject;

这意味着，当我们通过NSObject *obj = [[NSObject alloc] init];创建一个 NSObject 实例时，实际上在堆上分配了一个struct objc_object结构体，而变量obj只是一个指向该结构体的指针。

// 这行代码在底层实际上做了类似下面的事情：
NSObject *obj = [[NSObject alloc] init];

// 等效的伪C代码:
// 1. 调用 alloc 类方法，其核心是调用 malloc 在堆上分配一块足够大的内存
// 大小至少是 sizeof(struct objc_object)，即一个isa指针的大小
NSObject *obj = (NSObject *)malloc(sizeof(struct objc_object));

// 2. 初始化这块内存，最重要的是设置 isa 指针，让它指向 NSObject 这个类
obj->isa = [NSObject class]; // 实际过程更复杂，但本质如此

// 3. 其他初始化工作 (init)

那么这里提到的isa指针是什么呢？

SIL（Swift Intermediate Language）

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

SIL（Swift Intermediate Language，Swift 中间语言）是 Swift 编译器在编译过程中生成的一种中间表示（Intermediate Representation，IR）。它位于 Swift 源码与 LLVM IR 之间，是 Swift 编译器架构中至关重要的一层。

SIL 的设计目标是：

对 Swift 语言的高级语义进行精确建模
在高层抽象的基础上执行强大的优化
保留足够的类型信息，用于诊断和安全检查
作为 Swift 特有优化的载体，弥补 LLVM IR 无法直接表达 Swift 语义的不足

SIL 并不是给开发者日常编写的语言，而是编译器的内部表示。理解它有助于深入理解 Swift 的编译过程、性能优化原理和内存管理机制。

Swift 编译流程概览

在了解 SIL 之前，需要先理解 Swift 的整体编译流程：

flowchart TD
A[Swift 源代码 .swift] --> B[词法分析 Lexer]
B --> C[语法分析 Parser]
C --> D[语义分析 Sema]
D --> E[SILGen: 生成 Raw SIL]
E --> F[SIL 优化 Guaranteed Passes]
F --> G[SIL 优化 General Passes]
G --> H[IRGen: 生成 LLVM IR]
H --> I[LLVM 优化]
I --> J[机器码 .o]
J --> K[链接器 Linker]
K --> L[可执行文件 / 动态库]

各阶段简述

词法分析（Lexer）

编译的第一步。Lexer 逐字符扫描 .swift 源文件，将其切分为一系列Token（词法单元），例如关键字 func、标识符 add、运算符 +、字面量 42、左右括号等。Token 是后续所有分析的最小输入单位。这一步会剥离注释和空白，但保留它们的位置信息以便后续生成精确的诊断信息（错误提示的行号和列号）。

Swift中import详解

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

源码版本说明：本文涉及的源码基于 Swift 编译器 开发版本（swift main分支，commit: e0db5152d4d4，2026-01-19）。不同版本的实现细节可能略有差异，但核心机制保持一致。

在前一篇文章Objective-C中import详解中，我们深入探讨了 Objective-C 中的 import 机制，包括 #include、#import、@import 以及 Clang Modules 的工作原理。本文将继续从 Swift 编译器的角度，讲解 Swift 中 import 的语法、模块查找机制、底层实现原理以及与 Objective-C 的互操作。

从 Clang Module 到 Swift Module

在深入 Swift 的 import 机制之前，让我们先回顾一下上一篇文章中 Clang Module 的核心概念。

Clang Module 核心概念回顾

在 Objective-C 文章中，我们学习了 Clang Module 的几个关键特性：

module.modulemap：定义模块结构的配置文件

framework module Foundation {
 umbrella header "Foundation.h"
 export *
}

预编译模块缓存（.pcm 文件）：Clang 将模块编译为二进制格式，缓存以加速后续编译
懒加载机制：只加载实际使用的声明，未使用的部分不会被解析
自动链接：@import 会自动链接对应的库，无需手动配置
模块查找路径：通过 -I、-F 等参数指定搜索路径

Swift 如何继承 Clang Module 的设计

Swift 的模块系统并非从零开始设计，而是站在 Clang Module 的肩膀上，继承了其核心优势，并针对 Swift 的特性进行了扩展：

Swift二进制兼容性

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

Swift二进制兼容性是指Swift编译后的二进制代码能够跨版本、跨模块正确链接和运行的能力。它由三个核心机制组成：ABI稳定（Swift 5.0）、模块稳定性（Swift 5.1）和Library Evolution。这三者共同使得Swift二进制框架的分发成为可能。

graph TD
A[Swift二进制兼容性] --> B[ABI稳定
Swift 5.0]
A --> C[模块稳定性
Swift 5.1]
A --> D[Library Evolution]
B --> B1[统一运行时
固定调用约定/内存布局]
C --> C1[.swiftinterface
跨编译器版本导入模块]
D --> D1[运行时布局查询
库可独立于客户端更新]
B1 --> E[二进制框架分发]
C1 --> E
D1 --> E

ABI稳定

什么是ABI

ABI（Application Binary Interface，应用程序二进制接口）定义了二进制层面的接口规范，包括：

数据类型的大小和对齐方式：如Int在64位系统上是8字节
函数调用约定：参数如何传递、返回值如何获取
名称修饰（Name Mangling）规则：函数和类型在二进制中的命名方式
内存布局：对象在内存中的结构
异常处理机制：错误如何在二进制层面传播
运行时元数据格式：类型信息的存储方式

ABI vs API

特性	API（源码接口）	ABI（二进制接口）
层面	源代码层面	编译后的二进制层面
兼容性检查	编译时	链接时/运行时
关注点	函数签名、类型定义	内存布局、调用约定
变化影响	需要重新编译	需要重新链接或替换二进制

一个简单的例子：

// API层面：函数签名
func calculate(value: Int) -> Int

// ABI层面关注的是：
// - Int在内存中占多少字节
// - value参数通过哪个寄存器传递
// - 返回值通过哪个寄存器返回
// - 函数在二进制中的符号名是什么

ABI不稳定时期的问题

在Swift 5.0之前，Swift的ABI是不稳定的。这意味着：

Swift 宏

Mon, 04 May 2026 00:38:29 +0800

Swift 5.9（WWDC 2023）引入的宏（Macro）是近几年语言层最大的一次能力扩展。它让 Swift 第一次具备了编译期代码生成的官方机制——你可以在源码层面写一段"能生成代码的代码"，编译器会在类型检查前把它展开成真正的 Swift 源码，再走正常的编译流程。SwiftUI 的 #Preview、Observation 框架的 @Observable、SwiftData 的 @Model、Swift Testing 的 @Test / #expect、FoundationModels 的 @Generable / @Tool，全都是宏。

一、为什么要有宏

1.1 Swift 之前能做什么，又差在哪

在宏之前，Swift 已经有一整套"元编程"手段，但每一种都有明显的边界：

机制	做什么	局限
`@propertyWrapper`	给属性注入行为（如 `@Published`、`@State`）	只能包属性，不能生成方法、不能生成类型、不能访问其他成员
`@resultBuilder`	把一段 DSL 收集成表达式（如 SwiftUI 的 `ViewBuilder`）	只作用于闭包里，无法改类型定义
KeyPath + Mirror	运行时反射读写属性	只能读，类型安全差，性能差（见 iOS反射）
Codable 等编译器魔法	自动合成 `init(from:)` / `encode(to:)`	只有编译器内部能写，开发者写不出同等能力的东西
Sourcery / SwiftGen	文本级代码生成	游离于编译器之外，无类型信息、无法访问 AST
Objective-C `#define`	纯文本替换	没有作用域、没有类型、没有卫生（hygiene），对调试器和 IDE 极不友好

宏就是要一次性补齐这块能力：在保留类型安全与 IDE 体验的前提下，把"只有 Swift 编译器团队能写的代码生成"开放给所有开发者。

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

Wed, 06 May 2026 22:05:01 +0800

在Objective-C底层原理-NSObject文章中，我们深入了解了Objective-C对象的底层实现。本文将探讨Swift中类和结构体的底层原理。

Swift数据结构的分类

Swift中的类根据是否继承自NSObject，在底层实现上存在显著差异：

继承自NSObject的Swift类：兼容Objective-C运行时，支持完整的Objective-C特性
纯Swift类：使用Swift原生运行时，性能更优但Objective-C互操作性受限

Swift中结构体是值类型，具有以下核心特征：

栈上分配内存（非逃逸情况）
值语义和完整拷贝
写时拷贝优化（COW）
静态方法派发

Swift类的底层实现

继承自NSObject的Swift类

当Swift类继承自NSObject时，必须兼容Objective-C的运行时系统，其底层实现与Objective-C对象高度一致。

内存布局

class Class: NSObject {
 var name: String
 var isMale: Bool
 var age: Int

 init(name: String, isMale: Bool, age: Int) {
 self.name = name
 self.isMale = isMale
 self.age = age
 super.init()
 }
}

实例内存布局：

偏移量	内容	大小	说明
0x0-0x7	isa_t isa	8字节	指向类对象，包含优化的位域信息
0x8-0x17	String name	16字节	Swift String结构（64位系统）
0x18	Bool isMale	1字节	布尔值
0x19-0x1F	(padding)	7字节	Swift编译器根据下一个字段（Int，8字节对齐要求）自动插入填充，确保Int字段从8的倍数地址开始
0x20-0x27	Int age	8字节	64位整数
0x28-0x2F	(padding)	8字节	最终内存对齐填充

关键特性：

iOS 定时器的注意事项

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

iOS 开发中常用的定时器有 NSTimer、CADisplayLink 和 GCD Timer。它们各有特点，但在使用时都有一些需要注意的问题。

常见定时器类型

1. NSTimer

最常用的定时器，基于 RunLoop 实现：

// 自动添加到当前 RunLoop 的 DefaultMode
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1.0
 target:self
 selector:@selector(timerFired)
 userInfo:nil
 repeats:YES];

// 手动创建，需要手动添加到 RunLoop
NSTimer *timer = [NSTimer timerWithTimeInterval:1.0
 target:self
 selector:@selector(timerFired)
 userInfo:nil
 repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];

2. CADisplayLink

与屏幕刷新率同步的定时器，适合做动画：

CADisplayLink *displayLink = [CADisplayLink displayLinkWithTarget:self
 selector:@selector(update)];
[displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

3. GCD Timer

不依赖 RunLoop，精度更高：

dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0);
dispatch_source_set_event_handler(timer, ^{
 NSLog(@"GCD Timer fired");
});
dispatch_resume(timer);

注意事项一：循环引用问题

问题描述

NSTimer 和 CADisplayLink 在使用 target-action 模式时，会强引用 target。如果 target 又持有定时器，就会形成循环引用：

iOS中的内存管理

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

本文将系统介绍iOS中的内存管理机制，从程序内存布局、引用计数原理、ARC机制到系统级内存管理，帮助你建立完整的iOS内存管理知识体系。

一、程序内存布局

内存区域划分

在iOS应用程序中，内存按照用途和管理方式分为以下几个区域：

高地址
┌─────────────────────────────────────┐
│ 栈区 (Stack) │ ↓ 向低地址增长
│ 局部变量、函数参数、返回地址 │
├─────────────────────────────────────┤
│ ↕ │
│ 动态分配区 │
│ ↕ │
├─────────────────────────────────────┤
│ 堆区 (Heap) │ ↑ 向高地址增长
│ 动态分配的对象实例 │
├─────────────────────────────────────┤
│ 全局/静态区 (BSS) │
│ 未初始化的全局变量和静态变量 │
├─────────────────────────────────────┤
│ 数据区 (Data) │
│ 已初始化的全局变量和静态变量 │
├─────────────────────────────────────┤
│ 常量区 (Rodata) │
│ 字符串常量等 │
├─────────────────────────────────────┤
│ 代码区 (Text) │
│ 编译后的代码 │
└─────────────────────────────────────┘
低地址

各区域的特点：

iOS中的数据库

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

数据持久化是移动端开发的核心能力之一。iOS提供了从轻量级KV存储到完整关系数据库的多层次方案。本文将从底层存储原理出发，系统性地梳理iOS中各类数据库与持久化技术的设计思想、实现机制和适用场景。

一、iOS数据持久化方案全景

iOS中常见的数据持久化方案，按数据复杂度和使用场景可分为以下几层：

graph TD
subgraph KV["轻量级KV存储"]
A["UserDefaults
plist序列化"]
B["Keychain
加密存储"]
C["MMKV
mmap + protobuf"]
end
subgraph FILE["文件存储"]
D["plist / JSON"]
E["NSCoding / Codable
归档"]
end
subgraph SQL["关系数据库"]
F["SQLite
C语言API"]
G["FMDB
OC封装"]
H["WCDB
ORM + 加密"]
end
subgraph ORM["ORM框架"]
I["Core Data
Apple官方"]
J["Realm
零拷贝"]
K["SwiftData
Swift原生"]
end
KV --> |"数据结构更复杂"| FILE
FILE --> |"需要结构化查询"| SQL
SQL --> |"需要对象映射"| ORM

方案	数据模型	查询能力	线程安全	加密	适用场景
UserDefaults	KV (plist类型)	Key查找	线程安全	无	用户偏好、简单配置
Keychain	KV (Data)	Key查找	线程安全	系统加密	密码、Token、证书
MMKV	KV (protobuf)	Key查找	线程安全	可选AES	高频读写的KV数据
plist/JSON文件	字典/数组	无	不安全	无	静态配置、缓存
NSCoding/Codable	对象图	无	不安全	无	对象序列化
SQLite	关系表	SQL	需手动处理	可选(SQLCipher)	结构化数据、复杂查询
FMDB	关系表	SQL	FMDatabaseQueue	可选	SQLite的OC封装
WCDB	关系表+ORM	SQL+ORM	自动管理	内置	高性能结构化存储
Core Data	对象图	NSPredicate	NSManagedObjectContext	无	复杂对象关系
Realm	对象	类型安全查询	对象冻结	可选AES	高性能对象存储
SwiftData	Swift对象	#Predicate宏	ModelContext	无	Swift原生数据持久化

二、轻量级KV存储

2.1 UserDefaults

UserDefaults是iOS最常用的轻量级存储方案，底层将数据以plist格式序列化到磁盘。

iOS反射

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

反射（Reflection）是指程序在运行时检查、访问和修改自身结构（类型、属性、方法等）的能力。在 iOS 开发中，Objective-C 和 Swift 分别提供了不同层次的反射支持：OC 依赖 Runtime 提供完整的动态反射能力，Swift 则通过 Mirror 提供只读的内省能力。

Objective-C 的反射能力

Objective-C 的反射能力完全建立在 Runtime 之上。Runtime 在运行时维护了完整的类型元数据（类对象、元类对象、方法列表、属性列表、成员变量列表、协议列表等），并通过一系列 C 函数 API 暴露给开发者，使得程序可以在运行时动态地查询和修改几乎所有类型信息。

关于 Runtime 的消息发送、消息转发、Method Swizzling、关联对象等核心能力，请参考 runtime。本节聚焦于 Runtime 中与"反射"直接相关的能力——即运行时的类型内省和动态操作。

类型内省

类型内省（Introspection）是反射中最基础的能力——在运行时查询一个对象的类型信息。

NSObject 提供的内省方法

NSObject 定义了一组内省方法，这些方法底层都依赖 Runtime 的 isa 指针和类型元数据来实现：

id obj = [[NSMutableArray alloc] init];

// 类型判断
[obj isKindOfClass:[NSArray class]]; // YES — 判断是否是某个类或其子类的实例
[obj isMemberOfClass:[NSMutableArray class]]; // YES — 判断是否是某个类的直接实例
[obj conformsToProtocol:@protocol(NSCoding)]; // YES — 判断是否遵循某个协议

// 方法响应检查
[obj respondsToSelector:@selector(addObject:)]; // YES — 判断是否能响应某个消息

// 获取类型信息
NSStringFromClass([obj class]); // @"__NSArrayM"（真实的私有子类名）
NSStringFromSelector(@selector(count)); // @"count"

需要注意 isKindOfClass: 和 isMemberOfClass: 的区别：前者沿继承链向上查找，后者只比较当前类。另外，[obj class] 返回的可能是私有子类（如类簇 NSArray 的实际类是 __NSArrayI 或 __NSArrayM），而 object_getClass(obj) 能获取真正的 isa 指向的类（KVO 场景下会是 NSKVONotifying_ 前缀的子类）。

iOS编译原理

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

编译器架构：LLVM 与 Clang

iOS 开发中的两种主要语言 Objective-C 和 Swift 都基于 LLVM 编译器基础设施。理解 LLVM 的架构是理解 iOS 编译原理的基础。

LLVM 的三段式架构

LLVM 采用经典的前端-中间表示-后端三段式设计，将编译过程解耦为三个独立的阶段：

flowchart LR
subgraph Frontend["前端（Frontend）"]
direction TB
A1["Clang（OC/C/C++）"]
A2["Swift 前端"]
end
subgraph Middle["中间表示"]
direction TB
B1["LLVM IR"]
end
subgraph Backend["后端（Backend）"]
direction TB
C1["arm64（iOS真机）"]
C2["x86_64（模拟器）"]
end
A1 --> B1
A2 --> B1
B1 --> C1
B1 --> C2

阶段	职责	iOS 中的实现
前端（Frontend）	词法分析、语法分析、语义分析，将源码转换为中间表示	Clang（OC/C/C++）、Swift 前端
中间表示（IR）	与语言无关、与平台无关的中间形式，承载优化	LLVM IR（Swift 还有额外的 SIL 层）
后端（Backend）	将 IR 转换为目标平台的机器码	arm64（真机）、x86_64（Intel 模拟器）

三段式架构的核心优势是解耦：新增一门语言只需实现一个前端，新增一个目标平台只需实现一个后端，所有语言和平台共享同一套优化基础设施。这正是 Apple 能同时支持 OC 和 Swift 两种语言、多种架构（arm64、x86_64）的技术基础。

+load与+initialize的区别

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

+load和+initialize是Objective-C中两个特殊的类方法，它们都会被Runtime自动调用，但调用时机、调用方式和使用场景有很大区别。理解它们的差异对于iOS开发和性能优化非常重要。

基本定义

+load方法

+load方法在类被加载到内存时由Runtime自动调用，发生在main函数执行之前。

@implementation MyClass
+ (void)load {
 NSLog(@"MyClass loaded");
}
@end

+initialize方法

+initialize方法在类第一次收到消息时由Runtime自动调用，是一种懒加载机制。

@implementation MyClass
+ (void)initialize {
 NSLog(@"MyClass initialized");
}
@end

核心区别对比

特性	+load	+initialize
调用时机	main函数之前，类加载时	类首次收到消息时
调用方式	直接调用函数指针	通过objc_msgSend
调用次数	每个类只调用一次	可能被调用多次
是否阻塞启动	是	否
是否需要显式调用父类	否，自动调用	否，自动调用
Category的行为	都会被调用	会覆盖主类实现
线程安全	是	是
调用顺序	父类 -> 子类 -> Category	父类 -> 子类
未实现时的行为	不调用	可能调用父类实现

调用时机详解

+load的调用时机

+load的调用发生在dyld加载镜像的过程中：

dyld加载Mach-O
 ↓
映射到内存
 ↓
读取__DATA段中的__objc_nlclslist（非懒加载类列表）
 ↓
调用所有类的+load方法
 ↓
读取__objc_nlcatlist（非懒加载分类列表）
 ↓
调用所有分类的+load方法
 ↓
main()函数执行

+initialize的调用时机

+initialize在类第一次收到消息时调用：

mmap详解

Thu, 07 May 2026 10:26:09 +0800

mmap（Memory-mapped file，内存映射文件）是一种将文件或设备映射到进程地址空间的技术。通过mmap，可以像操作内存一样操作文件，是iOS开发中实现高性能IO的重要手段。

基本概念

什么是mmap

mmap是一个POSIX系统调用，它在进程的虚拟地址空间中创建一个映射，将文件内容映射到内存地址。映射建立后，对该内存区域的读写操作会直接反映到文件上。

文件映射：将磁盘上的普通文件映射到内存，用于高效读写文件内容（iOS开发中最常用）
设备映射：将硬件设备的I/O内存（如显卡显存、网卡缓冲区）映射到用户空间，让程序可以像读写内存一样直接与硬件交互，常用于驱动开发和嵌入式系统

flowchart LR
subgraph traditional["传统文件IO (read/write)"]
direction LR
U1["用户缓冲区"] <-- "② 数据拷贝" --> K1["内核缓冲区"]
K1 <-- "① 磁盘读取" --> F1["磁盘文件"]
end
subgraph mmap_io["mmap 内存映射"]
direction LR
U2["虚拟地址空间
映射区域"] <-. "直接映射
零拷贝" .-> F2["磁盘文件"]
end
traditional ~~~ mmap_io

方式	数据流向	拷贝次数
传统IO	磁盘 → 内核缓冲 → 用户缓冲	2次
mmap	磁盘 ↔ 映射区域（直接访问）	0次

mmap的工作原理

flowchart TD
A["调用mmap()"] --> B["内核在进程虚拟地址空间
分配一段连续地址"]
B --> C["建立虚拟地址到文件的映射关系
（页表项指向文件页）"]
C --> D["返回映射区域的起始地址"]
D --> E["进程访问映射地址"]
E --> F{"页面是否在内存中?"}
F -- 否 --> G["触发缺页中断
(Page Fault)"]
G --> H["内核从磁盘读取对应页面
到物理内存"]
H --> I["更新页表，建立映射"]
I --> J["进程继续访问"]
F -- 是 --> J
J --> K["读写操作直接作用于内存"]
K --> L["内核适时将脏页
写回磁盘"]

API详解

mmap函数原型

#include <sys/mman.h>

void *mmap(
 void *addr, // 建议的映射起始地址，通常传NULL让系统决定
 size_t length, // 映射区域的长度（字节）
 int prot, // 内存保护标志（可读/可写/可执行）
 int flags, // 映射类型标志
 int fd, // 文件描述符
 off_t offset // 文件偏移量（必须是页大小的整数倍）
);

// 返回值：成功返回映射区域的起始地址，失败返回MAP_FAILED

参数详解

prot（内存保护标志）：

RunLoop

Wed, 27 May 2026 22:24:03 +0800

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

简单来说，RunLoop 就是一个 do-while 循环：

// 伪代码
void CFRunLoopRun() {
 do {
 // 处理各种事件源
 // 如果没有事件，线程休眠
 // 有事件时被唤醒处理
 } while (running);
}

RunLoop 与线程的关系

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

// 获取当前线程的 RunLoop
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];

// 获取主线程的 RunLoop
CFRunLoopRef mainRunLoop = CFRunLoopGetMain();
NSRunLoop *mainRunLoop = [NSRunLoop mainRunLoop];

RunLoop 的核心组成

RunLoop 包含以下几个核心概念：

1. RunLoop 对象（CFRunLoopRef）

RunLoop 对象本身，管理整个事件循环。在代码层面对应 CFRunLoopRef 类型。

Runtime

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

什么是 Runtime

Runtime 是 Objective-C 的运行时系统，是一套底层的 C 语言 API。Objective-C 是一门动态语言，很多操作都是在运行时而非编译时决定的，这一切都依赖于 Runtime。

Runtime 提供的核心能力：

消息发送与转发
方法交换（Method Swizzling）
关联对象（Associated Objects）
动态创建类和对象
动态添加和修改方法、属性

关于对象、类、isa 指针等底层数据结构的详细介绍，请参考 Objective-C底层原理-NSObject。本文专注于 Runtime 的动态能力和实际应用。

消息发送机制

Objective-C 的消息发送机制是其动态性的核心体现。与 Swift 支持静态派发不同，Objective-C 的方法调用都是动态消息派发。更多关于两者的对比，请参考 Objective-C与Swift区别。

objc_msgSend

Objective-C 的方法调用本质上是消息发送，编译器会将方法调用转换为 objc_msgSend 函数：

// 源代码
[obj doSomething];

// 编译后
objc_msgSend(obj, @selector(doSomething));

消息发送流程

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

方法缓存

为了提高消息发送效率，Runtime 在类对象中使用哈希表缓存最近调用的方法：

static关键字详解

Sun, 03 May 2026 23:11:47 +0800

基础概念

static 是 C 语言定义的存储类说明符（Storage Class Specifier），Objective-C 和 Swift 中均有使用，但语义有所扩展。它的核心作用可以归纳为两点：

改变存储位置：将局部变量从栈区移到数据段，使其在函数返回后依然存活
限制链接可见性：将全局变量或函数的链接属性从 external 改为 internal，使其仅在当前编译单元（.m 文件）内可见

flowchart TD
A["static 关键字"] --> B["修饰局部变量"]
A --> C["修饰全局变量"]
A --> D["修饰函数"]
A --> E["Swift 中的 static"]
B --> B1["存储位置：栈 → 数据段"]
B --> B2["生命周期：函数作用域 → 整个进程"]
B --> B3["作用域不变：仍限于函数内"]
C --> C1["存储位置不变：仍在数据段"]
C --> C2["链接属性：external → internal"]
C --> C3["作用域缩小：全局 → 当前文件"]
D --> D1["存储位置不变：仍在代码段"]
D --> D2["链接属性：external → internal"]
D --> D3["作用域缩小：全局 → 当前文件"]

一、静态局部变量

基本用法

在函数或方法内部用 static 修饰局部变量，使其只初始化一次，后续调用保留上次的值。

weak详解

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

本文将深入探讨iOS中weak引用的实现原理，包括底层数据结构、核心函数实现、生命周期管理，以及weak、unowned、unsafe_unretained三者的对比。

weak的基本概念

weak是一种弱引用修饰符，它不会增加对象的引用计数，也就是说不会持有对象。当对象被释放时，所有指向该对象的weak引用会自动被置为nil，这是weak最核心的特性。

// Objective-C中使用weak
@property (nonatomic, weak) id<SomeDelegate> delegate;

__weak NSObject *weakObj = strongObj;

// Swift中使用weak
weak var delegate: SomeDelegate?

weak var weakObj = strongObj

weak的底层数据结构

要理解weak的实现原理，首先需要了解几个核心数据结构。

SideTable

SideTable是Runtime中非常重要的数据结构。关于SideTable在引用计数存储中的作用，请参考iOS中的内存管理-侧表存储。

struct SideTable {
 os_unfair_lock slock; // 锁，保证线程安全
 RefcountMap refcnts; // 引用计数哈希表
 weak_table_t weak_table; // 弱引用表
};

系统维护了一个固定大小的SideTable数组，称为StripedMap。通过对对象地址做哈希和取模来定位对应的SideTable：

// 通过对象地址获取对应的SideTable
static SideTable& table = SideTables()[obj];

// 内部等效逻辑：index = hash(obj) % StripeCount
// StripeCount为StripedMap的大小

由于对象数量远大于SideTable数量，多个对象会被映射到同一个SideTable，这类似于哈希表中的哈希冲突。这种设计的核心目的是分散锁竞争——每个SideTable拥有独立的锁，不同SideTable上的操作可以并行执行，相比单一全局表大幅提升了多线程性能。

weak_table_t

weak_table_t是存储弱引用关系的哈希表，采用 开放寻址法（线性探测） 解决哈希冲突：

struct weak_table_t {
 weak_entry_t *weak_entries; // 连续分配的数组，作为开放寻址哈希表的底层存储
 size_t num_entries; // 当前已使用的条目数量
 uintptr_t mask; // 容量掩码（= 数组容量 - 1），用于 hash & mask 快速取模
 uintptr_t max_hash_displacement; // 最大哈希冲突偏移量
};

虽然 weak_entries 的类型是 weak_entry_t *（即一块连续内存），但元素不是按顺序填入的——插入时通过 hash(referent地址) & mask 计算目标槽位，冲突时向后线性探测。因此它本质上是一个用数组实现的开放寻址哈希表，而非普通的顺序数组。

值类型和引用类型的区别

Sun, 10 May 2026 22:25:41 +0800

定义

值类型

值类型是指变量直接存储自身字段或描述信息的类型。值类型具有值语义，当将一个值类型变量赋值给另一个变量时，语义上会得到一份独立的值；底层是否立即复制完整数据，取决于编译器优化和写时拷贝等实现。

引用类型

引用类型是指变量存储的是指向数据在内存中位置的引用（指针）。当将一个引用类型变量赋值给另一个变量时，两个变量指向同一块内存区域。

Objective-C中的类型分类

在Objective-C中：

值类型：基础数据类型（int、float、double、BOOL、char等）、结构体（struct）、枚举（enum）
引用类型：除基础数据类型之外的大部分类型，包括NSObject及其子类（NSString、NSArray、NSDictionary、自定义类等）

Swift中的类型分类

Swift对类型的分类更加清晰：

值类型：基础数据类型（Int、Float、Double、Bool等）、字符串（String）、结构体（Struct）、枚举（Enum）、数组（Array）、字典（Dictionary）、集合（Set）等
引用类型：类（Class）、闭包（Closure）、Actor等

拷贝机制差异

值类型 - 值语义拷贝

每个值类型变量都有自己的字段存储
对一个变量的操作不会影响另一个变量
赋值语义上会得到独立副本；如果字段是引用类型，复制的是引用本身，底层也可能通过写时拷贝延迟真正的数据复制

引用类型 - 浅拷贝

引用类型在内存中有一个指向该位置的引用
引用类型的变量可以指向相同类型的数据
对一个变量进行的操作会影响另一变量所指向的数据

内存分配机制

需要注意：值类型/引用类型描述的是语义模型，不等价于栈/堆分配规则。Swift编译器会根据生命周期、逃逸分析、优化级别、协议类型包装、集合存储等因素决定具体放在哪里。

理解Swift对象和字段的内存位置，可以先记住三个规则：

class实例本体通常在堆上，通过引用计数管理生命周期
struct/enum的字段通常内联存储在这个值本身所在的位置
class类型的字段存储的是对象引用，也就是一个指针，真实class实例仍然在堆上

常见存储位置

局部值类型变量：生命周期明确、未逃逸时，通常可以放在当前线程的栈区，甚至被优化到寄存器中
class实例：实例本体在堆区，局部变量中保存的是指向堆对象的引用
class里的struct属性：struct属性内联存储在class实例这块堆内存中
struct里的class属性：struct内部只保存class引用，真实class实例仍然在堆上
被逃逸闭包捕获的值类型可能随闭包上下文一起存储在堆区
Array、Dictionary、Set、String等写时拷贝值类型通常只有一小段描述信息是值本身，真实元素或字符缓冲区可能在堆上
协议类型（existential container）持有大值类型时，如果超过存在容器的内联缓冲区大小，会使用堆分配
indirect enum的间接关联值会通过堆上的盒子存储，常见于递归枚举
全局变量、静态变量不属于栈区，也不是普通意义上的堆对象，它们通常位于全局/静态存储区

栈区内存分配和销毁通常只需移动栈顶指针，成本较低；堆区更动态，但分配、释放和引用计数维护都有额外成本。

struct中包含class属性

class Dog {
 var name: String

 init(name: String) {
 self.name = name
 }
}

struct Person {
 var age: Int
 var dog: Dog
}

var p1 = Person(age: 18, dog: Dog(name: "Lucky"))
var p2 = p1

p2.age = 20
p2.dog.name = "Max"

print(p1.age) // 18
print(p1.dog.name) // Max

内存关系可以近似理解为：

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

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

当手指触碰iPhone屏幕上的一个按钮时，背后经历了从硬件感知、系统传递、命中测试、事件分发到最终响应的完整链路。本文将系统性地拆解iOS事件处理机制的每个环节。

一、响应者与响应者链

理解事件处理的前提是理解"谁有能力处理事件"。在iOS中，这个问题的答案是 响应者（Responder）。

1.1 UIResponder

所有能够接收并处理事件的对象都继承自 UIResponder：

classDiagram
NSObject <|-- UIResponder
UIResponder <|-- UIView
UIResponder <|-- UIViewController
UIResponder <|-- UIApplication
UIView <|-- UIWindow
UIView <|-- UIControl
UIView <|-- UIScrollView
UIControl <|-- UIButton
UIControl <|-- UISlider
UIScrollView <|-- UITableView
class UIResponder {
+nextResponder: UIResponder?
+touchesBegan(touches, event)
+touchesMoved(touches, event)
+touchesEnded(touches, event)
+touchesCancelled(touches, event)
}

UIResponder 定义了处理触摸事件的四个核心方法：

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;

1.2 nextResponder与响应者链

每个 UIResponder 都有一个 nextResponder 属性，指向"下一个响应者"。所有响应者通过这个属性串联成一条 响应者链（Responder Chain）。

iOS多线程编程

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

iOS多线程方案对比

方案	简介	语言	生命周期管理
pthread	POSIX标准的多线程API	C	手动管理
NSThread	面向对象的线程封装	OC/Swift	手动管理
GCD	Grand Central Dispatch	C/OC/Swift	自动管理
NSOperation	基于GCD的面向对象封装	OC/Swift	自动管理

pthread

pthread是POSIX标准的多线程API，是最底层的多线程方案，使用C语言编写。

#import <pthread.h>

void *threadFunction(void *param) {
 NSLog(@"pthread执行任务: %@", [NSThread currentThread]);
 return NULL;
}

- (void)createPthread {
 pthread_t thread;
 pthread_create(&thread, NULL, threadFunction, NULL);
}

特点：

跨平台，可移植性强
使用复杂，需要手动管理线程生命周期
实际开发中很少直接使用

NSThread

NSThread是苹果对pthread的面向对象封装，使用更加简单。

创建线程的方式

// 方式1：实例方法创建，需要手动启动
NSThread *thread = [[NSThread alloc] initWithTarget:self
 selector:@selector(doTask)
 object:nil];
thread.name = @"MyThread";
[thread start];

// 方式2：类方法创建，自动启动
[NSThread detachNewThreadSelector:@selector(doTask)
 toTarget:self
 withObject:nil];

// 方式3：隐式创建
[self performSelectorInBackground:@selector(doTask) withObject:nil];

常用方法

// 获取当前线程
NSThread *currentThread = [NSThread currentThread];

// 获取主线程
NSThread *mainThread = [NSThread mainThread];

// 判断是否是主线程
BOOL isMain = [NSThread isMainThread];

// 线程休眠
[NSThread sleepForTimeInterval:2.0];
[NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:2.0]];

// 退出当前线程
[NSThread exit];

线程间通信

// 回到主线程执行
[self performSelectorOnMainThread:@selector(updateUI)
 withObject:nil
 waitUntilDone:NO];

// 在指定线程执行
[self performSelector:@selector(doTask)
 onThread:thread
 withObject:nil
 waitUntilDone:NO];

GCD（Grand Central Dispatch）

GCD是苹果推出的多线程解决方案，基于C语言实现，自动管理线程的生命周期。GCD的核心概念是 队列（Queue） 和任务（Task）。

布局方法详解

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

本文详细介绍 iOS 中三种布局方式（Frame、Auto Layout、UIStackView）的原理和对比，视图更新的三个阶段（约束、布局、绘制），UIView 与 CALayer 的关系和区别，以及 updateConstraints、layoutSubviews、setNeedsLayout、layoutIfNeeded、setNeedsDisplay 等相关方法的作用、调用时机和区别。

iOS 布局方式

iOS 提供了三种主要的布局方式，按出现时间排列：

布局方式	引入版本	核心思想	API
Frame 布局	iOS 2	直接指定视图的位置和大小	frame、bounds、center
Auto Layout	iOS 6	通过约束描述视图间关系，系统自动计算 frame	NSLayoutConstraint、Anchor API
UIStackView	iOS 9	线性排列子视图，自动管理约束	UIStackView

Frame 布局

直接通过设置 frame 属性来确定视图的位置和大小，是最基础的布局方式。

let label = UILabel()
label.frame = CGRect(x: 20, y: 100, width: 200, height: 44)
view.addSubview(label)

优点：性能最好（无需约束求解），逻辑直观，完全可控。

缺点：需要手动计算所有数值，难以适配不同屏幕尺寸和动态内容，维护成本高。

适用场景：简单固定布局、性能敏感的场景（如 UITableViewCell 内大量视图手动布局）、需要频繁更新 frame 的动画。

Auto Layout

Auto Layout 是基于 约束（Constraint） 的布局系统。开发者不直接设置 frame，而是描述视图之间的关系（如"A 的左边距 B 右边 16pt"），系统通过求解约束方程组自动计算出每个视图的 frame。

iOS中的生命周期

Tue, 05 May 2026 00:41:41 +0800

iOS开发中，理解各种生命周期是非常重要的基础知识。本文将详细介绍应用生命周期、UIViewController生命周期、UIView生命周期，以及其他常见的生命周期。

应用生命周期（App Lifecycle）

应用状态

iOS应用有五种运行状态：

状态	描述
Not Running	应用未启动或已被系统终止
Inactive	应用在前台运行但未接收事件（如来电、锁屏时的过渡状态）
Active	应用在前台运行并接收事件，这是应用的正常运行状态
Background	应用在后台执行代码，通常只有短暂的执行时间
Suspended	应用在后台但不执行代码，系统会在内存不足时自动终止该状态的应用

状态转换图

stateDiagram-v2
[*] --> Not_Running
Not_Running --> Inactive : 启动
Inactive --> Active
Active --> Background
Background --> Inactive
Background --> Suspended
Suspended --> [*]

UIApplicationDelegate 方法（iOS 12及之前）

在iOS 12及之前的版本中，应用生命周期主要通过UIApplicationDelegate协议来管理：

// 应用启动完成
func application(_ application: UIApplication,
 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
 // 初始化配置、第三方SDK等
 return true
}

// 应用即将进入非活动状态
func applicationWillResignActive(_ application: UIApplication) {
 // 暂停正在进行的任务、禁用定时器
 // 游戏应该在此暂停
}

// 应用已进入后台
func applicationDidEnterBackground(_ application: UIApplication) {
 // 释放共享资源、保存用户数据
 // 可以请求额外的后台执行时间
}

// 应用即将进入前台
func applicationWillEnterForeground(_ application: UIApplication) {
 // 撤销进入后台时所做的更改
}

// 应用已变为活动状态
func applicationDidBecomeActive(_ application: UIApplication) {
 // 重启被暂停的任务
 // 如果应用之前在后台，可以刷新UI
}

// 应用即将终止
func applicationWillTerminate(_ application: UIApplication) {
 // 保存数据、清理资源
 // 注意：如果应用从Suspended状态被终止，此方法不会被调用
}

UISceneDelegate 方法（iOS 13+）

从iOS 13开始，Apple引入了Scene-based生命周期，支持多窗口场景。

类型擦除

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

类型擦除（Type Erasure）是一种编程技术，用于在运行时隐藏具体的类型信息，使得不同类型可以通过统一的接口进行操作。在iOS开发中，Objective-C和Swift都有类型擦除的概念，但实现方式和应用场景有所不同。

Swift中的类型擦除

Swift是一门强类型语言，类型信息在编译时被严格检查。但在某些场景下，我们需要隐藏具体类型信息，这时就需要使用类型擦除技术。

存在类型与不透明类型

在理解类型擦除之前，需要先理解 Swift 类型系统中两个关键概念：存在类型（Existential Type） 和不透明类型（Opaque Type）。它们是协议在类型层面的两种使用方式，也是理解 any 和 some 关键字的基础。

存在类型（Existential Type）

“存在类型"这个术语来自类型论中的存在量词（∃）。它表达的语义是：“存在某个类型 T 遵循了协议 P，但我不知道也不关心 T 具体是什么。”

当你把一个协议当作类型来使用时（而非泛型约束），你就在使用存在类型：

protocol Animal {
 func makeSound() -> String
}

struct Dog: Animal {
 func makeSound() -> String { "Woof!" }
}

struct Cat: Animal {
 func makeSound() -> String { "Meow!" }
}

// animals 数组中的每个元素都是存在类型
// 编译器不知道每个元素的具体类型，只知道"存在某个类型遵循了 Animal"
var animals: [any Animal] = [Dog(), Cat()]

存在类型的核心特征：

运行时多态：具体类型在运行时才确定，同一个变量可以在不同时刻持有不同的具体类型
有性能开销：Swift 通过存在容器（Existential Container）来存储值，方法调用需要通过见证表间接派发
类型信息被隐藏：调用方只能通过协议接口与值交互，无法访问具体类型的特有成员

在 Swift 5.6 之前，直接把协议写成类型（如 let x: Animal）就是存在类型，但语法上没有任何标记。Swift 5.6 引入 any 关键字使其变得显式，目的是提醒开发者这里存在运行时开销。Swift 5.7 起，对于带有关联类型的协议，必须使用 any 才能作为存在类型。

计算机网络

Sun, 03 May 2026 23:11:47 +0800

网络分层模型

OSI七层模型

OSI（Open Systems Interconnection）是国际标准化组织提出的网络通信参考模型：

层级	名称	功能	协议/设备举例
7	应用层	为应用程序提供网络服务	HTTP, FTP, DNS, SMTP
6	表示层	数据格式转换、加密/解密	SSL/TLS, JPEG, ASCII
5	会话层	建立、管理和终止会话	RPC, SQL
4	传输层	端到端的可靠数据传输	TCP, UDP
3	网络层	路由选择与IP寻址	IP, ICMP, ARP
2	数据链路层	帧的封装与MAC寻址	Ethernet, Wi-Fi
1	物理层	比特流的物理传输	光纤, 双绞线

TCP/IP四层模型

实际工程中更常用的是TCP/IP四层模型，它将OSI的上三层合并为应用层，下两层合并为网络接口层：

graph TB
subgraph "TCP/IP四层模型"
A["应用层
HTTP, DNS, FTP, SMTP"]
B["传输层
TCP, UDP"]
C["网络层
IP, ICMP, ARP"]
D["网络接口层
Ethernet, Wi-Fi"]
end
subgraph "OSI七层模型"
E["应用层"]
F["表示层"]
G["会话层"]
H["传输层"]
I["网络层"]
J["数据链路层"]
K["物理层"]
end
A --- E
A --- F
A --- G
B --- H
C --- I
D --- J
D --- K

数据封装与解封装

数据在发送方从上到下逐层封装，每一层都将上层传来的数据视为载荷（Payload），在其前面添加本层的头部信息（部分层还会添加尾部信息），然后交给下一层处理。接收方则从下到上逐层解封装，每一层剥离本层头部后将载荷交给上层。