IOS开发

objc4 runtime 懒初始化 并发等待 fork safety +initialize 懒初始化与并发状态机 +initialize 是 Objective-C 运行时在类第一次被真正使用时触发的类级初始化钩子。 objc4 的实现重点不是“调用一个方法”，而是用每个类的递归初始化锁、元类上的状态位、线程本地的初始化列表和 fork 子进程保护规则，保证父类优先、单线程执行、并发可等待、重入不死锁。 目录 作用 实现原理 核心状态字段 入口与触发 并发状态机 关键流程 测试依据 作用 +initialize 的语义是：在某个类或其子类第一次收到会触发初始化的消息前，运行时先给该类发送一次 +initialize。 这让类可以延迟建立全局状态、注册方法、准备缓存或执行只依赖本类的初始化逻辑。 懒触发 objc_getClass() 只查找类，不触发初始化；普通消息发送、部分运行时查询、autorelease 返回值路径和弱引用相关路径可能需要先完成初始化。 父类优先 子类开始初始化前，运行时递归确保父类已经初始化，避免类层次中间被并发线程插入造成死锁。 一次完成 同一类只有一个线程真正发送 +initialize；其他线程要么等待，要么在同一初始化线程重入时直接放行。 实现原理 objc4 把 +initialize 做成一个按需进入的并发状态机：消息查找路径发现目标类未初始化时，先把类 realize，再释放 runtimeLock，进入 initializeNonMetaClass()。 后者用父类递归、每类递归锁、元类状态位和线程本地初始化列表协调所有线程。真正执行用户代码的线程设置 INITIALIZING，发送 +initialize，最后在 @finally 中切换到 INITIALIZED；其他线程通过同一把类锁等待状态稳定。 这个设计的核心约束是单调性：类状态只从“未初始化”前进到“初始化中”，再前进到“已初始化”。即使 +initialize 抛异常，状态机也会完成收尾；即使发生重入，只有当前初始化线程能绕过等待；即使 fork 发生在多线程初始化期间，子进程也只允许 trivial 初始化继续，其他自定义初始化会主动终止。 核心类/结构状态字段 初始化状态存在类对象的元类标志位里。源码注释明确约束：初始时 RW_INITIALIZING 和 RW_INITIALIZED 都未设置；初始化中只设置前者；完成后清除前者并设置后者；两者永不同时为真，且 RW_INITIALIZED 一旦设置就不会清除。 ...

objc4 runtime +load 调度：从 load_images 到 call_load_methods 这页解释 objc4 如何在 dyld 映射镜像后发现、排队并调用 Objective-C 的 +load。 重点是类与分类的顺序、父类优先、递归和重入处理，以及 runtimeLock 与 loadMethodLock 的边界。 入口：dyld callback 队列：loadable_classes / loadable_categories 调度：call_load_methods 测试：load*.m 目录 作用 实现原理 核心结构和关键函数 关键流程 带注释代码片段 测试体现的语义 作用 +load 是 Objective-C 运行时在类或分类被装入进程时主动调用的类方法。 它不依赖消息发送触发，也早于普通的 +initialize。objc4 的任务不是简单遍历所有方法并调用， 而是在 dyld 映射镜像、runtime 完成类注册和分类附着后，按照语言语义和装载依赖稳定地调用。 装载时机 dyld 通过 _dyld_objc_register_callbacks 注册 runtime 回调。镜像映射后先走 map_images，随后 load_images 处理该镜像中的非懒加载类和分类。 顺序语义 类 +load 必须父类优先；所有当前可调用的类 +load 先于分类 +load；分类必须等宿主类已经完成自己的 +load。 重入安全 +load 内部可能 dlopen 新镜像，再次进入 load_images。objc4 让内层调用只排队，真正调用由最外层 call_load_methods 收尾。 实现原理 objc4 将 +load 分成“发现”和“调用”两阶段。发现阶段需要持有 runtimeLock， 因为它要读取和实现类、解析分类、查找元类方法列表。调用阶段释放 runtimeLock， 只持有递归的 loadMethodLock，因为用户代码可能执行任意 Objective-C 行为并重新映射镜像。 ...

