性能优化 on Last Stand

启动优化-Initializers

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

Initializers是指在main函数之前执行的初始化代码，包括C++静态构造函数和__attribute__((constructor))标记的函数。这些代码会在Pre-main阶段同步执行，阻塞启动。

问题分析

以下代码会在main之前执行：

1. C++静态构造函数

__attribute__((constructor))
static void MyInitializer() {
 // 耗时初始化
 initializeHeavyResource();
}

2. 全局静态变量的构造函数

// 全局静态变量
static std::vector<std::string> globalCache = loadFromDisk(); // 构造函数在main前调用

3. 非基本类型的全局变量

// 非POD类型的全局变量会触发构造函数
static std::string globalString = "Hello";
static MyClass globalObject;

优化方案

方案1：延迟初始化

将全局变量改为懒加载模式：

// 优化前：全局变量在main前初始化
static std::vector<std::string> globalCache = loadFromDisk();

// 优化后（纯C++方案，适用于 .cpp 文件）：
#include <mutex>
static std::vector<std::string>* getGlobalCache() {
 static std::vector<std::string>* cache = nullptr;
 static std::once_flag onceFlag;
 std::call_once(onceFlag, [&] {
 cache = new std::vector<std::string>();
 *cache = loadFromDisk();
 });
 return cache;
}

// 优化后（ObjC++方案，适用于 .mm 文件）：
static std::vector<std::string>* getGlobalCache() {
 static std::vector<std::string>* cache = nullptr;
 static dispatch_once_t onceToken;
 dispatch_once(&onceToken, ^{
 cache = new std::vector<std::string>();
 *cache = loadFromDisk();
 });
 return cache;
}

方案2：使用Swift懒加载

Swift的懒加载特性可以避免在启动时初始化：

启动优化-Rebase与Bind

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

Rebase和Bind是Pre-main阶段的重要步骤，用于修正程序中的指针地址。ObjC类、方法、协议等元数据越多，需要修复的指针越多，启动时间越长。

基本概念

由于ASLR（Address Space Layout Randomization）技术，App每次启动时加载到内存的地址都是随机的，因此需要进行地址修正。关于Rebase和Bind的底层原理，可以参考Mach-O的链接、装载与库。

Rebase（重定位）

修正指向Mach-O内部的指针，将编译时的地址加上ASLR偏移量。

Bind（绑定）

修正指向Mach-O外部的指针，查找符号表，绑定到正确的外部符号地址。

