基础

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 是 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 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 是 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 修饰局部变量，使其只初始化一次，后续调用保留上次的值。 ...

本文将深入探讨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 计算目标槽位，冲突时向后线性探测。因此它本质上是一个用数组实现的开放寻址哈希表，而非普通的顺序数组。 ...

定义 值类型 值类型是指变量直接存储自身字段或描述信息的类型。值类型具有值语义，当将一个值类型变量赋值给另一个变量时，语义上会得到一份独立的值；底层是否立即复制完整数据，取决于编译器优化和写时拷贝等实现。 引用类型 引用类型是指变量存储的是指向数据在内存中位置的引用（指针）。当将一个引用类型变量赋值给另一个变量时，两个变量指向同一块内存区域。 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 内存关系可以近似理解为： ...

当手指触碰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多线程方案对比 方案 简介 语言 生命周期管理 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）。 ...

本文详细介绍 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开发中，理解各种生命周期是非常重要的基础知识。本文将详细介绍应用生命周期、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生命周期，支持多窗口场景。 ...