objc4 runtime Category 装载与方法、协议、属性附加 Category 的本质不是“修改类结构体”，而是在镜像加载和类实现化时，把分类携带的方法列表、协议列表、属性列表合并到目标类或元类的可变列表视图中。objc4 同时要处理未实现类、stub class、dyld 预附加列表、方法缓存失效和 +load 顺序。 runtime/objc-runtime-new.mm runtime/objc-runtime-new.h runtime/objc-loadmethod.mm test/category.m 等测试 目录 作用 实现原理总览 核心结构和字段 关键流程 带注释核心代码 测试揭示的行为 作用 扩展类行为 分类把实例方法挂到类，把类方法挂到元类，让现有类获得新 selector 或覆盖既有 selector。 扩展反射信息 分类的协议和属性参与 class_copyProtocolList、class_getProperty 等运行时查询。 保持加载顺序 后加载的分类应优先被方法查找看到，所以列表附加采用“前插”。 支持动态镜像 bundle、共享缓存、stub class 和未实现类都能在不同时间点接收分类。 关键结论：分类附加不是把方法逐个复制进类定义，而是把 method_list_t、protocol_list_t、property_list_t 这类“列表”挂到 class_rw_ext_t 的数组视图前端。 实现原理总览 Mach-O 镜像 __objc_catlist / __objc_catlist2 中保存 category_t *。runtime 通过 header_info 知道分类来自哪个镜像。 → 分类分流 目标类未实现则暂存到 unattachedCategories；目标类已实现则立即 attachCategories。 → 列表前插 attachLists 把新增列表放在旧列表前面，方法查找和反射会先看到分类列表。 依据：load_categories_nolock 分流逻辑见 runtime/objc-runtime-new.mm:3585-3717；列表前插见 runtime/objc-runtime-new.h:2021-2105。 ...

objc4 方法缓存 cache_t / bucket_t 技术讲解 本文基于当前仓库中的 runtime/objc-cache.mm、 runtime/objc-runtime-new.h、runtime/objc-runtime-new.mm 以及 cache flush 相关测试，说明 Objective-C runtime 如何把一次慢速方法查找变成后续的快速 objc_msgSend cache hit。 一、方法缓存的作用 Objective-C 消息发送以 (Class, SEL) 为核心输入。完整方法查找需要处理类实现、父类链、 动态方法解析、转发和分类变更等逻辑，代价高于一次普通函数调用。cache_t 是挂在每个 objc_class 上的 IMP cache，用 SEL 作为 key，缓存最终应该调用的 IMP。 加速热路径命中时 objc_msgSend 不进入 runtime 慢路径，直接由 bucket 中的 IMP 跳转。 缓存继承结果子类未实现某 selector 时，也可以把父类找到的 IMP 缓存在子类 cache 中。 支持动态变更分类加载、添加方法、交换实现等操作会触发 cache flush，避免继续调用旧 IMP。 cache 不是方法列表本身，也不是权威数据源。它是一个可丢弃、可重建的性能结构；扩容时甚至不会搬迁旧条目， 而是让后续消息重新填充热点 selector。 二、核心结构 bucket_t：一个 selector 到 IMP 的槽位 字段 _sel 保存 selector，_imp 保存编码后的 IMP。arm64 上 IMP 在前，其他架构通常 SEL 在前，以贴合汇编 fast path 和指针认证需求。 sel() 以 relaxed atomic 读取 selector。空槽的 selector 为 0。 imp(base, cls) 读取并解码 IMP。arm64e 可使用 ptrauth，部分配置使用 class 指针 XOR，未编码配置则直接返回。 set<Atomic, Encoded>() 写入一个 bucket。写入顺序被精心安排，保证无锁读取者不会看到“新 SEL + 旧 IMP”的错误组合。 cache_t：每个类上的哈希表 _bucketsAndMaybeMask 保存 buckets 指针，有些 64 位配置还把 mask 打包进高位；preoptimized cache 也用低位 marker 复用这个字段。 _mask / 内联 mask bucket 数量始终为 2 的幂，mask = capacity - 1，哈希后用按位与得到起始槽。 _occupied 已占用动态 bucket 数。插入成功后递增；换表时清零。 _flags 保存若干快速路径标记，例如 metaclass、C++ ctor/dtor、默认 alloc 或 RR 等，具体位定义在 objc-runtime-new.h。 关键方法 insert、eraseNolock、destroy、copyCacheNolock、maybeConvertToPreoptimized、preoptFallbackClass。 preopt_cache_t：dyld shared cache 预构建的常量 cache fallback_class_offset 预优化查找未覆盖时继续查找的类，相对当前 class 地址保存。 shift / mask 用于计算预优化 entries 下标。capacity() 返回 mask + 1。 occupied 预优化 cache 中的有效条目数量。 has_inlines 标记是否存在内联 selector；方法列表变更时需要更谨慎地禁用这类 cache。 entries[] 每项保存 selector offset 和 IMP offset，而不是直接保存完整指针。 三、实现原理 动态 cache 是一个开放寻址哈希表。cache_hash(sel, mask) 用 selector 地址和 mask 得到起始槽； 冲突时调用 cache_next 继续探测。不同架构的探测方向不同：部分架构递增并使用 end marker， arm64 递减并通过 mask 回绕。 ...