flowchart LR
subgraph compile["编译时 (Mach-O文件)"]
A1["内部指针: 0x1000
(指向内部数据)"]
A2["外部符号: _objc_msgSend
(待绑定)"]
end
subgraph runtime["运行时 (内存中)"]
B1["内部指针: 0x1000 + slide
(Rebase修正)"]
B2["外部符号: 实际地址
(Bind绑定)"]
end
A1 -->|"Rebase"| B1
A2 -->|"Bind"| B2

问题分析

以下因素会增加Rebase/Bind的工作量：

因素	影响
ObjC类数量	每个类都有元数据需要修正
Swift类数量	Swift类在Apple平台也会生成ObjC兼容的元数据，同样需要修正
ObjC方法数量	方法列表中的指针需要修正
Category数量	Category的方法列表需要绑定
C++虚函数	虚函数表中的指针需要绑定
全局变量	指向其他符号的全局变量需要绑定

关于缓存机制：

系统动态库：Rebase/Bind 操作已在 dyld shared cache 中预先完成，不会在 App 启动时执行

App 动态库：dyld 3 的 Launch Closure 会缓存 Rebase/Bind 的元数据信息（哪些指针需要修正、修正方式等），但 Rebase/Bind 操作本身仍需每次启动时执行，因为 ASLR slide 每次启动都不同

因此，减少 ObjC 类、Category、C++ 虚函数等仍然是有效的优化手段。

启动优化-didFinishLaunching

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

didFinishLaunchingWithOptions是main阶段的核心入口，在这里初始化大量SDK和服务会阻塞启动。本文介绍如何优化这个阶段的耗时。

问题分析

典型的问题代码：

func application(_ application: UIApplication,
 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

 // 所有初始化都在主线程同步执行
 CrashReporter.setup()
 Analytics.setup()
 PushNotification.setup()
 NetworkManager.setup()
 DatabaseManager.setup()
 ImageCache.setup()
 AdSDK.setup()
 SocialSDK.setup()
 // ... 更多SDK

 return true
}

这种写法的问题：

所有初始化都在主线程同步执行
无论是否需要，所有SDK都在启动时初始化
阻塞首帧渲染

优化方案

方案1：分级启动任务管理

将启动任务按优先级分类，只在启动时执行必要的任务：

// 启动任务优先级
enum LaunchTaskPriority {
 case required // 必须在首帧前完成
 case high // 首帧后立即执行
 case normal // 首屏稳定后执行
 case low // 空闲时执行
}

// 启动任务管理器
class LaunchTaskManager {
 static let shared = LaunchTaskManager()

 private var tasks: [LaunchTaskPriority: [() -> Void]] = [:]

 func register(priority: LaunchTaskPriority, task: @escaping () -> Void) {
 if tasks[priority] == nil {
 tasks[priority] = []
 }
 tasks[priority]?.append(task)
 }

 func executeRequiredTasks() {
 tasks[.required]?.forEach { $0() }
 }

 func executeHighPriorityTasks() {
 DispatchQueue.main.async {
 self.tasks[.high]?.forEach { $0() }
 }
 }

 func executeNormalTasks() {
 DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) {
 self.tasks[.normal]?.forEach { $0() }
 }
 }

 func executeLowPriorityTasks() {
 // 监听RunLoop空闲时执行
 CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopDefaultMode) {
 self.tasks[.low]?.forEach { $0() }
 }
 }
}

使用示例

func application(_ application: UIApplication,
 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

 let manager = LaunchTaskManager.shared

 // 必须在首帧前完成
 manager.register(priority: .required) {
 CrashReporter.setup() // 崩溃收集必须最先初始化
 }

 // 首帧后立即执行
 manager.register(priority: .high) {
 Analytics.setup()
 PushNotification.setup()
 }

 // 首屏稳定后执行
 manager.register(priority: .normal) {
 AdSDK.setup()
 SocialSDK.setup()
 }

 // 空闲时执行
 manager.register(priority: .low) {
 PreloadManager.preloadResources()
 }

 // 只执行必须的任务
 manager.executeRequiredTasks()

 return true
}

任务分级建议

优先级	适用场景	示例
required	崩溃收集、核心功能依赖	Crash SDK、必要的配置加载
high	用户可能很快用到	推送、统计、网络配置
normal	非首屏功能	广告SDK、社交分享
low	预加载、缓存	图片预加载、数据预热

方案2：并行初始化

将无依赖关系的初始化任务并行执行：

启动优化-load方法

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

+load方法是ObjC运行时在类被加载时自动调用的方法，所有+load方法在main函数之前同步执行，会阻塞启动。

问题分析

+load方法的特点：

特性	说明
调用时机	main函数之前，ObjC Runtime初始化时
调用顺序	父类 → 子类 → Category
线程	主线程，同步执行
影响	直接阻塞启动

// 问题代码：+load中执行耗时操作
@implementation HeavyModule
+ (void)load {
 // 耗时操作会阻塞启动
 [self setupDatabase];
 [self preloadResources];
 [self registerServices];
}
@end

+load与+initialize的区别

特性	+load	+initialize
调用时机	main之前	类首次使用时
调用次数	只调用一次	可能多次（子类触发）
是否阻塞启动	是	否
线程安全	是	是
调用顺序	父类→子类→Category	父类→子类

更详细的对比请参考：+load与+initialize的区别

优化方案

方案1：使用+initialize替代

将+load中的逻辑迁移到+initialize，延迟到类首次使用时执行：

@implementation HeavyModule

// 优化前
+ (void)load {
 [self setupDatabase];
}

// 优化后
+ (void)initialize {
 static dispatch_once_t onceToken;
 dispatch_once(&onceToken, ^{
 // 延迟到类首次使用时执行
 [self setupDatabase];
 });
}

@end

注意：+initialize可能被子类触发多次调用，需要使用dispatch_once保证只执行一次。

启动优化-二进制重排

Fri, 08 May 2026 22:56:38 +0800

二进制重排是一种通过重新排列二进制文件中函数顺序来减少启动时Page Fault的优化技术。

基本原理

Page Fault问题

iOS使用虚拟内存管理，讨论Page Fault时需要先区分两层“内存”：

虚拟地址空间：进程看到的是一段连续的虚拟地址。App启动时，dyld会把Mach-O的__TEXT、__DATA等段映射到进程的虚拟地址空间里。这里的“映射”只是建立虚拟地址和文件偏移的关系，不代表整段二进制代码已经全部进入物理内存。
物理内存：CPU真正执行代码时，需要对应虚拟页背后有可用的物理页。代码页通常是文件映射页，第一次访问某个尚未驻留在物理内存中的代码页时，会触发Page Fault。内核再从App二进制文件中读取这个页的内容，填充到物理页，并更新页表。

所以，更准确地说：程序代码按页映射到虚拟地址空间；启动过程中实际执行到某个函数时，才会按需把该函数所在的代码页调入物理内存。Page Fault本身不是异常崩溃，而是虚拟内存按需调页的正常机制，只是冷启动时如果触发太多文件读取，会增加启动耗时。

默认情况下，编译器按照链接顺序排列函数，导致启动时调用的函数可能分散在不同的代码页中：

优化前（启动函数分散在不同代码页）：
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ Page 1 │ │ Page 2 │ │ Page 3 │ │ Page 4 │
│ func_A │ │ func_X │ │ func_B │ │ func_C │
│ ... │ │ ... │ │ ... │ │ ... │
└────────┘ └────────┘ └────────┘ └────────┘
启动调用 A→B→C 会触达 Page 1, 3, 4。
如果这些代码页还没有驻留在物理内存中，就可能产生3次Page Fault。

二进制重排的效果

通过重排，将启动时调用的函数集中排列在相邻的代码页中：

启动优化-减少动态库

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

动态库加载是Pre-main阶段的重要组成部分，每个动态库都需要加载、验证签名、进行符号绑定，这些操作会显著影响启动时间。

问题分析

当App启动时，dyld需要：

分析Mach-O文件的Load Commands，找出依赖的动态库
递归加载所有依赖的动态库
对每个动态库进行签名验证
执行Rebase和Bind操作

动态库数量越多，这些操作的耗时就越长。Apple建议将自定义动态库数量控制在6个以内。关于动态库加载的详细流程，可以参考Mach-O的链接、装载与库。

关于缓存机制：

系统动态库：已被放入 dyld shared cache 中，其加载和符号绑定操作已预先完成，不会影响 App 启动时间

App 动态库：dyld 3 引入的 Launch Closure 机制会缓存依赖分析、Rebase/Bind 信息等元数据。首次启动（或 App 更新后）会生成缓存，后续启动直接使用

但即使有 Launch Closure 缓存，Rebase/Bind 操作本身仍需执行（因为 ASLR slide 每次启动都不同），动态库数量越多，这些操作的耗时仍然越长。

App可执行文件
 ├── UIKit.framework
 │ ├── Foundation.framework
 │ │ └── CoreFoundation.framework
 │ └── CoreGraphics.framework
 ├── 自定义Framework A
 │ └── 依赖库...
 └── 自定义Framework B
 └── 依赖库...

优化方案

1. 合并动态库

将功能相近的动态库合并为一个：

启动优化-观测

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

准确测量启动时间是优化的前提。启动时间是用户体验的关键指标之一，研究表明，应用性能直接影响用户留存：页面加载时间每增加1秒，用户流失率会显著上升。对于iOS应用，需要在20秒内完成启动，否则可能会被watchdog强制终止。

本文介绍如何测量和监控iOS应用的启动时间。关于启动流程的详细介绍，请参考 App启动流程。

一、测量方式概览

iOS 提供了多种测量启动时间的方式，适用于不同场景：

方式	适用场景	粒度	是否需要代码
dyld 环境变量	开发调试	定性分析	否
Instruments App Launch	深度分析	函数级	否
代码埋点	开发调试 + 线上监控	自定义	是
MetricKit	线上监控	冷启动/热启动	少量代码

二、开发调试阶段

2.1 dyld 环境变量

通过设置 dyld 环境变量可以在控制台查看启动过程中的加载信息：

Edit Scheme → Run → Arguments → Environment Variables

与启动测量相关的环境变量：

环境变量	作用	启动分析用途
`DYLD_PRINT_LIBRARIES`	打印每个加载的 mach-o 镜像	查看动态库加载顺序，确认是否加载了不必要的库
`DYLD_PRINT_LOADERS`	打印镜像的加载器类型（JustInTimeLoader / PrebuiltLoader）	分析是否使用了启动闭包优化
`DYLD_PRINT_INITIALIZERS`	打印每个 initializer 的执行	查看 +load、constructor、C++ 静态构造函数的执行顺序
`DYLD_PRINT_BINDINGS`	打印每次符号绑定	分析符号绑定情况（输出量很大）
`DYLD_PRINT_SEARCHING`	打印库搜索路径	排查库加载问题
`DYLD_PRINT_APIS`	打印 dyld API 调用（如 dlopen）	检测运行时动态加载行为
`DYLD_PRINT_TO_FILE`	将日志输出到指定文件	避免控制台日志过多，方便后续分析

使用示例：

启动优化

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

iOS应用的启动时间是用户体验的关键指标之一。研究表明，应用性能直接影响用户留存：页面加载时间每增加1秒，用户流失率会显著上升。对于iOS应用，需要在20秒内完成启动，否则可能会被watchdog强制终止。

本系列文章从启动流程的各个阶段入手，系统性地介绍iOS启动优化的方法和实践。

启动监控是 APM 的重要子系，线上 P50/P90/P99 的采集、冷/温/热启动判定、以及与业务秒开指标的关联，请参考 APM 系列：指标体系、数据采集。

启动流程概述

App的启动流程分为两个主要阶段：

阶段	时间范围	主要工作
Pre-main	进程创建 → main()函数	加载可执行文件、加载动态库、Rebase/Bind、ObjC Runtime初始化、Swift Runtime元数据注册、+load方法、Initializers
main	main()函数 → 首帧渲染	UIApplicationMain、AppDelegate回调、首帧渲染

flowchart TD
Start([App 冷启动]) --> PreMain
subgraph PreMain["Pre-main 阶段"]
direction TB
A[加载可执行文件
创建进程、mmap映射、签名验证] --> B[加载动态库
递归加载依赖、包括 Swift Runtime]
B --> C[Rebase & Bind
指针修正、符号绑定]
C --> D[ObjC Runtime 初始化
类注册、Category 附加]
D --> E[Swift Runtime 元数据注册
类型元数据、协议遵循表]
E --> F[调用 +load 方法]
F --> G[执行 Initializers
C++静态构造函数、__attribute__]
end
PreMain --> MainPhase
subgraph MainPhase["main 阶段"]
direction TB
H[main函数] --> I[UIApplicationMain
创建UIApplication、AppDelegate、启动RunLoop]
I --> J[AppDelegate回调
willFinish、didFinishLaunching]
J --> K[首帧渲染
创建Window、RootViewController、首屏UI]
end
MainPhase --> End([启动完成])

文章导航

本系列包含以下文章，建议按顺序阅读：

耗电-CPU与后台优化

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

CPU是App最容易"无意识"耗电的模块，而后台则是最容易"偷偷"耗电的场景。本文聚焦这两大问题域，给出具体的优化手段。

一、CPU耗电的根本原因

根据耗电-原理中的分析，CPU耗电由三部分构成：

活跃时间：CPU处于C0/P0的时间。
瞬时功率：和P-State频率相关。
唤醒次数：频繁从C-State唤醒无法进入深度休眠。

对应三条优化方向：

优化方向	策略
减少活跃	任务及时结束，该停就停
降低功率	避免无谓的满核满频，使用合适的QoS
合并唤醒	聚合Timer、聚合任务，让CPU能连续工作后进入深休眠

二、识别CPU耗电热点

从MetricKit入手

cumulativeCPUTime 是线上最直接的CPU指标。对比同版本前后、同机型前后的CPU时长，能快速定位回归。

Time Profiler的使用技巧

在Instruments中抓一份Time Profiler Trace后：

按"Heavy Stack"视图查看耗时函数。
关注后台的采样（通过Xcode的生命周期切换复现）。
查看线程调用频率——单次耗时低但高频调用的函数，同样是耗电大头。

代码层面的CPU异味

// 1. 死循环轮询
while isWaitingForData {
 if dataReady { break }
}

// 2. 主线程sleep循环
DispatchQueue.global().async {
 while true {
 checkStatus()
 Thread.sleep(forTimeInterval: 0.1)
 }
}

// 3. 密集Timer
Timer.scheduledTimer(withTimeInterval: 0.016, repeats: true) { _ in
 self.updateUI()
}

// 4. 无限制的CADisplayLink
displayLink = CADisplayLink(target: self, selector: #selector(tick))
displayLink.add(to: .main, forMode: .common)
// 页面隐藏后忘记invalidate

这些代码在Time Profiler中都会显示出异常高的调用频率。

耗电-原理

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

本文从硬件功耗模型、iOS系统的能效调度机制、以及各个硬件模块的功耗特性三个维度，系统性地讲解iOS App耗电的底层原理。

功耗的基本概念

功率、能量与电量

功率（Power）：单位时间内消耗的能量，单位为瓦特（W）。
能量（Energy）：功率在时间上的积分，单位为焦耳（J）或毫瓦时（mWh）。
电量（Battery Capacity）：电池能存储的总能量，单位为毫安时（mAh）。

\[ Energy = \int P(t)\,dt \]

对于一段时间内近似恒定的功率，可以简化为 \( E = P \times t \)。这也是所有耗电优化的起点——要么降功率（P），要么降时间（t）。

电池电压与电流

iPhone使用锂电池，标称电压约为3.7~3.8V。操作系统看到的电流则随着硬件负载实时变化。可以近似认为：

\[ P(t) = V \times I(t) \]

在App层面，我们无法直接测量V和I，但可以通过 UIDevice.current.batteryLevel 观察电量百分比，通过 IOKit 私有API读取更精细的电池状态（后面检测篇会详细讲）。

硬件功耗特性

不同硬件模块的功耗曲线差异非常大。理解每个模块的特性，才能找到最有效的优化点。

CPU：P-State与C-State

现代CPU（包括Apple Silicon）通过 动态电压频率调整（DVFS） 来平衡性能与功耗。

P-State（Performance State）

P-State描述CPU在工作时的电压/频率档位。以Apple A系列芯片为例，大核和小核都有多个P-State：

flowchart LR
subgraph P-State
P0["P0
最高频率
功耗最大"]
P1["P1
中高频率"]
P2["P2
中低频率"]
P3["P3
低频率
功耗小"]
end
P0 -.->|负载下降| P1
P1 -.-> P2
P2 -.-> P3
P3 -.->|负载上升| P0

CPU的功耗与频率大致呈 立方关系（电压随频率升高，功耗 ≈ V² × f ≈ f³）。这意味着：

耗电-定位与传感器优化

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

定位是iOS设备上公认的"耗电大户"，GPS冷启动一次动辄十几秒的高功耗；传感器（加速度计、陀螺仪等）虽然单次功耗不高，但高频采样会累积成可观的电量消耗；屏幕则是持续耗电的模块，其功耗和亮度、刷新率、像素颜色都强相关。本文聚焦这三类问题，给出工程化的优化方案。

一、定位精度与功耗的关系

iOS通过 CLLocationManager 提供定位服务，底层融合了 GPS、蜂窝基站、WiFi、蓝牙信标 等多源信号。精度越高，需要开启的硬件越多，功耗越高。

精度常量	精度范围	硬件使用	典型功耗
kCLLocationAccuracyBestForNavigation	<5m	GPS + 传感器融合（需插电）	极高
kCLLocationAccuracyBest	~10m	GPS持续	高
kCLLocationAccuracyNearestTenMeters	~10m	GPS + WiFi	高
kCLLocationAccuracyHundredMeters	~100m	WiFi + 基站	中
kCLLocationAccuracyKilometer	~1km	WiFi + 基站（低频）	低
kCLLocationAccuracyThreeKilometers	~3km	基站	极低

注：iOS 14+ 引入的 ReducedAccuracy 是用户授权层面的"粗略位置"，通过 CLAccuracyAuthorization.reducedAccuracy 体现，而不是 desiredAccuracy 常量。即使 App 申请了高精度，只要用户选择了"粗略位置"，系统就只会返回约5公里精度的数据，功耗也随之降到极低。

不同业务场景的精度选择

业务	推荐精度
导航	BestForNavigation（仅使用中 + 插电时）
打车、骑行记录	Best
外卖、附近的人	HundredMeters
天气、资讯推荐	Kilometer 或 ThreeKilometers
反欺诈、粗粒度风控	ReducedAccuracy（尊重隐私 + 省电）

常见反例

// Bad: 所有场景都用Best，页面打开就开，关闭不关
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.startUpdatingLocation()

// Bad: distanceFilter用kCLDistanceFilterNone，每次都回调
locationManager.distanceFilter = kCLDistanceFilterNone

正确姿势：按需精度 + 距离过滤

class WeatherLocationClient: NSObject, CLLocationManagerDelegate {
 private let manager = CLLocationManager()
 private var completion: ((CLLocation) -> Void)?

 override init() {
 super.init()
 manager.delegate = self
 manager.desiredAccuracy = kCLLocationAccuracyKilometer
 manager.distanceFilter = 500 // 500米才更新
 }

 func requestOnce(_ completion: @escaping (CLLocation) -> Void) {
 self.completion = completion
 manager.requestLocation() // 一次性定位，完成后自动停止
 }

 func locationManager(_ manager: CLLocationManager, didUpdateLocations locs: [CLLocation]) {
 guard let loc = locs.last else { return }
 completion?(loc)
 completion = nil
 }

 func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
 completion = nil
 }
}

requestLocation()（iOS 9+）是最省电的一次性定位入口，系统会在获取到满足精度的定位后自动停止硬件。

耗电-检测

Fri, 08 May 2026 22:35:33 +0800

本文介绍iOS耗电问题的检测手段，从开发阶段的本地工具，到线上的监控体系，帮助团队形成一套完整的耗电可观测能力。

检测手段全景

flowchart TB
subgraph Dev["研发阶段"]
EG["Xcode Energy Gauge
实时能效评分"]
Inst["Instruments
Energy Log / Time Profiler"]
XCT["XCTest能效测试"]
end
subgraph Test["测试阶段"]
Thermal["热节流测试"]
Battery["真机电量消耗测试"]
IOKit["IOKit内部分析"]
LPM["低电量模式回归"]
end
subgraph Online["线上阶段"]
MK["MetricKit"]
Self["自建实时采集
电量 / CPU / Thermal / 生命周期"]
Report["埋点上报
数据看板"]
end
Dev --> Test --> Online

一、Xcode Energy Gauge

Xcode在真机调试时，“Debug Navigator → Energy Impact"提供了实时能效评估。

能效评分（Energy Impact）

Xcode将功耗分为5档：

等级	含义	典型值
Very Low / Low	正常使用	0~~3 / 4~~8
High	偏高，需要关注	9~16
Very High	严重，必须优化	17~20

评分由以下几个因素构成：

CPU：平均CPU使用率。
Network：网络活跃时间与流量。
Location：定位活跃时间与精度。
GPU：GPU活跃时间。
Background：后台活跃时间。
Overhead：系统唤醒代价。

典型使用流程

Xcode连接真机（模拟器的数据不准确）。
运行App，选择Debug Navigator → Energy Impact。
进行典型操作（刷Feed、看视频、聊天等），观察评分。
如果出现High/Very High，使用Instruments进一步定位。

二、Instruments Energy Log

Instruments中有多个和能效相关的工具：

耗电-治理

Thu, 07 May 2026 15:42:48 +0800

前面几篇分别讲了耗电的原理、检测、以及CPU/网络/定位/屏幕的具体优化手段。本文把这些内容整合起来，给出一套面向工程团队的 耗电治理体系：从研发规范、线上监控、问题排查到常态化运营。

耗电治理是 APM 资源子系的一部分，与稳定性、流畅性、启动指标共用同一套监控与告警基础设施。完整的 APM 建设方案见 APM 系列：数据采集、B端平台设计。

一、治理体系全景

一个成熟的iOS耗电治理体系通常由四个闭环组成：

flowchart TB
subgraph Dev["研发侧"]
R1["能效规范"]
R2["架构层能效约束"]
R3["Code Review清单"]
end
subgraph Test["测试侧"]
T1["XCTest能效基线"]
T2["真机续航测试"]
T3["极端场景矩阵"]
end
subgraph Online["线上侧"]
O1["MetricKit接入"]
O2["自建CPU/电量采样"]
O3["场景化埋点"]
O4["大盘 + 告警"]
end
subgraph Gov["运营侧"]
G1["版本耗电报告"]
G2["Top问题跟进"]
G3["复盘与规范迭代"]
end
Dev --> Test --> Online --> Gov --> Dev

二、研发阶段的能效规范

模块准入清单

每个新增模块在接入主App前，必须回答以下问题：

维度	问题
CPU	是否有常驻Timer？是否有轮询？是否在不可见时暂停？
网络	请求频率？是否合并？是否支持后台取消？
定位	是否申请定位？精度多少？后台策略？
传感器	是否开启传感器？采样率？视图生命周期？
后台能力	是否申请Background Mode？如何收敛？
动画/渲染	是否有长驻动画？是否适配ProMotion？
Low Power	低电量模式下的降级策略？
权限	涉及的用户权限？是否遵守最小权限原则？

架构层面的能效约束

一些通用能力可以在架构层统一管控，避免各业务重复踩坑：

耗电-网络优化

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

网络是iOS设备上仅次于屏幕的耗电大户。和其他模块不同，网络耗电的"坑"非常隐蔽——请求本身只持续几十毫秒，但无线电（Radio）会有10~20秒的"尾能耗"。本文从无线电能效模型出发，给出具体的网络优化手段。

一、无线电能效模型回顾

RRC状态机再看一眼

无线电不是"开就费电、关就不费电"这么简单。它在连接和空闲之间存在中间状态：

stateDiagram-v2
[*] --> Idle: 初始/长时间空闲
Idle --> Connected: 发送/接收
Connected --> ShortDRX: 空闲~1秒
ShortDRX --> LongDRX: 空闲~5秒
LongDRX --> Idle: 空闲~10秒
Connected --> Connected: 持续通信
ShortDRX --> Connected: 新请求
LongDRX --> Connected: 新请求

状态	功耗	说明
Connected	最高（12W）	数据传输中
Short DRX	中等	周期性监听页 paging，仍持有连接
Long DRX	低	周期变长，仍在空中接口
Idle	极低（~几mW）	完全释放

一次请求从发起到彻底回到Idle大约 12~20秒。这个尾巴就是"Tail Energy"。

能效启示

10次请求，每次间隔2秒：
- Radio持续处于Connected/DRX状态 ≈ 30秒
- 实际传输时间可能只有几百ms

10次请求合并成1次:
- Radio活跃时间 ≈ 15秒（主要是尾巴）
- 节省约50%~70%的Radio能耗

结论：网络能效的核心就是"减少Radio醒来的次数"。

耗电

Fri, 08 May 2026 22:35:33 +0800

耗电（Energy Consumption）是移动应用质量的重要指标之一。一款耗电过快的App会直接影响用户的续航体验，轻则被用户吐槽，重则被系统标记为"耗电大户"（在iOS的"设置 → 电池"中显示），最终被用户卸载。

本系列文章从iOS功耗模型入手，系统性地介绍耗电问题的原理、检测、优化与治理。

为什么要关注耗电

iOS设备的电池容量有限（iPhone通常在3000~5000mAh），而应用的功耗会直接影响续航时间。苹果在iOS 8之后提供了"电池用量"统计入口，用户可以清楚地看到每个App消耗的电量比例。

常见的耗电投诉场景：

场景	用户感知	典型原因
后台待机一晚电量掉20%	手机放着不用也掉电	后台定位、后台音频、后台Fetch未合理释放
App使用1小时电量掉30%	使用过程电量下降过快	CPU长时间高占用、高频网络请求、GPU密集渲染
手机发烫	设备温度异常升高	CPU/GPU长期满载、持续定位、频繁屏幕唤醒
被系统标记为"后台活动"过高	系统提示"此App正在消耗大量电池"	后台任务未合理调度，违反能效规则

苹果对"耗电"非常敏感——从iOS 9开始引入低电量模式（Low Power Mode），从iOS 13开始加强后台任务的能效审查（BackgroundTasks框架），从iOS 15开始通过MetricKit将功耗数据开放给开发者。

iOS功耗模型概述

iOS设备的功耗来源可以分为以下几大类：

flowchart TB
Battery["电池总功耗"]
Battery --> CPU["CPU
计算、编解码"]
Battery --> GPU["GPU
渲染、图层合成"]
Battery --> Screen["屏幕
显示、亮度、刷新率"]
Battery --> Network["网络
蜂窝、WiFi、BLE"]
Battery --> Location["定位
GPS、基站、WiFi定位"]
Battery --> Sensor["传感器
加速度计、陀螺仪、气压计"]
Battery --> Audio["音视频
录制、播放、相机"]
Battery --> Storage["存储
磁盘IO"]
Battery --> IO["外设
蓝牙、NFC、UWB"]

不同硬件模块的功耗量级差异很大。参考苹果WWDC的数据，定位和蜂窝数据通常是"耗电大户"，屏幕是"持续耗电大户"，而CPU/GPU在计算密集时瞬时功耗最高。

模块	典型功耗等级	特点
屏幕	持续高	只要亮屏就持续耗电
蜂窝数据	高	搜索基站、维持连接都耗电
GPS定位	高	冷启动搜星耗电特别明显
CPU/GPU	中~高	计算量决定功耗
WiFi	中	比蜂窝省电
蓝牙（BLE）	低	低功耗蓝牙专为续航优化
传感器	低~中	高频采样会显著增加功耗

耗电问题的本质

耗电问题的本质可以用一个简单的公式表示：

JetsamEvent 日志解读

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

JetsamEvent 是 iOS 唯一由系统官方生成、且专门记录"因内存原因终止进程"的日志。它不记录线程堆栈，却完整刻画了发生强杀那一刻整机的内存分布——这使它成为 OOM 归因、阈值建模、后台生命周期治理最权威的数据源。

本文聚焦 JetsamEvent 日志本身：存放位置、文件结构、字段含义、reason 类型、案例解读、自动化批量解析脚本，以及机型内存上限/iOS 版本差异等实战要点。OOM 监控治理的整体方法论见崩溃-治理。

1. Jetsam 与 JetsamEvent 是什么

iOS 通过 XNU 内核的 memorystatus 子系统（俗称 Jetsam）做整机内存管理：

前台/后台进程按 Jetsam 优先级排序；
当系统整体可用物理页（vm_page_free_count）或单个进程 phys_footprint 触发阈值时，按优先级杀掉进程；
被杀时，内核在 /var/mobile/Library/Logs/CrashReporter/ 生成 JetsamEvent-yyyy-MM-dd-HHmmss.ips 文件，并通过 DiagnosticsReporting 暴露给 设置 → 隐私与安全性 → 分析与改进 → 分析数据。

需要理解两个关键结论：

JetsamEvent 不是单个进程的崩溃日志，而是整机一次 Jetsam 事件的快照。 一个文件里往往包含几十个进程条目，只有其中一个（或少数）被真正杀掉；其余进程是作为"当时整机内存画像"被附带记录。
JetsamEvent 不含线程堆栈。 它的价值在于告诉你"谁占用了多少内存"和"为什么被杀"，而不是"在哪一行代码被杀"。堆栈需要由 App 自己的 Memory Dump / MetricKit 补齐。

2. 获取方式

场景	路径
真机设置页查看	设置 → 隐私与安全性 → 分析与改进 → 分析数据，文件名 `JetsamEvent-*.ips`
Xcode 连接真机	Window → Devices and Simulators → 选中设备 → View Device Logs
sysdiagnose 包	解压后位于 `crashes_and_spins/*.ips`
越狱设备	`/var/mobile/Library/Logs/CrashReporter/JetsamEvent-*.ips`
自动上报	App 下次启动时扫描沙盒外的 Apple 日志目录不可行，只能依赖 `MetricKit` 的 `MXCrashDiagnostic`/`MXAppExitMetric`（iOS 14+）

⚠️ iOS 沙盒下 App 无法直接读取 /var/mobile/Library/Logs/ 的原始 ips 文件，线上规模化采集必须走 MetricKit。JetsamEvent 原始日志主要用于研发期抓真机、或用户反馈场景的手工分析。

崩溃-Mach异常

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

本文深入介绍Mach异常的底层实现细节，包括端口操作、消息机制以及如何实现自定义的Mach异常处理器。

关于Mach异常的基础概念（Task、Thread、Port、Message）和异常端口的查找顺序，请参考崩溃-原理。

Mach端口详解

端口权限

端口权限类型：

┌─────────────────────────────────────────────────────────────┐
│ 端口权限 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MACH_PORT_RIGHT_SEND │
│ ├── 发送权限 │
│ ├── 可以向端口发送消息 │
│ └── 可以复制给其他任务 │
│ │
│ MACH_PORT_RIGHT_RECEIVE │
│ ├── 接收权限 │
│ ├── 可以从端口接收消息 │
│ ├── 只能有一个持有者 │
│ └── 持有者销毁时端口销毁 │
│ │
│ MACH_PORT_RIGHT_SEND_ONCE │
│ ├── 一次性发送权限 │
│ └── 发送一次后自动失效 │
│ │
│ MACH_PORT_RIGHT_PORT_SET │
│ ├── 端口集合权限 │
│ └── 可以同时监听多个端口 │
│ │
│ MACH_PORT_RIGHT_DEAD_NAME │
│ ├── 死名权限 │
│ └── 端口已销毁但名字仍存在 │
│ │
└─────────────────────────────────────────────────────────────┘

端口操作

#include <mach/mach.h>

// 分配新端口
mach_port_t port;
kern_return_t kr = mach_port_allocate(
 mach_task_self(), // 当前任务
 MACH_PORT_RIGHT_RECEIVE, // 接收权限
 &port // 输出端口名
);

// 添加发送权限
kr = mach_port_insert_right(
 mach_task_self(),
 port,
 port,
 MACH_MSG_TYPE_MAKE_SEND // 创建发送权限
);

// 销毁端口
kr = mach_port_destroy(mach_task_self(), port);

// 释放端口权限
kr = mach_port_deallocate(mach_task_self(), port);

Mach消息

消息结构

// 消息头部
typedef struct {
 mach_msg_bits_t msgh_bits; // 消息类型和权限
 mach_msg_size_t msgh_size; // 消息大小
 mach_port_t msgh_remote_port; // 目标端口
 mach_port_t msgh_local_port; // 本地端口（用于回复）
 mach_port_name_t msgh_voucher_port;// 凭证端口
 mach_msg_id_t msgh_id; // 消息ID
} mach_msg_header_t;

// 完整消息示例
typedef struct {
 mach_msg_header_t header;
 // 可选的消息体
 mach_msg_body_t body;
 // 可选的端口描述符
 mach_msg_port_descriptor_t port;
 // 可选的数据
 char data[256];
} MyMessage;

消息发送与接收

// 发送消息
kern_return_t send_message(mach_port_t port, const char *data, size_t len) {
 struct {
 mach_msg_header_t header;
 char data[256];
 } message;

 message.header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0);
 message.header.msgh_size = sizeof(message);
 message.header.msgh_remote_port = port;
 message.header.msgh_local_port = MACH_PORT_NULL;
 message.header.msgh_id = 0;

 size_t copy_len = len < sizeof(message.data) ? len : sizeof(message.data);
 memcpy(message.data, data, copy_len);

 return mach_msg(
 &message.header,
 MACH_SEND_MSG, // 发送
 sizeof(message), // 发送大小
 0, // 接收大小
 MACH_PORT_NULL, // 接收端口
 MACH_MSG_TIMEOUT_NONE, // 超时
 MACH_PORT_NULL // 通知端口
 );
}

// 接收消息
kern_return_t receive_message(mach_port_t port) {
 struct {
 mach_msg_header_t header;
 char data[256];
 } message;

 kern_return_t kr = mach_msg(
 &message.header,
 MACH_RCV_MSG, // 接收
 0, // 发送大小
 sizeof(message), // 接收大小
 port, // 接收端口
 MACH_MSG_TIMEOUT_NONE, // 超时
 MACH_PORT_NULL // 通知端口
 );

 if (kr == MACH_MSG_SUCCESS) {
 // 处理消息
 printf("Received: %s\n", message.data);
 }

 return kr;
}

异常端口操作

设置异常端口

#include <mach/mach.h>

// 设置任务级异常端口
kern_return_t setup_task_exception_port(mach_port_t exception_port) {
 // 异常类型掩码
 exception_mask_t mask =
 EXC_MASK_BAD_ACCESS |
 EXC_MASK_BAD_INSTRUCTION |
 EXC_MASK_ARITHMETIC |
 EXC_MASK_BREAKPOINT |
 EXC_MASK_SOFTWARE;

 return task_set_exception_ports(
 mach_task_self(),
 mask,
 exception_port,
 EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES,
 THREAD_STATE_NONE
 );
}

// 获取当前异常端口
kern_return_t get_exception_ports(void) {
 exception_mask_t masks[EXC_TYPES_COUNT];
 mach_msg_type_number_t count = EXC_TYPES_COUNT;
 mach_port_t ports[EXC_TYPES_COUNT];
 exception_behavior_t behaviors[EXC_TYPES_COUNT];
 thread_state_flavor_t flavors[EXC_TYPES_COUNT];

 return task_get_exception_ports(
 mach_task_self(),
 EXC_MASK_ALL,
 masks,
 &count,
 ports,
 behaviors,
 flavors
 );
}

异常处理流程

完整的异常处理流程

flowchart TD
A["1. 硬件检测到异常
CPU执行非法操作，触发硬件中断"] --> B["2. 陷入内核
CPU切换到内核态，执行异常处理程序"]
B --> C["3. 内核构造异常消息
创建包含异常信息的Mach消息"]
C --> D["4. 发送到异常端口
按照 Thread → Task → Host 顺序查找端口"]
D --> E["5. 等待回复
内核暂停线程，等待异常处理程序的回复"]
E --> F{"6. 处理回复"}
F -->|KERN_SUCCESS| G["恢复线程执行"]
F -->|其他| H["转换为Unix信号或终止进程"]

异常消息格式

// 异常消息结构
typedef struct {
 mach_msg_header_t Head;

 // 消息体
 mach_msg_body_t msgh_body;
 mach_msg_port_descriptor_t thread; // 发生异常的线程
 mach_msg_port_descriptor_t task; // 发生异常的任务

 // 异常信息
 NDR_record_t NDR;
 exception_type_t exception; // 异常类型
 mach_msg_type_number_t codeCnt; // 代码数量
 int64_t code[2]; // 异常代码
} __Request__mach_exception_raise_t;

// 异常回复消息
typedef struct {
 mach_msg_header_t Head;
 NDR_record_t NDR;
 kern_return_t RetCode; // 返回码
} __Reply__mach_exception_raise_t;

实现Mach异常处理器

完整示例

#include <mach/mach.h>
#include <pthread.h>

// 异常处理线程
static pthread_t exception_thread;
static mach_port_t exception_port;

// 保存原始异常端口
static mach_port_t original_exception_port;
static exception_behavior_t original_behavior;
static thread_state_flavor_t original_flavor;

// 异常处理函数
static kern_return_t handle_exception(
 mach_port_t exception_port,
 mach_port_t thread,
 mach_port_t task,
 exception_type_t exception,
 mach_exception_data_t code,
 mach_msg_type_number_t code_count
) {
 // 获取线程状态（ARM64架构）
 // 注意：如需支持x86_64模拟器，需要使用x86_thread_state64_t和X86_THREAD_STATE64
#if defined(__arm64__)
 arm_thread_state64_t state;
 mach_msg_type_number_t state_count = ARM_THREAD_STATE64_COUNT;

 thread_get_state(thread, ARM_THREAD_STATE64,
 (thread_state_t)&state, &state_count);

 // 记录崩溃信息
 printf("Exception: %d\n", exception);
 printf("Code: 0x%llx, 0x%llx\n", code[0], code[1]);
 printf("PC: 0x%llx\n", (unsigned long long)state.__pc);
 printf("LR: 0x%llx\n", (unsigned long long)state.__lr);
#endif

 // 采集堆栈（需要自行实现）
 // collect_backtrace(thread);

 // 保存崩溃日志（需要自行实现）
 // save_crash_log();

 // 返回失败，让系统继续处理（转换为信号）
 return KERN_FAILURE;
}

// 异常处理线程主函数
static void *exception_handler_thread(void *arg) {
 kern_return_t kr;

 while (1) {
 // 接收异常消息
 struct {
 mach_msg_header_t head;
 mach_msg_body_t body;
 mach_msg_port_descriptor_t thread;
 mach_msg_port_descriptor_t task;
 NDR_record_t NDR;
 exception_type_t exception;
 mach_msg_type_number_t code_count;
 int64_t code[2];
 int flavor;
 mach_msg_type_number_t state_count;
 natural_t state[224];
 } request;

 struct {
 mach_msg_header_t head;
 NDR_record_t NDR;
 kern_return_t ret_code;
 } reply;

 // 接收消息
 kr = mach_msg(
 &request.head,
 MACH_RCV_MSG | MACH_RCV_LARGE,
 0,
 sizeof(request),
 exception_port,
 MACH_MSG_TIMEOUT_NONE,
 MACH_PORT_NULL
 );

 if (kr != MACH_MSG_SUCCESS) {
 continue;
 }

 // 处理异常
 kr = handle_exception(
 exception_port,
 request.thread.name,
 request.task.name,
 request.exception,
 request.code,
 request.code_count
 );

 // 发送回复
 reply.head.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_MOVE_SEND_ONCE, 0);
 reply.head.msgh_size = sizeof(reply);
 reply.head.msgh_remote_port = request.head.msgh_remote_port;
 reply.head.msgh_local_port = MACH_PORT_NULL;
 // Mach IPC惯例：回复消息ID = 请求消息ID + 100
 reply.head.msgh_id = request.head.msgh_id + 100;
 reply.NDR = NDR_record;
 reply.ret_code = kr;

 mach_msg(
 &reply.head,
 MACH_SEND_MSG,
 sizeof(reply),
 0,
 MACH_PORT_NULL,
 MACH_MSG_TIMEOUT_NONE,
 MACH_PORT_NULL
 );
 }

 return NULL;
}

// 安装异常处理器
kern_return_t install_exception_handler(void) {
 kern_return_t kr;

 // 创建异常端口
 kr = mach_port_allocate(
 mach_task_self(),
 MACH_PORT_RIGHT_RECEIVE,
 &exception_port
 );
 if (kr != KERN_SUCCESS) return kr;

 // 添加发送权限
 kr = mach_port_insert_right(
 mach_task_self(),
 exception_port,
 exception_port,
 MACH_MSG_TYPE_MAKE_SEND
 );
 if (kr != KERN_SUCCESS) return kr;

 // 保存原始异常端口
 exception_mask_t mask = EXC_MASK_BAD_ACCESS |
 EXC_MASK_BAD_INSTRUCTION |
 EXC_MASK_ARITHMETIC |
 EXC_MASK_BREAKPOINT;

 // 用于接收查询结果的数组
 exception_mask_t masks_out[EXC_TYPES_COUNT];
 mach_port_t ports_out[EXC_TYPES_COUNT];
 exception_behavior_t behaviors_out[EXC_TYPES_COUNT];
 thread_state_flavor_t flavors_out[EXC_TYPES_COUNT];
 mach_msg_type_number_t count = EXC_TYPES_COUNT;

 kr = task_get_exception_ports(
 mach_task_self(),
 mask, // 输入：要查询的异常类型掩码
 masks_out, // 输出：实际的掩码数组
 &count, // 输入输出：数组大小
 ports_out, // 输出：端口数组
 behaviors_out, // 输出：行为数组
 flavors_out // 输出：flavor数组
 );

 // 保存第一个有效的原始端口（简化处理）
 if (count > 0) {
 original_exception_port = ports_out[0];
 original_behavior = behaviors_out[0];
 original_flavor = flavors_out[0];
 }

 // 设置新的异常端口
 kr = task_set_exception_ports(
 mach_task_self(),
 mask,
 exception_port,
 EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES,
 THREAD_STATE_NONE
 );
 if (kr != KERN_SUCCESS) return kr;

 // 创建异常处理线程
 pthread_create(&exception_thread, NULL,
 exception_handler_thread, NULL);

 return KERN_SUCCESS;
}

调试器检测

调试器（如LLDB）通过在Task（任务/进程）级别注册异常端口来优先拦截异常。了解这一机制有助于理解为什么调试时某些崩溃行为会有所不同。

崩溃-信号处理

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

Unix信号是进程间通信和异常通知的重要机制。本文详细介绍Unix信号的基础知识、常见崩溃信号以及Signal Handler的正确实现方式。

Unix信号基础

什么是信号

信号的本质：

┌─────────────────────────────────────────────────────────────┐
│ Unix信号 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 信号是一种软件中断机制： │
│ • 用于通知进程发生了某个事件 │
│ • 可以由内核、其他进程或进程自身发送 │
│ • 进程可以选择处理、忽略或使用默认行为 │
│ │
│ 信号的来源： │
│ • 硬件异常（如除零、非法内存访问） │
│ • 用户输入（如Ctrl+C） │
│ • 系统调用（如kill） │
│ • 软件条件（如定时器到期） │
│ │
└─────────────────────────────────────────────────────────────┘

信号的生命周期

flowchart TD
A["1. 信号产生（Generation）
某个事件触发信号的产生"]
--> B["2. 信号投递（Delivery）
信号被投递到目标进程
此时信号处于pending状态"]
--> C["3. 信号处理（Handling）
进程响应信号，执行以下之一"]
C --> D["执行默认动作"]
C --> E["执行自定义处理函数"]
C --> F["忽略信号"]

常见信号类型

崩溃相关信号

信号	编号(macOS/iOS)	默认动作	说明
SIGABRT	6	终止+core	调用abort()产生
SIGBUS	10	终止+core	总线错误
SIGFPE	8	终止+core	算术异常
SIGILL	4	终止+core	非法指令
SIGSEGV	11	终止+core	段错误
SIGTRAP	5	终止+core	断点陷阱
SIGSYS	12	终止+core	非法系统调用

其他重要信号

信号	编号	默认动作	说明
SIGKILL	9	终止	强制终止（不可捕获）
SIGTERM	15	终止	请求终止
SIGINT	2	终止	中断（Ctrl+C）
SIGQUIT	3	终止+core	退出（Ctrl+\）
SIGPIPE	13	终止	管道破裂
SIGALRM	14	终止	定时器到期

信号详解

SIGABRT (6)
────────────────────────────────────────
触发条件：
• 调用abort()函数
• 未捕获的NSException
• C++ exception未处理
• assert失败（某些情况）

特点：
• 可以捕获和处理
• 通常表示程序主动终止


SIGSEGV (11)
────────────────────────────────────────
触发条件：
• 访问无效内存地址
• 空指针解引用
• 栈溢出
• 访问已释放的内存

对应Mach异常：
• EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)
• EXC_BAD_ACCESS (KERN_PROTECTION_FAILURE)


SIGBUS (10)
────────────────────────────────────────
触发条件：
• 内存对齐错误
• 访问不存在的物理地址
• mmap映射失效

与SIGSEGV的区别：
• SIGSEGV: 虚拟地址层面的问题（地址未映射或权限不足）
• SIGBUS: 物理地址层面的问题（对齐错误、硬件问题等）


SIGILL (4)
────────────────────────────────────────
触发条件：
• 执行非法指令
• Swift强制解包nil
• 代码段损坏

对应Mach异常：
• EXC_BAD_INSTRUCTION


SIGFPE (8)
────────────────────────────────────────
触发条件：
• 整数除零
• 浮点异常
• 算术溢出

对应Mach异常：
• EXC_ARITHMETIC


SIGTRAP (5)
────────────────────────────────────────
触发条件：
• 断点指令
• Swift的fatalError
• precondition失败
• 调试器断点

对应Mach异常：
• EXC_BREAKPOINT

Signal Handler

基本用法

#include <signal.h>

// 简单的信号处理函数
void simple_handler(int sig) {
 // 处理信号
 // 注意：这里只能调用异步信号安全的函数
}

// 注册信号处理函数
void setup_simple_handler(void) {
 signal(SIGSEGV, simple_handler);
 signal(SIGABRT, simple_handler);
}

使用sigaction（推荐）

#include <signal.h>

// 带详细信息的信号处理函数
void detailed_handler(int sig, siginfo_t *info, void *context) {
 // sig: 信号编号
 // info: 信号详细信息
 // context: 上下文（包含寄存器状态）
}

// 使用sigaction注册
void setup_sigaction_handler(void) {
 struct sigaction action;

 // 清零结构体
 memset(&action, 0, sizeof(action));

 // 设置处理函数
 action.sa_sigaction = detailed_handler;

 // 设置标志
 action.sa_flags = SA_SIGINFO // 使用sa_sigaction而非sa_handler
 | SA_ONSTACK; // 使用备用栈

 // 清空信号掩码
 sigemptyset(&action.sa_mask);

 // 注册信号处理器
 sigaction(SIGSEGV, &action, NULL);
 sigaction(SIGABRT, &action, NULL);
 sigaction(SIGBUS, &action, NULL);
 sigaction(SIGFPE, &action, NULL);
 sigaction(SIGILL, &action, NULL);
 sigaction(SIGTRAP, &action, NULL);
}

siginfo_t结构

typedef struct {
 int si_signo; // 信号编号
 int si_errno; // 错误码
 int si_code; // 信号代码（更详细的原因）
 pid_t si_pid; // 发送信号的进程ID
 uid_t si_uid; // 发送信号的用户ID
 void *si_addr; // 故障地址（SIGSEGV/SIGBUS）
 int si_status; // 退出状态
 // ... 其他字段
} siginfo_t;

// 解析siginfo
void parse_siginfo(int sig, siginfo_t *info) {
 printf("Signal: %d (%s)\n", sig, strsignal(sig));
 printf("Code: %d\n", info->si_code);

 if (sig == SIGSEGV || sig == SIGBUS) {
 printf("Fault address: %p\n", info->si_addr);
 }

 // 解析信号代码
 switch (sig) {
 case SIGSEGV:
 switch (info->si_code) {
 case SEGV_MAPERR:
 printf("Address not mapped\n");
 break;
 case SEGV_ACCERR:
 printf("Invalid permissions\n");
 break;
 }
 break;
 case SIGBUS:
 switch (info->si_code) {
 case BUS_ADRALN:
 printf("Invalid address alignment\n");
 break;
 case BUS_ADRERR:
 printf("Nonexistent physical address\n");
 break;
 }
 break;
 // ... 其他信号
 }
}

备用信号栈

为什么需要备用栈

问题场景：

当栈溢出时：
1. 栈空间已耗尽
2. 系统发送SIGSEGV信号
3. 信号处理函数需要栈空间来执行
4. 但是栈已经溢出了！
5. 信号处理函数无法执行

解决方案：
使用备用信号栈（Alternate Signal Stack）

设置备用栈

#include <signal.h>
#include <stdlib.h>

// 设置备用信号栈
void setup_alternate_stack(void) {
 // 分配栈空间
 void *stack = malloc(SIGSTKSZ);
 if (stack == NULL) {
 return;
 }

 // 配置备用栈
 stack_t ss;
 ss.ss_sp = stack;
 ss.ss_size = SIGSTKSZ;
 ss.ss_flags = 0;

 // 设置备用栈
 if (sigaltstack(&ss, NULL) != 0) {
 free(stack);
 return;
 }

 // 注册信号处理器时使用SA_ONSTACK标志
 struct sigaction action;
 action.sa_sigaction = signal_handler;
 action.sa_flags = SA_SIGINFO | SA_ONSTACK;
 sigemptyset(&action.sa_mask);

 sigaction(SIGSEGV, &action, NULL);
}

异步信号安全

什么是异步信号安全

异步信号安全（Async-Signal-Safe）：

信号可能在任何时刻打断正常执行：
• 可能在malloc中间被打断
• 可能在printf中间被打断
• 可能持有某个锁时被打断

如果信号处理函数调用了相同的函数：
• 可能导致死锁（重复获取锁）
• 可能导致数据损坏（数据结构不一致）
• 可能导致未定义行为

因此，信号处理函数只能调用"异步信号安全"的函数

异步信号安全函数列表

// 可以在信号处理函数中安全调用的函数（部分）：

// 文件操作
write()
read()
open()
close()
fsync()

// 进程控制
_exit()
_Exit()
abort()
raise()
kill()
getpid()

// 信号相关
signal()
sigaction()
sigprocmask()
sigemptyset()
sigfillset()
sigaddset()
sigdelset()

// 其他（注意：以下函数不在POSIX异步信号安全列表中，但大多数实现是安全的）
strlen() // 大多数实现安全，但非POSIX标准
memcpy() // 大多数实现安全，但非POSIX标准

不安全的函数

// 不能在信号处理函数中调用的函数：

// 内存分配
malloc()
free()
realloc()
new / delete

// 标准I/O
printf()
fprintf()
fopen()
fclose()

// Objective-C
objc_msgSend()
NSLog()
任何OC方法调用

// C++
大多数C++标准库函数
异常处理

// 其他
syslog()
strtok()
localtime()

完整的崩溃信号处理器

实现示例

#include <signal.h>
#include <execinfo.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>

// 需要捕获的信号
static const int kFatalSignals[] = {
 SIGABRT,
 SIGBUS,
 SIGFPE,
 SIGILL,
 SIGSEGV,
 SIGTRAP,
 SIGSYS,
};
static const int kFatalSignalsCount = sizeof(kFatalSignals) / sizeof(kFatalSignals[0]);

// 原始信号处理器
static struct sigaction g_originalActions[32];

// 崩溃日志文件路径（预先设置）
static char g_crashLogPath[1024];

// 防止重入的标志
static volatile sig_atomic_t g_handling = 0;

// 异步安全的字符串写入
static void safe_write_string(int fd, const char *str) {
 if (str) {
 write(fd, str, strlen(str));
 }
}

// 异步安全的整数转字符串
static void safe_write_int(int fd, long value) {
 char buffer[32];
 char *ptr = buffer + sizeof(buffer) - 1;
 *ptr = '\0';

 int negative = value < 0;
 if (negative) value = -value;

 do {
 *--ptr = '0' + (value % 10);
 value /= 10;
 } while (value > 0);

 if (negative) *--ptr = '-';

 write(fd, ptr, buffer + sizeof(buffer) - 1 - ptr);
}

// 异步安全的十六进制写入
static void safe_write_hex(int fd, unsigned long value) {
 char buffer[32];
 char *ptr = buffer + sizeof(buffer) - 1;
 *ptr = '\0';

 static const char hex[] = "0123456789abcdef";
 do {
 *--ptr = hex[value & 0xf];
 value >>= 4;
 } while (value > 0);

 *--ptr = 'x';
 *--ptr = '0';

 write(fd, ptr, buffer + sizeof(buffer) - 1 - ptr);
}

// 信号处理函数
static void crash_signal_handler(int sig, siginfo_t *info, void *context) {
 // 防止重入
 if (g_handling) {
 return;
 }
 g_handling = 1;

 // 打开崩溃日志文件
 int fd = open(g_crashLogPath, O_WRONLY | O_CREAT | O_TRUNC, 0644);
 if (fd < 0) {
 // 无法打开文件，尝试写入stderr
 fd = STDERR_FILENO;
 }

 // 写入基本信息
 safe_write_string(fd, "=== Crash Report ===\n");
 safe_write_string(fd, "Signal: ");
 safe_write_int(fd, sig);
 safe_write_string(fd, " (");

 // 信号名称
 switch (sig) {
 case SIGABRT: safe_write_string(fd, "SIGABRT"); break;
 case SIGBUS: safe_write_string(fd, "SIGBUS"); break;
 case SIGFPE: safe_write_string(fd, "SIGFPE"); break;
 case SIGILL: safe_write_string(fd, "SIGILL"); break;
 case SIGSEGV: safe_write_string(fd, "SIGSEGV"); break;
 case SIGTRAP: safe_write_string(fd, "SIGTRAP"); break;
 default: safe_write_string(fd, "UNKNOWN"); break;
 }
 safe_write_string(fd, ")\n");

 // 信号代码
 safe_write_string(fd, "Code: ");
 safe_write_int(fd, info->si_code);
 safe_write_string(fd, "\n");

 // 故障地址
 if (sig == SIGSEGV || sig == SIGBUS) {
 safe_write_string(fd, "Fault Address: ");
 safe_write_hex(fd, (unsigned long)info->si_addr);
 safe_write_string(fd, "\n");
 }

 // 获取堆栈
 // 注意：backtrace()严格来说也不是异步信号安全的函数
 // 但为了获取崩溃堆栈，这是一个常见的权衡取舍
 safe_write_string(fd, "\nBacktrace:\n");
 void *callstack[128];
 int frames = backtrace(callstack, 128);

 // 注意：backtrace_symbols使用malloc，不是异步安全的
 // 这里我们只写入地址，符号化在后续处理
 for (int i = 0; i < frames; i++) {
 safe_write_int(fd, i);
 safe_write_string(fd, ": ");
 safe_write_hex(fd, (unsigned long)callstack[i]);
 safe_write_string(fd, "\n");
 }

 // 同步写入
 if (fd != STDERR_FILENO) {
 fsync(fd);
 close(fd);
 }

 // 恢复原始处理器并重新发送信号
 sigaction(sig, &g_originalActions[sig], NULL);
 raise(sig);
}

// 安装信号处理器
void install_crash_signal_handlers(const char *logPath) {
 // 保存日志路径
 strncpy(g_crashLogPath, logPath, sizeof(g_crashLogPath) - 1);

 // 设置备用栈
 static char alternate_stack[SIGSTKSZ];
 stack_t ss;
 ss.ss_sp = alternate_stack;
 ss.ss_size = SIGSTKSZ;
 ss.ss_flags = 0;
 sigaltstack(&ss, NULL);

 // 配置信号处理器
 struct sigaction action;
 memset(&action, 0, sizeof(action));
 action.sa_sigaction = crash_signal_handler;
 action.sa_flags = SA_SIGINFO | SA_ONSTACK;
 sigemptyset(&action.sa_mask);

 // 注册所有致命信号
 for (int i = 0; i < kFatalSignalsCount; i++) {
 int sig = kFatalSignals[i];
 sigaction(sig, &action, &g_originalActions[sig]);
 }
}

// 卸载信号处理器
void uninstall_crash_signal_handlers(void) {
 for (int i = 0; i < kFatalSignalsCount; i++) {
 int sig = kFatalSignals[i];
 sigaction(sig, &g_originalActions[sig], NULL);
 }
}

获取上下文信息

从ucontext获取寄存器

#include <signal.h>
#include <sys/ucontext.h>

void signal_handler(int sig, siginfo_t *info, void *context) {
 ucontext_t *uc = (ucontext_t *)context;

#if defined(__arm64__) || defined(__aarch64__)
 // ARM64架构
 mcontext_t mc = uc->uc_mcontext;

 // 通用寄存器
 for (int i = 0; i < 29; i++) {
 printf("x%d: 0x%llx\n", i, mc->__ss.__x[i]);
 }

 // 特殊寄存器
 printf("fp: 0x%llx\n", mc->__ss.__fp); // 帧指针
 printf("lr: 0x%llx\n", mc->__ss.__lr); // 链接寄存器
 printf("sp: 0x%llx\n", mc->__ss.__sp); // 栈指针
 printf("pc: 0x%llx\n", mc->__ss.__pc); // 程序计数器
 printf("cpsr: 0x%x\n", mc->__ss.__cpsr); // 状态寄存器

#elif defined(__x86_64__)
 // x86_64架构
 mcontext_t mc = uc->uc_mcontext;

 printf("rax: 0x%llx\n", mc->__ss.__rax);
 printf("rbx: 0x%llx\n", mc->__ss.__rbx);
 printf("rcx: 0x%llx\n", mc->__ss.__rcx);
 printf("rdx: 0x%llx\n", mc->__ss.__rdx);
 printf("rsi: 0x%llx\n", mc->__ss.__rsi);
 printf("rdi: 0x%llx\n", mc->__ss.__rdi);
 printf("rbp: 0x%llx\n", mc->__ss.__rbp);
 printf("rsp: 0x%llx\n", mc->__ss.__rsp);
 printf("rip: 0x%llx\n", mc->__ss.__rip);

#endif
}

从寄存器回溯堆栈

// 基于帧指针的堆栈回溯
void backtrace_from_context(ucontext_t *context) {
 mcontext_t mc = context->uc_mcontext;

#if defined(__arm64__)
 uintptr_t pc = mc->__ss.__pc;
 uintptr_t fp = mc->__ss.__fp;

 printf("Backtrace:\n");
 printf("0: 0x%lx (PC)\n", (unsigned long)pc);

 int frame = 1;
 while (fp != 0 && frame < 128) {
 // ARM64栈帧布局：
 // [fp+0]: 上一帧的fp
 // [fp+8]: 返回地址

 uintptr_t *frame_ptr = (uintptr_t *)fp;

 // 安全检查
 if ((uintptr_t)frame_ptr < 0x1000) break;

 uintptr_t return_addr = frame_ptr[1];
 printf("%d: 0x%lx\n", frame, (unsigned long)return_addr);

 // 移动到上一帧
 fp = frame_ptr[0];
 frame++;
 }
#endif
}

信号掩码

阻塞信号

#include <signal.h>

// 阻塞特定信号
void block_signals(void) {
 sigset_t mask;
 sigemptyset(&mask);
 sigaddset(&mask, SIGINT);
 sigaddset(&mask, SIGTERM);

 // 阻塞信号
 sigprocmask(SIG_BLOCK, &mask, NULL);

 // 执行关键代码...

 // 解除阻塞
 sigprocmask(SIG_UNBLOCK, &mask, NULL);
}

// 在信号处理期间阻塞其他信号
void setup_handler_with_mask(void) {
 struct sigaction action;
 action.sa_sigaction = signal_handler;
 action.sa_flags = SA_SIGINFO;

 // 在处理SIGSEGV时阻塞其他信号
 sigfillset(&action.sa_mask);

 sigaction(SIGSEGV, &action, NULL);
}

检查待处理信号

// 检查是否有信号待处理
void check_pending_signals(void) {
 sigset_t pending;
 sigpending(&pending);

 if (sigismember(&pending, SIGINT)) {
 printf("SIGINT is pending\n");
 }
}

信号与多线程

线程与信号

多线程环境下的信号处理：

1. 信号处理器是进程级的
 • 所有线程共享信号处理器设置
 • 一个线程设置的处理器影响整个进程

2. 信号掩码是线程级的
 • 每个线程有自己的信号掩码
 • pthread_sigmask()用于设置线程的信号掩码

3. 信号投递
 • 同步信号（如SIGSEGV）投递给触发它的线程
 • 异步信号投递给任意一个不阻塞该信号的线程

线程信号掩码

#include <pthread.h>
#include <signal.h>

// 设置线程信号掩码
void setup_thread_signal_mask(void) {
 sigset_t mask;
 sigemptyset(&mask);
 sigaddset(&mask, SIGPIPE); // 阻塞SIGPIPE

 pthread_sigmask(SIG_BLOCK, &mask, NULL);
}

// 专门的信号处理线程
void *signal_handler_thread(void *arg) {
 sigset_t mask;
 sigemptyset(&mask);
 sigaddset(&mask, SIGTERM);
 sigaddset(&mask, SIGINT);

 int sig;
 while (1) {
 // 同步等待信号
 sigwait(&mask, &sig);

 printf("Received signal: %d\n", sig);

 if (sig == SIGTERM) {
 // 处理终止信号
 break;
 }
 }

 return NULL;
}

// 主线程设置
void setup_signal_thread(void) {
 // 在主线程中阻塞这些信号
 sigset_t mask;
 sigemptyset(&mask);
 sigaddset(&mask, SIGTERM);
 sigaddset(&mask, SIGINT);
 pthread_sigmask(SIG_BLOCK, &mask, NULL);

 // 创建信号处理线程
 pthread_t thread;
 pthread_create(&thread, NULL, signal_handler_thread, NULL);
}

常见问题与解决方案

信号处理器中的死锁

问题：信号处理器中调用了非异步安全函数导致死锁

场景：
1. 主线程调用malloc()，获取了内存分配锁
2. 此时收到SIGSEGV信号
3. 信号处理器中调用malloc()
4. 尝试获取同一把锁 -> 死锁

解决方案：
• 只使用异步信号安全的函数
• 使用预分配的内存
• 将复杂处理延迟到信号处理器外部

信号处理器重入

// 问题：信号处理器被再次调用
// 解决：使用标志位防止重入

static volatile sig_atomic_t g_handling = 0;

void signal_handler(int sig, siginfo_t *info, void *context) {
 // 检查是否正在处理
 if (g_handling) {
 // 已经在处理中，直接返回
 return;
 }

 // 设置标志
 g_handling = 1;

 // 处理信号...

 // 注意：不要在这里清除标志
 // 因为我们会重新发送信号
}

与其他SDK的冲突

// 问题：多个SDK都注册了信号处理器

// 解决方案：保存并调用原始处理器
static struct sigaction g_original_action;

void my_signal_handler(int sig, siginfo_t *info, void *context) {
 // 我的处理逻辑
 handle_crash(sig, info, context);

 // 调用原始处理器
 if (g_original_action.sa_flags & SA_SIGINFO) {
 g_original_action.sa_sigaction(sig, info, context);
 } else if (g_original_action.sa_handler != SIG_DFL &&
 g_original_action.sa_handler != SIG_IGN) {
 g_original_action.sa_handler(sig);
 } else {
 // 恢复默认行为
 signal(sig, SIG_DFL);
 raise(sig);
 }
}

void install_handler(void) {
 struct sigaction action;
 action.sa_sigaction = my_signal_handler;
 action.sa_flags = SA_SIGINFO | SA_ONSTACK;
 sigemptyset(&action.sa_mask);

 // 保存原始处理器
 sigaction(SIGSEGV, &action, &g_original_action);
}

信号与Mach异常的关系

转换关系

flowchart LR
subgraph Mach["Mach异常"]
A1[EXC_BAD_ACCESS]
A2[EXC_BAD_INSTRUCTION]
A3[EXC_ARITHMETIC]
A4[EXC_BREAKPOINT]
A5[EXC_CRASH]
A6[EXC_SOFTWARE]
end
subgraph Signal["Unix信号"]
B1[SIGSEGV / SIGBUS]
B2[SIGILL]
B3[SIGFPE]
B4[SIGTRAP]
B5[SIGABRT]
B6[取决于具体代码]
end
A1 --> B1
A2 --> B2
A3 --> B3
A4 --> B4
A5 --> B5
A6 --> B6

转换时机：

崩溃-原理

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

理解崩溃的底层原理是有效治理的基础。本文详细介绍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的微内核，提供了最基础的系统服务：

崩溃-治理

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

本文详细介绍常见崩溃类型的修复方法、防崩溃保护机制以及线上监控体系。

崩溃治理是 APM 稳定性子系的核心模块。完整的监控建设、多类型稳定性问题（Watchdog/OOM/CPU/IO）的统一治理与 Zombie/Coredump/MemoryGraph 等高级归因能力，请参考 APM 系列：指标体系、业界方案。

崩溃治理流程

flowchart TB
subgraph S1[1. 崩溃发现]
A1[线上监控报警]
A2[用户反馈]
A3[测试发现]
end
subgraph S2[2. 崩溃分析]
B1[符号化堆栈]
B2[问题定位]
B3[根因分析]
end
subgraph S3[3. 问题修复]
C1[代码修复]
C2[防护措施]
C3[回归测试]
end
subgraph S4[4. 效果验证]
D1[灰度发布]
D2[监控崩溃率]
D3[持续跟踪]
end
A1 --> S2
A2 --> S2
A3 --> S2
S2 --> S3
S3 --> S4

常见崩溃类型及修复

1. 数组越界

// 崩溃示例
NSArray *array = @[@1, @2, @3];
id obj = array[10]; // NSRangeException

// 修复方案1：边界检查
- (id)safeObjectAtIndex:(NSUInteger)index fromArray:(NSArray *)array {
 if (index < array.count) {
 return array[index];
 }
 return nil;
}

// 修复方案2：分类安全方法
@implementation NSArray (Safe)

- (id)safeObjectAtIndex:(NSUInteger)index {
 if (index < self.count) {
 return [self objectAtIndex:index];
 }
 return nil;
}

@end

// 修复方案3：Swift可选绑定
extension Array {
 subscript(safe index: Index) -> Element? {
 return indices.contains(index) ? self[index] : nil
 }
}

// 使用
let value = array[safe: 10] // 返回nil而不是崩溃

2. 字典插入nil

// 崩溃示例
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSString *value = nil;
[dict setObject:value forKey:@"key"]; // NSInvalidArgumentException

// 修复方案1：nil检查
- (void)setObject:(id)object forKey:(id)key inDict:(NSMutableDictionary *)dict {
 if (object && key) {
 dict[key] = object;
 }
}

// 修复方案2：分类安全方法
@implementation NSMutableDictionary (Safe)

- (void)safeSetObject:(id)object forKey:(id)key {
 if (object && key) {
 [self setObject:object forKey:key];
 }
}

@end

// 修复方案3：使用NSNull
dict[@"key"] = value ?: [NSNull null];

3. Unrecognized Selector

// 崩溃示例
NSString *str = @"hello";
[str performSelector:@selector(count)]; // unrecognized selector

// 修复方案1：respondsToSelector检查
if ([obj respondsToSelector:@selector(someMethod)]) {
 [obj performSelector:@selector(someMethod)];
}

// 修复方案2：消息转发防护
@implementation NSObject (CrashProtection)

+ (void)load {
 // Hook forwardingTargetForSelector:
 Method original = class_getInstanceMethod(self, @selector(forwardingTargetForSelector:));
 Method swizzled = class_getInstanceMethod(self, @selector(safe_forwardingTargetForSelector:));
 method_exchangeImplementations(original, swizzled);
}

- (id)safe_forwardingTargetForSelector:(SEL)aSelector {
 // 如果找不到方法，返回一个空实现的对象
 id target = [self safe_forwardingTargetForSelector:aSelector];
 if (target) return target;

 // 记录错误
 NSLog(@"Unrecognized selector: %@ on %@", NSStringFromSelector(aSelector), self);

 // 返回一个能处理任何消息的对象
 return [CrashStub shared];
}

@end

4. KVO崩溃

// 崩溃场景1：重复移除观察者
[obj removeObserver:self forKeyPath:@"value"];
[obj removeObserver:self forKeyPath:@"value"]; // 崩溃

// 崩溃场景2：未移除观察者就释放
- (void)dealloc {
 // 忘记移除观察者
}

// 修复方案：安全的KVO封装
@interface SafeKVOProxy : NSObject
@property (nonatomic, weak) id observer;
@property (nonatomic, weak) id target;
@property (nonatomic, copy) NSString *keyPath;
@property (nonatomic, copy) void (^callback)(id newValue);
@end

@implementation SafeKVOProxy

- (instancetype)initWithTarget:(id)target
 keyPath:(NSString *)keyPath
 observer:(id)observer
 callback:(void (^)(id))callback {
 self = [super init];
 if (self) {
 _target = target;
 _keyPath = keyPath;
 _observer = observer;
 _callback = callback;

 [target addObserver:self forKeyPath:keyPath options:NSKeyValueObservingOptionNew context:NULL];
 }
 return self;
}

- (void)observeValueForKeyPath:(NSString *)keyPath
 ofObject:(id)object
 change:(NSDictionary *)change
 context:(void *)context {
 if (self.callback) {
 self.callback(change[NSKeyValueChangeNewKey]);
 }
}

- (void)dealloc {
 [_target removeObserver:self forKeyPath:_keyPath];
}

@end

5. 多线程崩溃

// 崩溃场景：非线程安全的集合操作
// 线程1
[mutableArray addObject:obj1];
// 线程2
[mutableArray removeObjectAtIndex:0]; // 可能崩溃

// 修复方案1：加锁
@property (nonatomic, strong) NSLock *arrayLock;

- (void)safeAddObject:(id)object {
 [self.arrayLock lock];
 [self.mutableArray addObject:object];
 [self.arrayLock unlock];
}

// 修复方案2：使用GCD串行队列
@property (nonatomic, strong) dispatch_queue_t arrayQueue;

- (void)safeAddObject:(id)object {
 dispatch_sync(self.arrayQueue, ^{
 [self.mutableArray addObject:object];
 });
}

// 修复方案3：使用Actor（Swift Concurrency）
actor SafeStorage {
 private var items: [Any] = []

 func append(_ item: Any) {
 items.append(item)
 }

 func remove(at index: Int) {
 guard index < items.count else { return }
 items.remove(at: index)
 }

 func getAll() -> [Any] {
 return items
 }
}

let storage = SafeStorage()
await storage.append(obj1)

6. 野指针崩溃

// 崩溃场景
__unsafe_unretained id unsafeRef = obj;
obj = nil;
[unsafeRef description]; // EXC_BAD_ACCESS

// 修复方案1：使用weak而非unsafe_unretained
__weak id weakRef = obj;
obj = nil;
[weakRef description]; // 安全，weakRef为nil

// 修复方案2：Zombie Objects检测（调试用）
// 在Scheme中启用Zombie Objects

// 修复方案3：野指针检测工具
// 使用Address Sanitizer
// Product -> Scheme -> Edit Scheme -> Diagnostics -> Address Sanitizer

7. Swift强制解包崩溃

// 崩溃示例
let value: String? = nil
print(value!) // Fatal error: Unexpectedly found nil

// 修复方案1：可选绑定
if let value = optionalValue {
 print(value)
}

// 修复方案2：空合运算符
let value = optionalValue ?? "default"

// 修复方案3：guard语句
guard let value = optionalValue else {
 return
}
print(value)

// 修复方案4：可选链
let length = optionalString?.count // 返回Int?

8. OOM（Out Of Memory）崩溃

OOM 是 iOS 最难治理的崩溃类型之一：系统因进程占用内存超过限制而将其强杀，不会产生标准崩溃日志，App 也没有机会在崩溃现场同步写下详细堆栈。因此 OOM 治理必须在事故前就把现场数据预埋下来，分为三个时段：

崩溃-采集

Sun, 21 Jun 2026 22:41:52 +0800

准确采集崩溃信息是分析和修复问题的前提。本文详细介绍iOS崩溃的捕获方案、堆栈回溯技术以及符号化原理。

崩溃采集架构

flowchart TB
subgraph capture["崩溃捕获层"]
direction LR
mach["Mach Exception Handler"]
signal["Unix Signal Handler"]
exception["NSException Handler"]
end
subgraph collect["信息采集层"]
direction LR
backtrace["堆栈回溯(Backtrace)"]
register["寄存器状态"]
thread["线程信息"]
device["设备/应用信息"]
end
subgraph storage["本地存储层"]
direction LR
async_write["异步安全写入"]
file_manage["崩溃文件管理"]
end
subgraph report["上报处理层"]
direction LR
symbolicate["符号化解析"]
aggregate["崩溃聚合"]
analyze["数据分析"]
end
capture --> collect
collect --> storage
storage --> report

Mach异常捕获

Mach是macOS/iOS的内核，提供了底层的异常处理机制。Mach异常是最底层的异常类型，发生在内核态，比Unix信号更早被触发。通过注册Mach异常处理器，可以在信号处理之前捕获到崩溃信息。

核心概念：

Mach Port（端口）：Mach内核中进程间通信（IPC）的基本单元，类似于文件描述符
Exception Port（异常端口）：专门用于接收异常消息的端口
Task：Mach中的任务概念，对应一个进程，包含地址空间和资源

异常端口注册

#include <mach/mach.h>

// 异常处理线程函数
static void *exception_handler_thread(void *arg) {
 mach_port_t exception_port = (mach_port_t)(uintptr_t)arg;

 while (1) {
 // 接收异常消息
 struct {
 mach_msg_header_t head;
 mach_msg_body_t body;
 // ... 其他字段
 } request;

 mach_msg_return_t result = mach_msg(
 &request.head,
 MACH_RCV_MSG | MACH_RCV_LARGE,
 0,
 sizeof(request),
 exception_port,
 MACH_MSG_TIMEOUT_NONE,
 MACH_PORT_NULL
 );

 if (result == MACH_MSG_SUCCESS) {
 // 处理异常
 handle_exception(&request);
 }
 }

 return NULL;
}

// 注册异常端口
kern_return_t register_exception_handler(void) {
 kern_return_t kr;
 mach_port_t exception_port;

 // 创建异常端口
 kr = mach_port_allocate(
 mach_task_self(),
 MACH_PORT_RIGHT_RECEIVE,
 &exception_port
 );
 if (kr != KERN_SUCCESS) return kr;

 // 添加发送权限
 kr = mach_port_insert_right(
 mach_task_self(),
 exception_port,
 exception_port,
 MACH_MSG_TYPE_MAKE_SEND
 );
 if (kr != KERN_SUCCESS) return kr;

 // 设置任务异常端口
 kr = task_set_exception_ports(
 mach_task_self(),
 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION |
 EXC_MASK_ARITHMETIC | EXC_MASK_BREAKPOINT,
 exception_port,
 EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES,
 THREAD_STATE_NONE
 );
 if (kr != KERN_SUCCESS) return kr;

 // 创建异常处理线程
 pthread_t thread;
 pthread_create(&thread, NULL, exception_handler_thread,
 (void *)(uintptr_t)exception_port);

 return KERN_SUCCESS;
}

Mach异常处理流程

flowchart TD
A["1. 异常发生"] --> B["2. 内核发送异常消息到异常端口"]
B --> C["3. 异常处理线程接收消息"]
C --> D["4. 解析异常信息"]
D --> D1["exception type"]
D --> D2["exception code"]
D --> D3["thread state"]
D1 & D2 & D3 --> E["5. 采集崩溃信息"]
E --> E1["堆栈回溯"]
E --> E2["寄存器状态"]
E --> E3["其他上下文"]
E1 & E2 & E3 --> F["6. 保存崩溃日志"]
F --> G["7. 决定后续处理"]
G --> G1["转发给原异常处理器"]
G --> G2["让进程终止"]

Unix信号捕获

Unix信号（Signal）是操作系统向进程发送的异步通知机制。当发生特定事件（如非法内存访问、算术错误等）时，内核会向进程发送相应的信号。iOS中，Mach异常通常会被转换为对应的Unix信号。

崩溃

Mon, 04 May 2026 10:37:14 +0800

崩溃是影响App稳定性的最严重问题。当应用发生崩溃时，用户会被强制退出应用，严重影响用户体验和产品口碑。

本系列文章系统性地介绍iOS崩溃的原理、采集方案以及治理策略。

什么是崩溃

崩溃（Crash）是指应用程序因为异常或错误而被强制终止的现象。从技术角度看，崩溃可以分为以下几类：

崩溃类型	触发原因	典型场景
Mach异常	底层硬件/内核异常	访问无效内存、除零错误
Unix信号	系统信号导致进程终止	SIGABRT、SIGSEGV、SIGBUS
NSException	OC层未捕获的异常	数组越界、unrecognized selector
内存问题	OOM或内存损坏	内存不足、野指针
Watchdog	系统监控超时	启动超时、后台任务超时

崩溃率指标

崩溃率是衡量App稳定性的核心指标：

崩溃率计算方式：

1. 崩溃用户率（推荐）
 崩溃用户率 = 发生崩溃的用户数 / 总活跃用户数 × 100%

2. 崩溃次数率
 崩溃次数率 = 崩溃次数 / 启动次数 × 100%

3. 崩溃Session率
 崩溃Session率 = 崩溃Session数 / 总Session数 × 100%

崩溃处理的整体架构

┌─────────────────────────────────────────────────────────────┐
│ 崩溃处理架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 崩溃发生 │ │
│ │ Mach异常 / Unix信号 / NSException / OOM │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 崩溃捕获 │ │
│ │ • Mach异常处理 │ │
│ │ • Signal Handler │ │
│ │ • NSSetUncaughtExceptionHandler │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 信息采集 │ │
│ │ • 堆栈信息 │ │
│ │ • 设备信息 │ │
│ │ • 用户上下文 │ │
│ │ • 崩溃现场 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 本地存储 │ │
│ │ • 写入文件（需要异步安全） │ │
│ │ • 避免使用OC/Swift API │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 上报分析 │ │
│ │ • 下次启动时上报 │ │
│ │ • 符号化解析 │ │
│ │ • 聚合分析 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘

文章导航

本系列包含以下文章，建议按顺序阅读：

崩溃日志解读

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

iOS 崩溃日志（.ips / 老版 .crash）是排查线上问题的一手证据。它不仅记录了"谁崩了"，更隐藏着异常类型、终止命名空间、寄存器现场、线程堆栈、二进制映射、资源限额等多维度事实。看懂每一个字段，才能把"不能复现"的崩溃拆成"寄存器 x0 是 nil 的后果"这种可复现假设。

本文聚焦系统生成的崩溃日志本身：格式演变、bug_type 全景、Header/Body 逐字段、Exception Type / Termination Namespace 深度解读、寄存器视角、符号化工具链、实战案例库、自动化脚本。OOM 专用的 JetsamEvent 日志见 JetsamEvent 日志解读；崩溃采集与治理方法论见崩溃-采集、崩溃-治理。

1. `.ips` / `.crash` 格式演变

iOS 的崩溃日志格式几经迭代：

时代	文件扩展名	格式	说明
iOS 13 及以前	`.crash` / `.ips`	类 plist 纯文本	Key-Value 混排，人眼可读但难解析
iOS 14+	`.ips`	双段 JSON（Header JSON + Body JSON，以换行分隔）	机器可解析，字段更标准化
Xcode Organizer 导出	`.crash`	纯文本渲染视图	由 `.ips` 通过 `CrashReporter.framework` 渲染而来

解析规则和 JetsamEvent 完全一致——第一行是 Header JSON，剩余部分是 Body JSON，不能整体 parse。iOS 14+ .ips 内容可用 log show --archive 或 Xcode Organizer 转为旧式可读文本，但字段原始数据始终在 JSON 里。

卡顿-TableView优化

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

列表滚动是用户最敏感的交互场景之一。本文介绍UITableView和UICollectionView的性能优化方案。

列表卡顿的常见原因

flowchart TB
subgraph frame["每一帧（16.67ms内）需要完成"]
A["1. 计算可见Cell"] --> B["2. 复用或创建Cell"]
B --> C["3. 配置Cell内容"]
C --> C1["设置文本"]
C --> C2["加载图片"]
C --> C3["计算布局"]
C --> C4["渲染视图"]
C1 --> D["4. 提交渲染"]
C2 --> D
C3 --> D
C4 --> D
end
D --> E["⚠️ 任何一步超时都会导致掉帧"]

常见问题

问题	原因	影响
高度计算慢	复杂布局、Auto Layout	滚动卡顿
Cell配置慢	大量视图操作、图片加载	滚动卡顿
复用失效	未正确注册、identifier错误	内存暴涨、卡顿
离屏渲染	圆角、阴影	GPU瓶颈
图片加载	主线程解码	滚动卡顿

Cell复用机制

正确使用复用

class OptimizedTableViewController: UITableViewController {

 private let cellIdentifier = "OptimizedCell"

 override func viewDidLoad() {
 super.viewDidLoad()

 // 注册Cell类（推荐）
 tableView.register(OptimizedCell.self, forCellReuseIdentifier: cellIdentifier)

 // 或注册Nib
 // tableView.register(UINib(nibName: "OptimizedCell", bundle: nil), forCellReuseIdentifier: cellIdentifier)
 }

 override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
 // 使用dequeueReusableCell（带indexPath的版本会自动创建）
 let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as! OptimizedCell

 // 配置Cell
 let item = items[indexPath.row]
 cell.configure(with: item)

 return cell
 }
}

Cell的prepareForReuse

class OptimizedCell: UITableViewCell {

 private let titleLabel = UILabel()
 private let avatarImageView = OptimizedImageView()
 private var currentTask: URLSessionTask?

 override func prepareForReuse() {
 super.prepareForReuse()

 // 重置状态
 titleLabel.text = nil
 avatarImageView.image = nil

 // 取消进行中的任务
 currentTask?.cancel()
 currentTask = nil
 avatarImageView.cancelLoading()
 }

 func configure(with item: Item) {
 titleLabel.text = item.title

 // 异步加载图片
 avatarImageView.setImage(from: item.avatarURL, placeholder: UIImage(named: "placeholder"))
 }
}

高度缓存

问题：每次都计算高度

// 问题代码：每次滚动都重新计算
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
 let item = items[indexPath.row]
 return calculateHeight(for: item) // 耗时操作
}

解决方案1：预计算并缓存

class HeightCachedTableViewController: UITableViewController {

 private var items: [Item] = []
 private var heightCache: [IndexPath: CGFloat] = [:]

 func setItems(_ newItems: [Item]) {
 items = newItems
 heightCache.removeAll()

 // 预计算高度（可以在后台线程）
 precomputeHeights()

 tableView.reloadData()
 }

 private func precomputeHeights() {
 let width = tableView.bounds.width

 for (index, item) in items.enumerated() {
 let indexPath = IndexPath(row: index, section: 0)
 heightCache[indexPath] = calculateHeight(for: item, width: width)
 }
 }

 private func calculateHeight(for item: Item, width: CGFloat) -> CGFloat {
 // 计算文本高度
 let textHeight = item.content.boundingRect(
 with: CGSize(width: width - 32, height: .greatestFiniteMagnitude),
 options: [.usesLineFragmentOrigin, .usesFontLeading],
 attributes: [.font: UIFont.systemFont(ofSize: 16)],
 context: nil
 ).height

 return ceil(textHeight) + 60 // 加上其他元素的高度
 }

 override func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
 return heightCache[indexPath] ?? UITableView.automaticDimension
 }

 // 数据更新时更新缓存
 func updateItem(at indexPath: IndexPath, with item: Item) {
 items[indexPath.row] = item
 heightCache[indexPath] = calculateHeight(for: item, width: tableView.bounds.width)
 tableView.reloadRows(at: [indexPath], with: .automatic)
 }
}

解决方案2：使用estimatedHeight

class EstimatedHeightTableViewController: UITableViewController {

 private var heightCache: [IndexPath: CGFloat] = [:]

 override func viewDidLoad() {
 super.viewDidLoad()

 // 设置估算高度（重要！）
 tableView.estimatedRowHeight = 100
 tableView.rowHeight = UITableView.automaticDimension
 }

 override func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {
 // 缓存实际显示的高度
 heightCache[indexPath] = cell.bounds.height
 }

 override func tableView(_ tableView: UITableView, estimatedHeightForRowAt indexPath: IndexPath) -> CGFloat {
 // 优先返回缓存的高度
 return heightCache[indexPath] ?? 100
 }
}

解决方案3：固定高度

// 如果所有Cell高度相同，直接设置固定值
override func viewDidLoad() {
 super.viewDidLoad()

 tableView.rowHeight = 80 // 固定高度，性能最好
 tableView.estimatedRowHeight = 0 // 关闭估算
}

异步渲染

基本原理

将复杂的渲染工作移到后台线程：

卡顿-主线程优化

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

主线程阻塞是卡顿最常见的原因。本文介绍如何优化主线程的工作，减少阻塞时间。

主线程的职责

主线程（UI线程）负责：

mindmap
root((主线程职责))
事件处理
触摸事件
手势识别
UI更新
布局计算
视图绘制
动画执行
Core Animation
UIView动画
系统回调
生命周期
AppDelegate
定时器
NSTimer
CADisplayLink
通知处理
NotificationCenter
KVO

原则：主线程应该只做UI相关的轻量级工作

常见的主线程阻塞场景

1. 耗时计算

// 问题代码：在主线程进行复杂计算
func processData() {
 let result = heavyComputation(data) // 阻塞主线程
 updateUI(with: result)
}

// 优化后：异步计算
func processDataAsync() {
 DispatchQueue.global(qos: .userInitiated).async {
 let result = self.heavyComputation(self.data)

 DispatchQueue.main.async {
 self.updateUI(with: result)
 }
 }
}

2. 文件I/O

// 问题代码：主线程读写文件
func loadConfig() {
 let data = try? Data(contentsOf: configURL) // 阻塞
 parseConfig(data)
}

// 优化后：异步I/O
func loadConfigAsync() {
 DispatchQueue.global(qos: .utility).async {
 let data = try? Data(contentsOf: self.configURL)

 DispatchQueue.main.async {
 self.parseConfig(data)
 }
 }
}

3. 数据库操作

// 问题代码：主线程数据库查询
func loadUsers() {
 let users = database.query("SELECT * FROM users") // 阻塞
 tableView.reloadData()
}

// 优化后：异步查询
func loadUsersAsync() {
 database.queryAsync("SELECT * FROM users") { [weak self] users in
 self?.users = users
 DispatchQueue.main.async {
 self?.tableView.reloadData()
 }
 }
}

任务异步化

基本原则

flowchart TB
subgraph main["主线程任务"]
direction LR
A1["UI更新
视图刷新、动画"]
A2["用户交互
点击响应、手势处理"]
A3["轻量计算
简单数据转换"]
end
subgraph bg["后台线程任务"]
direction LR
B1["复杂计算
数据处理、算法"]
B2["I/O操作
文件读写、网络请求"]
B3["数据库操作
查询、写入"]
B4["图片处理
解码、缩放、滤镜"]
end
main --> |"轻量、快速"| UI((用户界面))
bg --> |"耗时、阻塞"| main

GCD任务调度

class AsyncTaskManager {

 // 计算密集型任务
 static func compute<T>(_ work: @escaping () -> T,
 completion: @escaping (T) -> Void) {
 DispatchQueue.global(qos: .userInitiated).async {
 let result = work()
 DispatchQueue.main.async {
 completion(result)
 }
 }
 }

 // I/O任务
 static func io<T>(_ work: @escaping () throws -> T,
 completion: @escaping (Result<T, Error>) -> Void) {
 DispatchQueue.global(qos: .utility).async {
 do {
 let result = try work()
 DispatchQueue.main.async {
 completion(.success(result))
 }
 } catch {
 DispatchQueue.main.async {
 completion(.failure(error))
 }
 }
 }
 }

 // 低优先级后台任务
 static func background(_ work: @escaping () -> Void) {
 DispatchQueue.global(qos: .background).async {
 work()
 }
 }
}

// 使用示例
AsyncTaskManager.compute({
 // 复杂计算
 return self.processLargeDataSet()
}) { result in
 // 主线程更新UI
 self.displayResult(result)
}

Swift Concurrency

// 使用async/await
class DataProcessor {

 func processAsync() async throws -> ProcessedData {
 // 在后台执行
 return try await Task.detached(priority: .userInitiated) {
 return self.heavyProcessing()
 }.value
 }

 @MainActor
 func loadAndDisplay() async {
 do {
 let data = try await processAsync()
 // 自动在主线程更新UI
 updateUI(with: data)
 } catch {
 showError(error)
 }
 }
}

// 使用TaskGroup并行处理
func processImagesParallel(urls: [URL]) async -> [UIImage] {
 await withTaskGroup(of: UIImage?.self) { group in
 for url in urls {
 group.addTask {
 await self.loadImage(from: url)
 }
 }

 var images: [UIImage] = []
 for await image in group {
 if let image = image {
 images.append(image)
 }
 }
 return images
 }
}

任务拆分与调度

大任务拆分

当必须在主线程执行大量工作时，可以拆分成小块：

卡顿-原理

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

理解卡顿的原理是优化的基础。本文从屏幕显示的底层机制出发，沿着"VSync信号 -> 渲染管线 -> RunLoop协作 -> 掉帧产生"的逻辑链条，逐步揭示卡顿产生的根本原因。

屏幕显示的基础：VSync与缓冲机制

要理解卡顿，首先要理解屏幕是如何显示画面的。

VSync信号

VSync（Vertical Synchronization，垂直同步）是显示器发出的信号，用于协调GPU渲染和屏幕显示的时机。在60Hz的屏幕上，每16.67ms发出一次VSync信号。当信号到来时，屏幕从帧缓冲区读取数据进行显示。

时间轴：
│←── 16.67ms ──→│←── 16.67ms ──→│←── 16.67ms ──→│
 ↑ ↑ ↑
 VSync 1 VSync 2 VSync 3
 │ │ │
 显示帧1 显示帧2 显示帧3

双缓冲与三缓冲

为了避免画面撕裂（GPU写入和屏幕读取同一块内存导致），iOS使用多缓冲机制：

flowchart LR
subgraph 双缓冲机制
direction TB
GPU["GPU"] -->|渲染到| BB["后缓冲区（Back Buffer）"]
BB <-->|VSync时交换| FB["前缓冲区（Frame Buffer）"]
FB -->|读取显示| Display["显示器"]
end

双缓冲（默认）：GPU渲染到后缓冲区，VSync到来时交换前后缓冲区，显示器从前缓冲区读取。
三缓冲（高负载时自动启用）：增加第三个缓冲区，当渲染无法在一个VSync周期内完成时，GPU可以在额外缓冲区继续渲染，不必等待交换完成。代价是增加一帧延迟和内存占用。

系统在两者之间动态切换，开发者无需手动干预。

ProMotion自适应刷新率

ProMotion设备（iPhone 13 Pro及以上）支持10Hz-120Hz的自适应刷新率，这意味着帧时间预算不再固定：

刷新率	帧时间	卡顿阈值建议
120Hz	8.33ms	>16ms视为掉帧
60Hz	16.67ms	>33ms视为掉帧
30Hz	33.33ms	>66ms视为掉帧

// 检查设备最大刷新率
let maxFrameRate = UIScreen.main.maximumFramesPerSecond

// CADisplayLink适配ProMotion
if #available(iOS 15.0, *) {
 displayLink?.preferredFrameRateRange = CAFrameRateRange(
 minimum: 60,
 maximum: 120,
 preferred: 120
 )
}

iOS渲染架构

了解了屏幕显示机制后，接下来看iOS是如何将UI元素最终变成屏幕上的像素的。

卡顿-图片优化

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

图片处理是iOS应用中常见的性能瓶颈。本文介绍图片解码原理以及各种优化方案。

图片解码原理

为什么需要解码

图片文件（PNG、JPEG等）是压缩格式，无法直接显示。GPU需要的是位图（Bitmap）格式：

flowchart LR
A[压缩图片
PNG/JPEG] --> B[解码
Decode
CPU密集操作]
B --> C[位图
Bitmap
GPU可直接使用]

位图大小 = 宽度 × 高度 × 每像素字节数例如：1000×1000 RGBA图片 = 1000 × 1000 × 4 = 4MB

默认解码时机

// 加载图片（此时未解码）
let image = UIImage(named: "large_image")

// 设置到ImageView（仍未解码）
imageView.image = image

// 在 CATransaction commit 的 prepare 阶段，Core Animation 会在主线程对未解码的图片执行解码
// 未提前解码的图片一定会在此阶段被解码，从而阻塞主线程引发卡顿

异步解码

基本原理

将解码工作移到后台线程：

sequenceDiagram
participant M as 主线程
participant B as 后台线程
M->>B: 请求加载图片
Note over M: 继续处理其他事件
B->>B: 加载压缩数据
B->>B: 解码为位图
B->>B: 创建CGImage
B->>M: 返回解码后的图片
M->>M: 更新UI

实现方案1：强制解码

extension UIImage {

 /// 强制解码图片
 func decodedImage() -> UIImage? {
 guard let cgImage = self.cgImage else { return nil }

 let width = cgImage.width
 let height = cgImage.height

 // 创建位图上下文
 let colorSpace = CGColorSpaceCreateDeviceRGB()
 let bitmapInfo = CGBitmapInfo(rawValue: CGImageAlphaInfo.premultipliedFirst.rawValue | CGBitmapInfo.byteOrder32Little.rawValue)

 guard let context = CGContext(
 data: nil,
 width: width,
 height: height,
 bitsPerComponent: 8,
 bytesPerRow: 0,
 space: colorSpace,
 bitmapInfo: bitmapInfo.rawValue
 ) else {
 return nil
 }

 // 绘制到上下文（触发解码）
 context.draw(cgImage, in: CGRect(x: 0, y: 0, width: width, height: height))

 // 从上下文创建新图片
 guard let decodedCGImage = context.makeImage() else { return nil }

 return UIImage(cgImage: decodedCGImage, scale: scale, orientation: imageOrientation)
 }
}

// 异步使用
func loadImageAsync(named name: String, completion: @escaping (UIImage?) -> Void) {
 DispatchQueue.global(qos: .userInitiated).async {
 let image = UIImage(named: name)?.decodedImage()

 DispatchQueue.main.async {
 completion(image)
 }
 }
}

实现方案2：使用ImageIO

import ImageIO

class ImageDecoder {

 static func decodeImage(from url: URL) -> UIImage? {
 guard let source = CGImageSourceCreateWithURL(url as CFURL, nil) else {
 return nil
 }

 let options: [CFString: Any] = [
 kCGImageSourceShouldCache: true,
 kCGImageSourceShouldCacheImmediately: true // 立即解码
 ]

 guard let cgImage = CGImageSourceCreateImageAtIndex(source, 0, options as CFDictionary) else {
 return nil
 }

 return UIImage(cgImage: cgImage)
 }

 static func decodeImageAsync(from url: URL, completion: @escaping (UIImage?) -> Void) {
 DispatchQueue.global(qos: .userInitiated).async {
 let image = ImageDecoder.decodeImage(from: url)

 DispatchQueue.main.async {
 completion(image)
 }
 }
 }
}

实现方案3：使用UIGraphicsImageRenderer

extension UIImage {

 func decodedImageUsingRenderer() -> UIImage {
 let format = UIGraphicsImageRendererFormat()
 format.scale = scale
 format.opaque = true
 format.preferredRange = .standard

 let renderer = UIGraphicsImageRenderer(size: size, format: format)

 return renderer.image { context in
 draw(at: .zero)
 }
 }
}

图片降采样

为什么需要降采样

当图片尺寸远大于显示尺寸时，加载原图是浪费：

卡顿-检测

Thu, 07 May 2026 16:54:12 +0800

准确检测卡顿是优化的前提。本文介绍多种卡顿检测方案，从开发调试到线上监控都有对应的方案。

检测方案概览

方案	原理	优点	缺点	适用场景
CADisplayLink	监控帧节奏、FPS、慢帧/掉帧	简单直接、适合趋势观察	无法直接给出堆栈，FPS 只能辅助判断	开发调试/线上辅助指标
RunLoop Observer	监控RunLoop状态	可获取堆栈	有一定开销	开发/线上
子线程Ping	定时检测主线程响应	实现简单	精度有限	线上监控
Instruments	系统级分析	信息详细	只能开发时用	性能分析
MetricKit	系统数据收集	无额外开销	iOS 13+	线上监控
Sentry ANR V2	帧延迟分析	区分阻塞类型	需集成SDK	线上监控

1. CADisplayLink监控

基本原理

CADisplayLink 是一个和屏幕显示刷新节奏同步的回调。它适合回答“当前 UI 刷新是否顺畅、是否出现慢帧、掉帧或冻结帧”，但 FPS 本身只是辅助参考，不能单独作为卡顿结论。

原因是：

FPS 只描述结果，不描述原因：FPS 下降只能说明某段时间显示帧变少了，不能告诉你是主线程计算、布局、图片解码、锁等待、I/O、GPU 渲染还是系统主动降刷新率导致的。
ProMotion 会动态调整刷新率：在支持 120Hz 的机型上，系统可能根据内容和功耗策略把刷新率降到 10Hz、24Hz、30Hz、60Hz、80Hz、120Hz 等。静止页面低 FPS 可能只是系统主动省电，不是卡顿。
主线程阻塞会让回调延迟：如果主线程真的被阻塞，CADisplayLink 回调本身也会延后，此时需要结合实际回调间隔、RunLoop 状态和堆栈采样判断。

因此线上卡顿监控更推荐记录 帧间隔 / 慢帧 / 冻结帧 / 交互场景，而不是只显示一个“当前 FPS”。

卡顿-离屏渲染

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

离屏渲染（Offscreen Rendering）是GPU渲染中的性能杀手。本文介绍离屏渲染的原理、触发条件以及优化方案。

什么是离屏渲染

正常渲染流程

正常情况下，GPU直接将渲染结果写入帧缓冲区（Frame Buffer）：

flowchart LR
subgraph 正常渲染["正常渲染 On-Screen Rendering"]
A[GPU
渲染] --> B[Frame Buffer
帧缓冲区] --> C[屏幕
显示]
end
style A fill:#e1f5fe
style B fill:#fff3e0
style C fill:#e8f5e9

特点：

直接渲染到帧缓冲区
渲染完成即可显示
效率最高

离屏渲染流程

离屏渲染需要先渲染到离屏缓冲区，再合成到帧缓冲区：

flowchart LR
subgraph 离屏渲染["离屏渲染 Offscreen Rendering"]
A[GPU
渲染] --> B[Offscreen Buffer
离屏缓冲区]
B --> C[Frame Buffer
帧缓冲区]
C --> D[屏幕
显示]
end
E[额外的缓冲区] -.-> B
style A fill:#e1f5fe
style B fill:#f48fb1
style C fill:#fff3e0
style D fill:#e8f5e9
style E fill:#f48fb1,stroke:#f44336,stroke-dasharray: 5 5

性能开销：

卡顿

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

卡顿是影响用户体验的关键问题之一。当应用无法在一帧的时间内（通常为16.67ms）完成渲染工作时，就会出现掉帧，用户会感知到界面不流畅。

本系列文章从渲染原理入手，系统性地介绍iOS卡顿的检测与优化方法。

卡顿监控是 APM 流畅性子系的核心能力，线上指标体系、检测采集、上报策略请参考 APM 系列：指标体系、数据采集、业界方案（微信 Matrix / 字节 Slardar 卡死监控）。

什么是卡顿

iOS设备的屏幕刷新率通常为60Hz（ProMotion设备可达120Hz），这意味着每秒需要渲染60帧画面。每一帧的渲染时间窗口约为16.67ms（1000ms / 60）。

当CPU或GPU无法在这个时间窗口内完成工作时，就会发生掉帧（Frame Drop），用户会感知到卡顿。

掉帧情况	用户感知	严重程度
偶尔掉1-2帧	几乎无感知	轻微
连续掉帧	明显卡顿	中等
长时间阻塞（>250ms）	界面冻结	严重

渲染流程概述

iOS的渲染流程涉及CPU和GPU的协作，通过Core Animation Pipeline完成：

flowchart TB
subgraph APP["App 进程（CPU 阶段）"]
direction TB
Layout["Layout（布局计算）
layoutSubviews、约束计算"]
Display["Display（绘制显示）
drawRect:、文本绘制"]
Prepare["Prepare（准备）
图片解码、格式转换"]
Commit["Commit（提交）
打包图层树"]
Layout --> Display --> Prepare --> Commit
end
subgraph RS["Render Server 进程（GPU 阶段）"]
direction TB
Decode["解码图层树"]
Vertex["顶点着色器"]
Raster["光栅化"]
Fragment["片段着色器"]
Buffer["帧缓冲区写入"]
Decode --> Vertex --> Raster --> Fragment --> Buffer
end
APP -->|"IPC 传输"| RS
RS --> VSync["VSync 信号到来"]
VSync --> Screen["显示到屏幕"]

CPU与GPU的职责

阶段	主要工作	常见瓶颈
CPU	布局计算、视图创建、文本计算、图片解码	复杂布局、大量文本、主线程阻塞
GPU	纹理渲染、图层混合、离屏渲染	离屏渲染、大量透明图层、超大图片

卡顿的常见原因

CPU瓶颈

主线程阻塞：耗时操作在主线程执行
复杂布局：大量约束计算、频繁布局
文本计算：复杂富文本、大量文本渲染
图片解码：大图片在主线程解码
对象创建：大量对象的创建和销毁

GPU瓶颈

离屏渲染：圆角、阴影、遮罩触发离屏渲染
图层混合：大量透明图层叠加
超大图片：纹理尺寸超过GPU限制
复杂特效：模糊、滤镜等GPU密集操作

文章导航

本系列包含以下文章，建议按顺序阅读：

包瘦身-App Thinning

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

App Thinning是Apple提供的包体积优化技术，让用户只下载适合其设备的内容。本文详细介绍App Thinning的三个组成部分及其原理。

整体架构

开发者上传：
┌─────────────────────────────────────────┐
│ Universal IPA │
│ ├── arm64 代码 │
│ ├── @1x/@2x/@3x 图片 │
│ ├── iPhone/iPad 资源 │
│ └── Metal GPU资源（OpenGL ES已弃用） │
└─────────────────────────────────────────┘
 ↓
 App Store处理
 ↓
┌───────────┐ ┌──────────┐ ┌──────────┐
│ iPhone 12 │ │ iPhone 8 │ │ iPad Pro │
│ 变体 │ │ 变体 │ │ 变体 │
│ @3x图片 │ │ @2x图片 │ │ @2x图片 │
│ arm64 │ │ arm64 │ │ arm64 │
│ A14 GPU │ │ A11 GPU │ │ M1 GPU │
└───────────┘ └──────────┘ └──────────┘

App Thinning包含三个部分：

包瘦身-分析工具

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

在进行包体积优化之前，首先需要了解如何分析包体积。本文介绍常用的分析工具和Mach-O文件结构。

查看IPA构成

解压IPA文件分析各部分大小：

# 解压IPA
unzip -q YourApp.ipa -d ./ipa_content

# 查看各文件大小
find ./ipa_content -type f -exec ls -lh {} \; | sort -k5 -h -r | head -20

LinkMap分析

LinkMap文件记录了链接器生成可执行文件的详细信息，可以精确分析二进制大小：

# Build Settings中设置
Write Link Map File = YES
Path to Link Map File = $(TARGET_TEMP_DIR)/$(PRODUCT_NAME)-LinkMap-$(CURRENT_VARIANT)-$(CURRENT_ARCH).txt

LinkMap文件结构

# Path: /path/to/YourApp
# Arch: arm64

# Object files:
[ 0] linker synthesized
[ 1] /path/to/ViewController.o
[ 2] /path/to/Model.o

# Sections:
# Address Size Segment Section
0x100001000 0x00012345 __TEXT __text
0x100013345 0x00001234 __TEXT __stubs

# Symbols:
# Address Size File Name
0x100001000 0x00000100 [ 1] -[ViewController viewDidLoad]
0x100001100 0x00000050 [ 2] -[Model init]

解析脚本

可以使用脚本解析LinkMap统计各模块大小：

包瘦身-可执行文件优化

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

可执行文件通常占iOS应用包体积的30-50%，是优化的重点。本文介绍各种可执行文件优化手段及其原理。

编译器优化选项

优化级别原理

编译器优化级别控制了LLVM在编译时应用的优化Pass数量和类型。

什么是优化Pass？ Pass是指编译器对代码进行的一次特定优化处理过程。LLVM将优化工作分解为多个独立的Pass，每个Pass负责一种特定类型的优化：

源代码 → 前端解析 → IR（中间表示）→ Pass1 → Pass2 → Pass3 → ... → 优化后的代码 → 机器码

常见的优化Pass包括：

Pass名称	作用
Dead Code Elimination	删除永远不会执行的代码
Constant Folding	编译时计算常量表达式，如`3+5`直接变成`8`
Function Inlining	将函数调用替换为函数体本身
Loop Unrolling	展开循环，减少循环控制开销
Common Subexpression Elimination	消除重复计算的表达式

不同的优化级别启用不同数量和类型的Pass：

# Build Settings
Optimization Level = -Os # 级别：-Os 优化大小（推荐用于Release）

-O0（无优化）

不应用任何优化Pass，编译速度最快。代码按原样生成，保留所有变量和控制流，便于调试。适用于Debug构建。

-O1（基础优化）

应用不显著增加编译时间的基础优化，包括：

基本的死代码消除
简单的常量折叠
基本块合并

死代码消除： 死代码消除（Dead Code Elimination）是指编译器自动移除永远不会被执行或执行结果不会被使用的代码。注意：这里的死代码消除是编译阶段的优化，作用于函数内部；而后文提到的Dead Code Stripping是链接阶段的优化，用于移除未被引用的整个函数或类。

-O1 适合需要一定优化但对编译速度敏感的场景。

-O2（标准优化）

应用大多数优化Pass，是性能和体积的平衡点。包括：

包瘦身-资源优化

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

资源文件通常占iOS应用包体积的40-60%，是优化的重要方向。本文介绍各种资源优化手段及其原理。

图片优化

Asset Catalog原理

Asset Catalog（.xcassets）编译后生成Assets.car文件，这是一个优化过的资源容器：

编译前：
Images.xcassets/
├── AppIcon.appiconset/
│ ├── icon-60@2x.png
│ └── icon-60@3x.png
├── Logo.imageset/
│ ├── logo@2x.png
│ └── logo@3x.png
└── Contents.json

编译后：
Assets.car ← 单一文件，包含所有资源

Assets.car的优化：

图片被重新编码，使用更高效的压缩
支持App Thinning，按设备分发
运行时高效加载（内存映射）

可以使用assetutil查看Assets.car内容：

assetutil --info Assets.car

图片压缩原理

PNG压缩原理：

PNG使用DEFLATE无损压缩，但可以通过以下方式减小体积：

原始PNG结构：
┌────────────────┐
│ PNG Header │
├────────────────┤
│ IHDR (图像信息) │
├────────────────┤
│ IDAT (图像数据) │ ← 压缩的像素数据
├────────────────┤
│ 辅助chunks │ ← 可以移除
└────────────────┘

优化方向：
1. 移除不必要的chunks（如tEXt、iTXt）
2. 优化DEFLATE压缩参数
3. 减少颜色数量（有损）
4. 使用更高效的滤波器

有损压缩原理（pngquant）：

包瘦身

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

包体积（IPA大小）是iOS应用的重要质量指标。App Store对蜂窝网络下载有200MB的提示阈值，超过这个大小会弹窗询问用户是否使用流量下载（iOS 13之前是强制要求Wi-Fi）。这个弹窗会增加用户的决策成本，影响下载转化率。因此，包体积优化对于用户获取和留存都有重要影响。

包格式介绍

iOS开发中常见的包格式有三种：

格式	扩展名	说明
.app	目录	应用程序包，是一个包含可执行文件和资源的目录结构
.xcarchive	目录	Xcode归档包，包含.app、dSYM符号文件、构建信息等
.ipa	文件	安装包，本质是ZIP压缩的.app，用于分发和安装

日常使用场景：

开发调试：Xcode直接将.app安装到模拟器或真机
测试分发：使用.ipa通过TestFlight、蒲公英、fir.im等平台分发给测试人员
App Store上架：通过Xcode或Transporter将.xcarchive导出并上传到App Store Connect（实际上传的是从xcarchive导出的IPA或直接上传xcarchive中的内容）

.app（Application Bundle）

.app是macOS/iOS应用的标准格式，实际上是一个目录（Finder中显示为单个文件）。包含：

可执行文件（Mach-O格式）
Info.plist配置文件
资源文件（图片、音频、本地化文件等）
Frameworks目录（动态库）
PlugIns目录（App Extension）

.xcarchive（Xcode Archive）

.xcarchive是Xcode的归档格式，用于保存完整的构建产物。目录结构：

YourApp.xcarchive/
├── Products/
│ └── Applications/
│ └── YourApp.app # 应用程序包
├── dSYMs/
│ └── YourApp.app.dSYM # 符号文件（用于崩溃解析）
├── Info.plist
└── SCMBlueprint/ # 源码管理信息

主要用途：

保存dSYM符号文件，用于线上崩溃日志符号化
导出不同分发渠道的IPA（App Store、Ad Hoc、Enterprise）
上传到App Store Connect

.ipa（iOS App Store Package）

.ipa是iOS应用的安装包格式，本质是一个ZIP压缩文件。结构：