阅读视图

发现新文章,点击刷新页面。

OpenClaw 学习笔记

今天尝试安装了一下 OpenClaw,记录一些要点。

1、执行安装脚本

curl -fsSL https://openclaw.ai/install.sh | bash

2、申请 Telegram Bot

在 Telegram 上找 @BotFather 聊天,输入 /newbot,然后设置好昵称和帐号名,最终记录下 Bot 的 API Key。

我本来还申请了飞书的 Bot,但是发现比 Telegram 麻烦很多,为了快速测试,就放弃了飞书。

3、申请大模型的 API Key

我申请的是 OpenRouter 上的 Key,这样方便切换模型做测试。这一步需要刷信用卡充值。

因为是测试,为了防止 OpenClaw 超用量,我充了 10 美元,并且设置了一天使用限额最多 5 美元。

4、配置

第一步安装到最后就会自动执行 openclaw onboard,这是一个交互式配置程序,然后你就可以在程序中配置上面第 2 和第 3 步的 Key。

安装好的 OpenClaw 在 ~/.openclaw/ 下有一个叫 openclaw.json的文件。所有的交互配置都是在帮你更新这个文件。

所以,其实你也可以直接在这个文件中设置 Telegram 的配置信息,类似这样:

1
2
3
4
5
6
7
8
9
10
{
channels: {
telegram: {
enabled: true,
botToken: "填写你申请的 BOT 的 KEY",
dmPolicy: "pairing",
groups: { "*": { requireMention: true } },
},
},
}

5、配对

用你的 Telegram 给 BOT 发一条信息,然后 OpenClaw 会回复你 Pairing code。在你的命令行中执行回复内容的最后一行代码,类似这样:

1
openclaw pairing approve telegram <pairing code>

,就完成了帐号的配对。

这其实修改的是 ~/.openclaw/credentials/telegram-default-allowFrom.json 文件。

所有的配置都在文件中,所以也很方便你随时查看、修改或备份。

6、控制面板

现在你就可以和 OpenClaw 用 Telegram 聊天了。你也可以打开网页版的控制面板,默认在 http://127.0.0.1:18789/ 查看到相关的信息。

7、其它的一些执令

  • 关闭 openclaw:openclaw gateway stop
  • 重启 openclaw:openclaw gateway restart
  • 检查:openclaw doctor

8、初步的使用感受

  • 定时执令应该会比较好用。比如帮你每天整理一些消息、新闻什么的。
  • 当作 ifttt 的高级版应该也会挺好,比如:
    • 当我 push 文章到 github 的时候,就帮我同步发布。
    • 当我给它发票的时候,就帮我提报销(或至少整理发票)。
  • 日常问答/编程/整理文件/写作 感觉都不太适合,还不如用对应的产品。
  • 如果不是程序员/产品经理,就别试用了,大量的命令行操作,还是太不适合小白了。

01-研究系统框架@Web@iOS | JavaScriptCore 框架:从使用到原理解析

JavaScriptCore 框架:从使用到原理解析

JavaScript 越来越多地出现在我们客户端开发的视野中,从 React Native 到 JSPatch,JavaScript 与客户端相结合的技术开始变得魅力无穷。本文主要讲解 iOS 中的 JavaScriptCore 框架,正是它为 iOS 提供了执行 JavaScript 代码的能力。未来的技术日新月异,JavaScript 与 iOS 正在碰撞出新的激情。

JavaScriptCoreJavaScript虚拟机,为 JavaScript 的执行提供底层资源。


📋 目录


一、JavaScript

在讨论JavaScriptCore之前,我们首先必须对JavaScript有所了解。

1. JavaScript干啥的?

  • 说的高大上一点:一门基于原型、函数先行的高级编程语言,通过解释执行,是动态类型的直译语言。是一门多范式的语言,它支持面向对象编程,命令式编程,以及函数式编程。
  • 说的通俗一点:主要用于网页,为其提供动态交互的能力。可嵌入动态文本于HTML页面,对浏览器事件作出响应,读写HTML元素,控制cookies等。
  • 再通俗一点:抢月饼,button.click()。(PS:请谨慎使用while循环)

img

2. JavaScript起源与历史

  • 1990年底,欧洲核能研究组织(CERN)科学家Tim Berners-Lee,在互联网的基础上,发明了万维网(World Wide Web),从此可以在网上浏览网页文件。
  • 1994年12月,Netscape 发布了一款面向普通用户的新一代的浏览器Navigator 1.0版,市场份额一举超过90%。
  • 1995年,Netscape公司雇佣了程序员Brendan Eich开发这种嵌入网页的脚本语言。最初名字叫做Mocha,1995年9月改为LiveScript。
  • 1995年12月,Netscape公司与Sun公司达成协议,后者允许将这种语言叫做JavaScript。

3. JavaScript与ECMAScript

  • “JavaScript”是Sun公司的注册商标,用来特制网景(现在的Mozilla)对于这门语言的实现。网景将这门语言作为标准提交给了ECMA——欧洲计算机制造协会。由于商标上的冲突,这门语言的标准版本改了一个丑陋的名字“ECMAScript”。同样由于商标的冲突,微软对这门语言的实现版本取了一个广为人知的名字“Jscript”。
  • ECMAScript作为JavaScript的标准,一般认为后者是前者的实现。

4. Java和JavaScript

img

《雷锋和雷峰塔》

Java 和 JavaScript 是两门不同的编程语言 一般认为,当时 Netscape 之所以将 LiveScript 命名为 JavaScript,是因为 Java 是当时最流行的编程语言,带有 “Java” 的名字有助于这门新生语言的传播。

二、 JavaScriptCore

1. 浏览器演进

  • 演进完整图

upload.wikimedia.org/wikipedia/c…

  • WebKit分支

现在使用WebKit的主要两个浏览器Sfari和Chromium(Chorme的开源项目)。WebKit起源于KDE的开源项目Konqueror的分支,由苹果公司用于Sfari浏览器。其一条分支发展成为Chorme的内核,2013年Google在此基础上开发了新的Blink内核。

img

2. WebKit排版引擎

webkit是sfari、chrome等浏览器的排版引擎,各部分架构图如下

img

  • webkit Embedding API是browser UI与webpage进行交互的api接口;
  • platformAPI提供与底层驱动的交互, 如网络, 字体渲染, 影音文件解码, 渲染引擎等;
  • WebCore它实现了对文档的模型化,包括了CSS, DOM, Render等的实现;
  • JSCore是专门处理JavaScript脚本的引擎;

3. JavaScript引擎

  • JavaScript引擎是专门处理JavaScript脚本的虚拟机,一般会附带在网页浏览器之中。第一个JavaScript引擎由布兰登·艾克在网景公司开发,用于Netscape Navigator网页浏览器中。JavaScriptCore就是一个JavaScript引擎。
  • 下图是当前主要的还在开发中的JavaScript引擎

img

4. JavaScriptCore组成

JavaScriptCore主要由以下模块组成:

  • Lexer 词法分析器,将脚本源码分解成一系列的Token
  • Parser 语法分析器,处理Token并生成相应的语法树
  • LLInt 低级解释器,执行Parser生成的二进制代码
  • Baseline JIT 基线JIT(just in time 实施编译)
  • DFG 低延迟优化的JIT
  • FTL 高通量优化的JIT

关于更多JavaScriptCore的实现细节,参考 trac.webkit.org/wiki/JavaSc…

5. JavaScriptCore 框架与历史

JavaScriptCore 是一个 C++ 实现的开源项目(WebKit 的一部分)。历史上,JSC 长期作为 Safari / WebKit 的内置 JS 引擎;自 iOS 7.0 / OS X 10.9 起,Apple 将 JavaScriptCore 以系统框架 JavaScriptCore.framework 的形式开放给开发者,使其可在 Objective-C 或基于 C 的程序中执行 JavaScript 代码,并向 JS 环境中插入自定义对象,而无需依赖 UIWebView。这为 Hybrid 应用、热更新、脚本引擎等场景提供了统一的底层能力。

JavaScriptCore.h 中,我们可以看到:

#ifndef JavaScriptCore_h
#define JavaScriptCore_h

#include <JavaScriptCore/JavaScript.h>
#include <JavaScriptCore/JSStringRefCF.h>

#if defined(__OBJC__) && JSC_OBJC_API_ENABLED

#import "JSContext.h"
#import "JSValue.h"
#import "JSManagedValue.h"
#import "JSVirtualMachine.h"
#import "JSExport.h"

#endif

#endif /* JavaScriptCore_h */

这里已经很清晰地列出了JavaScriptCore的主要几个类:

  • JSContext
  • JSValue
  • JSManagedValue
  • JSVirtualMachine
  • JSExport

接下来我们会依次讲解这几个类的用法。

6. Hello World!

这段代码展示了如何在 Objective-C 中执行一段 JavaScript 代码,并且获取返回值并转换成 OC 数据打印:

// 创建虚拟机
JSVirtualMachine *vm = [[JSVirtualMachine alloc] init];

//创建上下文
JSContext *context = [[JSContext alloc] initWithVirtualMachine:vm];

//执行JavaScript代码并获取返回值
JSValue *value = [context evaluateScript:@"1+2*3"];

// 转换成 OC 数据并打印
NSLog(@"value = %d", [value toInt32]);
// Output: value = 7

Swift 等价写法:

import JavaScriptCore

let vm = JSVirtualMachine()!
let context = JSContext(virtualMachine: vm)!
let value = context.evaluateScript("1 + 2 * 3")!
print("value =", value.toInt32())  // value = 7

三、 JSVirtualMachine

一个JSVirtualMachine的实例就是一个完整独立的JavaScript的执行环境,为JavaScript的执行提供底层资源。

这个类主要用来做两件事情:

  1. 实现并发的 JavaScript 执行
  2. JavaScript 和 Objective-C 桥接对象的内存管理

看下头文件 JSVirtualMachine.h 里有什么:

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSVirtualMachine : NSObject

/* 创建一个新的完全独立的虚拟机 */
(instancetype)init;

/* 对桥接对象进行内存管理 */
- (void)addManagedReference:(id)object withOwner:(id)owner;

/* 取消对桥接对象的内存管理 */
- (void)removeManagedReference:(id)object withOwner:(id)owner;

@end

每一个JavaScript上下文(JSContext对象)都归属于一个虚拟机(JSVirtualMachine)。每个虚拟机可以包含多个不同的上下文,并允许在这些不同的上下文之间传值(JSValue对象)。

然而,每个虚拟机都是完整且独立的,有其独立的堆空间和垃圾回收器(garbage collector ),GC无法处理别的虚拟机堆中的对象,因此你不能把一个虚拟机中创建的值传给另一个虚拟机。

img

线程和JavaScript的并发执行

JavaScriptCore API都是线程安全的。你可以在任意线程创建JSValue或者执行JS代码,然而,所有其他想要使用该虚拟机的线程都要等待。

  • 如果想并发执行JS,需要使用多个不同的虚拟机来实现。
  • 可以在子线程中执行JS代码。

通过下面这个 demo 来理解这个并发机制:

JSContext *context = [[CustomJSContext alloc] init];
JSContext *context1 = [[CustomJSContext alloc] init];
JSContext *context2 = [[CustomJSContext alloc] initWithVirtualMachine:[context virtualMachine]];
NSLog(@"start");
dispatch_async(queue, ^{
    while (true) {
        sleep(1);
        [context evaluateScript:@"log('tick')"];
    }
});
dispatch_async(queue1, ^{
    while (true) {
        sleep(1);
        [context1 evaluateScript:@"log('tick_1')"];
    }
});
dispatch_async(queue2, ^{
    while (true) {
        sleep(1);
        [context2 evaluateScript:@"log('tick_2')"];
    }
});
[context evaluateScript:@"sleep(5)"];
NSLog(@"end");

context和context2属于同一个虚拟机。

context1属于另一个虚拟机。

三个线程分别异步执行每秒1次的js log,首先会休眠1秒。

在context上执行一个休眠5秒的JS函数。

首先执行的应该是休眠5秒的JS函数,在此期间,context所处的虚拟机上的其他调用都会处于等待状态,因此tick和tick_2在前5秒都不会有执行。

而context1所处的虚拟机仍然可以正常执行tick_1

休眠5秒结束后,tick和tick_2才会开始执行(不保证先后顺序)。

实际运行输出的 log 是:

start
tick_1
tick_1
tick_1
tick_1
end
tick
tick_2

四、 JSContext

一个JSContext对象代表一个JavaScript执行环境。在native代码中,使用JSContext去执行JS代码,访问JS中定义或者计算的值,并使JavaScript可以访问native的对象、方法、函数。

img

1. JSContext执行JS代码

  • 调用evaluateScript函数可以执行一段top-level 的JS代码,并可向global对象添加函数和对象定义
  • 其返回值是JavaScript代码中最后一个生成的值

API Reference

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSContext : NSObject

/* 创建一个JSContext,同时会创建一个新的JSVirtualMachine */
(instancetype)init;

/* 在指定虚拟机上创建一个JSContext */
(instancetype)initWithVirtualMachine:
        (JSVirtualMachine*)virtualMachine;

/* 执行一段JS代码,返回最后生成的一个值 */
(JSValue *)evaluateScript:(NSString *)script;

/* 执行一段JS代码,并将sourceURL认作其源码URL(仅作标记用) */
- (JSValue *)evaluateScript:(NSString *)script withSourceURL:(NSURL*)sourceURL     NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的context */
+ (JSContext *)currentContext;

/* 获取当前执行的JavaScript function*/
+ (JSValue *)currentCallee NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的this */
+ (JSValue *)currentThis;

/* Returns the arguments to the current native callback from JavaScript code.*/
+ (NSArray *)currentArguments;

/* 获取当前context的全局对象。WebKit中的context返回的便是WindowProxy对象*/
@property (readonly, strong) JSValue *globalObject;

@property (strong) JSValue *exception;
@property (copy) void(^exceptionHandler)(JSContext *context, JSValue
    *exception);

@property (readonly, strong) JSVirtualMachine *virtualMachine;

@property (copy) NSString *name NS_AVAILABLE(10_10, 8_0);


@end

2. JSContext访问JS对象

一个JSContext对象对应了一个全局对象(global object)。例如web浏览器中中的JSContext,其全局对象就是window对象。在其他环境中,全局对象也承担了类似的角色,用来区分不同的JavaScript context的作用域。全局变量是全局对象的属性,可以通过JSValue对象或者context下标的方式来访问。

示例代码:

JSValue *value = [context evaluateScript:@"var a = 1+2*3;"];

NSLog(@"a = %@", [context objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", [context.globalObject objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", context[@"a"]);
// Output: a = 7, a = 7, a = 7

这里列出了三种访问JavaScript对象的方法

  • 通过context的实例方法objectForKeyedSubscript
  • 通过context.globalObject的objectForKeyedSubscript实例方法
  • 通过下标方式

设置属性也是对应的。

API Reference

/* 为 JSContext 提供下标访问元素的方式 */
@interface JSContext (SubscriptSupport)

/* 首先将key转为JSValue对象,然后使用这个值在JavaScript context的全局对象中查找这个名字的属性并返回 */
(JSValue *)objectForKeyedSubscript:(id)key;

/* 首先将key转为JSValue对象,然后用这个值在JavaScript context的全局对象中设置这个属性。
可使用这个方法将native中的对象或者方法桥接给JavaScript调用 */
(void)setObject:(id)object forKeyedSubscript:(NSObject <NSCopying>*)key;

@end



/* 例如:以下代码在JavaScript中创建了一个实现是Objective-C block的function */
context[@"makeNSColor"] = ^(NSDictionary *rgb){
    float r = [rgb[@"red"] floatValue];
    float g = [rgb[@"green"] floatValue];
    float b = [rgb[@"blue"] floatValue];
    return [NSColor colorWithRed:(r / 255.f) green:(g / 255.f) blue:(b / 255.f)         alpha:1.0];
};
JSValue *value = [context evaluateScript:@"makeNSColor({red:12, green:23, blue:67})"];

五、 JSValue

一个JSValue实例就是一个JavaScript值的引用。使用JSValue类在JavaScript和native代码之间转换一些基本类型的数据(比如数值和字符串)。你也可以使用这个类去创建包装了自定义类的native对象的JavaScript对象,或者创建由native方法或者block实现的JavaScript函数。

每个JSValue实例都来源于一个代表JavaScript执行环境的JSContext对象,这个执行环境就包含了这个JSValue对应的值。每个JSValue对象都持有其JSContext对象的强引用,只要有任何一个与特定JSContext关联的JSValue被持有(retain),这个JSContext就会一直存活。通过调用JSValue的实例方法返回的其他的JSValue对象都属于与最始的JSValue相同的JSContext。

img

每个JSValue都通过其JSContext间接关联了一个特定的代表执行资源基础的JSVirtualMachine对象。你只能将一个JSValue对象传给由相同虚拟机管理(host)的JSValue或者JSContext的实例方法。如果尝试把一个虚拟机的JSValue传给另一个虚拟机,将会触发一个Objective-C异常。

img

1. JSValue类型转换

JSValue提供了一系列的方法将native与JavaScript的数据类型进行相互转换:

img

2. NSDictionary与JS对象

NSDictionary 对象以及其包含的 keys 与 JavaScript 中的对应名称的属性相互转换。key 所对应的值也会递归地进行拷贝和转换。

[context evaluateScript:@"var color = {red:230, green:90, blue:100}"];

//js->native 给你看我的颜色
JSValue *colorValue = context[@"color"];
NSLog(@"r=%@, g=%@, b=%@", colorValue[@"red"], colorValue[@"green"], colorValue[@"blue"]);
NSDictionary *colorDic = [colorValue toDictionary];
NSLog(@"r=%@, g=%@, b=%@", colorDic[@"red"], colorDic[@"green"], colorDic[@"blue"]);

//native->js 给你点颜色看看
context[@"color"] = @{@"red":@(0), @"green":@(0), @"blue":@(0)};
[context evaluateScript:@"log('r:'+color.red+'g:'+color.green+' b:'+color.blue)"];
// Output:
// r=230, g=90, b=100
// r=230, g=90, b=100
// r:0 g:0 b:0

可见,JS中的对象可以直接转换成Objective-C中的NSDictionary,NSDictionary传入JavaScript也可以直接当作对象被使用。

3. NSArray与JS数组

NSArray 对象与 JavaScript 中的 array 相互转换。其子元素也会递归地进行拷贝和转换。

[context evaluateScript:@"var friends = ['Alice','Jenny','XiaoMing']"];

//js->native 你说哪个是真爱?
JSValue *friendsValue = context[@"friends"];
NSLog(@"%@, %@, %@", friendsValue[0], friendsValue[1], friendsValue[2]);
NSArray *friendsArray = [friendsValue toArray];
NSLog(@"%@, %@, %@", friendsArray[0], friendsArray[1], friendsArray[2]);

//native->js 我觉得 XiaoMing 不错,给你再推荐个 Jimmy
context[@"girlFriends"] = @[friendsArray[2], @"Jimmy"];
[context evaluateScript:@"log('girlFriends :'+girlFriends[0]+' '+girlFriends[1])"];
// Output: Alice, Jenny, XiaoMing / girlFriends : XiaoMing Jimmy

4. Block/函数和JS function

Objective-C中的block转换成JavaScript中的function对象。参数以及返回类型使用相同的规则转换。

将一个代表native的block或者方法的JavaScript function进行转换将会得到那个block或方法。

其他的JavaScript函数将会被转换为一个空的dictionary。因为JavaScript函数也是一个对象。

5. OC对象和JS对象

对于所有其他 native 的对象类型,JavaScriptCore 都会创建一个拥有 constructor 原型链的 wrapper 对象,用来反映 native 类型的继承关系。默认情况下,native 对象的属性和方法并不会导出给其对应的 JavaScript wrapper 对象。通过 JSExport 协议可选择性地导出属性和方法。下面第六节对 JSExport 与原生对象导出做详细讲解。


六、JSExport 与原生对象导出

JSExport 是 JavaScriptCore 框架中的协议,用于将 Objective-C/Swift 的类(属性与方法)选择性导出给 JavaScript,使 JS 代码可以像调用普通对象一样调用原生对象 [1][2]。

6.1 作用与机制

  • 遵循 JSExport 的协议中声明的属性和方法,会在将 native 对象注入到 JSContext(如 context[@"bridge"] = nativeObject)时,自动暴露为 JS 侧的属性和函数。
  • 若类未实现 JSExport 或未在协议中声明,则对应属性/方法不会出现在 JS 中;这样可控制「桥接面」,避免暴露内部实现 [1][2]。

6.2 使用示例(概念)

@protocol MyPointExport <JSExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
- (NSString *)description;
@end

@interface MyPoint : NSObject <MyPointExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
@end

MyPoint 实例赋给 context[@"point"] 后,在 JS 中可访问 point.xpoint.y 并调用 point.description()
注意:若在 Block 或导出方法中再次使用 JSValueJSContext,需注意线程与内存管理(见第七节 JSManagedValue)[1][2]。

Swift 中的等价写法(通过 JSContext 注入遵循 JSExport 的类):

import JavaScriptCore

@objc protocol PointExport: JSExport {
    var x: Double { get set }
    var y: Double { get set }
    func description() -> String
}

class Point: NSObject, PointExport {
    @objc var x: Double
    @objc var y: Double
    init(x: Double, y: Double) { self.x = x; self.y = y }
    func description() -> String { "Point(\(x), \(y))" }
}

// 注入到 context
let context = JSContext()!
context.setObject(Point(x: 1, y: 2), forKeyedSubscript: "point" as NSString)
context.evaluateScript("point.x; point.description()")

6.3 与 Block 注入的对比

方式 适用场景
context[@"fn"] = ^(id arg){ ... } 单次或简单逻辑,直接暴露为 JS 函数
JSExport 协议 + 原生对象 需要暴露多个方法/属性、保持对象身份与状态的「桥接对象」

七、JSManagedValue 与内存管理

7.1 为何需要 JSManagedValue

  • JSValueJSContext强引用JSContext 又挂在 JSVirtualMachine 上。
  • 若在 堆上的 OC 对象(如某 ViewController 的 property)中直接强引用 JSValue,而该 JSValue 通过某种方式(例如被注入到 context 的全局对象)又引用回该 OC 对象,会形成 OC ↔ JS 的循环引用,导致 Context 与 OC 对象均无法释放 [1][2]。

7.2 JSManagedValue 的职责

JSManagedValueJSValue 的包装类,用于在「被 OC 堆对象持有」的场景下,以条件保留的方式引用 JS 值,并可与 JSVirtualMachineaddManagedReference:withOwner: / removeManagedReference:withOwner: 配合,让虚拟机在合适的时机断开或保留对 native 对象的引用,从而打破循环、避免 JSContext 无法释放 [1][2]。

7.3 使用要点(概念)

  • 当需要把 JSValue(或从 JS 传回的函数/对象)存为 OC 对象的成员变量时,应使用 JSManagedValue 包装,并以 owner 注册到 JSVirtualMachine;在 owner 析构或不再需要时调用 removeManagedReference:withOwner: [1][2]。
  • 仅临时在栈上使用 JSValue(如 evaluateScript 的返回值在方法内使用后不再持有)时,一般无需 JSManagedValue。

八、关键概念图示与流程

8.1 VM、Context、Value 关系

flowchart TB
  subgraph VM1[JSVirtualMachine 1]
    C1[JSContext 1]
    C2[JSContext 2]
  end
  subgraph VM2[JSVirtualMachine 2]
    C3[JSContext 3]
  end
  C1 --> V1[JSValue]
  C2 --> V2[JSValue]
  C1 -.->|可传值| C2
  C1 -.->|不可跨 VM| C3

同一 JSVirtualMachine 下多个 JSContext 可共享、传递 JSValue;不同 VM 之间不能传递 JSValue [3]。

8.2 JavaScriptCore 引擎执行层级(概念)

源码经 Lexer → Parser 得到语法树并生成字节码后,由下至上的执行/编译层级可概括为:

flowchart LR
  A[源码] --> B[Lexer]
  B --> C[Parser / AST]
  C --> D[字节码]
  D --> E[LLInt 解释器]
  E --> F[Baseline JIT]
  F --> G[DFG JIT]
  G --> H[FTL JIT]
  • LLInt:低级解释器,低延迟启动。
  • Baseline JIT:首次 JIT,兼顾分析与回退。
  • DFG:基于数据流的优化 JIT。
  • FTL:更高优化层(历史上曾用 LLVM/B3 后端)[4][5]。

更多实现细节见 WebKit JavaScriptCore Wiki


九、应用场景与最佳实践

9.1 典型应用场景

场景 说明
Hybrid 应用 在 App 内执行 JS 脚本、调用原生能力(如弹窗、定位、支付),JavaScriptCore 提供 OC/Swift 与 JS 的双向桥接 [1][2]
React Native / 类 RN 方案 早期 RN 等方案在 iOS 上依赖 JSC 执行 JS bundle;JSC 提供 VM、Context、Value 等能力 [3]
JSPatch 等热修复 通过下发 JS 脚本并在 JSC 中执行,动态调用原生类与方法,实现热更新(需注意安全与审核政策)[3]
WKWebView 与 Web 页面 WKWebView 内部使用系统 WebKit,其 JS 引擎与 Safari 一致;独立使用 JSC 时无需 WebView 即可执行 JS [1][2]
规则引擎 / 脚本配置 将业务规则或配置写成 JS,由原生在 JSC 中执行并取结果,便于迭代与 A/B 测试

9.2 最佳实践要点

  • 线程:同一 VM 下多线程会串行等待;需并发执行 JS 时使用多个 JSVirtualMachine [3]。
  • 异常:设置 context.exceptionHandler,在 JS 抛错时记录或上报,避免静默失败 [3]。
  • 内存:在 OC 堆对象中持有 JS 值时使用 JSManagedValue + add/removeManagedReference,避免循环引用 [1][2]。
  • 安全:执行来自网络或不可信来源的 JS 时,需做沙箱与权限控制;避免将敏感 API 无限制暴露给 JS [3]。

十、伪代码与算法说明

10.1 执行脚本并取返回值(概念)

function evaluateScript(script: String) -> JSValue:
  parse script -> AST
  generate bytecode from AST
  execute bytecode (via LLInt or JIT tier)
  return last expression value as JSValue

10.2 将 Native 对象注入 Context(概念)

function setObject(object: Any, forKey key: String):
  if object is Block or conforms to JSExport:
    create JS wrapper (function or object with exported properties/methods)
  else:
    create generic wrapper preserving native type hierarchy
  set wrapper on context.globalObject[key]

10.3 JS 调用 Native Block 时(概念)

JavaScript 侧,调用通过 context[@"key"] 注入的 Block,与调用普通函数一致:

// 假设 Native 已注入:context["makeColor"] = ^(NSDictionary *rgb) { ... }
var color = makeColor({ red: 12, green: 23, blue: 67 });

底层流程(伪代码):

当 JS 调用 context 中注册的 Block 时:
  1. JSC 将 JS 参数按类型转换为 OC 对象(NSNumber/NSString/NSDictionary/NSArray 等)
  2. 调用 Block,传入转换后的参数
  3. 将 Block 返回值按类型转换为 JSValue 并返回给 JS

参考文献

[1] Apple. JavaScriptCore Framework. iOS / macOS Developer Documentation.
[2] 掘金 / 博客. iOS 与 JS 交互开发知识总结JavaScriptCore 初探 等.
[3] 本文原稿与常见 JSC 教程(JSVirtualMachine、JSContext、JSValue、并发与内存).
[4] WebKit. Introducing the WebKit FTL JIT. webkit.org/blog/3362/i…
[5] WebKit. JavaScriptCore - Deep Dive. docs.webkit.org/Deep%20Dive…
[6] trac.webkit.org. JavaScriptCore. trac.webkit.org/wiki/JavaSc…
[7] 美团技术团队. 深入理解 JSCore. blog.csdn.net/MeituanTech…

01-HarmonyOS底层原理|HarmonyOS的各个渲染框架和HarmonyOS图层渲染原理

HarmonyOS 底层原理:各个渲染框架与图层渲染原理

前言


概述

本文主要对 HarmonyOS 页面渲染原理 展开讨论。在讨论本文主题之前,我们需要先了解 HarmonyOS,然后进行一定的知识铺垫,先带大家简单回顾一下 计算机图形渲染原理。若您不想了解 HarmonyOS 的系统背景,可以从第二节「铺垫知识」开始。若您也有一定的 计算机图形学基础,可以忽略前期的知识准备,直接从本文的第三节开始阅读。

本文总共有以下几个章节:


📋 目录


一、HarmonyOS 简述

HarmonyOS 系统由中国的华为公司发行。它作为首款完全自主国产智能移动终端搭载系统,自诞生以来就备受关注,至今为止已经迭代了 3+ 代。国内很多电子发烧友都想进一步了解 HarmonyOS,在此过程中也提出了一些疑问:HarmonyOS 是否是 Android 系统的套皮?(换言之就是怀疑:HarmonyOS 是否是以安卓操作系统为底座,修改了上层的 UI 图形显示界面的系统)。华为公司在多次系统发布会也对 HarmonyOS 的定位、它的设计等各方面做出了介绍。在本文中我们首先从以下几个方面来认识发烧友们的质疑是否可靠:

  • 系统定位
  • 内核对比
  • 运行速度

鸿蒙(HarmonyOS):一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上,HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备,提供全场景(移动办公、运动健康、社交通信、媒体娱乐等)业务能力。

1.1 鸿蒙系统和 Android 系统的定位不同

华为官方对于 HarmonyOS 系统定位的介绍视频 我们可以得知:

Android 和 HarmonyOS 两款产品的研发初衷完全不一样,根本就不在同一个赛道上。安卓系统面向的是手机端,而鸿蒙系统面向的是这些年比较新的概念物联网,致力于利用其 5G 世界领先的技术,优先布局和打造一个超级终端、万物互联的生态。

安卓(Android): 是一种基于 Linux 内核(不包含 GNU 组件)的自由及开放源代码的操作系统,主要使用于移动设备,如智能手机和平板电脑,由美国 Google 公司和开放手机联盟领导及开发。

鸿蒙(HarmonyOS): 是一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上,HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备,提供全场景(移动办公、运动健康、社交通信、媒体娱乐等)业务能力。

1.2 鸿蒙系统和 Android 系统的内核不同

安卓(Android): 基于 Linux 的宏内核设计。宏内核包含了操作系统绝大多数的功能和模块,而且这些功能和模块都具有最高的权限,只要一个模块出错,整个系统就会崩溃,这也是安卓系统容易崩溃的原因。

  • 系统开发难度低。

鸿蒙(HarmonyOS): 基于微内核设计。微内核仅包括了操作系统必要的功能模块(任务管理、内存分配等),处在核心地位具有最高权限;其他模块不具有最高权限,也就是说其他模块出现问题,对于整个系统的运行是没有阻碍的。

  • 微内核稳定性很高。
  • 鸿蒙系统包含了两个内核:
    • Linux 内核
    • LiteOS 内核
  • 内核子系统:HarmonyOS 采用多内核设计,支持针对不同资源受限设备选用适合的 OS 内核。
    • 内核抽象层(KAL,Kernel Abstract Layer) 通过屏蔽多内核差异,对上层提供基础的内核能力,包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
  • 驱动子系统:硬件驱动框架(HDF)是 HarmonyOS 硬件生态开放的基础,提供统一外设访问能力和驱动开发、管理框架。

关于鸿蒙系统内核的介绍,我们也可以通过 官方视频 的介绍来进一步认识。

HarmonyOS 底层内核空间 以 【Linux Kernel】作为基石。上层用户空间由 Native 系统库虚拟机运行环境框架层 组成,通过系统调用(Syscall) 连通系统的 内核空间用户空间

对于用户空间主要采用 C++ 和 Java 代码编写,通过 JNI 技术 打通用户空间的 Java 层Native 层(C++/C),从而连通整个系统。

我们今天就以 HarmonyOS 渲染原理为主题,对 HarmonyOS 系统的渲染框架和渲染流水线展开讨论,以为后期在项目实施过程中做技术选型做知识储备!!那就让我们进入今天的正题吧!!!

1.3 鸿蒙系统和 Android 系统的运行速度对比

安卓(Android): 基于 Java 语言编码。Java 语言有个很大的缺点是其不能直接与底层操作系统通信,需要通过虚拟机(JVM)充当中间转换的角色,这是每一个 Java 开发人员都知道的知识点。虽然 Java 语言由于虚拟机的优化、编译器的优化、热点代码等技术使得其越来越快,但是无法直接与操作系统互相通信一直影响着其性能的突破。

鸿蒙(HarmonyOS): 鸿蒙的开发也可以采用 Java 语言,官方也推荐使用 Java 语言开发,但是 华为针对 Java 语言的这种特性,研发了方舟编译器,通过方舟编译器编译的软件可以直接与底层操作系统通信,方舟编译器在这一层面做到了取代虚拟机。通过方舟编译器转换为操作系统能够读懂的机器语言,这样就可以跳过虚拟机解释这一步骤,当然这是肯定对机器的内存要求比较高,应该也存在启动后无法继续优化等问题。

1.4 方舟编译器简单介绍

华为方舟编译器作为一款全新的编译器可以显著提高手机的运行速度,它 不采用现有编译器边解释边执行的模式,而是将这种动态编译改为静态编译,可以做到全程执行机器码,进而高效运行程序,大大缩短程序响应时间

方舟编译器的优势

  • 多语言联合:将同一应用中的不同语言代码联合编译、联合优化,消除语言间的性能「鸿沟」,降低开发者的优化成本
  • 轻量运行时:通过编译器的语言实现能力和优化能力增强,应用运行时的开销更小
  • 软硬件协同:编译器与芯片实现软硬件协同优化,充分发挥硬件能效,应用体验更佳
  • 多平台支持:支持面向多样化的终端设备平台进行编译和运行,根据设备特征提供便捷的开发与部署策略,提高开发效率


二、铺垫知识

HarmonyOS 系统的图形渲染原理其实在核心部分都是和 计算机图形学 的计算机图形渲染原理一样的。所以我们在了解 HarmonyOS 的 视图系统 和其 2D、3D 渲染框架渲染流水线 之前,我们需要进入笔者的这篇文章:计算机图形渲染原理 进行一定的知识准备。

链接 附带的文章中,我们可以了解到「智能硬件 的 CPU、GPU 的设计理念以及两者之间的性能差异」、「计算机图形渲染芯片 GPU 的诞生史」、「围绕 GPU 工作的 3D 图形渲染库(OpenGL、DirectX 等)、图形学相关的专业术语和 OpenGL 工作的渲染流水线」、「屏幕成像的电子束 CRT 扫描原理」、「屏幕成像原理」等诸多相关的核心要点。

您若是不想关注 CPU、GPU,直接了解移动设备的屏幕成像原理,也可以阅读笔者这一份专门为移动而写的简约版:移动终端屏幕成像与卡顿
在这篇文章中,我们可以分别从两个维度去关注:第一个就是 系统成像遇到的 Bug 问题,第二个就是 解决问题的解决方案。几个要点可以简单归纳为:

  • 问题:「屏幕撕裂 Screen Tearing」、「掉帧 Jank」、视图成像切换衔接失误导致的画面空白
  • 解决方案:「Vsync」、「Double Buffering」、「Triple Buffering」

总结:我们这里主要关注屏幕成像的整个渲染流水线,以便于我们后面对 HarmonyOS 的图像渲染原理展开讨论:

① 获取图层渲染数据 → ② GPU 加工成像素数据 → ③ 帧缓冲器(存储像素信息)→ ④ 视频控制器读取缓存 → ⑤ 数模转换、显示器显示

我们今天的主题就是主要关注第一个环节。入手点分为几个:

  • HarmonyOS 系统的**视图层(Layer)视图窗口(Window)**以及系统中的各个图形渲染框架(2D/3D)
  • HarmonyOS 系统的渲染流水线
  • HarmonyOS 系统的事件机制

下面用一张流程图概括从「应用绘制」到「屏幕显示」的通用流水线(与第二节铺垫知识对应):

flowchart LR
  subgraph 应用与框架
    A[应用/ArkUI 绘制]
    B[图层数据]
  end
  subgraph 系统与硬件
    C[GPU 光栅化]
    D[帧缓冲]
    E[视频控制器]
    F[显示器]
  end
  A --> B --> C --> D --> E --> F

三、HarmonyOS 的视图层和视图窗口

本节在不删减原有结构的前提下,对 HarmonyOS 的 窗口(Window)窗口层级视图层(Layer)Surface 等概念做系统性补充,便于与后文「渲染框架与流水线」衔接。相关表述综合自华为/开放原子官方文档、开发者社区与项目实践 [1][2][3][4]。

3.1 窗口子系统与窗口类型

HarmonyOS 的窗口模块(窗口子系统)负责在同一块物理屏幕上提供多个应用界面的显示与交互,其核心职责包括 [2]:

  • 提供应用系统界面的窗口对象
  • 组织不同窗口的显示关系,维护窗口的叠加层次位置属性
  • 提供窗口动效交互
  • 指导输入事件分发

窗口在类型上可分为两大类 [2]:

类型 说明
系统窗口 完成系统特定功能的窗口,如音量条、壁纸、通知栏、状态栏、导航栏等
应用窗口 应用主窗口:显示应用主界面,在任务管理界面中显示;应用子窗口:弹窗、悬浮窗等辅助窗口,生命周期跟随主窗口

应用主窗口与子窗口在尺寸上有约束:宽度范围 [320, 2560] vp,高度范围 [240, 2560] vp(具体以当前版本文档为准)[1]。

3.2 窗口层级与 WindowType

窗口的前后叠加关系WindowTypepriority(优先级) 共同决定 [4]:

  • BelowApp:底层,如桌面、壁纸等,priority = 0
  • App:中间层,应用主窗口(priority = 0)、应用子窗口(priority = 1)等
  • AboveApp:上层,如锁屏(priority = 114)、状态栏(priority = 110)等

同一 WindowType 下,priority 值越大,层级越高,越靠近用户 [4]。窗口模式(WindowMode)可配置为全屏、分屏主/副、悬浮等(如 WINDOW_MODE_FULLSCREENWINDOW_MODE_FLOATING 等)[4]。

flowchart TB
  subgraph AboveApp
    L[锁屏 priority=114]
    S[状态栏 priority=110]
  end
  subgraph App
    M[应用主窗口 priority=0]
    C[应用子窗口 priority=1]
  end
  subgraph BelowApp
    D[桌面/壁纸 priority=0]
  end
  L --> S --> M --> C --> D

系统侧由 WindowManagerService(WMS) 负责窗口的创建、销毁、布局、层级与焦点管理;DisplayManagerService(DMS) 管理 Display 与 Screen 的映射关系。Screen 表示物理屏幕,Display 表示逻辑屏幕,Window 依附于某个 Display [4]。

3.3 UIAbility 与 WindowStage

在应用开发模型中,窗口生命周期与 UIAbilityWindowStage 绑定 [3][5]:

  • UIAbility 是应用组件的一种,代表一个「界面能力」的抽象;一个 UIAbility 可拥有一个主窗口及若干子窗口。
  • WindowStage 在 UIAbility 创建时被建立,负责该 Ability 下窗口的创建与生命周期维护
  • onWindowStageCreate 回调中,应用加载 UI 界面(如 ArkUI 页面),主窗口在此阶段被创建并展示。

因此,从「界面」到「窗口」的链条为:UIAbility → WindowStage → Window(s);渲染框架则基于这些窗口提供的 Surface 进行绘制与合成。

3.4 视图层(Layer)与 Surface

在图形栈中,窗口对应可绘制的表面(Surface)。应用或 ArkUI 将 UI 内容绘制到与窗口绑定的 Surface 上,形成图层(Layer)数据;多个 Layer 由系统的 GPU 合成器(如 Rosen / Render Service) 按 z-order 合成为最终一帧,再送入帧缓冲,经 VSync显示控制器输出到屏幕 [1][2][6]。

  • Surface:可绘制的缓冲区抽象,对应窗口的绘图目标;应用侧通过 Canvas、Skia/OpenGL 等接口向 Surface 提交绘制命令或像素。
  • Layer:可理解为某一层绘制结果(或某棵视图树对应的渲染结果);多层叠加后经合成器合成为一帧。

OpenHarmony 文档与社区资料中常出现 RSSurfaceRSWindow 等接口,用于创建和管理可绘制的表面与窗口,与上述概念对应 [6]。


四、HarmonyOS 的各个渲染框架和渲染流水线

本节系统性地介绍 HarmonyOS / OpenHarmony 的图形栈分层ArkUI 声明式框架2D/3D 渲染框架Measure-Layout-Draw 渲染管线以及 Rosen(Render Service)合成,并给出从应用层到屏幕的完整流水线概览。内容综合自华为/开放原子官方文档、InfoQ 等技术文章及开发者社区 [1][2][6][7][8][9]。

4.1 图形栈整体架构

OpenHarmony 采用自研的图形栈,按分层抽象可分为 [6][7]:

层次 内容说明
接口层 向应用提供 NDK 等能力,包括 WebGL、Native Canvas、OpenGL 指令级支持等
框架层 Render Service(RS)、Drawing、Animation、Effect、显示与内存管理等
引擎层 2D 图形库、3D 图形引擎等

华为开发者官网将 ArkGraphics 2D 作为 HarmonyOS 上二维图形绘制、渲染与显示的核心模块,采用 API 层 — 服务层 — 硬件适配层 的三层架构,支持 ArkTS 与 C/C++ 开发 [1]。整体上,应用 UI 框架(如 ArkUI) 调用 2D/3D 图形 API,由 RS 进行合成与 VSync 调度,最终输出到屏幕。

flowchart TB
  subgraph 应用层
    ArkUI[ArkUI / ArkUI JS]
  end
  subgraph 图形栈
    API[API 层 / ArkGraphics 2D 等]
    RS[Render Service / Rosen]
    Draw[Drawing / 2D 引擎]
    Eng[3D 引擎]
  end
  subgraph 硬件
    GPU[GPU]
    Disp[显示控制器]
  end
  ArkUI --> API --> Draw
  ArkUI --> Eng
  Draw --> RS
  Eng --> RS
  RS --> GPU --> Disp

4.2 ArkUI 框架与声明式渲染

ArkUI 是 HarmonyOS 上主推的 声明式 UI 框架,面向 1+8+N 多设备,支持 ArkUI JS(类 Web/小程序范式)与 ArkUI eTS(声明式 + 方舟编译器)两套开发范式 [7][8]。从渲染角度看,ArkUI 可概括为 [7][8][9]:

  • 声明层:通过 build() 描述 UI 结构,用 @State / @Prop / @Link 等装饰器管理状态,遵循 UI = f(State) 的声明式范式。
  • 节点层:将声明式描述转化为内部可计算的节点树(Component 树、Alignment 树、Render 树等),支持细粒度更新,避免整树重算。
  • 渲染管线层:在 VSync 驱动下,经历 Measure → Layout → Draw,最终通过统一的渲染引擎(如 Skia 或华为自研引擎)将内容绘制到 Surface [7][8]。

ArkUI 采用前后端分离:前端为声明式 DSL(eTS 或类 Web),后端为 C++ 编写的声明式后端引擎,包含布局、动画、多态组件、自绘制渲染管线等;底层使用统一的框架层渲染引擎(当前文档多提及 Skia,华为亦在自研替代方案)[7][8]。

4.3 2D 与 3D 渲染框架

HarmonyOS 在应用层可归纳为两类典型渲染路线 [1][9]:

方式 适用场景 说明
ArkUI + Canvas / 内置组件 常规 UI、轻量 2D 动效、小游戏 使用 ArkGraphics 2D、Canvas 等 API,由框架完成 Measure-Layout-Draw
XComponent + Native(OpenGL ES) 复杂 3D、高性能图形、游戏 通过 XComponent 获得 Native 层 Surface,直接调用 OpenGL ES,细粒度控制

ArkGraphics 2D 提供画布操作、图元绘制(几何、图片、文本)、文本模块、可变帧率、Vsync、Window 管理等能力 [1]。3D 渲染则依赖系统图形子系统(含 Rosen/RS)提供的 Native 缓冲区与 OpenGL ES/Vulkan 等接口,实现完整渲染管线控制 [9]。

4.4 渲染管线:Measure、Layout、Draw

ArkUI 的 UI 渲染管线与常见移动端框架一致,分为三个阶段 [8][9]:

  1. Measure(测量):系统询问每个组件的尺寸需求,父容器根据子元素约束与自身约束计算每个节点的宽高。
  2. Layout(布局):根据测量结果与布局规则(如 Column、Row、Flex)确定每个组件在父容器中的位置(x, y)。
  3. Draw(绘制):将组件的几何、图片、文本等绘制到 Surface 对应的缓冲区,最终由 RS 合成并送显。

伪代码(概念)

function renderFrame():
  for each node in renderTree (from root to leaf):
    node.measure()   // 测量宽高
  for each node in renderTree (from root to leaf):
    node.layout()    // 确定 x, y
  for each node in renderTree (in draw order):
    node.draw()      // 绘制到 Surface
  submitToRenderService()

自定义 NDK 组件可通过 onMeasure / onLayout / onDraw 等回调接入该管线;测量与布局相关的 API(如 measureNodelayoutNodesetMeasuredSizesetLayoutPosition)需在对应的 ARKUI_NODE_CUSTOM_EVENT_ON_MEASUREARKUI_NODE_CUSTOM_EVENT_ON_LAYOUT 回调中使用 [9]。

flowchart LR
  M[Measure 测量]
  L[Layout 布局]
  D[Draw 绘制]
  RS[Render Service]
  M --> L --> D --> RS

4.5 Rosen / Render Service 与合成

Rosen 是 OpenHarmony 的 GPU 合成与显示服务,在架构上类似 Android 的 SurfaceFlinger,负责 [6][7]:

  • 管理 RSSurfaceRSWindow 等可绘制表面与窗口;
  • 接收各应用/窗口提交的图层数据,按 z-order 与可见性进行 GPU 合成
  • DisplayManager 配合,分发 VSync 信号,实现帧同步与双缓冲/三缓冲,减少撕裂与掉帧。

可通过系统调试命令(如 hidumper -s RenderService)查看 RS 状态、屏幕、节点、FPS 等信息 [7]。图层数据经 RS 合成后写入帧缓冲,再由视频控制器读取并输出到物理屏幕,与第二节「铺垫知识」中的流水线一致。

4.6 从应用层到屏幕的完整流水线

将上述各节串联,从「应用 UI」到「屏幕显示」的完整流水线可概括为:

  1. 应用层:ArkUI(或 Native UI)根据状态构建/更新 Component 树 → Render 树,在 VSync 触发下执行 Measure → Layout → Draw
  2. 绘制输出:Draw 阶段将内容绘制到各窗口对应的 Surface,生成**图层(Layer)**缓冲区。
  3. 合成Render Service(Rosen) 收集所有窗口的 Layer,按层级与区域进行 GPU 合成,输出一帧到帧缓冲
  4. 显示视频控制器VSync 同步下读取帧缓冲,经数模转换输出到显示器

整体与第二节给出的「① 获取图层渲染数据 → ② GPU 加工 → ③ 帧缓冲 → ④ 视频控制器 → ⑤ 显示器」一致,HarmonyOS 在「①」环节通过 ArkUI、ArkGraphics 2D、Rosen 等框架与服务实现了从视图到图层的完整链路。

flowchart TB
  subgraph 应用
    A[ArkUI build/update]
    B[Measure / Layout / Draw]
  end
  subgraph 系统图形
    C[Surface / Layer]
    D[Render Service 合成]
    E[帧缓冲]
  end
  subgraph 硬件
    F[VSync]
    G[显示器]
  end
  A --> B --> C --> D --> E --> F --> G

五、总结

通过前面的介绍,我们基本知道了:

  • HarmonyOS 的定位是面向万物互联的分布式操作系统,与 Android 在定位、内核(微内核 vs 宏内核)、运行速度(方舟编译器) 等方面存在差异;底层以 Linux 内核为基石,用户空间通过 JNI 等连通 Java 与 Native。
  • 铺垫知识 部分强调了计算机图形渲染原理与移动端屏幕成像(Vsync、多缓冲)的通用流水线,本文主题聚焦该流水线的第一个环节:视图层、窗口与渲染框架。
  • 视图层与窗口:HarmonyOS 通过窗口子系统(WMS、DMS)管理系统窗口应用窗口(主窗口/子窗口),窗口层级由 WindowType + priority 决定;UIAbility / WindowStage 负责应用侧窗口生命周期;Surface / Layer 是绘制与合成的载体。
  • 渲染框架与流水线:图形栈分为接口层、框架层(含 RS)、引擎层ArkUI 提供声明式 UI 与 Measure–Layout–Draw 管线;2DArkGraphics 2D 为主,3D 通过 XComponent + OpenGL ES 等实现;Rosen(Render Service) 负责图层合成与 VSync,最终与帧缓冲、显示控制器一起完成从应用到屏幕的完整成像链路。

本篇文章,没有解决的问题如下:

  • HarmonyOS 系统事件机制(输入事件从硬件到应用的分发路径、与窗口/焦点的关系)的详细梳理;
  • ArkUI 与 Flutter / SwiftUI 在渲染管线与性能上的对比分析;
  • 更多性能调优卡顿排查在 HarmonyOS 上的具体工具与步骤(如 RS 的 hidumper、ArkUI 的布局与绘制耗时分析)。
  • ……

参考

  • 见文末 参考文献

六、文章推荐


相关阅读(共计 14 篇文章)

iOS 相关专题
webApp 相关专题
跨平台开发方案相关专题
阶段性总结:Native、WebApp、跨平台开发三种方案性能比较
Android、HarmonyOS 页面渲染专题
小程序页面渲染专题
总结

参考文献

[1] 华为开发者. 图形绘制概览 / ArkGraphics 2D(HarmonyOS 文档). developer.huawei.com/consumer/cn…
[2] HarmonyOS 应用窗口管理(Stage 模型)等. 博客园 / 华为云社区.
[3] 深入理解 HarmonyOS UIAbility:生命周期、WindowStage 与启动模式. 华为云社区. bbs.huaweicloud.com/blogs/41689…
[4] OpenHarmony 窗口子系统基本概念与流程分析. 掘金. juejin.cn/post/751099…
[5] 深入解析 HarmonyOS 5 UIAbility 组件:从核心架构到实战应用. CSDN.
[6] 深入解析 OpenHarmony:图层渲染与合成 SurfaceBuffer 实践指南. 百度云. cloud.baidu.com/article/327…
[7] OpenHarmony 实战开发——图形框架解析. 腾讯云开发者. cloud.tencent.com/developer/a…
[8] InfoQ. HarmonyOS ArkUI 框架的实现原理和落地实践. www.infoq.cn/article/tsa…
[9] HarmonyOS 开发者社区 / CSDN. ArkUI 渲染管线、Measure/Layout/Draw、自定义组件 NDK 等.
[10] 掘金. 鸿蒙 HarmonyOS 实战 - 窗口管理. juejin.cn/post/741784…

07-Debug调试@iOS-其它调试方式指导SOP补充

本文在「网络/蓝牙/UI/调试器/崩溃」等专题之外,对 LLDB/GDB 常用操作、Xcode 调试技巧、Chisel/Reveal/FLEX 等其它 iOS 调试方式做 SOP 与要点补充,便于日常查阅与落地使用。


📋 目录


一、LLDB 与 GDB

LLDB 是 Xcode 默认调试器;与 GDB 的命令对应关系可参考:lldb 与 gdb 命令对比

1.1 常用 Debug 快捷键

功能 命令
暂停/继续 Cmd + Ctrl + Y
断点失效/生效 Cmd + Y
控制台显示/隐藏 Cmd + Shift + Y
光标切换到控制台 Cmd + Shift + C
清空控制台 Cmd + K
Step Over F6
Step Into F7
Step Out F8

1.2 技巧一:格式化输出数据

1、封装 log 函数

// Swift 版
func DLog<T>(message: T, file: String = #file, method: String = #function, line: Int = #line) {
    #if DEBUG
        print("\((file as NSString).lastPathComponent) : \(line), \(method)  \(message)")
    #endif
}
// OC 版
#ifdef DEBUG
#define DLog(fmt, ...) NSLog((@"<%s : %d> %s  " fmt), [[[NSString stringWithUTF8String:__FILE__] lastPathComponent] UTF8String], __LINE__, __PRETTY_FUNCTION__, ##__VA_ARGS__);
#else
#define DLog(...)
#endif

2、代替 NSLog,打印对象的内部属性

在 LLDB 中可使用 po(print object)打印对象描述;若需更细粒度,可结合 exprframe variable。Xcode 控制台在断点停下时,对变量使用「右键 → Print Description of …」或输入 po 变量名 即可查看内部属性。

1.3 技巧二:条件断点(condition)

设置断点后,可为断点添加触发条件,只有条件为真时才暂停,便于在循环或高频调用处精确定位。

注意:在条件表达式中调用 Objective-C 方法时,需强转返回值类型,否则可能报错:

// 正确
(BOOL)[pId isEqualToString:@"short-videopage"]

// 报错:error: no known method '-isEqualToString:'; cast the message send to the method's return type
[pId isEqualToString:@"short-videopage"]

1.4 技巧三:运行中修改变量的值(expr & call)

在断点处可通过 Expression (expr)Debug → Debug Workflow → Evaluate Expression 修改变量或调用方法,无需重新运行。例如:调试登录时临时改 token/登录状态,或调试 UI 时改某控件的颜色、frame。

在调试登录相关的 bug 时,非常方便,不用担心经常输密码,还输错的尴尬

调试 UI,改变指定控件的颜色

1.5 技巧四:符号断点(Add Symbolic Breakpoint)

通过 Add Symbolic Breakpoint 可对符号名(函数/方法)下断点,无需指定具体文件行号。适合在陌生项目中快速了解执行路径,例如对所有 viewDidLoad 下断点,观察页面加载顺序。

Symbol 填写格式

语言/风格 写法说明
C 语言 methodName 只需写函数名,不用写后面的 ()
Objective-C [ClassName methodName],ClassName 为类名,methodName 为方法名(不区分类方法/实例方法)
Swift ClassName.methodName
  • Module:模块筛选,避免不同库中同名方法/函数冲突。
  • Condition:触发条件。可写表达式(如第一个参数不能为 nil);参数可用 $arg3$arg4 等表示(如 $arg3 == nil)。也可调用返回 BOOL 的类方法。
    样例:找出给 [UIImage imageNamed:] 传 nil 的调用。Symbol 设为 [UIImage imageNamed:],Condition 设为 $arg3 == nil,运行中一旦传 nil 就会触发断点。

如何查某个函数的符号:在该函数处打普通断点,运行到断点后,在堆栈信息中查看对应帧的显示格式,即可得到 Symbol 应填的格式。

1.6 技巧五:全局异常断点(Add Exception Breakpoint)

添加 Exception Breakpoint 后,当发生 Objective-C / C++ 异常(或可选 Swift 异常)时,调试器会在抛出处暂停,便于快速定位未捕获异常。

1.7 技巧六:查看整体 UI 层级结构(debug view hierarchy)

Xcode 菜单 Debug → View Debugging → Capture View Hierarchy 可捕获当前界面的视图层级并做 3D 展示与选择。若机器配置较低、卡顿明显,可改用 Chiselpviews 等命令在控制台输出层级文本(参见本文第二节)。

1.8 技巧七:开启僵尸模式(EXC_BAD_ACCESS)

EXC_BAD_ACCESS 常表示向已释放对象发消息。开启 Zombie Objects 后,这类访问会被系统标记,Xcode 可据此在诊断中给出对象类型与释放相关信息,便于定位野指针。

开启步骤Edit Scheme → Run → Diagnostics,勾选 Enable Zombie Objects

1.9 技巧八:查看 frame 的值

在 LLDB 中打印 UIViewframe 等属性时,若直接 p self.view.frame 可能报「property 'frame' not found」。可先 导入 UIKit 模块,再打印:

(lldb) p self.view.frame
error: property 'frame' not found on object of type 'UIView *'
error: 1 errors parsing expression
(lldb) e @import UIKit
(lldb) p self.view.frame
(CGRect) $0 = (origin = (x = 0, y = 0), size = (width = 375, height = 667))

或使用强制转换:

print (CGRect)[view frame]
(CGRect) $1 = (origin = (x = 0, y = 0), size = (width = 200, height = 100))

1.10 技巧九:监听所有点击事件(UIControl、Touch、Gesture)

方法:覆写 UIApplication

通过自定义 UIApplication 子类并重写 sendEvent:,可在事件派发前统一拦截,用于统计、调试或行为分析。

.h 文件:

#import <UIKit/UIKit.h>

NS_ASSUME_NONNULL_BEGIN

@interface CustomApplication : UIApplication

@end

NS_ASSUME_NONNULL_END

.m 文件:

#import "CustomApplication.h"

@implementation CustomApplication
- (void)sendEvent:(UIEvent *)event {
    [super sendEvent:event];
}
@end

main.m 文件:

#import <UIKit/UIKit.h>
#import "AppDelegate.h"
#import "CustomApplication.h"

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc,
                                 argv,
                                 NSStringFromClass([CustomApplication class]),
                                 NSStringFromClass([AppDelegate class]));
    }
}

方法执行与事件次数

一次事件可能会执行三次函数:-(void)sendEvent:(UIEvent *)event,三次的 force 有区别


一次事件可能会执行两次函数:-(void)sendEvent:(UIEvent *)event,两次的 force 没区别


响应者链条

1、若是 UIControl 事件,继承自 UIResponder 的控件(如 UIButton)消息传递链(倒序)如下图所示


2、若是 UIGestureRecognizer 手势事件,继承自 UIResponder 的控件(如 UIView)消息传递链(倒序)如下图所示


3、若 UIControl 和 UIGestureRecognizer 同时存在,优先级关系如下图所示


二、其它工具:Chisel

Chisel 是 Facebook(Meta)开源的 LLDB 命令集合,在 Xcode 调试时提供如 pviewspvcfvvisualizebmessage 等高层命令,便于查看视图层级、查找视图、可视化图片、对方法下符号断点等。

安装

具体参考官方 README

使用 Homebrew 安装:

brew update
brew install chisel

安装完成后,将下面一行加入 ~/.lldbinit,Xcode 启动时才会加载 Chisel:

# Intel Mac 常见路径
command script import /usr/local/opt/chisel/libexec/fbchisellldb.py

# Apple Silicon (M1/M2/M3) 常见路径
# command script import /opt/homebrew/opt/chisel/libexec/fbchisellldb.py

若你当前使用的是旧版路径 fblldb.py,且能正常加载,可保留;新版本仓库中入口一般为 fbchisellldb.py,以官方 README 为准。

常用命令

在 LLDB 中查看完整命令列表与说明:

(lldb) help

更完整的 Chisel 命令说明与原理见本目录:05-Debug调试@调试器-Chisel LLDB调试工具:从原理到实践

参考Chisel - LLDB 命令插件,让调试更 Easy


三、其它工具:Reveal

RevealiOS 界面调试 的桌面应用,可连接模拟器或真机,实时查看与修改视图层级、约束、属性等,使用上往往比 Xcode 自带的 View Debugging 更流畅、功能更丰富。软件为商业收费,提供试用(如 30 天),试用期过后需购买授权。

集成方式约有多种(Framework、CocoaPods、Swift Package 等),详情见 Reveal 官网集成指南


四、其它工具:FLEX

FLEX 是 Flipboard 开源的 应用内调试工具集,以第三方库形式集成到 App 中。运行时通过调用 [[FLEXManager sharedManager] showExplorer]; 即可调出调试工具栏,无需连接 Mac,适合真机或脱机场景。

主要功能包括

  • 查看、修改 views
  • 查看任意对象的属性
  • 动态修改属性
  • 动态调用实例方法与类方法
  • 查看网络请求过程
  • 添加模拟的键盘快捷键
  • 查看系统日志
  • 从堆中获取任意对象
  • 查看沙盒中的文件
  • 查看文件系统中的 SQLite / Realm 数据库
  • 在模拟器中触发 3D Touch
  • 查看应用中所有的类
  • 快速获取常用对象(如 [UIApplication sharedApplication]、App Delegate、key window 的 root view controller 等)
  • 动态查看 NSUserDefaults 中的值

参考文献

06-Debug调试@崩溃-iOS崩溃日志分析与反解(符号化):从原理到实践

📋 目录


一、概述与历史演进

1.1 什么是崩溃日志与符号化

当 iOS/macOS 应用因未捕获异常、非法内存访问、系统终止等原因退出时,操作系统会生成一份崩溃报告(crash report),记录进程终止时的状态:异常类型、终止原因、各线程的调用栈(backtrace)、已加载的二进制镜像(binary images)等 [1][2]。其中调用栈以内存地址形式呈现符号化(symbolication) 即把这些地址替换为可读的函数名与源码行号,使开发者能定位到具体代码位置 [2][3]。

  • 未符号化:栈帧显示为 0x1022cbfa80x1022c0000 + 49064 等,难以直接对应源码。
  • 已符号化:栈帧显示为 Line.updateRectForExistingPoint(_:) (in TouchCanvas) + 656ViewController.touchesEstimatedPropertiesUpdated(_:) (in TouchCanvas) + 304,可直接对应到工程中的类与方法 [2]。

符号化依赖与崩溃时运行二进制一一对应的 dSYM(Debug Symbol)文件及正确的加载地址(load address);只有 Build UUID 一致 的二进制与 dSYM 才能正确反解 [3][4]。

1.2 历史与格式演进

时期/变化 说明
传统 .crash 文本格式 早期至 iOS 14,崩溃报告多为纯文本:Incident IdentifierProcessException TypeThread 0 CrashedBinary Images 等字段,便于人工阅读与 grep [1][5]
iOS 15 / macOS 12 起 .ips 系统改为将崩溃数据存为 JSON,文件扩展名为 .ips;首行为 IPS 元数据对象,其余为崩溃报告数据对象。Console 等工具将 JSON 转成可读展示 [6][7]
Xcode Organizer 与自动符号化 从 App Store / TestFlight 收集的崩溃若在上传时包含符号,Xcode 的 Crashes 组织器可自动符号化;本地需自行提供 dSYM [2][8]
TN2151 与现行文档 Apple 早年的 Technical Note TN2151: Understanding and Analyzing Application Crash Reports 仍被广泛引用;现行说明已迁移至 Adding identifiable symbol names to a crash report 等官方文档 [2][3]

1.3 典型应用场景

  • 线上/TestFlight 崩溃定位:用户或测试反馈崩溃,从 Xcode Organizer 或邮件拿到 .ips/.crash,用对应版本的 dSYM 符号化后根据异常类型与栈顶帧排查。
  • 内存与稳定性问题:EXC_BAD_ACCESS、EXC_CRASH (SIGABRT)、Watchdog 等,结合 Exception Type、Termination Reason、Last Exception Backtrace 分析。
  • 审核或论坛反馈:App Review 或用户提供的 .txt/.crash,重命名为 .crash 后在 Xcode 中拖入 Device Logs 或使用 symbolicatecrash/atos 反解 [2][8]。
  • 多版本/多架构管理:为每个分发版本保留 Archive 与 dSYM,用 UUID 匹配正确 dSYM 进行符号化 [3][4]。

二、核心概念与崩溃报告结构

2.1 崩溃报告包含哪些信息

无论 .crash 文本还是 .ips 中的 JSON,一份完整崩溃报告通常包含 [1][6][9]:

部分 含义
Header / 元数据 进程名、Bundle ID、版本、设备/系统、时间、Incident Identifier、CrashReporter Key 等,用于区分环境与用户
Exception / 异常信息 异常类型(如 EXC_BAD_ACCESS、EXC_BREAKPOINT、EXC_CRASH)、信号(SIGSEGV、SIGABRT 等)、Exception Codes、Exception Message/Subtype
Termination 若进程被系统或其它进程终止,会包含 Termination Reason、namespace、code、indicator 等 [6]
Threads / 线程与栈 各线程的 backtrace(frames)、触发崩溃的线程标记、部分场景下的 threadState(寄存器)
Last Exception Backtrace 语言层异常(如 Objective-C/Swift 未捕获异常)时的专用栈,便于区分“谁抛出了异常” [9]
Binary Images 进程内已加载的二进制列表:名称、路径、UUID、加载地址(base)、大小;符号化与 atos 依赖此处的 UUID 与 base

2.2 栈帧(Frame)与 Backtrace

  • Frame 0:崩溃发生时正在执行的函数(或最内层调用)。
  • Frame 1, 2, …:调用者链,从内到外;通常从栈顶向下读,先看 Frame 0 与自家 App 的帧,再结合系统帧理解调用链 [9]。
  • 每帧包含:二进制名运行时地址(或 imageOffset + 对应 image 的 base)、符号化后为 函数名 + 偏移(+ 行号视工具而定) [6][7]。

三、崩溃报告格式:.crash 与 .ips

3.1 传统 .crash 文本格式(概要)

常见字段包括 [1][5]:

  • Incident IdentifierCrashReporter Key
  • ProcessIdentifierVersionCode Type
  • Exception TypeException CodesException SubtypeCrashed Thread
  • Thread 0 Crashed: 下列出各帧:序号 二进制名 地址 符号或 基址+偏移
  • Binary Images: 下列出各镜像的地址范围、名称、UUID(括号内,常为小写无连字符)

Xcode 的 Device Logs 要求文件扩展名为 .crash;若拿到的是 .txt 或其它扩展名,需重命名为 .crash 再拖入,才能正确触发符号化 [2]。

3.2 .ips:JSON 双对象结构(iOS 15+)

.ips 文件由两段 JSON 组成 [6][7]:

  1. 第一行IPS 元数据对象(单行一个 JSON 对象)。
  2. 其余内容崩溃报告数据对象(当 bug_type == "309" 时表示崩溃报告)。

解析逻辑要点(与官方示例一致)[6]:

  • 先读第一行解析 metadata。
  • metadata["bug_type"] == "309",再把剩余部分解析为 report。
  • 报告中的地址、码值等在 JSON 中多为十进制,需按需转为十六进制以便阅读或传给 atos [6][7]。

3.2.1 IPS 元数据常用键

Key 类型 说明
name String 进程可执行文件名
bug_type String 日志类型,309 表示崩溃报告;288 表示 stackshot 等 [6]
bundleID String Bundle 标识符
build_version String 构建版本号
incident_id String 报告唯一 ID
platform Number 平台(1=macOS, 2=iOS, 3=tvOS, 4=watchOS, 6=Mac Catalyst, 7=iOS Simulator 等)[6]
timestamp String 日志系统记录时间

3.2.2 崩溃报告对象常用键

Key 类型 说明
exception Dictionary typesignalcodessubtypemessage 等 [6]
faultingThread Number 崩溃线程在 threads 数组中的下标
threads Array 各线程对象,含 framesidqueuetriggeredthreadState 等 [6][7]
usedImages Array Binary images:basesizenamepathuuidarchsource 等 [7]
captureTimeprocLaunch String 崩溃时间、进程启动时间
lastExceptionBacktrace Array 语言层异常栈 [6]
bundleInfoosVersionstoreInfo Dictionary 包信息、系统版本、商店信息等

3.2.3 Frames 与 Binary Images(用于符号化)

  • frames 中每帧:imageIndex(对应 usedImages 下标)、imageOffset(相对该镜像的偏移)、symbolsymbolLocation(符号化后才有)[7]。
  • usedImages 中每项:base(加载地址)、uuid(Build UUID,用于匹配 dSYM)、namepatharch [7]。
    符号化时:运行时地址 = base + imageOffset;atos 需要 -l base 和该镜像对应的 dSYM [2][3]。

四、dSYM 与符号化原理

4.1 dSYM 是什么

dSYM(Debug Symbol File) 是 Xcode 生成的调试符号包,与编译出的二进制一一对应:包含函数名、行号、变量等 DWARF 调试信息,不随 App 分发,仅用于调试与崩溃反解 [3][4]。每个可执行体(主程序、Extension、Framework)各有自己的 dSYM;二进制与 dSYM 通过 Build UUID 绑定,只有 UUID 完全一致才能正确符号化 [3][4]。

4.2 生成与归档 dSYM

在 Xcode 中 [4]:

  • Build Settings → Debug Information Format 设为 DWARF with dSYM File(Release 与需分析崩溃的构建建议一致)。
  • Generate Debug Symbols 建议保持 YES

归档(Archive)时,Xcode 会把该次构建的所有二进制与 dSYM 收进 .xcarchive;上传 App Store/TestFlight 时可勾选上传符号,便于在 Crashes 组织器中自动符号化 [2][4]。必须为每个对外分发的版本保留对应 Archive,否则无法为该版本崩溃找到匹配 dSYM [4]。

4.3 符号化的本质

  • 崩溃报告里记录的是运行时地址(或 image 的 base + offset)。
  • 编译器在生成二进制时,会把符号与地址的对应关系写入 dSYM(DWARF)。
  • 符号化工具(Xcode、symbolicatecrash、atos)根据 UUID 找到对应 dSYM,再根据 load address(base) 把运行时地址换算成“镜像内偏移”,在 dSYM 中查找函数与行号并写回报告或输出 [2][3]。

因此:UUID 不一致(例如换了 Xcode 版本或编译选项重新构建)、缺少 dSYMload address 错误,都会导致无法符号化或结果错误。


五、获取崩溃报告

5.1 从 Xcode 与 App Store Connect

  • Xcode → Window → Organizer → Crashes:可看到已同步的崩溃报告(来自 TestFlight/App Store 用户且已开启诊断共享)。若上传时包含符号,此处多为已符号化 [2][8]。
  • Xcode → Window → Devices and Simulators → 选中设备 → View Device Logs:可把本机或用户导出的 .crash/.ips 拖入 Device Logs 列表,由 Xcode 自动尝试符号化(需本机有对应 dSYM 或系统符号)[2]。

5.2 从设备本地导出(用户/测试人员操作)

iOS / iPadOS [8]:

  1. 设置 → 隐私与安全性 → 分析与改进 → 分析数据(Analytics Data)。
  2. 找到以应用名为前缀的崩溃日志(名称常以 _ 开头),点进后通过“分享”以邮件等方式发给开发者。

macOS [8]:

  1. 打开 Console.app → 左侧选择本机 → Crash Reports。
  2. 找到对应应用的崩溃报告,右键 → Reveal in Finder,可复制或通过邮件发送。

5.3 调试时生成完整崩溃报告

若在 Xcode 中调试时发生崩溃,调试器会先接管,系统不会立即写盘。需要“完整崩溃报告”时:Debug → Detach(或 LLDB 中执行 detach),让进程继续运行直至退出,系统再生成报告;再按 5.2 方式在设备或 Mac 上找到该报告 [8]。


六、符号化操作 SOP

6.1 前置检查:UUID 一致

符号化前必须确认:崩溃报告里该二进制的 UUIDdSYM 的 UUID 一致。

  • 从报告中找 Binary Images 里该镜像的 UUID(.ips 的 usedImages[].uuid;.crash 常在小括号内,小写无连字符)。
  • 在终端执行 [2][3]:
dwarfdump --uuid <PathToDSYM>/Contents/Resources/DWARF/<BinaryName>
dwarfdump --uuid <PathToBinary>

两者一致才可用该 dSYM 符号化该二进制。

6.2 用 Xcode 符号化(推荐)

  1. 扩展名:确保报告为 .crash(.ips 若 Xcode 支持可直接拖,否则可先导出为 .crash 或保留 .ips 用命令行)。
  2. 打开 Devices and Simulators → 选中设备 → View Device Logs
  3. 将崩溃报告文件拖入左侧日志列表。
  4. 若本机 Spotlight 可搜到对应 UUID 的 dSYM(例如在 ~/Library/Developer/Xcode/Archives 或项目 DerivedData),Xcode 会自动符号化;符号化后栈中会显示函数名与行号 [2]。

若未符号化或仅部分符号化:多为缺少匹配 dSYM系统框架符号缺失(需连接过对应系统版本的设备,让 Xcode 拉取系统符号)[2]。

6.3 用 symbolicatecrash 命令行

位置(随 Xcode 安装)[2][3]:

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

环境变量(必须)[2][3]:

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

用法示例 [2][3]:

symbolicatecrash /path/to/crash.crash /path/to/App.dSYM > symbolicated.txt
# 或指定 dSYM 目录
symbolicatecrash -d /path/to/dSYMs -o symbolicated.txt /path/to/crash.crash
  • 支持一次传入多个 dSYM 或目录,工具会按报告中的 UUID 自动匹配。
  • 输入必须是系统生成的完整崩溃报告(含 Binary Images),否则无法解析。

6.4 用 atos 单地址符号化

适用于:只有若干地址、或在 LLDB/脚本中对单帧反解。

公式 [2][3][7]:报告中某帧的运行时地址 = 该镜像在报告中的 base(load address) + 该帧的 imageOffset(.ips 中)或从 “base+offset” 形式中读出。

命令形式 [2][3]:

atos -arch <arch> -o <PathToDSYM>/Contents/Resources/DWARF/<BinaryName> -l <LoadAddress> <Address1> [Address2 ...]

示例(Binary 名为 TouchCanvas,arm64,base 0x1022c0000)[2]:

atos -arch arm64 -o TouchCanvas.app.dSYM/Contents/Resources/DWARF/TouchCanvas -l 0x1022c0000 0x00000001022df754
# 输出示例:ViewController.touchesEstimatedPropertiesUpdated(_:) (in TouchCanvas) + 304
  • -o 必须是 dSYM 包内的 DWARF 文件路径,不能只写 .dSYM 包路径 [2]。
  • -l 必须是该次运行中该镜像的 load address,在 Binary Images 中查。

6.5 用 Spotlight 查找本机 dSYM(按 UUID)

若已知 Binary 在报告中的 Build UUID(如 9cc89c5e55163f4ab40c5821e99f05c6),可转为标准格式(大写、8-4-4-4-12)再查 [2]:

mdfind "com_apple_xcode_dsym_uuids == 9CC89C5E-5516-3F4A-B40C-5821E99F05C6"

若返回路径,说明本机有该 dSYM,可再 dwarfdump --uuid 核对后用于 Xcode 或 symbolicatecrash。

6.6 符号化 SOP 速查

步骤 操作
1 拿到 .ips 或 .crash;若是 .txt,重命名为 .crash 以便 Xcode 识别
2 在报告底部 Binary Images 中确认主程序/Extension 的 UUID 与 arch
3 mdfind "com_apple_xcode_dsym_uuids == <UUID>" 或 Archive 路径找到对应 dSYM,dwarfdump --uuid 核对
4 优先在 Xcode Device Logs 中拖入报告,由 Xcode 自动符号化
5 若需命令行:设置 DEVELOPER_DIR,用 symbolicatecrash 传入报告与 dSYM(或目录),输出到文件
6 若仅有个别地址:从 Binary Images 取 base,用 atos -arch -o -l 反解

七、异常类型与诊断要点

7.1 常见异常类型(Exception Type)

以下为 Apple 文档中常见类型与含义摘要 [10][11]:

异常类型 典型含义与排查方向
EXC_BAD_ACCESS (SIGSEGV) 非法或越界内存访问(野指针、已释放对象、栈溢出等)[10]
EXC_BAD_ACCESS (SIGBUS) 错位访问、指针认证失败等 [10]
EXC_BREAKPOINT (SIGTRAP) 陷阱指令触发;Swift 中常见于强制解包 nil、断言失败、fatalError 等 [10][11]
EXC_CRASH (SIGABRT) 进程调用 abort() 或断言失败;常见于 NSException 未捕获、Objective-C 异常、断言 [10]
EXC_CRASH (SIGKILL) 被系统终止:如 Watchdog、内存压力、用户强退等 [10]
EXC_CRASH (SIGTERM) 软件终止信号 [10]
EXC_GUARD 违反受保护资源(如文件描述符 guard)[10]
EXC_RESOURCE 超过资源限制(CPU 时间、内存等)[10]
EXC_ARITHMETIC 算术异常(如除零、浮点错误)[10]

7.2 诊断时的使用方式

  • 先看 Exception Type / signal 判断大类:内存问题、断言/abort、系统杀进程等。
  • 结合 Exception Message / Termination ReasonLast Exception Backtrace(若有)缩小范围。
  • Crashed ThreadFrame 0 与自家 App 的栈帧是首要关注点;系统库帧可帮助理解调用链(例如是否在 present popover、主线程卡顿等)[9]。

八、崩溃分析流程与解读

8.1 分析顺序建议(基于 Apple 文档 [9])

  1. 确认报告已充分符号化:至少自家 App 的栈帧要有函数名与行号;否则先按第六章完成符号化。
  2. 从用户视角找入口:根据栈中与业务相关的帧,推断用户当时在使用什么功能(例如某个 VC、某个 present)。
  3. 看 Header:设备型号、系统版本、App 版本、启动时间与崩溃时间(运行时长)、是否 TestFlight、主 App 还是 Extension 等,用于复现环境与分组。
  4. 看异常信息:Exception Type、Exception Codes、Termination Reason,判断是内存、断言、Watchdog 等哪一类。
  5. 看崩溃线程 backtrace:从 Frame 0 往上看,先关注自家代码;再结合 Last Exception Backtrace(若有)看“谁抛出了异常”。
  6. 看其它线程:是否有大量相似等待、是否涉及不该在非主线程调用的 API(如 UI)等 [9]。
  7. 复杂内存/寄存器问题:可结合 threadState 与 atos 对 PC/LR 等地址符号化,或参考 [Investigating memory access crashes] 等专项文档。

8.2 分组与复现

  • 多份报告可按 相同 Exception Type + 相同栈顶帧相同 Termination Reason 分组,便于判断是否为同一根因、是否可稳定复现 [9]。
  • 用 Header 中的 CrashReporter Key / Beta Identifier 区分不同用户/设备,评估影响面。

8.3 系统符号与 Binary Images

  • 若系统库帧未符号化,需在与报告系统版本一致的设备上连接 Xcode,让 Xcode 拉取该系统版本的符号;或在本机已有对应版本符号时,Xcode 才能反解系统帧 [2]。
  • Binary Images 可用来确认:主程序与各 Framework/Extension 的 UUID是否缺少预期加载的库(如动态加载的 framework)[9]。

九、关键概念图示与流程

9.1 崩溃报告生成与符号化数据流

flowchart LR
    subgraph 设备
        A[App 崩溃]
        B[系统收集状态]
        C[.ips / .crash]
    end
    subgraph 开发机
        D[dSYM]
        E[Xcode / symbolicatecrash / atos]
        F[符号化报告]
    end
    A --> B --> C
    C --> E
    D --> E
    E --> F

9.2 符号化匹配关系

flowchart TB
    subgraph 崩溃报告
        U1[Binary Images: UUID, base, name]
        F1[Frames: imageIndex, imageOffset]
    end
    subgraph 本地
        DSYM[dSYM: UUID, DWARF]
    end
    U1 -->|UUID 一致| DSYM
    F1 -->|base + imageOffset = 运行时地址| atos
    DSYM --> atos[atos / symbolicatecrash]
    atos --> out[函数名 + 行号]

9.3 从获取到分析的流程

flowchart TD
    A[获取 .ips / .crash] --> B{是否已符号化?}
    B -->|否| C[按 UUID 找 dSYM]
    C --> D[Xcode 拖入 或 symbolicatecrash/atos]
    D --> E[得到符号化报告]
    B -->|是| E
    E --> F[看 Exception Type]
    F --> G[看 Crashed Thread 栈顶与自家帧]
    G --> H[结合 Last Exception / Termination]
    H --> I[定位代码与复现路径]

十、伪代码与算法说明

10.1 判断报告是否已符号化

根据 Apple 文档 [2]:若 backtrace 中每一帧都包含可读函数名(而非“基址+偏移”或纯地址),则视为已完全符号化;若仅部分帧有函数名,为部分符号化;若全是地址或“基址+偏移”,为未符号化

对于报告中的每个线程 thread:
  对于 thread 的每个帧 frame:
    若 frame 仅包含 "0x... + 数字" 或 "基址 + 偏移" 且无函数名:
      返回 "未符号化"
若 存在任一 frame 无函数名:
  返回 "部分符号化"
否则:
  返回 "已符号化"

10.2 atos 使用的地址关系

报告中某帧的运行时地址load address(base)imageOffset 关系 [2][7]:

运行时地址 = base(Binary Images 中该镜像的 base) + imageOffset(该帧相对该镜像的偏移)

atos 内部会用“运行时地址 - base”得到相对偏移,在 dSYM 的 DWARF 中查找对应符号与行号。因此 -l 必须传入该次运行的 base(从同一份报告的 Binary Images 读取)。

10.3 UUID 匹配与 dSYM 查找

1. 从崩溃报告 Binary Images 中取出目标镜像的 uuid 字符串(可能为小写、无连字符)。
2. 转为标准格式:32 字符,8-4-4-4-12,大写,连字符分隔。
3. 使用 mdfind "com_apple_xcode_dsym_uuids == <UUID>" 得到候选 dSYM 路径。
4. 对候选路径执行 dwarfdump --uuid <dSYM内DWARF路径>,与报告中的 uuid(忽略大小写与连字符)比较。
5. 一致则该 dSYM 可用于该二进制;否则需从 Archive 或构建产物中取正确版本。

十一、应用场景与最佳实践

11.1 构建与归档

  • Release/分发构建 统一使用 DWARF with dSYM File,并保留每次分发的 Archive(含 dSYM)[4]。
  • 上传 App Store/TestFlight 时勾选上传符号,便于 Organizer 中自动符号化 [2][4]。

11.2 第三方崩溃统计与符号上传

若使用 Firebase Crashlytics、Bugly、Sentry 等,需按各平台文档在构建阶段上传 dSYM(或符号表),以便其服务端对上报的堆栈做符号化 [12]。例如 Firebase 要求在 Xcode Build Phases 中配置上传脚本与 dSYM 路径 [12]。

11.3 .ips 与脚本化处理

  • .ips 为 JSON,便于用脚本解析:取 bug_type==309threadsusedImagesexception 等,批量提取 UUID、faultingThread、栈顶帧等 [6][7]。
  • 若需对大量报告做“是否可符号化”检查,可解析 usedImages 中的 uuid,与本地或符号服务器中的 dSYM UUID 列表比对。

11.4 常见崩溃模式与专项文档

11.5 官方文档与延伸阅读

资源 用途
Adding identifiable symbol names to a crash report 符号化步骤、Xcode/atos、UUID、mdfind [2]
Analyzing a crash report 分析顺序、Header/Exception/Backtrace/寄存器 [9]
Interpreting the JSON format of a crash report .ips 结构、metadata、report 各键 [6][7]
Understanding the exception types in a crash report 异常类型与信号含义 [10]
Acquiring crash reports and diagnostic logs 获取途径、设备导出、Organizer [8]
Building your app to include debugging information dSYM 生成、上传与归档 [4]
Identifying the cause of common crashes 常见崩溃模式与排查思路
Investigating memory access crashes 内存访问崩溃深入分析

参考文献

[1] Apple. Understanding and Analyzing Application Crash Reports (TN2151).
[2] Apple. Adding identifiable symbol names to a crash report. developer.apple.com/documentati…
[3] Apple. Symbolicating iPhone App Crash Reports (Stack Overflow / 社区实践).
[4] Apple. Building your app to include debugging information. developer.apple.com/documentati…
[5] 阿里云. 苹果官方文档:理解和分析ios应用崩溃日志. developer.aliyun.com/article/239…
[6] Apple. Interpreting the JSON format of a crash report. developer.apple.com/documentati…
[7] Apple. Interpreting the JSON format of a crash report — Binary images, Frames, Convert numeric values.
[8] Apple. Acquiring crash reports and diagnostic logs. developer.apple.com/documentati…
[9] Apple. Analyzing a crash report. developer.apple.com/documentati…
[10] Apple. Understanding the exception types in a crash report. developer.apple.com/documentati…
[11] RY's Blog. EXC_BREAKPOINT when forced unwrapping optional in Swift.
[12] Firebase. 在 Crashlytics 信息中心内获取易于理解的崩溃报告(Apple 平台) / Get deobfuscated crash reports.
[13] Apple. Identifying the cause of common crashes. developer.apple.com/documentati…
[14] Apple. Investigating memory access crashes. developer.apple.com/documentati…

04-Debug调试@UI-Lookin UI调试工具:从原理到实践

Lookin UI 调试工具:从原理到实践

📋 目录


一、概述与历史演进

1.1 工具简介

Lookin 是一款免费的 macOS 端 iOS 视图调试应用,与 LookinServer(嵌入 iOS 工程的 Framework)配合使用,可查看与修改 iOS App 内的 UI 对象——包括视图层级结构、视图与控件属性、布局与约束等,功能定位类似 Xcode 自带的 UI Inspector 或商业软件 Reveal [1][2][3]。

Lookin 由 QMUI 团队(曾隶属微信读书等产品)开源并维护:LookinServer 为 iOS 端 SDK(GitHub: QMUI/LookinServer),Lookin 为 macOS 端桌面应用(GitHub: hughkli/Lookin)。官网为 lookin.work/;集成后支持模拟器与真机,并可在无 Mac 连接时通过 App 内摇一摇等方式使用内置调试界面 [1][2][4][5]。

1.2 历史与版本脉络

时期/版本 事件
开源发布 Lookin / LookinServer 以免费、开源形式发布,填补 Xcode UI Inspector 能力有限、Reveal 收费等需求 [1][2]
仓库与官网 iOS 端 QMUI/LookinServer、Mac 端 hughkli/Lookin;官网 lookin.work 提供集成指南与 FAQ [1][2]
集成方式演进 支持 CocoaPods(ObjC / Swift 子库)、Swift Package Manager手动集成(Framework + Run Script)[1][2][4]
1.0.6+ 安全要求 禁止在 Release/App Store 构建中集成 LookinServer不要使用早于 1.0.6 的版本,旧版存在严重 Bug 可能导致线上事故 [2][6]
文档与技巧 官方与社区提供「自定义信息展示」「更多成员变量」「Swift 优化」等进阶文档(如字节飞书文档汇总)[2]

1.3 典型应用场景

  • 视图层级与结构排查:查看完整 UI 树(含屏幕外、hidden 视图)、UITableViewCell 的 indexPath、嵌套层级与折叠级别,定位视图遮挡、层级错误或约束冲突。
  • 属性查看与修改:实时查看 frame、bounds、backgroundColor、alpha、约束等;在 Mac 端或控制台修改属性并立即在设备上生效,用于快速验证布局与样式。
  • 导出与协作:将当前页面的 UI 信息导出为文件,脱离 Xcode 与设备单独查看或分享给他人分析。
  • 方法监听与堆栈:监听指定方法调用并打印堆栈,辅助定位触发时机与调用链。
  • 无 Mac 场景:在真机上通过摇一摇等触发 App 内 Lookin 界面,不依赖 Mac 连接即可做基础审查。

二、核心原理与架构

2.1 双端架构:LookinServer(iOS)与 Lookin(macOS)

Lookin 采用 「iOS 端 SDK + macOS 端桌面应用」 的 C/S 式架构 [1][2][4][5]:

  • LookinServer(iOS):以 Framework 形式嵌入目标 App(仅 Debug 配置)。在 App 进程内通过 Objective-C Runtime反射 获取当前 UI 层级与视图属性,将数据序列化后通过进程间/网络通信发送给 Mac 端。
  • Lookin(macOS):在 Mac 上运行,发现并连接同一网络或通过 USB 转发的 iOS 设备/模拟器上的 LookinServer,接收序列化数据后反序列化并渲染为 2D 层级树3D 视图,支持属性编辑与指令回传。

因此,不集成 LookinServer 的 App 无法被 Mac 版 Lookin 连接;集成后,模拟器或真机与 Mac 需处于可发现/可通信环境(如本机模拟器、同网段或 USB 连接)[1][2][4]。

2.2 视图信息的获取与序列化(概念)

iOS 的 UI 层级根植于 UIWindow / UIViewController 及其 view 层级。LookinServer 在 App 进程内 [4][5]:

  1. 遍历视图树:从 keyWindow(或指定 window)的 rootViewController 出发,递归访问 view.subviews,得到整棵视图树;可配置折叠深度、是否包含 hidden 视图等。
  2. 提取属性:对每个 UIView(及其子类)利用 Runtime 读取属性(如 frame、bounds、backgroundColor、layer 信息、约束等),以及自定义的 LKS_Config 等扩展属性。
  3. 序列化:将树形结构及属性编码为可在进程间或网络上传输的格式(如自定义二进制或 JSON),并发送给 Mac。
  4. Mac 端反序列化与展示:Lookin 收到数据后重建树结构,在 2D 面板展示层级、在 3D 视图展示空间关系,并支持点击选中、属性面板编辑。

修改回写:用户在 Mac 上修改某视图属性(如 frame、backgroundColor)时,Lookin 将修改指令发回 LookinServer,LookinServer 在 App 主线程对对应视图执行 setter(如 view.frame = ...),实现实时生效 [4][5]。

2.3 三种使用模式:2D、3D、Export

  • Lookin_2D:在 Mac 或 App 内以树形列表形式展示视图层级,点击节点可查看/编辑属性,对应「审查元素」。
  • Lookin_3D:将视图层级以三维空间形式展示,便于观察重叠、遮挡与 z-order。
  • Lookin_Export:将当前 UI 快照(层级与属性)导出为文件,可在未连接设备时用 Lookin 打开查看 [1][4][5]。
    触发方式:除在 Mac 或 App 内点击对应入口外,可通过代码发送通知触发,例如(Objective-C): [[NSNotificationCenter defaultCenter] postNotificationName:@"Lookin_Export" object:nil];
    同理可触发 Lookin_2DLookin_3D [1][5]。

2.4 数据流概览

flowchart LR
    subgraph iOS App
        A[UIWindow / ViewController]
        B[LookinServer]
        C[Runtime / 视图树遍历]
    end
    subgraph 传输
        D[序列化]
        E[IPC / 网络]
    end
    subgraph Mac
        F[Lookin]
        G[反序列化 / 2D·3D 展示]
        H[属性编辑回写]
    end
    A --> C
    C --> B
    B --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> E
    E --> B

三、获取、安装与集成

3.1 前置条件

项目 说明
Mac 安装 Lookin 桌面应用(从官网或 GitHub Release 下载)[1][2]
Xcode 用于编译运行 iOS 工程;LookinServer 仅需在 Debug 配置下集成 [1][2]
iOS 项目 支持 Objective-C 或 Swift;Swift 项目需使用 Swift 子库或 SPM [2]

3.2 获取 Lookin 桌面应用

3.3 集成 LookinServer 到 iOS 项目(官方方式 [1][2])

重要仅在 Debug 配置下集成不要使用早于 1.0.6 的版本 [2][6]。

通过 CocoaPods
  • Objective-C 项目:在 Podfile 中增加
    pod 'LookinServer', :configurations => ['Debug']
    然后 pod install
  • Swift 项目
    pod 'LookinServer', :subspecs => ['Swift'], :configurations => ['Debug']

若项目使用自定义 xcconfig,需将所有 Debug 相关配置名列入 configurations,例如:
pod 'LookinServer', :configurations => ['Debug', 'Debug-Staging']
否则 Release 或其它配置可能误链 LookinServer,存在上线风险 [4][7]。

通过 Swift Package Manager
  • 在 Xcode 中:File → Add Package Dependencies,填入
    https://github.com/QMUI/LookinServer
    并选择仅在 Debug 配置下链接该依赖。
手动集成
  • LookinServer 仓库 获取 LookinServer.framework(或源码),加入工程。
  • 通过 Run Script 在构建时按配置条件嵌入;需定义宏(如 SHOULD_COMPILE_LOOKIN_SERVER)确保 Release 不包含。详见 官网集成指南Run Script 说明 [2][4]。

3.4 集成后验证

  1. Debug 配置编译并运行到模拟器真机(真机与 Mac 需同网或通过 USB 等可发现方式)。
  2. 打开 Mac 上的 Lookin,应能自动发现并列出当前运行中的 App。
  3. 选择对应设备与 App,连接成功后即可看到 2D 层级与 3D 视图;若无法发现,请检查网络、防火墙及是否确为 Debug 包且已包含 LookinServer。

四、使用流程与操作步骤

4.1 基本使用流程(Mac + 模拟器/真机)

步骤 操作 说明
1 Debug 配置运行 iOS App 模拟器或真机均可;真机与 Mac 需可通信(同网或 USB)
2 打开 Mac 上的 Lookin 从应用程序或官网下载的 app 启动
3 在 Lookin 中选择设备与 App 列表中选中当前运行中的 App,建立连接
4 选择 2D3D 模式 2D:树形层级与属性面板;3D:空间关系与遮挡
5 在层级树或 3D 视图中选中视图 右侧或面板中显示该视图属性,可编辑并实时生效
6 (可选)使用控制台或方法监听 执行代码或监听方法调用与堆栈
7 (可选)导出 使用 Export 将当前 UI 快照导出为文件,便于离线查看或分享

4.2 无 Mac 连接:App 内使用

  • 在已集成 LookinServer 的 App 中,可通过摇一摇(或配置的其它手势)调起 Lookin 内置的调试界面 [3][5]。
  • 或通过代码发送通知触发 2D/3D/Export:
    • Lookin_2D:审查元素
    • Lookin_3D:3D 视图
    • Lookin_Export:导出文件
      这样可在真机或他人设备上不连 Mac 也能做基础 UI 审查与导出。

4.3 导出(Lookin_Export)

  • 在 Mac 或 App 内触发 Export 后,当前页面的 UI 层级与属性会保存为 Lookin 可识别的文件格式。
  • 导出文件可在未连接设备时用 Lookin 打开,用于归档、协作或问题复现 [1][5]。

五、功能体系与数据表示

5.1 功能总览

功能 说明
视图层级展示 树形结构展示 UI 层级,支持折叠级别、显示 hidden 视图、屏幕外视图;可显示 UITableViewCell 的 indexPath 等 [1][4]
属性查看与编辑 查看 frame、bounds、backgroundColor、alpha、约束等;在 Mac 或控制台修改后实时回写到 App [1][4][5]
2D 审查 对应 Lookin_2D,以列表+属性面板形式审查元素
3D 视图 对应 Lookin_3D,以三维形式展示视图堆叠与遮挡关系
导出 将当前 UI 快照导出为文件,脱离设备与 Xcode 查看 [1][5]
控制台 输入代码访问当前选中视图或类,执行方法或读取属性 [1][4]
方法监听 监听特定方法调用并打印堆栈,辅助定位调用链 [1][4]
自定义展示 通过 LKS_Config 等接口在 Lookin 中展示自定义信息或更多成员变量 [2]

5.2 与 Xcode UI Inspector 的差异(概念)

  • 范围:Lookin 可展示比 Xcode UI Inspector 更大范围的视图(不限于当前屏幕可见区域),且可配置折叠与 hidden 视图 [1][4]。
  • 形态:Lookin 提供独立的 Mac 应用与 2D/3D/Export 多种形态;Xcode 的 UI Inspector 嵌入在 Debug 会话中。
  • 集成:Lookin 需主动集成 LookinServer;Xcode 对任意 Debug 运行中的 App 均可使用 UI Inspector,但功能相对简单。

六、关键概念图示与流程

6.1 双端与数据流

flowchart TB
    subgraph iOS
        APP[App 进程]
        RT[Runtime / 视图树]
        LKS[LookinServer]
    end
    subgraph 传输
        S[序列化]
        C[连接]
    end
    subgraph macOS
        LK[Lookin]
        UI[2D / 3D / 属性面板]
    end
    APP --> RT
    RT --> LKS
    LKS --> S
    S --> C
    C --> LK
    LK --> UI
    UI -->|编辑回写| C
    C --> LKS

6.2 使用流程简图

sequenceDiagram
    participant U as 用户
    participant M as Mac Lookin
    participant I as iOS App + LookinServer

    U->>M: 打开 Lookin,选择设备与 App
    M->>I: 建立连接
    I->>I: 遍历视图树,序列化
    I->>M: 发送 UI 数据
    M->>U: 展示 2D/3D 与属性
    U->>M: 编辑属性或触发 Export
    M->>I: 回写修改或请求导出
    I->>M: 确认或返回导出文件

七、应用场景与最佳实践

7.1 视图层级与布局调试

  • 使用 2D 检查嵌套层级、view 的父子关系与同层顺序,结合 3D 查看重叠与遮挡。
  • 利用「显示 hidden 视图」「折叠级别」减少噪音,快速定位目标 view;通过属性面板查看 frame、constraints、autoresizing 等,判断布局异常原因。

7.2 属性实时修改与验证

  • 在属性面板直接改 frame、backgroundColor、alpha 等,无需改代码重新运行,适合快速验证样式与布局假设。
  • 注意:修改仅对当前运行实例生效,不会写入源码;需将确认后的值同步到代码或约束中。

7.3 导出与协作

  • 对难以复现的 UI 问题,使用 Export 导出当前页面快照,将文件发给同事或在未连接设备时用 Lookin 打开分析。
  • 建议在问题复现后立即导出,避免界面变化导致快照与问题现场不一致。

7.4 官方文档与进阶技巧导读

内容 链接或入口
官网与集成 lookin.work集成指南CocoaPods手动集成 Run Script
LookinServer 仓库 GitHub QMUI/LookinServer(iOS 端)
Lookin Mac 应用 GitHub hughkli/Lookin
演示项目 官网提供的 QMUI-Demo 等,可快速体验
进阶 官方与社区文档:在 Lookin 中展示自定义信息、展示更多成员变量、Swift 优化等(见 LookinServer README 中的飞书/字节文档链接)[2]

7.5 安全与版本规范

  • 仅 Debug 集成:通过 :configurations => ['Debug'] 或 SPM/手动时的配置条件,确保 Release/App Store 包不包含 LookinServer [2][6]。
  • 版本:使用 1.0.6 及以上 版本,避免旧版严重 Bug 导致线上风险 [2][6]。
  • 自定义 xcconfig:若存在多种 Debug 配置,务必在 Pod 的 configurations 中全部列出,防止误打到非 Debug 包 [4][7]。

八、伪代码与算法说明

8.1 视图树遍历与属性收集(概念)

函数 collect_view_hierarchy(root, options):
  nodes = []
  函数 visit(view, depth):
    若 options.include_hidden 为假 且 view.hidden 为真: 返回
    若 depth > options.max_depth: 返回
    node = 新建节点()
    node.view_class = view.class
    node.frame = view.frame
    node.bounds = view.bounds
    node.alpha = view.alpha
    node.hidden = view.hidden
    node.backgroundColor = view.backgroundColor
    // 通过 Runtime 读取更多属性、约束等
    node.children = []
    for subview in view.subviews:
      child = visit(subview, depth + 1)
      if child: node.children.append(child)
    nodes.append(node)
    return node
  visit(root, 0)
   return 根节点

8.2 序列化与连接(概念)

函数 send_to_mac(tree):
  将 tree 编码为可传输格式(如二进制或 JSON)
  通过已建立的连接(如 socket / 本地通信)发送到 Lookin Mac 端
  Mac 端反序列化后重建树结构,渲染 2D 树与 3D 视图

8.3 属性修改回写(概念)

函数 apply_edit(view_id, property_key, value):
  LookinServer 在 App 主线程根据 view_id 找到对应 UIView 实例
  根据 property_key 调用对应 setter,例如 setFrame: / setBackgroundColor:
  视图更新后,可选地再次同步当前状态到 Mac

九、与其它 UI 调试工具的对比

维度 Lookin Xcode UI Inspector Reveal
费用 免费、开源 随 Xcode 免费 商业收费
集成方式 需集成 LookinServer(Debug) 无需集成,Debug 运行即可 需集成 Reveal SDK 或 Reveal Loader
视图范围 可超出一屏、含 hidden、可折叠 以当前层级为主 完整层级、多窗口
2D/3D 2D 树 + 3D 视图 + Export 以层级与属性为主 2D/3D、时间线等
属性修改 支持实时回写 支持部分修改 支持
控制台/方法监听 支持控制台与方法监听 依赖 LLDB/控制台 部分版本支持
无 Mac 使用 支持 App 内摇一摇等 不适用 依赖 Reveal App

Lookin 适合需要免费、开源、可定制视图范围与 2D/3D/Export 能力的团队;Xcode UI Inspector 适合快速随 Debug 使用;Reveal 适合对商业支持与高级功能有需求的场景。


参考文献

[1] Lookin 官网. Lookin - Free macOS app for iOS view debugging. lookin.work/
[2] QMUI. LookinServer. GitHub. github.com/QMUI/Lookin…
[3] hughkli. Lookin (macOS app). GitHub. github.com/hughkli/Loo…
[4] 腾讯云开发者社区 / IM Geek / GitCode 等. Lookin 原理与集成(Runtime、序列化、双端通信、CocoaPods/SPM/手动集成).
[5] 简书. 使用 Lookin 调试 iOS App UI. www.jianshu.com/p/ec5c7e0e7…
[6] LookinServer 官方. 不要使用早于 1.0.6 的版本;不要在 Release 集成. GitHub README 与 Feishu 说明.
[7] GitCode 博客. LookinServer 集成:自定义 xcconfig 配置时的注意事项.
[8] Apple. UI Inspector. Xcode 文档.
[9] Reveal. Reveal - iOS UI Debugger. revealapp.com/

05-Debug调试@调试器-Chisel LLDB调试工具:从原理到实践

📋 目录


一、概述与历史演进

1.1 工具简介

ChiselFacebook(Meta) 开源的 LLDB 命令集合,用于辅助调试 iOS 与 macOS 应用。它通过 Python 脚本 调用 LLDB 的 Scripting Bridge API(SB API) 扩展调试器能力,在不修改 Xcode 或 LLDB 本体的前提下,为开发者提供大量高层调试命令——如递归打印视图/控制器层级、在 Mac 上可视化 UIImage/UIView、按类名查找视图、对方法设置符号断点、查看响应链与约束等 [1][2][3]。

与仅使用 LLDB 内置的 pobtframe variable 等相比,Chisel 的命令更贴近 UIKit/AppKit 与日常 UI 调试场景,可显著减少手写表达式与重复操作。Chisel 与 Derek Selander 的 LLDB 扩展项目齐名,被广泛视为 iOS 开发者的标配调试增强工具 [1][3]。

仓库GitHub - facebook/chisel许可证:MIT。

1.2 历史与版本脉络

时期/事件 说明
Facebook 开源 Chisel 由 Facebook 工程师开发并开源,作为内部 iOS 调试的增强工具集 [1][2]
LLDB 与 Python 依赖 LLDB 的 Python 脚本SB API:通过 command script import 加载 fbchisellldb.py,在调试会话中注册自定义命令 [1][2]
Homebrew 分发 支持 brew install chisel 安装,安装后需在 ~/.lldbinit 中配置 command script import 路径 [1][2]
架构差异 Intel Mac:常见路径为 /usr/local/opt/chisel/libexec/fbchisellldb.pyApple Silicon (M1+):为 /opt/homebrew/opt/chisel/libexec/fbchisellldb.py [2]
objc.io 推荐 Chisel 官方 README 推荐阅读 Ari Grant 的 Dancing in the Debugger — A Waltz with LLDB(objc.io 第 19 期),以理解 LLDB 与 Chisel 的配合 [2]

1.3 典型应用场景

  • 视图/控制器层级排查:断点暂停后使用 pviewspvc 快速查看 keyWindow 的视图树与 ViewController 栈,定位层级或 present 关系问题。
  • 视图定位与可视化:用 fv/fvc 按类名或正则查找视图/控制器并将地址拷到剪贴板;用 visualize 将 UIImage/UIView/CALayer 等在 Mac 的 Preview 中打开,便于检查图片或布局。
  • 临时显示/隐藏与边框show/hideborder/unbordermask/unmaskflicker 在不继续执行的情况下修改视图可见性或描边,辅助确认视图位置与遮挡关系。
  • 断点与监视bmessage 对类或其子类上的方法设置符号断点(无需关心具体实现类);wivar 对实例变量设置 watchpoint,便于追踪成员变化。
  • 响应链、约束与数据presponder 打印响应链;paltracealamborder 等辅助 Auto Layout 调试;pcurlpjsonpdata 等方便网络与数据调试。

二、核心原理与架构

2.1 LLDB 与 Python 脚本扩展

LLDB(Low Level Debugger)是 Apple 在 Xcode 中采用的底层调试器,支持 C、C++、Objective-C、Swift 等。除内置命令外,LLDB 提供 Python 脚本接口:在调试会话中可通过 command script import <path> 加载 Python 模块,该模块可调用 LLDB Python API(SB API) 访问调试目标(进程、线程、帧、变量、表达式求值等),并调用 debugger.HandleCommand()SBCommandInterpreter 注册自定义命令 [2][4][5]。

Chisel 的入口脚本为 fbchisellldb.py:被 import 后,会加载 commands/ 目录下各 Python 模块,每个模块通过 FBCommand 基类(或等价接口)定义命令的 namedescriptionrun 以及可选的参数/选项;最终这些命令被注册到当前 LLDB 的 command interpreter,在 (lldb) 提示符下可直接输入使用 [1][2]。

2.2 Chisel 的代码结构(概念)

  • fbchisellldb.py:入口,负责加载各子模块并注册命令。
  • fbchisellldbbase.py 等:基类与公共逻辑(如 FBCommand、参数解析、raw-input 等)。
  • commands/:按功能拆分的命令实现,例如:
    • FBPrintCommands.py:pviews、pvc、pclass、pmethods、presponder、pcurl、pjson 等打印类命令。
    • FBDisplayCommands.py:border、unborder、show、hide、mask、unmask、caflush、dismiss、present 等显示与视图操作。
    • FBFindCommands.py:fv、fvc、taplog、vs 等查找与交互。
    • FBDebugCommands.py:bmessage、binside、wivar、mwarning 等断点与监视。
    • FBVisualizationCommands.py:visualize。
    • FBAutoLayoutCommands.py:paltrace、alamborder、alamunborder。
    • 以及 Accessibility、Component、Invocation、TextInput 等 [1][2]。

命令实现中通过 LLDB SB API 获取当前 target、frame、变量,并执行表达式(如 [UIApplication sharedApplication]keyWindowsubviews)以遍历视图层级或修改属性;部分命令会将数据(如图像)通过 LLDB 传回 Mac 并在本地用 Preview 等打开 [2][4]。

2.3 数据流与执行位置

Chisel 的命令在 开发机(Mac) 上的 LLDB 进程中执行,但 表达式求值 发生在 被调试进程(iOS 模拟器或真机上的 App)中。例如 pviews 会在目标进程中执行获取 keyWindow 与递归 description 的代码,结果回传到 LLDB 并打印到控制台;visualize 则会把目标进程中的 UIImage 等数据提取出来,在 Mac 上写入临时文件并用 Preview 打开 [2][4]。

flowchart LR
    subgraph Mac
        X[Xcode / LLDB]
        C[Chisel Python]
        P[Preview / 剪贴板]
    end
    subgraph 目标进程
        A[iOS/macOS App]
    end
    X --> C
    C -->|SB API 求值| A
    A -->|返回值/数据| C
    C --> X
    C --> P

三、获取与安装

3.1 前置条件

项目 说明
Mac 运行 macOS,已安装 Xcode 及命令行工具
LLDB 随 Xcode 提供;Chisel 在调试会话中通过 command script import 加载
Python LLDB 内置 Python 绑定,无需单独安装 Python;Homebrew 安装的 Chisel 会使用系统或 LLDB 自带 Python

3.2 通过 Homebrew 安装(推荐 [2])

brew update
brew install chisel

安装后,Chisel 的脚本通常位于:

  • Intel Mac/usr/local/opt/chisel/libexec/fbchisellldb.py
  • Apple Silicon (M1+)/opt/homebrew/opt/chisel/libexec/fbchisellldb.py

3.3 配置 ~/.lldbinit

~/.lldbinit 不存在,可创建并编辑:

touch ~/.lldbinit
open ~/.lldbinit

~/.lldbinit 中增加一行(路径按实际架构二选一):

# Intel Mac
command script import /usr/local/opt/chisel/libexec/fbchisellldb.py

# Apple Silicon (M1+)
# command script import /opt/homebrew/opt/chisel/libexec/fbchisellldb.py

保存后,下次启动 Xcode 并进入调试会话 时,Chisel 命令会自动加载。若已打开 Xcode,可先在 LLDB 中执行 command source ~/.lldbinit 重新加载 [2]。

3.4 从源码安装

facebook/chisel 克隆或下载后,在 ~/.lldbinit 中写:

command script import /path/to/chisel/fbchisellldb.py

/path/to/chisel 替换为本地 Chisel 仓库路径 [2]。

3.5 验证安装

在 Xcode 中运行任意 iOS/macOS 工程,断点命中后,在 LLDB 控制台输入:

(lldb) help

在输出末尾的「user-defined commands」中应能看到 Chisel 提供的命令(如 pviewspvcfvborder 等)。也可直接执行:

(lldb) pviews

若输出了当前 keyWindow 的视图层级,则安装与配置正确 [2]。


四、命令体系与使用流程

4.1 命令分类概览

类别 代表命令 用途
视图/控制器层级 pviews、pvc 递归打印 keyWindow 的 view / view controller 描述
查找 fv、fvc、fa11y、vs 按类名/正则/无障碍标签查找视图或控制器,或交互式搜索
可视化 visualize 在 Mac Preview 中打开 UIImage、UIView、CALayer 等
显示/边框/遮罩 show、hide、border、unborder、mask、unmask、flicker 临时显示/隐藏视图、加边框、加遮罩、闪烁
渲染 caflush、slowanim、unslowanim 刷新 Core Animation、慢速动画
断点与监视 bmessage、binside、wivar 方法符号断点、库内偏移断点、实例变量 watchpoint
打印 presponder、pclass、pmethods、pproperties、pcurl、pjson、pdata、pblock、pinvocation、pivar 等 响应链、继承关系、方法列表、属性、curl、JSON、NSData、Block、调用信息、实例变量
Auto Layout paltrace、alamborder、alamunborder 约束追踪、歧义约束边框
ViewController present、dismiss present / dismiss 指定 VC
其它 mwarning、setinput、settext、taplog、pcomponents、dcomponents、rcomponents 等 模拟内存警告、输入文本、点击日志、Component 相关

完整列表可在 LLDB 中执行 help 查看,或参阅 Chisel Wiki [1][2]。

4.2 基本使用流程

  1. 在 Xcode 中为 iOS 或 macOS 项目设置断点(或运行后点击暂停)。
  2. 断点命中或暂停后,在 LLDB 控制台 输入 Chisel 命令;多数命令支持 raw-input(即命令后可直接写表达式,如 fv UITableViewborder 0x12345678);可执行 help raw-input 查看说明。
  3. 查看输出或效果(控制台打印、剪贴板、Preview 窗口等);若需修改命令行为,可查阅 help <command>
  4. 继续执行(如 continue)或单步调试,结合其它 LLDB 命令(pobtframe variable)完成排查。

五、常用命令详解与 SOP

5.1 视图与控制器层级

命令 语法与说明 典型用法
pviews pviews [--up] [--depth=depth] [view] 无参数时递归打印 keyWindow 的视图层级;--up 只打印从指定 view 到 window 的上层;--depth 限制深度;传入 view 则从该 view 开始 [2][6]
pvc pvc [viewController] 递归打印 keyWindow 的 ViewController 层级(含 present 关系);iOS 常用,macOS 不支持 [2][6]

SOP:布局或层级异常时,先 pviews 看整棵树,再用 fv <ClassName> 找到目标 view 地址,用 border <addr>mask <addr> 在界面上标出位置;若关心 VC 栈则用 pvc

5.2 查找与可视化

命令 语法与说明 典型用法
fv fv <classNameRegex> 在 keyWindow 的视图树中按类名正则查找,第一个匹配的 view 地址会写入剪贴板;后续可用 border (id)[剪贴板] 或直接 border <addr> [2][6]
fvc fvc [--name=classNameRegex] [--view=view] 按 ViewController 类名正则查找,或将拥有某 view 的 VC 打印出来 [2][6]
visualize visualize <expr> UIImage、CGImageRef、UIView、CALayer、NSData(图像)、UIColor、CIColor、CIImage、CGColorRef、CVPixelBuffer 等在 Preview.app 中打开;expr 为对象表达式 [2][6]

SOP:需要确认某视图是否在层级中或位置时:fv MyCustomView → 粘贴地址 → border (id)0x...visualize (UIView *)0x...

5.3 显示、边框与遮罩

命令 语法与说明 典型用法
show / hide show <view/layer>hide <view/layer> 不继续执行即可在设备/模拟器上显示或隐藏该 view/layer,便于确认是谁在遮挡 [2][6]
border / unborder border [--color=] [--width=] [--depth=] <view/layer> 给 view/layer 画边框;color、width、depth 可选;unborder 移除 [2][6]
mask / unmask mask [--color=] [--alpha=] <view/layer> 在 view/layer 上叠加半透明矩形,标出范围;unmask 移除 [2][6]
flicker flicker <view> 快速显示再隐藏一次,用于快速定位视图位置 [2][6]

5.4 断点与监视

命令 语法与说明 典型用法
bmessage bmessage "<expr>" 类或其子类上对方法设符号断点;expr 如 -[MyView setFrame:]+[MyClass sharedInstance]-[0xabcd1234 setFrame:];Chisel 会沿继承链找到实际实现该 selector 的类并设条件断点 [2][6]
wivar wivar <object> <ivarName> 对对象的实例变量watchpoint,该 ivar 被写入时断下 [2][6]

5.5 响应链、约束与数据

命令 语法与说明 典型用法
presponder presponder [responder] 从指定 responder 起向上打印 响应链 [2][6]
paltrace paltrace [view] 打印 Auto Layout 的调试 trace,默认 keyWindow [2][6]
alamborder / alamunborder alamborder [--color=] [--width=]alamunborder 布局歧义的 view 加边框;需 raw-input [2][6]
pcurl pcurl [--embed-data] <NSURLRequest> NSURLRequest 转成 curl 命令,便于在终端重放 [2][6]
pjson pjson [--plain] <NSDictionary/NSArray> JSON 形式打印字典或数组 [2][6]

5.6 命令速查表

场景 推荐命令
看当前界面视图树 pviews
看 ViewController 栈 pvc
按类名找 view 并标出 fv <Regex> → border <addr>
在 Mac 上看图/看 view visualize <expr>
临时隐藏某 view hide <view>
给 view 加边框 border [选项] <view>
对某类方法下断点 bmessage "-[ClassName method:]"
监视某对象 ivar 变化 wivar <obj> <ivarName>
看响应链 presponder [responder]
看约束问题 paltrace;alamborder
把请求变 curl pcurl <request>

六、关键概念图示与流程

6.1 Chisel 在调试会话中的位置

flowchart TB
    subgraph 开发机
        X[Xcode]
        L[LLDB]
        I[~/.lldbinit]
        C[Chisel Python]
    end
    subgraph 目标
        A[iOS/macOS App 进程]
    end
    X --> L
    I -->|command script import| L
    L --> C
    C -->|SB API / 表达式求值| L
    L --> A
    A -->|结果/数据| L
    L --> C

6.2 典型调试流程(视图问题)

sequenceDiagram
    participant D as 开发者
    participant L as LLDB
    participant C as Chisel
    participant A as App

    D->>L: 断点命中 / 暂停
    D->>L: pviews
    L->>C: 执行 pviews
    C->>A: 求值 keyWindow / 递归 description
    A->>C: 返回字符串
    C->>L: 输出到控制台
    D->>L: fv MyView
    C->>A: 查找并取地址
    C->>D: 地址拷到剪贴板
    D->>L: border (id)0x...
    C->>A: 设置 layer border
    A->>D: 界面显示边框

七、自定义命令与开发工作流

7.1 自定义命令接口(概念 [2])

Chisel 支持在本地添加自定义命令,供个人或团队使用。基本方式:

  1. 编写一个 Python 文件,定义继承自 fbchisellldbbase.FBCommand 的类,实现:
    • name(self):命令名
    • description(self):简短描述
    • run(self, arguments, options):命令逻辑;内部可调用 lldb.debugger.HandleCommand() 执行 LLDB 命令,或使用 SB API 获取 frame、变量、求值表达式等。
  2. ~/.lldbinit 中先 command script import Chisel 的 fbchisellldb.py,再调用 loadCommandsInDirectory 加载自定义命令所在目录 [2]。

示例(来自 Chisel README):打印 keyWindow 的 windowLevel:

#!/usr/bin/python
# 示例:自定义命令
import lldb
import fbchisellldbbase as fb

def lldbcommands():
    return [ PrintKeyWindowLevel() ]

class PrintKeyWindowLevel(fb.FBCommand):
    def name(self):
        return 'pkeywinlevel'
    def description(self):
        return 'Print the window level of the key window.'
    def run(self, arguments, options):
        lldb.debugger.HandleCommand('p (CGFloat)[(id)[(id)[UIApplication sharedApplication] keyWindow] windowLevel]')

更多参数与选项可参考 Chisel 内置命令(如 borderpinvocation)的实现;官方 README 的 Custom CommandsContributing 提供了贡献与扩展说明 [2]。

7.2 开发工作流(调试 Chisel 命令本身 [2])

  1. 写好命令脚本并放到某目录。
  2. ~/.lldbinit 中配置 loadCommandsInDirectory 加载该目录。
  3. 启动 LLDB(或 Xcode 调试),断点命中后执行 command source ~/.lldbinit 重新加载。
  4. 运行正在开发的命令,观察行为。
  5. 修改命令代码后,可使用 script reload(modulename) 重载模块,无需重启 Xcode,再重复 4–5 直至满意。

八、伪代码与算法说明

8.1 pviews 类命令的递归描述(概念)

函数 print_view_hierarchy(view, depth, max_depth):
  若 max_depth 已设定且 depth >= max_depth: 返回
  缩进 = 根据 depth 生成
  输出 缩进 + view 的 description(类名、frame 等)
  for subview in view.subviews:
    print_view_hierarchy(subview, depth + 1, max_depth)

实际实现中,Chisel 通过 LLDB 在目标进程中执行 Objective-C 表达式获取 keyWindowrootViewController.viewsubviews 等,并在本地拼接输出 [2][4]。

8.2 fv 查找视图(概念)

函数 find_view_matching(regex):
  window = 求值 "[UIApplication sharedApplication].keyWindow"
  results = 在 window 的子树中递归查找 view.class 与 regex 匹配的 view
  若 results 非空:
    将 results[0] 的地址写入剪贴板
    返回 results[0]
  否则 返回 nil

8.3 bmessage 符号断点(概念)

函数 bmessage(expr):
  # expr 如 "-[MyView setFrame:]"
  解析出 class(或 instance)与 selector
  遍历 class 及其子类(或 instance 的类及其子类),查找实际实现该 selector 的类
  在该类的实现上设置断点(或条件断点,使仅当 receiver 匹配时断下)

这样无需关心 setFrame: 是在 MyView 还是其子类中实现,都能在调用时断下 [2][6]。


九、应用场景与最佳实践

9.1 UI 层级与布局

  • 先用 pviewspvc 把握整体结构;再用 fv + bordermask 在界面上标出目标 view,确认 frame 与遮挡关系。
  • Auto Layout 异常时用 paltrace 看约束冲突/歧义;用 alamborder 在歧义 view 上画边框便于对照。

9.2 图片与渲染

  • visualize 将 UIImage、CALayer、UIView 等导出到 Preview,检查内容与尺寸;配合 pviews 找到持有该 image 的 view。
  • 若界面未刷新,可尝试 caflush 强制 Core Animation 刷新。

9.3 断点与数据

  • 对「谁调用了某方法」不清晰时,用 bmessage 在该方法上设断点,运行到断点后看 btpinvocation(x86)等。
  • 对 NSURLRequest 用 pcurl 转为 curl 在终端重放;对 NSDictionary/NSArray 用 pjson 查看结构。

9.4 官方文档与资源导读

资源 链接 说明
Chisel 仓库 GitHub facebook/chisel 源码、README、CONTRIBUTING、安装与自定义命令
命令列表 Chisel Wiki 各命令的 Syntax、Arguments、Options 与实现文件
LLDB 与 Chisel 综述 Dancing in the Debugger — A Waltz with LLDB(objc.io #19) Ari Grant 撰文,理解 LLDB 与 Chisel 的配合 [2][7]
LLDB Python API LLDB Python API SB API、自定义命令接口
LLDB 自定义命令教程 Writing Custom Commands 官方扩展 LLDB 的教程

9.5 注意事项

  • Chisel 命令依赖当前暂停的 target 与 frame;若未暂停或 target 不对,部分命令会失败。
  • raw-input:多数命令的最后一个参数可直接写表达式(如 view 地址或类名),无需用引号包裹整条表达式;详见各命令 help
  • 真机调试时,visualize 等需要将数据从设备传回 Mac,大图或复杂层级可能略慢。

十、与其它调试工具的对比

维度 Chisel 纯 LLDB (po/bt/expr) Lookin / Reveal
形态 LLDB 命令集合(Python) 调试器内置命令与表达式 独立 Mac 应用 + App 内/网络
集成 配置 ~/.lldbinit 即可,无需改工程 Lookin 需集成 LookinServer;Reveal 需 SDK 或 Loader
视图层级 pviews/pvc 文本输出;fv + border 等辅助 需手写 po 与递归表达式 图形化 2D/3D 树与属性面板
可视化 visualize 在 Preview 中看图/view 在 Lookin/Reveal 内直接看
断点/监视 bmessage、wivar 等 breakpoint set、watchpoint 等需手写 不提供
适用场景 断点调试时快速查层级、改显示、下断点、看数据 通用底层调试 专注 UI 结构审查与属性修改

Chisel 与 LLDB 内置能力互补:在保持「断点 + 控制台」工作流的前提下,用少量命令完成视图、VC、约束、请求等常见调试任务;与 Lookin/Reveal 相比,无需改工程、无需额外进程,但视图展示为文本与简单边框/遮罩,而非完整图形化树 [1][2][3]。


参考文献

[1] 掘金等. LLDB 命令库 Chisel 介绍(Facebook、Python、SB API、与 Derek Selander 对比).
[2] Facebook. Chisel. GitHub. github.com/facebook/ch…
[3] 西门桃桃. LLDB;LearnLLDB 等. Chisel 命令用法总结.
[4] LLDB. Python APIWriting Custom CommandsImplementing Standalone Scripts. lldb.llvm.org/python_api.…lldb.llvm.org/use/tutoria…
[5] LLDB. Scripting Bridge API. lldb.llvm.org/resources/s…
[6] Facebook. Chisel Wiki (Commands). github.com/facebook/ch…
[7] objc.io. Dancing in the Debugger — A Waltz with LLDB (Ari Grant). Issue 19. www.objc.io/issue-19/ll…

02-Debug调试@网络-Wireshark网络抓包工具:从原理到实践

Wireshark 网络抓包工具:从原理到实践

📋 目录


一、概述与历史演进

1.1 工具简介

Wireshark 是一款开源的网络协议分析器(Network Protocol Analyzer),支持实时抓包(Live Capture)离线分析(Offline Analysis),可对数百种协议进行深度解析(Deep Inspection),运行于 Windows、Linux、macOS 等平台,被业界与教育机构广泛用于网络排障、安全分析、协议学习与性能调优 [1][2]。

与 Charles、Fiddler 等应用层代理不同,Wireshark 工作在网卡/驱动层,可捕获本机及经本机转发的原始报文(含二层以太网帧、IP、TCP/UDP 及各类应用层协议),不依赖应用配置代理,适用于全栈协议分析与非 HTTP(S) 流量 [3]。

1.2 历史与版本脉络

时期 事件
1997 年底 Gerald Combs 为解决工作中的网络问题并学习网络知识,开始编写 Ethereal(Wireshark 前身)[1][4]
1998 年 7 月 Ethereal 0.2.0 首次发布;Gilbert Ramirez、Guy Harris、Richard Sharpe 等贡献底层解析器与协议支持 [4]
2006 年 项目迁移基础设施并更名为 Wireshark [1][4]
2008 年 Wireshark 1.0 发布,标志着「最低可用功能」完成;首届 SharkFest 开发者与用户大会举办 [4]
2015 年 Wireshark 2.0 发布,采用全新 UI [4]
2023 年 项目由 Wireshark Foundation(美国 501(c)(3) 非营利组织)接管,负责基础设施、SharkFest 与网络教育推广 [4]

社区贡献模式以「所需协议驱动」为主:开发者复制现有解析器、实现新协议后回馈上游,使 Wireshark 支持的协议数量持续增长(如 4.x 版本已支持数千种协议、数十万字段)[1][2][5]。

1.3 典型应用场景

  • 网络排障:定位连接超时、丢包、重传、RST、DNS 解析失败等,结合协议栈与时间轴分析根因。
  • 协议学习与逆向:查看真实报文结构、字段含义、状态机行为(如 TCP 握手/挥手、TLS 握手)。
  • 安全与取证:检测异常流量、分析攻击载荷、配合 TLS 密钥日志解密 HTTPS 以审计内容(需合规授权)。
  • 性能分析:统计往返时延、重传率、吞吐量,配合 IO 图形化与专家信息系统(Expert Info)。
  • 嵌入式与物联网:抓取串口/蓝牙/BLE 等经适配器转换后的报文,或配合远程抓包(SSH、rpcapd)分析设备侧流量。

二、核心原理与架构

2.1 抓包在 OS 中的位置

抓包需要网卡驱动或内核模块将流经网卡的报文复制一份交给用户态。在 Unix/Linux/macOS 上,Wireshark 使用 libpcap:应用通过 libpcap 打开设备或文件,由 libpcap 与内核交互(如 Linux 的 PF_PACKET、BPF 过滤器),把满足条件的报文拷贝到用户空间 [6][7]。在 Windows 上,早期依赖 WinPcap(基于 libpcap 1.0.0,支持至 Windows 8,已停止维护);现代 Wireshark(3.0+)默认使用 Npcap:由 Nmap 项目维护,采用 NDIS 6 Light-Weight Filter 驱动,支持环回(loopback)抓包、原始 802.11、x86/x64/ARM,并随 Wireshark 安装包分发;相比 WinPcap 性能与安全性更优 [6][8]。

flowchart TB
    subgraph 用户态
        W[Wireshark / tshark]
        L[libpcap / Npcap]
    end
    subgraph 内核
        K[内核网络栈 / NDIS]
        D[抓包驱动]
    end
    subgraph 硬件
        N[网卡]
    end
    N --> K
    K --> D
    D --> L
    L --> W

2.2 抓包过滤器与显示过滤器的分工

  • 抓包过滤器(Capture Filter):在抓包前由驱动/内核或 libpcap 应用,只将符合条件的报文写入捕获文件或交给 Wireshark,未匹配的报文直接丢弃。语法为 Berkeley Packet Filter (BPF),与 tcpdump、WinDump 等一致;抓包过程中不可更改 [5][9]。
  • 显示过滤器(Display Filter):在已抓取的报文上做二次过滤,仅影响界面展示与统计,不改变捕获文件内容;可随时修改,基于 Wireshark 自有的字段与协议树 [5][10]。

因此:抓包过滤器用于减负与聚焦(如只抓某主机或某端口),在抓包前设置且抓包过程中不可修改,可减少落盘与内存占用;显示过滤器用于分析时的精筛(如只看 HTTP 请求、某状态码、某字段值),不改变捕获文件内容,仅隐藏包列表中的报文,可随时修改。二者语法不同:例如「某主机 Telnet」抓包过滤写 tcp port 23 and host 10.0.0.5,显示过滤写 tcp.port == 23 and ip.addr == 10.0.0.5 [9][17][18]。

2.3 协议解析(Dissection)与协议树

每个报文进入 Wireshark 后,由解析器(Dissector)按协议栈逐层解析:先由 Frame 解析器处理捕获元数据(时间戳、长度等),再依次调用数据链路层(如 Ethernet)、网络层(IP/ARP)、传输层(TCP/UDP)、应用层(HTTP、TLS、DNS 等)解析器,形成协议树。解析器可内置或通过插件加载;支持协议与字段的完整列表可通过「View → Internals → Supported Protocols」查看,显示过滤器可基于任意已注册字段 [5][11]。


三、抓包过滤器(Capture Filter)与 BPF

3.1 BPF 语法概述(官方语法 [9][12])

抓包过滤器采用 libpcap 过滤器语言(即 BPF),与 tcpdump、WinDump 等使用同一语法。形式为若干原语(primitive) 通过 and / or 连接,并可加 not

[not] primitive [and|or [not] primitive ...]

原语限定符(qualifier) + ID 组成。根据 pcap-filter man pageWireshark User's Guide §4.10,常见原语包括:

原语 含义 示例
[src|dst] host 按主机 IP 或主机名过滤 host 10.0.0.5src host 192.168.1.1;不写 src/dst 时表示源或目的任一匹配即可
ether [src|dst] host 按以太网(MAC)地址过滤 ether host aa:bb:cc:dd:ee:ff
gateway host 以 host 为网关的报文(以太网源/目的为 host,但 IP 源/目的不是 host) gateway 192.168.1.1
[src|dst] net [mask|len] 按网络号过滤,可写掩码或 CIDR 长度 net 192.168.0.0/24net 192.168.0.0 mask 255.255.255.0
[tcp|udp] [src|dst] port 按 TCP/UDP 端口过滤;tcp/udp 须在 src/dst 前 tcp port 80udp dst port 53
portrange 端口范围(libpcap 0.9.1+) tcp portrange 1501-1549
less | greater length 按报文长度 ≤ 或 ≥ 某值 greater 128less 64
ip | ether proto 按 IP 或以太网层协议类型过滤 ip proto 6(TCP)、ether proto 0x888e(EAPOL)
ether | ip broadcast | multicast 广播或组播 not broadcast and not multicast
relop 按字节或字节范围选择(复杂表达式) 见 pcap-filter man page

注意:抓包过滤器不是显示过滤器;前者在抓包前应用、语法更受限,后者在已抓包上过滤、可随时修改 [17]。

3.2 常用抓包过滤器示例(官方与 Wiki [9][12][17])

host 172.18.5.4                    # 与某 IP 双向流量
src host 192.168.1.1 / dst host 192.168.1.1   # 仅源或仅目的
net 192.168.0.0/24                 # 某网段;或 net 192.168.0.0 mask 255.255.255.0
src net 192.168.0.0/24             # 源网段
tcp port 23 and host 10.0.0.5      # 发往/来自 10.0.0.5 的 Telnet
tcp port 23 and not src host 10.0.0.5  # Telnet 且源非 10.0.0.5
port 53                            # DNS(TCP+UDP)
port not 53 and not arp             # 排除 DNS 与 ARP
tcp portrange 1501-1549             # TCP 端口区间
ether host aa:bb:cc:dd:ee:ff        # 以太网地址
ether proto 0x888e                  # 仅 EAPOL
ip                                # 仅 IPv4,可排除 ARP/STP 等
not broadcast and not multicast     # 仅单播
host www.example.com and not (port 80 or port 25)  # 排除 HTTP/SMTP
dst host ff02::1                   # IPv6 全节点组播(如 RA)

完整语法见 pcap-filter man pageWireshark Wiki CaptureFilters [9][12][17]。

3.3 抓包前设置与 Capture Options 界面(官方 [9])

  • 入口:菜单 Capture → Options…(或主工具栏对应项),打开 「Capture Options」 对话框 [19]。
  • 抓包过滤器输入位置:在 Input 标签页中,Interface 表格里每块网卡有一列 Capture Filter;可双击该列编辑该接口的 BPF;也可在表格上方「Capture filter for selected interfaces」为多块接口统一设置。设置完成后点击 Start 开始抓包。
  • Input 标签页:除 Capture Filter 外,还可配置每块接口的 Promiscuous(混杂模式)、Snaplen(每包捕获字节数)、Buffer(内核缓冲区大小)、Link-layer header type(链路层类型)、Monitor mode(无线 802.11 原始头,可能断网)等;悬停或展开接口可看到其 IPv4/IPv6 地址。
  • Output 标签页:可设置 Capture to a permanent file(保存路径、pcapng 默认格式)、Create a new file automatically(按时间/时长/大小/包数切换文件)、Ring buffer(多文件循环)。
  • Options 标签页Update list of packets in real-time(实时更新包列表)、Automatically scroll during live capture(自动滚动)、Name Resolution(解析 MAC/网络/传输层名称)、Stop capture automatically after…(按时长/大小/包数自动停止)。
  • Compile Selected BPFs:可查看当前 BPF 编译后的字节码,便于理解与排错。
  • 自动排除远程会话流量:当 Wireshark 在远程环境运行(如 SSH、X11、终端服务器)时,会检测环境变量并自动生成一条抓包过滤器以排除远程连接流量,减少无关包。检测变量包括:SSH_CONNECTIONSSH_CLIENTREMOTEHOSTDISPLAY(X11)、SESSIONNAME(终端服务器);Windows 下会检测是否在 Remote Desktop Services 环境 [9][17]。

Linux 提示:开启 BPF JIT 可加速过滤:echo 1 >/proc/sys/net/core/bpf_jit_enable(需 root);持久化可借助 sysfsutils [9]。


四、显示过滤器(Display Filter)

显示过滤器用于在已抓取的报文上精确控制显示哪些包;与抓包过滤器不同,可随时修改且基于协议树字段。完整语法见 User's Guide §6.4;协议与字段列表见 View → Internals → Supported ProtocolsDisplay Filter Reference [10][18][20]。

4.1 按协议/字段过滤与比较运算符(官方 [10])

  • 最简单:在显示过滤器栏输入协议名(如 tcp)或字段名(如 http.request),只显示包含该协议或该字段的报文。
  • 比较运算符User's Guide Table 6.6):
英文/别名 C 风格 含义 示例
eq / any_eq == 相等(多值字段时任一匹配即成立) ip.src == 10.0.0.5
ne / all_ne != 不相等(多值字段时全部不匹配才成立;Wireshark 3.6+ 语义) ip.src != 10.0.0.5
all_eq === 相等(多值字段时全部匹配才成立) ip.src === 10.0.0.5
any_ne !== 不相等(多值字段时任一不匹配即成立) ip.src !== 10.0.0.5
gt / lt / ge / le > < >= <= 大于/小于/大于等于/小于等于 frame.len > 100frame.len le 0x100
contains 协议、字段或切片包含某值 sip.To contains "a1762"udp contains 81:60:03
matches ~ 协议或文本字段匹配 Perl 兼容正则 http.host matches "acme\\.(org|com|net)"

注意ip.addrtcp.port 等为多值字段(同时含源与目的);== 表示「任一匹配」,要排除某地址应写 !(ip.addr == 10.43.54.65) 而非 ip.addr != 10.43.54.65(后者语义为「至少一个不等于」,易误用)[18]。

示例:

ip.addr == 192.168.0.1
ip.src == 10.0.0.5 and tcp.flags.fin
frame.len > 100
http.request.uri contains "api"
http.host matches "acme\.(org|com|net)"
tcp.flags.syn == 1
tcp.flags & 0x02

4.2 字段类型(官方 [10])

类型 说明与示例
无符号/有符号整数 可 8/16/24/32/64 位;可写十进制、八进制(0)、十六进制(0x)、二进制(0b)。例:ip.len le 1500ip.len le 0x5dc
布尔 1 或 True、0 或 False。字段存在即参与过滤;要匹配 SYN 置位须写 tcp.flags.syn == 1
以太网地址 6 字节,分隔符可为 :.-。例:eth.dst == ff:ff:ff:ff:ff:ff
IPv4 ip.addr == 192.168.0.1;支持 CIDR:ip.addr == 129.111.0.0/16
IPv6 ipv6.addr == ::1,也可匹配子网
字符串 双引号;可用 \xhh\ddd 转义。例:http.request.uri == "https://www.wireshark.org/";原始字符串前缀 rR 使反斜杠按字面处理
日期时间 字符串格式,如 frame.time == "Sep 26, 2004 23:18:04.954975"frame.time < "2022-01-01";小数秒可选,无时区后缀

4.3 逻辑、集合与算术

  • 逻辑Table 6.7):and(&&)、or(||)、not(!)、xor(^^);子序列用 []
  • 集合(Membership)field in { 值1, 值2 } 或范围 field in {443, 4430..4434};等价于多个 == 的 or,但集合对单字段求值,避免多值字段歧义。例:tcp.port in {80, 443, 8080}http.request.method in {"HEAD", "GET"}ip.addr in {10.0.0.5..10.0.0.9, 192.168.1.1..192.168.1.9}
  • 算术+-(减号前需空格)、*/%&(按位与)。例:frame.cap_len < { 14 + ip.hdr_len + tcp.hdr_len } 可找被截断的 TCP 选项。

4.4 切片、层操作符与 @ 操作符(官方 [10])

  • 切片(Slice):在字段或协议名后加 [范围]。范围格式:n:m(从偏移 n 起长度 m)、n-m(从 n 到 m inclusive)、:m(从头到 m)、n:(从 n 到结尾)、单字节 [n];负偏移表示从末尾算起。例:eth.src[0:3] == 00:00:83frame[-4:](最后 4 字节)、frame[-4:4] == 0.1.2.3。字符串切片按 UTF-8 码点边界。
  • 层操作符 #:限定到协议栈某一层。例:ip.addr#2 == 192.168.30.40 只匹配第二层 IP(如隧道内层);tcp.port#[2-4] 表示第 2、3、4 层。
  • @ 操作符:用 @ 前缀表示按原始字节比较,不经过解码。例:@browser.comment == 73:74:72:69:6e:67:... 用于有解码错误时的精确匹配。

4.5 函数(官方 [10])

函数 说明 示例
upper / lower 字符串大小写转换 lower(http.server) contains "apache"
len 字符串或字节长度(字节数) len(http.request.uri) > 100
count 帧中某字段出现次数 count(ip.addr) > 2
string 将字段转为字符串(可与 matches 等配合) string(frame.number) matches "[13579]$"
vals 将字段转为「值字符串」(若有定义) 用于与枚举名比较
dec / hex 整数转十进制/十六进制字符串
float / double 转为浮点;double 可处理时间(自 epoch 秒)
max / min 参数中的最大/最小值 max(tcp.srcport, tcp.dstport) <= 1024
abs 绝对值

4.6 字段引用(Field References)

${proto.field} 表示当前选中报文中该字段的值,用于动态过滤。例:自当前包起前 5 分钟:frame.time_relative >= ${frame.time_relative} - 300;或 HTTP 且目的 IP 等于当前帧 DNS A 记录:http && ip.dst eq ${dns.a} [10]。

4.7 正则与多值字段注意点

  • matches 的字符串会先经 Wireshark 解析再交给 PCRE,转义可能需双重(如括号 \\();用原始字符串 r"..." 可减少问题 [10]。
  • 协议名歧义:如 fc 可能被解析为协议 Fibre Channel 或十六进制 0xFC;用 .fc 强制协议名、:fc 强制字节序列 [10]。
  • 协议更名:如 bootp → dhcp,旧名可能仍可用但会提示 deprecated;新写过滤器建议用新名 [10]。

五、关键概念图示与流程

5.1 从网卡到界面的数据流

flowchart LR
    subgraph 捕获
        A[网卡] --> B[驱动/Npcap]
        B --> C[BPF 抓包过滤]
        C --> D[捕获缓冲区/文件]
    end
    subgraph 解析与展示
        D --> E[Frame 解析器]
        E --> F[各层 Dissector]
        F --> G[协议树]
        G --> H[显示过滤器]
        H --> I[包列表/详情/字节]
    end

5.2 抓包过滤器 vs 显示过滤器

flowchart TD
    subgraph 抓包阶段
        P1[所有经过网卡的报文] --> CF{抓包过滤器 BPF}
        CF -->|匹配| P2[写入捕获]
        CF -->|不匹配| P3[丢弃]
    end
    subgraph 分析阶段
        P2 --> DF{显示过滤器}
        DF -->|匹配| Q1[列表中显示]
        DF -->|不匹配| Q2[隐藏,仍存在于文件]
    end

5.3 协议解析栈(概念)

flowchart TB
    F[Frame] --> E[Ethernet]
    E --> I[IP / ARP]
    I --> T[TCP / UDP / ICMP]
    T --> A[HTTP / TLS / DNS / ...]
    A --> B[应用数据]

六、应用场景与实战

6.1 HTTP/HTTPS 调试

  • HTTP:显示过滤 httphttp.requesthttp.response.code == 404;右键报文 → Follow → HTTP Stream 可查看完整请求/响应体 [13]。
  • HTTPS:默认仅能看到 TLS 握手与加密载荷。若需查看明文,需提供会话密钥:在浏览器或 curl 侧设置 SSLKEYLOGFILE 环境变量导出密钥日志,在 Wireshark 中 Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename 指向该文件,重新抓包或重放后即可解密(依赖 TLS 1.2 等支持密钥导出;PFS 场景下必须用密钥日志,仅私钥不足)[14][15]。

6.2 TLS 握手与证书问题

  • 过滤:tlsip.addr == 1.2.3.4 and tls,查看 Client Hello / Server Hello / Certificate / Alert 等。
  • 典型问题:版本或套件不匹配、证书链不完整、主机名不匹配、Alert 告警等,可在 Expert Info 与 TLS 解析树中定位 [14][16]。

6.3 连接与性能问题

  • TCP:过滤 tcp,关注 SYN/ACK/RST/FIN、重传、窗口;统计 → 往返时延、流图,辅助判断延迟与丢包。
  • DNS:过滤 dns,查看请求与响应、响应码与解析结果,排查解析失败或污染。

6.4 TLS 解密配置步骤(摘要)

  1. 导出密钥日志:在客户端(浏览器/curl)设置环境变量 SSLKEYLOGFILE 指向一可写文件;完成 TLS 会话后,该文件会包含 NSS 格式的会话密钥。
  2. Wireshark 配置:Edit → Preferences → Protocols → TLS → 在「(Pre)-Master-Secret log filename」中指定上述文件路径。
  3. 抓包或重放:重新建立 TLS 连接并抓包,或对已有 pcap 重新打开;若密钥匹配,应用层载荷会以明文显示在 TLS 解析树下。
  4. 限制:仅持有服务器私钥无法解密使用 ECDHE/DHE 的会话(PFS);必须依赖客户端导出的密钥日志 [14][15][16]。

6.5 企业与实践参考

  • Cisco 等厂商文档中常推荐使用 Wireshark 进行 TLS 与通用网络故障排查,并说明如何配合密钥日志解密 HTTPS [16]。
  • 实践中常采用「先抓包过滤缩小范围 + 再显示过滤精查 + Follow Stream / 统计 / 专家信息」的组合流程;大流量环境优先用 BPF 减少落盘与内存占用。

6.6 典型通讯场景抓包与数据包分析 SOP

以下针对 Socket TCP、Socket UDP、音视频直播、WebRTC P2P 等典型通讯场景,给出从抓包配置 → 显示过滤 → 关键字段解读 → 调试与排错的完整 SOP,便于按场景落地使用。


6.6.1 Socket TCP 抓包与分析 SOP

场景说明:基于 TCP 的 Socket 通讯(自定义协议、长连接、游戏/IM 等),需观察连接建立、数据传输、重传、挥手与 RST 等。

阶段 操作 说明
1. 抓包前配置 若已知对端 IP 或端口,在 Capture Options → Capture Filter 中设置 BPF,减少无关流量 例:host 192.168.1.100tcp port 9000tcp portrange 8000-8010;未知时可先不设过滤,抓包后用显示过滤器精查
2. 选择接口 选择实际收发流量的网卡(有线/无线/环回) 本机压测选 loopback;真机/远程选对应物理或虚拟接口
3. 开始抓包 启动抓包后,在客户端/服务端触发 TCP 连接与数据收发 建议在问题复现前开始抓,复现后尽快停止,便于定位时间窗口
4. 显示过滤 在显示过滤器栏输入表达式,精确定位目标流 常用:tcp.port == 9000ip.addr == 192.168.1.100tcp.stream eq 0(按流索引);组合示例:tcp and ip.addr == 192.168.1.100 and tcp.port == 9000
5. 定位单条连接 在包列表中选中该连接任意一包 → 右键 → Follow → TCP Stream 弹出窗口显示该连接重组后的双向数据(可看明文或十六进制);窗口内可切换「仅显示/仅请求/仅响应」与编码方式
6. 分析连接状态 查看 TCP 握手与挥手 握手:过滤 tcp.flags.syn == 1 and tcp.flags.ack == 0 找 SYN,再找对应 SYN+ACK、ACK;挥手:过滤 tcp.flags.fin == 1tcp.flags.rst == 1异常:大量 tcp.analysis.retransmissiontcp.analysis.fast_retransmission 表示重传,需结合 RTT 与丢包排查
7. 统计与 RTT Statistics → Flow GraphStatistics → Round-Trip Time Flow Graph 可看时序;RTT 可看往返时延分布;Statistics → Conversations → TCP 可看每条连接的字节数、包数,辅助判断是否有半开、僵死连接

关键字段与调试要点

  • tcp.flags:syn、ack、fin、rst、push 等;RST 表示连接被重置,需结合前后包分析是哪一端发起。
  • tcp.seq / tcp.ack:序列号与确认号,用于判断丢包、乱序与重传。
  • tcp.len: payload 长度;0 表示纯 ACK 或控制包。
  • tcp.window_size_value:接收窗口,过小可能限制吞吐。
  • Expert InfoAnalyze → Expert Information 可汇总重传、重复 ACK、零窗口等,便于快速定位问题。

常见问题排查

  • 连接超时/建连失败:过滤 SYN,看是否有 SYN 无 SYN+ACK(对端未响应或防火墙拦截),或 SYN+ACK 无 ACK(本机未回 ACK)。
  • 数据丢包/应用收不到:看是否有重传(tcp.analysis.retransmission)、对端 RST(tcp.flags.rst == 1)、或中间设备分片/MTU 问题(看 IP 分片与 ICMP 不可达)。
  • 连接被重置:过滤 tcp.flags.rst == 1,看 RST 来自哪一侧、在哪个 seq 之后,结合应用日志判断是服务端主动关闭、超时还是异常断开。

6.6.2 Socket UDP 抓包与分析 SOP

场景说明:基于 UDP 的 Socket 通讯(DNS、QUIC、游戏、音视频 RTP、自定义协议等),无连接状态,需按五元组或 payload 特征过滤。

阶段 操作 说明
1. 抓包前配置 若已知端口或主机,在 Capture Filter 中设置 BPF 例:udp port 53(DNS)、udp port 5000host 10.0.0.1 and udp;UDP 流量大时可加 udp 避免抓过多 TCP
2. 选择接口 同 TCP,选实际收发流量的接口 本机/容器/远程按需选择
3. 开始抓包 触发 UDP 收发后抓包 UDP 无握手,需在业务触发期间抓取
4. 显示过滤 按端口、IP、长度等过滤 常用:udp.port == 5000udp and ip.addr == 192.168.1.100udp.length > 100;若 Wireshark 解析了上层协议(如 DNS、RTP),可用 dnsrtp
5. 按流重组(若支持) 部分协议支持「Follow → UDP Stream」或按 RTP 重组 对裸 UDP 可右键 → Follow → UDP Stream 看该五元组下双向 payload;RTP 可用 Telephony → RTP → Stream Analysis
6. 分析 payload 查看 Packet Bytes 或解析后的应用层字段 UDP 无重传标识,需结合应用逻辑判断丢包;可统计同一目的端口包数/字节与时间间隔,判断发送频率与是否被丢弃

关键字段与调试要点

  • udp.srcport / udp.dstport:源/目的端口,区分服务与流。
  • udp.length:UDP 段总长度(含 8 字节头);大包需关注是否 IP 分片(ip.fragments)。
  • ip.addr:确认五元组,便于区分多路流。
  • 无连接状态:不能像 TCP 那样用「流」概念直接看握手;需通过时间序、端口、payload 模式关联请求与响应(若协议有请求/响应结构)。

常见问题排查

  • 收不到包:确认抓包接口正确、BPF 未过滤掉目标端口;对端是否真的发送(可在对端或中间设备抓包对比)。
  • 丢包:UDP 本身不保证可靠,Wireshark 只能看到「到达本机网卡」的包;若应用层发现丢包,可对比包序号(若协议带序号)或统计包数。
  • 分片:过滤 ip.fragmentsip.flags.mf,看是否有多片;分片丢失会导致重组失败,应用收不到完整报文。

6.6.3 音视频直播场景抓包与分析 SOP

场景说明:音视频直播涉及多种传输方式——基于 TCP 的 HTTP(HLS、HTTP-FLV、DASH 等)、基于 UDP 的 RTP/RTCP、RTSP 控制 + RTP 承载、以及 WebRTC(见 6.6.4)。此处覆盖 RTP/RTCP、RTSP 及 HTTP 直播拉流。

阶段 操作 说明
1. 抓包前配置 按协议类型选用 BPF,缩小范围 RTP/RTCPudp portrange 5000-6000 或已知端口;RTSPtcp port 554udp port 554HLS/HTTP-FLVtcp port 80 or tcp port 443,或先不过滤在显示层再筛
2. 开始抓包 在播放端开始拉流/播放的同时启动抓包 确保从「起播」或「卡顿/花屏发生前」开始,便于做时序与丢包分析
3. 显示过滤 按协议与端口过滤 RTPrtprtp.payload_type == 96(H.264 常见);RTCPrtcpRTSPrtspHLShttp.request.uri contains ".m3u8"http.request.uri contains ".ts"HTTP-FLVhttp.request.uri contains ".flv"
4. RTP 流分析 Telephony → RTP → RTP StreamsStatistics → Flow Graph RTP Streams 可列出所有 RTP 流,选中某流后可 Analyze;可看丢包数、抖动、 delta 等;Follow → RTP Stream 可看 payload 与解码尝试(若支持)
5. RTCP 分析 过滤 rtcp,查看 SR/RR、丢包率与抖动报告 RTCP 携带接收端统计(丢包、抖动),可与 RTP 侧对比,判断是网络丢包还是对端发送问题
6. RTSP 分析 过滤 rtsp,右键 Follow → TCP Stream(若 RTSP 走 TCP) 看 OPTIONS、DESCRIBE、SETUP、PLAY 等信令与 SDP;可确认媒体端口、编码格式与 URL
7. HTTP 直播(HLS/DASH/FLV) 过滤 http,按 URI 或 Host 筛 看 .m3u8/.mpd 请求与 200 响应、.ts/.m4s 分片请求顺序与状态码;Follow → HTTP Stream 看完整请求/响应;关注 4xx/5xx 与超时

关键字段与调试要点

  • RTPrtp.ssrcrtp.seqrtp.timestamprtp.payload_type;丢包会导致 seq 不连续或 RTCP 报告高丢包率。
  • RTCP:SR(Sender Report)含发送端 NTP/RTP 时间与包数/字节数;RR(Receiver Report)含丢包数、最高接收 seq、抖动。
  • RTSP:CSeq、Session、Transport(含端口与 RTP/RTCP 端口对)。
  • HTTP 直播:状态码、Content-Length、Range 请求;分片请求间隔与响应时间可辅助判断卡顿是否与拉流延迟有关。

常见问题排查

  • 花屏/卡顿:先看 RTP 或 HTTP 分片是否有丢包或重传;再看 RTCP RR 的丢包率与抖动;最后看应用层是否频繁重试或切换码率。
  • 无法起播:RTSP 检查 DESCRIBE/SETUP/PLAY 是否均 200、SDP 与 Transport 端口是否可用;HTTP 检查 m3u8/mpd 与首条分片是否 200、CDN 是否可达。
  • 延迟大:看 RTP 时间戳与接收时间差、HTTP 分片请求间隔;缓冲与 GOP 大小也会影响延迟,需结合播放器与服务器配置。

6.6.4 WebRTC P2P 场景抓包与分析 SOP

场景说明:WebRTC 包含 信令(多通过 HTTP/WebSocket)、媒体(SRTP/SRTCP over UDP)、以及 NAT 穿透用的 STUN/TURN。抓包可分析 ICE 候选、DTLS 握手、SRTP 流与信令交互;媒体内容为加密,解密需密钥(见下)。

阶段 操作 说明
1. 抓包前配置 建议先宽抓再显示过滤;若已知端口可收窄 常用 BPF:udp(STUN/RTP 多为 UDP)或 tcp port 443 or tcp port 80(信令);WebRTC 端口动态,常不事先过滤端口
2. 开始抓包 在浏览器或 App 中完成「加入房间/呼叫」至「建立音视频」全过程 从点击「开始」前即开始抓,便于捕获完整 ICE 与 DTLS
3. 显示过滤(信令) 信令多为 HTTPS/WSS httptls 过滤信令域名;若已配 SSLKEYLOGFILE 并解密 TLS,可看到 WebSocket 或 HTTP 上的 SDP/ICE 等
4. 显示过滤(STUN) STUN 用于 NAT 探测与保活 stunstun.type;可看 Binding Request/Response、XOR-MAPPED-ADDRESS(即 NAT 映射地址)
5. 显示过滤(DTLS) WebRTC 媒体使用 DTLS 协商密钥,再以 SRTP 传媒体 dtls;可看 Client Hello/Server Hello、Certificate、Finished;无法仅凭私钥解密 DTLS,需在端点导出 DTLS/SRTP 密钥(见下)
6. 显示过滤(RTP/媒体) 解密前仅能见 SRTP 密文;解密后可识别为 RTP 解密前:udp.port == 9xxx(媒体端口在 SDP 中);解密后:可用 rtp 过滤并做 RTP 流分析
7. 解密 WebRTC 媒体(可选) 在 Chrome/Chromium 中启用 SSL 日志,导出密钥供 Wireshark 解密 SRTP Chrome 启动参数加 --ssl-key-log-file=<path> 并指定路径;Wireshark:Edit → Preferences → Protocols → TLS,在 (Pre)-Master-Secret log filename 填该路径;部分版本需在 Protocols → RTP 中启用「Decrypt SRTP」并依赖 DTLS 密钥;Chrome 的 NSS 格式密钥日志对 DTLS 有效,解密后可见 RTP 流

关键字段与调试要点

  • STUNstun.type(0x0001 Binding Req、0x0101 Binding Resp);stun.att.xor_mapped_address 为服务器看到的客户端公网地址,用于 ICE 候选。
  • SDP(在信令中)m=video/m=audioc=IN IP4a=rtcp-muxa=ice-ufrag/a=ice-pwda=fingerprint(DTLS);可确认媒体端口、ICE 与 DTLS 参数。
  • ICE:在信令中交换 candidate(host/srflx/relay);抓包可验证 candidate 是否与 STUN 响应一致、是否走 TURN(relay)。
  • DTLS:握手成功后才会有 SRTP;若 DTLS 失败,无媒体流或报错。

常见问题排查

  • P2P 不通、仅 TURN 能通:看 STUN Binding 是否有响应;若只有 relay candidate 可用,说明 NAT 对称或策略限制,需 TURN 中继。
  • 无音频/无视频:看信令中 SDP 是否含对应 m= 与 codec;看 DTLS 是否握手成功;看是否有对应端口的 UDP 包(防火墙/安全组可能拦媒体端口)。
  • 媒体解密失败:确认密钥日志在握手已配置、浏览器确实写入了该文件;Wireshark 需同时支持 TLS 密钥日志与 RTP 的 SRTP 解密(部分版本需在 RTP 偏好中勾选解密选项)。

WebRTC 抓包与解密流程简图

flowchart LR
    subgraph 抓包
        A[抓 UDP/TCP] --> B[显示过滤 STUN/DTLS/TLS]
        B --> C[信令看 SDP/ICE]
    end
    subgraph 解密
        D[浏览器 ssl-key-log] --> E[Wireshark TLS 密钥]
        E --> F[DTLS/SRTP 解密]
    end
    C --> G[分析候选与媒体端口]
    F --> G

6.6.5 场景与过滤器速查表
场景 建议抓包过滤(BPF) 常用显示过滤 分析入口
Socket TCP tcp port 端口host IP tcp.port == 端口tcp.stream eq 流索引 Follow TCP Stream、Expert Info、Flow Graph
Socket UDP udp port 端口host IP and udp udp.port == 端口udp.length > 0 Follow UDP Stream、Packet Bytes
音视频 RTP udp portrange 5000-6000 rtprtcprtp.payload_type == 96 Telephony → RTP Streams、RTP Stream Analysis
RTSP tcp port 554udp port 554 rtsp Follow TCP Stream(信令)、RTP 同音视频
HLS/HTTP 直播 tcp port 80 or tcp port 443 http.request.uri contains ".m3u8"http.request.uri contains ".ts" Follow HTTP Stream、看状态码与顺序
WebRTC 信令 tcp port 443 http/tls(解密后看 WSS/SDP) Follow HTTP Stream、看 SDP/ICE
WebRTC STUN/媒体 udp stundtlsrtp(解密后) STUN 看 XOR-MAPPED;RTP 同音视频

七、高级应用与扩展

7.1 官方文档与界面操作导读

内容 官方入口 说明
抓包 Capture → Options;User's Guide Ch.4 接口选择、Capture Filter、Output/Options 标签
抓包过滤语法 §4.10 Filtering while capturingWiki CaptureFilters BPF 原语、自动远程过滤
显示过滤语法 §6.4 Building Display Filter ExpressionsWiki DisplayFilters 比较/逻辑/切片/函数/字段引用
协议与字段列表 View → Internals → Supported ProtocolsDisplay Filter Reference 各协议可过滤字段名
跟随流 右键包 → Follow → TCP/TLS/HTTP Stream 见下
统计 Statistics 菜单 Conversations、Endpoints、Protocol Hierarchy、RTT、IO Graph
专家信息 Analyze → Expert Information 重传、重复 ACK、错误等汇总
开发/解析器 Developer's Guide 编写 Dissector、插件

7.2 跟随流(Follow Stream)

对 TCP、TLS、HTTP 等协议,右键报文选择 Follow → TCP Stream / TLS Stream / HTTP Stream,可在一个窗口中看到该连接上的重组应用数据(明文或解密后),便于分析单会话内容 [13]。

7.3 统计与 IO 图

  • Statistics:Conversations、Endpoints、Protocol Hierarchy、Round-Trip Time 等,用于宏观把握流量与延迟。
  • IO Graphs:按时间轴绘制报文数、字节数或自定义显示过滤器计数,便于观察突发、重传与趋势。

7.4 命令行 tshark

tshark 为 Wireshark 的命令行版本,使用相同的抓包与显示过滤器,适合脚本化与 CI 环境,例如:

tshark -i eth0 -f "tcp port 80" -w capture.pcapng
tshark -r capture.pcapng -Y "http.request" -T fields -e http.request.uri

7.5 自定义解析器与插件

新协议可通过编写 Dissector(C 或 Lua)注册到 Wireshark,实现 proto_register_XXXproto_reg_handoff_XXX,将协议与字段挂入协议树并参与显示过滤;详见 Wireshark Developer's Guide [11]。


八、伪代码与算法说明

8.1 抓包过滤器(BPF)求值概念

BPF 在内核或用户态对每个报文执行布尔表达式求值,仅当结果为真时交付给上层;原语通常对应「偏移 + 长度 + 掩码 + 比较」,例如「IPv4 且目的端口为 80」会编译为对帧内特定偏移处字节的测试。完整语义见 BPF 论文与 man page [12]。

8.2 显示过滤器求值

对每条已解析的报文,根据当前显示过滤器表达式遍历协议树:若字段存在且满足比较/逻辑/集合条件则保留显示,否则隐藏。字段类型与运算符需匹配(如整数用 ==、字符串用 contains/matches),类型不匹配会导致过滤无效或报错。多值字段(如 ip.addr 同时有源与目的)下,== 表示「任一匹配即成立」(any_eq),若需「全部匹配」可使用 ===(all_eq)[10]。

8.3 协议解析器调用顺序(概念)

对每个捕获的 frame:
  1. Frame dissector 写入时间戳、长度等元数据
  2. 根据链路层类型(如 Ethernet type)选择下一层解析器
  3. 递归:每个解析器解析本层头部,根据「下一层协议」字段(如 IP 的 protocol、TCP 的 port)调用子解析器
  4. 直至无子协议或数据结束,协议树与字段注册完成,供显示过滤器使用

参考文献

[1] Wireshark. About Wireshark. www.wireshark.org/about.html
[2] Wireshark. Wireshark User's Guide. www.wireshark.org/docs/wsug_h…
[3] 与 Charles 等代理工具的差异:Charles 为应用层代理,Wireshark 为底层抓包与协议解析。
[4] Wireshark. 1.4. A Brief History Of Wireshark. www.wireshark.org/docs/wsug_h…
[5] Wireshark. Filtering while capturing / Building Display Filter Expressions. User's Guide.
[6] Wireshark Wiki. libpcap. wiki.wireshark.org/libpcap
[7] Wireshark Wiki. Packet capture. wiki.wireshark.org/CaptureSetu…
[8] Npcap. Npcap: Windows Packet Capture Library & Driver. npcap.org/
[9] Wireshark. 4.10. Filtering while capturing. www.wireshark.org/docs/wsug_h…
[10] Wireshark. 6.4. Building Display Filter Expressions. www.wireshark.org/docs/wsug_h…
[11] Wireshark. Chapter 9. Packet Dissection. Developer's Guide. www.wireshark.org/docs/wsdg_h…
[12] tcpdump. pcap-filter man page. www.tcpdump.org/manpages/pc…
[13] Wireshark. Following Protocol Streams. User's Guide.
[14] Wireshark Wiki. TLS. wiki.wireshark.org/TLS
[15] SSLTrust / 第三方. Wireshark troubleshoot network SSL TLS.
[16] Cisco Community. Troubleshoot TLS using Wireshark. community.cisco.com/t5/security…
[17] Wireshark Wiki. CaptureFilters. wiki.wireshark.org/CaptureFilt…
[18] Wireshark Wiki. DisplayFilters. wiki.wireshark.org/DisplayFilt…
[19] Wireshark. 4.5. The "Capture Options" Dialog Box. User's Guide. www.wireshark.org/docs/wsug_h…
[20] Wireshark. Display Filter Reference. www.wireshark.org/docs/dfref/

01-Debug调试@网络-Charles网络抓包工具:从原理到实践

📋 目录


一、概述与历史演进

1.1 工具简介

Charles 是一款面向 Windows、macOS、LinuxWeb 调试代理(Web Debugging Proxy) 应用,由 Karl von Randow 创建,自 2002 年发布至今,由 XK72 维护 [1][2]。其核心能力包括:拦截、记录、修改与重放 HTTP/HTTPS 流量,支持带宽限速、断点调试、请求/响应重写与本地/远程映射,被广泛用于 Web 与移动端接口调试、前后端联调、弱网与异常场景测试 [1][3][4]。

1.2 历史与版本脉络

时期 事件
2002 Charles 首次发布,以 Java 实现,跨平台运行
3.x 引入 SSL Proxying(HTTPS 中间人解密)、各平台根证书安装流程
3.10+ Charles 根证书改为每台安装独立生成,需重新信任
3.11.4+ 支持 iOS App Transport Security (ATS)
2018 Charles for iOS 上架 App Store,支持在设备端抓包 [2]
2024–2025 4.6.x 稳定版;Charles 5.0 发布,新 UI、Apple Silicon/Windows on ARM、新会话格式 .chlz [2][5]

1.3 典型应用场景

  • 接口调试:查看请求 URL、Method、Header、Body 与响应状态、Body(JSON/XML 等),定位参数与返回错误。
  • HTTPS 明文查看:通过 SSL Proxying 将加密流量解密为明文,便于分析 API 内容。
  • 弱网与限速:Throttling 模拟带宽、延迟、丢包,验证加载、超时与降级逻辑。
  • Mock 与联调:Map Local / Map Remote / Rewrite 用本地或备用环境响应替代线上,或修改请求/响应内容。
  • 断点调试:在请求发出前或响应返回前暂停,修改后再放行或中止,用于测试异常与边界。

二、核心原理

2.1 代理与中间人

Charles 作为 HTTP/HTTPS 代理 运行在本机(默认端口 8888)。客户端(浏览器、App)将代理设置为 127.0.0.1:8888 后,发往目标的 HTTP(S) 请求会先发到 Charles,再由 Charles 转发到真实服务器;响应同样经 Charles 再回到客户端。因此 Charles 处于「客户端 ↔ Charles ↔ 服务端」的中间人位置,可完整查看与修改双向流量 [3][4]。

flowchart LR
    subgraph 客户端
        C[Browser / App]
    end
    subgraph 代理层
        P[Charles :8888]
    end
    subgraph 服务端
        S[Origin Server]
    end
    C -->|1. 请求| P
    P -->|2. 转发请求| S
    S -->|3. 响应| P
    P -->|4. 返回响应| C

2.2 数据流与记录

  • 记录:Charles 在转发前后记录请求与响应的 URL、方法、头、体;对 HTTPS 需开启 SSL Proxying 并安装根证书后才能解密并记录明文。
  • 结构视图:按 Host 或 Path 聚合展示会话,便于按接口查看;支持搜索、过滤与导出会话(.chls/.chlz)。
  • 证书与解密:HTTPS 解密依赖「客户端信任 Charles 根证书 + Charles 对指定 Host 启用 SSL Proxying」,详见第三节。

三、HTTPS 与 SSL 代理

3.1 为何 HTTPS 需要特殊处理

HTTPS 在 TCP 之上建立 TLS/SSL 加密通道,端到端加密后,代理若只做「透传」,无法看到应用层明文。Charles 要查看或修改内容,必须作为 TLS 中间人:与客户端建立一条 TLS 连接,与服务器建立另一条 TLS 连接,在中间以明文处理数据 [4][6]。

3.2 SSL Proxying(中间人)原理

Charles 的 SSL Proxying 本质是受控的「中间人」行为 [6][7]:

  1. 客户端 → Charles:客户端发起 HTTPS 请求到 host:443,因系统代理指向 Charles,TCP 连接实际建到 Charles;TLS 握手时,Charles 转发服务器真实证书,而是用 Charles 根证书签发一张「伪造」的站点证书(Subject 等与目标 host 匹配),下发给客户端。
  2. 客户端验证:客户端校验证书链。若未安装/信任 Charles 根证书,会报「不受信任的 CA」;安装并信任 Charles 根证书后,客户端认为该站点证书合法,与 Charles 完成 TLS 握手,后续应用层数据以 Charles 与客户端协商的密钥加密。
  3. Charles → 服务端:Charles 再以真实客户端身份向目标服务器发起 HTTPS,使用服务器真实证书完成 TLS,获得与服务器的明文通信。
  4. 结果:Charles 同时拥有「客户端 ↔ Charles」与「Charles ↔ 服务端」的解密能力,可记录、修改请求与响应后再转发。
    简要对应关系 [16]:客户端向服务器发起 HTTPS 请求 → Charles 拦截并伪装成客户端向服务器请求 → 服务器返回 CA 证书给「客户端」(实为 Charles)→ Charles 用本地根证书签发一张与目标站点匹配的证书,替换后发给客户端 → 客户端用 Charles 公钥加密对称密钥发给 Charles → Charles 用私钥解密得到对称密钥,再用服务器公钥加密发给服务器 → 此后 Charles 同时持有两端密钥,可解密、修改后再转发。关键前提:客户端必须信任 Charles 根证书,否则会报证书不受信任。
sequenceDiagram
    participant C as 客户端
    participant P as Charles
    participant S as 服务器

    C->>P: 建立连接 (代理)
    P->>C: 返回 Charles 签发的站点证书
    Note over C: 校验证书(需信任 Charles 根证书)
    C->>P: 加密请求 (客户端↔Charles 密钥)
    P->>S: 建立 TLS,获取服务器证书
    P->>S: 加密请求 (Charles↔服务器 密钥)
    S->>P: 加密响应
    P->>P: 解密并可选修改
    P->>C: 用客户端密钥加密后返回

3.3 配置要点(官方建议 [6][7][8])

  • 启用 SSL Proxying:Proxy → SSL Proxying Settings,勾选 Enable SSL Proxying,并在列表中加入要解密的主机(Host + Port,如 *:443api.example.com:443)。不在此列表中的 Host,Charles 对 HTTPS 只做透传,不解密。
  • 按地址启用 SSL Proxying(重要):若只做了全局「Enable SSL Proxying」却未把具体要抓的域名加入列表,该域名的 HTTPS 仍会以密文显示。操作方式二选一即可 [15][16]:
    • 方式一:在 Charles 会话列表(Structure/Sequence)中,右键目标 Host 或该域名下的某条请求 → SSL Proxying → Enable SSL Proxying,Charles 会自动将该 Host:443 加入 SSL Proxying 列表。
    • 方式二:Proxy → SSL Proxying Settings → Add,手动填写 Host(如 api.example.com)与 Port(如 443)。
      因此:具体的 HTTPS 抓包,必须在「被抓包的那个地址」上启用 SSL Proxying,否则无法看到明文。
  • 安装并信任根证书:Help → SSL Proxying → Install Charles Root Certificate(或 Save 后手动导入)。安装后需在系统/浏览器中将该证书设为受信任的根 CA(如 macOS 钥匙串中设为「始终信任」),否则客户端仍会报错。
  • 关闭解密:若不需要查看 HTTPS 明文,可在 Proxy Preferences 中关闭 SSL Proxying,Charles 将直接转发 TLS 流量,不进行解密与记录明文。

3.4 HTTPS 解密流程(算法级描述)

算法概念:Charles 作为 TLS 中间人

1. 客户端向 host:443 发起 TLS ClientHello(因系统代理,连接至 Charles)。
2. Charles 向真实服务器发起 TLS 连接,完成与服务器的握手,获得服务器证书与会话密钥 K2。
3. Charles 用本地 Charles 根证书的私钥,为「host」签发一张新证书 cert_fake,Subject 等与服务器证书一致或兼容。
4. Charles 向客户端返回 cert_fake,客户端用已信任的 Charles 根证书验证 cert_fake,通过则与 Charles 完成握手,得到客户端与 Charles 的会话密钥 K1。
5. 客户端发送的 HTTPS 请求用 K1 加密,Charles 用 K1 解密得到明文请求;Charles 用 K2 加密后转发给服务器。
6. 服务器响应用 K2 加密,Charles 用 K2 解密得到明文响应;Charles 可修改后再用 K1 加密返回客户端。
7. 因此 Charles 在「请求」与「响应」两段均具备明文读写能力,用于记录、Breakpoint 修改、Rewrite、Map Local 等。

3.5 证书与安全注意

  • Charles 根证书拥有对任意域签发证书的能力,一旦被信任,可被用于窃听或篡改 HTTPS。因此仅应在本机调试环境安装,不要在生产或个人敏感环境中长期信任。
  • 从 Charles 3.10 起,根证书为每台机器/每次安装独立生成,旧设备导出的根证书不能直接用于新环境,需在新环境重新安装并信任 [8]。

3.6 HTTPS 抓包配置处理(操作清单)

要成功对 HTTPS 流量进行抓包并看到明文,必须同时满足 Charles 端客户端/本机 两处配置;缺一不可。下面给出统一的操作清单与排查要点。

3.6.1 Charles 端必须完成的配置

顺序 操作 说明
打开 Proxy → SSL Proxying Settings 若未打开过,先进入该窗口
勾选 Enable SSL Proxying 不勾选则所有 HTTPS 仅透传,不解密
SSL Proxying Locations 列表中为要抓的域名添加条目 Host:填域名或 *(如 * 表示任意;api.example.com 表示仅该域名);Port:一般为 443。未在列表中的 Host 不会被解密,界面中仍显示为密文

按地址启用的两种方式(任选其一即可):

  • 方式 A(推荐):抓包时在会话列表(Structure / Sequence)中,右键目标 Host 或该域名下任意一条请求 → SSL Proxying → Enable SSL Proxying,Charles 会自动把该 Host:443 加入上述列表。
  • 方式 B:在 SSL Proxying Settings 窗口点击 Add,手动填写 HostPort(443);可用 * 表示任意主机。

3.6.2 客户端/本机必须完成的配置

抓包对象是,就要在的系统或环境中安装并信任 Charles 根证书:

抓包对象 证书安装与信任位置
本机浏览器 本机:Help → SSL Proxying → Install Charles Root Certificate;安装后在系统钥匙串/证书存储中将该证书设为受信任的根 CA(如 macOS 钥匙串访问 → 找到 Charles Proxy CA → 展开「信任」→ 使用此证书时:始终信任
iOS 真机 App/浏览器 手机:Safari 打开 chls.pro/ssl 安装描述文件;设置 → 通用 → 关于本机 → 证书信任设置 中对该 Charles 证书启用「完全信任
Android / HarmonyOS 设备 设备浏览器打开 chls.pro/ssl 安装证书;Android 7+ 自研 App 还需在工程中配置 Network Security Configuration 信任用户证书(见 §6.3)
iOS 模拟器 Charles:Help → SSL Proxying → Install Charles Root Certificate in iOS Simulators(需先关闭模拟器再执行)

未安装或未信任根证书时,客户端会报「证书不受信任」「连接不是私密连接」等错误,HTTPS 握手失败,无法抓包。

3.6.3 配置自检与常见问题

  • Charles 里能看到请求,但 Response 是乱码或显示为加密数据
    → 说明代理已生效,但未对该 Host 启用 SSL Proxying。按 3.6.1 在 SSL Proxying Locations 中添加该 Host:443,或右键该请求/Host → Enable SSL Proxying。

  • 客户端报证书错误、无法打开页面或 App 请求失败
    → 说明未在该客户端环境安装或信任 Charles 根证书。按 3.6.2 在对应设备/本机完成安装并在「证书信任设置」或系统凭据中设为信任。

  • *已添加 :443 仍有个别域名看不到明文
    → 少数情况下需确认该请求确实走了 Charles 代理(系统/App 代理指向 Charles);若为自研 App,检查是否开启了证书锁定(Certificate Pinning),若开启则需在调试版本中关闭或信任 Charles。

  • 换电脑或重装 Charles 后,手机/本机之前装的证书报错
    → Charles 3.10+ 根证书每台机器独立生成,需在当前运行 Charles 的电脑上重新执行「Install Charles Root Certificate on a Mobile Device」,并在设备上重新访问 chls.pro/ssl 安装新证书并信任。

3.6.4 配置处理流程简图

flowchart LR
    subgraph Charles端
        A1[Enable SSL Proxying]
        A2[Add Host:443 或 右键启用]
    end
    subgraph 客户端
        B1[安装 Charles 根证书]
        B2[信任该证书]
    end
    A1 --> A2
    B1 --> B2
    A2 --> C[HTTPS 可解密]
    B2 --> C

总结:HTTPS 抓包 = Charles 端对目标 Host 启用 SSL Proxying + 在抓包对象所在环境安装并信任 Charles 根证书;两者都做对后,即可在 Charles 中看到该域名的请求/响应明文并进行修改、断点等操作。


四、功能体系与工具链

4.1 功能总览

功能 说明 典型用途
Proxy 记录 自动记录经 Charles 的 HTTP(S) 请求与响应 日常抓包、接口排查
SSL Proxying 对指定 Host 解密 HTTPS,以明文展示与修改 查看/改写 API 内容
Breakpoints 按 URL 匹配在请求/响应前后暂停,可编辑后放行或中止 改参数、改响应、模拟失败
Map Local 将匹配的请求的响应替换为本地文件内容 用本地 JSON/HTML 做 Mock
Map Remote 将匹配的请求重定向到另一 Host/Path 将线上接口指到测试/预发
Rewrite 按规则修改请求/响应头或体(如替换字符串) 改 Host、Token、部分 JSON
Throttling 限制带宽、延迟、丢包、MTU 等 弱网、高延迟、不稳定网络
Compose / Repeat 手动编辑请求并发送、重放已有请求 接口重放、压力与回归

4.2 Breakpoints(断点)[9]

  • 作用:在请求发出前或响应返回前拦截,在 Charles 中查看并编辑内容,再选择 Execute(应用修改并继续)、Abort(中止并返回错误)或 Cancel(放弃修改并原样通过)。
  • 配置:Proxy → Breakpoint Settings,添加 Location,用协议、Host、端口、路径模式匹配 URL,支持通配符;每个断点可单独勾选「Request」「Response」或两者。
  • 流程概念
请求发出 → 若匹配 Request 断点 → 暂停 → 编辑 → Execute/Abort/Cancel
         → 若未匹配或已放行 → 转发到服务器
响应返回 → 若匹配 Response 断点 → 暂停 → 编辑 → Execute/Abort/Cancel
         → 若未匹配或已放行 → 返回客户端

4.3 Map Local 与 Map Remote [10][11][15]

  • Map Local:当请求的 URL 与设定规则匹配时,Charles 向服务器发请求,而是用本地文件内容作为响应体返回。适用于静态资源或 JSON 等;服务端动态逻辑不会执行。
    典型用法 [15]:① 用本地 JSON 文件充当某接口的返回值(如难以复现的首充、活动接口);② 用本地 JS 调试线上页面:将线上站点的 https://www.example.com/js/main.js 映射到本机 /Users/xxx/project/js/main.js,在浏览器直接访问线上 URL 即可看到本地修改在「线上环境」下的效果,适合本地环境不完整、必须依赖线上环境联调时。
  • Map Remote:将匹配的请求重定向到另一地址(可不同 Host/Path),例如把 https://api.prod.com/v1/* 映射到 https://api.test.com/v1/*,便于用测试环境替代生产。
    典型用法 [15]:本地开发时接口写为带域名的 https://www.example.com/api/getData(避免跨域),在 Charles 中配置「将 https://localhost/api/* 或本机某路径映射到 https://www.example.com/」,这样本地请求会实际转发到线上或测试环境;配合 Rewrite 注入登录 Cookie 后,可带登录态访问测试/线上接口。

4.4 Rewrite [11][15]

  • 按规则对请求或响应的 Header / Body 做字符串级替换(如键名、域名、Token)。与 Map Local/Remote 相比,不替换整份内容,只做局部修改;规则可基于 URL 匹配与通配符。
    典型用法 [15]:
    • 模拟登录态:在 Tools → Rewrite 中添加规则,对指定 URL 集合做 Add Header,将已登录环境下的 Cookie 填入请求头,即可在本地或无登录环境访问需登录的接口(Cookie 有过期时间,需定期更新)。
    • 解决响应乱码:部分响应使用 Brotli(br) 编码时,Charles 可能无法正确解码导致 Body 乱码;可在 Rewrite 中修改请求头 Accept-Encoding,去掉 br,让服务端返回 gzip/deflate,Charles 即可正常显示 JSON 等内容。
    • 其他:添加/修改请求参数、修改响应状态码或部分 JSON 字段等。

4.5 Throttling(带宽与弱网模拟)[4][12]

  • 作用:模拟慢速、高延迟、丢包等,使客户端「以为」处于弱网环境,用于验证加载、超时、错误提示与降级策略。
  • 启用:Proxy → Start Throttling(或快捷键);Proxy → Throttle Settings 配置。
  • 常见参数
    • Bandwidth:上行/下行带宽上限(如 256 kbps)。
    • Latency:往返延迟(如 500 ms)。
    • Reliability:丢包率。
    • MTU:最大传输单元。
  • 仅限部分 Host:在 Throttle Settings 中勾选「Only for selected hosts」并添加 Host,可只对指定接口限速,避免影响其他操作。

五、配置与使用场景

5.1 本机浏览器抓包(macOS / Windows)

  1. 启动 Charles,默认监听 8888。
  2. 系统代理:Charles 可自动设置系统 HTTP/HTTPS 代理为 127.0.0.1:8888(Proxy → macOS Proxy / Windows Proxy);关闭 Charles 时通常可恢复原设置。请求路径如下:
flowchart LR
    A[浏览器] -->|系统代理 127.0.0.1:8888| B[Charles]
    B --> C[目标服务器]
    C --> B
    B --> A
  1. HTTPS:按第三节安装并信任根证书,在 SSL Proxying Settings 中添加需解密的主机(如 *:443)。
  2. 浏览器访问任意 HTTP(S) 站点,在 Charles 的 Structure 或 Sequence 视图中查看会话。

5.2 仅抓部分域名或接口

  • SSL Proxying Settings:只添加需要解密的 Host,其他 HTTPS 不解密。
  • Proxy → Recording Settings:Include 中只填需要记录的 Host/Path,或 Exclude 排除无关域名,减少噪音。

5.3 Mock 与联调流程(概念)

1. 在 Map Local 中添加规则:例如 Host=api.example.com, Path=/v1/config → 本地文件 config.json
2. 客户端请求 https://api.example.com/v1/config → Charles 匹配规则 → 直接返回 config.json 内容
3. 或使用 Map Remote:将 api.example.com 映射到 api.test.com,请求被转发到测试环境
4. 或使用 Rewrite:将响应体中的 "env":"prod" 替换为 "env":"test"

5.4 弱网测试流程(概念)

1. Proxy → Throttle Settings,设置 Bandwidth / Latency / Reliability 等
2. 可选:Only for selected hosts,添加待测接口的 Host
3. Proxy → Start Throttling
4. 在 App 或页面中触发请求,观察加载时间、超时与错误处理
5. 测试结束后 Stop Throttling

六、各平台网络抓包配置 SOP

以下按 iOS、AOS(Android)、HOS(HarmonyOS)、WebAPP(浏览器/Web 端) 四类平台,给出 Charles 抓包的标准操作步骤(SOP),便于按平台查阅与排错。

6.1 通用前提与平台对照

项目 说明
网络 终端设备与运行 Charles 的电脑处于同一局域网(同一 Wi‑Fi 或同网段)。
端口 电脑防火墙放行 8888 入站,或临时关闭防火墙测试。
Charles 已启动并监听 8888;需抓 HTTPS 时在 Charles 内对目标 Host 启用 SSL Proxying(见 §3.3)。
平台 代理配置位置 证书安装方式 HTTPS 特别说明
iOS 设置 → Wi‑Fi → 当前网络 → 配置代理 浏览器打开 chls.pro/ssl → 安装描述文件 → 证书信任设置 需在「证书信任设置」中勾选 Charles
AOS (Android) 设置 → WLAN → 当前网络 → 代理 浏览器打开 chls.pro/ssl 安装;Android 7+ 自研 App 需 NSC 信任用户证书 见 §6.3
HOS (HarmonyOS) 设置 → WLAN → 当前网络 → 代理 同 AOS,浏览器 chls.pro/ssl;自研应用可能需网络安全配置 与 Android 类似,新系统可能需应用内代理/证书配置
WebAPP 系统代理或浏览器代理指向本机 127.0.0.1:8888 本机安装 Charles 根证书并信任(Help → Install Charles Root Certificate) 依赖系统/浏览器信任 Charles 根证书

6.2 iOS 抓包配置 SOP [8][13]

适用于 iPhone / iPad 真机iOS 模拟器

6.2.1 iOS 真机

步骤 操作 说明
1 电脑:Charles 已启动 → Help → SSL Proxying → Install Charles Root Certificate on a Mobile Device 弹出框内会显示代理地址(如 192.168.x.x:8888)与证书下载页 chls.pro/ssl,记下电脑 IP 与 8888 端口
2 手机:设置 → Wi‑Fi → 点击当前已连接网络右侧 (i) → 配置代理 → 选择 手动 服务器:填电脑 IP;端口:8888;保存
3 手机:用 Safari 打开 chls.pro/ssl 按提示下载并安装「Charles Proxy CA」描述文件,若提示需在设置中确认则前往「设置 → 已下载描述文件」安装
4 手机:设置 → 通用关于本机证书信任设置 找到 Charles Proxy CA,打开「完全信任」开关;未信任则 HTTPS 会报证书错误
5 Charles:Proxy → SSL Proxying Settings → 勾选 Enable,在列表中 Add 需解密的 Host(如 *:443api.xxx.com:443);或抓包时在会话列表右键目标 Host/请求 → SSL Proxying → Enable SSL Proxying 不在此列表的域名 HTTPS 仍为密文 [15][16]
6 在手机中打开要抓的 App 或 Safari,正常发起请求 Charles 的 Structure / Sequence 中应出现对应会话;HTTPS 需完成步骤 4、5 才能看到明文

注意:若 App 启用 ATS 且不信任用户安装的 CA,需在自研 App 的 Info.plist 中配置 ATS 例外或使用已信任 Charles 的调试包。

6.2.2 iOS 模拟器

步骤 操作 说明
1 关闭所有 iOS 模拟器实例 确保证书安装到当前模拟器运行时
2 Charles:Help → SSL Proxying → Install Charles Root Certificate in iOS Simulators 证书会安装到当前已安装的模拟器系统中
3 启动模拟器;在 macOS 上勾选 Proxy → macOS Proxy(或 Windows Proxy) 模拟器继承系统代理,流量走本机 Charles
4 在 Charles 的 SSL Proxying Settings 中为需抓取的 Host 启用 SSL Proxying 同真机步骤 5
5 在模拟器内打开 Safari 或目标 App 发起请求 抓包与真机一致

6.3 AOS(Android)抓包配置 SOP [8]

适用于 Android 手机 / 平板(含 Android 7+ 自研 App 的证书信任配置)。

步骤 操作 说明
1 电脑:Charles 已启动;Help → SSL Proxying → Install Charles Root Certificate on a Mobile Device,记下 电脑 IP8888 同 iOS
2 手机:设置 → WLAN(或 网络和互联网 → Wi‑Fi)→ 长按当前连接网络 → 修改网络 / 高级选项代理手动 主机名:电脑 IP;端口:8888;保存
3 手机:用系统浏览器打开 **chls.pro/ssl**,下载并安装 Charles 根证书 按系统提示完成「安装到凭据存储」等步骤
4 Android 7.0+ (N):系统默认不信任用户安装的 CA。若抓的是自研 App,需在工程中增加 Network Security Configuration,在 debug 下信任用户证书: 仅影响调试包,正式包可不引用或仅 debug 引用

res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <debug-overrides>
    <trust-anchors>
      <certificates src="user" />
      <certificates src="system" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

AndroidManifest.xml<application> 中增加:

android:networkSecurityConfig="@xml/network_security_config"

| 5 | Charles:Proxy → SSL Proxying Settings → 为需抓取的 Host 添加 *:443 或具体域名:443;或右键会话中的 Host → Enable SSL Proxying | 同 iOS | | 6 | 在手机中打开目标 App 或浏览器发起请求 | 若仍报证书错误,检查步骤 3、4 是否完成;第三方 App 无法改 NSC 时可能无法抓其 HTTPS |


6.4 HOS(HarmonyOS)抓包配置 SOP

适用于 华为 / 荣耀等搭载 HarmonyOS 的设备;代理与证书流程与 Android 类似,部分机型路径可能为「设置 → WLAN → 当前网络 → 代理」 [17]。

步骤 操作 说明
1 电脑:Charles 已启动;记下电脑 IP 与 8888 端口(Help → Install Charles Root Certificate on a Mobile Device 可查看) 同 iOS / AOS
2 手机:设置 → WLAN → 当前连接网络 → 代理(或 高级 / 更多)→ 选 手动 主机/服务器:电脑 IP;端口:8888
3 手机:浏览器打开 **chls.pro/ssl**,下载并安装 Charles 根证书 按系统提示安装到「凭据存储」等;部分 HarmonyOS 版本需在「设置 → 安全 → 加密与凭据」中确认用户证书已安装
4 自研 HarmonyOS 应用:若抓包时 HTTPS 仍报证书错误,需在应用内配置信任用户证书(视 SDK/API 版本而定;API 10+ 支持 usingProxycaPath 等)或使用系统提供的网络安全配置能力 与 AOS 的 NSC 思路类似,具体以华为开发者文档为准
5 Charles:SSL Proxying Settings 中为需解密的 Host 添加条目,或右键会话 → Enable SSL Proxying 同其他平台
6 在设备上打开目标 App 或浏览器发起请求 确认代理与证书均生效

6.5 WebAPP(浏览器 / Web 端)抓包配置 SOP

适用于 桌面浏览器(Chrome / Edge / Safari / Firefox) 以及 移动端浏览器 访问的 Web 页面;核心是「本机或当前设备使用 Charles 作为代理 + 信任 Charles 根证书」。

6.5.1 桌面端(本机浏览器)

步骤 操作 说明
1 电脑:启动 Charles,确认监听 8888 默认 Proxy → macOS Proxy / Windows Proxy 会设置系统代理为 127.0.0.1:8888
2 本机证书:Help → SSL Proxying → Install Charles Root Certificate;安装后在系统钥匙串(macOS)或证书管理(Windows)中将 Charles 根证书设为受信任的根 CA 否则浏览器访问 HTTPS 会报不安全
3 Charles:Proxy → SSL Proxying Settings → Enable SSL Proxying,Add 需解密的 Host(如 *:443)或抓包时右键目标 Host → Enable SSL Proxying 同移动端
4 在浏览器中访问目标 Web 或 WebAPP 流量经 Charles,Structure / Sequence 中可查看与修改请求/响应

仅对当前浏览器走代理(不改系统代理)时:安装浏览器代理扩展(如 SwitchyOmega),将 HTTP/HTTPS 代理指向 127.0.0.1:8888,并确保该浏览器信任本机已安装的 Charles 根证书。

6.5.2 移动端浏览器(手机/平板访问 Web)

  • iOS:按 §6.2.1 配置代理与证书后,在 Safari 或其他浏览器中访问的 H5/Web 请求会经 Charles。
  • AOS / HOS:按 §6.3 / §6.4 配置代理与证书后,在系统浏览器或 Chrome 等中访问的页面请求会经 Charles;若仅浏览器抓包、不涉及 App,通常只需系统代理 + 安装并信任 Charles 证书即可。

6.6 流程小结

flowchart TD
    A[设备与电脑同网 + Charles 已启动] --> B[设备端配置代理: 电脑IP:8888]
    B --> C[设备/本机安装并信任 Charles 根证书]
    C --> D[Charles 内对目标 Host 启用 SSL Proxying]
    D --> E[发起请求]
    E --> F[Charles 记录并可选解密/修改]

七、最佳实践与注意事项

  • 仅调试环境使用:Charles 根证书权限极大,只在开发/测试机器上安装并信任,用毕可关闭系统代理或停用 Charles。
  • 最小化 SSL Proxying 范围:只对需要查看的 Host 开启 SSL Proxying,避免不必要的解密与隐私风险。
  • 弱网:优先使用「Only for selected hosts」限速,减少对整机其他请求的影响。
  • 敏感数据:会话中可能包含 Token、Cookie、账号信息,保存 .chls/.chlz 或截图时注意脱敏与保管。
  • 合规:仅对自有或已授权的应用与接口抓包,勿用于未授权的第三方服务或用户数据。

延伸阅读(掘金系列)

以下文章从 iOS/Android 抓包、前端联调、HTTPS 原理与 Charles 功能教程等角度做了补充说明,可按需查阅。

序号 标题 链接 内容概要
01 iOS Charles 抓包 掘金 iOS 端 Charles 抓包配置与证书安装
02 Android 端 Charles 抓包 掘金 Android 代理与证书配置、高版本信任用户 CA
03 Charles 前端应用 掘金 Rewrite 模拟登录 Cookie、Map Remote/Local、去掉 br 解决乱码
04 史上最强 Charles 抓包 掘金 Charles 功能与抓包场景综合介绍
05 Charles 从入门到精通 掘金 入门到进阶功能与操作教程
06 Charles 功能介绍和使用教程 掘金 功能说明与使用步骤
07 HTTPS 与 Charles 掘金 HTTP/HTTPS 安全、TLS 握手与 Charles 中间人原理
08 为了学会 Charles,我拼命了 掘金 简介、iPhone/Chrome 配置、Repeat/Compose/Rewrite/Map 简介
09 最明白的 Charles 教程(一) 掘金 Charles 基础与界面说明
10 最明白的 Charles 教程(二) 掘金 抓包与过滤操作
11 最明白的 Charles 教程(三) 掘金 进阶功能与场景
12 最明白的 Charles 教程(四) 掘金 综合实战与排错

参考文献

[1] Charles Proxy. Overview / Features. www.charlesproxy.com/overview/fe…
[2] Wikipedia. Charles (software). en.wikipedia.org/wiki/Charle…
[3] Charles Proxy. Documentation – Welcome. www.charlesproxy.com/documentati…
[4] XK72. Charles Proxy. www.charlesproxy.com/
[5] Charles Proxy. Version History. www.charlesproxy.com/documentati…
[6] Charles Proxy. SSL Proxying. www.charlesproxy.com/documentati…
[7] Charles Proxy. SSL Certificates. www.charlesproxy.com/documentati…
[8] Charles Proxy. SSL Certificates – iOS / Android / Java / Chrome. 官方文档 Install Charles Root Certificate 各平台说明.
[9] Charles Proxy. Breakpoints Tool. www.charlesproxy.com/documentati…
[10] Charles Proxy. Map Remote. www.charlesproxy.com/documentati…
[11] Charles Proxy. Map Local;Stack Overflow. Charles Proxy Rewrite vs Map Local.
[12] Charles Proxy. Throttling;Donny Wals. Throttle network speeds for a specific host in Charles;Mobot. Charles Proxy for Network Throttling.
[13] Detroit Labs. A Guide To Charles Proxy for Mobile Development;Medium. Setting Up Charles Proxy with iOS Devices and Emulators;Charles. iOS Getting Started.
[14] CSDN / 技术博客. 使用 Charles 抓取 HTTPS 数据及原理分析(中间人、证书链).
[15] 掘金. charles 前端应用. juejin.cn/post/684490… Remote、Map Local 实战).
[16] 掘金. HTTPS 与 Charles为了学会 Charles,我拼命了. juejin.cn/post/684490… 握手与 Charles 证书替换、按地址启用 SSL Proxying).
[17] HarmonyOS 网络抓包与 Charles 代理证书配置(代理 + chls.pro/ssl + 证书信任);华为开发者文档 @ohos.net.http(API 10+ 代理与证书参数).

其它参考

02-编程范式和编程思想学习@iOS |【Effective Objective-C】精华导读

image.png

📋 目录


一、概述与定位

《Effective Objective-C 2.0: 52 Specific Ways to Write Better iOS and OS X Programs》(以下简称「本书」)由 Matt Galloway 撰写,2013 年由 Addison-Wesley Professional 出版,隶属 Effective Software Development Series(Scott Meyers 主编),与《Effective C++》《Effective Java》等同属「以条目化、可操作建议」提升代码质量的经典技术书 [1][2]。

1.1 目标读者与写作方式

  • 目标读者:具备 Objective-C 与 Cocoa/Cocoa Touch 基础的中高级开发者,不侧重语法入门,而侧重在既有知识基础上写出更安全、可维护、符合范式的代码 [2]。
  • 写作方式:全书分为 52 条(Item) 独立建议,每条聚焦一个具体问题或原则,可单独阅读;条目间有交叉引用,便于形成体系 [1]。

1.2 与「编程范式」的关系

本书所涉的编程范式涵盖:

  • 面向对象范式:对象、消息传递、继承与多态在 Objective-C 中的实现方式(动态类型、运行时)。
  • 内存管理范式:从手动引用计数(MRR)到自动引用计数(ARC)的演进,以及所有权与对象图思维。
  • 并发与异步范式:Block 闭包与 Grand Central Dispatch(GCD)所代表的「任务 + 队列」模型。
  • 接口与 API 设计范式:命名、不可变性、委托与协议、分类与扩展等 Cocoa 惯例。

下文从历史演进核心原理图示与算法应用场景四方面系统梳理本书内容,并引用权威文献与业界实践。本文档同时参考了掘金上的「《Effective Objective-C》干货三部曲」(概念篇、规范篇、技巧篇)[13][14][15],对部分条目的示例与归类做了补充。文档兼顾学术严谨性(概念定义、引用来源)与可读性(结构分条、图示与伪代码),便于既作速查又作体系化学习。


二、技术演进与历史脉络

2.1 Objective-C 与 Cocoa 的渊源

Objective-C 在 C 语言之上增加了单继承的面向对象动态消息传递(dynamic messaging)。对象收到「消息」后,由运行时根据**选择子(selector)**查找并执行对应方法实现;这种「发消息」而非「调函数」的模型,使得方法解析、转发、替换(如 method swizzling)均在运行时完成,构成本书所述「对象、消息与运行时」的基础 [3][4]。

2.2 内存管理范式的演进

阶段 时期 范式 说明
MRR 早期至 iOS 4 / Mac OS X 10.6 手动引用计数 开发者显式调用 retain / release / autorelease,所有权由命名约定(如 allocnewcopy 返回持有)约定 [5][6]
ARC iOS 5 / Mac OS X 10.7 起 自动引用计数 编译器在编译期插入合适的 retain/release,仍为引用计数语义,非追踪式 GC;循环引用需开发者用 __weak 等打破 [5][7]
GC 弃用 OS X Mountain Lion 起 垃圾回收在 OS X 上被弃用,macOS Sierra 后从运行时移除,ARC 成为官方推荐 [7]

要点:ARC 与 MRR 共享同一套所有权与引用计数概念;理解「谁拥有对象、何时释放」有助于写出 ARC 下仍正确的代码(尤其 Block、delegate、timer 等易产生循环引用的场景)[5][8]。

2.3 Block 与 GCD 的引入

  • Block:Apple 在 C、Objective-C、C++ 中引入的闭包语法,可捕获上下文变量并延迟执行,是回调、动画、GCD 任务的基础。本书强调 Block 的循环引用(block 捕获 self、self 又持有 block)及 weak–strong dance 的规范写法 [9][10]。
  • Grand Central Dispatch (GCD):基于队列的并发抽象,将任务(block)派发到串行/并发队列,由系统管理线程。与 performSelector: 相比,GCD 支持异步、取消语义与队列层次,成为 iOS/macOS 并发编程的主流范式 [2][11]。

2.4 内存管理范式演进(时间线)

时期 范式/事件
早期 Cocoa MRR:手动 retain / release / autorelease
iOS 5 / Mac OS X 10.7 (Xcode 4.2) ARC 完整支持,编译期插入引用计数调用
OS X Mountain Lion 起 垃圾回收(GC)弃用
macOS Sierra 起 GC 从运行时移除,ARC 为唯一推荐方式

三、全书结构与 52 条建议总览

本书共 7 章、52 条,下表给出每章主题与条目范围,便于按需查阅 [1][2]。

主题 条目 核心内容概要
1 熟悉 Objective-C 1–5 语言根源、头文件与导入、字面量语法、类型常量与枚举
2 对象、消息与运行时 6–14 属性与实例变量、相等性、类簇、关联对象、消息机制、方法转发、method swizzling、类对象
3 接口与 API 设计 15–22 命名、指定初始化器、description、不可变优先、命名一致性、私有方法、错误处理、NSCopying
4 协议与分类 23–28 委托模式、分段实现、分类前缀、分类中避免属性、类扩展、匿名对象
5 内存管理 29–36 引用计数、ARC、dealloc、异常安全、弱引用、autorelease 池、僵尸对象、retainCount
6 Block 与 GCD 37–46 Block 语法与 typedef、handler block、循环引用、dispatch 队列、GCD 与 performSelector、NSOperation、dispatch group、dispatch_once、当前队列
7 系统框架 47–52 框架使用、块枚举、桥接、NSCache、+load/+initialize、NSTimer

四、核心原理与精华条目

4.1 第一章:熟悉 Objective-C

  • 语言根源与运行期组件:Objective-C 采用消息结构,运行时才查找要执行的方法;运行期组件是与开发者代码链接的动态库,包含面向对象所需的数据结构与函数,更新运行期组件即可提升应用性能。对象分配在、指针在;不含 * 的变量可能用栈,结构体保存非对象类型 [13]。
  • 头文件与向前声明:在类的头文件中尽量少引用其他头文件;若仅需声明某类型为属性,使用 向前声明@class EOCEmployer;),在 .m 中再 #import,可减少编译时间并避免循环引用。继承或遵从协议时必须在头文件中引入对应头文件 [14]。
  • 字面量与装箱:使用 @""@[]@{}@() 等字面量可减少冗长代码并降低错误;字面量若含 nil 会立即抛异常,而 arrayWithObjects:nil 会截断,易埋坑。字面量创建的集合为不可变 [2][14]。
  • 常量与枚举:用 static const(编译单元内可见)或 extern const(对外公开)定义常量,避免 #define(无类型、易被改)。对外常量命名建议带类名前缀;枚举用 NS_ENUM / NS_OPTIONSswitch 中不要写 default,以便新增枚举成员时编译器提示未处理 [2][14][15]。

4.2 第二章:对象、消息与运行时

4.2.1 属性与实例变量

属性(@property)是编译器自动生成存取器与(可选)实例变量的语法糖。要点 [2][4]:

  • 读写语义strong(默认对象)、copy(如 NSString/Block 防外部修改)、weak(避免循环引用)、assign(非对象类型)。
  • 原子性atomic(默认)在存取时加锁,多数场景下 nonatomic 更高效且足够;若需线程安全,应结合更高级的同步手段。
  • 属性关键字小结copy 用于 NSString/Block 等需拷贝语义的类型;unsafe_unretained 类似 assign 但用于对象,对象释放后不会清空;在非 setter 中给属性赋值时也需遵循其语义(如 copy 属性在 init 里应对传入值 copy)[13]。

4.2.2 对象相等性与 isEqual / hash

  • 相等性:若逻辑上「相等」需自定义,应实现 isEqual:hashhash 在对象被放入集合(如 NSSet、NSDictionary key)时使用,相等对象必须有相同 hash,反之不要求;hash 应稳定、计算量小 [2]。
  • 类簇(Class Cluster):公开接口是抽象基类(如 NSString、NSArray),实际返回私有子类实例。自定义子类需继承簇的「抽象基类」并实现其工厂方法所依赖的初始器;直接比较类时要注意类簇的多种子类 [2][4]。

4.2.3 关联对象(Associated Objects)

运行时允许在不修改类定义的前提下,给对象关联键值对。常用于:给分类「添加」存储、给系统类绑定上下文数据。需注意键的唯一性与内存语义(如 OBJC_ASSOCIATION_RETAIN_NONATOMIC)[2][4]。

4.2.4 objc_msgSend 与消息查找

[someObject messageName:parameter] 在底层转为 C 函数调用:objc_msgSend(someObject, @selector(messageName:), parameter)。该函数在接收者所属类及父类链的方法列表中查找与选择子相符的 IMP;找到则执行并缓存到类的快速映射表,下次同消息更快;找不到则进入消息转发 [3][13]。

4.2.5 消息转发(Message Forwarding)

当对象收到无法识别的消息时,运行时在报错前会给予二次机会 [3][12][13]:

  1. 动态方法解析+resolveInstanceMethod: / +resolveClassMethod:,可为该类动态添加方法实现(如 class_addMethod);典型应用是 @dynamic 属性 + 内部字典存储(EOCAutoDictionary 模式)。
  2. 快速转发-forwardingTargetForSelector:,返回备援接收者,运行期将消息转给该对象。
  3. 完整转发-methodSignatureForSelector:-forwardInvocation:,将消息封装为 NSInvocation,可修改目标、参数或返回值,实现代理、多继承等。

应用:代理对象、惰性加载大型对象、将未识别消息转发到后备对象等 [12]。

4.2.6 类对象与类型查询

运行期用 objc_class 结构描述类(含 isa、super_class、methodLists、cache 等)。isMemberOfClass: 判断是否为某特定类的实例;isKindOfClass: 判断是否为某类或其派生类的实例。从集合取出对象后往往需做类型判断再调用方法,避免向错误类型发消息 [13]。

4.2.7 Method Swizzling

通过运行时交换两个方法的实现(IMP),从而在不修改原类源码的情况下「注入」或「替换」行为;常用于 AOP、调试、无埋点统计。注意:交换应在 +load 等单次执行路径执行,并考虑继承与多线程安全 [2][4]。

4.3 第三章:接口与 API 设计

  • 命名:方法名应语义清晰、读起来像句子,如 initWithWidth:height: 优于 initWithSize::;布尔 getter 用 is/has 前缀(如 isEqualToString:hasPrefix:)。每个冒号左侧的方法部分最好与右侧参数名对应 [14]。
  • 指定初始化器(Designated Initializer):选定全能初始化方法(参数最多的那个),其他 init 及子类 init 均委托到它;子类若有自己的全能初始化器,需覆写父类的全能初始化器并转调自己的,避免用父类 init 产生非法状态(如 Square 覆写 initWithWidth:andHeight: 转调 initWithDimension:)。实现 initWithCoder: 时也应调用超类对应方法 [2][15]。
  • description:覆写 description 返回类名、地址与关键属性(或字典形式),便于调试时在控制台看到有意义信息 [15]。
  • 不可变优先:对外属性设为 readonly,在类扩展中改为 readwrite;集合对外暴露不可变类型(如 NSSet *friends),内部用 NSMutableSet,通过定制 addFriend:/removeFriend: 等接口修改,getter 返回 [_internalFriends copy],避免外部直接改底层数据 [14]。
  • 私有方法前缀:实现文件中的私有方法加前缀(如 p_privateMethod),便于与公共方法区分;不要用单下划线(与 Apple API 冲突)[14]。
  • NSError:用 NSError 封装错误域(domain)、错误码(code)、用户信息(userInfo);作为「输出参数」传递时用 (NSError **)error,调用方检查 *error;可定义 extern NSString *const EOCErrorDomainNS_ENUM 错误码 [13]。
  • NSCopying:实现 copyWithZone:(及可变版的 mutableCopyWithZone:);Foundation 集合默认浅拷贝,深拷贝需自己遍历并 copyItems:YES 或实现 deepCopy [13][15]。

4.4 第四章:协议与分类

  • 委托(Delegate):用 @protocol 定义回调接口,属性用 weak 避免循环引用;delegate 可选方法用 @optional,调用前先判断 delegate 是否存在再 respondsToSelector:,例如 if (_delegate && [_delegate respondsToSelector:@selector(...)]) { ... } [14]。委托模式与数据源模式:信息从类流向委托者 vs 从数据源流向类。
  • 分类(Category):按逻辑将类方法分散到多个分类(如 Friendship、Work、Play),便于管理;可为「私有方法」建 Private 分类。勿在分类中声明属性(仅 class-continuation 可增加实例变量);为第三方或系统类加分类时,分类名与方法名均加前缀(如 ABC_HTTP),避免覆盖原实现 [2][14]。
  • 类扩展(Class Continuation):在 .m 中的匿名分类,可遵循协议而不暴露、将只读属性改为读写、增加实例变量 [14]。
  • 匿名对象id<EOCDelegate> 表示「遵从某协议的对象」而非「某类的实例」,用作 delegate 属性或方法参数(如 setObject:forKey:(id<NSCopying>)key),强调协议契约 [15]。

4.5 第五章:内存管理

4.5.1 引用计数与 ARC

  • 所有权:谁创建(alloc/new/copy/mutableCopy)、谁持有;谁不再需要,谁释放(在 ARC 下由编译器插入)[5][6]。
  • ARC 规则:不能显式调用 retain/release/autorelease;不能使用 retainCount(仅调试用且不可靠);Core Foundation 与 Objective-C 对象混用需注意桥接(__bridge / __bridge_retained / __bridge_transfer)[5][7]。

4.5.2 循环引用与 weak

典型循环:对象 A 强引用 B,B 强引用 A(或通过 block/delegate 形成环)。解决:将其中一侧改为 weak(如 delegate、block 内对 self 的引用)[8][10]。

4.5.3 其他要点

  • dealloc:在 ARC 下仅用于释放 Core Foundation 对象(如 CFRelease)、移除 KVO/通知(如 removeObserver:self)等;不要在 dealloc 中调用其他方法或属性存取器,可能触发异步回调或 KVO 导致使用已释放对象 [2][5][14]。
  • autorelease 池:对象 autorelease 后在下一次事件循环清空池时才会 release;在循环中创建大量临时对象时,在循环内使用 @autoreleasepool { ... }降低内存峰值 [5][8][15]。
  • 僵尸对象(Zombie):开启后,已释放对象的 isa 被改为指向特殊僵尸类,不回收内存、不覆写;再次向该对象发消息会抛出异常并描述原对象与消息,便于排查野指针 [2][6][15]。
  • retainCount:不应使用;ARC 下已废弃,且其返回值只能反映某一时刻的计数,无法反映自动释放池等后续变化 [14]。
  • 异常安全:MRC 下 try 中 retain 的对象若在 release 前抛异常会泄漏,应在 @finally 中 release;ARC 下需 -fobjc-arc-exceptions 才会在异常路径插入清理代码,会增大体积并影响性能 [15]。

4.6 第六章:Block 与 GCD

4.6.1 Block 类型与循环引用

  • Block 三种类型栈 block(定义时在栈上,离开作用域可能失效);堆 block(对栈 block 发 copy 后拷贝到堆,带引用计数);全局 block(不捕获外部变量时可为全局块)。需长期持有的 block 应 copy 到堆 [13][15]。
  • Block 会捕获其使用的局部变量;对对象默认是强引用。若 block 被当前对象持有(如属性、成员变量),且 block 内又使用了 self_ivar(等价于 self),则形成循环引用 [9][10]。
  • 规范写法:在 block 外先 __weak typeof(self) weakSelf = self;,在 block 内使用 weakSelf;若需在 block 执行过程中保证 self 存活,可在 block 内再 __strong typeof(weakSelf) strongSelf = weakSelf; 后使用 strongSelf(weak–strong dance)。也可在 block 末尾将持有 block 的成员置为 nil 以打破环(如 completion 内 _networkFetcher = nil)[10][15]。
  • handler block 与 typedef:用 completion handler 块替代 delegate 回调可让「发起请求」与「处理结果」写在一起;对常用块签名使用 typedef void(^EOCCompletionHandler)(NSData *data, NSError *error); 便于复用与修改 [15]。

4.6.2 GCD 队列与任务

  • 队列类型:串行队列(同一时间只执行一个任务)、并发队列(可多任务并发);主队列(main queue)为串行,用于 UI 更新。不要使用 dispatch_get_current_queue 判断「当前队列」,因队列有层级关系,结果不可靠 [11][14]。
  • 常用 APIdispatch_asyncdispatch_syncdispatch_afterdispatch_once(单例等)、dispatch_group_async + dispatch_group_notify(多任务完成后汇总)[2][11][15]。
  • 同步与锁:可用串行队列统一读写(读写都 dispatch_sync 到同一队列);或并发队列 + dispatch_barrier_async 写、普通 async/sync 读,保证写互斥、读可并发 [15]。
  • 与 performSelector 对比:GCD 不依赖 selector、可传多参数与返回值;延后执行用 dispatch_after,回主线程用 dispatch_async(main_queue, ^{ ... }),替代 performSelector:withObject:afterDelay:performSelectorOnMainThread: [2][15]。
  • NSOperation 适用场景:需取消任务、设置依赖、指定优先级或 KVO 监听 isFinished/isCancelled 时,用 NSOperationQueue 更合适;GCD 为「fire and forget」[15]。

4.7 第七章:系统框架

  • 块枚举:使用 enumerateObjectsUsingBlock: 可获下标、键值对及 *stop 提前终止;比 for 循环简洁,且可修改块签名以做类型检查。遍历 Dictionary/Set 时无需先 allKeys/allObjects 再遍历,减少临时数组 [2][14]。
  • NSCache:线程安全、不拷贝 key(保留)、内存紧张时自动删减(含「最久未用」策略);可设置 countLimittotalCostLimit。与 NSPurgeableData 配合时,访问前 beginContentAccess、用毕 endContentAccess,便于系统回收内存 [2][14]。
  • +load 与 +initialize+load 在类/分类加入运行期时各调用一次,尽量不要在 load 里调用其他类(加载顺序未定义)。+initialize 在类首次收到消息前调用,子类未实现会调用父类,因此需判断 if (self == [EOCBaseClass class]) 再执行逻辑,避免子类触发父类 initialize [2][4][14]。
  • NSTimer:会强引用 target,若 target 是 self 且 self 又持有 timer,则形成保留环;dealloc 中 invalidate 可能无法执行(因环未打破)。推荐:用 NSTimer 的 block 封装(Category 提供 eoc_scheduledTimerWithTimeInterval:block:repeats:,timer 的 target 为类对象,userInfo 存 [block copy]),在 block 内用 weakSelf/strongSelf 调用业务逻辑,这样 self 释放后 block 中 weakSelf 为 nil,或 dealloc 中 invalidate 即可打破环 [2][14]。
  • 无缝桥接:Foundation 与 Core Foundation 间用 __bridge(不转移所有权)、__bridge_retained__bridge_transfer 转换;创建 CF 集合时可指定回调以自定义内存管理语义,再桥接到 OC 使用 [15]。

五、关键概念图示与流程

5.1 消息发送与查找流程

Objective-C 中 [obj message] 在运行时转化为 objc_msgSend(obj, selector, ...),随后在类的方法表及父类链中查找 IMP;若未找到,进入消息转发 [3][4]。

flowchart TD
    A[obj 收到消息] --> B{在类及父类中查找 IMP}
    B -->|找到| C[调用 IMP]
    B -->|未找到| D[动态方法解析 resolveInstanceMethod:]
    D --> E{添加方法?}
    E -->|是| C
    E -->|否| F[forwardingTargetForSelector:]
    F --> G{返回非 nil 目标?}
    G -->|是| H[向目标转发消息]
    G -->|否| I[methodSignatureForSelector: + forwardInvocation:]
    I --> J[开发者可转发到其他对象或处理]

5.2 消息转发(forwardInvocation)概念

当使用 forwardInvocation: 时,运行时将原始消息封装为 NSInvocation,传给接收者;接收者可修改目标、参数或返回值,实现「代理」「多继承」等 [12]。

sequenceDiagram
    participant C as 调用方
    participant R as 接收者
    participant T as 转发目标

    C->>R: 发送未知消息
    R->>R: methodSignatureForSelector:
    R->>R: forwardInvocation:(invocation)
    R->>T: [invocation invokeWithTarget:T]
    T-->>R: 返回值
    R-->>C: 返回

5.3 引用计数与所有权(概念)

flowchart LR
    subgraph 创建
        A[alloc/new/copy] --> B[引用计数 = 1]
    end
    subgraph 持有
        B --> C[retain +1]
        C --> D[release -1]
    end
    subgraph 释放
        D --> E{计数 = 0?}
        E -->|是| F[dealloc 释放对象]
        E -->|否| G[仍存活]
    end

5.4 Block 循环引用

flowchart LR
    subgraph 循环
        S[self] --> B[block]
        B --> S
    end
    subgraph 打破
        W[weakSelf] --> B2[block]
        S2[self] -.->|弱引用| W
        B2 -.->|捕获 weakSelf| W
    end

5.5 GCD 队列层次(概念)

flowchart TB
    subgraph 主队列
        M[Main Queue - UI]
    end
    subgraph 全局并发队列
        G[Global Concurrent Queue]
    end
    subgraph 自定义
        Q1[Serial Queue]
        Q2[Concurrent Queue]
    end
    M --> G
    G --> Q1
    G --> Q2

六、伪代码与算法说明

6.1 对象相等性与 hash(约定)

约定(Effective Objective-C 与 Cocoa 惯例):
1. 若 [a isEqual:b] 为 YES,则 [a hash] == [b hash] 必须成立。
2. hash 在对象生命周期内应稳定(不变)。
3. hash 不必唯一,但应尽量均匀以减少冲突。

算法(示例,仅说明思路):
- 对关键属性分别求 hash(如 NSString 的 hash、数值的 hash),再组合(如异或、乘质数相加)。
- 避免在 hash 中做重计算或依赖可变状态。

6.2 weak–strong 避免 Block 循环引用(伪代码)

// 错误:block 被 self 持有,block 内又强引用 self
self.block = ^{ [self doSomething]; };  // 循环引用

// 正确:block 外 weak,block 内 strong(可选,防止执行过程中 self 被释放)
__weak typeof(self) weakSelf = self;
self.block = ^{
    __strong typeof(weakSelf) strongSelf = weakSelf;
    if (strongSelf) { [strongSelf doSomething]; }
};

6.3 dispatch_once 单例(典型写法)

+ (instancetype)sharedInstance {
    static MyClass *instance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[MyClass alloc] init];
    });
    return instance;
}
// dispatch_once 保证块只执行一次,且线程安全。

6.4 forwardInvocation 转发到后备对象(伪代码)

// 根据 Apple 文档 [12],简化实现思路:
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector {
    NSMethodSignature *sig = [super methodSignatureForSelector:selector];
    if (!sig) sig = [backupObject methodSignatureForSelector:selector];
    return sig;
}
- (void)forwardInvocation:(NSInvocation *)invocation {
    if ([backupObject respondsToSelector:[invocation selector]])
        [invocation invokeWithTarget:backupObject];
    else
        [super forwardInvocation:invocation];
}

七、应用场景与最佳实践

7.1 场景与条目对照

场景 本书建议概要 典型条目
网络/异步回调 使用 Block + GCD,避免 performSelector;在 block 内用 weak–strong 避免循环引用 37–40, 42–43
自定义集合元素 实现 isEqual: 与 hash;若需复制实现 NSCopying 8, 22
为系统类添加方法 用 Category,方法名加前缀;需存储用关联对象或类扩展 25–26
单例或一次性初始化 dispatch_once 45
缓存图片/数据 NSCache,不手写 NSDictionary + 淘汰 50
定时任务 NSTimer 注意与 target 的循环引用,及时 invalidate 或拆开 52
调试内存/野指针 僵尸对象、Instruments、静态分析 35–36
多任务完成后统一处理 dispatch_group + dispatch_group_notify 44

7.2 高级应用场景简述

  • AOP / 无埋点:通过 Method Swizzling 在系统或业务方法前后插入逻辑(如统计、日志),需注意交换时机与线程安全;可与 +load 配合 [2][4]。
  • 跨框架混用(Core Foundation ↔ Objective-C):使用 __bridge(不转移所有权)、__bridge_retained(CF 侧持有)、__bridge_transfer(OC 侧持有)正确管理生命周期,避免重复释放或泄漏 [5][7]。
  • 大循环中的临时对象:在循环内使用 @autoreleasepool { ... } 及时排空自动释放池,降低内存峰值 [5][8]。
  • 委托与数据源:delegate 属性声明为 weak,在 dealloc 中无需显式置 nil(weak 会自动清空);调用可选方法前用 respondsToSelector: 判断 [2]。

八、其它补充

第2条: 在类的头文件中尽量少引用其他头文件

有时,类A需要将类B的实例变量作为它公共API的属性。这个时候,我们不应该引入类B的头文件,而应该使用向前声明(forward declaring)使用class关键字,并且在A的实现文件引用B的头文件。

// EOCPerson.h
#import <Foundation/Foundation.h>

@class EOCEmployer;

@interface EOCPerson : NSObject

@property (nonatomic, copy) NSString *firstName;
@property (nonatomic, copy) NSString *lastName;
@property (nonatomic, strong) EOCEmployer *employer;//将EOCEmployer作为属性

@end

// EOCPerson.m
#import "EOCEmployer.h"

这样做有什么优点呢:

  • 不在A的头文件中引入B的头文件,就不会一并引入B的全部内容,这样就减少了编译时间。
  • 可以避免循环引用:因为如果两个类在自己的头文件中都引入了对方的头文件,那么就会导致其中一个类无法被正确编译。

但是个别的时候,必须在头文件中引入其他类的头文件:

主要有两种情况:

  1. 该类继承于某个类,则应该引入父类的头文件。
  2. 该类遵从某个协议,则应该引入该协议的头文件。而且最好将协议单独放在一个头文件中。

第3条:多用字面量语法,少用与之等价的方法

1. 声明时的字面量语法:

在声明NSNumber,NSArray,NSDictionary时,应该尽量使用简洁字面量语法。

NSNumber *intNumber = @1;
NSNumber *floatNumber = @2.5f;
NSArray *animals =[NSArray arrayWithObjects:@"cat", @"dog",@"mouse", @"badger", nil];
Dictionary *dict = @{@"animal":@"tiger",@"phone":@"iPhone 6"};

2. 集合类取下标的字面量语法:

NSArray,NSDictionary,NSMutableArray,NSMutableDictionary 的取下标操作也应该尽量使用字面量语法。

NSString *cat = animals[0];
NSString *iphone = dict[@"phone"];

使用字面量语法的优点:

  1. 代码看起来更加简洁。
  2. 如果存在nil值,则会立即抛出异常。如果在不用字面量语法定义数组的情况下,如果数组内部存在nil,则系统会将其设为数组最后一个元素并终止。所以当这个nil不是最后一个元素的话,就会出现难以排查的错误。

注意: 字面量语法创建出来的字符串,数组,字典对象都是不可变的。

第4条:多用类型常量,少用#define预处理命令

在OC中,定义常量通常使用预处理命令,但是并不建议使用它,而是使用类型常量的方法。 首先比较一下这两种方法的区别:

  • 预处理命令:简单的文本替换,不包括类型信息,并且可被任意修改。
  • 类型常量:包括类型信息,并且可以设置其使用范围,而且不可被修改。

我们可以看出来,使用预处理虽然能达到替换文本的目的,但是本身还是有局限性的:不具备类型 + 可以被任意修改,总之给人一种不安全的感觉。

知道了它们的长短处,我们再来简单看一下它们的具体使用方法:

预处理命令:

#define W_LABEL (W_SCREEN - 2*GAP)

这里,(W_SCREEN - 2*GAP)替换了W_LABEL,它不具备W_LABEL的类型信息。而且要注意一下:如果替换式中存在运算符号,以笔者的经验最好用括号括起来,不然容易出现错误(有体会)。

类型常量:

static const NSTimeIntervalDuration = 0.3;

这里: const 将其设置为常量,不可更改。 static意味着该变量仅仅在定义此变量的编译单元中可见。如果不声明static,编译器会为它创建一个外部符号(external symbol)。我们来看一下对外公开的常量的声明方法:

对外公开某个常量:

如果我们需要发送通知,那么就需要在不同的地方拿到通知的“频道”字符串,那么显然这个字符串是不能被轻易更改,而且可以在不同的地方获取。这个时候就需要定义一个外界可见的字符串常量。

//header file
extern NSString *const NotificationString;

//implementation file
NSString *const  NotificationString = @"Finish Download";

这里NSString *const NotificationString是指针常量。 extern关键字告诉编译器,在全局符号表中将会有一个名叫NotificationString的符号。

我们通常在头文件声明常量,在其实现文件里定义该常量。由实现文件生成目标文件时,编译器会在“数据段”为字符串分配存储空间。

最后注意一下公开和非公开的常量的命名规范:

公开的常量:常量的名字最好用与之相关的类名做前缀。 非公开的常量:局限于某个编译单元(tanslation unit,实现文件 implementation file)内,在签名加上字母k。

第5条:用枚举表示状态,选项,状态码

我们经常需要给类定义几个状态,这些状态码可以用枚举来管理。下面是关于网络连接状态的状态码枚举:

typedef NS_ENUM(NSUInteger, EOCConnectionState) {
  EOCConnectionStateDisconnected,
  EOCConnectionStateConnecting,
  EOCConnectionStateConnected,
};

需要注意的一点是: 在枚举类型的switch语句中不要实现default分支。它的好处是,当我们给枚举增加成员时,编译器就会提示开发者:switch语句并未处理所有的枚举。对此,笔者有个教训,又一次在switch语句中将“默认分支”设置为枚举中的第一项,自以为这样写可以让程序更健壮,结果后来导致了严重的崩溃。

第21条:理解Objective-C错误类型

在OC中,我们可以用NSError描述错误。 使用NSError可以封装三种信息:

  • Error domain:错误范围,类型是字符串
  • Error code :错误码,类型是整数
  • User info:用户信息,类型是字典

1. NSError的使用

用法:

1.通过委托协议来传递NSError,告诉代理错误类型。

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error

2.作为方法的“输出参数”返回给调用者

- (BOOL)doSomething:(NSError**)error

使用范例:


NSError *error = nil;
BOOL ret = [object doSomething:&error];

if (error) {
    // There was an error
}

2. 自定义NSError

我们可以设置属于我们自己程序的错误范围和错误码

  • 错误范围可以用全局常量字符串来定义。
  • 错误码可以用枚举来定义。

// EOCErrors.h
extern NSString *const EOCErrorDomain;

//定义错误码
typedef NS_ENUM(NSUInteger, EOCError) {

    EOCErrorUnknown = –1,
    EOCErrorInternalInconsistency = 100,
    EOCErrorGeneralFault = 105,
    EOCErrorBadInput = 500,
};



// EOCErrors.m
NSString *const EOCErrorDomain = @"EOCErrorDomain"; //定义错误范围

第22条:理解NSCopying协议

如果我们想令自己的类支持拷贝操作,那就要实现NSCopying协议,该协议只有一个方法:

- (id)copyWithZone:(NSZone*)zone

作者举了个:


- (id)copyWithZone:(NSZone*)zone {

     EOCPerson *copy = [[[self class] allocWithZone:zone] initWithFirstName:_firstName  andLastName:_lastName];
    copy->_friends = [_friends mutableCopy];
     return copy;
}

之所以是copy->_friends,而不是copy.friends是因为friends并不是属性,而是一个内部使用的实例变量。

1. 复制可变的版本:

遵从协议

而且要执行:

- (id)mutableCopyWithZone:(NSZone*)zone;

注意:拷贝可变型和不可变型发送的是copymutableCopy消息,而我们实现的却是- (id)copyWithZone:(NSZone*)zone- (id)mutableCopyWithZone:(NSZone*)zone 方法。

而且,如果我们想获得某对象的不可变型,统一调用copy方法;获得某对象的可变型,统一调用mutableCopy方法。

例如数组的拷贝:

-[NSMutableArray copy] => NSArray
-[NSArray mutableCopy] => NSMutableArray

2. 浅拷贝和深拷贝

Foundation框架中的集合类默认都执行浅拷贝:只拷贝容器对象本身,而不复制其中的数据。 而深拷贝的意思是连同对象本身和它的底层数据都要拷贝。

作者用一个图很形象地体现了浅拷贝和深拷贝的区别:

图片来自:《Effective Objective-C》

浅拷贝后的内容和原始内容指向同一个对象 深拷贝后的内容所指的对象是原始内容对应对象的拷贝

3. 如何深拷贝?

我们需要自己编写深拷贝的方法:遍历每个元素并复制,然后将复制后的所有元素重新组成一个新的集合。

- (id)initWithSet:(NSArray*)array copyItems:(BOOL)copyItems;

在这里,我们自己提供了一个深拷贝的方法:该方法需要传入两个参数:需要拷贝的数组和是否拷贝元素(是否深拷贝)


- (id)deepCopy {
       EOCPerson *copy = [[[self class] alloc] initWithFirstName:_firstName andLastName:_lastName];
        copy->_friends = [[NSMutableSet alloc] initWithSet:_friends copyItems:YES];
        return copy;
}

第47条:熟悉系统框架

如果我们使用了系统提供的现成的框架,那么用户在升级系统后,就可以直接享受系统升级所带来的改进。

主要的系统框架:

  • Foundation:NSObject,NSArray,NSDictionary等
  • CFoundation框架:C语言API,Foundation框架中的许多功能,都可以在这里找到对应的C语言API
  • CFNetwork框架:C语言API,提供了C语言级别的网络通信能力
  • CoreAudio:C语言API,操作设备上的音频硬件
  • AVFoundation框架:提供的OC对象可以回放并录制音频和视频
  • CoreData框架:OC的API,将对象写入数据库
  • CoreText框架:C语言API,高效执行文字排版和渲染操作

用C语言来实现API的好处:可以绕过OC的运行期系统,从而提升执行速度

第7条: 在对象内部尽量直接访问实例变量

关于实例变量的访问,可以直接访问,也可以通过属性的方式(点语法)来访问。书中作者建议在读取实例变量时采用直接访问的形式,而在设置实例变量的时候通过属性来做。

1. 直接访问属性的特点:

  • 绕过set,get语义,速度快;

2. 通过属性访问属性的特点:

  • 不会绕过属性定义的内存管理语义
  • 有助于打断点排查错误
  • 可以触发KVO

因此,有个关于折中的方案:

设置属性:通过属性 读取属性:直接访问

不过有两个特例:

  1. 初始化方法和dealloc方法中,需要直接访问实例变量来进行设置属性操作。因为如果在这里没有绕过set方法,就有可能触发其他不必要的操作。
  2. 惰性初始化(lazy initialization)的属性,必须通过属性来读取数据。因为惰性初始化是通过重写get方法来初始化实例变量的,如果不通过属性来读取该实例变量,那么这个实例变量就永远不会被初始化。

第15条:用前缀 避免命名空间冲突

Apple宣称其保留使用所有"两字母前缀"的权利,所以我们选用的前缀应该是三个字母的。 而且,如果自己开发的程序使用到了第三方库,也应该加上前缀。

第18条:尽量使用不可变对象

书中作者建议尽量把对外公布出来的属性设置为只读,在实现文件内部设为读写。具体做法是:

在头文件中,设置对象属性为readonly,在实现文件中设置为readwrite。这样一来,在外部就只能读取该数据,而不能修改它,使得这个类的实例所持有的数据更加安全。

而且,对于集合类的对象,更应该仔细考虑是否可以将其设为可变的。

如果在公开部分只能设置其为只读属性,那么就在非公开部分存储一个可变型。这样一来,当在外部获取这个属性时,获取的只是内部可变型的一个不可变版本,例如:

在公共API中:

@interface EOCPerson : NSObject

@property (nonatomic, copy, readonly) NSString *firstName;
@property (nonatomic, copy, readonly) NSString *lastName;
@property (nonatomic, strong, readonly) NSSet *friends //向外公开的不可变集合

- (id)initWithFirstName:(NSString*)firstName lastName:(NSString*)lastName;
- (void)addFriend:(EOCPerson*)person;
- (void)removeFriend:(EOCPerson*)person;

@end

在这里,我们将friends属性设置为不可变的set。然后,提供了来增加和删除这个set里的元素的公共接口。

在实现文件里:

@interface EOCPerson ()

@property (nonatomic, copy, readwrite) NSString *firstName;
@property (nonatomic, copy, readwrite) NSString *lastName;

@end

@implementation EOCPerson {
     NSMutableSet *_internalFriends;  //实现文件里的可变集合
}

- (NSSet*)friends {
     return [_internalFriends copy]; //get方法返回的永远是可变set的不可变型
}

- (void)addFriend:(EOCPerson*)person {
    [_internalFriends addObject:person]; //在外部增加集合元素的操作
    //do something when add element
}

- (void)removeFriend:(EOCPerson*)person {
    [_internalFriends removeObject:person]; //在外部移除元素的操作
    //do something when remove element
}

- (id)initWithFirstName:(NSString*)firstName lastName:(NSString*)lastName {

     if ((self = [super init])) {
        _firstName = firstName;
        _lastName = lastName;
        _internalFriends = [NSMutableSet new];
    }
 return self;
}

我们可以看到,在实现文件里,保存一个可变set来记录外部的增删操作。

这里最重要的代码是:

- (NSSet*)friends {
 return [_internalFriends copy];
}

这个是friends属性的获取方法:它将当前保存的可变set复制了一不可变的set并返回。因此,外部读取到的set都将是不可变的版本。

等一下,有个疑问:

在公共接口设置不可变set 和 将增删的代码放在公共接口中是否矛盾的?

答案:并不矛盾!

因为如果将friends属性设置为可变的,那么外部就可以随便更改set集合里的数据,这里的更改,仅仅是底层数据的更改,并不伴随其他任何操作。 然而有时,我们需要在更改set数据的同时要执行隐秘在实现文件里的其他工作,那么如果在外部随意更改这个属性的话,显然是达不到这种需求的。

因此,我们需要提供给外界我们定制的增删的方法,并不让外部”自行“增删。

第19条:使用清晰而协调的命名方式

在给OC的方法取名字的时候要充分利用OC方法的命名优势,取一个语义清晰的方法名!什么叫语义清晰呢?就是说读起来像是一句话一样。

我们看一个例子:

先看名字取得不好的:

//方法定义
- (id)initWithSize:(float)width :(float)height;

//方法调用
EOCRectangle *aRectangle =[[EOCRectangle alloc] initWithSize:5.0f :10.0f];

这里定义了Rectangle的初始化方法。虽然直观上可以知道这个方法通过传入的两个参数来组成矩形的size,但是我们并不知道哪个是矩形的宽,哪个是矩形的高。 来看一下正确的🌰 :

//方法定义
- (id)initWithWidth:(float)width height:(float)height;

//方法调用
EOCRectangle *aRectangle =[[EOCRectangle alloc] initWithWidth:5.0f height:10.0f];

这个方法名就很好的诠释了该方法的意图:这个类的初始化是需要宽度和高度的。而且,哪个参数是高度,哪个参数是宽度,看得人一清二楚。永远要记得:代码是给人看的

笔者自己总结的方法命名规则:

每个冒号左边的方法部分最好与右边的参数名一致。

对于返回值是布尔值的方法,我们也要注意命名的规范:

  • 获取”是否“的布尔值,应该增加“is”前缀:

- isEqualToString:

获取“是否有”的布尔值,应该增加“has”前缀:

- hasPrefix:

第20条:为私有方法名加前缀

建议在实现文件里将非公开的方法都加上前缀,便于调试,而且这样一来也很容易区分哪些是公共方法,哪些是私有方法。因为往往公共方法是不便于任意修改的。

在这里,作者举了个例子:

#import <Foundation/Foundation.h>

@interface EOCObject : NSObject

- (void)publicMethod;

@end


@implementation EOCObject

- (void)publicMethod {
 /* ... */
}

- (void)p_privateMethod {
 /* ... */
}

@end

注意: 不要用下划线来区分私有方法和公共方法,因为会和苹果公司的API重复。

第23条:通过委托与数据源协议进行对象间通信

如果给委托对象发送消息,那么必须提前判断该委托对象是否实现了该消息:

NSData *data = /* data obtained from network */;

if ([_delegate respondsToSelector: @selector(networkFetcher:didReceiveData:)])
{
        [_delegate networkFetcher:self didReceiveData:data];
}

而且,最好再加上一个判断:判断委托对象是否存在


NSData *data = /* data obtained from network */;

if ( (_delegate) && ([_delegate respondsToSelector: @selector(networkFetcher:didReceiveData:)]))
{
        [_delegate networkFetcher:self didReceiveData:data];
}

对于代理模式,在iOS中分为两种:

  • 普通的委托模式:信息从类流向委托者
  • 信息源模式:信息从数据源流向类

普通的委托 | 信息源

就好比tableview告诉它的代理(delegate)“我被点击了”;而它的数据源(data Source)告诉它“你有这些数据”。仔细回味一下,这两个信息的传递方向是相反的。

第24条:将类的实现代码分散到便于管理的数个分类中

通常一个类会有很多方法,而这些方法往往可以用某种特有的逻辑来分组。我们可以利用OC的分类机制,将类的这些方法按一定的逻辑划入几个分区中。

例子:

无分类的类:

#import <Foundation/Foundation.h>

@interface EOCPerson : NSObject

@property (nonatomic, copy, readonly) NSString *firstName;
@property (nonatomic, copy, readonly) NSString *lastName;
@property (nonatomic, strong, readonly) NSArray *friends;

- (id)initWithFirstName:(NSString*)firstName lastName:(NSString*)lastName;

/* Friendship methods */
- (void)addFriend:(EOCPerson*)person;
- (void)removeFriend:(EOCPerson*)person;
- (BOOL)isFriendsWith:(EOCPerson*)person;


/* Work methods */
- (void)performDaysWork;
- (void)takeVacationFromWork;


/* Play methods */
- (void)goToTheCinema;
- (void)goToSportsGame;


@end

分类之后:

#import <Foundation/Foundation.h>


@interface EOCPerson : NSObject

@property (nonatomic, copy, readonly) NSString *firstName;
@property (nonatomic, copy, readonly) NSString *lastName;
@property (nonatomic, strong, readonly) NSArray *friends;



- (id)initWithFirstName:(NSString*)firstName

lastName:(NSString*)lastName;

@end



@interface EOCPerson (Friendship)

- (void)addFriend:(EOCPerson*)person;
- (void)removeFriend:(EOCPerson*)person;
- (BOOL)isFriendsWith:(EOCPerson*)person;

@end



@interface EOCPerson (Work)

- (void)performDaysWork;
- (void)takeVacationFromWork;

@end



@interface EOCPerson (Play)

- (void)goToTheCinema;
- (void)goToSportsGame;

@end

其中,FriendShip分类的实现代码可以这么写:


// EOCPerson+Friendship.h
#import "EOCPerson.h"


@interface EOCPerson (Friendship)

- (void)addFriend:(EOCPerson*)person;
- (void)removeFriend:(EOCPerson*)person;
- (BOOL)isFriendsWith:(EOCPerson*)person;

@end


// EOCPerson+Friendship.m
#import "EOCPerson+Friendship.h"


@implementation EOCPerson (Friendship)

- (void)addFriend:(EOCPerson*)person {
 /* ... */
}

- (void)removeFriend:(EOCPerson*)person {
 /* ... */
}

- (BOOL)isFriendsWith:(EOCPerson*)person {
 /* ... */
}

@end

注意:在新建分类文件时,一定要引入被分类的类文件。

通过分类机制,可以把类代码分成很多个易于管理的功能区,同时也便于调试。因为分类的方法名称会包含分类的名称,可以马上看到该方法属于哪个分类中。

利用这一点,我们可以创建名为Private的分类,将所有私有方法都放在该类里。这样一来,我们就可以根据private一词的出现位置来判断调用的合理性,这也是一种编写“自我描述式代码(self-documenting)”的办法。

第25条:总是为第三方类的分类名称加前缀

分类机制虽然强大,但是如果分类里的方法与原来的方法名称一致,那么分类的方法就会覆盖掉原来的方法,而且总是以最后一次被覆盖为基准。

因此,我们应该以命名空间来区别各个分类的名称与其中定义的方法。在OC里的做法就是给这些方法加上某个共用的前缀。例如:

@interface NSString (ABC_HTTP)

// Encode a string with URL encoding
- (NSString*)abc_urlEncodedString;

// Decode a URL encoded string
- (NSString*)abc_urlDecodedString;

@end

因此,如果我们想给第三方库或者iOS框架里的类添加分类时,最好将分类名和方法名加上前缀。

第26条:勿在分类中声明属性

除了实现文件里的class-continuation分类中可以声明属性外,其他分类无法向类中新增实例变量。

因此,类所封装的全部数据都应该定义在主接口中,这里是唯一能够定义实例变量的地方。

关于分类,需要强调一点:

分类机制,目标在于扩展类的功能,而不是封装数据。

第27条:使用class-continuation分类 隐藏实现细节

通常,我们需要减少在公共接口中向外暴露的部分(包括属性和方法),而因此带给我们的局限性可以利用class-continuation分类的特性来补偿:

  • 可以在class-continuation分类中增加实例变量。
  • 可以在class-continuation分类中将公共接口的只读属性设置为读写。
  • 可以在class-continuation分类中遵循协议,使其不为人知。

第31条:在dealloc方法中只释放引用并解除监听

永远不要自己调用dealloc方法,运行期系统会在适当的时候调用它。根据性能需求我们有时需要在dealloc方法中做一些操作。那么我们可以在dealloc方法里做什么呢?

  • 释放对象所拥有的所有引用,不过ARC会自动添加这些释放代码,可以不必操心。
  • 而且对象拥有的其他非OC对象也要释放(CoreFoundation对象就必须手动释放)
  • 释放原来的观测行为:注销通知。如果没有及时注销,就会向其发送通知,使得程序崩溃。

举个简单的🌰 :


- (void)dealloc {

     CFRelease(coreFoundationObject);
    [[NSNotificationCenter defaultCenter] removeObserver:self];

}

尤其注意:在dealloc方法中不应该调用其他的方法,因为如果这些方法是异步的,并且回调中还要使用当前对象,那么很有可能当前对象已经被释放了,会导致崩溃。

并且在dealloc方法中也不能调用属性的存取方法,因为很有可能在这些方法里还有其他操作。而且这个属性还有可能处于键值观察状态,该属性的观察者可能会在属性改变时保留或者使用这个即将回收的对象。

第36条:不要使用retainCount

在非ARC得环境下使用retainCount可以返回当前对象的引用计数,但是在ARC环境下调用会报错,因为该方法已经被废弃了 。

它被废弃的原因是因为它所返回的引用计数只能反映对象某一时刻的引用计数,而无法“预知”对象将来引用计数的变化(比如对象当前处于自动释放池中,那么将来就会自动递减引用计数)。

第46条:不要使用dispatch_get_current_queue

我们无法用某个队列来描述“当前队列”这一属性,因为派发队列是按照层级来组织的。

那么什么是队列的层级呢?

队列的层及分布

安排在某条队列中的快,会在其上层队列中执行,而层级地位最高的那个队列总是全局并发队列。

在这里,B,C中的块会在A里执行。但是D中的块,可能与A里的块并行,因为A和D的目标队列是并发队列。

正因为有了这种层级关系,所以检查当前队列是并发的还是非并发的就不会总是很准确。

第48条:多用块枚举,少用for循环

当遍历集合元素时,建议使用块枚举,因为相对于传统的for循环,它更加高效,而且简洁,还能获取到用传统的for循环无法提供的值:

我们首先看一下传统的遍历:

1. 传统的for遍历

NSArray *anArray = /* ... */;
for (int i = 0; i < anArray.count; i++) {
   id object = anArray[i];
   // Do something with 'object'
}



// Dictionary
NSDictionary *aDictionary = /* ... */;
NSArray *keys = [aDictionary allKeys];
for (int i = 0; i < keys.count; i++) {
   id key = keys[i];
   id value = aDictionary[key];
   // Do something with 'key' and 'value'
}


// Set
NSSet *aSet = /* ... */;
NSArray *objects = [aSet allObjects];
for (int i = 0; i < objects.count; i++) {
   id object = objects[i];
   // Do something with 'object'

}

我们可以看到,在遍历NSDictionary,和NSet时,我们又新创建了一个数组。虽然遍历的目的达成了,但是却加大了系统的开销。

2. 利用快速遍历:

NSArray *anArray = /* ... */;
for (id object in anArray) {
 // Do something with 'object'
}

// Dictionary
NSDictionary *aDictionary = /* ... */;
for (id key in aDictionary) {
 id value = aDictionary[key];
 // Do something with 'key' and 'value'

}


NSSet *aSet = /* ... */;
for (id object in aSet) {
 // Do something with 'object'
}

这种快速遍历的方法要比传统的遍历方法更加简洁易懂,但是缺点是无法方便获取元素的下标。

3. 利用基于block的遍历:

NSArray *anArray = /* ... */;
[anArray enumerateObjectsUsingBlock:^(id object, NSUInteger idx, BOOL *stop){

   // Do something with 'object'
   if (shouldStop) {
      *stop = YES; //使迭代停止
  }

}];


“// Dictionary
NSDictionary *aDictionary = /* ... */;
[aDictionary enumerateKeysAndObjectsUsingBlock:^(id key, id object, BOOL *stop){
     // Do something with 'key' and 'object'
     if (shouldStop) {
        *stop = YES;
    }
}];


// Set
NSSet *aSet = /* ... */;
[aSet enumerateObjectsUsingBlock:^(id object, BOOL *stop){
     // Do something with 'object'
     if (shouldStop) {
        *stop = YES;
    }
];

我们可以看到,在使用块进行快速枚举的时候,我们可以不创建临时数组。虽然语法上没有快速枚举简洁,但是我们可以获得数组元素对应的序号,字典元素对应的键值,而且,我们还可以随时令遍历终止。

利用快速枚举和块的枚举还有一个优点:能够修改块的方法签名

for (NSString *key in aDictionary) {
         NSString *object = (NSString*)aDictionary[key];
        // Do something with 'key' and 'object'
}

NSDictionary *aDictionary = /* ... */;

    [aDictionary enumerateKeysAndObjectsUsingBlock:^(NSString *key, NSString *obj, BOOL *stop){

             // Do something with 'key' and 'obj'

}];

第50条:构建缓存时选用NSCache 而非NSDictionary

如果我们缓存使用得当,那么应用程序的响应速度就会提高。只有那种“重新计算起来很费事的数据,才值得放入缓存”,比如那些需要从网络获取或从磁盘读取的数据。

在构建缓存的时候很多人习惯用NSDictionary或者NSMutableDictionary,但是作者建议大家使用NSCache,它作为管理缓存的类,有很多特点要优于字典,因为它本来就是为了管理缓存而设计的。

1. NSCache优于NSDictionary的几点:

  • 当系统资源将要耗尽时,NSCache具备自动删减缓冲的功能。并且还会先删减“最久未使用”的对象。
  • NSCache不拷贝键,而是保留键。因为并不是所有的键都遵从拷贝协议(字典的键是必须要支持拷贝协议的,有局限性)。
  • NSCache是线程安全的:不编写加锁代码的前提下,多个线程可以同时访问NSCache。

2. 关于操控NSCache删减内容的时机

开发者可以通过两个尺度来调整这个时机:

  • 缓存中的对象总数.
  • 将对象加入缓存时,为其指定开销值。

对于开销值,只有在能很快计算出开销值的情况下,才应该考虑采用这个尺度,不然反而会加大系统的开销。

下面我们来看一下缓存的用法:缓存网络下载的数据

// Network fetcher class
typedef void(^EOCNetworkFetcherCompletionHandler)(NSData *data);

@interface EOCNetworkFetcher : NSObject

- (id)initWithURL:(NSURL*)url;
- (void)startWithCompletionHandler:(EOCNetworkFetcherCompletionHandler)handler;

@end

// Class that uses the network fetcher and caches results
@interface EOCClass : NSObject
@end

@implementation EOCClass {
     NSCache *_cache;
}

- (id)init {

     if ((self = [super init])) {
    _cache = [NSCache new];

     // Cache a maximum of 100 URLs
    _cache.countLimit = 100;


     /**
     * The size in bytes of data is used as the cost,
     * so this sets a cost limit of 5MB.
     */
    _cache.totalCostLimit = 5 * 1024 * 1024;
    }
 return self;
}



- (void)downloadDataForURL:(NSURL*)url { 

     NSData *cachedData = [_cache objectForKey:url];

     if (cachedData) {

         // Cache hit:存在缓存,读取
        [self useData:cachedData];

    } else {

         // Cache miss:没有缓存,下载
         EOCNetworkFetcher *fetcher = [[EOCNetworkFetcher alloc] initWithURL:url];      

        [fetcher startWithCompletionHandler:^(NSData *data){
         [_cache setObject:data forKey:url cost:data.length];    
        [self useData:data];
        }];
    }
}
@end

在这里,我们使用URL作为缓存的key,将总对象数目设置为100,将开销值设置为5MB。

3. NSPurgeableData

NSPurgeableData是NSMutableData的子类,把它和NSCache配合使用效果很好。

因为当系统资源紧张时,可以把保存NSPurgeableData的那块内存释放掉。

如果需要访问某个NSPurgeableData对象,可以调用beginContentAccess方发,告诉它现在还不应该丢弃自己所占据的内存。

在使用完之后,调用endContentAccess方法,告诉系统在必要时可以丢弃自己所占据的内存。

上面这两个方法类似于“引用计数”递增递减的操作,也就是说,只有当“引用计数”为0的时候,才可以在将来删去它所占的内存。


- (void)downloadDataForURL:(NSURL*)url { 

      NSPurgeableData *cachedData = [_cache objectForKey:url];

      if (cachedData) {         

            // 如果存在缓存,需要调用beginContentAccess方法
            [cacheData beginContentAccess];

             // Use the cached data
            [self useData:cachedData];

             // 使用后,调用endContentAccess
            [cacheData endContentAccess];


        } else {

                 //没有缓存
                 EOCNetworkFetcher *fetcher = [[EOCNetworkFetcher alloc] initWithURL:url];    

                  [fetcher startWithCompletionHandler:^(NSData *data){                         NSPurgeableData *purgeableData = [NSPurgeableData dataWithData:data];
                         [_cache setObject:purgeableData forKey:url cost:purgeableData.length];

                          // Don't need to beginContentAccess as it begins            
                          // with access already marked
                           // Use the retrieved data
                            [self useData:data];

                             // Mark that the data may be purged now
                            [purgeableData endContentAccess];

            }];
      }
}
复制代码

注意:

在我们可以直接拿到purgeableData的情况下需要执行beginContentAccess方法。然而,在创建purgeableData的情况下,是不需要执行beginContentAccess,因为在创建了purgeableData之后,其引用计数会自动+1;

第51条: 精简initialize 与 load的实现代码

1. load方法

+(void)load;

每个类和分类在加入运行期系统时,都会调用load方法,而且仅仅调用一次,可能有些小伙伴习惯在这里调用一些方法,但是作者建议尽量不要在这个方法里调用其他方法,尤其是使用其他的类。原因是每个类载入程序库的时机是不同的,如果该类调用了还未载入程序库的类,就会很危险。

2. initialize方法

+(void)initialize;

这个方法与load方法类似,区别是这个方法会在程序首次调用这个类的时候调用(惰性调用),而且只调用一次(绝对不能主动使用代码调用)。

值得注意的一点是,如果子类没有实现它,它的超类却实现了,那么就会运行超类的代码:这个情况往往很容易让人忽视。

看一下🌰 :

#import <Foundation/Foundation.h>

@interface EOCBaseClass : NSObject
@end

@implementation EOCBaseClass
+ (void)initialize {
 NSLog(@"%@ initialize", self);
}
@end

@interface EOCSubClass : EOCBaseClass
@end

@implementation EOCSubClass
@end

当使用EOCSubClass类时,控制台会输出两次打印方法:

EOCBaseClass initialize
EOCSubClass initialize

因为子类EOCSubClass并没有覆写initialize方法,那么自然会调用其父类EOCBaseClass的方法。 解决方案是通过检测类的类型的方法:

+ (void)initialize {
   if (self == [EOCBaseClass class]) {
       NSLog(@"%@ initialized", self);
    }
}

这样一来,EOCBaseClass的子类EOCSubClass就无法再调用initialize方法了。 我们可以察觉到,如果在这个方法里执行过多的操作的话,会使得程序难以维护,也可能引起其他的bug。因此,在initialize方法里,最好只是设置内部的数据,不要调用其他的方法,因为将来可能会给这些方法添加其它的功能,那么会可能会引起难以排查的bug。

第52条: 别忘了NSTimer会保留其目标对象

在使用NSTimer的时候,NSTimer会生成指向其使用者的引用,而其使用者如果也引用了NSTimer,那么就会生成保留环。

#import <Foundation/Foundation.h>

@interface EOCClass : NSObject
- (void)startPolling;
- (void)stopPolling;
@end


@implementation EOCClass {
     NSTimer *_pollTimer;
}


- (id)init {
     return [super init];
}


- (void)dealloc {
    [_pollTimer invalidate];
}


- (void)stopPolling {

    [_pollTimer invalidate];
    _pollTimer = nil;
}


- (void)startPolling {
   _pollTimer = [NSTimer scheduledTimerWithTimeInterval:5.0
                                                 target:self
                                               selector:@selector(p_doPoll)
                                               userInfo:nil
                                                repeats:YES];
}

- (void)p_doPoll {
    // Poll the resource
}

@end

在这里,在EOCClass和_pollTimer之间形成了保留环,如果不主动调用stopPolling方法就无法打破这个保留环。像这种通过主动调用方法来打破保留环的设计显然是不好的。

而且,如果通过回收该类的方法来打破此保留环也是行不通的,因为会将该类和NSTimer孤立出来,形成“孤岛”:

孤立了类和它的NSTimer

这可能是一个极其危险的情况,因为NSTimer没有消失,它还有可能持续执行一些任务,不断消耗系统资源。而且,如果任务涉及到下载,那么可能会更糟。。

那么如何解决呢? 通过“块”来解决!

通过给NSTimer增加一个分类就可以解决:

#import <Foundation/Foundation.h>

@interface NSTimer (EOCBlocksSupport)

+ (NSTimer*)eoc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
                                         block:(void(^)())block
                                         repeats:(BOOL)repeats;
@end



@implementation NSTimer (EOCBlocksSupport)

+ (NSTimer*)eoc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
                                         block:(void(^)())block
                                        repeats:(BOOL)repeats
{
             return [self scheduledTimerWithTimeInterval:interval
                                                  target:self
                                                selector:@selector(eoc_blockInvoke:)
                                                userInfo:[block copy]
                                                 repeats:repeats];

}


+ (void)eoc_blockInvoke:(NSTimer*)timer {
     void (^block)() = timer.userInfo;
         if (block) {
             block();
        }
}
@end

我们在NSTimer类里添加了方法,我们来看一下如何使用它:

- (void)startPolling {

         __weak EOCClass *weakSelf = self;    
         _pollTimer = [NSTimer eoc_scheduledTimerWithTimeInterval:5.0 block:^{

               EOCClass *strongSelf = weakSelf;
               [strongSelf p_doPoll];
          }

                                                          repeats:YES];
}

在这里,创建了一个self的弱引用,然后让块捕获了这个self变量,让其在执行期间存活。

一旦外界指向EOC类的最后一个引用消失,该类就会被释放,被释放的同时,也会向NSTimer发送invalidate消息(因为在该类的dealloc方法中向NSTimer发送了invalidate消息)。

而且,即使在dealloc方法里没有发送invalidate消息,因为块里的weakSelf会变成nil,所以NSTimer同样会失效。

如果我们可以知道集合里的元素类型,就可以修改签名。这样做的好处是:可以让编译期检查该元素是否可以实现我们想调用的方法,如果不能实现,就做另外的处理。这样一来,程序就能变得更加安全。

九、iOS底层原理精华

书中其它部分和之前研究底层原理的内容有交叉,因此,可以参照 底层原理的精华篇幅和文章:

9.1 前知识

9.2 基于OC语言探索iOS底层原理

9.3 基于Swift语言探索iOS底层原理

关于函数枚举可选项结构体闭包属性方法swift多态原理StringArrayDictionary引用计数MetaData等Swift基本语法和相关的底层原理文章有如下几篇:

9.4底层原理相关专题

9.4 iOS相关专题

9.5 webApp相关专题

9.6 跨平台开发方案相关专题

9.7 阶段性总结:Native、WebApp、跨平台开发三种方案性能比较

9.8 Android、HarmonyOS页面渲染专题

9.9 小程序页面渲染专题


延伸阅读(掘金三部曲)

以下为同一作者(J_Knight_)对《Effective Objective-C》的概念 / 规范 / 技巧三分法总结,与本书 52 条一一对应,配有大量示例代码与图示,可作为按条目深挖的补充阅读。

标题 链接 内容概要
概念篇 《Effective Objective-C》干货三部曲(一):概念篇 掘金 - 概念篇 第 1 条(起源、运行期组件、堆栈)、第 6 条(属性、存取方法、关键字)、第 8 条(等同性、hash)、第 11 条(objc_msgSend)、第 12 条(消息转发、EOCAutoDictionary)、第 14 条(类对象、objc_class、isKindOfClass)、第 21 条(NSError)、第 22 条(NSCopying、浅/深拷贝)、第 29–30 条(引用计数、ARC)、第 37 条(Block 栈/堆/全局)、第 47 条(系统框架)
规范篇 《Effective Objective-C》干货三部曲(二):规范篇 掘金 - 规范篇 第 2 条(向前声明)、第 3–5 条(字面量、类型常量、枚举)、第 7 条(直接访问实例变量)、第 15 条(前缀)、第 18 条(不可变对象、内部可变集合)、第 19–20 条(命名、私有方法前缀)、第 23–27 条(委托、分类分散、分类前缀、勿在分类声明属性、class-continuation)、第 31 条(dealloc)、第 36 条(retainCount)、第 46 条(dispatch_get_current_queue)、第 48 条(块枚举)、第 50 条(NSCache、NSPurgeableData)、第 51 条(load/initialize)、第 52 条(NSTimer 保留环与 block 方案)
技巧篇 《Effective Objective-C》干货三部曲(三):技巧篇 掘金 - 技巧篇 第 9 条(类族模式)、第 10 条(关联对象、UIAlertView+block)、第 13 条(方法调配、lowercaseString 示例)、第 16 条(全能初始化、子类覆写、initWithCoder)、第 17 条(description)、第 28 条(匿名对象)、第 32–35 条(异常安全、弱引用、自动释放池块、僵尸对象)、第 38–45 条(block typedef、handler 块、保留环、串行队列/barrier、GCD vs performSelector、NSOperation、dispatch group、dispatch_once)、第 49 条(无缝桥接)

参考文献

[1] Galloway, M. Effective Objective-C 2.0: 52 Specific Ways to Write Better iOS and OS X Programs. Addison-Wesley Professional, 2013.
[2] O'Reilly. Effective Objective-C 2.0 — Table of Contents and Chapter Summaries. www.oreilly.com/library/vie…
[3] Apple. Objective-C Runtime Programming Guide. Developer Documentation Archive.
[4] Apple. The Objective-C Programming Language (Legacy).
[5] Apple. Advanced Memory Management Programming Guide. developer.apple.com/library/arc…
[6] Apple. About Memory Management. developer.apple.com/library/arc…
[7] Apple. Transitioning to ARC Release Notes. developer.apple.com/library/arc…
[8] Clang. Automatic Reference Counting (ARC). clang.llvm.org/docs/Automa…
[9] Stack Overflow. Block retain cycle, weak-strong dance.
[10] Apple. Working with Blocks. Programming Guide.
[11] Apple. Dispatch (GCD). Concurrency Programming Guide.
[12] Apple. Message Forwarding. Objective-C Runtime Guide. developer.apple.com/library/arc…
[13] J_Knight_. 《Effective Objective-C》干货三部曲(一):概念篇. 掘金,2018-01-08. juejin.cn/post/684490…
[14] J_Knight_. 《Effective Objective-C》干货三部曲(二):规范篇. 掘金,2018-01-10. juejin.cn/post/684490…
[15] J_Knight_. 《Effective Objective-C》干货三部曲(三):技巧篇. 掘金,2018-01-12. juejin.cn/post/684490…

老司机 iOS 周报 #365 | 2026-03-02

ios-weekly
老司机 iOS 周报,只为你呈现有价值的信息。

你也可以为这个项目出一份力,如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们,我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

新手推荐

🐎 Swift Package Manager Mirrors for Local Development

@BluesJiang: 文章介绍了 Swift Pacakge Manager 的 Mirrors 的用法。当在开发时,可以在使用命令行,临时将 Package.swift 中声明的依赖从分发地址映射到本地仓库或者其他地址。不再需要手动的修改链接地址,并且还要在提交时刻意改回来或者不提交改动。是一个很好用的功能。

文章

🌟 🐕 Ioser 铭(iOS 开发 2015-2025)

@邦 Ben:看着 Ioser 著名 iOS 梗,以及「孙源(sunnyxx)」,「郭耀源(ibireme)」的「YYKit」,「唐巧」的《iOS 开发进阶》成为必读书目,「喵神王巍(onevcat)」的 OneV's Den,「Casa Taloyum(casatwy)」的组件化架构方案「Bang」的 JSPatch,「雷纯锋」分享的 MVVM 和 RAC 实践,「limboy」的技术思考,小虾等前辈在技术会议上分享等等,熟悉感拉满的名字,都看恍惚了。这十年里苹果生态的变化也大得很,从啃 UIKit、写 OC,到 Swift 慢慢成熟、SwiftUI 推出,再到空间计算一步步落地,新技术新框架换了一波又一波。但越干越明白,底层原理、扎实的工程能力从来没过时,不管技术怎么变,把问题拆透、把性能做优、把工程搭稳的核心思路一直没变。如今迈入 AI 时代,端侧智能、AI Agent 成为新方向,AI 也成了开发的好帮手,虽赛道不断拓展、工具持续升级,但本质的事情还是得持续迎向新事物学习,朋友们,一起加油,AI 时代有更好的机会。

🐕 How Apple Hooks Entire Frameworks

@Kyle-Ye: 文章深入分析了 Apple 如何通过 Method Swizzling 实现对整个框架的 hook,以 Main Thread Checker 为例,展示了其如何大规模替换数万个方法。作者介绍了基于 trampoline 的实现方案——为每个被 hook 的方法生成唯一的跳板函数,通过共享的汇编处理程序保存和恢复寄存器状态,再调用统一的回调。文章还探讨了如何通过运行时内存映射动态创建 trampoline 以突破数量限制,以及使用私有 API class_replaceMethodsBulk 批量替换方法以减少锁竞争从而提升性能。对于对 Objective-C Runtime 底层机制和性能优化感兴趣的开发者值得一读。

🐕 Should You Use All These Dependencies?

@Barney:从 iOS 项目依赖选择角度出发,作者以项目中仅用到 3 处 RxSwift 却引入 3MB 体积与编译成本为例,讨论“能不用库就不用”的默认立场。核心内容包括:

  • 决策标准:评估收益、迁移成本、团队熟悉度与长期维护负担,避免因熟悉而引入不必要抽象
  • 案例对比:以 Alamofire vs URLSession 说明第三方并非总是更省时,功能范围与实际需求应匹配
  • 风险控制:建议使用 Wrapper/Facade、版本锁定与定期依赖审计(工具 + 清单)降低锁定与弃坑风险

最后强调每个依赖都是“当下效率”与“未来债务”的权衡,适合建立团队的依赖准入与清理流程。

🐕 CKSyncEngine questions and answers

@AidenRao:苹果在 WWDC23 带来的 CKSyncEngine 毫无疑问是近年来最优秀的 API 之一,它将复杂的云同步逻辑大幅简化。但官方文档之外,仍有大量实践细节亟待探索。知名应用 Apollo 和 Pixel Pals 的作者 Christian Selig 近期分享了他在集成 CKSyncEngine 过程中的一系列实战问答。本文并非入门教程,而是围绕冲突解决、数据模型兼容、状态管理、错误处理等开发者必然会遇到的具体问题,提供了清晰的解决方案和代码示例。如果你正考虑为你的应用添加健壮的 CloudKit 同步能力,这份来自一线开发者的经验总结将极具价值。

工具

Happy:为 Codex/Claude Code 提供无缝的移动端交互

Happy (Happy Coder) 是一款开源的第三方配套应用,旨在为 Claude Code (以及 OpenAI Codex) 提供无缝的移动端交互体验。它并不是要取代你的桌面环境,而是通过“远程中继”方案,让你在离开工位时也能通过手机完全掌控 AI 的编程进度:

  • 无感切换 (Seamless Handoff):在电脑终端运行 happy 启动 Claude。当你合上电脑出门时,打开手机 App 即可实时接管刚才的对话和代码上下文,状态完全同步。
  • 权限即时推送:Claude Code 在执行高风险操作(如删除文件、运行复杂脚本)时需要授权。有了 Happy,你的手机会收到推送通知,点击即可远程“允许”或“拒绝”,无需死守在屏幕前。
  • 实时语音协作:集成了语音交互功能。你可以像跟真人交互一样直接发语音,在走路或通勤时向 Claude 描述需求,看着它在远程电脑上自动写代码。
  • 端到端加密 (E2E):安全性是其核心。它采用类似 Signal 的加密协议,代码和对话在传输前即在本地加密,开发者服务器无法读取你的任何代码内容。

内推

重新开始更新「iOS 靠谱内推专题」,整理了最近明确在招人的岗位,供大家参考

具体信息请移步:https://www.yuque.com/iosalliance/article/bhutav 进行查看(如有招聘需求请联系 iTDriverr)

关注我们

我们是「老司机技术周报」,一个持续追求精品 iOS 内容的技术公众号,欢迎关注。

关注有礼,关注【老司机技术周报】,回复「2024」,领取 2024 及往年内参

同时也支持了 RSS 订阅:https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom

说明

🚧 表示需某工具,🌟 表示编辑推荐

预计阅读时间:🐎 很快就能读完(1 - 10 mins);🐕 中等 (10 - 20 mins);🐢 慢(20+ mins)

Star Trek : Captain's Chair 初体验

今年过年,我沉迷于 Star Trek : Captain's Chair 这款 2025 年的桌游。暂时还没有中文版,如果直译的话,名为《星际迷航:船长之椅》。这是一款以卡牌构筑为核心玩法的桌游,在游戏过程中,不断完善自己的牌堆,构筑一个高效的得分引擎。如果能比对手获得更多的 VP 就可以获得游戏胜利,但也要避免突然死亡。这是一款新游戏,但作者 Nigel Buckle 和 David Turczi 之前已经用类似的系统出过 Imperium (帝国)三部曲。其中《帝国:经典版》和《帝国:传奇版》有中文版,在淘宝上就可以买到。btw, 前段时间我玩过的 VoidFall 也是他们的作品。

这个游戏的规则还是挺复杂的,在 BGG 上的 weight 评级达到了 4.06 。注:游戏的重度(weight)是由玩家评分综合而来,最高为 5 。它指的是规则的繁杂程度,而并非游戏的策略深度(通常有相关性)。例如围棋虽然策略深度几乎达到了桌游的天花板,但它的 weight 就不到 4 。而 bgg 上 weight 超过 4 的游戏并不多见,大部分超过 3 的桌游,一般就被归为重度游戏了。我大概花了 10 多个小时试玩,看了几个小时的教学视频,才感觉学会了游戏的基本规则。不过一旦理解了游戏的设计逻辑,玩起来还颇为流畅,规则书以及规则助记版都非常符合直觉,简单好认。重度游戏大多不太讨人喜欢,但设计良好的重度游戏也能带来更多乐趣。

我认为 ST:CC 是我这些年玩过的所有卡牌构筑类桌游中机制、策略和局势变化最丰富的。它提供了及其丰富的机制让玩家控制牌组的构成,这也是“构筑”这个机制的核心玩点。和最早的《Dominion 领土》作比较:这类游戏的基本玩法就是从市场购买新卡,构建一个得分引擎。分往往也体现在牌组中,但会稀释行动牌的价值(通常分卡在游戏过程中没有收益),让玩家在构筑过程中做出权衡。Dominion 每局游戏的后期通常会面对厚厚的牌堆,行动会变得越来越不可预测。后来的同类游戏逐步加入了更丰富的机制来帮助卡组瘦身,提供给玩家更多确定性,更好的控制自己的行动。

ST:CC 以及它的前身 Imperium 提供了非常丰富的卡组瘦身机制:

  1. 可以把卡堆里的牌 LOG 起来:和早期卡牌构筑游戏不同,得分卡并不是专门的卡,而是每张卡本身就带有 VP 。这更像银河竞逐这样的引擎构建游戏。收集的卡越多得分越高。LOG 可以把当局游戏不再用的卡从当前卡堆里移除,但得分依旧保留。

  2. 可以把卡片 deploy 到桌面:放在桌面的卡可以提供持久的被动能力,也可以有限的提供主动能力或响应能力。同时,活动卡组也得到的瘦身。根据卡片属性不同,提供有差异的回收规则。船员卡可以常驻一张,新的船员卡晋升后 dismiss 旧的;飞船卡则在占领星球后自动 dismiss ;事件卡则每张有不同的回收前置行动(不回收会在游戏结束结算时计为负分)。

  3. 卡片可以 beam 到飞船或星球上:这可以对卡组作更灵活的临时瘦身。几乎所有的飞船都有主动能力可以 beam 手牌,但反向回到手牌的 recall 操作却比较稀少。不过,beam 在飞船上的卡也可以随飞船 dismiss 而一同回到弃牌堆。

永久(不可逆)和临时(可收回)的卡牌瘦身操作,可以让玩家在游戏过程中动态的调整卡组,让游戏的确定性更高,而不会在抽牌堆太大时,过于依赖抽卡的手气。就我这几天玩的数盘游戏体验,通常我的活动牌组(抽牌堆加上弃牌堆和手牌)在整局游戏里也很少超过 20 张。

ST:CC 在游戏过程中的卡组升级也有新意。

首先,和大多数卡牌构筑游戏一样,初始卡组是 10 张左右,每轮抽 5 张。这样可以保证前两轮可以作一个轮回,让随机性限制在 10 张卡的不同组合上。但和之前的很多游戏不同,它的 10 张卡是完全不同的,每张都特别设计过。甚至游戏带了 6 套风格迥异的初始牌组。而传统上的设计更偏好在初始卡组中放上雷同的初始能力卡,加上很少量的特殊卡。如果没玩过桌游的话,可以对比杀戮尖塔这样受桌游启发的电子游戏:一开始的初始卡组中只有一张特殊能力卡加上普通的打击和防御。

而和一般的卡牌构筑游戏的升级流程不同,它会为每个初始牌组设计 5 张左右的固定补充卡堆和 8 张左右的高级补充卡,以固定节奏补充进来:每次抽牌堆抽空都会自动触发这个补充操作,加入一张额外的补充卡。基本的补充卡的随机性在于每局游戏的进入次序是打乱的,而高级卡则需要用不同资源购买,但可以让玩家指定(没有抽卡的随机环节)。这样熟练牌组的玩家可以预先学习好每个角色牌组的策略,再实际玩的时候又不至于形成太固定的套路。

游戏依然提供公共市场和供双方争夺的中立地点卡。但很多传统的市场机制是用资源从市场买卡,而 SC:CC 并不通过积累资源购买市场卡,而是改为用特定行动卡片直接获取。市场被分为了四类:船员、货物、飞船、盟友,分别对应不同的行动卡去获取。根据选择的初始牌组不同,获取这些市场卡的行动卡使用方式也不一样。由于行动力有限,规划行动的分配获取市场卡就变成了卡片 combo 重要的一环。玩家很难积累获取市场卡的能力,抢夺地点卡更是这样:规则限制了每个回合最多只能获得一个中立地点。整局游戏中不会获得太多的额外卡片,且每张公共卡都是单独设计的,这让引入每张卡到自己的卡组都需要仔细规划。

ST:CC 的卡片被设计成一卡多用。卡片处于不同位置:从手牌打出或桌面上激活会有不同的能力。而即使是同一种方式使用它,一般也有多种能力供选择,只能选其一使用。虽然每种使用方式大多有前置条件或副作用,但本身的多种选择让每张卡片在不同场景下都有用。

因为卡片的位置非常丰富:除了传统的抽牌堆、弃牌堆、手牌外,还有桌面区、市场区、当前市场、市场库存、中立地、废牌堆、附着在其它卡片上、LOG 区、升级区、事件区等等。就我主要玩的 PICARD 牌阵来说,大量的行动就是将卡在这些这些区域之间调度。所以在玩的时候,有一点工人分配游戏的感觉。不仅提供了丰富的卡牌策略,还非常好的契合了星际迷航那种驾驶飞船探索宇宙的主题。


为了让游戏不限于千篇一律的构建得分引擎循环,游戏给每个牌组都设计了不同主题的任务。任务不同于很多引擎构建游戏的终局任务卡,那个在 ST:CC 里也有,被设计为 Encouter 卡片,通常可以提供大笔的 VP 。任务就是固定在每个初始卡组上的,像是堆每组不同风格的牌作一个游戏引导,引导在游戏过程中侧重某种玩法。例如,PICARD 的基本任务就是获得三张同盟卡,并把他们都 beam 到同一艘飞船上,且获得至少 4 点科技点和 4 点影响力,就可以完成。

这个设计不会让玩家(熟悉后)玩游戏时不会走一步看一步,每步寻找当下行动的利益最大化。玩家必须作一个长远规划:因为任务必不可少的需要分成很多步骤,同步相当多的行动在好几个回合才可能达成。以我玩的经验来看,基本任务一般在游戏中后期才可以达成,而以开始不作计划的话,常常忙到快结束时还差上一点点。

由于只靠固定牌组很难有效的完成任务,随机出现的公共牌加入卡组都能带来意想不到的高效组合,所以每局游戏的过程都会差异很大。我用 PICARD 玩了 3,4 局游戏,都选的 KOLOTH 这个 bot ,但每局游戏体验完全不同。更别说换掉对手会有完全不同的局面。游戏为每个舰长的 bot 定制了不同的自动化策略来模拟人类玩家选择不同舰长会出现的不一样的打牌倾向。

这是一个两人对战游戏,但也可以用设计好的自动化规则来模拟一个对手。但在 BGG 上,大多数玩家认为这个单人对抗 bot 的玩法更好玩。游戏的教学作的不错,提供了一个更存粹没有对手的单人模式,通常用于熟悉牌组。这个教学模式就是无干扰的刷分,刷够足够的分就胜利了。通过玩这个模式,可以体验不同舰长牌风格迥异的 combo 策略。通常建议把 6 个舰长都刷够分,这样在对战时既能知道自己应该怎么玩,还能熟知对手的策略。

正式的单人模式是对抗固定规则的对手。采用的是不对称规则:玩家和 bot 的行动法则是不一样的。我没有玩过对战模式,但据 BGG 论坛玩家的反馈,预设规则把和真人玩家的对抗时会产生的交互:争夺市场卡片、抢占中立地点等模拟的很好。一开始玩的时候,操作 bot 很容易出错,但玩过一盘之后就非常顺畅了,bot 每个回合一两分钟就能操作完,反之自己这边的行动每个回合会花很长时间。可想而之,和人对战应该会有极大的 downtime ,怪不得大多数人都选择了单人 solo 。

但我觉得,如果有个人类对手和自己一样玩过很多盘 solo 的话,再在一起对战应该也是非常有趣的。

官方还为单人模式设计了一个长线的五年计划规则。让玩家可以连着玩 5~10 盘游戏,在每盘游戏间加入了牌组升级:每次胜利都可以加入当局游戏终局时的某张市场卡进入初始牌组,或是 boost 一些初始能力。由于游戏设计了 6 组不同的牌,这相当于需要击败 5 个不同的对手(自动化 bot ),想来不会有太多重复感。我打算熟悉玩所有卡组后就尝试一下这个长线任务,应该会很有趣。


很想买一套实体版,但在淘宝上找不到代购,甚至目前美国那边也缺货等着重印。我这几天都是在桌面模拟器上玩的(有玩家制作的 mod )。我的感觉是,由于电子版缺少触感,细节更容易玩错。即使很熟悉后,游戏效率还是比不上实体。这点和版图游戏颇为不同,这个几乎全部用卡牌作道具,假若是实体牌的话,电子版只在洗牌时会便利一点,打牌及查看牌面要麻烦很多。而很多版图游戏,电子模拟器在 setup 以及游戏过程中的摆放都会更方便。

作为 solo 游戏,实体版最方便的地方在于易于反悔。只要没有信息揭示环节(例如抽牌后查看),大多数行动你都可以方便的在牌桌上 undo ,尝试各种不同的组合。电子模拟器上的 undo 操作一不小心就把桌面状态弄乱了。毕竟桌游除了桌面,人脑里还有一整套游戏状态,缺少实体会让大脑负荷要重得多。


谈点体外话。由于这款游戏规则相对繁杂,我尝试用 AI 辅助学习游戏规则,使用的 Gemini 。可惜这个游戏还太新,网上资料太少。导致 Gemini 对游戏规则细节知之甚少。但它又表现得很懂,对话中自信满满。我问了很多规则细节结果都是错的,即使我让它指出细节出至规则书上具体哪里,也全是幻觉。甚至引用论坛网友的讨论也能理解错误。最后,我还是得自己推敲规则书,或是用传统的搜索方法找到 bgg 论坛规则讨论版面的帖子,研读作者写的 FAQ 等等。和 AI 的问答阅读起来固然舒服,针对性很强(不像规则书读起来那么累),但我实在没有能力鉴别 AI 的错误。毕竟我原本就是因为不懂规则才去问的呀。

有些错误还是能看出来。毕竟我玩的游戏很多,可以从作者的游戏设计思路角度去考虑。玩的过程中有疑问去问 AI 。对反直觉(感觉游戏不应该这样设计)的答案有所警惕,可继续追问。但有些真看不出来。

比如我在和 bot 对战时,触发了一条 bot 需要 log 一艘飞船,我不知道该如何处理。(特地用英文术语)问了下 AI 。AI 告诉我应该把最近 bot 部署的 ship 卡 log 起来,并将同一地区的所有外派部队收回。但后一条是 AI 自己编的规则,我在规则书中怎么都找不到对应的文字。反复询问,AI 都表现的信誓旦旦。让我去查规则书某个章节(其实不存在)。它还引用了 BGG 论坛的帖子。而我仔细研读了大篇的帖子后,确定是 AI 混淆了 log 和 dismiss 的处理方法。

结果,我和 AI 的这番对话并没有帮我节省理解规则的时间。不仅自己重新反复研究规则书,还花了更多时间去论坛看帖(当然这不是坏事)。我想,如果我让一个人类游戏玩家教我,若是自己没怎么玩这个游戏的话,都不会表现的如此自信吧。如何辨别 LLM 提供的信息中哪些确有价值会变得更加重要。LLM 的语言表达能力越来越强,也会变得越来越有欺骗性。

SwiftUI路由管理架构揭秘:从混乱到优雅的蜕变

引言

想象一下:当你打开一个 App,点击不同标签页,切换页面时,所有导航状态都能完美保持;当你从详情页返回时,TabBar 能智能地重新出现;当你需要传递数据时,类型安全的导航能让你告别字符串硬编码的烦恼。这一切,都离不开一个优秀的路由管理架构。

在现代 iOS 应用开发中,路由管理常常被视为"基础设施"而被忽视,但其重要性却不亚于任何核心功能。一个设计良好的路由系统,不仅能让代码结构更清晰,还能显著提升用户体验。今天,我将带大家深入剖析我项目中的路由管理架构,分享从设计到实现的全过程,希望能为你的项目带来启发。

路由架构概览

我项目的路由管理基于 SwiftUI 的 NavigationStackNavigationPath,采用了集中式的路由管理方案。核心组件包括:

  • Router 类:全局导航路由器,管理所有 Tab 的导航路径
  • MainTab 枚举:定义应用的标签页结构
  • MainContainerView:主容器视图,负责整合标签页和导航逻辑
  • App 启动注入:在应用启动时将 Router 注入到环境中

路由的启动注入

EviApp.swift 中,我们通过 @StateObject 创建 Router 实例,并通过 environmentObject 将其注入到应用环境中:

import SwiftUI

@main
struct EviApp: App {
    // 把 AppDelegate 接进来,系统会照常调用 didFinishLaunchingWithOptions 等
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()
    
    var body: some Scene {
        WindowGroup {
            MainContainerView()
                .environmentObject(overlay)
                .environmentObject(router)
        }
    }
}

这样,在应用的任何视图中,都可以通过 @EnvironmentObject 来访问 Router 实例,实现全局路由管理。

核心组件分析

1. Router 类:路由管理的核心

import SwiftUI

/// 全局导航路由器,管理所有Tab的导航路径
class Router: ObservableObject {
    
    // 当前选中的Tab
    @Published var selectedTab: MainTab = .home
    
    // 为每个tab单独存储NavigationPath
    @Published var homePath = NavigationPath()
    @Published var hotPath = NavigationPath()
    @Published var creationPath = NavigationPath()
    @Published var stylePath = NavigationPath()
    @Published var profilePath = NavigationPath()
    
    // MARK: - 获取导航路径
    
    /// 获取指定tab的导航路径
    func getNavigationPath(for tab: MainTab) -> NavigationPath {
        switch tab {
        case .home: return homePath
        case .hot: return hotPath
        case .creation: return creationPath
        case .style: return stylePath
        case .profile: return profilePath
        }
    }
    
    /// 获取指定tab的导航路径绑定
    func getNavigationPathBinding(for tab: MainTab) -> Binding<NavigationPath> {
        switch tab {
        case .home: return binding(for: \.homePath)
        case .hot: return binding(for: \.hotPath)
        case .creation: return binding(for: \.creationPath)
        case .style: return binding(for: \.stylePath)
        case .profile: return binding(for: \.profilePath)
        }
    }
    
    // MARK: - 清空导航路径
    
    /// 清空指定tab的导航路径
    func clearPath(for tab: MainTab) {
        switch tab {
        case .home: clear(\.homePath)
        case .hot: clear(\.hotPath)
        case .creation: clear(\.creationPath)
        case .style: clear(\.stylePath)
        case .profile: clear(\.profilePath)
        }
    }
    
    /// 清空所有导航路径
    func clearAllPaths() {
        clear(\.homePath)
        clear(\.hotPath)
        clear(\.creationPath)
        clear(\.stylePath)
        clear(\.profilePath)
    }
    
    // MARK: - 当前Tab操作
    
    /// 获取当前选中Tab的导航路径
    func getCurrentNavigationPath() -> NavigationPath {
        return getNavigationPath(for: selectedTab)
    }
    
    /// 获取当前选中Tab的导航路径绑定
    func getCurrentNavigationPathBinding() -> Binding<NavigationPath> {
        return getNavigationPathBinding(for: selectedTab)
    }
    
    /// 清空当前选中Tab的导航路径
    func clearCurrentPath() {
        clearPath(for: selectedTab)
    }
    
    // MARK: - 私有辅助方法
    
    /// 创建导航路径的绑定
    private func binding(for keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) -> Binding<NavigationPath> {
        Binding {
            self[keyPath: keyPath]
        } set: {
            self[keyPath: keyPath] = $0
        }
    }
    
    /// 清空指定的导航路径
    private func clear(_ keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) {
        self[keyPath: keyPath].removeLast(self[keyPath: keyPath].count)
    }
}

设计亮点

  • 集中管理:所有路由逻辑集中在一个类中,便于统一管理
  • Tab 隔离:为每个标签页维护独立的导航路径,确保切换标签时不会影响其他标签的导航状态
  • 响应式设计:使用 @Published 修饰符,实现路由状态的自动更新
  • 便捷方法:提供了丰富的方法来操作导航路径,如获取路径、清空路径等

2. MainTab 枚举:标签页定义

import SwiftUI

/// 主标签栏枚举
enum MainTab {
    case home
    case hot
    case creation
    case style
    case profile
}

extension MainTab {
    
    /// 根据选中状态返回对应的图标名称
    func iconName(isSelected: Bool) -> String {
        switch self {
        case .home:
            return isSelected ? "tabbar_home_sel" : "tabbar_home_nor"
        case .hot:
            return isSelected ? "tabbar_hot_sel" : "tabbar_hot_nor"
        case .creation:
            return "tabbar_add"
        case .style:
            return isSelected ? "tabbar_style_sel" : "tabbar_style_nor"
        case .profile:
            return isSelected ? "tabbar_me_sel" : "tabbar_me_nor"
        }
    }
}

设计亮点

  • 类型安全:使用枚举定义标签页,避免了字符串硬编码
  • 扩展功能:通过扩展为枚举添加了获取图标名称的功能,使代码更整洁

3. MainContainerView:路由的实际应用

import SwiftUI

/// 主容器视图,包含悬浮TabBar
struct MainContainerView: View {
    
    // 获取指定tab的导航路径
    private func getNavigationPath(for tab: MainTab) -> NavigationPath {
        return router.getNavigationPath(for: tab)
    }
    
    /// 创建带有NavigationStack的标签页视图
    private func tabView(_ tab: MainTab) -> some View {
        NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
            switch tab {
            case .home:
                HomeView()
            case .hot:
                HotHomeView()
            case .creation:
                CreationHomeView()
            case .style:
                StyleHomeView()
            case .profile:
                ProfileHomeView()
            }
        }
        .tag(tab)
    }
    
    @StateObject private var appConfigManager = AppConfigManager.shared
    
    @EnvironmentObject private var overlay: GlobalOverlayManager
    @EnvironmentObject private var router: Router
    
    var body: some View {
        if appConfigManager.appConfig != nil {
            ZStack {
                
                // 真正负责页面生命周期的容器
                TabView(selection: $router.selectedTab) {
                    tabView(.home)
                    tabView(.hot)
                    tabView(.creation)
                    tabView(.style)
                    tabView(.profile)
                }
                
                // 你的悬浮TabBar,根据当前选中标签的导航路径长度控制显示
                if isTabBarVisible {
                    VStack {
                        Spacer()
                        FloatingTabBar(selectedTab: $router.selectedTab)
                            .padding(.horizontal, 16)
                            .padding(.bottom, 20)
                    }
                }
                
                // 全局弹框显示
                if let current = overlay.current {
                    
                    // 遮罩
                    Color.black.opacity(0.4)
                        .ignoresSafeArea()
                        .onTapGesture {
                            overlay.dismiss()
                        }
                    
                    switch current {
                    case .login:
                        LoginOverlayView(onClose: {
                            overlay.dismiss()
                        })
                        .transition(.flipFromBottom)
                    }
                }
                
            }
            .animation(.easeInOut(duration: 0.25), value: overlay.current)
        } else {
            // 显示空View
            EmptyView()
                .background(ThemeManager.Background.global)
        }
    }
    
    var isTabBarVisible: Bool {
        return getNavigationPath(for: router.selectedTab).count == 0
    }
}

设计亮点

  • NavigationStack 集成:为每个标签页创建独立的 NavigationStack
  • TabBar 智能显示:根据当前导航路径长度控制 TabBar 的显示/隐藏
  • 环境对象注入:使用 @EnvironmentObject 注入 Router,实现全局访问
  • 动画效果:添加了平滑的过渡动画,提升用户体验

路由管理的实现细节

1. 路径管理机制

路由系统的核心是 NavigationPath 的管理。NavigationPath 是 SwiftUI 4.0+ 引入的类型,它是一个类型擦除的容器,可以存储任意类型的导航目的地。

在我们的实现中:

  • 每个标签页都有自己的 NavigationPath 实例
  • 通过 getNavigationPathBinding 方法获取路径的绑定,用于 NavigationStack
  • 提供了 clearPathclearAllPaths 方法来清空导航路径

2. 标签页切换逻辑

当用户切换标签页时:

  1. router.selectedTab 的值会更新
  2. TabView 会根据新的 selectedTab 显示对应的标签页
  3. 由于每个标签页有独立的 NavigationPath,切换标签不会影响其他标签的导航状态

3. 导航路径的实际使用

在具体的视图中,可以通过以下方式使用路由:

// 在视图中注入 Router
@EnvironmentObject private var router: Router

// 使用全局路由管理进行导航
let currentPath = router.getCurrentNavigationPathBinding()
// 向当前路径添加新页面
currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material))

// 清空当前标签页的导航路径
router.clearCurrentPath()

4. 导航目的地定义

项目使用 AppNavigationDestination 枚举来定义导航目的地:

import Foundation
import SwiftUI

/// 导航目标枚举
enum AppNavigationDestination: Hashable {
    case accountLogin
    case materialDetail(MaterialListDTOElement)
}

这种方式的优势:

  • 类型安全:使用枚举定义导航目的地,避免了字符串硬编码
  • 参数传递:可以在导航时传递相关数据,如 materialDetail 中的 MaterialListDTOElement
  • 可扩展性:可以轻松添加新的导航目的地

5. NavigationStack 中处理导航目的地

在使用 NavigationStack 时,需要处理导航目的地的显示逻辑。通常在根视图中添加 navigationDestination 修饰符:

NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .accountLogin:
                AccountLoginView()
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            }
        }
}

这样,当我们通过 currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material)) 导航时,NavigationStack 会自动显示对应的目标视图。

6. 完整导航流程示例

下面是一个完整的导航流程示例,展示从触发导航到显示目标页面的全过程:

// 1. 在视图中注入 Router
@EnvironmentObject private var router: Router

// 2. 定义导航触发事件
Button("查看素材详情") {
    // 3. 获取当前路径绑定
    let currentPath = router.getCurrentNavigationPathBinding()
    // 4. 向路径添加导航目的地
    currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(selectedMaterial))
}

// 5. 在根视图中处理导航目的地
NavigationStack(path: router.getNavigationPathBinding(for: .home)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            default:
                EmptyView()
            }
        }
}

// 6. 从详情页返回
Button("返回") {
    // 清空当前路径,返回根视图
    router.clearCurrentPath()
}

7. 导航路径与 TabBar 显示的关联

MainContainerView 中,通过 isTabBarVisible 计算属性控制 TabBar 的显示:

var isTabBarVisible: Bool {
    return getNavigationPath(for: router.selectedTab).count == 0
}

当导航路径为空时(即处于标签页的根视图),显示 TabBar;当导航路径不为空时(即进入了子页面),隐藏 TabBar,为用户提供更大的内容显示区域。

优势与最佳实践

优势

  1. 清晰的职责分离:路由逻辑与 UI 逻辑分离,使代码更易于维护
  2. 类型安全:使用枚举和类型化的导航路径,减少运行时错误
  3. 状态管理:集中管理路由状态,避免状态分散
  4. 灵活性:可以轻松添加新的标签页和导航目的地
  5. 用户体验:标签页切换时保持各自的导航状态,提升用户体验

最佳实践

  1. 统一的路由入口:所有导航操作都通过 Router 进行,避免直接操作 NavigationPath
  2. 合理的路径清理:在适当的时机清理导航路径,避免内存占用过高
  3. 导航目的地的类型定义:为导航目的地创建明确的类型,提高代码可读性
  4. 错误处理:添加适当的错误处理,确保导航操作的稳定性
  5. 测试:为路由逻辑编写单元测试,确保其正确性

代码优化建议

  1. 导航目的地类型化

    // 建议为每个标签页创建导航目的地枚举
    enum HomeDestination {
        case detail(id: String)
        case search
    }
    
    // 然后在导航时使用
    router.homePath.append(HomeDestination.detail(id: "123"))
    
  2. 添加导航日志

    // 添加导航日志,便于调试和分析用户行为
    func appendToPath(_ value: some Hashable, for tab: MainTab) {
        let path = getNavigationPathBinding(for: tab)
        path.wrappedValue.append(value)
        print("Navigate to \(value) in tab \(tab)")
    }
    
  3. 导航路径持久化

    // 可以考虑在应用进入后台时保存导航状态,在应用启动时恢复
    func saveNavigationState() {
        // 保存导航状态到 UserDefaults 或其他存储
    }
    
    func restoreNavigationState() {
        // 从存储中恢复导航状态
    }
    
  4. 添加路由拦截器

    // 可以添加路由拦截器,用于处理登录验证等场景
    func appendToPath(_ value: some Hashable, for tab: MainTab) {
        if needsAuthentication(for: value) {
            // 显示登录界面
            overlay.present(.login)
        } else {
            let path = getNavigationPathBinding(for: tab)
            path.wrappedValue.append(value)
        }
    }
    

总结

通过以上分析,我们可以看到,一个良好的路由管理架构对于 iOS 应用的重要性。我项目中的路由架构采用了集中式管理、Tab 隔离、响应式设计等原则,通过 Router 类、MainTab 枚举和 MainContainerView 的配合,实现了清晰、灵活、用户友好的导航体验。

这种路由架构不仅适用于当前项目,也可以作为其他 SwiftUI 项目的参考。通过不断优化和扩展,可以构建更加完善的路由系统,为用户提供更加流畅的应用体验。

希望这篇文章能够帮助大家更好地理解和实现 iOS 项目中的路由管理架构。如果你有任何问题或建议,欢迎在评论区留言讨论!

Flutter调试组件:打印任意组件尺寸位置信息 NRenderBox

一、需求来源

当页面元素特别多,比较杂,又必须获取某个组件尺寸位置时,一个个加 GlobalKey 有太麻烦,这是使用一个封装好的组件就特别有用了。然后就有了 NRenderBox 组件,可以打印出子组件的位置及尺寸。

二、使用

NRenderBox(
  child: Container(
    padding: EdgeInsets.symmetric(horizontal: 8, vertical: 4),
    decoration: BoxDecoration(
      color: Colors.transparent,
      border: Border.all(color: Colors.blue),
      borderRadius: BorderRadius.all(Radius.circular(0)),
    ),
    child: Column(
      mainAxisSize: MainAxisSize.min,
      children: [
        NNetworkImage(
          width: 50,
          height: 60,
          url: AppRes.image.urls.random ?? '',
        ),
        Text("选项"),
      ],
    ),
  ),
)
flutter: NRenderBox rect: Rect.fromLTRB(88.5, 322.0, 157.5, 413.0)

三、NRenderBox源码

import 'package:flutter/material.dart';

/// 点击打印尺寸
class NRenderBox extends StatefulWidget {
  const NRenderBox({
    super.key,
    required this.child,
  });

  final Widget child;

  @override
  State<NRenderBox> createState() => _NRenderBoxState();
}

class _NRenderBoxState extends State<NRenderBox> {
  final renderKey = GlobalKey();

  RenderBox? get renderBox {
    final ctx = renderKey.currentContext;
    if (ctx == null) {
      return null;
    }
    final box = ctx.findRenderObject() as RenderBox?;
    return box;
  }

  Offset? get renderPosition {
    return renderBox?.localToGlobal(Offset.zero);
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      key: renderKey,
      onTap: () {
        if (renderBox == null) {
          return;
        }
        final position = renderPosition;
        final size = renderBox!.size;
        final rect = Rect.fromLTWH(position!.dx, position.dy, size.width, size.height);
        debugPrint("$widget rect: $rect");
      },
      child: widget.child,
    );
  }
}

github

苹果谷歌商店:如何监控并维护用户评分评论

前阵子,我无意中发现我们的应用在 App Store 上悄然出现了几条差评,但团队里似乎没人注意到。这让我意识到一个严重的问题:如果我们不能及时听到用户的声音,怎么能及时发现应用的不足,留住用户呢? 更令人担忧的是,潜在用户在下载前往往会浏览评论区,一条未被回应的负面评价,可能就足以让他们转身离开,影响新增转化。

如果能在用户留下评论(尤其是差评)的第一时间收到通知,我们就能快速响应、修复问题、安抚情绪,甚至将一次不满转化为一次忠诚度的提升。更重要的是,积极、真诚地回复用户评论,不仅能展现团队的专业与负责,还能向所有观望者传递一个信号:我们在乎每一位用户。

本篇文章将从实操角度出发,为不熟悉苹果和谷歌开发者后台的开发或运营同学,讲解如何监控苹果谷歌商店的评分评论,以及如何回复用户评论,为大家提供一些帮助。

一、苹果

苹果开发者后台 appstoreconnect.apple.com/,需要 客户支持 权限。

1、如何监控评分和评论

苹果后台目前不支持收到新的评分评论后邮件通知开发者。只支持“开发者回复”(当顾客编辑你已回复的评论时,你将收到电子邮件),如需开启“开发者回复”邮件通知,按下面步骤操作:

登录 App Store Connect。
点击右上角的用户头像,进入 “用户和访问”。
选择你的账户,在左侧菜单点击 “通知”。

Tips:“收到评分评论后邮件通知开发者”,这个功能在旧版 iTunes Connect 中曾经存在,但在新版 App Store Connect 中已被移除。猜测苹果可能不想开发者过度关注单条评分评论。

如果目前想要监控苹果商店的评分评论,有几个方案可参考:
1、使用官方的 App Store Connect App,每天刷一刷,自己主动去看。App内可以设置“接收用户评分”通知,但不确定现在还是否有效。
2、苹果官方提供了App Store Connect API,可以自己开发程序拉取用户评分,再进一步做监控。
3、滴答清单定个周期性提醒,每天上班打开商店详情瞅一眼,现在苹果上线了Web版AppStore了,瞅一眼也很方便。
4、借助第三方平台。

2、查看和回复用户评论

(1)通过网页端查看

登录苹果开发者后台,appstoreconnect.apple.com/

评分评论入口:分发 - 评分和评论 图片.png

点击“回复”可以回复用户评论
图片.png

(2)通过官方App "App Store Connect" 查看

iOS端下载地址:apps.apple.com/cn/app/app-…
(如果你搜不到可能是你手机系统版本太低了。没有安卓端。)

图片.png App Store Connect App核心功能:
-- 销售与趋势监控(查看 App 的下载量、销售额)
-- 版本状态管理(跟踪审核状态,回复审核)
-- 用户评论处理(查看和回复评论)

App Store Connect内查看评分及评论入口:
图片.png

3、重置总评分

发布新版本到 App Store 时(必须更包),你可以重置 App 总评分。重置后,你的 App Store 产品页面将显示说明,提示顾客 App 的总评分最近已重置。此说明将一直显示,直到有足够多的顾客对新版本进行了评分且页面出现新的总评分。

请注意,重置总评分并不会重置顾客评论,App Store 仍将继续显示历史的顾客评论

图片.png

二、Google

Google开发者后台 play.google.com/console/dev…,需要 用户反馈 权限。
“用户反馈”权限

1、如何监控评分和评论

Google官方支持收到新的评论后邮件提醒开发者,并支持按应用、评分星级设置不同的提醒开关。注意:邮件提醒默认是关闭的,需要手动开启。请按下列步骤操作。

Google开发者后台 - 设置 - 个人邮件通知(这个只会改你个人的通知设置,不会改整个团队的) 图片.png

按需将邮件提醒开关打开,修改后记得保存。
图片.png

如果你的账号拥有开发者账号下多个App的权限,默认是所有应用都给你发邮件,点击下图位置,可以选择哪些应用接收邮件。 图片.png

收到新的评论后,Google会给你推邮件,模板样式如下,包含了应用名称、评分星级、评论内容,不用打开Google后台就能看到评论内容,很方便。
注意:如果你接收了多个应用的邮件,请留意邮件标题里App的名字。

图片.png

2、查看和回复用户评论

(1)网页端

Google后台 - 应用 - 监控与改进 - 评分与评价。

Google后台的评论,Google会默认帮你翻译成你的语言,很贴心。如果你想看原始评论,点击“显示原评论”查看。你也可以在这里回复用户的评论。
图片.png

(2)官方 Google Play Console App

Google也像苹果一样,提供了官方的供开发者维护自己App的应用,Google Play Console App。你可以通过它在移动端方便的看评分和回复评论。

iOS端:apps.apple.com/cn/app/goog…
安卓端:play.google.com/store/apps/…

Google Play Console App

Google Play Console App 核心功能:

  • 查看数据指标:监控安装量、卸载量、更新量以及应用的崩溃率(ANR/Crash)。
  • 回复用户评论:及时查看并回复用户的评价,这对于维护 App 评分至关重要。
  • 订单管理:查看应用内购买和订阅的订单详情,甚至可以进行简单的退款操作。
  • 发布状态监控:跟踪应用版本的审核进度和发布状态。

3、Google不支持重置评分评论

Google不像苹果那样可以主动重置评分。虽然你不能手动重置,但 Google Play 的评分系统是动态权重的,更加偏重于近期(Recent)的用户评分权重会更高

这意味着:
(1)如果你的应用过去因为有 Bug 而评分很低,只要你在新版本中修复了问题,随着新用户和老用户在近期的好评增多,你的平均分会逐渐回升。
(2)时间是最好的解药:只要新版本的体验确实提升了,评分曲线会自动向好的方向修正。

三、结束语

其实维护应用商店的评论,并不需要多么复杂的流程或高深的技巧,但你做了和没做,用户感受是不一样的,每个人都希望被尊重,用真诚打动你的用户吧!

希望这篇文章能给你一点帮助。如果你有更好的监控方法,欢迎留言交流。

参考文档
【苹果官方文档】查看评分和评论

02-研究优秀开源框架@图层处理@iOS | Kingfisher 框架:从使用到原理解析

📋 目录


一、Kingfisher 概述与历史演进

1. 框架简介

Kingfisher 是一款面向 Apple 平台(iOS / macOS / tvOS / watchOS)的纯 Swift 异步图片下载与缓存库,由 onevcat(王巍)维护。其「图层处理」相关能力以 ImageProcessor 为核心:在「从数据到图像」以及「从图像到图像」的管线中,完成解码、缩放、圆角、模糊、着色等处理,并与 ImageCache(内存 + 磁盘)、ImageDownloader 协同,形成「请求 → 缓存查询 → 下载 → 处理 → 缓存 → 展示」的完整流程 [1][2]。

与 SDWebImage(Objective-C 为主)相比,Kingfisher 采用协议导向Options 模式,图层处理通过统一的 ImageProcessor 协议和 ImageProcessItem 双态输入抽象,便于扩展与组合。

2. 技术演进与版本脉络

Kingfisher 的图层处理能力随版本逐步增强,并与缓存、下载模块解耦清晰。

阶段 版本/时期 图层处理与相关能力
早期 3.x 基础下载与缓存,简单图片处理
缓存与处理器 3.10 带 ImageProcessor 的缓存策略:先查已处理图,若无再查原图,避免重复下载 [3]
架构升级 5.0 MemoryStorage / DiskStorage 分离,可缓存原始 Data,完善 KingfisherError,处理管线与缓存键绑定 [4]
下采样修复 5.3 下采样 scale 与内存表现修复:从原图加载下采样结果时的 scale 与内存问题 [5]
动图与序列化 7.8 磁盘缓存取回动图时正确使用请求中的 processor [6]
渐进式 JPEG 8.3 SwiftUI KFImage 支持 progressiveJPEG 修饰符 [7]

5.0 是重要分水岭:处理管线与缓存键(含 processorIdentifier)深度结合,使「同一 URL + 不同 Processor」对应不同缓存条目,原图与处理后图可并存。

3. 图层处理在整体架构中的位置

下图概括从「资源(URL / ImageDataProvider)」到「显示到视图」的流程,并标出 ImageProcessor 所在阶段。

flowchart LR
    subgraph 输入
        A[URL / ImageDataProvider]
    end
    subgraph 获取数据
        B[ImageDownloader / Provider.data]
    end
    subgraph 处理层
        C[Data]
        D[ImageProcessor 管线]
        E[KFCrossPlatformImage]
    end
    subgraph 缓存与输出
        F[ImageCache]
        G[ImageView / KFImage]
    end
    A --> B --> C --> D --> E --> F --> G

要点

  • ImageProcessor 的输入可以是 Data(未解码)或 Image(已解码);输出为 Image。因此它同时覆盖「Data → Image」(如 DefaultImageProcessor、DownsamplingImageProcessor)和「Image → Image」(如 RoundCorner、Blur、Resizing)两类操作。
  • 处理在 KingfisherManager 协调下、通常在后台队列执行,避免阻塞主线程,符合 Apple 图像最佳实践 [8]。

二、图像处理管线(ImageProcessor Pipeline)

1. ImageProcessItem 与双态输入

Kingfisher 用 ImageProcessItem 表示处理器的输入,有两种情况 [9]:

public enum ImageProcessItem: Sendable {
    /// 已解码的图像,处理器在其上做几何/像素变换
    case image(KFCrossPlatformImage)
    /// 原始数据,处理器需负责解码(或解码+变换)
    case data(Data)
}

设计意图

  • 统一接口:同一套管线既可处理「仅解码」(Data → Image),也可处理「仅变换」(Image → Image),或「解码 + 变换」(Data 经多个 Processor 最终得到 Image)。
  • 避免重复解码:当管线中第一个 Processor 已将 Data 转为 Image 后,后续 Processor 收到 .image(...),只需做几何/滤镜等操作,无需再次解码。

数据流概念

flowchart LR
    subgraph 管线输入
        I[Data]
    end
    subgraph P1[Processor 1]
        I --> D1[解码/下采样]
        D1 --> O1[Image]
    end
    subgraph P2[Processor 2]
        O1 --> D2[圆角/缩放等]
        D2 --> O2[Image]
    end
    O2 --> Out[输出]

2. ImageProcessor 协议与标识符

ImageProcessor 协议是 Kingfisher 图层处理的核心抽象 [9][10]:

协议 ImageProcessor:
    属性 identifier: String   // 唯一标识,参与缓存键
    方法 process(item: ImageProcessItem, options: KingfisherParsedOptionsInfo) -> KFCrossPlatformImage?
  • identifier:相同功能/参数的 Processor 应返回相同字符串,用于缓存键。官方建议使用反向域名(如 com.onevcat.Kingfisher.RoundCornerImageProcessor(20)),且不要与 DefaultImageProcessor"" 冲突。
  • process:返回 nil 表示处理失败,管线会报错并中止;若输入已是 .image 且当前步骤可透传,可返回原图以继续后续 Processor。

伪代码:管线执行

函数 runPipeline(item: ImageProcessItem, processors: [ImageProcessor], options) -> Image?:
    current = item
    对每个 p in processors:
        若 current 为 .data 且 p 只支持 .image:
            current = .image(DefaultImageProcessor.default.process(current, options))
        若 current 为 nil: 返回 nil
        next = p.process(current, options)
        若 next 为 nil: 返回 nil
        current = .image(next)
    返回 current

许多内置 Processor(如 RoundCorner、Blur)在收到 .data 时,会先通过 DefaultImageProcessor.default |> self 将 Data 解码为 Image,再对 Image 做自身变换,从而复用同一套协议。

3. 下采样(Downsampling)与 Resizing 的区分

Kingfisher 明确区分两种「变小」的方式,对应不同的内存与 CPU 成本 [10][11]。

3.1 DownsamplingImageProcessor

  • 输入:仅 Data(压缩数据)。在解码阶段直接生成小尺寸位图,而不是先解码全图再缩放。
  • 实现:基于 ImageIO 的 CGImageSourceCreateThumbnailAtIndex,通过 kCGImageSourceThumbnailMaxPixelSize 等选项限制最大边长,在解码器内部只生成缩略图级像素缓冲。
  • 优势:内存占用与目标尺寸相关,避免「先全图解码」的峰值;大图列表、头像等场景推荐使用。

下采样算法步骤(与 Kingfisher / ImageIO 语义一致)

函数 Downsample(data: Data, size: CGSize) -> Image?:
    1. maxDimensionInPixels = max(size.width, size.height) * scale
    2. source = CGImageSourceCreateWithData(data, nil)
    3. options = {
         kCGImageSourceCreateThumbnailFromImageAlways: true,
         kCGImageSourceCreateThumbnailWithTransform: true,
         kCGImageSourceShouldCacheImmediately: true,
         kCGImageSourceThumbnailMaxPixelSize: maxDimensionInPixels
       }
    4. cgImage = CGImageSourceCreateThumbnailAtIndex(source, 0, options)
    5. 由 cgImage 构造 UIImage/NSImage 并返回

注意size 不能为 (0, 0),否则会触发 "Processing image failed. Processor: DownsamplingImageProcessor" [11];在列表 cell 中应使用 cell 或目标视图的 bounds 计算合理 size。

3.2 ResizingImageProcessor

  • 输入:一般为 Image(或通过 DefaultImageProcessor 先解码的 Data)。对已解码的位图做缩放,支持 ContentMode(如 aspectFit、aspectFill)。
  • 实现:在像素缓冲上做几何变换(绘制到目标尺寸),会先占用全图解码的内存,再产生缩放后的新缓冲。
  • 适用:已解码图、或必须对 Image 做精确尺寸/比例控制时使用;若从 Data 缩小,应优先 DownsamplingImageProcessor

对比小结

维度 DownsamplingImageProcessor ResizingImageProcessor
输入 Data Image(或 Data 经 Default 解码)
时机 解码时直接出小图 先解码全图再缩放
内存 与目标尺寸相关 先有全图峰值再缩放
典型场景 列表缩略图、头像 已解码图的尺寸/比例调整

4. 多处理器链式组合

Kingfisher 支持将多个 ImageProcessor 串联成一条管线,按顺序执行:前一个的输出作为后一个的输入(.image(...))[10]。

组合方式:通过 append(another:)|> 运算符(Kingfisher 在 ImageProcessor 扩展中定义 |> 为调用 append(another:)):

// 先模糊,再圆角
let processor = BlurImageProcessor(blurRadius: 4) |> RoundCornerImageProcessor(cornerRadius: 20)
imageView.kf.setImage(with: url, options: [.processor(processor)])

组合后的 identifier"\(p1.identifier)|>\(p2.identifier)",用于缓存键,保证「同一 URL + 同一处理器链」唯一对应一条缓存。

链式执行语义(伪代码)

函数 GeneralProcessor.process(item, options):
    image1 = self.process(item, options)
    若 image1 为 nil: 返回 nil
    返回 another.process(.image(image1), options)

因此,若链中第一个 Processor 能处理 .data(如 DefaultImageProcessor 或 DownsamplingImageProcessor),后续 Processor 将始终收到 .image(...)


三、解码、缓存与处理器的协同

1. 检索流程与缓存键

Kingfisher 的检索顺序可概括为 [2][3]:

  1. 使用 cacheKey + processorIdentifier内存缓存
  2. 若未命中,查磁盘缓存(同样 key + processorIdentifier);
  3. 若仍未命中,通过 ImageDownloaderImageDataProvider 获取 Data;
  4. 对 Data 执行 ImageProcessor 管线,得到 Image;
  5. 将结果写入内存与磁盘缓存,并交给视图或完成回调。

缓存键:缓存的唯一标识是 cacheKey + processorIdentifier(DefaultImageProcessor 的 identifier 为空字符串)。因此:

  • 同一 URL,不同 Processor(或不同链)会得到不同缓存条目
  • 原图(DefaultImageProcessor)与下采样/圆角等版本可并存
  • 判断或读取缓存时若请求中指定了非 Default 的 Processor,需传入相同 processorIdentifier,例如:cache.isCached(forKey: cacheKey, processorIdentifier: processor.identifier)cache.retrieveImage(forKey: cacheKey, options: [.processor(processor)], ...)
flowchart TD
    A[请求: URL + Processor] --> B[构造 cacheKey + processorIdentifier]
    B --> C{内存缓存?}
    C -->|命中| D[返回 Image]
    C -->|未命中| E{磁盘缓存?}
    E -->|命中| F[解码/反序列化]
    F --> D
    E -->|未命中| G[下载 / Provider]
    G --> H[Processor 管线]
    H --> I[写内存+磁盘]
    I --> D

2. CacheSerializer 与磁盘格式

CacheSerializer 负责「Image ↔ Data」在磁盘缓存中的序列化与反序列化 [10]:

  • 存储data(with:original:),将当前要缓存的 Image 转为 Data(可结合 original Data 决定格式);
  • 读取image(with:options:),将磁盘上的 Data 转回 Image。

调用时机(便于理解与扩展):

  • Processor.process:① 网络下载成功或 ImageDataProvider 返回 Data 后,将 Data 加工为 Image;② 从磁盘读取到原始 Data 后,先经 CacheSerializer 反序列化为 Image,再经 Processor 处理(若请求中指定了 Processor)。因此磁盘命中「已处理图」时直接返回,命中「原图」时会再走一次 Processor。
  • CacheSerializer.image:从磁盘读取到 Data 后,用于将 Data 反序列化为 Image。
  • CacheSerializer.data:需要写入磁盘时,将 Image 序列化为 Data 再落盘。

默认行为:尽量保持原始数据格式(如 JPEG 仍存为 JPEG)。但当使用 RoundCornerImageProcessor 等会引入透明通道的处理器时,若原图是 JPEG(无透明通道),直接按 JPEG 存会丢失圆角透明区域。此时可指定 FormatIndicatedCacheSerializer.png,强制以 PNG 缓存处理后的图像:

imageView.kf.setImage(with: url,
    options: [.processor(RoundCornerImageProcessor(cornerRadius: 20)),
              .cacheSerializer(FormatIndicatedCacheSerializer.png)])

3. 内置 Processor 一览

Processor 输入偏好 功能
DefaultImageProcessor Data / Image Data→Image 解码,或 Image 按 scale 缩放
DownsamplingImageProcessor Data 解码时下采样,限制最大尺寸
ResizingImageProcessor Image 按 referenceSize + ContentMode 缩放
RoundCornerImageProcessor Image 圆角(可指定角、背景色、目标尺寸)
CroppingImageProcessor Image 按 size + anchor 裁剪
BlurImageProcessor Image 高斯模糊(Accelerate)
TintImageProcessor / OverlayImageProcessor Image 着色 / 叠色
ColorControlsProcessor / BlackWhiteProcessor Image 亮度对比度饱和度 / 黑白
BorderImageProcessor Image 加边框
BlendImageProcessor (iOS) / CompositingImageProcessor (macOS) Image 混合模式

4. 应用场景与选型

场景 推荐 Processor 说明
列表/表格缩略图 DownsamplingImageProcessor(size:) 从 Data 直接下采样,控制内存;size 取 cell 或目标尺寸
头像/圆角 RoundCornerImageProcessor 可配合 .png serializer 保留透明圆角
占位/毛玻璃 BlurImageProcessor 基于 Accelerate 的高斯模糊
统一尺寸且需等比 ResizingImageProcessor(referenceSize, mode: .aspectFit) 对已解码图做缩放
多步效果 链式:e.g. Blur |> RoundCorner 顺序决定最终效果与缓存键

RoundCornerImageProcessor 指定圆角:除四角统一圆角外,可指定部分角,如仅左上与右下:RoundCornerImageProcessor(cornerRadius: 20, roundingCorners: [.topLeft, .bottomRight])


四、类结构图分析

1. 核心类总览

Kingfisher 的类可按职责分为:入口与协调加载缓存处理管线视图扩展 五类。下表给出核心类/协议及其职责。

模块 核心类 / 协议 职责简述
协调 KingfisherManager 统一入口:协调 ImageDownloader、ImageCache、ImageProcessor 管线,执行「查缓存 → 下载/Provider → 处理 → 写缓存 → 回调」
加载 ImageDataProvider (协议) 定义数据来源接口:根据 URL 或资源标识返回 Data(如 Base64ImageDataProviderLocalFileImageDataProvider
ImageDownloader 默认网络加载:基于 URLSession 下载,支持并发、取消、RequestModifier、SessionDelegate
ImageDownloaderOperation 单次下载任务,封装 URLSessionTask
缓存 ImageCache 内存 + 磁盘二级缓存,提供 retrieve/store/remove,key 含 cacheKey + processorIdentifier
MemoryStorage / DiskStorage 5.0+ 内存层、磁盘层具体实现,可配置 count/cost 限制与过期策略
处理管线 ImageProcessor (协议) 定义 process(item:options:) -> KFCrossPlatformImage?,输入为 ImageProcessItem(.data / .image)
ImageProcessItem (枚举) 双态输入:.data(Data).image(KFCrossPlatformImage),统一「仅解码」「仅变换」「解码+变换」
DefaultImageProcessor / DownsamplingImageProcessor / RoundCornerImageProcessor 内置 Processor 实现,支持 ` >` 链式组合
CacheSerializer (协议) 磁盘格式:Image ↔ Data 序列化/反序列化,如 FormatIndicatedCacheSerializer.png
视图 KingfisherWrapper + ImageView.kf 为 UIImageView/NSImageView 等提供 kf.setImage(with:options:...)kf.cancelDownloadTask()
KFImage (SwiftUI) SwiftUI 图片组件,支持 URL、Processor、progressiveJPEG 等
ImagePrefetcher 预取多张图片,可配合 UICollectionView 的 prefetch

2. 模块划分与依赖关系

下图从「模块」维度表示各层之间的依赖方向:视图扩展与 Prefetcher 依赖 KingfisherManager,Manager 依赖 Downloader/Cache,处理管线在 Manager 内执行(Processor 链与 CacheSerializer 参与缓存键与磁盘格式)。

flowchart TB
    subgraph 视图层
        V1[ImageView.kf / KFImage]
        V2[ImagePrefetcher]
    end
    subgraph 协调层
        M[KingfisherManager]
    end
    subgraph 加载层
        L[ImageDownloader]
        P[ImageDataProvider 实现]
    end
    subgraph 缓存层
        C[ImageCache]
    end
    subgraph 处理管线层
        IP[ImageProcessor 实现]
        CS[CacheSerializer]
    end
    V1 --> M
    V2 --> M
    M --> L
    M --> P
    M --> C
    M --> IP
    M --> CS

3. 加载与缓存类结构

ImageDownloader 负责从网络获取 Data;ImageDataProvider 可提供本地或自定义 Data;ImageCache 负责内存与磁盘的读写。KingfisherManager 持有 cache 与 downloader,在单次请求中先查缓存(key = cacheKey + processorIdentifier),未命中再通过 downloader 或 provider 取数据,经 Processor 管线后写回缓存。

classDiagram
    class KingfisherManager {
        -cache: ImageCache
        -downloader: ImageDownloader
        +retrieveImage(with:options:progressBlock:completionHandler:)
        -loadAndCacheImage(source:options:completionHandler:)
    }
    class ImageCache {
        -memoryStorage: MemoryStorage
        -diskStorage: DiskStorage
        +retrieveImage(forKey:options:callbackQueue:completionHandler:)
        +store(_:forKey:options:toDisk:completionHandler:)
        +removeImage(forKey:fromMemory:fromDisk:completionHandler:)
    }
    class ImageDownloader {
        -session: URLSession
        -downloadQueue: OperationQueue
        +downloadImage(with:options:completionHandler:)
    }
    class ImageDataProvider {
        <<protocol>>
        +data(handler:)
        +cacheKey
    }
    KingfisherManager --> ImageCache : 使用
    KingfisherManager --> ImageDownloader : 使用
    KingfisherManager ..> ImageDataProvider : 支持 Source.provider
  • KingfisherManager:对外通过 retrieveImage(with:...) 接收 Source(.network(URL) 或 .provider(ImageDataProvider)),先查 ImageCache(key 含 processorIdentifier),未命中则调 downloader 或 provider 取 Data,再跑 Processor 管线并写回缓存。
  • ImageCache:5.0+ 将内存与磁盘拆为 MemoryStorage / DiskStorage,可配置 count/cost、过期时间;存储时由 CacheSerializer 决定 Image → Data 的格式(如 PNG 保留圆角透明)。
  • ImageDownloader:基于 URLSession,单次下载封装为 ImageDownloaderOperation,支持并发数、超时、RequestModifier;与 Provider 一起构成「数据来源」的两种方式。

4. 处理管线与 Processor 类结构

ImageProcessor 协议是图层处理的核心:输入为 ImageProcessItem(.data 或 .image),输出为 KFCrossPlatformImage。Manager 在「取得 Data 后」按 options 中的 processor(或链)依次执行;链的 identifier 拼接后参与缓存键,实现「同一 URL + 不同 Processor」对应不同缓存条目。

classDiagram
    class KingfisherManager {
        -runProcessors(_:data:options:)
    }
    class ImageProcessItem {
        <<enumeration>>
        +image(KFCrossPlatformImage)
        +data(Data)
    }
    class ImageProcessor {
        <<protocol>>
        +identifier: String
        +process(item: ImageProcessItem, options: KingfisherParsedOptionsInfo): KFCrossPlatformImage?
    }
    class DefaultImageProcessor {
        +process(item:options:)
    }
    class DownsamplingImageProcessor {
        +size: CGSize
        +process(item:options:)
    }
    class RoundCornerImageProcessor {
        +cornerRadius: CGFloat
        +process(item:options:)
    }
    class ImageProcessorGroup {
        -processors: [ImageProcessor]
        +append(another:)
        +identifier
    }
    class CacheSerializer {
        <<protocol>>
        +data(with:original:)
        +image(with:options:)
    }
    ImageProcessItem --> ImageProcessor : 输入
    ImageProcessor <|.. DefaultImageProcessor : 实现
    ImageProcessor <|.. DownsamplingImageProcessor : 实现
    ImageProcessor <|.. RoundCornerImageProcessor : 实现
    ImageProcessor <|.. ImageProcessorGroup : 链式组合
    KingfisherManager ..> ImageProcessor : 执行管线
    KingfisherManager ..> CacheSerializer : 磁盘序列化
  • ImageProcessItem:双态设计使同一管线既可处理「Data → Image」(解码/下采样),也可处理「Image → Image」(圆角、模糊、缩放),或混合链式处理;收到 .data 的 Processor 可先通过 DefaultImageProcessor.default |> self 解码再变换。
  • ImageProcessor 链:通过 append(another:)|> 组合,链的 identifier 为各子 Processor identifier 用 "|>" 拼接,参与缓存键;执行时前一个输出作为后一个的 .image(...) 输入。
  • CacheSerializer:磁盘存储时由 data(with:original:) 将 Image 转为 Data,读取时由 image(with:options:) 反序列化;圆角等带透明通道的结果可选用 FormatIndicatedCacheSerializer.png 避免 JPEG 丢失透明。

5. View 扩展与调用链

视图扩展(如 ImageView.kf、SwiftUI 的 KFImage)是业务最常接触的入口:内部将 Resource(URL 或 ImageDataProvider)、placeholder、options 交给 KingfisherManager,并把返回的 DownloadTask 与 view 关联,以便在复用时取消。

sequenceDiagram
    participant V as ImageView
    participant KF as ImageView.kf
    participant M as KingfisherManager
    participant C as ImageCache
    participant D as ImageDownloader

    V->>KF: setImage(with: url, options: [.processor(...)])
    KF->>KF: cancelDownloadTask()
    KF->>M: retrieveImage(with: .network(url), options: ...)
    M->>C: retrieveImage(forKey: cacheKey+processorIdentifier)
    alt 缓存命中
        C-->>M: image (memory/disk)
        M-->>KF: completion(image, .memory/.disk)
    else 未命中
        M->>D: downloadImage(with: url, ...)
        D-->>M: data
        M->>M: Processor 管线处理
        M->>C: store(image, forKey: ...)
        M-->>KF: completion(image, .none)
    end
    KF->>V: imageView.image = image
  • kf.setImage(with: placeholder: options: progressBlock: completionHandler:):先对当前 view 取消未完成的 DownloadTask,再调 KingfisherManager.shared.retrieveImage(with: source, options: options, ...);在 completion 中把得到的 image 赋给 imageView.image(并可选执行 transition)。
  • kf.cancelDownloadTask():取消与该 view 绑定的任务,避免 cell 复用时旧请求覆盖新图。
  • KFImage (SwiftUI):通过 KFImage 传入 url、processor、placeholder 等,内部同样走 KingfisherManager,支持 progressiveJPEG(8.3+)等选项。

将上述「核心类总览」「模块依赖」「加载与缓存类图」「Processor 与管线类图」「View 调用链」串联起来,即可形成对 Kingfisher 类结构图 的完整分析:入口在视图扩展(kf / KFImage),核心协调在 KingfisherManager,加载(Downloader/Provider)、缓存(ImageCache + CacheSerializer)、处理(ImageProcessor + ImageProcessItem)均为协议导向的可插拔设计,便于扩展与测试。


五、与系统及业界实践的衔接

1. Apple 图像与图形最佳实践

Apple 在 WWDC 2018「Image and Graphics Best Practices」[8] 中强调:

  • 在后台线程解码与下采样,避免主线程卡顿;
  • 解码时即做下采样,使解码后缓冲与显示尺寸匹配,降低内存峰值;
  • 预取:在列表等场景提前准备即将显示的图像。

Kingfisher 的 DownsamplingImageProcessor 直接对应「解码时下采样」;处理管线在 KingfisherManager 的队列中执行,满足「后台处理」;配合 ImagePrefetcherUICollectionViewDataSourcePrefetching 等可实现预取 [10]。与 SDWebImage 类似,其设计与此类最佳实践一致。

2. 与 SDWebImage 的对比

维度 Kingfisher SDWebImage
语言 纯 Swift Objective-C 为主,Swift 接口
处理抽象 ImageProcessor + ImageProcessItem SDImageTransformer
输入类型 .image / .data 双态 一般为已解码 Image
下采样 DownsamplingImageProcessor(Data→Image) 解码管线内缩略图/limitBytes
链式组合 append / |>,identifier 拼接 SDImagePipelineTransformer 数组
缓存键 cacheKey + processorIdentifier 含 transformer 信息
渐进式 8.3+ KFImage progressiveJPEG Progressive Coder 体系

二者都遵循「解码/下采样 + 变换 + 缓存」的管线思想,Kingfisher 通过 ImageProcessItem 将「解码」与「变换」统一进同一协议,便于从 Data 直接到最终 Image 的一体化处理。

3. 动图加载(GIF)与 AnimatedImageView

Kingfisher 加载 GIF 的两种方式:UIImageViewAnimatedImageView(继承自 UIImageView),调用方式相同,内部行为不同 [12]。

  • UIImageViewshouldPreloadAllAnimation() 扩展返回 true,即 preloadAllAnimationData 被设为 true,GIF 会先解码为所有帧的 UIImage 数组,再通过 UIImage.animatedImage(with:duration:) 展示。适合帧数少的动图。
  • AnimatedImageView:重写 shouldPreloadAllAnimation() 返回 false,不预加载全部帧;通过关联的 CGImageSourceAnimator 按需解码(默认仅预加载前若干帧),用 CADisplayLink 在每帧刷新时更新 layer.contents(重写 display(_ layer:))。更省内存,CPU 略高。

AnimatedImageView 独有runLoopModebackgroundDecodeframePreloadCountautoPlayAnimatedImagerepeatCount 等。若需在列表或详情中播放 GIF 且控制内存,建议使用 AnimatedImageView


六、设计模式与编程思想

1. 设计模式应用

Kingfisher 在架构上大量运用经典设计模式,与纯 Swift、协议导向的风格结合,使扩展与维护成本可控。

模式 在 Kingfisher 中的体现 作用
外观 / 门面(Facade) KingfisherManager 对外提供 retrieveImage(with:options:progressBlock:completionHandler:),内部协调 ImageDownloader、ImageCache、ImageProcessor 管线,调用方无需关心多级缓存与处理顺序 简化使用、隐藏复杂度
策略(Strategy) ImageProcessorCacheSerializerImageDataProvider 均为协议,多种实现可替换(RoundCorner、Downsampling、FormatIndicatedCacheSerializer 等),通过 KingfisherOptionsInfo 传入 算法/行为可插拔,易扩展新处理与存储格式
责任链 / 管道(Chain of Responsibility / Pipeline) ImageProcessor 通过 append(another:)|> 串联成管线;ImageProcessItem 双态(.data / .image)使「解码 → 变换」在同一链中顺序执行 多步处理顺序清晰,便于组合与复用
单例 + 共享依赖(Singleton) KingfisherManager.sharedImageCache.defaultImageDownloader.default 提供默认实例,同时 retrieveImage 等 API 支持传入自定义 cache、downloader,打破单例绑定 全局统一入口,又保留可测试性与多实例能力
观察者 / 回调(Observer / Callback) 通过 progressBlockcompletionHandler 闭包通知进度与结果;Swift 并发下也可用 async/await 异步结果与 UI 解耦
组合 / 装饰(Composite) 多个 ImageProcessor 通过 |> 组合成新 Processor,其 identifier 为子 Processor 的 identifier 拼接,对外仍满足同一 ImageProcessor 协议 链式处理器可当作单一策略使用,参与缓存键一致

类图关系(概念层)

classDiagram
    class KingfisherManager {
        -cache: ImageCache
        -downloader: ImageDownloader
        +retrieveImage(with:options:progressBlock:completionHandler:)
    }
    class ImageCache {
        +retrieveImage(forKey:options:callbackQueue:completionHandler:)
        +store(_:forKey:options:toDisk:completionHandler:)
    }
    class ImageDownloader {
        +downloadImage(with:options:completionHandler:)
    }
    class ImageProcessor {
        <<protocol>>
        +identifier: String
        +process(item: ImageProcessItem, options:): KFCrossPlatformImage?
    }
    class ImageDataProvider {
        <<protocol>>
        +data(handler:)
        +cacheKey
    }
    KingfisherManager --> ImageCache : 使用
    KingfisherManager --> ImageDownloader : 使用
    KingfisherManager ..> ImageProcessor : 处理时选用
    KingfisherManager ..> ImageDataProvider : Source.provider

2. 编程思想精华

Kingfisher 的编程思想可提炼为以下几点,对理解与模仿其设计很有帮助。

2.1 协议导向与「可替换实现」

  • ImageProcessorCacheSerializerImageDataProvider 均以协议呈现,具体实现可替换、可组合。
  • 新增一种图像处理或一种磁盘格式,只需实现对应协议并通过 options 传入(如 .processor(...).cacheSerializer(...)),无需改动 KingfisherManager 核心流程。这体现了开闭原则:对扩展开放,对修改关闭。

2.2 管线化与单一职责

  • 把「从 Source 到屏幕」拆成:获取数据(Downloader/Provider)→ Processor 管线(解码/下采样 + 变换)→ 缓存 → 展示,每一步只做一件事。
  • Processor 只关心 ImageProcessItem → Image,Cache 只关心存储与查找,Downloader 只关心网络 Data。单一职责使每块可独立测试、优化和扩展;管线化则使数据流清晰,便于加日志与监控。

2.3 双态输入与「解码+变换」统一

  • ImageProcessItem.data / .image 双态设计,使同一 ImageProcessor 协议既能表达「Data → Image」(如 Default、Downsampling),也能表达「Image → Image」(如 RoundCorner、Blur),还能通过链式组合在一次管线中完成解码与多步变换。
  • 避免「解码器」与「变换器」两套抽象,降低概念数量,便于链式组合与缓存键一致(整条链一个 identifier 串)。

2.4 缓存键与「同一资源多形态」

  • 通过 cacheKey + processorIdentifier 的设计,同一 URL 可以对应「原图」「下采样图」「圆角图」等多条缓存,避免重复下载,又满足不同场景对尺寸/形态的需求。这体现了用键设计表达业务差异的思想。

2.5 后台处理与主线程回调

  • 下载、Processor 管线、磁盘 I/O 均在后台队列执行,completionHandler 通过 CallbackQueue.mainAsync 等派发到主线程,兼顾性能与 UI 安全。这是移动端异步加载库的通用范式:重活放后台,结果回主线程

2.6 取消与生命周期绑定

  • 视图扩展(如 ImageView.kf)会把「当前正在进行的 DownloadTask」与 view 绑定,当对同一 view 发起新请求时先取消旧任务,避免错位和浪费。这体现了生命周期与请求绑定的思想,在列表 cell 复用时尤为重要。

2.7 配置通过 Options 透传

  • 不通过全局单例属性堆砌配置,而是通过 KingfisherOptionsInfo(如 .processor.cacheSerializer.callbackQueue)在单次请求中传入,使「同一 App 内不同页面/模块」可使用不同 Processor 与缓存策略,且易于单元测试时注入 mock。

Kingfisher 编程思想精华一览

思想 在框架中的体现
协议导向、可替换 ImageProcessor / CacheSerializer / ImageDataProvider 协议化,新处理、新格式仅需实现协议并通过 options 传入
管线化、单一职责 获取数据 → Processor 管线 → 缓存 → 展示,每步职责单一,便于扩展与测试
双态输入、解码+变换统一 ImageProcessItem(.data / .image) + 链式 Processor,一条管线完成解码与多步变换,identifier 参与缓存键
键设计表达多形态 同一 URL 通过 cacheKey + processorIdentifier 支持原图、下采样图、圆角图等多条缓存
后台处理、主线程回调 重 CPU/IO 在后台队列,completion 回主线程(CallbackQueue),兼顾性能与 UI 安全
生命周期绑定取消 View 与 DownloadTask 绑定,新请求自动取消旧请求,避免列表错位
Options 透传配置 单次请求级 options(processor、cacheSerializer、callbackQueue 等),避免全局状态,利于多策略并存与测试注入

七、使用示例与最佳实践

1. 基础加载与圆角

let processor = RoundCornerImageProcessor(cornerRadius: 20)
imageView.kf.setImage(with: url, options: [.processor(processor)])

2. 列表缩略图(下采样)

let size = imageView.bounds.size
let processor = DownsamplingImageProcessor(size: size)
imageView.kf.setImage(with: url, options: [.processor(processor)])
// 注意:size 不可为 .zero

3. 多处理器链与强制 PNG 缓存

let processor = BlurImageProcessor(blurRadius: 4) |> RoundCornerImageProcessor(cornerRadius: 20)
imageView.kf.setImage(with: url, options: [
    .processor(processor),
    .cacheSerializer(FormatIndicatedCacheSerializer.png)
])

4. 自定义 Processor(仅做示意)

struct MyProcessor: ImageProcessor {
    let identifier = "com.example.myprocessor"
    func process(item: ImageProcessItem, options: KingfisherParsedOptionsInfo) -> KFCrossPlatformImage? {
        switch item {
        case .image(let image): return image // 或对 image 做变换
        case .data(let data): return DefaultImageProcessor.default.process(item: item, options: options)
        }
    }
}

5. 预取与列表

// 配合 UICollectionViewDataSourcePrefetching
func collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath]) {
    let urls = indexPaths.compactMap { URL(string: model(at: $0).imageURL) }
    ImagePrefetcher(urls: urls).start()
}

6. Cell 完整示例(复用、下采样、进度与完成回调)

列表 Cell 中需在 prepareForReuse 中取消任务并清空,在 configure 中按目标尺寸下采样并可选显示进度。

class PhotoCell: UITableViewCell {
    static let reuseId = "PhotoCell"
    @IBOutlet weak var photoImageView: UIImageView!
    @IBOutlet weak var progressView: UIProgressView!

    override func prepareForReuse() {
        super.prepareForReuse()
        photoImageView.kf.cancelDownloadTask()
        photoImageView.image = nil
        progressView.progress = 0
        progressView.isHidden = true
    }

    func configure(with url: URL) {
        let size = photoImageView.bounds.size
        let processor = DownsamplingImageProcessor(size: size.isEmpty ? CGSize(width: 120, height: 120) : size)
        photoImageView.kf.setImage(
            with: url,
            placeholder: UIImage(named: "placeholder"),
            options: [.processor(processor), .scaleFactor(UIScreen.main.scale)],
            progressBlock: { [weak self] received, total in
                guard let self = self, total > 0 else { return }
                DispatchQueue.main.async {
                    self.progressView.isHidden = false
                    self.progressView.progress = Float(received) / Float(total)
                }
            },
            completionHandler: { [weak self] result in
                DispatchQueue.main.async {
                    self?.progressView.isHidden = true
                    if case .failure = result { /* 可设置失败占位图 */ }
                }
            }
        )
    }
}

7. UIButton 设置网络图片

为 UIButton 的不同 state 设置网络图片,可配合 Processor 与完成回调。

// 设置 normal / highlighted 等状态的图片
button.kf.setImage(with: url, for: .normal, placeholder: UIImage(named: "btn_placeholder"))
button.kf.setImage(with: highlightedURL, for: .highlighted)
button.kf.setBackgroundImage(with: backgroundURL, for: .normal)

// 带圆角与完成回调
let processor = RoundCornerImageProcessor(cornerRadius: 8)
button.kf.setImage(
    with: url,
    for: .normal,
    placeholder: nil,
    options: [.processor(processor), .cacheSerializer(FormatIndicatedCacheSerializer.png)],
    completionHandler: { result in
        if case .failure = result { print("加载失败") }
    }
)

8. 占位图、进度与过渡动画

使用占位图、下载进度条,并在图片加载完成后执行淡入等过渡动画。

imageView.kf.setImage(
    with: url,
    placeholder: UIImage(named: "placeholder"),
    options: [
        .transition(ImageTransition.fade(0.3)),
        .retryFailed
    ],
    progressBlock: { [weak progressView] received, total in
        guard let pv = progressView, total > 0 else { return }
        DispatchQueue.main.async {
            pv.progress = Float(received) / Float(total)
            pv.isHidden = false
        }
    },
    completionHandler: { [weak progressView] result in
        DispatchQueue.main.async {
            progressView?.isHidden = true
            if case .failure = result { /* 可显示失败占位或提示 */ }
        }
    }
)

9. 自定义缓存键与请求修饰(RequestModifier)

同一 URL 在不同业务下需要不同缓存键时,可通过 KingfisherOptionsInfo 传入自定义 cacheKey;需要鉴权或自定义 Header 时使用 ImageDownloadRequestModifier

// 自定义缓存键:列表用 thumb key、详情用原图 key
let listResource = ImageResource(downloadURL: url, cacheKey: "list_\(url.absoluteString)")
let detailResource = ImageResource(downloadURL: url, cacheKey: "detail_\(url.absoluteString)")
listImageView.kf.setImage(with: listResource, options: [.processor(DownsamplingImageProcessor(size: thumbSize))])
detailImageView.kf.setImage(with: detailResource)

// 请求修饰:Header、Token、超时
struct AuthModifier: ImageDownloadRequestModifier {
    let token: String
    func modified(for request: URLRequest) -> URLRequest? {
        var r = request
        r.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")
        r.setValue("image/webp,image/*,*/*;q=0.8", forHTTPHeaderField: "Accept")
        return r
    }
}
imageView.kf.setImage(with: url, options: [.requestModifier(AuthModifier(token: userToken))])

10. 缓存查询与手动存储

不经过视图加载流程,直接使用 ImageCache 查询、存储或移除缓存。

let cache = ImageCache.default
let key = url.absoluteString  // 或自定义 cacheKey(与 Processor 组合时由框架自动拼接 processorIdentifier)

// 查询是否已缓存
cache.imageCachedType(forKey: key) { result in
    switch result {
    case .success(let cached):
        switch cached {
        case .none:   print("未缓存")
        case .memory: print("在内存")
        case .disk:   print("在磁盘")
        }
    case .failure: break
    }
}

// 从缓存读取(不触发下载)
cache.retrieveImage(forKey: key, options: nil) { result in
    switch result {
    case .success(let value):
        if let image = value.image { imageView.image = image }
    case .failure: break
    }
}

// 手动写入缓存(如本地生成或从相册来的图)
cache.store(image, forKey: key, options: nil, toDisk: true) { _ in }

11. 自定义 Processor 完整示例(加边框)

实现 ImageProcessor 协议,对已解码图像做自定义绘制(如加灰色边框)。

struct GrayBorderProcessor: ImageProcessor {
    let identifier = "com.example.grayborder(\(borderWidth))"
    let borderWidth: CGFloat

    init(borderWidth: CGFloat = 2) { self.borderWidth = borderWidth }

    func process(item: ImageProcessItem, options: KingfisherParsedOptionsInfo) -> KFCrossPlatformImage? {
        switch item {
        case .image(let image):
            let size = image.size
            let renderer = UIGraphicsImageRenderer(size: size)
            return renderer.image { ctx in
                image.draw(at: .zero)
                UIColor.gray.setStroke()
                let rect = CGRect(origin: .zero, size: size).insetBy(dx: borderWidth/2, dy: borderWidth/2)
                ctx.stroke(rect, with: .color(.gray), lineWidth: borderWidth)
            }
        case .data:
            return DefaultImageProcessor.default.process(item: item, options: options)
        }
    }
}

// 使用
imageView.kf.setImage(with: url, options: [.processor(GrayBorderProcessor(borderWidth: 3))])

12. SwiftUI KFImage 与 async/await

在 SwiftUI 中使用 KFImage,并配合渐进式 JPEG、占位与异步加载。

// 基础用法
KFImage(url)
    .placeholder { ProgressView() }
    .fade(duration: 0.25)
    .resizable()
    .aspectRatio(contentMode: .fit)

// 带 Processor 与圆角
KFImage(url)
    .setProcessor(RoundCornerImageProcessor(cornerRadius: 12))
    .placeholder { Color.gray.opacity(0.2) }
    .cacheSerializer(FormatIndicatedCacheSerializer.png)

// 8.3+ 渐进式 JPEG
KFImage(url)
    .progressiveJPEG(ImageProgressive(isBlur: true, isFastestScan: true, scanInterval: 0.1))

// 使用 async/await(Kingfisher 提供的异步 API)
Task {
    let result = await KingfisherManager.shared.retrieveImage(with: url)
    if case .success(let value) = result {
        await MainActor.run { imageView.image = value.image }
    }
}

13. ImageDataProvider(本地与 Base64)用法

不依赖网络 URL 时,可用 ImageDataProvider 从本地文件或 Base64 字符串加载,并同样走缓存与 Processor 管线。

// 本地文件
let fileURL = Bundle.main.url(forResource: "avatar", withExtension: "jpg")!
let provider = LocalFileImageDataProvider(fileURL: fileURL)
imageView.kf.setImage(with: provider)

// Base64 数据(如接口返回的 data URL)
let base64String = "data:image/png;base64,iVBORw0KGgo..."
if let provider = Base64ImageDataProvider(base64String: base64String, cacheKey: "custom_key") {
    imageView.kf.setImage(with: provider, options: [.processor(RoundCornerImageProcessor(cornerRadius: 10))])
}

// 自定义 Provider:从相册、加密存储等获取 Data
struct MyImageDataProvider: ImageDataProvider {
    var cacheKey: String { "my_\(id)" }
    let id: String
    func data(handler: @escaping (Result<Data, Error>) -> Void) {
        // 异步获取 Data 后调用 handler(.success(data)) 或 handler(.failure(...))
    }
}
imageView.kf.setImage(with: MyImageDataProvider(id: "123"))

14. 其他常用选项速览

选项 含义
.forceRefresh 跳过缓存,强制重新下载
.retryFailed 对之前失败的 URL 重试
.onlyFromCache 仅从缓存读取,不发起网络请求
.backgroundDecode 在后台队列解码,减少主线程压力
.callbackQueue(.mainAsync) 指定完成回调的派发队列
.downloadPriority(1.0) 下载任务优先级(iOS)
.scaleFactor(UIScreen.main.scale) 与 @2x/@3x 匹配,避免模糊
.cacheMemoryOnly 仅写内存缓存,不写磁盘
.loadDiskFileSynchronously 从磁盘加载时是否同步(默认异步)
imageView.kf.setImage(with: url, options: [.forceRefresh, .retryFailed, .callbackQueue(.mainAsync)])

15. Options 详解(延伸)

  • targetCache / originalCache:默认为 nil 时使用 ImageCache(name: "default")targetCache 为最终展示图的缓存(含 Processor 处理后的图),originalCache 为原始数据的缓存,可用于「列表用处理图、详情用原图」等分离策略。
  • transition:图片加载完成后的展示动画;forceTransition 为 true 时即使命中缓存也执行 transition,为 false 时仅在不使用缓存(新下载)时执行。
  • callbackQueue / processingQueuecallbackQueue 可选 .mainAsync.mainCurrentOrAsync(当前线程为主线程则直接执行,否则主线程异步)、.untouch.dispatch(DispatchQueue),默认多为 .mainCurrentOrAsyncprocessingQueue 为 Processor 执行所在队列,默认串行子队列。
  • memoryCacheAccessExtendingExpiration:从内存/磁盘取图时是否延长过期时间,可选 .none(不延长)、.cacheTime(当前时间 + 原过期时长)、.expirationTime(StorageExpiration)(延长到指定时长)。

16. 指示器、Placeholder 与 Transition 类型

  • 指示器(Indicator)imageView.kf.indicatorType 可选 .none.activity(UIActivityIndicatorView)、.image(imageData: Data)(GIF 等)、.custom(indicator: Indicator),自定义需实现 Indicator 协议(startAnimatingView / stopAnimatingView)。
  • Placeholder:除 UIImage 外,可实现 Placeholder 协议的自定义 View(如 class MyPlaceholder: UIView, Placeholder {}),设置 imageView.kf.setImage(with: url, placeholder: myPlaceholderView)
  • ImageTransitionnonefade(TimeInterval)flipFromLeft/Right/Top/Bottom(TimeInterval)custom(duration:options:animations:completion:)

17. 缓存配置与清除

内存缓存cache.memoryStorage.config):totalCostLimit(默认约物理内存 1/4)、countLimitexpiration(默认 300 秒)、cleanInterval(清除过期缓存的时间间隔,仅初始化可设)。单张可设 .memoryCacheExpiration(.never);访问时延长策略用 .memoryCacheAccessExtendingExpiration(.cacheTime)

磁盘缓存cache.diskStorage.config):sizeLimitexpiration(默认 7 天)、pathExtensionusesHashedFileName(文件名是否用 key 的 MD5)。超出容量时按最后访问时间排序,删除最旧文件直至低于 sizeLimit 的一半。

清除cache.clearMemoryCache() / cache.cleanExpiredMemoryCache()cache.clearDiskCache() / cache.cleanExpiredDiskCache();删除指定 key 可用 cache.removeImage(forKey:processorIdentifier:fromMemory:fromDisk:completionHandler:)。获取磁盘占用:cache.calculateDiskStorageSize { result in ... }

18. ImagePrefetcher 与请求修饰、重定向

ImagePrefetcher:除 start() 外,提供 completionHandler(参数为 [Resource] 的 skipped/failed/completed)与 completionSourceHandler(参数为 [Source]),分别对应用 URL/Resource 初始化与用 Source 初始化的场景;progressBlock / progressSourceBlock 同理。maxConcurrentDownloads 控制并发数。stop() 会取消当前未完成的下载任务,并将剩余未加载项计入「完成回调」的 skipped;若调用 stop 时已全部完成,则不会再次触发完成回调。

请求修饰:通过 AnyModifier 或实现 ImageDownloadRequestModifier 在请求前添加 Header、Token 等,例如 let modifier = AnyModifier { var r = $0; r.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization"); return r },options 中加 .requestModifier(modifier)超时ImageDownloader.default.downloadTimeout = 60重定向:通过 .redirectHandler(AnyRedirectHandler { ... }) 自定义 302 等重定向后的请求。

19. 扩展 WebP 支持(Processor + CacheSerializer)

Kingfisher 默认不包含 WebP 编解码,可借助 ProcessorCacheSerializer 扩展 [13]。依赖 libwebp 实现 Data ↔ Image 后,定义 WebPProcessor(在 process 中若为 .data 则用 WebP 解码为 Image,若为 .image 则透传)与 WebPCacheSerializerdata(with:original:) 返回 WebP 编码、image(with:options:) 返回 WebP 解码),使用时设置 options: [.processor(WebPProcessor.default), .cacheSerializer(WebPCacheSerializer.default)] 即可对 .webp URL 加载并缓存。


延伸阅读(掘金系列)

以下为同一作者的 Kingfisher 源码解析系列文章,可按需跳转深入阅读(链接与标题保持一致):

主题 链接 内容概要
使用 Kingfisher源码解析之使用 Resource/ImageDataProvider、Placeholder、GIF、Indicator、Transition、Processor 概览、缓存与下载配置、预加载、常用 options
Options 解释 Kingfisher源码解析之Options解释 targetCache/originalCache、downloader、transition/forceTransition、preloadAllAnimationData、callbackQueue/processingQueue、memoryCacheAccessExtendingExpiration
加载流程 Kingfisher源码解析之加载流程 setImage 之后发生了什么、图片加载与缓存查找流程
ImageCache Kingfisher源码解析之ImageCache MemoryStorage(NSCache、StorageObject、Config)、DiskStorage(FileMeta、removeExpiredValues、removeSizeExceededValues)、缓存读写与清理
加载动图 Kingfisher源码解析之加载动图 UIImageView 与 AnimatedImageView 加载 GIF 的差异、preloadAllAnimationData、CGImageSource、Animator、CADisplayLink、display(_ layer:)
Processor 和 CacheSerializer Kingfisher源码解析之Processor和CacheSerializer Processor/ImageProcessItem 定义与调用时机、CacheSerializer 调用时机、使用 Processor+CacheSerializer 扩展 WebP
ImagePrefetcher Kingfisher源码解析之ImagePrefetcher 预加载功能、completionHandler/completionSourceHandler、progressBlock/progressSourceBlock、stop() 行为、Resource 与 Source 两套回调

参考文献

[1] Kingfisher. Cheat Sheet. GitHub Wiki.
[2] Kingfisher. Image Manager Structure. studyraid.com / Agent Docs.
[3] Kingfisher. CHANGELOG / Releases — 3.10.0 cache retrieval with ImageProcessor.
[4] Kingfisher. Release 5.0.0. GitHub.
[5] Kingfisher. Release 5.3.0 — Downsampling scale/memory fix.
[6] Kingfisher. Release 7.8.1 — Animated image from disk cache with processor.
[7] Kingfisher. Release 8.3.0 — Progressive JPEG for KFImage.
[8] Apple. Image and Graphics Best Practices. WWDC 2018, Session 219.
[9] Kingfisher. ImageProcessor.swift. GitHub (onevcat/Kingfisher).
[10] Kingfisher. Cheat Sheet — Processor, Cache, Downloader. GitHub Wiki.
[11] Stack Overflow / Kingfisher Issues. DownsamplingImageProcessor size (0,0) and processing failure.

01-研究优秀开源框架@图层处理@iOS | SDWebImage 框架:从使用到原理解析

📋 目录


一、SDWebImage 概述与历史演进

0. 框架结构概览与功能简介

SDWebImage 的框架结构

SDWebImage的框架结构

SDWebImage 的图片下载分类,只要一行代码就可以实现图片异步下载和缓存功能。

功能简介

  1. 一个添加了 web 图片加载和缓存管理的 UIImageView 分类
  2. 一个异步图片下载器
  3. 一个异步的内存加磁盘综合存储图片并且自动处理过期图片
  4. 支持动态 gif 图
    • 4.0 之前的动图效果并不是太好
    • 4.0 以后基于 FLAnimatedImage 加载动图
  5. 支持 webP 格式的图片
  6. 后台图片解压处理
  7. 确保同样的图片 url 不会下载多次
  8. 确保伪造的图片 url 不会重复尝试下载
  9. 确保主线程不会阻塞

1. 框架简介

SDWebImage 是 Apple 平台(iOS / macOS / watchOS / visionOS)上广泛使用的异步图片下载与缓存库,提供从网络(或自定义 Loader)加载图片、解码、变换、缓存到展示的完整管线。其「图层处理」相关能力主要体现在:解码管线(将压缩数据解码为可渲染的位图)与变换管线(在解码后对位图做缩放、裁剪、滤镜等处理),二者共同构成「从数据到屏幕」的中间处理层。

2. 技术演进与版本脉络

SDWebImage 的图层处理能力并非一蹴而就,而是随版本逐步完善,与系统 API 和业界实践同步演进。

阶段 版本/时期 解码与图层处理相关能力
早期 3.x 及以前 以网络下载 + 简单缓存为主,解码依赖系统默认行为
规范化 4.0 引入 Custom Download Operation、更清晰的职责划分
编解码扩展 4.2 Custom Coder:支持注册自定义编解码器(如 WebP、渐进 JPEG)
统一管线 5.0 Image TransformerAnimated Image 全栈方案(GIF/WebP/APNG)、解码与变换在 Manager 内统一调度
精细化 5.x 后续 缩略图解码、HDR、强制解码策略(Force Decode Policy)、解码尺度与字节限制等

5.0 是重要分水岭:解码(Coder)、变换(Transformer)、缓存(Cache)、加载(Loader)在 SDWebImageManager 中形成一条清晰流水线,便于理解「图层处理」在整体中的位置。

3. 图层处理在整体架构中的位置

下图概括了从「URL 请求」到「显示到视图」的流程,并标出解码与变换所在阶段。

flowchart LR
    subgraph 输入
        A[URL / 自定义 Loader]
    end
    subgraph 加载
        B[SDImageLoader]
    end
    subgraph 解码层
        C[Data]
        D[SDImageCoder 解码]
        E[UIImage/NSImage]
    end
    subgraph 变换层
        F[SDImageTransformer]
        G[变换后图像]
    end
    subgraph 缓存与输出
        H[SDImageCache]
        I[UIImageView 等]
    end
    A --> B --> C --> D --> E --> F --> G --> H --> I

要点

  • 解码(Decoder):将压缩格式数据(JPEG/PNG/WebP/HEIC/AVIF 等)转为内存中的位图(如 UIImage/NSImage),是「数据 → 图层」的第一步。
  • 变换(Transformer):在「已解码的位图」上做几何或像素级处理(缩放、裁剪、圆角、滤镜等),输出仍是位图,再写入缓存或交给视图。
  • 二者均可在后台线程执行,避免阻塞主线程,符合 Apple 在 WWDC 等场合强调的「Image and Graphics Best Practices」[1]。

二、图像解码管线(Decoder Pipeline)

1. 解码的基础概念与双缓冲模型

在操作系统与图形栈中,图像通常以两种形式存在:

  1. 数据缓冲(Data Buffer)
    即磁盘或网络中的压缩编码数据(如 JPEG、PNG 的二进制)。体积小,但不能直接用于渲染。

  2. 图像缓冲(Image Buffer)
    解码后的像素矩阵(如 RGBA 位图),可被 GPU/CPU 渲染。其大小与分辨率(宽×高×通道数)成正比,与压缩格式无关。

因此,解码(Decoding) 的含义是:将 Data Buffer 转换为 Image Buffer。该过程是 CPU 密集型,且解码后的图像缓冲往往远大于原始数据(例如一张 4K 图片可解码为上百 MB 像素数据)。系统会在首次渲染时触发解码,若在主线程进行,易造成卡顿;若不经控制,大图会带来内存峰值与 OOM 风险。

双缓冲概念可归纳为

┌─────────────────┐     decode      ┌─────────────────┐
│  Data Buffer    │  ────────────►  │  Image Buffer   │
│ (JPEG/PNG/…)    │   (CPU 密集)     │  (像素矩阵)      │
└─────────────────┘                 └─────────────────┘
      体积较小                          体积 ∝ 宽×高×4

Apple 在 WWDC 2018「Image and Graphics Best Practices」[1] 中明确指出:解码后的缓冲区大小由图像尺寸决定,而非显示尺寸;因此在解码阶段就做下采样(Downsampling),避免先解码全尺寸再缩放的巨大内存与 CPU 开销。

2. 缩略图与下采样(Downsampling)

下采样指在解码时直接生成较小尺寸的位图,而不是先解码全图再缩放。这样既能减少内存占用,也能减少解码与后续绘制的计算量。

2.1 系统 API:ImageIO 与缩略图

在 iOS/macOS 上,推荐使用 ImageIOCGImageSourceCreateThumbnailAtIndex 在解码阶段就限制最大尺寸,从而在内存中只生成缩略图级别的像素缓冲 [2][3]。

算法思路(伪代码)

函数 DownsampleImage(数据 data, 最大边长 maxPixelSize):
    1. 使用 data 创建 CGImageSourceRef source
    2. 设置选项 options:
       - kCGImageSourceCreateThumbnailFromImageAlways: true
       - kCGImageSourceCreateThumbnailWithTransform: true
       - kCGImageSourceThumbnailMaxPixelSize: maxPixelSize
    3. thumbnail = CGImageSourceCreateThumbnailAtIndex(source, 0, options)
    4. 由 thumbnail 创建 UIImage/NSImage 并返回

这样,解码器内部可以在部分解码低分辨率解码路径上生成缩略图,避免全图解码。SDWebImage 在 5.x 中通过 SDImageCoderDecodeScaleDownLimitBytes 等能力,将「按目标尺寸或字节限制做缩略图解码」纳入其解码管线,与上述思路一致。

2.2 下采样算法与内存估算

算法步骤(与 ImageIO 语义一致)

  1. Data 创建 CGImageSourceRef,不立即解码全图。
  2. 从 source 读取图像属性(宽、高),计算缩放比例,使长边不超过 maxPixelSize
  3. 设置 kCGImageSourceThumbnailMaxPixelSizekCGImageSourceCreateThumbnailFromImageAlwayskCGImageSourceCreateThumbnailWithTransform 等选项。
  4. 调用 CGImageSourceCreateThumbnailAtIndex(source, 0, options) 得到缩略图 CGImage
  5. CGImage 创建 UIImage/NSImage 并返回。

这样解码器在内部只生成目标尺寸的像素缓冲,避免「先全图解码再缩放」的双倍内存与 CPU 开销。

2.3 内存与性能关系

下采样带来的内存节省可近似表示为:

  • 全图解码:memory ≈ width × height × 4(假设 RGBA)。
  • 限制最大边长 L 后:若等比缩放,则 memory ≈ L² × 4,与原始分辨率无关。

因此,在列表、缩略图等场景下,在解码阶段就限制最大尺寸是业界公认的最佳实践,也是 SDWebImage 解码管线优化的核心之一。

3. 渐进式解码(Progressive Decoding)

渐进式编码(如 Progressive JPEG)允许数据分块到达时逐步呈现:先看到模糊全图,再随数据增多逐步变清晰。渐进式解码即在未完整接收数据时,对当前已有数据做解码并显示,以提升感知性能(尤其在弱网环境)[4]。

流程概念

sequenceDiagram
    participant N as 网络
    participant D as 渐进式解码器
    participant V as 视图

    N->>D: 数据块 1
    D->>D: 解码当前数据
    D->>V: 显示低分辨率帧 1
    N->>D: 数据块 2
    D->>D: 更新解码状态,解码
    D->>V: 显示更清晰帧 2
    N->>D: 数据块 n(完成)
    D->>D: 最终解码
    D->>V: 显示最终图像

SDWebImage 通过 SDWebImageProgressiveCoder 协议扩展解码器:支持「增量数据」输入,每次 updateIncrementalData:finished: 时更新内部解码状态并输出当前可用的图像,供上层展示。对动图(如 GIF),还可配合 SDAnimatedImageCoder 在渐进加载时逐帧解码并驱动 SDAnimatedImageView 的渐进动画。

渐进式解码流程(伪代码)

函数 ProgressiveDecode:
    状态: 已接收数据 buffer, 解码器内部状态 decoderState
    当 收到新数据块 chunk:
        append(buffer, chunk)
        decodedFrame = decoder.decodeIncremental(buffer, decoderState)
        若 decodedFrame 非空:
            回调 onPartialImage(decodedFrame)
    当 数据接收完成:
        finalImage = decoder.finalize(buffer, decoderState)
        回调 onComplete(finalImage)

注意:渐进式解码比单次完整解码的 CPU 开销更高 [4],适合「先显示再细化」的体验需求,需在流畅度与电量之间做权衡。

4. 编解码器扩展与多格式支持

SDWebImage 将「解码 / 编码」抽象为 SDImageCoder 协议,通过 SDImageCodersManager 注册多个 Coder,按数据格式(或 MIME 类型)选择对应实现。这样可在不修改核心管线的前提下支持新格式。

解码器选择与解码流程(高层)

flowchart TD
    A[Image Data] --> B{SDImageCodersManager}
    B --> C[遍历已注册 Coder]
    C --> D{canDecodeFromData?}
    D -->|是| E[该 Coder 解码]
    D -->|否| C
    E --> F[UIImage/NSImage]
    F --> G[可选: 缩略图/字节限制]
    G --> H[解码结果]

典型 Coder 职责

方法/能力 含义
decodedImageWithData:options: 将 Data 解码为 UIImage/NSImage
encodedDataWithImage:format:options: 将图像编码为指定格式 Data
canDecodeFromData: / canEncodeToFormat: 是否支持某格式的解码/编码

动图则通过 SDAnimatedImageCoder 扩展:提供按帧解码、帧时长、循环次数等,供 SDAnimatedImage + SDAnimatedImageView 使用。内置支持 GIF、WebP、APNG、HEIC 动图等;用户也可实现自定义 Coder 并注册,从而纳入统一的加载与缓存流程。


三、图像变换管线(Transformer Pipeline)

1. 变换器的设计思想与协议

图像变换在 SDWebImage 中定义为:输入与输出均为图像对象(如 UIImage/NSImage)的运算。与 Coder(Data ↔ Image)不同,Transformer 只做 Image → Image,例如缩放、裁剪、圆角、滤镜等,对应「数字图像处理」中的几何变换与像素操作 [5]。

协议设计(概念)

协议 SDImageTransformer:
    方法 transform(image, key) -> Image?:
        输入: 原始图像、缓存 key(可选,用于生成变换后的 cache key)
        输出: 变换后的图像;失败可返回 nil

这样设计便于:

  • SDWebImageManager 中,在「解码完成」之后、「写入缓存」之前插入变换步骤;
  • 对同一 URL 可因不同变换参数得到不同 cache key,从而分别缓存原图与变换结果。

2. 内置变换器与组合管线

SDWebImage 提供多种内置 Transformer,覆盖常见 UI 需求:

变换器 功能说明
SDImageResizingTransformer 缩放到指定尺寸,支持 scaleMode(fill/aspectFit 等)
SDImageCroppingTransformer 按矩形裁剪
SDImageRoundCornerTransformer 圆角(可带边框)
SDImageRotationTransformer 按角度旋转,可选 fitSize
SDImageFlippingTransformer 水平/垂直翻转
SDImageBlurTransformer 高斯模糊
SDImageTintTransformer 颜色 tint
SDImageFilterTransformer 基于 CIFilter 的滤镜(除 watchOS 外)

组合管线:通过 SDImagePipelineTransformer 将多个 Transformer 按顺序组合,形成链式处理:

图像 → Transformer1 → Transformer2 → … → TransformerN → 最终图像

例如先裁剪再圆角再缩放,只需将三个 Transformer 放入一个 Pipeline 即可。对应伪代码:

pipeline = SDImagePipelineTransformer([CropTransformer(rect), RoundCornerTransformer(radius), ResizingTransformer(size)])
resultImage = pipeline.transform(originalImage, key)

在 Swift/Objective-C 中的用法可参见官方 Advanced Usage - Image Transformer [6]。

3. 变换与缓存的协同

变换发生在 Manager 层:
先由 Loader 得到 Data,由 Coder 解码得到 Image,再经 Transformer 得到最终 Image,最后再写入 Cache 并交给 UI。因此:

  • 原始图变换后的图可以分别缓存:
    • 原图可用 SDWebImageContextOriginalImageCache 指定单独缓存实例;
    • 变换后的图使用默认(或指定)的 Cache,其 cache key 会包含变换信息,避免不同变换结果互相覆盖。
  • 若只关心「下载 + 变换」而不写缓存,可通过 .fromLoaderOnlystoreCacheType = .none 实现,仅走 Loader → 解码 → 变换 → 回调,不读/写缓存。

变换与缓存的整体管线(含解码)

flowchart LR
    subgraph 请求
        U[URL + Context]
    end
    subgraph 缓存查询
        C1{查 Cache}
    end
    subgraph 加载与解码
        L[Loader]
        D[Coder 解码]
    end
    subgraph 变换
        T[Transformer]
    end
    subgraph 写回与展示
        C2[写 Cache]
        V[View]
    end
    U --> C1
    C1 -->|命中| V
    C1 -->|未命中| L --> D --> T --> C2 --> V

4. 应用场景简述

场景 解码侧 变换侧
列表缩略图 使用 scaleDown/limitBytes 做缩略图解码,降低内存 可选 ResizingTransformer 统一尺寸
头像/圆角 常规解码即可 RoundCornerTransformer
弱网/大图 Progressive Coder 渐进显示 可配合 Resizing 限制最终尺寸
相册/大图预览 原图或高分辨率解码 少用或仅做旋转/裁剪
动图(GIF/WebP) SDAnimatedImageCoder + 帧缓冲 一般不做几何变换,或仅对首帧做

四、类结构图分析

1. 核心类总览

SDWebImage 的类可按职责分为:入口与协调加载缓存解码变换视图扩展 六类。下表给出核心类及其职责(名称以 5.x 为主,OC/Swift 可能略有差异)。

模块 核心类 / 协议 职责简述
协调 SDWebImageManager 统一入口:协调 Loader、Cache、Coder、Transformer,执行「查缓存 → 下载 → 解码 → 变换 → 写缓存」
加载 SDImageLoader (协议) 定义加载接口:根据 URL 返回 Data 或 Image
SDWebImageDownloader 默认 Loader 实现:基于 URLSession 下载,支持并发、取消、RequestModifier
SDWebImageDownloaderOperation 单次下载任务,实现 SDWebImageDownloaderOperation 协议
缓存 SDImageCache 内存 + 磁盘二级缓存,提供 query/store/remove,支持自定义 key、过期策略
SDMemoryCache / SDDiskCache 内存层、磁盘层具体实现(5.x 可拆分)
解码 SDImageCoder (协议) 定义 Data ↔ Image 编解码,如 decodedImageWithData:options:
SDImageCodersManager 管理多个 Coder,按数据格式选择可用 Coder
SDWebImageImageIOCoder 内置 Coder 实现(JPEG/PNG/HEIC/…)
变换 SDImageTransformer (协议) 定义 Image → Image 变换,如 transformedImageWithImage:forKey:
SDImagePipelineTransformer 将多个 Transformer 串联为一条管线
SDImageResizingTransformer 内置 Transformer 实现
视图 UIImageView+WebCache 为 UIImageView 提供 sd_setImage(with:...)sd_cancelCurrentImageLoad
SDAnimatedImageView 动图展示,配合 SDAnimatedImage
UIButton+WebCache 其他控件的扩展

2. 模块划分与依赖关系

下图从「模块」维度表示各层之间的依赖方向:视图扩展依赖 Manager,Manager 依赖 Loader/Cache,解码与变换在 Manager 内被调用,Loader 只产出 Data,Cache 只做存取。

flowchart TB
    subgraph 视图层
        V1[UIImageView+WebCache]
        V2[UIButton+WebCache]
        V3[SDAnimatedImageView]
    end
    subgraph 协调层
        M[SDWebImageManager]
    end
    subgraph 加载层
        L[SDWebImageDownloader]
    end
    subgraph 缓存层
        C[SDImageCache]
    end
    subgraph 编解码层
        CM[SDImageCodersManager]
        CO[SDImageCoder 实现]
    end
    subgraph 变换层
        T[SDImageTransformer 实现]
    end
    V1 --> M
    V2 --> M
    V3 --> M
    M --> L
    M --> C
    M --> CM
    M --> T
    CM --> CO

3. 加载与缓存类结构

Loader 负责从网络(或自定义来源)获取数据;Cache 负责内存与磁盘的读写。Manager 持有两者引用,在单次请求中先问 Cache,未命中再调 Loader。

classDiagram
    class SDWebImageManager {
        -imageLoader: SDImageLoader
        -imageCache: SDImageCache
        +loadImage(with:options:context:progress:completed:)
        -callLoadImage(with:options:context:progress:completed:)
    }
    class SDImageLoader {
        <<protocol>>
        +requestImageWithURL:options:context:progress:completed()
        +canRequestImageForURL()
    }
    class SDWebImageDownloader {
        -session: URLSession
        -downloadQueue: NSOperationQueue
        +downloadImageWithURL:options:progress:completed()
    }
    class SDImageCache {
        -memoryCache: SDMemoryCache
        -diskCache: SDDiskCache
        +queryImageForKey:options:context:callback()
        +storeImage:imageData:forKey:completion()
        +removeImageForKey:withCompletion()
    }
    SDWebImageManager --> SDImageLoader : 使用
    SDWebImageManager --> SDImageCache : 使用
    SDWebImageDownloader ..|> SDImageLoader : 实现
  • SDWebImageManager:对外提供 loadImage(with:...),内部先查 imageCache,再根据需要调用 imageLoader,最后根据 context 决定是否解码、变换并写回缓存。
  • SDWebImageDownloader:实现 SDImageLoader 协议,通过 URLSession 下载,支持并发数、超时、RequestModifier;单次下载封装为 SDWebImageDownloaderOperation
  • SDImageCache:内存缓存通常用 NSCache 或自研 LRU,磁盘缓存为文件系统;query/store 的 key 由 Manager 根据 URL + context(含 transformer 等)生成。

4. 解码与变换类结构

Coder 将 Data 转为 Image(或反向);Transformer 将 Image 转为另一 Image。Manager 在「Loader 返回 Data 后」先选 Coder 解码,再按 context 中的 Transformer 做变换,得到最终 Image 再写入 Cache。

classDiagram
    class SDWebImageManager {
        -loadImage(with:...)
    }
    class SDImageCoder {
        <<protocol>>
        +decodedImageWithData:options()
        +encodedDataWithImage:format:options()
        +canDecodeFromData()
        +canEncodeToFormat()
    }
    class SDImageCodersManager {
        -coders: [SDImageCoder]
        +addCoder()
        +removeCoder()
        +canDecodeFromData()
        +decodedImageWithData:options()
    }
    class SDImageTransformer {
        <<protocol>>
        +transformerKey
        +transformedImageWithImage:forKey()
    }
    class SDImagePipelineTransformer {
        -transformers: [SDImageTransformer]
        +transformerKey
        +transformedImageWithImage:forKey()
    }
    SDWebImageManager ..> SDImageCodersManager : 解码时使用
    SDWebImageManager ..> SDImageTransformer : 变换时使用
    SDImageCodersManager --> SDImageCoder : 委托具体 Coder
    SDImagePipelineTransformer ..|> SDImageTransformer : 实现
  • SDImageCodersManager:持有一组 SDImageCoder,按 canDecodeFromData: 选出第一个能处理当前 Data 的 Coder 执行解码;编码同理。
  • SDImagePipelineTransformer:持有一组 SDImageTransformer,按顺序对 Image 依次变换;其 transformerKey 通常由各子 Transformer 的 key 拼接而成,参与缓存 key 生成。

5. View 扩展与调用链

视图扩展(如 UIImageView+WebCache)是业务最常接触的入口:内部将「当前 URL、placeholder、options、context」交给 SDWebImageManager,并把返回的加载任务与 view 关联,以便在复用时取消。

sequenceDiagram
    participant V as UIImageView
    participant Ext as UIImageView+WebCache
    participant M as SDWebImageManager
    participant C as SDImageCache
    participant L as SDWebImageDownloader

    V->>Ext: sd_setImage(with: url, ...)
    Ext->>Ext: sd_cancelCurrentImageLoad()
    Ext->>M: loadImage(with: url, context: [...])
    M->>C: queryImage(forKey:)
    alt 缓存命中
        C-->>M: image
        M-->>Ext: completed(image, .memory/.disk)
    else 未命中
        M->>L: requestImageWithURL:...
        L-->>M: data
        M->>M: 解码 + 变换
        M->>C: storeImage(forKey:)
        M-->>Ext: completed(image, .none)
    end
    Ext->>V: imageView.image = image
  • sd_setImage(with: placeholder: options: context: completed:):先对当前 view 取消未完成任务,再调 SDWebImageManager.shared.loadImage(with: url, options: options, context: context, progress: progress, completed: completed);在 completed 中把得到的 image 赋给 imageView.image(并可选执行 transition 动画)。
  • sd_cancelCurrentImageLoad():取消与该 view 绑定的 load 任务,避免 cell 复用时旧请求覆盖新图片。

将上述「核心类总览」「模块依赖」「Loader/Cache 类图」「Coder/Transformer 类图」「View 调用链」串联起来,即可形成对 SDWebImage 类结构图 的完整分析:入口在视图扩展,核心协调在 Manager,加载与缓存、解码与变换均为可插拔的协议实现,便于扩展与测试。


五、与系统及业界实践的衔接

1. Apple 图像与图形最佳实践

Apple 在 WWDC 2018「Image and Graphics Best Practices」[1] 中强调:

  • 在后台线程进行解码与下采样,避免在主线程做重 CPU 工作导致的卡顿。
  • 解码时即做下采样,使解码后的图像缓冲与显示尺寸匹配,降低内存与 CPU。
  • 预取(Prefetch):在列表等场景提前准备即将显示的图像,避免在滚动时才开始解码。

SDWebImage 的解码与变换均在后台队列执行,且支持按尺寸/字节限制的缩略图解码,与上述建议一致。其 Prefetch 能力(如 UITableView 的 prefetch 结合 sd_setImageWithURL:)可在业务层配合使用,实现「提前解码、避免滚动时卡顿」。

Force Decode 策略(5.17+):SDWebImage 引入 SDImageForceDecodePolicy,用于控制是否在加载管线中强制解码(将延迟解码的图片提前转为位图)。在部分场景下可避免在渲染阶段才触发 CA 的帧缓冲拷贝,从而降低主线程峰值与内存抖动;具体策略可根据「是否使用自定义渲染」「是否配合 Transformer」等选择,详见官方文档与 CHANGELOG。

2. 移动端图像管线研究简述

在移动端部署图像管线(含解码、缩放、轻量级「变换」)方面,业界与学界有大量工作:

  • FlexiViT [7] 等通过可变的 patch 尺寸在训练与推理时平衡精度与速度;
  • NanoFLUX [8]、SnapGen [9] 等关注在移动设备上的高效图像生成与压缩。
    这些工作与「在端侧做高效解码与分辨率控制」的目标一致:在有限算力与内存下,通过解码阶段控制(如缩略图、渐进解码)和管线化处理(解码 → 变换 → 缓存)提升体验。SDWebImage 的 Decoder + Transformer 双管线正是这一思路在「图片加载库」中的具体实现。

六、使用案例与原理分析

0. 框架结构速览

0.1 实现原理

  1. 架构图(UML 类图)

架构图(UML 类图)

  1. 流程图(方法调用顺序图)

1559217862563-364c0d60-3f2a-4db9-b5c5-e81f01cd125e.png

0.2 目录结构

  • Downloader\
    • SDWebImageDownloader\
    • SDWebImageDownloaderOperation
  • Cache\
    • SDImageCache
  • Utils\
    • SDWebImageManager\
    • SDWebImageDecoder\
    • SDWebImagePrefetcher
  • Categories\
    • UIView+WebCacheOperation\
    • UIImageView+WebCache\
    • UIImageView+HighlightedWebCache\
    • UIButton+WebCache\
    • MKAnnotationView+WebCache\
    • NSData+ImageContentType\
    • UIImage+GIF\
    • UIImage+MultiFormat\
    • UIImage+WebP
  • Other\
    • SDWebImageOperation(协议)\
    • SDWebImageCompat(宏定义、常量、通用函数)

0.3 相关类名与功能描述

  • SDWebImageDownloader:是专门用来下载图片和优化图片加载的,跟缓存没有关系
  • SDWebImageDownloaderOperation:继承于 NSOperation,用来处理下载任务的
  • SDImageCache:用来处理内存缓存和磁盘缓存(可选)的,其中磁盘缓存是异步进行的,因此不会阻塞主线程
  • SDWebImageManager:作为 UIImageView+WebCache 背后的默默付出者,主要功能是将图片下载(SDWebImageDownloader)和图片缓存(SDImageCache)两个独立的功能组合起来
  • SDWebImageDecoder:图片解码器,用于图片下载完成后进行解码
  • SDWebImagePrefetcher:预下载图片,方便后续使用,图片下载的优先级低,其内部由 SDWebImageManager 来处理图片下载和缓存
  • UIView+WebCacheOperation:用来记录图片加载的 operation,方便需要时取消和移除图片加载的 operation
  • UIImageView+WebCache:集成 SDWebImageManager 的图片下载和缓存功能到 UIImageView 的方法中,方便调用方的简单使用
  • UIImageView+HighlightedWebCache:跟 UIImageView+WebCache 类似,也是包装了 SDWebImageManager,只不过是用于加载 highlighted 状态的图片
  • UIButton+WebCache:跟 UIImageView+WebCache 类似,集成 SDWebImageManager 的图片下载和缓存功能到 UIButton 的方法中,方便调用方的简单使用
  • MKAnnotationView+WebCache:跟 UIImageView+WebCache 类似
  • NSData+ImageContentType:用于获取图片数据的格式(JPEG、PNG 等)
  • UIImage+GIF:用于加载 GIF 动图
  • UIImage+MultiFormat:根据不同格式的二进制数据转成 UIImage 对象
  • UIImage+WebP:用于解码并加载 WebP 图片

0.4 工作流程

工作流程

  • 入口 setImageWithURL:placeholderImage:options: 会先把 placeholderImage 显示,然后 SDWebImageManager 根据 URL 开始处理图片。
  • 进入 SDWebImageManager-downloadWithURL:delegate:options:userInfo: 交给 SDImageCache 从缓存查找图片是否已经下载 queryDiskCacheForKey:delegate:userInfo:。
  • 先从内存图片缓存查找是否有图片,如果内存中已经有图片缓存,SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。
  • SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage: 到 UIImageView+WebCache 等前端展示图片。
  • 如果内存缓存中没有,生成 NSInvocationOperation 添加到队列开始从硬盘查找图片是否已经缓存。
  • 根据 URLKey 在硬盘缓存目录下尝试读取图片文件。这一步是在 NSOperation 进行的操作,所以回主线程进行结果回调 notifyDelegate:。
  • 如果从硬盘读取到了图片,将图片添加到内存缓存中(如果空闲内存过小,会先清空内存缓存)。SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 进而回调展示图片。
  • 如果从硬盘缓存目录读取不到图片,说明所有缓存都不存在该图片,需要下载图片,回调 imageCache:didNotFindImageForKey:userInfo:。
  • 共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片。
  • 图片下载由 NSURLConnection(3.8.0 之后使用了 NSURLSession),实现相关 delegate 来判断图片下载中、下载完成和下载失败。
  • connection:didReceiveData: 中利用 ImageIO 做了按图片下载进度加载效果。connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。
  • 图片解码处理在一个 NSOperationQueue 完成,不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理,最好也在这里完成,效率会好很多。
  • 在主线程 notifyDelegateOnMainThreadWithInfo: 宣告解码完成,imageDecoder:didFinishDecodingImage:userInfo: 回调给 SDWebImageDownloader。
  • imageDownloader:didFinishWithImage: 回调给 SDWebImageManager 告知图片下载完成。
  • 通知所有的 downloadDelegates 下载完成,回调给需要的地方展示图片。
  • 将图片保存到 SDImageCache 中,内存缓存和硬盘缓存同时保存。写文件到硬盘也在以单独 NSInvocationOperation 完成,避免拖慢主线程。
  • SDImageCache 在初始化的时候会注册一些消息通知,在内存警告或退到后台的时候清理内存图片缓存,应用结束的时候清理过期图片。
  • SDWebImagePrefetcher 可以预先下载图片,方便后续使用。

1. 典型使用案例

1.1 列表 Cell 中加载缩略图(防错位 + 下采样)

UITableView / UICollectionView 的 cell 中,若不限制图片尺寸,大图会带来内存峰值与卡顿;且 cell 复用时需避免「先显示旧图再被新图覆盖」的错位。SDWebImage 通过 URL 绑定取消机制 解决错位,通过 Transformer 限制尺寸 控制内存。

// Cell 内
func configure(with url: URL) {
    imageView.sd_cancelCurrentImageLoad()
    let transformer = SDImageResizingTransformer(
        size: CGSize(width: 120, height: 120),
        scaleMode: .aspectFill
    )
    imageView.sd_setImage(
        with: url,
        placeholderImage: UIImage(named: "placeholder"),
        context: [.imageTransformer: transformer]
    )
}

要点sd_cancelCurrentImageLoad() 会取消该 view 上未完成的请求,新 URL 加载完成后才设置,避免复用时显示错误图片。

1.2 预取(Prefetch)提前解码

利用系统预取 API 在 cell 尚未显示时就开始加载,滚动时直接从缓存读取,减少卡顿。

// 实现 UICollectionViewDataSourcePrefetching
func collectionView(_ collectionView: UICollectionView, prefetchItemsAt indexPaths: [IndexPath]) {
    let urls = indexPaths.compactMap { model(at: $0).imageURL }
    urls.forEach { url in
        SDWebImagePrefetcher.shared.prefetchURLs([url])
    }
}

// 可选:取消不再需要的预取
func collectionView(_ collectionView: UICollectionView, cancelPrefetchingForItemsAt indexPaths: [IndexPath]) {
    let urls = indexPaths.compactMap { model(at: $0).imageURL }
    SDWebImagePrefetcher.shared.cancelPrefetching(for: urls)
}

1.3 多设备/多 Channel 下的加载

在多设备场景(如同一 URL 在不同 Channel 下需要不同尺寸)中,通过 context 传入不同的 Transformer 或 Cache,使同一 URL 对应多条缓存条目。

// 列表用小图
imageView.sd_setImage(with: url, context: [
    .imageTransformer: SDImageResizingTransformer(size: CGSize(width: 80, height: 80), scaleMode: .aspectFill)
])

// 详情用原图或大图
detailImageView.sd_setImage(with: url)  // 不传 transformer,用原图

1.4 占位图 + 加载完成过渡动画

通过 sd_imageTransition 在图片从网络加载完成后做淡入等过渡,提升观感。

imageView.sd_imageTransition = .fade(0.25)
imageView.sd_setImage(with: url, placeholderImage: placeholder)

1.5 仅下载不展示(后台缓存)

希望提前把图片下载并写入缓存,供后续使用,而不绑定到某个 view。

SDWebImageManager.shared.loadImage(
    with: url,
    options: [],
    progress: nil
) { image, data, error, cacheType, finished, url in
    if let image = image, finished {
        // 已缓存,可做后续逻辑
    }
}

1.6 完成回调与错误处理

通过 completed 区分来源(内存/磁盘/网络)并处理失败与取消。

imageView.sd_setImage(with: url, placeholderImage: placeholder) { image, error, cacheType, url in
    if let error = error {
        // 可根据 error 类型提示用户或降级
        return
    }
    switch cacheType {
    case .none:   break // 本次从网络加载
    case .memory: break // 从内存缓存
    case .disk:   break // 从磁盘缓存
    @unknown default: break
    }
}

2. 更多使用案例与代码

2.1 UITableViewCell 完整示例(含复用与尺寸)

class PhotoCell: UITableViewCell {
    static let reuseId = "PhotoCell"
    @IBOutlet weak var photoImageView: UIImageView!
    @IBOutlet weak var progressView: UIProgressView!

    override func prepareForReuse() {
        super.prepareForReuse()
        photoImageView.sd_cancelCurrentImageLoad()
        photoImageView.image = nil
        progressView.progress = 0
    }

    func configure(with url: URL) {
        let size = photoImageView.bounds.size
        let transformer = SDImageResizingTransformer(
            size: size.isEmpty ? CGSize(width: 120, height: 120) : size,
            scaleMode: .aspectFill
        )
        photoImageView.sd_setImage(
            with: url,
            placeholderImage: UIImage(named: "placeholder"),
            context: [.imageTransformer: transformer],
            progress: { [weak self] received, total, _ in
                guard let self = self, total > 0 else { return }
                DispatchQueue.main.async {
                    self.progressView.progress = Float(received) / Float(total)
                }
            },
            completed: { [weak self] image, error, _, _ in
                DispatchQueue.main.async {
                    self?.progressView.isHidden = (image != nil)
                }
            }
        )
    }
}

2.2 UIButton 设置网络图片

// 设置不同 state 的图片
button.sd_setImage(with: url, for: .normal, placeholderImage: UIImage(named: "btn_placeholder"))
button.sd_setImage(with: highlightedURL, for: .highlighted)
button.sd_setBackgroundImage(with: backgroundURL, for: .normal)

// 带圆角与完成回调
let transformer = SDImageRoundCornerTransformer(radius: 8, corners: .allCorners, borderWidth: 0, borderColor: nil)
button.sd_setImage(with: url, for: .normal, placeholderImage: nil, context: [.imageTransformer: transformer]) { _, error, _, _ in
    if error != nil { print("加载失败") }
}

2.3 自定义缓存键(同一 URL 多用途)

当同一 URL 在不同业务下需要不同缓存(例如列表用缩略图、详情用原图)时,可用 cacheKeyFilter 或自定义 key。

// 方式一:通过 context 的 cacheKeyFilter 生成不同 key
let listKeyFilter: SDWebImageCacheKeyFilter = { url in
    return "list_\(url?.absoluteString ?? "")" as NSString
}
imageView.sd_setImage(with: url, context: [.cacheKeyFilter: listKeyFilter])

let detailKeyFilter: SDWebImageCacheKeyFilter = { url in
    return "detail_\(url?.absoluteString ?? "")" as NSString
}
detailImageView.sd_setImage(with: url, context: [.cacheKeyFilter: detailKeyFilter])

// 方式二:在业务层用不同 URL 或 query 区分(如服务端支持 ?size=thumb)
let listURL = url.appendingPathComponent("?size=thumb")
let detailURL = url
imageView.sd_setImage(with: listURL, context: [.cacheKeyFilter: listKeyFilter])
detailImageView.sd_setImage(with: detailURL, context: [.cacheKeyFilter: detailKeyFilter])

2.4 请求修饰(Header、Token、超时)

需要带鉴权或自定义 Header 时,使用 requestModifier

let modifier = SDWebImageDownloaderRequestModifier { request in
    var r = request
    r.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")
    r.setValue("image/webp,image/*,*/*;q=0.8", forHTTPHeaderField: "Accept")
    r.timeoutInterval = 30
    return r
}
imageView.sd_setImage(
    with: url,
    context: [.requestModifier: modifier]
)

2.5 下载进度条 + 占位 + 过渡动画

imageView.sd_imageTransition = .fade(0.3)
imageView.sd_setImage(
    with: url,
    placeholderImage: UIImage(named: "placeholder"),
    options: [.retryFailed],
    progress: { [weak progressView] received, total, _ in
        guard let pv = progressView, total > 0 else { return }
        DispatchQueue.main.async {
            pv.progress = Float(received) / Float(total)
            pv.isHidden = false
        }
    },
    completed: { [weak progressView] image, _, cacheType, _ in
        DispatchQueue.main.async {
            progressView?.isHidden = true
            if image == nil { /* 显示失败占位 */ }
        }
    }
)

2.6 动图 GIF(SDAnimatedImageView)

// 使用 SDAnimatedImageView 播放 GIF/WebP/APNG
let animatedImageView = SDAnimatedImageView()
animatedImageView.sd_setImage(with: gifURL, placeholderImage: nil)

// 仅加载动图第一帧作为封面(节省内存)
animatedImageView.sd_setImage(with: gifURL, placeholderImage: nil, options: [.decodeFirstFrameOnly])

// 渐进式加载动图(边下边播)
animatedImageView.sd_setImage(with: gifURL, placeholderImage: nil, options: [.progressiveLoad])

2.7 缓存查询与手动存储

let cache = SDImageCache.shared
let key = url.absoluteString

// 查询是否已缓存
cache.containsImage(forKey: key) { cacheType in
    switch cacheType {
    case .none:   print("未缓存")
    case .memory: print("在内存")
    case .disk:   print("在磁盘")
    @unknown default: break
    }
}

// 从缓存读取(不触发下载)
cache.queryImage(forKey: key, options: nil, context: nil) { image, data, cacheType in
    if let image = image {
        imageView.image = image
    }
}

// 手动写入缓存(例如本地生成或从相册来的图)
cache.store(image, forKey: key, completion: nil)

2.8 自定义 Transformer 示例

实现 SDImageTransformer 协议,对已解码图像做自定义绘制或滤镜(以下方法名以 SDWebImage 5.x 协议为准,实际请参照当前版本头文件)。

// 实现协议:为图片加灰色边框
class GrayBorderTransformer: NSObject, SDImageTransformer {
    var transformerKey: String { "GrayBorder(\(borderWidth))" }
    let borderWidth: CGFloat

    init(borderWidth: CGFloat = 2) { self.borderWidth = borderWidth }

    func transformedImage(with image: UIImage, forKey key: String) -> UIImage? {
        let size = image.size
        UIGraphicsBeginImageContextWithOptions(size, false, image.scale)
        defer { UIGraphicsEndImageContext() }
        image.draw(at: .zero)
        UIColor.gray.setStroke()
        let path = UIBezierPath(rect: CGRect(origin: .zero, size: size).insetBy(dx: borderWidth/2, dy: borderWidth/2))
        path.lineWidth = borderWidth
        path.stroke()
        return UIGraphicsGetImageFromCurrentImageContext()
    }
}

// 使用
let transformer = GrayBorderTransformer(borderWidth: 3)
imageView.sd_setImage(with: url, context: [.imageTransformer: transformer])

2.9 强制刷新与仅从缓存读取

// 忽略缓存,强制重新下载(适用于需要刷新内容的场景)
imageView.sd_setImage(with: url, options: [.forceRefresh])

// 仅从缓存读取,没有则显示占位或报错(离线/省流量场景)
imageView.sd_setImage(with: url, options: [.onlyFromCache]) { image, error, _, _ in
    if image == nil { print("缓存中无此图") }
}

2.10 Objective-C 常用写法

// 基础加载
[imageView sd_setImageWithURL:url placeholderImage:[UIImage imageNamed:@"placeholder"]];

// 带 context 的 Transformer
id<SDImageTransformer> transformer = [SDImagePipelineTransformer transformerWithTransformers:@[
    [SDImageResizingTransformer transformerWithSize:CGSizeMake(100, 100) scaleMode:SDImageScaleModeFill],
    [SDImageRoundCornerTransformer transformerWithRadius:10 corners:SDRectCornerAllCorners borderWidth:0 borderColor:nil]
]];
[imageView sd_setImageWithURL:url placeholderImage:nil context:@{SDWebImageContextImageTransformer: transformer}];

// 取消当前加载
[imageView sd_cancelCurrentImageLoad];

// 完成回调
[imageView sd_setImageWithURL:url completed:^(UIImage * _Nullable image, NSError * _Nullable error, SDImageCacheType cacheType, NSURL * _Nullable imageURL) {
    if (error) { NSLog(@"加载失败: %@", error); }
}];

3. 核心流程原理分析

3.1 Manager 协调的完整链路

SDWebImageManager 是整条「加载 → 解码 → 变换 → 缓存」的协调者,其内部逻辑可概括为:

flowchart TD
    A[loadImageWithURL] --> B{查缓存 key}
    B --> C[先查内存]
    C --> D{命中?}
    D -->|是| E[回调 .memory]
    D -->|否| F[再查磁盘]
    F --> G{命中?}
    G -->|是| H[解码/反序列化]
    H --> I[写回内存]
    I --> E
    G -->|否| J[构造 Loader 任务]
    J --> K[Loader 返回 Data]
    K --> L[Coder 解码]
    L --> M{有 Transformer?}
    M -->|是| N[Transformer 变换]
    M -->|否| O[得到 Image]
    N --> O
    O --> P[写内存+磁盘缓存]
    P --> Q[回调 .none 或 .disk]

要点

  • 缓存 key 由 URL(或自定义 key)与 context(如 transformer、cacheKeyFilter)共同决定,同一 URL 不同 transformer 会得到不同 key。
  • 解码与变换均在 Manager 持有的串行/并发队列 中执行,回调通过 dispatch_async(main_queue) 回到主线程,便于更新 UI。

3.2 回调与线程模型

  • progress:在下载进度回调所在线程(多为 URLSession 回调线程),若需更新 UI 需自行切主线程。
  • completed:SDWebImage 内部会派发到主线程再调用,因此 completed 里可直接操作 UI。
  • 取消:当再次对同一 view 调用 sd_setImage(with: newURL) 时,会取消该 view 上此前由 SDWebImage 发起的任务,completed 仍可能被调用一次(cancel 语义),可通过 SDWebImageOption 或检查 finished 区分。

3.3 缓存键与 Transformer 的关系

变换后的图片会以「新 key」写入缓存:通常为 key + transformerIdentifier 或等价组合。因此:

  • 原图:key = url.absoluteString(或自定义)。
  • 变换图:key = f(url, transformer),例如 url.absoluteString + "_" + transformer.identifier

这样同一 URL 可同时存在「原图」与「缩放版」「圆角版」等多份缓存,互不覆盖;原图也可通过 SDWebImageContextOriginalImageCache 写入单独缓存实例,供大图页等使用。


七、设计模式与编程思想

1. 设计模式应用

SDWebImage 在架构上大量运用经典设计模式,使扩展与维护成本可控。

模式 在 SDWebImage 中的体现 作用
外观 / 门面(Facade) SDWebImageManager 对外提供 loadImage(with:options:progress:completed:),内部协调 Loader、Cache、Coder、Transformer,调用方无需关心多级缓存与管线顺序 简化使用、隐藏复杂度
策略(Strategy) SDImageTransformerSDImageCoder 均为协议,多种实现可替换(Resizing、RoundCorner、WebP Coder 等),通过 context 或注册表注入 算法/行为可插拔,易扩展新格式与新变换
责任链 / 管道(Chain of Responsibility / Pipeline) SDImagePipelineTransformer 将多个 Transformer 串联;解码管线中 Coder 的选取也可视为「按责任链匹配 canDecodeFromData」 多步处理顺序清晰,便于组合与复用
单例 + 共享依赖(Singleton) SDWebImageManager.sharedSDImageCache.sharedSDWebImageDownloader.shared 提供默认实例,同时支持传入自定义 Cache/Loader 以打破单例 全局统一入口,又保留可测试性与多实例能力
观察者 / 回调(Observer / Callback) 通过 progresscompleted 闭包通知进度与结果;部分能力通过 delegate 扩展 异步结果与 UI 解耦
工厂思想(Factory) SDImageCodersManager 根据 Data 格式选择 Coder;Loader 根据 URL 或 scheme 选择具体 Loader 实现 创建逻辑集中,便于支持新协议与新格式

类图关系(概念层)

classDiagram
    class SDWebImageManager {
        -cache: SDImageCache
        -loader: SDImageLoader
        +loadImage(with:options:progress:completed:)
    }
    class SDImageCache {
        +store(_:forKey:)
        +queryImage(forKey:options:callback:)
    }
    class SDImageLoader {
        +loadImage(with:options:progress:completed:)
    }
    class SDImageCoder {
        <<protocol>>
        +decodedImageWithData:options:
        +canDecodeFromData:
    }
    class SDImageTransformer {
        <<protocol>>
        +transform(image:key:)
    }
    SDWebImageManager --> SDImageCache : 使用
    SDWebImageManager --> SDImageLoader : 使用
    SDWebImageManager ..> SDImageCoder : 解码时选用
    SDWebImageManager ..> SDImageTransformer : 变换时选用

2. 编程思想精华

SDWebImage 的编程思想可提炼为以下几点,对理解与模仿其设计很有帮助。

2.1 协议导向与「可替换实现」

  • CoderTransformerLoaderCache 均以协议或抽象接口呈现,具体实现可替换、可组合。
  • 新增一种图片格式或一种变换,只需实现对应协议并注册,无需改动 Manager 核心流程。这体现了开闭原则:对扩展开放,对修改关闭。

2.2 管线化与单一职责

  • 把「从 URL 到屏幕」拆成:加载 → 解码 → 变换 → 缓存 → 展示,每一步只做一件事。
  • 解码只关心 Data → Image,变换只关心 Image → Image,缓存只关心存储与查找。单一职责使每块可独立测试、优化和扩展;管线化则使数据流清晰,便于加日志、监控和插桩。

2.3 缓存键与「同一资源多形态」

  • 通过 key = f(URL, context) 的设计,同一 URL 可以对应「原图」「缩略图」「圆角图」等多条缓存,避免重复下载,又满足不同场景对尺寸/形态的需求。这体现了用键设计表达业务差异的思想。

2.4 后台处理与主线程回调

  • 解码、变换、磁盘 I/O 均在后台队列执行,completed 回调派发到主线程,兼顾性能与 UI 安全。这是移动端异步加载库的通用范式:重活放后台,结果回主线程

2.5 取消与生命周期绑定

  • View 扩展(如 UIImageView+WebCache)会把「当前正在进行的任务」与 view 绑定,当对同一 view 发起新请求时自动取消旧请求,避免错位和浪费。这体现了生命周期与请求绑定的思想,在列表场景中尤为重要。

2.6 配置通过 Context 透传

  • 不通过全局单例属性堆砌配置,而是通过 SDWebImageContext 在单次请求中传入 Cache、Transformer、Loader、CacheKeyFilter 等,使「同一 App 内不同页面/模块」可使用不同策略,且易于单元测试时注入 mock。

SDWebImage 编程思想精华一览

思想 在框架中的体现
协议导向、可替换 Coder / Transformer / Loader 协议化,新格式、新变换仅需实现协议并注册
管线化、单一职责 加载 → 解码 → 变换 → 缓存 → 展示,每步职责单一,便于扩展与测试
键设计表达多形态 同一 URL 通过 key = f(URL, context) 支持原图、缩略图、圆角图等多条缓存
后台处理、主线程回调 重 CPU/IO 在后台队列,completed 回主线程,兼顾性能与 UI 安全
生命周期绑定取消 View 与当前任务绑定,新请求自动取消旧请求,避免列表错位
Context 透传配置 单次请求级配置,避免全局状态,利于多策略并存与测试注入

八、使用示例与最佳实践

1. 使用内置变换器(缩放 + 圆角)

let transformer = SDImagePipelineTransformer(transformers: [
    SDImageResizingTransformer(size: CGSize(width: 300, height: 300), scaleMode: .fill),
    SDImageRoundCornerTransformer(radius: 20, corners: .allCorners, borderWidth: 0, borderColor: nil)
])
imageView.sd_setImage(with: url, placeholderImage: nil, context: [.imageTransformer: transformer])

2. 仅下载并变换、不写缓存

SDWebImageManager.shared.loadImage(
    with: url,
    options: [.fromLoaderOnly],
    context: [.storeCacheType: SDImageCacheType.none.rawValue, .imageTransformer: transformer],
    progress: nil
) { image, _, _, _, _, _ in
    // 使用变换后的 image
}

3. 渐进式加载(渐进解码)

imageView.sd_setImage(with: url, placeholderImage: nil, options: [.progressiveLoad])

4. 自定义 Coder 注册(以 WebP 为例)

SDImageCodersManager.shared.addCoder(SDImageWebPCoder.shared)

5. 最佳实践小结

  • 列表/网格:cell 内先 sd_cancelCurrentImageLoad(),再 sd_setImage,并配合 Transformer 限制尺寸或使用下采样选项,减少内存与错位。
  • 预取:用 SDWebImagePrefetcher 或系统 prefetch API 提前加载即将出现的图片,滚动时优先命中缓存。
  • 大图/详情:列表用缩小版 Transformer,详情页用原图或单独 OriginalImageCache,避免重复下载。
  • 动图:使用 SDAnimatedImageView + SDAnimatedImage,并视情况注册 GIF/WebP/APNG 等 Coder。
  • 扩展与测试:自定义 Coder/Transformer 通过协议实现并注册;通过 context 注入自定义 Cache/Loader 便于单测与多策略并存。

九、常见面试题

1. 图片文件缓存的时间有多长?

一周。_maxCacheAge = kDefaultCacheMaxCacheAge

2. SDWebImage 的内存缓存是用什么实现的?

NSCache

3. SDWebImage 的最大并发数是多少?

maxConcurrentDownloads = 6(程序固定,可通过属性调整)

4. SDWebImage 支持动图吗?GIF

支持。示例:

#import <ImageIO/ImageIO.h>
[UIImage animatedImageWithImages:images duration:duration];

5. SDWebImage 是如何区分不同格式的图像的?

  • 根据图像数据第一个字节来判断
  • PNG:压缩比没有 JPG 高,但无损压缩,解压缩性能高,苹果推荐的图像格式
  • JPG:压缩比最高的一种图片格式,有损压缩,最多使用的场景如照相机,解压缩性能不好
  • GIF:序列帧动图,只支持 256 种颜色,曾流行于 1998~1999,有专利

6. SDWebImage 缓存图片的名称是怎么确定的?

  • 使用 md5 对完整 URL 做散列,得到 32 位字符串作为文件名;若单纯用文件名保存,重名几率高

7. SDWebImage 的内存警告是如何处理的?

  • 利用通知中心观察:
    • UIApplicationDidReceiveMemoryWarningNotification:接收到内存警告后执行 clearMemory,清理内存缓存
    • UIApplicationWillTerminateNotification:接收到应用将要终止后执行 cleanDisk,清理磁盘缓存
    • UIApplicationDidEnterBackgroundNotification:接收到应用进入后台后执行 backgroundCleanDisk,后台清理磁盘
  • 通过以上通知监听,保证缓存文件大小在控制范围内;clearDisk 可清空磁盘缓存,删除缓存目录中全部文件

参考文献

[1] Apple. Image and Graphics Best Practices. WWDC 2018, Session 219.
[2] Stack Overflow / Apple. Creating a thumbnail from UIImage using CGImageSourceCreateThumbnailAtIndex.
[3] Apple. Image decompression strategies for performance. developer.apple.com/forums/thread/653738.
[4] Ctrl.blog. Progressive JPEG loading; Google 研究:渐进解码约 3 倍于 baseline 的 CPU 开销.
[5] Wikipedia. Digital image processing.
[6] SDWebImage. Advanced Usage - Image Transformer, Custom Coder. GitHub Wiki.
[7] Beyer et al. FlexiViT: One Model for All Patch Sizes. CVPR 2023.
[8] NanoFLUX. Distillation-Driven Compression of Large Text-to-Image Generation Models for Mobile Devices. arXiv.
[9] SnapGen. Taming High-Resolution Text-to-Image Models for Mobile Devices. arXiv 2024.

04-研究优秀开源框架@响应式编程@iOS | RxSwift框架:从使用到源码解析

📋 目录


一、RxSwift框架使用详解

1. RxSwift框架概述

RxSwift 是 ReactiveX(Reactive Extensions)的 Swift 实现,是一个用于处理异步事件流的函数式响应式编程框架。

1.1 什么是RxSwift

RxSwift 基于观察者模式,允许你通过组合不同的操作符来处理异步事件序列。它提供了声明式的 API 来处理时间序列数据。

核心特点:

  • 响应式编程:基于观察者模式的事件驱动编程
  • 函数式编程:使用高阶函数和操作符组合
  • 类型安全:充分利用 Swift 的类型系统
  • 跨平台:基于 ReactiveX 标准,与其他平台一致
  • 丰富的操作符:提供大量操作符处理各种场景

1.2 RxSwift vs Combine

特性 RxSwift Combine
平台 跨平台(iOS、macOS、watchOS、tvOS) Apple 生态(iOS 13+)
语言 Swift Swift
官方支持 ❌ 第三方(ReactiveX) ✅ Apple 官方
最低版本 iOS 8.0+ iOS 13.0+
API风格 ReactiveX 标准 Apple 风格
学习曲线 陡峭 中等
生态 丰富(RxCocoa、RxDataSources等) 官方集成(SwiftUI)

1.3 RxSwift生态系统

  • RxSwift:核心框架
  • RxCocoa:UIKit/AppKit 集成
  • RxDataSources:TableView/CollectionView 数据源
  • RxTest:测试工具
  • RxBlocking:阻塞操作符(用于测试)

1.4 安装方式

CocoaPods:

pod 'RxSwift', '~> 6.0'
pod 'RxCocoa', '~> 6.0'

SPM:

dependencies: [
    .package(url: "https://github.com/ReactiveX/RxSwift.git", from: "6.0.0")
]

1.5 编程思想(背后的范式与理念)

为什么要先谈编程思想?
会用 RxSwift 的 API(ObservablesubscribemapflatMap 等)不等于能写好响应式架构。很多「看起来能跑」的代码其实仍是用响应式语法写命令式逻辑(例如在 subscribe 里写满 if-else、嵌套请求),难以测试、难以复用。先理解背后的范式与理念,再写代码,才能做到「用对场景、写对抽象、边界清晰」。RxSwift 与 Combine 同属 ReactiveX 一脉,背后的编程思想高度一致;理解这些思想有助于写出更清晰、可维护的响应式代码。

范式定位:FRP(函数式响应式编程)
RxSwift 是 FRP(Functional Reactive Programming) 的一种实现:用函数式组合与不可变方式,处理响应式事件流。不是「要么函数式要么响应式」,而是两者结合——流用操作符做纯变换(函数式),用订阅对事件做出反应(响应式)。了解这一点,就不会把 Rx 单纯当成「另一种回调封装」,而是从「流 + 变换 + 订阅」的视角设计数据与 UI 的边界。


(1)响应式编程(Reactive Programming)

  • 核心:将「数据与事件」视为随时间发生的事件序列,通过订阅对序列中的每一项做出反应,而不是主动轮询或层层回调。
  • 在 RxSwift 中Observable 表示一条事件流,Observer 通过 subscribe 订阅后,在 onNext / onError / onCompleted 中响应;按钮点击、网络返回、定时器都可统一为 Observable,用同一套操作符处理。
  • 思维转变:从「先调 A,等回调再调 B」变为「当流里出现某类事件时,执行 B」,逻辑由数据/事件驱动。

(2)声明式 vs 命令式

维度 命令式(Imperative) 声明式(Declarative)
关注点 「怎么做」:显式控制顺序与分支 「做什么」:描述结果与数据变换关系
典型写法 for 循环、if-else、嵌套回调 链式操作符:map / filter / flatMap / combineLatest
在 RxSwift 中 手写「请求 → 回调里解析 → 再请求」 observable.map(...).flatMap(...).subscribe(...) 描述整条流水线

声明式让「数据从哪来、怎么变、到哪去」一目了然,便于阅读和单元测试。

从 OOP/命令式到响应式的思维转变:传统写法习惯「谁持有谁、谁调谁」——对象持有状态,方法里 if-else 控制流程,异步靠回调或 delegate。响应式则把「谁在什么时候产生什么」抽象成流,把「对数据的处理」抽象成操作符链,把「最终消费」放在订阅里。习惯后,你会先想「有哪些事件源」「它们如何组合、变换」,再写具体订阅逻辑,而不是一上来就写一堆属性和回调。

同一需求的两种写法对比(搜索框防抖 + 请求 + 只取非空):
命令式常见写法是:在文本回调里设 Timer、取消上一次请求、判断非空再发请求、在回调里更新 UI,逻辑分散在多处。用 RxSwift 可以写成一条「流」:

// 响应式:一条链描述「输入 → 防抖 → 非空过滤 → 请求 → 主线程更新」
searchTextField.rx.text.orEmpty
    .debounce(.milliseconds(300), scheduler: MainScheduler.instance)
    .filter { !$0.isEmpty }
    .flatMapLatest { query in api.search(query) }
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { results in self.updateUI(results) })
    .disposed(by: disposeBag)

这样,「防抖」「过滤空串」「只保留最后一次请求」「切回主线程」都体现在操作符上,阅读时一眼能看出数据流;单元测试时可以对 Observable 链单独测,而不必依赖 UI。

(3)函数式思想(组合与不可变)

  • 组合(Composition):每个操作符只做一件事,通过 .map().filter().distinctUntilChanged() 等组合成完整逻辑,而不是在一个闭包里写尽所有逻辑。
  • 不可变(Immutability):操作符不修改原 Observable,而是返回新的 Observable;原流不变,便于复用和推理。
  • 副作用边界:纯变换放在操作符链中,副作用(UI 更新、写库、弹窗)集中在 subscribe 的闭包里,便于测试和并发安全。

(4)流与时间(Streams & Time)

  • 把所有「会随时间产生的事件」都视为时间序列:next、next、…、completed/error。
  • 时间相关操作符:debounce(静默一段时间后取最新)、throttle(间隔内只取第一个/最后一个)、delay(延后发射),统一表达「何时」而不只是「何值」。

(5)观察者与发布-订阅

  • 观察者模式:Observer 订阅 Observable,在事件发生时被通知。RxSwift 的 subscribe(onNext:onError:onCompleted:) 就是在注册观察者。
  • 发布-订阅:生产端(Observable)与消费端(Observer)解耦,通过 Disposable 表示一次订阅的生命周期;Rx 的「热/冷」流、背压(部分算子)都是在这一模型上的扩展。

(6)设计原则在 Rx 中的体现

原则 在 RxSwift 中的体现
单一职责 每个操作符只做一种变换(map 只做映射,filter 只做过滤),复杂逻辑由链式组合完成。
关注点分离 数据获取与变换在 Observable 链中,线程切换用 subscribeOn/observeOn,副作用集中在 subscribe
依赖倒置 业务依赖「Observable 流」的抽象,而不依赖具体如何产生事件(网络、本地、Mock 都可替换)。
开闭原则 通过新操作符或新 Observable 扩展行为,而不必修改已有链;原流不可变,易于复用。

小结:RxSwift 用声明式事件流(Observable)和可组合操作符,在观察者/发布-订阅模型下做响应式的异步与事件处理,并用 Scheduler 控制线程与时机。掌握这些思想后,再写「为什么用 map 而不是在 subscribe 里写一大段」「为什么需要 observeOn/subscribeOn」会更自然。


2. 核心概念

2.1 Observable(可观察序列)

Observable 是 RxSwift 的核心,表示可以观察的事件序列。

protocol ObservableType {
    associatedtype Element
    func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element
}

特点:

  • 可以发出零个或多个事件
  • 可能以完成或错误结束
  • 是值类型(struct)
  • 不可变(每次操作返回新的 Observable)

事件类型:

enum Event<Element> {
    case next(Element)      // 下一个元素
    case error(Swift.Error) // 错误
    case completed          // 完成
}

示例:

// 创建一个简单的 Observable
let observable = Observable<String>.just("Hello, RxSwift!")

observable.subscribe(onNext: { value in
    print(value)  // 输出: Hello, RxSwift!
}, onError: { error in
    print("错误: \(error)")
}, onCompleted: {
    print("完成")
})
.disposed(by: disposeBag)

// 使用数组创建 Observable
let arrayObservable = Observable.from([1, 2, 3, 4, 5])

arrayObservable.subscribe(onNext: { value in
    print(value)  // 依次输出: 1, 2, 3, 4, 5
})
.disposed(by: disposeBag)

2.2 Observer(观察者)

Observer 是接收 Observable 事件的协议。

protocol ObserverType {
    associatedtype Element
    func on(_ event: Event<Element>)
}

内置 Observer:

  • onNext:接收下一个元素
  • onError:接收错误
  • onCompleted:接收完成事件

示例:

let observable = Observable.from([1, 2, 3])

observable.subscribe(
    onNext: { value in
        print("收到值: \(value)")
    },
    onError: { error in
        print("错误: \(error)")
    },
    onCompleted: {
        print("完成")
    }
)
.disposed(by: disposeBag)

2.3 Disposable(可释放资源)

Disposable 表示订阅关系,用于取消订阅和释放资源。

protocol Disposable {
    func dispose()
}

DisposeBag:

class ViewController: UIViewController {
    private let disposeBag = DisposeBag()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        Observable.just("Hello")
            .subscribe(onNext: { print($0) })
            .disposed(by: disposeBag)  // 自动管理生命周期
    }
}

3. Observable与Observer

3.1 创建Observable

just

创建只发出一个元素的 Observable。

let observable = Observable.just("Hello")
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
from

从数组或序列创建 Observable。

let observable = Observable.from([1, 2, 3])
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
of

从多个元素创建 Observable。

let observable = Observable.of(1, 2, 3)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
create

自定义创建 Observable。

let observable = Observable<String>.create { observer in
    observer.onNext("A")
    observer.onNext("B")
    observer.onCompleted()
    return Disposables.create()
}

observable.subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
empty

创建不发出任何元素的 Observable。

let observable = Observable<Int>.empty()
    .subscribe(
        onNext: { print($0) },
        onCompleted: { print("完成") }
    )
    .disposed(by: disposeBag)
// 输出: 完成
never

创建永不发出事件也永不完成的 Observable。

let observable = Observable<Int>.never()
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 无输出
error

创建立即发出错误的 Observable。

enum MyError: Error {
    case customError
}

let observable = Observable<Int>.error(MyError.customError)
    .subscribe(
        onNext: { print($0) },
        onError: { print("错误: \($0)") }
    )
    .disposed(by: disposeBag)
// 输出: 错误: customError
range

创建发出指定范围内整数的 Observable。

let observable = Observable.range(start: 1, count: 5)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 1, 2, 3, 4, 5
repeatElement

重复发出指定元素。

let observable = Observable.repeatElement("Hello")
    .take(3)  // 只取前3个
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: Hello, Hello, Hello
interval

按指定时间间隔发出整数。

let observable = Observable<Int>.interval(
    .seconds(1),
    scheduler: MainScheduler.instance
)
.take(5)
.subscribe(onNext: { print($0) })
.disposed(by: disposeBag)
// 每秒输出: 0, 1, 2, 3, 4
timer

延迟指定时间后发出元素。

let observable = Observable<Int>.timer(
    .seconds(2),
    scheduler: MainScheduler.instance
)
.subscribe(onNext: { print($0) })
.disposed(by: disposeBag)
// 2秒后输出: 0

3.2 自定义Observable

struct CustomObservable<Element>: ObservableType {
    typealias Element = Element
    
    private let _subscribe: (AnyObserver<Element>) -> Disposable
    
    init(_ subscribe: @escaping (AnyObserver<Element>) -> Disposable) {
        self._subscribe = subscribe
    }
    
    func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element {
        let anyObserver = AnyObserver(observer)
        return _subscribe(anyObserver)
    }
}

// 使用
let custom = CustomObservable<Int> { observer in
    observer.onNext(1)
    observer.onNext(2)
    observer.onCompleted()
    return Disposables.create()
}

custom.subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

4. Operators操作符

4.1 转换操作符

map

转换每个元素。

Observable.from([1, 2, 3])
    .map { $0 * 2 }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 2, 4, 6
flatMap

将 Observable 发出的元素转换为 Observable,然后合并。

Observable.from(["A", "B", "C"])
    .flatMap { letter in
        Observable.from([1, 2]).map { "\(letter)\($0)" }
    }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: A1, A2, B1, B2, C1, C2
flatMapLatest

只保留最新的内部 Observable。

Observable.from(["A", "B", "C"])
    .flatMapLatest { letter in
        Observable.just(letter).delay(.seconds(1), scheduler: MainScheduler.instance)
    }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 只输出: C(A和B被取消)
scan

累积值。

Observable.from([1, 2, 3, 4, 5])
    .scan(0, accumulator: +)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 1, 3, 6, 10, 15
buffer

缓冲元素。

Observable.from([1, 2, 3, 4, 5, 6, 7, 8])
    .buffer(timeSpan: .seconds(1), count: 3, scheduler: MainScheduler.instance)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: [1, 2, 3], [4, 5, 6], [7, 8]
window

将 Observable 分割为多个 Observable。

Observable.from([1, 2, 3, 4, 5, 6])
    .window(timeSpan: .seconds(1), count: 2, scheduler: MainScheduler.instance)
    .flatMap { $0 }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

4.2 过滤操作符

filter

过滤元素。

Observable.from([1, 2, 3, 4, 5])
    .filter { $0 % 2 == 0 }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 2, 4
distinctUntilChanged

移除连续重复的元素。

Observable.from([1, 1, 2, 2, 3, 3])
    .distinctUntilChanged()
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 1, 2, 3
elementAt

获取指定索引的元素。

Observable.from([1, 2, 3, 4, 5])
    .elementAt(2)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 3
first / last

获取第一个或最后一个元素。

Observable.from([1, 2, 3, 4, 5])
    .first()
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 1

Observable.from([1, 2, 3, 4, 5])
    .last()
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 5
take / takeLast

获取前几个或后几个元素。

Observable.from([1, 2, 3, 4, 5])
    .take(3)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 1, 2, 3

Observable.from([1, 2, 3, 4, 5])
    .takeLast(3)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 3, 4, 5
skip / skipLast

跳过前几个或后几个元素。

Observable.from([1, 2, 3, 4, 5])
    .skip(2)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 3, 4, 5
debounce

防抖,等待指定时间后发出最新值。

let subject = PublishSubject<String>()

subject
    .debounce(.milliseconds(500), scheduler: MainScheduler.instance)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

subject.onNext("H")     // 不输出
subject.onNext("He")    // 不输出
subject.onNext("Hel")   // 不输出
subject.onNext("Hell")  // 不输出
subject.onNext("Hello") // 0.5秒后输出: Hello
throttle

节流,在指定时间间隔内只发出第一个值。

let subject = PublishSubject<String>()

subject
    .throttle(.seconds(1), scheduler: MainScheduler.instance)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

subject.onNext("A")  // 立即输出: A
subject.onNext("B")  // 不输出(1秒内)
subject.onNext("C")  // 不输出(1秒内)
// 1秒后
subject.onNext("D")  // 输出: D

4.3 组合操作符

startWith

在序列开始前插入元素。

Observable.from([1, 2, 3])
    .startWith(0)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 0, 1, 2, 3
merge

合并多个 Observable。

let subject1 = PublishSubject<Int>()
let subject2 = PublishSubject<Int>()

Observable.merge(subject1, subject2)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

subject1.onNext(1)  // 输出: 1
subject2.onNext(2)  // 输出: 2
subject1.onNext(3)  // 输出: 3
combineLatest

组合多个 Observable 的最新值。

let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<Int>()

Observable.combineLatest(subject1, subject2)
    .subscribe(onNext: { value1, value2 in
        print("\(value1): \(value2)")
    })
    .disposed(by: disposeBag)

subject1.onNext("A")  // 无输出(等待 subject2)
subject2.onNext(1)    // 输出: A: 1
subject1.onNext("B")  // 输出: B: 1
subject2.onNext(2)    // 输出: B: 2
zip

按顺序组合多个 Observable。

let subject1 = PublishSubject<String>()
let subject2 = PublishSubject<Int>()

Observable.zip(subject1, subject2)
    .subscribe(onNext: { value1, value2 in
        print("\(value1): \(value2)")
    })
    .disposed(by: disposeBag)

subject1.onNext("A")  // 等待 subject2
subject1.onNext("B")  // 等待 subject2
subject2.onNext(1)    // 输出: A: 1
subject2.onNext(2)    // 输出: B: 2
withLatestFrom

当源 Observable 发出元素时,使用另一个 Observable 的最新值。

let button = PublishSubject<Void>()
let textField = PublishSubject<String>()

button
    .withLatestFrom(textField)
    .subscribe(onNext: { text in
        print("按钮点击,文本: \(text)")
    })
    .disposed(by: disposeBag)

textField.onNext("Hello")  // 无输出
textField.onNext("World")  // 无输出
button.onNext(())          // 输出: 按钮点击,文本: World
switchLatest

切换到最新的内部 Observable。

let subject1 = PublishSubject<Int>()
let subject2 = PublishSubject<Int>()
let source = PublishSubject<Observable<Int>>()

source
    .switchLatest()
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

source.onNext(subject1)
subject1.onNext(1)  // 输出: 1
subject1.onNext(2)  // 输出: 2

source.onNext(subject2)
subject1.onNext(3)  // 不输出(已切换)
subject2.onNext(4)  // 输出: 4

4.4 错误处理操作符

catchError

捕获错误并返回备用 Observable。

enum MyError: Error {
    case failure
}

let observable = Observable<String>.error(MyError.failure)
    .catchError { error -> Observable<String> in
        print("捕获错误: \(error)")
        return Observable.just("备用值")
    }
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 捕获错误: failure, 备用值
catchErrorJustReturn

用默认值替换错误。

let observable = Observable<String>.error(MyError.failure)
    .catchErrorJustReturn("默认值")
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: 默认值
retry

重试失败的 Observable。

var attempts = 0

let observable = Observable<String>.create { observer in
    attempts += 1
    if attempts < 3 {
        observer.onError(MyError.failure)
    } else {
        observer.onNext("成功")
        observer.onCompleted()
    }
    return Disposables.create()
}
.retry(2)  // 最多重试 2 次
.subscribe(
    onNext: { print($0) },
    onError: { print("错误: \($0)") }
)
.disposed(by: disposeBag)
// 输出: 成功
retryWhen

根据条件重试。

let observable = Observable<String>.error(MyError.failure)
    .retryWhen { errors in
        errors.enumerated().flatMap { index, error -> Observable<Int> in
            if index < 2 {
                return Observable<Int>.timer(.seconds(index + 1), scheduler: MainScheduler.instance)
            } else {
                return Observable.error(error)
            }
        }
    }
    .subscribe(
        onNext: { print($0) },
        onError: { print("最终错误: \($0)") }
    )
    .disposed(by: disposeBag)

4.5 工具操作符

do

执行副作用操作。

Observable.from([1, 2, 3])
    .do(onNext: { print("即将发出: \($0)") },
        onError: { print("错误: \($0)") },
        onCompleted: { print("完成") },
        onSubscribe: { print("订阅") },
        onDispose: { print("释放") })
    .subscribe(onNext: { print("收到: \($0)") })
    .disposed(by: disposeBag)
delay

延迟发出元素。

Observable.from([1, 2, 3])
    .delay(.seconds(1), scheduler: MainScheduler.instance)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 1秒后依次输出: 1, 2, 3
delaySubscription

延迟订阅。

Observable.from([1, 2, 3])
    .delaySubscription(.seconds(1), scheduler: MainScheduler.instance)
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 1秒后开始输出: 1, 2, 3
materialize / dematerialize

将事件序列化/反序列化。

Observable.from([1, 2, 3])
    .materialize()
    .subscribe(onNext: { event in
        print(event)  // 输出: next(1), next(2), next(3), completed
    })
    .disposed(by: disposeBag)
timeout

超时处理。

Observable<Int>.never()
    .timeout(.seconds(2), scheduler: MainScheduler.instance)
    .subscribe(
        onNext: { print($0) },
        onError: { print("超时: \($0)") }
    )
    .disposed(by: disposeBag)
// 2秒后输出: 超时: RxError.timeout

5. Subjects

Subjects 既是 Observable 又是 Observer,可以手动发送事件。

5.1 PublishSubject

不保存当前值,只向订阅者发送订阅后的事件。

let subject = PublishSubject<String>()

// 订阅1
subject.subscribe(onNext: { print("订阅1: \($0)") })
    .disposed(by: disposeBag)

subject.onNext("A")  // 输出: 订阅1: A

// 订阅2
subject.subscribe(onNext: { print("订阅2: \($0)") })
    .disposed(by: disposeBag)

subject.onNext("B")  // 输出: 订阅1: B, 订阅2: B
subject.onCompleted()

5.2 BehaviorSubject

保存当前值,新订阅者会立即收到当前值。

let subject = BehaviorSubject<String>(value: "初始值")

// 订阅1
subject.subscribe(onNext: { print("订阅1: \($0)") })
    .disposed(by: disposeBag)
// 输出: 订阅1: 初始值

subject.onNext("新值")  // 输出: 订阅1: 新值

// 订阅2
subject.subscribe(onNext: { print("订阅2: \($0)") })
    .disposed(by: disposeBag)
// 输出: 订阅2: 新值(立即收到当前值)

5.3 ReplaySubject

保存指定数量的最近值,新订阅者会收到这些值。

let subject = ReplaySubject<String>.create(bufferSize: 2)

subject.onNext("A")
subject.onNext("B")
subject.onNext("C")

// 订阅
subject.subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
// 输出: B, C(最近2个值)

5.4 AsyncSubject

只发出最后一个值(在完成时)。

let subject = AsyncSubject<String>()

subject.subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)

subject.onNext("A")  // 不输出
subject.onNext("B")  // 不输出
subject.onNext("C")  // 不输出
subject.onCompleted()  // 输出: C

6. Schedulers调度器

Schedulers 决定操作在哪个线程执行。

6.1 内置Scheduler

MainScheduler

主线程调度器。

Observable.just(1)
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { value in
        // 在主线程执行
        print(Thread.isMainThread)  // true
    })
    .disposed(by: disposeBag)
SerialDispatchQueueScheduler

串行队列调度器。

let scheduler = SerialDispatchQueueScheduler(
    qos: .userInitiated,
    internalSerialQueueName: "custom.queue"
)

Observable.just(1)
    .observeOn(scheduler)
    .subscribe(onNext: { value in
        // 在后台线程执行
    })
    .disposed(by: disposeBag)
ConcurrentDispatchQueueScheduler

并发队列调度器。

let scheduler = ConcurrentDispatchQueueScheduler(
    qos: .background
)

Observable.from([1, 2, 3])
    .observeOn(scheduler)
    .subscribe(onNext: { value in
        // 在后台线程执行
    })
    .disposed(by: disposeBag)
OperationQueueScheduler

操作队列调度器。

let queue = OperationQueue()
queue.maxConcurrentOperationCount = 2

let scheduler = OperationQueueScheduler(operationQueue: queue)

Observable.from([1, 2, 3, 4, 5])
    .observeOn(scheduler)
    .subscribe(onNext: { value in
        // 在操作队列执行
    })
    .disposed(by: disposeBag)

6.2 subscribeOn vs observeOn

  • subscribeOn:指定订阅在哪个线程执行
  • observeOn:指定后续操作在哪个线程执行
Observable.create { observer in
    print("订阅线程: \(Thread.current)")
    observer.onNext(1)
    observer.onCompleted()
    return Disposables.create()
}
.subscribeOn(ConcurrentDispatchQueueScheduler(qos: .background))
.observeOn(MainScheduler.instance)
.subscribe(onNext: { value in
    print("接收线程: \(Thread.current)")
})
.disposed(by: disposeBag)

7. 错误处理

7.1 错误类型

enum RxError: Swift.Error {
    case unknown
    case disposed
    case timeout
    case noElements
    case moreThanOneElement
}

enum NetworkError: Error {
    case invalidURL
    case noData
    case decodingError
}

7.2 错误处理策略

func fetchData() -> Observable<String> {
    return Observable.create { observer in
        // 模拟网络请求
        DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
            observer.onError(NetworkError.noData)
        }
        return Disposables.create()
    }
}

fetchData()
    .catchError { error -> Observable<String> in
        // 捕获错误,返回备用 Observable
        return Observable.just("默认数据")
    }
    .retry(3)  // 重试 3 次
    .subscribe(
        onNext: { print($0) },
        onError: { print("最终错误: \($0)") }
    )
    .disposed(by: disposeBag)

8. 内存管理

8.1 DisposeBag

自动管理订阅的生命周期。

class ViewController: UIViewController {
    private let disposeBag = DisposeBag()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        Observable.just("Hello")
            .subscribe(onNext: { print($0) })
            .disposed(by: disposeBag)  // 自动管理
    }
    
    // viewController 释放时,disposeBag 会自动释放所有订阅
}

8.2 避免循环引用

class ViewModel {
    private let disposeBag = DisposeBag()
    
    func setup() {
        Observable.just("Data")
            .subscribe(onNext: { [weak self] value in
                // 使用 weak self 避免循环引用
                self?.process(value)
            })
            .disposed(by: disposeBag)
    }
    
    private func process(_ value: String) {
        // 处理数据
    }
}

8.3 takeUntil

在指定条件满足时自动取消订阅。

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        Observable.interval(.seconds(1), scheduler: MainScheduler.instance)
            .takeUntil(self.rx.deallocated)  // viewController 释放时自动取消
            .subscribe(onNext: { print($0) })
            .disposed(by: disposeBag)
    }
}

9. 与UIKit集成

9.1 RxCocoa基础

RxCocoa 提供了 UIKit 的 Rx 扩展。

import RxSwift
import RxCocoa

class ViewController: UIViewController {
    @IBOutlet weak var textField: UITextField!
    @IBOutlet weak var button: UIButton!
    @IBOutlet weak var label: UILabel!
    
    private let disposeBag = DisposeBag()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 文本输入绑定
        textField.rx.text
            .bind(to: label.rx.text)
            .disposed(by: disposeBag)
        
        // 按钮点击
        button.rx.tap
            .subscribe(onNext: { [weak self] in
                self?.handleButtonTap()
            })
            .disposed(by: disposeBag)
    }
}

9.2 常用绑定

// UILabel
label.rx.text.onNext("Hello")
label.rx.attributedText.onNext(attributedString)

// UITextField
textField.rx.text
    .subscribe(onNext: { text in
        print("文本: \(text ?? "")")
    })
    .disposed(by: disposeBag)

// UIButton
button.rx.tap
    .subscribe(onNext: {
        print("按钮点击")
    })
    .disposed(by: disposeBag)

// UISwitch
switch.rx.isOn
    .subscribe(onNext: { isOn in
        print("开关: \(isOn)")
    })
    .disposed(by: disposeBag)

// UISlider
slider.rx.value
    .subscribe(onNext: { value in
        print("值: \(value)")
    })
    .disposed(by: disposeBag)

9.3 TableView绑定

import RxDataSources

class ViewController: UIViewController {
    @IBOutlet weak var tableView: UITableView!
    
    private let disposeBag = DisposeBag()
    private let items = BehaviorSubject<[String]>(value: ["Item 1", "Item 2", "Item 3"])
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let dataSource = RxTableViewSectionedReloadDataSource<String> { dataSource, tableView, indexPath, item in
            let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath)
            cell.textLabel?.text = item
            return cell
        }
        
        items
            .map { [SectionModel(model: "", items: $0)] }
            .bind(to: tableView.rx.items(dataSource: dataSource))
            .disposed(by: disposeBag)
    }
}

10. 实际应用场景

10.1 网络请求

struct API {
    static func fetchUser(id: Int) -> Observable<User> {
        let url = URL(string: "https://api.example.com/users/\(id)")!
        
        return URLSession.shared.rx.data(request: URLRequest(url: url))
            .map { data in
                try JSONDecoder().decode(User.self, from: data)
            }
            .observeOn(MainScheduler.instance)
    }
}

API.fetchUser(id: 1)
    .subscribe(
        onNext: { user in
            print("用户: \(user)")
        },
        onError: { error in
            print("错误: \(error)")
        }
    )
    .disposed(by: disposeBag)

10.2 用户输入处理

class SearchViewModel {
    private let disposeBag = DisposeBag()
    let searchText = BehaviorSubject<String>(value: "")
    let results = BehaviorSubject<[String]>(value: [])
    
    init() {
        searchText
            .debounce(.milliseconds(500), scheduler: MainScheduler.instance)
            .distinctUntilChanged()
            .filter { !$0.isEmpty }
            .flatMapLatest { query -> Observable<[String]> in
                return self.search(query: query)
                    .catchErrorJustReturn([])
            }
            .bind(to: results)
            .disposed(by: disposeBag)
    }
    
    private func search(query: String) -> Observable<[String]> {
        // 实现搜索逻辑
        return Observable.just(["结果1", "结果2"])
    }
}

10.3 组合多个数据源

class DashboardViewModel {
    private let disposeBag = DisposeBag()
    let user = BehaviorSubject<User?>(value: nil)
    let posts = BehaviorSubject<[Post]>(value: [])
    let isLoading = BehaviorSubject<Bool>(value: false)
    
    func loadData() {
        isLoading.onNext(true)
        
        let userObservable = API.fetchUser(id: 1)
        let postsObservable = API.fetchPosts()
        
        Observable.zip(userObservable, postsObservable)
            .observeOn(MainScheduler.instance)
            .subscribe(
                onNext: { [weak self] user, posts in
                    self?.user.onNext(user)
                    self?.posts.onNext(posts)
                    self?.isLoading.onNext(false)
                },
                onError: { [weak self] error in
                    self?.isLoading.onNext(false)
                    print("错误: \(error)")
                }
            )
            .disposed(by: disposeBag)
    }
}

10.4 表单验证(多字段实时校验)

多字段表单:用户名、密码、确认密码实时校验,用 combineLatest 聚合多流,用 map 产出错误文案或是否可提交。

class FormViewModel {
    private let disposeBag = DisposeBag()

    let username = BehaviorRelay<String>(value: "")
    let password = BehaviorRelay<String>(value: "")
    let confirmPassword = BehaviorRelay<String>(value: "")

    let usernameError = BehaviorRelay<String?>(value: nil)
    let isFormValid = BehaviorRelay<Bool>(value: false)

    init() {
        // 用户名:非空 + 长度
        username
            .map { name in
                if name.isEmpty { return "请输入用户名" }
                if name.count < 3 { return "至少 3 个字符" }
                return nil
            }
            .bind(to: usernameError)
            .disposed(by: disposeBag)

        // 三字段 combineLatest,任一变化都重新计算表单是否有效
        Observable.combineLatest(username, password, confirmPassword)
            .map { name, pwd, confirm in
                if name.isEmpty || pwd.isEmpty { return false }
                if pwd != confirm { return false }
                if pwd.count < 6 { return false }
                return true
            }
            .bind(to: isFormValid)
            .disposed(by: disposeBag)
    }
}

// VC 中绑定
viewModel.isFormValid
    .bind(to: submitButton.rx.isEnabled)
    .disposed(by: disposeBag)
viewModel.usernameError
    .bind(to: usernameErrorLabel.rx.text)
    .disposed(by: disposeBag)

10.5 NotificationCenter 转 Observable

系统通知或自定义通知转为 Observable,便于在链中 mapfilterobserveOn

// 键盘即将显示:取键盘 frame
let keyboardWillShow = NotificationCenter.default.rx
    .notification(UIResponder.keyboardWillShowNotification)
    .map { notification -> CGRect in
        (notification.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? NSValue)?.cgRectValue ?? .zero
    }
    .observeOn(MainScheduler.instance)

keyboardWillShow
    .subscribe(onNext: { frame in
        print("键盘高度: \(frame.height)")
    })
    .disposed(by: disposeBag)

// 自定义通知
extension Notification.Name {
    static let myCustomEvent = Notification.Name("MyCustomEvent")
}
let customObservable = NotificationCenter.default.rx.notification(.myCustomEvent)

10.6 Timer 与周期任务

Observable.interval 做定时轮询,或用 Observable.timer 做延迟/单次任务。

// 每 1 秒发一个递增整数,主线程接收
let timerObservable = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
    .take(10)  // 只取 10 次
    .subscribe(onNext: { tick in
        print("tick: \(tick)")
    })
    .disposed(by: disposeBag)

// 延迟 2 秒后执行一次
Observable<Int>.timer(.seconds(2), scheduler: MainScheduler.instance)
    .subscribe(onNext: { _ in
        print("2 秒后执行")
    })
    .disposed(by: disposeBag)

// 轮询接口:每 5 秒请求一次,直到满足条件
Observable<Int>.interval(.seconds(5), scheduler: MainScheduler.instance)
    .flatMapLatest { _ in API.pollStatus() }
    .takeWhile { !$0.isDone }
    .subscribe(onNext: { status in
        print("状态: \(status)")
    })
    .disposed(by: disposeBag)

10.7 请求重试与超时

retry 在失败时重新订阅上游;timeout 超时未完成则发 error;配合 catchError 做兜底。

URLSession.shared.rx.data(request: request)
    .timeout(.seconds(10), scheduler: MainScheduler.instance)
    .retry(3)
    .map { data in try JSONDecoder().decode(User.self, from: data) }
    .catchError { _ in Observable.just(User.placeholder) }
    .observeOn(MainScheduler.instance)
    .subscribe(
        onNext: { user in
            // 更新 UI
        },
        onError: { error in
            print("错误: \(error)")
        }
    )
    .disposed(by: disposeBag)

10.8 多源竞速(主备 / race)

主接口失败时切到备用接口,用 catchError 切流;或 merge + take(1) 实现「谁先完成用谁」。

// 主接口失败时用备用接口
func loadFromPrimaryOrFallback() -> Observable<Data> {
    let primary = URLSession.shared.rx.data(request: primaryRequest)
    let fallback = URLSession.shared.rx.data(request: fallbackRequest)
    return primary.catchError { _ in fallback }
}

// 显式 race:两个请求谁先完成用谁
func race<Element>(_ a: Observable<Element>, _ b: Observable<Element>) -> Observable<Element> {
    Observable.merge(a, b).take(1)
}

10.9 节流与防抖组合(搜索 + 按钮防重复点击)

搜索框用 debounce 减少请求频率;提交按钮用 throttle 防止连续点击重复提交。

// 搜索:防抖 + 去重 + 非空 + flatMapLatest 只保留最后一次请求
searchBar.rx.text.orEmpty
    .debounce(.milliseconds(400), scheduler: MainScheduler.instance)
    .distinctUntilChanged()
    .filter { !$0.isEmpty }
    .flatMapLatest { query in
        API.search(query: query).catchErrorJustReturn([])
    }
    .observeOn(MainScheduler.instance)
    .bind(to: results)
    .disposed(by: disposeBag)

// 提交按钮:节流 1 秒内只响应一次
submitButton.rx.tap
    .throttle(.seconds(1), scheduler: MainScheduler.instance)
    .subscribe(onNext: { [weak self] in
        self?.submit()
    })
    .disposed(by: disposeBag)

10.10 RxCocoa 进阶:UISearchBar、RefreshControl、DelegateProxy

UISearchBarrx.textrx.searchButtonClicked 组合做「点击搜索」或「实时搜索」。

// 点击搜索按钮时用当前文本请求
searchBar.rx.searchButtonClicked
    .withLatestFrom(searchBar.rx.text.orEmpty)
    .filter { !$0.isEmpty }
    .flatMapLatest { API.search(query: $0) }
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { [weak self] results in
        self?.updateResults(results)
    })
    .disposed(by: disposeBag)

UIRefreshControl:下拉刷新与 isRefreshing 绑定。

refreshControl.rx.controlEvent(.valueChanged)
    .flatMapLatest { [weak self] _ in
        self?.loadData() ?? Observable.never()
    }
    .observeOn(MainScheduler.instance)
    .subscribe(
        onNext: { [weak self] _ in
            self?.refreshControl.endRefreshing()
        },
        onError: { [weak self] _ in
            self?.refreshControl.endRefreshing()
        }
    )
    .disposed(by: disposeBag)

DelegateProxy 示例(UITableView 点击):RxCocoa 已为常用控件提供 rx 扩展,如需自定义可继承 DelegateProxy

// 使用 RxCocoa 内置的 itemSelected
tableView.rx.itemSelected
    .subscribe(onNext: { indexPath in
        print("选中: \(indexPath)")
    })
    .disposed(by: disposeBag)

tableView.rx.modelSelected(Item.self)
    .subscribe(onNext: { item in
        print("选中项: \(item)")
    })
    .disposed(by: disposeBag)

10.11 页面生命周期与 takeUntil

在 VC 中让订阅随页面消失而自动取消:用 rx.deallocatingtakeUntil(self.rx.deallocated),避免重复订阅和泄漏。

class ViewController: UIViewController {
    private let disposeBag = DisposeBag()

    override func viewDidLoad() {
        super.viewDidLoad()

        // 方式一:统一丢进 disposeBag,VC 释放时一起 dispose
        someObservable
            .subscribe(onNext: { })
            .disposed(by: disposeBag)

        // 方式二:显式「直到某事件发生就结束」(如直到页面即将消失)
        someObservable
            .takeUntil(rx.deallocated)
            .subscribe(onNext: { })
            .disposed(by: disposeBag)
    }
}

10.12 CollectionView 与 RxDataSources

使用 RxDataSources 的 Section 模型驱动 UICollectionView,与 TableView 用法类似(Item 为业务模型类型,需与 Cell 一致)。

import RxDataSources

typealias Section = SectionModel<String, Item>  // Item 为业务模型
let dataSource = RxCollectionViewSectionedReloadDataSource<Section> { dataSource, collectionView, indexPath, item in
    let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) as! ItemCell
    cell.configure(with: item)
    return cell
}

items
    .map { [Section(model: "列表", items: $0)] }
    .bind(to: collectionView.rx.items(dataSource: dataSource))
    .disposed(by: disposeBag)

10.13 双向绑定与 ControlProperty

RxCocoa 的 ControlProperty 支持双向绑定:一方是「用户输入」,一方是「模型/ViewModel」。

// 将 TextField 与 BehaviorRelay 双向绑定(需自己写绑定逻辑,或使用 RxCocoa 的 bind)
// 单向:ViewModel -> UI
viewModel.username
    .bind(to: textField.rx.text)
    .disposed(by: disposeBag)

// 单向:UI -> ViewModel
textField.rx.text.orEmpty
    .bind(to: viewModel.username)
    .disposed(by: disposeBag)

// 若需「初始值 + 用户修改都同步」,两行都写即可(Relay 与控件类型匹配时)

10.14 错误流与用户提示

将网络/业务错误统一转为「可展示的提示」,用 materialize()catchError 转成另一种元素类型,再在 UI 层订阅。

API.fetchUser(id: 1)
    .materialize()
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { [weak self] event in
        switch event {
        case .next(let user):
            self?.showUser(user)
        case .error(let error):
            self?.showToast("加载失败: \(error.localizedDescription)")
        case .completed:
            break
        }
    })
    .disposed(by: disposeBag)

二、RxSwift框架源码解析

1. 架构设计

1.1 整体架构

RxSwift 采用协议导向的设计,核心是三个协议:

ObservableType (可观察类型)
    ↓
ObserverType (观察者类型)
    ↓
Disposable (可释放资源)

数据流:

Observable → Observer
     ↑          ↓
     └── 反馈 ──┘

1.2 核心协议层次

// 第一层:ObservableType 协议
protocol ObservableType {
    associatedtype Element
    func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element
}

// 第二层:ObserverType 协议
protocol ObserverType {
    associatedtype Element
    func on(_ event: Event<Element>)
}

// 第三层:Disposable 协议
protocol Disposable {
    func dispose()
}

1.3 事件类型

enum Event<Element> {
    case next(Element)
    case error(Swift.Error)
    case completed
}

2. Observable协议实现

2.1 ObservableType协议定义

public protocol ObservableType {
    associatedtype Element
    
    func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element
}

2.2 Observable实现

public class Observable<Element>: ObservableType {
    public typealias Element = Element
    
    internal init() {}
    
    public func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element {
        rxAbstractMethod()
    }
    
    public func asObservable() -> Observable<Element> {
        return self
    }
}

关键点:

  • Observable 是抽象类
  • subscribe 方法需要子类实现
  • 使用 rxAbstractMethod() 防止直接实例化

2.3 Just实现分析

final private class Just<Element>: Producer<Element> {
    private let element: Element
    
    init(element: Element) {
        self.element = element
    }
    
    override func run<Observer: ObserverType>(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable)
        where Observer.Element == Element {
        let sink = JustSink(parent: self, observer: observer, cancel: cancel)
        let subscription = sink.run()
        return (sink: sink, subscription: subscription)
    }
}

final private class JustSink<Observer: ObserverType>: Sink<Observer>, ObserverType {
    typealias Element = Observer.Element
    typealias Parent = Just<Element>
    
    private let parent: Parent
    
    init(parent: Parent, observer: Observer, cancel: Cancelable) {
        self.parent = parent
        super.init(observer: observer, cancel: cancel)
    }
    
    func on(_ event: Event<Element>) {
        switch event {
        case .next:
            forwardOn(.next(parent.element))
            forwardOn(.completed)
            self.dispose()
        case .error, .completed:
            forwardOn(event)
            self.dispose()
        }
    }
    
    func run() -> Disposable {
        forwardOn(.next(parent.element))
        forwardOn(.completed)
        return Disposables.create()
    }
}

关键点:

  • Just 继承自 Producer
  • 使用 JustSink 处理订阅逻辑
  • 立即发出元素并完成

2.4 Create实现分析

final private class AnonymousObservable<Element>: Producer<Element> {
    typealias SubscribeHandler = (AnyObserver<Element>) -> Disposable
    
    private let subscribeHandler: SubscribeHandler
    
    init(_ subscribeHandler: @escaping SubscribeHandler) {
        self.subscribeHandler = subscribeHandler
    }
    
    override func run<Observer: ObserverType>(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable)
        where Observer.Element == Element {
        let sink = AnonymousObservableSink(observer: observer, cancel: cancel)
        let subscription = sink.run(self)
        return (sink: sink, subscription: subscription)
    }
}

final private class AnonymousObservableSink<Observer: ObserverType>: Sink<Observer>, ObserverType {
    typealias Element = Observer.Element
    typealias Parent = AnonymousObservable<Element>
    
    private let parent: Parent
    
    init(observer: Observer, cancel: Cancelable) {
        self.parent = AnonymousObservable(subscribeHandler: { observer in
            // 包装观察者
            return Disposables.create()
        })
        super.init(observer: observer, cancel: cancel)
    }
    
    func on(_ event: Event<Element>) {
        switch event {
        case .next:
            forwardOn(event)
        case .error, .completed:
            forwardOn(event)
            self.dispose()
        }
    }
    
    func run(_ parent: Parent) -> Disposable {
        return parent.subscribeHandler(AnyObserver(self))
    }
}

关键点:

  • AnonymousObservable 使用闭包创建
  • AnyObserver 包装观察者
  • 支持自定义订阅逻辑

3. Observer协议实现

3.1 ObserverType协议定义

public protocol ObserverType {
    associatedtype Element
    
    func on(_ event: Event<Element>)
}

3.2 AnyObserver实现

public struct AnyObserver<Element>: ObserverType {
    public typealias Element = Element
    
    private let observer: AnyObserverBase<Element>
    
    public init<Observer: ObserverType>(_ observer: Observer)
        where Observer.Element == Element {
        self.observer = ObserverBox(observer)
    }
    
    public func on(_ event: Event<Element>) {
        observer.on(event)
    }
}

private class AnyObserverBase<Element>: ObserverType {
    func on(_ event: Event<Element>) {
        rxAbstractMethod()
    }
}

private final class ObserverBox<Observer: ObserverType>: AnyObserverBase<Observer.Element> {
    private let observer: Observer
    
    init(_ observer: Observer) {
        self.observer = observer
    }
    
    override func on(_ event: Event<Observer.Element>) {
        observer.on(event)
    }
}

关键点:

  • AnyObserver 是类型擦除包装器
  • 使用 ObserverBox 存储具体观察者
  • 实现观察者的多态

3.3 Sink实现

class Sink<Observer: ObserverType>: Disposable {
    typealias Element = Observer.Element
    
    private let observer: Observer
    private let cancel: Cancelable
    private var disposed = false
    
    init(observer: Observer, cancel: Cancelable) {
        self.observer = observer
        self.cancel = cancel
    }
    
    final func forwardOn(_ event: Event<Element>) {
        if isDisposed {
            return
        }
        observer.on(event)
    }
    
    final func forwardOn(_ event: Event<Element>, _ disposeHandler: @escaping () -> Void) {
        if isDisposed {
            return
        }
        observer.on(event)
        disposeHandler()
    }
    
    func dispose() {
        if !disposed {
            disposed = true
            cancel.dispose()
        }
    }
    
    var isDisposed: Bool {
        return disposed
    }
}

关键点:

  • Sink 是观察者的基类
  • 提供 forwardOn 方法转发事件
  • 管理订阅的生命周期

4. Operators实现原理

4.1 Map操作符实现

extension ObservableType {
    public func map<Result>(_ transform: @escaping (Element) -> Result) -> Observable<Result> {
        return Map(source: self.asObservable(), transform: transform)
    }
}

final private class Map<SourceType, ResultType>: Producer<ResultType> {
    typealias Transform = (SourceType) -> ResultType
    
    private let source: Observable<SourceType>
    private let transform: Transform
    
    init(source: Observable<SourceType>, transform: @escaping Transform) {
        self.source = source
        self.transform = transform
    }
    
    override func run<Observer: ObserverType>(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable)
        where Observer.Element == ResultType {
        let sink = MapSink(transform: transform, observer: observer, cancel: cancel)
        let subscription = source.subscribe(sink)
        return (sink: sink, subscription: subscription)
    }
}

final private class MapSink<SourceType, Observer: ObserverType>: Sink<Observer>, ObserverType {
    typealias ResultType = Observer.Element
    typealias Transform = (SourceType) -> ResultType
    
    private let transform: Transform
    
    init(transform: @escaping Transform, observer: Observer, cancel: Cancelable) {
        self.transform = transform
        super.init(observer: observer, cancel: cancel)
    }
    
    func on(_ event: Event<SourceType>) {
        switch event {
        case .next(let element):
            do {
                let mappedElement = try transform(element)
                forwardOn(.next(mappedElement))
            } catch {
                forwardOn(.error(error))
                dispose()
            }
        case .error(let error):
            forwardOn(.error(error))
            dispose()
        case .completed:
            forwardOn(.completed)
            dispose()
        }
    }
}

关键点:

  • Map 是新的 Observable,包装源 Observable
  • 创建 MapSink 进行转换
  • 错误处理:转换失败时发出错误

4.2 Filter操作符实现

extension ObservableType {
    public func filter(_ predicate: @escaping (Element) -> Bool) -> Observable<Element> {
        return Filter(source: self.asObservable(), predicate: predicate)
    }
}

final private class Filter<Element>: Producer<Element> {
    typealias Predicate = (Element) -> Bool
    
    private let source: Observable<Element>
    private let predicate: Predicate
    
    init(source: Observable<Element>, predicate: @escaping Predicate) {
        self.source = source
        self.predicate = predicate
    }
    
    override func run<Observer: ObserverType>(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable)
        where Observer.Element == Element {
        let sink = FilterSink(predicate: predicate, observer: observer, cancel: cancel)
        let subscription = source.subscribe(sink)
        return (sink: sink, subscription: subscription)
    }
}

final private class FilterSink<Observer: ObserverType>: Sink<Observer>, ObserverType {
    typealias Element = Observer.Element
    typealias Predicate = (Element) -> Bool
    
    private let predicate: Predicate
    
    init(predicate: @escaping Predicate, observer: Observer, cancel: Cancelable) {
        self.predicate = predicate
        super.init(observer: observer, cancel: cancel)
    }
    
    func on(_ event: Event<Element>) {
        switch event {
        case .next(let element):
            do {
                let satisfies = try predicate(element)
                if satisfies {
                    forwardOn(.next(element))
                }
            } catch {
                forwardOn(.error(error))
                dispose()
            }
        case .error, .completed:
            forwardOn(event)
            dispose()
        }
    }
}

关键点:

  • 不满足条件时不转发事件
  • 满足条件时才传递给下游

4.3 FlatMap操作符实现

extension ObservableType {
    public func flatMap<Source: ObservableConvertibleType>(
        _ selector: @escaping (Element) -> Source
    ) -> Observable<Source.Element> {
        return FlatMap(source: self.asObservable(), selector: selector)
    }
}

final private class FlatMap<SourceElement, SourceSequence: ObservableConvertibleType>: Producer<SourceSequence.Element> {
    typealias Selector = (SourceElement) -> SourceSequence
    
    private let source: Observable<SourceElement>
    private let selector: Selector
    
    init(source: Observable<SourceElement>, selector: @escaping Selector) {
        self.source = source
        self.selector = selector
    }
    
    override func run<Observer: ObserverType>(_ observer: Observer, cancel: Cancelable) -> (sink: Disposable, subscription: Disposable)
        where Observer.Element == SourceSequence.Element {
        let sink = FlatMapSink(selector: selector, observer: observer, cancel: cancel)
        let subscription = sink.run(source)
        return (sink: sink, subscription: subscription)
    }
}

final private class FlatMapSink<SourceElement, SourceSequence: ObservableConvertibleType, Observer: ObserverType>: MergeSink<SourceSequence, Observer>
    where Observer.Element == SourceSequence.Element {
    
    typealias Selector = (SourceElement) -> SourceSequence
    
    private let selector: Selector
    
    init(selector: @escaping Selector, observer: Observer, cancel: Cancelable) {
        self.selector = selector
        super.init(observer: observer, cancel: cancel)
    }
    
    override func on(_ event: Event<SourceElement>) {
        switch event {
        case .next(let element):
            do {
                let innerObservable = try selector(element).asObservable()
                subscribeInner(innerObservable, group: group)
            } catch {
                forwardOn(.error(error))
                dispose()
            }
        case .error(let error):
            forwardOn(.error(error))
            dispose()
        case .completed:
            groupCompleted()
        }
    }
}

关键点:

  • 管理多个内部 Observable 订阅
  • 使用 MergeSink 合并结果
  • 需要复杂的生命周期管理

5. Subjects实现原理

5.1 PublishSubject实现

public final class PublishSubject<Element>: Observable<Element>, SubjectType, Cancelable, ObserverType, SynchronizedUnsubscribeType {
    public typealias SubjectObserverType = PublishSubject<Element>
    
    typealias Observers = AnyObserver<Element>.s
    typealias DisposeKey = Observers.KeyType
    
    private let lock = RecursiveLock()
    private var observers: Observers = Observers()
    private var isDisposed = false
    private var stopped = false
    private var stoppedEvent: Event<Element>?
    
    public override init() {
        super.init()
    }
    
    public func on(_ event: Event<Element>) {
        dispatch(synchronized_on(event), event)
    }
    
    func synchronized_on(_ event: Event<Element>) -> Observers {
        lock.lock()
        defer { lock.unlock() }
        
        switch event {
        case .next:
            if isDisposed || stopped {
                return Observers()
            }
            return observers
        case .completed, .error:
            if stoppedEvent == nil {
                stoppedEvent = event
                stopped = true
                let observers = self.observers
                self.observers.removeAll()
                return observers
            }
            return Observers()
        }
    }
    
    public override func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element {
        lock.lock()
        defer { lock.unlock() }
        
        if let stoppedEvent = stoppedEvent {
            observer.on(stoppedEvent)
            return Disposables.create()
        }
        
        if isDisposed {
            observer.on(.error(RxError.disposed))
            return Disposables.create()
        }
        
        let key = observers.insert(observer.on)
        return SubscriptionDisposable(owner: self, key: key)
    }
    
    func synchronizedUnsubscribe(_ disposeKey: DisposeKey) {
        lock.lock()
        defer { lock.unlock() }
        observers.removeKey(disposeKey)
    }
}

关键点:

  • 使用锁保护 observers 集合
  • 不保存当前值,新订阅者不会收到历史值
  • 使用 SubscriptionDisposable 管理订阅

5.2 BehaviorSubject实现

public final class BehaviorSubject<Element>: Observable<Element>, SubjectType, ObserverType, SynchronizedUnsubscribeType {
    public typealias SubjectObserverType = BehaviorSubject<Element>
    
    typealias Observers = AnyObserver<Element>.s
    typealias DisposeKey = Observers.KeyType
    
    private let lock = RecursiveLock()
    private var observers: Observers = Observers()
    private var isDisposed = false
    private var stoppedEvent: Event<Element>?
    private var element: Element
    
    public init(value: Element) {
        self.element = value
        super.init()
    }
    
    public var value: Element {
        lock.lock()
        defer { lock.unlock() }
        return element
    }
    
    public func on(_ event: Event<Element>) {
        dispatch(synchronized_on(event), event)
    }
    
    func synchronized_on(_ event: Event<Element>) -> Observers {
        lock.lock()
        defer { lock.unlock() }
        
        if stoppedEvent != nil || isDisposed {
            return Observers()
        }
        
        switch event {
        case .next(let element):
            self.element = element
        case .error, .completed:
            stoppedEvent = event
        }
        
        return observers
    }
    
    public override func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable
        where Observer.Element == Element {
        lock.lock()
        defer { lock.unlock() }
        
        if let stoppedEvent = stoppedEvent {
            observer.on(stoppedEvent)
            return Disposables.create()
        }
        
        if isDisposed {
            observer.on(.error(RxError.disposed))
            return Disposables.create()
        }
        
        let key = observers.insert(observer.on)
        observer.on(.next(element))  // 立即发送当前值
        
        return SubscriptionDisposable(owner: self, key: key)
    }
}

关键点:

  • 保存当前值 element
  • 新订阅者立即收到当前值
  • 使用锁保护状态

6. Schedulers实现原理

6.1 SchedulerType协议

public protocol SchedulerType {
    var now: RxTime { get }
    
    func schedule<StateType>(_ state: StateType, action: @escaping (StateType) -> Disposable) -> Disposable
    
    func scheduleRelative<StateType>(_ state: StateType, dueTime: RxTimeInterval, action: @escaping (StateType) -> Disposable) -> Disposable
    
    func schedulePeriodic<StateType>(_ state: StateType, startAfter: RxTimeInterval, period: RxTimeInterval, action: @escaping (StateType) -> StateType) -> Disposable
}

6.2 MainScheduler实现

public final class MainScheduler: SerialDispatchQueueScheduler {
    private let mainQueue: DispatchQueue
    
    public static let instance = MainScheduler()
    
    public static let asyncInstance = SerialDispatchQueueScheduler(
        serialQueue: DispatchQueue.main
    )
    
    private init() {
        mainQueue = DispatchQueue.main
        super.init(serialQueue: mainQueue)
    }
    
    public static func ensureExecutingOnScheduler(errorMessage: String? = nil) {
        if !DispatchQueue.isMain {
            rxFatalError(errorMessage ?? "Executing on background thread. Please use `MainScheduler.instance.schedule` to schedule work on main thread.")
        }
    }
}

关键点:

  • 使用 DispatchQueue.main
  • 提供单例实例
  • 提供线程检查方法

6.3 SerialDispatchQueueScheduler实现

public class SerialDispatchQueueScheduler: SchedulerType {
    public typealias TimeInterval = Foundation.TimeInterval
    public typealias Time = Date
    
    private let configuration: DispatchQueueConfiguration
    private let serialQueue: DispatchQueue
    
    public var now: RxTime {
        return Date()
    }
    
    public init(serialQueue: DispatchQueue, leeway: DispatchTimeInterval = DispatchTimeInterval.nanoseconds(0)) {
        self.serialQueue = serialQueue
        self.configuration = DispatchQueueConfiguration(
            queue: serialQueue,
            leeway: leeway
        )
    }
    
    public final func schedule<StateType>(_ state: StateType, action: @escaping (StateType) -> Disposable) -> Disposable {
        return self.scheduleInternal(state, action: action)
    }
    
    func scheduleInternal<StateType>(_ state: StateType, action: @escaping (StateType) -> Disposable) -> Disposable {
        let cancel = SingleAssignmentDisposable()
        
        serialQueue.async {
            if cancel.isDisposed {
                return
            }
            cancel.setDisposable(action(state))
        }
        
        return cancel
    }
    
    public final func scheduleRelative<StateType>(_ state: StateType, dueTime: RxTimeInterval, action: @escaping (StateType) -> Disposable) -> Disposable {
        return scheduleRelativeInternal(state, dueTime: dueTime, action: action)
    }
    
    func scheduleRelativeInternal<StateType>(_ state: StateType, dueTime: RxTimeInterval, action: @escaping (StateType) -> Disposable) -> Disposable {
        let deadline = now.addingTimeInterval(dueTime)
        
        let cancel = SingleAssignmentDisposable()
        
        serialQueue.asyncAfter(deadline: deadline) {
            if cancel.isDisposed {
                return
            }
            cancel.setDisposable(action(state))
        }
        
        return cancel
    }
}

关键点:

  • 使用 DispatchQueue 执行任务
  • 支持立即和延迟调度
  • 使用 SingleAssignmentDisposable 管理取消

7. 背压处理机制

7.1 背压问题

当生产者产生数据的速度快于消费者处理数据的速度时,会产生背压问题。

7.2 背压处理策略

RxSwift 主要通过以下方式处理背压:

  1. 请求机制:Observer 可以控制请求的数据量
  2. 缓冲:使用 buffer 操作符缓冲数据
  3. 节流:使用 throttledebounce 控制数据流速度
  4. 采样:使用 sample 采样数据

7.3 背压处理示例

class BackpressureObserver: ObserverType {
    typealias Element = Int
    
    private var buffer: [Int] = []
    private let bufferSize: Int
    private var subscription: Subscription?
    
    init(bufferSize: Int = 10) {
        self.bufferSize = bufferSize
    }
    
    func on(_ event: Event<Int>) {
        switch event {
        case .next(let element):
            buffer.append(element)
            
            // 处理缓冲区
            processBuffer()
            
            // 如果缓冲区未满,可以继续接收
            if buffer.count < bufferSize {
                // 继续接收
            }
        case .error, .completed:
            // 处理完成
            processRemaining()
        }
    }
    
    private func processBuffer() {
        while !buffer.isEmpty {
            let value = buffer.removeFirst()
            print("处理: \(value)")
        }
    }
    
    private func processRemaining() {
        processBuffer()
    }
}

8. 性能优化策略

8.1 值类型优化

RxSwift 大量使用值类型(struct),避免堆分配:

// 值类型,零成本抽象
struct Just<Element>: ObservableType { }
struct Map<SourceType, ResultType>: ObservableType { }
struct Filter<Element>: ObservableType { }

8.2 类型擦除

使用 asObservable() 隐藏具体类型:

extension ObservableType {
    public func asObservable() -> Observable<Element> {
        return Observable.create { observer in
            return self.subscribe(observer)
        }
    }
}

8.3 延迟执行

使用 deferred 延迟创建 Observable:

let deferred = Observable.deferred {
    // 只在订阅时执行
    return expensiveOperation()
}

8.4 共享订阅

使用 share() 共享 Observable:

let shared = expensiveObservable()
    .share()  // 多个订阅者共享同一个 Observable

shared.subscribe(onNext: { })  // 订阅1
shared.subscribe(onNext: { })  // 订阅2(共享执行)

8.5 内存优化

  • 使用 DisposeBag 自动管理订阅
  • 使用 weak self 避免循环引用
  • 及时取消不需要的订阅

📚 总结

RxSwift 框架的核心优势

  1. 跨平台标准:基于 ReactiveX 标准,与其他平台一致
  2. 丰富的操作符:提供大量操作符处理各种场景
  3. 类型安全:充分利用 Swift 类型系统
  4. 性能优化:值类型、零成本抽象
  5. 生态丰富:RxCocoa、RxDataSources 等扩展

学习建议

  1. 从基础开始:理解 Observable、Observer、Disposable
  2. 实践操作符:熟悉常用操作符的使用
  3. 理解调度器:掌握 subscribeOnobserveOn
  4. 阅读源码:深入理解实现原理
  5. 实际应用:在项目中应用 RxSwift

RxSwift vs Combine

  • RxSwift:适合需要支持 iOS 8+ 的项目,API 更丰富
  • Combine:适合 iOS 13+ 项目,与系统深度集成

文档版本:v1.0
最后更新:2026年1月15日
参考文献:RxSwift GitHub Repository, ReactiveX Documentation

03-研究优秀开源框架@响应式编程@iOS | ReactiveCocoa框架:从使用到源码解析

📋 目录


一、ReactiveCocoa框架使用详解

1. ReactiveCocoa框架概述

ReactiveCocoa(简称 RAC)是一个基于 ReactiveSwift 的响应式编程框架,用于处理异步事件流和状态管理。它是 GitHub 开源的项目,提供了声明式的 API 来处理时间序列数据。

1.1 什么是ReactiveCocoa

ReactiveCocoa 是一个函数式响应式编程(FRP)框架,允许你通过组合不同的操作符来处理异步事件序列。它提供了声明式的 API 来处理时间序列数据。

核心特点:

  • 函数式响应式编程:基于函数式编程和响应式编程的结合
  • 类型安全:充分利用 Swift 的类型系统
  • 状态管理:提供 Property 和 MutableProperty 管理状态
  • Action模式:提供 Action 处理用户交互
  • UIKit集成:深度集成 UIKit 控件

1.2 ReactiveCocoa vs RxSwift vs Combine

特性 ReactiveCocoa RxSwift Combine
平台 iOS、macOS 跨平台 Apple 生态(iOS 13+)
语言 Swift Swift Swift
官方支持 ❌ GitHub 开源 ❌ 第三方 ✅ Apple 官方
核心类型 Signal、SignalProducer Observable Publisher
状态管理 Property、MutableProperty BehaviorSubject @Published
Action模式 ✅ Action
学习曲线 陡峭 陡峭 中等
生态 ReactiveSwift、ReactiveObjC RxCocoa SwiftUI

1.3 ReactiveCocoa生态系统

  • ReactiveSwift:核心框架,提供 Signal、SignalProducer 等
  • ReactiveCocoa:UIKit/AppKit 集成,提供控件绑定
  • ReactiveObjC:Objective-C 版本

1.4 安装方式

CocoaPods:

pod 'ReactiveSwift', '~> 7.0'
pod 'ReactiveCocoa', '~> 12.0'

SPM:

dependencies: [
    .package(url: "https://github.com/ReactiveCocoa/ReactiveSwift.git", from: "7.0.0"),
    .package(url: "https://github.com/ReactiveCocoa/ReactiveCocoa.git", from: "12.0.0")
]

1.5 编程思想(背后的范式与理念)

ReactiveCocoa 明确标榜函数式响应式编程(FRP),将函数式与响应式结合;理解其背后的编程思想,能更好地区分 Signal / SignalProducer、Property、Action 的适用场景。

(1)函数式响应式编程(FRP)

  • 核心:在「响应式」的事件流之上,用函数式的方式组合与变换——把「随时间发生的事件」视为可映射、可过滤、可合并的值,通过纯函数组合成新流,而不是在观察者闭包里写满副作用。
  • 在 RAC 中Signal / SignalProducer 表示事件流,mapfilterflatMap 等操作符对流做纯变换,observestart 才真正消费并产生副作用;流与副作用边界清晰。
  • 与「仅响应式」的对比:FRP 强调「流即数据」,用转换与组合表达业务逻辑,观察者只做「最后一步」的响应,便于测试和复用。

(2)声明式 vs 命令式

维度 命令式(Imperative) 声明式(Declarative)
关注点 「怎么做」:显式顺序与分支 「做什么」:描述数据/事件如何变换与约束
典型写法 回调嵌套、状态变量、if-else 链式操作符:map / filter / combineLatest
在 RAC 中 手写「请求 → 回调里判断 → 再请求」 signal.map(...).flatMap(...).observeValues(...) 描述整条流水线

声明式让「事件从哪来、如何变换、到哪去」一目了然,便于阅读和单元测试。

(3)函数式思想(组合与不可变)

  • 组合(Composition):每个操作符只做一件事,通过 .map().filter().flatMap(.latest) 等组合成完整逻辑;小能力组合成大能力,避免巨型闭包。
  • 不可变(Immutability):操作符不修改原 Signal/SignalProducer,而是返回新的;原流不变,便于复用和推理。
  • 副作用边界:纯变换放在操作符链中,副作用(UI 更新、写库、弹窗)集中在 observeValues / startWithValuesAction 的 execution 中,便于测试和并发安全。

(4)流与时间(Streams & Time)

  • 把所有「会随时间产生的事件」都视为时间序列:value、value、…、completed/failed/interrupted。
  • RAC 区分热信号(Signal)冷信号(SignalProducer):热信号有订阅即开始发送、多订阅者共享同一时间线;冷信号每次 start 才执行、每次订阅独立。时间相关操作符如 debouncethrottle 表达「何时」而不只是「何值」。

(5)观察者与「推」「拉」

  • 观察者模式:Observer 通过 observe 订阅 Signal,或通过 start 启动 SignalProducer,在事件发生时被通知。
  • 推模型:Signal 是「推」——事件由发送端推动,观察者被动接收;SignalProducer 是「按需拉」——只有 start 时才创建并执行,适合表示「一次异步操作」或「延迟计算」。

(6)Action 与「意图-执行」分离

  • 思想:用户操作(点击、下拉)是意图,网络请求、校验、弹窗是执行;将「意图」与「执行」分离,便于禁用、重试、统一错误处理。
  • 在 RAC 中Action 接收输入(如按钮 tap 或输入值),内部用 SignalProducer 描述一次执行,输出与错误统一由 Action 暴露;UI 只绑定「能否执行」与「执行结果」,不写一堆 isLoadingerror 状态。

小结:ReactiveCocoa 用声明式事件流(Signal/SignalProducer)和可组合操作符,在函数式响应式的范式下做异步与事件处理;用 Property 管理可变状态、用 Action 封装「意图-执行」,并用 Scheduler 控制线程。掌握这些思想后,再区分「用 Signal 还是 SignalProducer」「何时用 Property、何时用 Action」会更自然。


2. 核心概念

2.1 Signal(信号)

Signal 是 ReactiveCocoa 的核心类型,表示一个可以观察的事件流。

protocol SignalProtocol {
    associatedtype Value
    associatedtype Error: Swift.Error
    
    func observe(_ observer: Observer<Value, Error>) -> Disposable?
}

特点:

  • 可以发出零个或多个值
  • 可能以完成或错误结束
  • 是引用类型(class)
  • 热信号(Hot Signal):有订阅者时立即开始发送事件

事件类型:

enum Event<Value, Error: Swift.Error> {
    case value(Value)      // 值事件
    case failed(Error)    // 错误事件
    case completed        // 完成事件
    case interrupted      // 中断事件
}

示例:

let (signal, observer) = Signal<String, Never>.pipe()

signal.observeValues { value in
    print("收到值: \(value)")
}

observer.send(value: "Hello")
observer.send(value: "World")
observer.sendCompleted()

2.2 SignalProducer(信号生产者)

SignalProducer 是延迟创建 Signal 的类型,类似于 RxSwift 的 Observable。

struct SignalProducer<Value, Error: Swift.Error> {
    private let startHandler: (Observer<Value, Error>, Lifetime) -> Void
    
    func start(_ observer: Observer<Value, Error>) -> Disposable
}

特点:

  • 冷信号(Cold Signal):只有在被订阅时才开始发送事件
  • 每次订阅都会创建新的 Signal
  • 适合表示异步操作

示例:

let producer = SignalProducer<String, Never> { observer, lifetime in
    observer.send(value: "Hello")
    observer.send(value: "World")
    observer.sendCompleted()
}

producer.startWithValues { value in
    print("收到值: \(value)")
}

2.3 Observer(观察者)

Observer 是接收 Signal 事件的类型。

final class Observer<Value, Error: Swift.Error> {
    func send(value: Value)
    func send(error: Error)
    func sendCompleted()
    func sendInterrupted()
}

示例:

let (signal, observer) = Signal<Int, Never>.pipe()

signal.observe { event in
    switch event {
    case .value(let value):
        print("值: \(value)")
    case .completed:
        print("完成")
    case .failed(let error):
        print("错误: \(error)")
    case .interrupted:
        print("中断")
    }
}

observer.send(value: 1)
observer.send(value: 2)
observer.sendCompleted()

2.4 Disposable(可释放资源)

Disposable 表示订阅关系,用于取消订阅和释放资源。

protocol Disposable {
    func dispose()
}

CompositeDisposable:

let disposable = CompositeDisposable()

disposable += signal.observeValues { value in
    print(value)
}

disposable += anotherSignal.observeValues { value in
    print(value)
}

// 释放所有订阅
disposable.dispose()

3. Signal与SignalProducer

3.1 Signal创建方式

pipe

创建 Signal 和 Observer。

let (signal, observer) = Signal<String, Never>.pipe()

signal.observeValues { print($0) }
observer.send(value: "Hello")
never

创建永不发出事件的 Signal。

let signal = Signal<Int, Never>.never()
signal.observeValues { print($0) }  // 永远不会执行
empty

创建立即完成的 Signal。

let signal = Signal<Int, Never>.empty()
signal.observeCompleted { print("完成") }
failed

创建立即失败的 Signal。

enum MyError: Error {
    case failure
}

let signal = Signal<Int, MyError>.failed(.failure)
signal.observeFailed { print("错误: \($0)") }

3.2 SignalProducer创建方式

init

使用闭包创建 SignalProducer。

let producer = SignalProducer<String, Never> { observer, lifetime in
    observer.send(value: "A")
    observer.send(value: "B")
    observer.sendCompleted()
}

producer.startWithValues { print($0) }
value

创建发出单个值的 SignalProducer。

let producer = SignalProducer<String, Never>(value: "Hello")
producer.startWithValues { print($0) }
values

从序列创建 SignalProducer。

let producer = SignalProducer<String, Never>(values: ["A", "B", "C"])
producer.startWithValues { print($0) }
error

创建立即失败的 SignalProducer。

let producer = SignalProducer<Int, MyError>(error: .failure)
producer.startWithFailed { print("错误: \($0)") }
empty

创建立即完成的 SignalProducer。

let producer = SignalProducer<Int, Never>.empty
producer.startWithCompleted { print("完成") }
never

创建永不发出事件的 SignalProducer。

let producer = SignalProducer<Int, Never>.never
producer.startWithValues { print($0) }  // 永远不会执行

3.3 Signal vs SignalProducer

Signal(热信号):

  • 立即开始发送事件
  • 多个观察者共享同一个事件流
  • 适合表示已经发生的事件

SignalProducer(冷信号):

  • 延迟创建,只有在订阅时才开始
  • 每个观察者获得独立的事件流
  • 适合表示异步操作

转换:

// SignalProducer -> Signal
let producer = SignalProducer<String, Never>(value: "Hello")
let signal = producer.promoteToSignal()

// Signal -> SignalProducer
let (signal, observer) = Signal<String, Never>.pipe()
let producer = SignalProducer(signal)

4. Property与MutableProperty

4.1 Property

Property 是不可变的状态容器,表示一个随时间变化的值。

protocol PropertyProtocol {
    associatedtype Value
    
    var value: Value { get }
    var signal: Signal<Value, Never> { get }
    var producer: SignalProducer<Value, Never> { get }
}

特点:

  • 只读属性
  • 提供当前值
  • 提供 Signal 和 SignalProducer 观察变化

示例:

let property = Property(value: "初始值")

// 获取当前值
print(property.value)  // 输出: 初始值

// 观察变化
property.signal.observeValues { value in
    print("值变化: \(value)")
}

4.2 MutableProperty

MutableProperty 是可变的状态容器。

final class MutableProperty<Value>: MutablePropertyProtocol {
    var value: Value { get set }
    var signal: Signal<Value, Never> { get }
    var producer: SignalProducer<Value, Never> { get }
    
    init(_ value: Value)
}

特点:

  • 可读写属性
  • 修改值时会发出事件
  • 新观察者会立即收到当前值

示例:

let property = MutableProperty("初始值")

// 观察变化
property.signal.observeValues { value in
    print("值变化: \(value)")
}
// 立即输出: 值变化: 初始值

// 修改值
property.value = "新值"  // 输出: 值变化: 新值
property.value = "另一个值"  // 输出: 值变化: 另一个值

4.3 Property绑定

双向绑定:

let property1 = MutableProperty("")
let property2 = MutableProperty("")

// 双向绑定
property1 <~ property2
property2 <~ property1

property1.value = "Hello"  // property2.value 也变为 "Hello"
property2.value = "World"  // property1.value 也变为 "World"

单向绑定:

let source = MutableProperty("源")
let target = MutableProperty("目标")

// 单向绑定:source -> target
target <~ source

source.value = "新值"  // target.value 也变为 "新值"
target.value = "修改"  // source.value 不变

5. Action

Action 是 ReactiveCocoa 特有的类型,用于处理用户交互和异步操作。

5.1 Action基本使用

let action = Action<String, String, Never> { input in
    return SignalProducer { observer, lifetime in
        // 执行异步操作
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            observer.send(value: "结果: \(input)")
            observer.sendCompleted()
        }
    }
}

// 执行 Action
action.apply("输入").startWithValues { result in
    print(result)  // 输出: 结果: 输入
}

5.2 Action状态

Action 提供多个状态 Signal:

let action = Action<String, String, Never> { input in
    return SignalProducer(value: "结果: \(input)")
}

// 观察执行状态
action.isExecuting.signal.observeValues { isExecuting in
    print("执行中: \(isExecuting)")
}

// 观察值
action.values.observeValues { value in
    print("值: \(value)")
}

// 观察错误
action.errors.observeValues { error in
    print("错误: \(error)")
}

// 执行
action.apply("输入").start()

5.3 Action与UIButton绑定

let action = Action<Void, String, Never> {
    return SignalProducer(value: "按钮点击")
}

// 绑定到按钮
button.reactive.pressed = CocoaAction(action) { _ in }

// 观察结果
action.values.observeValues { result in
    print(result)
}

6. Operators操作符

6.1 转换操作符

map

转换每个值。

SignalProducer(values: [1, 2, 3])
    .map { $0 * 2 }
    .startWithValues { print($0) }
// 输出: 2, 4, 6
flatMap

将 Signal 发出的值转换为 SignalProducer,然后合并。

SignalProducer(values: ["A", "B", "C"])
    .flatMap(.latest) { letter in
        SignalProducer(values: [1, 2]).map { "\(letter)\($0)" }
    }
    .startWithValues { print($0) }
// 输出: A1, A2, B1, B2, C1, C2
scan

累积值。

SignalProducer(values: [1, 2, 3, 4, 5])
    .scan(0, +)
    .startWithValues { print($0) }
// 输出: 1, 3, 6, 10, 15

6.2 过滤操作符

filter

过滤值。

SignalProducer(values: [1, 2, 3, 4, 5])
    .filter { $0 % 2 == 0 }
    .startWithValues { print($0) }
// 输出: 2, 4
skip

跳过前几个值。

SignalProducer(values: [1, 2, 3, 4, 5])
    .skip(first: 2)
    .startWithValues { print($0) }
// 输出: 3, 4, 5
take

获取前几个值。

SignalProducer(values: [1, 2, 3, 4, 5])
    .take(first: 3)
    .startWithValues { print($0) }
// 输出: 1, 2, 3
distinctUntilChanged

移除连续重复的值。

SignalProducer(values: [1, 1, 2, 2, 3, 3])
    .distinctUntilChanged()
    .startWithValues { print($0) }
// 输出: 1, 2, 3

6.3 组合操作符

combineLatest

组合多个 Signal 的最新值。

let (signal1, observer1) = Signal<String, Never>.pipe()
let (signal2, observer2) = Signal<Int, Never>.pipe()

signal1.combineLatest(with: signal2)
    .observeValues { value1, value2 in
        print("\(value1): \(value2)")
    }

observer1.send(value: "A")  // 无输出(等待 signal2)
observer2.send(value: 1)    // 输出: A: 1
observer1.send(value: "B")  // 输出: B: 1
observer2.send(value: 2)    // 输出: B: 2
merge

合并多个 Signal。

let (signal1, observer1) = Signal<Int, Never>.pipe()
let (signal2, observer2) = Signal<Int, Never>.pipe()

signal1.merge(with: signal2)
    .observeValues { print($0) }

observer1.send(value: 1)  // 输出: 1
observer2.send(value: 2)  // 输出: 2
observer1.send(value: 3)  // 输出: 3
zip

按顺序组合多个 Signal。

let (signal1, observer1) = Signal<String, Never>.pipe()
let (signal2, observer2) = Signal<Int, Never>.pipe()

signal1.zip(with: signal2)
    .observeValues { value1, value2 in
        print("\(value1): \(value2)")
    }

observer1.send(value: "A")  // 等待 signal2
observer1.send(value: "B")  // 等待 signal2
observer2.send(value: 1)    // 输出: A: 1
observer2.send(value: 2)    // 输出: B: 2

6.4 时间操作符

debounce

防抖,等待指定时间后发出最新值。

let (signal, observer) = Signal<String, Never>.pipe()

signal.debounce(0.5, on: QueueScheduler.main)
    .observeValues { print($0) }

observer.send(value: "H")     // 不输出
observer.send(value: "He")    // 不输出
observer.send(value: "Hel")   // 不输出
observer.send(value: "Hell")  // 不输出
observer.send(value: "Hello") // 0.5秒后输出: Hello
throttle

节流,在指定时间间隔内只发出第一个值。

let (signal, observer) = Signal<String, Never>.pipe()

signal.throttle(1.0, on: QueueScheduler.main)
    .observeValues { print($0) }

observer.send(value: "A")  // 立即输出: A
observer.send(value: "B")  // 不输出(1秒内)
observer.send(value: "C")  // 不输出(1秒内)
// 1秒后
observer.send(value: "D")  // 输出: D
delay

延迟发出值。

SignalProducer(values: [1, 2, 3])
    .delay(1.0, on: QueueScheduler.main)
    .startWithValues { print($0) }
// 1秒后依次输出: 1, 2, 3

7. Schedulers调度器

7.1 内置Scheduler

QueueScheduler

队列调度器。

// 主队列
let mainScheduler = QueueScheduler.main

// 后台队列
let backgroundScheduler = QueueScheduler(
    qos: .background,
    name: "background.queue"
)

SignalProducer(value: 1)
    .start(on: backgroundScheduler)
    .observe(on: mainScheduler)
    .startWithValues { value in
        print(Thread.isMainThread)  // true
    }
UIScheduler

UI 调度器(主线程)。

let uiScheduler = UIScheduler()

SignalProducer(value: 1)
    .observe(on: uiScheduler)
    .startWithValues { value in
        print(Thread.isMainThread)  // true
    }

7.2 start vs observe

  • start:指定 SignalProducer 在哪个调度器上开始执行
  • observe:指定观察者在哪个调度器上接收事件
SignalProducer { observer, lifetime in
    print("执行线程: \(Thread.current)")
    observer.send(value: 1)
    observer.sendCompleted())
}
.start(on: QueueScheduler(qos: .background))
.observe(on: UIScheduler())
.startWithValues { value in
    print("接收线程: \(Thread.current)")
}

8. 错误处理

8.1 错误类型

enum NetworkError: Error {
    case invalidURL
    case noData
    case decodingError
}

8.2 错误处理操作符

catch

捕获错误并返回备用 SignalProducer。

SignalProducer<String, NetworkError>(error: .noData)
    .catch { error -> SignalProducer<String, Never> in
        print("捕获错误: \(error)")
        return SignalProducer(value: "备用值")
    }
    .startWithValues { print($0) }
retry

重试失败的 SignalProducer。

var attempts = 0

SignalProducer<String, NetworkError> { observer, lifetime in
    attempts += 1
    if attempts < 3 {
        observer.send(error: .noData)
    } else {
        observer.send(value: "成功")
        observer.sendCompleted()
    }
}
.retry(upTo: 2)  // 最多重试 2 次
.start(
    value: { print($0) },
    failed: { print("错误: \($0)") }
)
flatMapError

将错误转换为值。

SignalProducer<String, NetworkError>(error: .noData)
    .flatMapError { error in
        SignalProducer(value: "错误: \(error)")
    }
    .startWithValues { print($0) }

9. 内存管理

9.1 Lifetime

Lifetime 用于管理 SignalProducer 的生命周期。

let producer = SignalProducer<String, Never> { observer, lifetime in
    let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
        observer.send(value: "Tick")
    }
    
    lifetime.observeEnded {
        timer.invalidate()
    }
}

let disposable = producer.startWithValues { print($0) }

// 取消订阅时,timer 会自动失效
disposable.dispose()

9.2 避免循环引用

class ViewModel {
    private let property = MutableProperty("")
    
    func setup() {
        property.signal.observeValues { [weak self] value in
            self?.process(value)
        }
    }
    
    private func process(_ value: String) {
        // 处理数据
    }
}

10. 与UIKit集成

10.1 Reactive扩展

ReactiveCocoa 为 UIKit 控件提供了 Reactive 扩展。

import ReactiveSwift
import ReactiveCocoa

class ViewController: UIViewController {
    @IBOutlet weak var textField: UITextField!
    @IBOutlet weak var button: UIButton!
    @IBOutlet weak var label: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 文本输入绑定
        label.reactive.text <~ textField.reactive.continuousTextValues
        
        // 按钮点击
        button.reactive.pressed = CocoaAction(Action { [weak self] _ in
            return SignalProducer(value: "按钮点击")
        })
    }
}

10.2 常用绑定

// UILabel
label.reactive.text <~ property.producer.map { $0 }

// UITextField
textField.reactive.text <~ property.producer.map { $0 }
property <~ textField.reactive.continuousTextValues

// UIButton
button.reactive.pressed = CocoaAction(action)

// UISwitch
switch.reactive.isOn <~ property.producer.map { $0 }
property <~ switch.reactive.isOnValues

// UISlider
slider.reactive.value <~ property.producer.map { Float($0) }
property <~ slider.reactive.values.map { Int($0) }

11. 实际应用场景

11.1 网络请求

struct API {
    static func fetchUser(id: Int) -> SignalProducer<User, NetworkError> {
        let url = URL(string: "https://api.example.com/users/\(id)")!
        
        return URLSession.shared.reactive.data(with: URLRequest(url: url))
            .attemptMap { data, _ in
                try JSONDecoder().decode(User.self, from: data)
            }
            .observe(on: UIScheduler())
    }
}

API.fetchUser(id: 1)
    .start(
        value: { user in
            print("用户: \(user)")
        },
        failed: { error in
            print("错误: \(error)")
        }
    )

11.2 用户输入处理

class SearchViewModel {
    let searchText = MutableProperty("")
    let results = MutableProperty<[String]>([])
    
    init() {
        results <~ searchText.producer
            .debounce(0.5, on: QueueScheduler.main)
            .skipRepeats()
            .filter { !$0.isEmpty }
            .flatMap(.latest) { query -> SignalProducer<[String], Never> in
                return self.search(query: query)
                    .flatMapError { _ in SignalProducer(value: []) }
            }
    }
    
    private func search(query: String) -> SignalProducer<[String], NetworkError> {
        // 实现搜索逻辑
        return SignalProducer(value: ["结果1", "结果2"])
    }
}

二、ReactiveCocoa框架源码解析

1. 架构设计

1.1 整体架构

ReactiveCocoa 采用协议导向的设计,核心是 Signal 和 SignalProducer。

Signal (热信号)
    ↓
Observer
    ↓
Event (value/failed/completed/interrupted)

SignalProducer (冷信号)
    ↓
Observer
    ↓
Signal

1.2 核心协议层次

// Signal 协议
protocol SignalProtocol {
    associatedtype Value
    associatedtype Error: Swift.Error
    
    func observe(_ observer: Observer<Value, Error>) -> Disposable?
}

// SignalProducer 协议
protocol SignalProducerProtocol {
    associatedtype Value
    associatedtype Error: Swift.Error
    
    func start(_ observer: Observer<Value, Error>) -> Disposable
}

2. Signal实现原理

2.1 Signal类实现

public final class Signal<Value, Error: Swift.Error>: SignalProtocol {
    private let generator: (Observer<Value, Error>) -> Disposable?
    private var observers: Bag<Observer<Value, Error>> = Bag()
    private let lock = NSRecursiveLock()
    
    public init(_ generator: @escaping (Observer<Value, Error>) -> Disposable?) {
        self.generator = generator
    }
    
    public func observe(_ observer: Observer<Value, Error>) -> Disposable? {
        lock.lock()
        defer { lock.unlock() }
        
        let token = observers.insert(observer)
        
        // 如果是第一个观察者,开始生成事件
        if observers.count == 1 {
            let disposable = generator(Observer { [weak self] event in
                self?.send(event)
            })
            
            return CompositeDisposable(
                disposable,
                Disposable { [weak self] in
                    self?.lock.lock()
                    self?.observers.remove(using: token)
                    self?.lock.unlock()
                }
            )
        }
        
        return Disposable { [weak self] in
            self?.lock.lock()
            self?.observers.remove(using: token)
            self?.lock.unlock()
        }
    }
    
    private func send(_ event: Event<Value, Error>) {
        lock.lock()
        let currentObservers = observers
        lock.unlock()
        
        for observer in currentObservers {
            observer.send(event)
        }
        
        // 如果是终止事件,清理观察者
        if event.isTerminating {
            lock.lock()
            observers.removeAll()
            lock.unlock()
        }
    }
}

关键点:

  • Signal 是引用类型(class)
  • 使用 Bag 存储多个观察者
  • 使用锁保护共享状态
  • 第一个观察者订阅时开始生成事件

2.2 pipe实现

extension Signal {
    public static func pipe() -> (Signal<Value, Error>, Observer<Value, Error>) {
        let observer = Observer<Value, Error>()
        let signal = Signal<Value, Error> { observer in
            // 将外部 observer 的事件转发给内部 observer
            return observer.observe { event in
                observer.send(event)
            }
        }
        
        return (signal, observer)
    }
}

关键点:

  • pipe 创建 Signal 和 Observer 对
  • Observer 可以手动发送事件
  • 适合将命令式代码转换为响应式代码

3. SignalProducer实现原理

3.1 SignalProducer结构

public struct SignalProducer<Value, Error: Swift.Error>: SignalProducerProtocol {
    private let startHandler: (Observer<Value, Error>, Lifetime) -> Void
    
    public init(_ startHandler: @escaping (Observer<Value, Error>, Lifetime) -> Void) {
        self.startHandler = startHandler
    }
    
    public func start(_ observer: Observer<Value, Error>) -> Disposable {
        let lifetime = Lifetime()
        let compositeDisposable = CompositeDisposable()
        
        lifetime.observeEnded {
            compositeDisposable.dispose()
        }
        
        startHandler(observer, lifetime)
        
        return compositeDisposable
    }
}

关键点:

  • SignalProducer 是值类型(struct)
  • 每次 start 都会创建新的 Signal
  • 使用 Lifetime 管理资源生命周期

3.2 SignalProducer转换

extension SignalProducer {
    public var signal: Signal<Value, Error> {
        return Signal { observer in
            return self.start(observer)
        }
    }
}

extension Signal {
    public var producer: SignalProducer<Value, Error> {
        return SignalProducer { observer, lifetime in
            let disposable = self.observe(observer)
            lifetime.observeEnded {
                disposable?.dispose()
            }
        }
    }
}

关键点:

  • SignalProducer 可以转换为 Signal
  • Signal 可以转换为 SignalProducer
  • 转换是延迟的,不会立即执行

4. Property实现原理

4.1 Property协议

public protocol PropertyProtocol {
    associatedtype Value
    
    var value: Value { get }
    var signal: Signal<Value, Never> { get }
    var producer: SignalProducer<Value, Never> { get }
}

4.2 MutableProperty实现

public final class MutableProperty<Value>: MutablePropertyProtocol {
    private let lock = NSRecursiveLock()
    private var _value: Value
    private let observer: Observer<Value, Never>
    private let signal: Signal<Value, Never>
    
    public var value: Value {
        get {
            lock.lock()
            defer { lock.unlock() }
            return _value
        }
        set {
            lock.lock()
            let oldValue = _value
            _value = newValue
            lock.unlock()
            
            if oldValue != newValue {
                observer.send(value: newValue)
            }
        }
    }
    
    public init(_ value: Value) {
        _value = value
        let (signal, observer) = Signal<Value, Never>.pipe()
        self.signal = signal
        self.observer = observer
        
        // 立即发送初始值
        observer.send(value: value)
    }
    
    public var producer: SignalProducer<Value, Never> {
        return SignalProducer { observer, lifetime in
            // 立即发送当前值
            observer.send(value: self.value)
            
            // 观察后续变化
            let disposable = self.signal.observe(observer)
            lifetime.observeEnded {
                disposable?.dispose()
            }
        }
    }
}

关键点:

  • MutableProperty 是引用类型
  • 使用锁保护 _value
  • 值变化时发出事件
  • producer 会立即发送当前值

4.3 绑定操作符实现

infix operator <~ : BindingPrecedence

public func <~ <Source: SignalProducerProtocol, Destination: BindingTargetProtocol>(
    destination: Destination,
    source: Source
) -> Disposable
where Source.Value == Destination.Value, Source.Error == Never {
    return source.startWithValues { value in
        destination.consume(value)
    }
}

public func <~ <Source: SignalProtocol, Destination: BindingTargetProtocol>(
    destination: Destination,
    source: Source
) -> Disposable?
where Source.Value == Destination.Value, Source.Error == Never {
    return source.observeValues { value in
        destination.consume(value)
    }
}

关键点:

  • <~ 操作符实现单向绑定
  • 自动管理订阅生命周期
  • 支持 Signal 和 SignalProducer

5. Action实现原理

5.1 Action结构

public final class Action<Input, Output, Error: Swift.Error> {
    private let executeClosure: (Input) -> SignalProducer<Output, Error>
    private let isEnabledProperty: MutableProperty<Bool>
    private let eventsObserver: Observer<Event<Output, Error>, Never>
    
    public let isEnabled: Property<Bool>
    public let isExecuting: Property<Bool>
    public let values: Signal<Output, Never>
    public let errors: Signal<Error, Never>
    public let events: Signal<Event<Output, Error>, Never>
    
    public init(enabledIf: Property<Bool> = Property(value: true),
                execute: @escaping (Input) -> SignalProducer<Output, Error>) {
        self.executeClosure = execute
        self.isEnabledProperty = MutableProperty(true)
        self.isEnabled = Property(capturing: isEnabledProperty)
        
        let (eventsSignal, eventsObserver) = Signal<Event<Output, Error>, Never>.pipe()
        self.events = eventsSignal
        self.eventsObserver = eventsObserver
        
        self.values = events.map { $0.value }.skipNil()
        self.errors = events.map { $0.error }.skipNil()
        
        let isExecutingProperty = MutableProperty(false)
        self.isExecuting = Property(capturing: isExecutingProperty)
        
        // 监听执行状态
        events.observeValues { event in
            switch event {
            case .value:
                isExecutingProperty.value = true
            case .completed, .failed, .interrupted:
                isExecutingProperty.value = false
            }
        }
    }
    
    public func apply(_ input: Input) -> SignalProducer<Output, Error> {
        return SignalProducer { observer, lifetime in
            guard self.isEnabled.value else {
                observer.sendInterrupted()
                return
            }
            
            let producer = self.executeClosure(input)
            let disposable = producer.start { event in
                self.eventsObserver.send(value: event)
                observer.send(event)
            }
            
            lifetime.observeEnded {
                disposable.dispose()
            }
        }
    }
}

关键点:

  • Action 封装异步操作
  • 提供执行状态(isEnabled、isExecuting)
  • 提供值、错误、事件流
  • 可以禁用 Action

6. Operators实现原理

6.1 map实现

extension SignalProducer {
    public func map<U>(_ transform: @escaping (Value) -> U) -> SignalProducer<U, Error> {
        return SignalProducer { observer, lifetime in
            self.start { event in
                switch event {
                case .value(let value):
                    observer.send(value: transform(value))
                case .failed(let error):
                    observer.send(error: error)
                case .completed:
                    observer.sendCompleted()
                case .interrupted:
                    observer.sendInterrupted()
                }
            }
        }
    }
}

关键点:

  • map 创建新的 SignalProducer
  • 转换每个值事件
  • 保持其他事件不变

6.2 filter实现

extension SignalProducer {
    public func filter(_ predicate: @escaping (Value) -> Bool) -> SignalProducer<Value, Error> {
        return SignalProducer { observer, lifetime in
            self.start { event in
                switch event {
                case .value(let value):
                    if predicate(value) {
                        observer.send(value: value)
                    }
                case .failed(let error):
                    observer.send(error: error)
                case .completed:
                    observer.sendCompleted()
                case .interrupted:
                    observer.sendInterrupted()
                }
            }
        }
    }
}

关键点:

  • filter 创建新的 SignalProducer
  • 只转发满足条件的值
  • 保持其他事件不变

6.3 flatMap实现

extension SignalProducer {
    public func flatMap<U>(_ strategy: FlattenStrategy, _ transform: @escaping (Value) -> SignalProducer<U, Error>) -> SignalProducer<U, Error> {
        return SignalProducer { observer, lifetime in
            let flattenProducer = self.map(transform).flatten(strategy)
            let disposable = flattenProducer.start(observer)
            lifetime.observeEnded {
                disposable.dispose()
            }
        }
    }
}

关键点:

  • flatMap 支持多种策略(.latest、.merge、.concat)
  • 管理多个内部 SignalProducer
  • 需要复杂的生命周期管理

7. Schedulers实现原理

7.1 Scheduler协议

public protocol Scheduler {
    func schedule(_ action: @escaping () -> Void) -> Disposable?
    func schedule(after date: Date, action: @escaping () -> Void) -> Disposable?
    func schedule(after date: Date, interval: TimeInterval, action: @escaping () -> Void) -> Disposable?
}

7.2 QueueScheduler实现

public final class QueueScheduler: Scheduler {
    public let queue: DispatchQueue
    
    public init(qos: DispatchQoS = .default, name: String = "org.reactivecocoa.ReactiveSwift.QueueScheduler") {
        self.queue = DispatchQueue(label: name, qos: qos)
    }
    
    public static let main = QueueScheduler(queue: .main, name: "org.reactivecocoa.ReactiveSwift.QueueScheduler.main")
    
    public func schedule(_ action: @escaping () -> Void) -> Disposable? {
        let disposable = SimpleDisposable()
        queue.async {
            if !disposable.isDisposed {
                action()
            }
        }
        return disposable
    }
    
    public func schedule(after date: Date, action: @escaping () -> Void) -> Disposable? {
        let disposable = SimpleDisposable()
        let timeInterval = date.timeIntervalSinceNow
        queue.asyncAfter(deadline: .now() + timeInterval) {
            if !disposable.isDisposed {
                action()
            }
        }
        return disposable
    }
}

关键点:

  • QueueScheduler 使用 DispatchQueue
  • 支持立即和延迟调度
  • 支持取消调度

8. 生命周期管理

8.1 Lifetime实现

public final class Lifetime {
    private let token: Token
    private var observers: Bag<() -> Void> = Bag()
    private let lock = NSRecursiveLock()
    
    public init() {
        token = Token()
    }
    
    public func observeEnded(_ action: @escaping () -> Void) {
        lock.lock()
        let isEnded = token.isEnded
        if !isEnded {
            observers.insert(action)
        }
        lock.unlock()
        
        if isEnded {
            action()
        }
    }
    
    deinit {
        token.markEnded()
        lock.lock()
        let currentObservers = observers
        observers.removeAll()
        lock.unlock()
        
        for observer in currentObservers {
            observer()
        }
    }
}

关键点:

  • Lifetime 管理资源生命周期
  • 对象释放时自动执行清理操作
  • 使用 observeEnded 注册清理回调

8.2 Disposable管理

public final class CompositeDisposable: Disposable {
    private var disposables: [Disposable] = []
    private let lock = NSRecursiveLock()
    private var isDisposed = false
    
    public init(_ disposables: Disposable...) {
        self.disposables = disposables
    }
    
    public func add(_ disposable: Disposable?) {
        guard let disposable = disposable else { return }
        
        lock.lock()
        if isDisposed {
            lock.unlock()
            disposable.dispose()
            return
        }
        
        disposables.append(disposable)
        lock.unlock()
    }
    
    public func dispose() {
        lock.lock()
        guard !isDisposed else {
            lock.unlock()
            return
        }
        
        isDisposed = true
        let currentDisposables = disposables
        disposables.removeAll()
        lock.unlock()
        
        for disposable in currentDisposables {
            disposable.dispose()
        }
    }
}

关键点:

  • CompositeDisposable 管理多个 Disposable
  • 线程安全
  • 一次性释放所有资源

9. 性能优化策略

9.1 值类型优化

SignalProducer 是值类型,避免堆分配:

// 值类型,零成本抽象
struct SignalProducer<Value, Error: Swift.Error> { }

9.2 延迟执行

SignalProducer 延迟创建 Signal:

let producer = SignalProducer<String, Never> { observer, lifetime in
    // 只在 start 时执行
    observer.send(value: "Hello")
}

9.3 共享执行

使用 share() 共享 SignalProducer:

let shared = expensiveProducer().share()

shared.startWithValues { }  // 订阅1
shared.startWithValues { }  // 订阅2(共享执行)

9.4 内存优化

  • 使用 weak 引用避免循环引用
  • 使用 Lifetime 自动管理资源
  • 及时释放不需要的订阅

📚 总结

ReactiveCocoa 的核心优势

  1. Property 状态管理:提供 Property 和 MutableProperty 管理状态
  2. Action 模式:提供 Action 处理用户交互和异步操作
  3. 类型安全:充分利用 Swift 类型系统
  4. 生命周期管理:使用 Lifetime 自动管理资源
  5. UIKit 集成:深度集成 UIKit 控件

学习建议

  1. 理解 Signal vs SignalProducer:掌握热信号和冷信号的区别
  2. 理解 Property:掌握状态管理
  3. 理解 Action:掌握用户交互处理
  4. 阅读源码:深入理解实现原理
  5. 实际应用:在项目中应用 ReactiveCocoa

文档版本:v1.0
最后更新:2026年1月15日
参考文献:ReactiveCocoa GitHub Repository, ReactiveSwift Source Code

❌