objc4 runtime dispatch Objective-C 消息发送：objc_msgSend 与慢速查找入口 Objective-C 的方法调用本质上是一次以 receiver 和 SEL 为键的动态派发。 在 arm64 上，objc_msgSend 先用少量汇编完成 nil/tagged pointer 判断和方法缓存查找； 只有缓存未命中时，才进入 C++ 慢路径 lookUpImpOrForward，沿类层级查找、触发动态解析、填充缓存或进入消息转发。 入口：runtime/Messengers.subproj/objc-msg-arm64.s 慢路径：runtime/objc-runtime-new.mm 缓存：runtime/objc-cache.mm 测试：test/msgSend.m 目录 作用 实现原理总览 核心结构与约定 快速路径 慢速查找入口 消息转发 测试观察点 作用 objc_msgSend(id self, SEL _cmd, ...) 是 Objective-C 实例方法和类方法调用的公共派发入口。 编译器把 [obj method:arg] 形式的调用降低为对 objc_msgSend 的调用；真正执行哪个 IMP 由运行时根据接收者的实际类、选择子和当前方法缓存决定。 动态派发 同一个 SEL 可以在不同类上命中不同 IMP，体现多态。 缓存加速 大多数热路径只扫描类的 cache_t，命中后直接尾调用 IMP。 语义兼容 nil 接收者返回零值；tagged pointer 通过标签映射到伪类继续派发。 扩展入口 未找到实现时支持 +resolve... 和完整的 forwarding 机制。 ...

objc4 类加载、read_images 与类实现化 本文解释 Objective-C runtime 从 dyld 通知镜像映射，到读取类、处理 future class、realize class、methodize class、附着 category 的主干流程。 重点源码来自 runtime/objc-runtime-new.mm、objc-runtime-new.h、objc-os.mm、objc-class.mm 及相关测试。 作用 核心结构 关键流程 测试视角 一、这条链路的作用 把 Mach-O 中的静态元数据变成运行时可用的类 编译器把类、元类、方法列表、协议列表、属性列表和 ivar 布局写入 Mach-O 的 Objective-C sections。 这些数据起初主要是只读的 class_ro_t。runtime 加载镜像时要登记类名、修正 selector/protocol/class 引用，并在必要时分配可写的 class_rw_t。 延迟成本，同时保证消息发送能看到正确结构 大量类可以保持未 realized 状态，直到非懒加载、+load、消息发送、Swift 桥接或显式 API 需要它们。 realize 时才连接父类和元类、修正 ivar 偏移、初始化 cache、复制运行时标志，并把方法列表整理成可查找的形态。 简化理解：read_images 是“发现并登记”；readClass 是“读一个类声明并处理 future/remap”；realizeClassWithoutSwift 是“把类接入运行时继承图”；methodizeClass 是“准备方法/协议/属性并合并 category”。 二、核心类/结构和关键字段 结构 关键字段 作用 objc_class superclass、cache、bits 类对象本体。bits 初始可指向 class_ro_t，realize 后指向 class_rw_t 并夹带 fast flags。 class_ro_t flags、instanceStart、instanceSize、name、baseMethods、ivars 编译期只读描述。包含类名、方法、协议、属性、ivar 布局和 root/meta/future/realized 等 ABI 标志。 class_rw_t flags、ro_or_rw_ext、firstSubclass、nextSiblingClass 运行时可写状态。保存 realized/initialized/constructing 等状态，并把类接入子类链。 class_rw_ext_t ro、methods、properties、protocols 当类需要扩展列表时分配。category 附着后，方法/属性/协议列表通常进入这里。 method_list_t entsizeAndFlags、count、方法条目 方法列表。加载时会 uniquing selector，必要时排序并标记 fixed-up。 category_t cls、instanceMethods、classMethods、protocols、instanceProperties 分类元数据。目标类已 realized 时立即附着，否则暂存到 unattached categories。 header_info classlist、nlclslist、catlist、selrefs、protocolrefs 一个 Mach-O 镜像的 ObjC 元数据索引。objc-os.mm 中 addHeader 负责创建或取出它。 类数据从 ro 切换到 rw struct objc_class : objc_object { Class superclass; cache_t cache; class_data_bits_t bits; // 未实现时指向 class_ro_t，实现后指向 class_rw_t }; struct class_rw_t { uint32_t flags; // RW_REALIZED、RW_FUTURE、RW_INITIALIZED 等 explicit_atomic<uintptr_t> ro_or_rw_ext; Class firstSubclass; Class nextSiblingClass; }; class_data_bits_t::safe_ro() 允许在并发 realize 场景下安全取出 ro。 setData() 则在 realization 或构造阶段把 objc_class::bits 改成 rw 指针，并设置 FAST_IS_RW_POINTER。 ...

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 类型。 ...

大型 iOS 工程的编译耗时往往是研发效能最突出的瓶颈之一。以抖音、今日头条、美团为代表的一线团队，工程代码量通常在数百万到千万行级，本地全量编译耗时 10 分钟以上、CI 上半小时起步已是常态。编译等待不仅直接压缩研发时间，还会打断心流、降低人均产出。 本系列文章从 iOS 编译系统的原理出发，结合社区最新实践（Xcode 16/17 Explicit Modules、rules_xcodeproj、seer-optimize、cocoapods-hmap-prebuilt、Rugby 等），系统性介绍编译优化的各类手段与背后的原理。 编译流程概述 理解iOS编译原理是编译优化的前提。一次典型的 iOS 编译流程可以划分为以下阶段： flowchart TD A[Parse Podfile / 生成工程] --> B[Pod Install / 依赖解析] B --> C[Xcode Build System 调度] C --> D[Dependency Scan / 模块依赖扫描] D --> E[Swift/Clang 前端编译] E --> F[生成 .o / .swiftmodule / .pcm] F --> G[链接 ld64 / ld-prime / lld] G --> H[签名 / 打包 / 资源处理] H --> I[产出 .app / .ipa] 阶段 主要工作 常见瓶颈 依赖管理 Pod Install、SPM 解析 Source 更新慢、Specification 解析重复、沙盒拷贝 工程生成 生成 Pods.xcodeproj、xcconfig、hmap Target 数量多、pbxproj 膨胀 构建调度 Build System 解析任务图、并行调度 依赖粒度过粗、并行度不足 模块扫描 Clang/Swift 依赖扫描 隐式模块重复编译 源码编译 Swift/Clang 前端、类型检查、SIL/IR 生成 类型推导爆炸、WMO 关闭、PCH 失效 链接 符号解析、LTO、dead-strip 链接参数过长、ThinLTO 串行 收尾 签名、资源拷贝、dSYM 串行脚本阻塞 优化思路全景 编译优化的核心思路只有三条：减少需要做的工作、让必须做的工作更快、让做过的工作可复用。所有社区实践都可以归入这三类。 ...

定义 值类型 值类型是指变量直接存储自身字段或描述信息的类型。值类型具有值语义，当将一个值类型变量赋值给另一个变量时，语义上会得到一份独立的值；底层是否立即复制完整数据，取决于编译器优化和写时拷贝等实现。 引用类型 引用类型是指变量存储的是指向数据在内存中位置的引用（指针）。当将一个引用类型变量赋值给另一个变量时，两个变量指向同一块内存区域。 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的异常处理机制、崩溃的传递链路以及各类崩溃的本质原因。 iOS异常处理架构 iOS的异常处理采用分层架构，从底层到上层依次为： flowchart BT subgraph ARCH["异常处理架构"] direction BT HW["硬件层 (Hardware)CPU异常、内存访问违规、非法指令"] MACH["Mach层 (Mach Exception)EXC_BAD_ACCESS、EXC_BAD_INSTRUCTION、EXC_CRASH"] BSD["BSD层 (Unix Signal)SIGABRT、SIGSEGV、SIGBUS、SIGFPE、SIGILL"] APP["应用层 (Application Layer)NSException、@try-@catch、Swift Error"] HW --> MACH MACH --> BSD BSD --> APP end 需要注意：这张图表示崩溃治理中常见的异常/终止机制层次，并不表示所有异常都一定从硬件层逐级向上传递。NSException 属于 Objective-C 运行时/框架层的语言异常机制，不是内核产生的 Mach 异常。只有当 NSException 未被捕获时，运行时最终通常会调用 abort() 主动终止进程，随后表现为 SIGABRT / EXC_CRASH。 崩溃的传递链路 当异常发生时，会按照特定的链路传递： flowchart TD A["1. 硬件触发异常CPU检测到非法操作（如访问无效内存地址）触发硬件中断，陷入内核态"] --> B["2. Mach层处理内核将硬件异常转换为Mach异常通过异常端口发送给用户态的异常处理程序如果没有处理，转换为Unix信号"] B --> C["3. BSD层处理Mach异常被转换为对应的Unix信号调用进程注册的Signal Handler如果没有处理或处理后继续，执行默认行为"] C --> D["4. 进程终止默认行为通常是终止进程生成崩溃日志"] Mach异常与Unix信号的对应关系 Mach异常 Unix信号 触发原因 EXC_BAD_ACCESS SIGSEGV/SIGBUS 访问无效内存 EXC_BAD_INSTRUCTION SIGILL 非法指令 EXC_ARITHMETIC SIGFPE 算术异常（如除零） EXC_BREAKPOINT SIGTRAP 断点/调试陷阱 EXC_CRASH SIGABRT 程序主动abort Mach异常机制 Mach内核简介 Mach是macOS/iOS的微内核，提供了最基础的系统服务： ...