Objective-C 的余晖 on 错误的，

Objective-C 的余晖

Sat, 24 Jan 2026 00:00:00 +0000

Book Description

An in-depth look at the language that powered the Apple revolution. From the NeXT Cube to the iPhone App Store, these are the stories and the syntax of a golden era.

第一章：那只薛定谔的猫 —— OC的诞生

Sat, 24 Jan 2026 00:00:00 +0000

1.1 C语言的狂野与Smalltalk的优雅

故事开始于1980年代初。那是一个计算机还在穿纸尿裤的年代。

当时，C语言 就像是那个拿着电锯的德州杀人狂——强大、高效、但也极其危险。它能让你直接操作内存，能让你写出极快的代码，但也能让你因为一个野指针而让整个系统崩溃。

而在另一个平行宇宙里，施乐（Xerox）帕罗奥多研究中心（PARC）的一群天才们搞出了 Smalltalk。Smalltalk 就像是一个优雅的芭蕾舞者，它不仅是一门语言，更是一个完整的环境。在它的世界里，一切皆对象，一切皆消息。它不用你操心内存，不用你关心底层，你只需要对着对象喊：“嘿，跳个舞！”，它就会跳个舞。

这时候，有两个叫 Brad Cox 和 Tom Love 的哥们出现了。他们看着C语言，又看着Smalltalk，心里产生了一个大胆（甚至有点变态）的想法：

“如果我们把Smalltalk的消息机制，嫁接到C语言的身上，会生出一个什么怪胎……啊不，天才？”

于是，Objective-C 就在这种“杂交”实验中诞生了。它不是一门全新的语言，它严格来说是 C 语言的一个超集。也就是说，任何合法的 C 语言代码，都是合法的 Objective-C 代码。

这就像是：你本来只会骑自行车（C语言），突然有人给你的自行车装了一个甚至能飞的火箭助推器（Smalltalk的运行时），但你依然可以像骑自行车一样踩脚踏板。

1.2 NeXT：被流放国王的复仇之剑

如果OC只是Brad Cox的一个实验品，它可能早就淹没在历史的垃圾堆里了。让它真正加冕为王的，是一个被自己创立的公司踢出门的男人——Steve Jobs。

Jobs 被赶出苹果后，创立了 NeXT。他想造一台完美的电脑，这台电脑不仅要有完美的硬件，还要有完美的软件。他需要一个强大的操作系统，和一套能让开发者快速开发出漂亮GUI程序的开发工具。

他看上了 Objective-C。

在那个年代，写GUI程序简直是刑罚。你得处理几千行的C代码来画一个窗口。但是用OC，配合NeXT开发的 Interface Builder（是的，它那时候就叫这个），你可以像搭积木一样拖拽按钮、窗口，然后用简单的 [window makeKeyAndOrderFront:self] 这种像英语一样的代码来控制它。

NeXTSTEP 操作系统诞生了。它优雅、先进、完全面向对象。它是乔布斯的复仇之剑。

1.3 如果你觉得现在的Xcode难用……

回想一下当初的开发环境。那时候没有自动补全，没有ARC，没有StackOverflow。开发者们靠着名为 Project Builder（Xcode的前身）和 Interface Builder 的双剑合璧，在NeXTSTEP上创造了一个又一个奇迹。

比如 WorldWideWeb —— 世界上第一个Web浏览器，就是蒂姆·伯纳斯-李（Tim Berners-Lee）在NeXT电脑上用Objective-C写出来的。是的，没有OC，就没有现在的互联网。（好的，这有点夸张，但它确实加速了 Web 的诞生。）

1.4 总结

OC 的出生，带着一种“实用主义的缝合怪”气质。它不像 C++ 那样试图重新发明轮子（然后造出了一个正十二面体轮子），它极其简单粗暴：

保留 C 的一切（指针、结构体、宏）。
引入 Smalltalk 的面向对象运行时。
用一对方括号 [] 把它们强行把它们箍在一起。

这种“简单的暴力美学”，贯穿了 OC 的一生。

第二章：黄金时代 —— 当方括号统治世界

Sat, 24 Jan 2026 00:00:00 +0000

2.1 逆袭：NeXT 吞并 Apple

1996年，Apple 即使快要倒闭了。他们的操作系统 Mac OS 9 就像一座摇摇欲坠的危楼，那是还是以 Pascal 风格为基础的 Toolbox 年代。他们试图开发下一代操作系统 Copland，但失败得一塌糊涂。

走投无路的 Apple 看向了外界。他们有两个选择：BeOS 和 NeXTSTEP。最终，他们选择了 NeXT。乔布斯带着他的 Objective-C 军火库，回到了库比蒂诺。虽说是 Apple 收购了 NeXT，但正如乔布斯后来所做的那样，怎么看都像是 NeXT 的文化吞噬了旧 Apple。

2.2 Cocoa 与 Carbon 的战争

回到 Apple 后，乔布斯面临一个巨大的问题：怎么让现有的开发者迁移到这个满是方括号的新世界？当时的 Mac开发者习惯了 C++ 和 Pascal 风格的 API。让他们去学这门看起来像天书一样的 Objective-C？没门。

于是 Apple 搞出了两条路：

Carbon：旧世界的桥梁。你几乎不用改太多代码就能让你的老程序跑在 Mac OS X 上。
Cocoa：新世界的船票。纯正的 NeXTSTEP 血统，纯正的 Objective-C。

这场战争持续了几年，但胜负早已注定。Cocoa 的开发效率是 Carbon 无法比拟的。那些坚持用 Carbon 的开发者发现，隔壁用 Cocoa 的家伙，一边喝着咖啡，一边用几行代码就实现了一个带有漂亮动画的抽屉效果窗口，而自己还在和事件循环（Event Loop）搏斗。

最终，Objective-C 赢了。方括号插满了 Mac OS X 的每一个角落。

2.3 2008：寒武纪大爆发

如果说 Mac 只是让 OC 站稳了脚跟，那么 iPhone 则让 OC 统治了世界。

2007年，初代 iPhone 发布。那时只有 Web App。黑客们通过越狱证明了这台设备能运行原生代码。 2008年，Jobs 终于妥协（或者说是顺水推舟），发布了 iPhone SDK。

这一刻，Objective-C 的命运齿轮开始疯狂转动。全世界的开发者蜂拥而至。不管你之前是写 Java 的、写 C# 的、还是写 PHP 的，要想在那个闪闪发光的 App Store 里淘金，你就必须学会 Objective-C。

你必须学会什么叫 [alloc init]。
你必须学会为什么字符串前面要加个 @。
你必须学会对着屏幕骂：“这该死的 EXC_BAD_ACCESS 是什么鬼？！”

成千上万的 App 像雨后春笋一样冒出来。愤怒的小鸟、水果忍者、Instagram…… Objective-C 成了当时世界上薪水最高的语言之一。也就是在这个时候，无数中国开发者通过名为《Objective-C 2.0 程序设计》（那是红皮书吗？还是黄皮书？）的武林秘籍，踏入了 iOS 开发的大门。

那是一个疯狂的、充满梦想的、满屏幕都是方括号的黄金时代。

第三章：战壕里的故事 —— 你的 App 为什么又崩了？

Sat, 24 Jan 2026 00:00:00 +0000

3.1 手动挡的乐趣（与恐惧）

现在的孩子们（指 Swift 开发者）可能无法想象，在 ARC（Automatic Reference Counting）出现之前，我们是怎么活下来的。

那时候，我们是手动的引用计数（MRC, Manual Reference Counting）的奴隶。每一个对象生下来（alloc），你都要负责对它说“我要你”（retain）。当你用完了，你必须记得说“我不要你了”（release）。

如果你忘了说 retain，对象就会在你转身的一瞬间消失，然后你的程序就会在一个莫名其妙的地方崩溃，报错信息只有冷冰冰的一行：EXC_BAD_ACCESS。这通常意味着你访问了一个还是温热的尸体（Zombie Object）。

如果你忘了说 release，恭喜你，你的 App 会像吃自助餐一样吞噬内存，直到被操作系统无情地杀掉。

那时候的 iOS 面试题，有一半都是关于内存管理的：

“请问 retainCount 是几？”（正确答案是：别问，问就是不准。）
“autorelease 什么时候释放？”
“为什么我在循环里创建临时对象会导致内存飙升？”

我们不仅是程序员，我们还是拆弹专家。

3.2 经典的崩溃：Unrecognized Selector

如果你写过 OC，你一定见过这个报错： -[__NSCFString count]: unrecognized selector sent to instance 0x...

这通常发生在你把一个 NSArray 当成了 NSString 用，或者反过来。因为 OC 是动态类型的，你把一个猫指给编译器看，说“这是狗”，编译器会说“好的，它是狗”。但是当你试图命令这只“狗”去“汪汪叫”的时候，这只猫就会给你一巴掌（抛出异常）。

这种极其宽松的类型检查，既是噩梦，也是乐子。它意味着你可以把任何东西传给任何方法。这也催生了一个著名的防崩溃库模式：即使你向我发送了我听不懂的消息，我也假装听懂了，或者把消息转发给那个真正懂的人。

3.3 那些年我们写的宏

为了少写点代码，OC 程序员个个都是宏定义（#define）大师。

#define WEAK_SELF __weak typeof(self) weakSelf = self;
#define STRONG_SELF __strong typeof(weakSelf) strongSelf = weakSelf;
#define RGB(r, g, b) [UIColor colorWithRed:r/255.0 green:g/255.0 blue:b/255.0 alpha:1]

每一个项目里都有一个 Prefix.pch，里面塞满了各种奇技淫巧。有的宏甚至能把 OC 伪装成 JS 或者是 C#。

3.4 总结

那是一个充满了危险的年代。代码里到处是地雷。但当我们成功地在一台 256MB 内存的 iPhone 3GS 上跑起一个复杂的 3D 游戏，且没有内存泄漏时，那种成就感是无与伦比的。我们是走钢丝的人。

第四章：遗产 —— 它留下了什么？

Sat, 24 Jan 2026 00:00:00 +0000

4.1 好的遗产：命名即文档

OC 最被人诟病的地方，也是它最伟大的地方，就是它的冗长。

在 C 语言里，你可能会看到 strcpm 这种 cryptic 的函数名。但在 OC 里，你會看到： stringByReplacingOccurrencesOfString:withString:options:range:

“太长了！”新手惊呼。 “太清晰了！”老手感叹。

Objective-C 这种如同写文章一样的命名风格（Verbose），直接影响了 Cocoa 框架的设计哲学，也深深地刻在了 Swift 的基因里（虽然 Swift 稍微剪短了一点，但 Argument Label 的精髓依然保留了）。它教会了我们：代码是写给人看的，偶尔顺便给机器运行一下。

4.2 坏的遗产：头文件地狱

OC 继承了 C 的 .h 和 .m 分离的传统。这意味着你改了一个方法的签名，你得在两个地方修改。这意味着编译器在编译你的项目时，需要把成千上万个头文件复制粘贴几十万次。这也是为什么 OC 的编译速度（尤其是以前）那么慢的原因之一。

Swift 终于消灭了头文件，这是 OC 送给我们的最后一份礼物：作为一个反面教材，告诉我们 Module 是多么重要。

4.3 永远的方括号

虽然我们正在逐渐告别 OC，但当你偶然打开一个底层的 C++ 库，或者深入 Runtime 的源码时，你依然会感受到那种力量。 Objective-C 证明了：动态运行时（Runtime）不仅是可行的，而且是强大的。

它让我们明白，并在移动设备如此受限的资源下，依然可以拥有 Smalltalk 般灵动的架构。这一章结束了历史的回顾。下一部分，我们将深入代码，去解剖那对方括号背后的秘密。

第五章：方括号的艺术 —— 不是调用，是发消息

Sat, 24 Jan 2026 00:00:00 +0000

5.1 从 `object.method()` 到 `[object method]`

如果你来自 Java、C#、或者 Swift，你习惯了“点语法”。 dog.bark() —— 意思是：命令狗叫。这也是大多数现代语言的逻辑：函数调用（Function Call）。你拿到一个对象的地址，直接跳转到它内存里的那个函数代码块去执行。

但在 Objective-C 里，事情变得哲学了起来。 [dog bark] —— 意思是：向狗发送一个“bark”的消息。

区别在哪？

函数调用：是很生硬的。编译器必须知道 dog 有没有 bark 方法。如果没有，编译报错。
发消息：是很礼貌的。我只是把“bark”这张纸条递给 dog。至于 dog 看了纸条是高兴地叫两声，还是把纸条撕了（忽略），或者是转交给旁边的猫（消息转发），那完全取决于 dog 心情（Runtime 决议）。

这就是 OC 动态性的根源。因为是“发消息”，所以你可以给 nil 发消息（对着空气说话，不会有人打你），所以你可以在运行时把消息截获下来换成别的。

5.2 多参数的魅力：像写句子一样写代码

C++ / Java 的函数多参数调用长这样： subString(0, 5) 有时候你看着这两个数字，不仅陷入沉思：哪个是 Start？哪个是 Length？还是 End？

Objective-C 就在这里展示了它的文科生气质： [string substringFromIndex:0 toIndex:5] (注：虽然 OC 实际 API 是 substringWithRange: 等，但这里举例展示标签（Label）的意义) 或者更真实的： [array insertObject:obj atIndex:5]

每一个参数前面都有一个介词或者标签。这让 OC 的代码读起来就像一句英语长难句。 [waiter bringCoffee:hot toTable:5 withSugar:YES]

这被 Swift 完美继承了下来。

5.3 嵌套的方括号：无数个框

当你想把这一连串操作连起来时，噩梦开始了：

[[[[string uppercaseString] substringFromIndex:1] stringByAppendingString:@"World"] length]

这就是著名的“方括号盖饭”。为了读懂这行代码，你得像剥洋葱一样，从最里面那个括号开始往外剥。这也是为什么后来 OC 引入了点语法（Dot Syntax）来访问属性（Properties），试图挽救一下大家的视力。 string.uppercaseString.length —— 啊，世界清净了。

第六章：关键词大观园 —— 那些带 @ 的家伙

Sat, 24 Jan 2026 00:00:00 +0000

在 C 语言里，关键词通常没有前缀。在 OC 里，为了避免和 C 语言的关键词冲突（因为 OC 是 C 的超集），OC 的特有关键词前面都带了一个 @。这让 OC 的代码看起来充满了“邮件感”。

6.1 @interface 与 @implementation

如果你想定义一个类 Person，你需要两步：

1. 在头文件（.h）里昭告天下 (@interface)：

@interface Person : NSObject
// 我有什么属性
@property (nonatomic, strong) NSString *name;
// 我能干什么
- (void)sayHello;
@end

这就好比你的名片。

2. 在实现文件（.m）里修炼内功 (@implementation)：

@implementation Person
- (void)sayHello {
    NSLog(@"Hello, I am %@", self.name);
}
@end

这就好比你的真身。

6.2 +/- 号的分野

你在方法定义前会看到 - 或 +。

- (减号)：实例方法 (Instance Method)。必须先 alloc init 出一个对象才能用。 [person sayHello]
+ (加号)：类方法 (Class Method)。直接对着类喊。 [Person new]

6.3 @property 的魔力

在很久很久以前，我们必须手动写 getter 和 setter。 @property 的出现拯救了我们。 @property (nonatomic, strong) NSString *name; 这一行代码，编译器自动帮你生成了 _name 成员变量，name (getter) 方法，和 setName: (setter) 方法。

这里的 nonatomic 和 strong (或者 copy, assign, weak) 是内存管理的“咒语”。

strong: “你是我的，我死你才能死。” (拥有权)
weak: “我看着你，你死了我就当不认识你。” (弱引用，防止循环引用)
copy: “复印一份给我，原件随你便。” (通常用于字符串)
assign: “我就存个地址，死了别找我。” (用于基本数据类型)

6.4 别的 @ 伙伴

@class: “这就是个类名，别问细节，先编译过去再说。” (前向声明)
@protocol: “这也是一份合同，签了就得干活。” (协议/接口)
@synthesize: “编译器，帮我生成代码。” (现在基本不用写了)
@dynamic: “编译器，别管，我自己会在运行时搞定。” (高阶玩法)

第七章：文件与头文件 —— 你的入场券

Sat, 24 Jan 2026 00:00:00 +0000

7.1 .h 与 .m 的分离

C 语言的遗产。任何一个 OC 类通常需要两个文件：

Header (.h): 你的脸。你要告诉别人你是谁，你有什么公开的方法。
Implementation (.m): 你的心。你实际上是怎么干活的。

这种分离在几十年前是为了提高编译速度（不用每次都解析实现细节），也是为了封装（虽然 OC 的封装是防君子不防小人的）。

什么是 .mm？

如果你看到 .mm 文件，别怕。那是 Objective-C++。它是 OC 和 C++ 的混血儿。在那个文件里，你可以左手写 std::vector，右手写 [NSArray array]。这是通往 C++ 庞大生态库的桥梁。

7.2 #import 与 @class

在 C 里面，我们用 #include。在 OC 里，请永远使用 #import。 #import 聪明一点，它保证同一个文件只会被包含一次，不会让你出现“重定义”的错误。

面试必考题：#import 与 @class 的区别？

#import "Person.h": 我不仅知道有一个类叫 Person，我还知道它内裤是什么颜色的（知道它所有的公开属性和方法）。
@class Person;: 我只知道有一个叫 Person 的东西，至于它具体长啥样，我不关心。我只需要能声明 Person *p 这个指针就行了。

这也是解决 循环引用（Circular Dependency） 的唯一解药：A 引用 B，B 引用 A时，至少有一方由于只能用 @class。

7.3 pch 与 module

以前，我们把所有通用的头文件（比如 UIKit）都塞进 Prefix.pch 里，这样就不用每个文件都写 import。但这样会让编译变慢。

后来，Apple 发明了 Modules (@import UIKit;)。它预编译了模块，极大地加速了编译，而且让你不再需要手动去 Link 二进制库文件。这是现代 OC 开发的标配。

第八章：实战 —— Hello, Object!

Sat, 24 Jan 2026 00:00:00 +0000

8.1 一个完整的 OC 程序

让我们把之前学到的东西拼装起来。如果不依赖 Xcode 的模板，一个纯粹的 OC 程序长什么样？

Greeter.h

#import <Foundation/Foundation.h>

// 定义协议
@protocol GreeterDelegate <NSObject>
- (void)greeterDidFinishGreeting:(NSString *)message;
@end

@interface Greeter : NSObject
@property (nonatomic, copy) NSString *name;
@property (nonatomic, weak) id<GreeterDelegate> delegate;

- (instancetype)initWithName:(NSString *)name;
- (void)greet;
@end

Greeter.m

#import "Greeter.h"

@implementation Greeter

- (instancetype)initWithName:(NSString *)name {
    self = [super init]; // 先初始化父类
    if (self) {
        _name = [name copy]; // 记住要 Copy 字符串
    }
    return self;
}

- (void)greet {
    NSString *msg = [NSString stringWithFormat:@"Hello, %@!", self.name];
    NSLog(@"%@", msg);
    
    // 检查代理是否响应方法，然后发送消息
    if ([self.delegate respondsToSelector:@selector(greeterDidFinishGreeting:)]) {
        [self.delegate greeterDidFinishGreeting:msg];
    }
}
@end

main.m

#import <Foundation/Foundation.h>
#import "Greeter.h"

// 稍微作弊一下，直接在 main 里面实现协议
@interface MainRunner : NSObject <GreeterDelegate>
@end

@implementation MainRunner
- (void)greeterDidFinishGreeting:(NSString *)message {
    NSLog(@"[Delegate Callback] Done: %@", message);
}
@end

int main(int argc, const char * argv[]) {
    @autoreleasepool { // 自动释放池，内存的保护伞
        MainRunner *runner = [MainRunner new];
        
        Greeter *g = [[Greeter alloc] initWithName:@"Objective-C"];
        g.delegate = runner;
        
        [g greet];
    }
    return 0;
}

8.2 解读

@autoreleasepool: 在 main 函数里，所有的 OC 对象通常都需要在这个池子里。当出了这个括号，临时的对象（autoreleased objects）就会被统一清理。
[super init]: OC 的初始化模式。先让爸爸初始化，爸爸同意了（返回非 nil），儿子再初始化。
respondsToSelector:: 这就是动态性的体现。我在运行时问你：“你会不会这招？”你会我才调，不会我就不调，防止崩。
Delegate 模式: id<GreeterDelegate>。这里用 id 表示“随便什么对象”，只要它遵守 GreeterDelegate 协议。这是 iOS 开发中最著名的设计模式。

8.3 Categories (分类)

OC 还有一个大杀器：Category。你可以不通过继承，直接给现有的类（甚至是系统类 NSString）添加方法。

@interface NSString (Reverse)
- (NSString *)reversedString;
@end

这在 Swift 里叫 Extension。但 OC 的 Category 更加野蛮，甚至可以通过 Runtime 给分类添加属性（虽然有点绕）。

8.4 总结

这一部分我们了解了 OC 的骨架。你可能会觉得有点繁琐。没错，OC 就是繁琐。但这种繁琐中包含着一种确定性。所有的逻辑都赤裸裸地摆在桌面上，没有 Swift 那么多语法糖藏着掖着。下一章，我们将进入深水区：Advanced & Runtime。

第九章：灵魂 —— Runtime 运行时

Sat, 24 Jan 2026 00:00:00 +0000

9.1 面向对象的谎言

你写的代码： [receiver message]

编译器眼中的代码： objc_msgSend(receiver, @selector(message))

Objective-C 是一门披着 C 语言外衣的动态语言。普通的 C 语言在编译时就决定了哪个函数被调用（静态绑定）。而 OC 直到运行的那一刻，才决定去哪里找这个方法。

这就像是： C 语言是拿着地图走路，路线早就画好了。 OC 是打车，上车了才跟司机说去哪，半路还能改目的地（Method Swizzling）。

9.2 objc_msgSend 的魔法

这个函数是 OC 的心脏。它是用汇编写的，为了极致的速度。它做的事情很简单：

检查 receiver 是不是 nil。是的话直接返回 0。
在 receiver 的 Class 的缓存（Cache）里找 message。
找不到？去 Class 的方法列表（Method List）里找。
还找不到？去 SuperClass 里找。
…一直找到 NSObject。

这也是为什么 OC 的方法调用比 C++ 的虚函数稍微慢那么一点点的原因，但换来的是无与伦比的灵活性。

9.3 黑魔法：Method Swizzling

因为方法查找本身就是一个在表里查字符串的过程。那如果我们悄悄把表改了呢？我们要把 [UIViewController viewWillAppear:] 方法换成我们自己的 [MyClass my_viewWillAppear:]，在里面偷偷埋点统计用户行为，然后再调用回原来的方法。

这就是 AOP（面向切面编程） 在 OC 里的终极形态。 Swift 只有在继承了 NSObject 并且标记了 dynamic 的时候才能这么干。但在 OC 里，这是标配。

你可以把系统的 UIImage imageNamed: 替换掉，给所有图片加载加个缓存或者是打印个日志。能力越强，责任越大。乱用 Swizzling 的后果就是 Debug 的时候你想杀人。

9.4 消息转发：死前的挣扎

当 obj 真的找不到 message 时，系统不会立刻崩溃，而是给你三次机会：

Resolve: +resolveInstanceMethod: —— 给你个机会动态添加一个方法。
ForwardingTarget: -forwardingTargetForSelector: —— 问你有没有备胎（其他对象）能处理这个消息？
ForwardInvocation: -forwardInvocation: —— 把消息打包成 NSInvocation，随你随便怎么处理（改参数、改目标、甚至吞掉）。

如果这三步你都无动于衷，那么 doesNotRecognizeSelector: 才会把你送走。

9.5 总结

Runtime 是 OC 的灵魂。 Swift 很棒，很快，很安全。但只有在操作 Runtime 的时候，你才会感觉自己像个真正的黑客。

第十章：现代化的救赎 —— Block 与 GCD

Sat, 24 Jan 2026 00:00:00 +0000

10.1 Block：闭包的方括号版本

在很久以前，OC 想要回调，只能靠 Delegate。为了回传一个状态，你得写协议、设代理、实现方法……太累了。后来，Apple 引入了 Blocks（^）。

它的语法可以说是 OC 中最反人类的设计之一（著名的 fuckingblocksyntax.com 就是为此而生）： returnType (^blockName)(parameterTypes) = ^returnType(parameters) {...};

但是，它让代码可以在原地执行回调。

[manager fetchWeathersWithCompletion:^(NSArray *weathers, NSError *error) {
    // 收到数据，直接在这里处理
    NSLog(@"Fetched: %@", weathers);
}];

这极大地简化了异步编程的逻辑。需要注意的是 循环引用（Retain Cycle）：在 Block 里用 self，一定要先 __weak typeof(self) weakSelf = self;。

10.2 GCD：把线程扔进队列

与 Blocks 一起诞生的，是 Grand Central Dispatch (GCD)。在 GCD 之前，我们用 NSThread 或 NSOperation。 GCD 告诉我们：忘掉线程吧。你只需要关心队列（Queue）。

串行队列 (Serial Queue): 一个接一个做。
并发队列 (Concurrent Queue): 大家一起做。
主队列 (Main Queue): 专门负责更新 UI 的（UI 只能在主线程更新）。

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // 1. 在后台干脏活累活（下载图片）
    UIImage *img = [self downloadImage];
    
    dispatch_async(dispatch_get_main_queue(), ^{
        // 2. 回到主线程更新 UI
        self.imageView.image = img;
    });
});

这套 dispatch_async 的模板代码，是每一个 OC 程序员的肌肉记忆。虽然 Swift 如今有了 async/await，但 GCD 依然是底层最坚实的基石。

第十一章：设计的哲学 —— OC 的七种武器

Sat, 24 Jan 2026 00:00:00 +0000

11.1 单例（Singleton）：只有一个

OC 的单例写起来很有仪式感：

+ (instancetype)sharedInstance {
    static MyClass *instance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[super allocWithZone:NULL] init];
    });
    return instance;
}

dispatch_once 保证了线程安全，保证了只会执行一次。这是最标准的写法。

11.2 代理（Delegate）：一对一的纠缠

前面说过，Delegate 是为了解耦。 WebView 即使不知道正在使用它的是哪个 ViewController，也能通过 id<UIWebViewDelegate> 告诉外面：“网页加载完了”。弱引用（weak property）是关键，否则两个对象互相抱着对方的大腿（Retain Cycle），谁也死不掉。

11.3 通知（Notification）：一对多的广播

NSNotificationCenter 是一个大喇叭。只要你注册了监听，我不认识你，我还是能发消息给你。适用于：登录成功、键盘弹出、APP 进入后台这些全局事件。记得在 dealloc 里移除监听（虽然 iOS 9 以后系统自动帮你做了，但老习惯很难改）。

11.4 KVO (Key-Value Observing)：暗中观察

OC 允许你观察任意对象的任意属性的变化。 [person addObserver:self forKeyPath:@"name" ...] 这在实现 MVVM（Model-View-ViewModel）架构时非常有用。不用写任何回调代码，只要 Model 变了，View 自动就变了。

11.5 总结

OC 的设计模式非常推崇 松耦合。无论是 Delegate 还是 Runtime 消息机制，都在试图让对象之间的连接变得没那么“僵硬”。这种哲学让 OC 的代码往往比 C++ 项目更容易拆分和重构（如果不算那堆头文件的话）。

第十二章：双城记 —— OC vs Swift

Sat, 24 Jan 2026 00:00:00 +0000

12.1 安全感 vs 自由度

Swift 是一门安全的语言。它有 Optional，逼着你处理 nil。它有强类型检查，逼着你不能乱转类型。它像一个控制欲极强的妈，把刀具（指针）都收起来，把桌角都包上软垫，生怕你伤着自己。

Objective-C 是一门自由的语言。它给你一把枪（指针），告诉你枪口不要对着脚，然后就去喝咖啡了。如果你真的对着脚开了一枪（Crash），那是你自己的问题。 id 甚至可以容纳一切。

12.2 值类型 vs 引用类型

Swift 推崇 Struct（值类型）。你复制一份，就是真的复制了一份。修改 A 不会影响 B。这减少了很多多线程竞争的问题。

OC 只有 Class（引用类型）。所有的对象都在堆（Heap）上。你传过去的是一个指针。如果不小心，你在 A 线程改了对象的属性，B 线程可能直接崩给你看。所以 OC 里我们在多线程环境下通过 copy 属性或锁来保命。

12.3 动态派发 vs 静态派发

Swift 默认尽可能使用 Static Dispatch。方法调用在编译时就确定了地址，速度飞快，编译器能做大量优化（内联）。

OC 永远是 Dynamic Dispatch（消息发送）。它慢，但它灵活。这也是为什么 Swift 的库很难 Mock，而 OC 的库随便 Swizzle 一下就能 Mock 的原因。

12.4 总结

Swift 是未来，是工业化、标准化的产物。 Objective-C 是过去，是手工艺、即兴发挥的爵士乐。它们没有谁好谁坏，只有适不适合。但是在今天，新项目首选 Swift 已经是不争的共识。

第十三章：鹊桥会 —— OC 与 Swift 的混编

Sat, 24 Jan 2026 00:00:00 +0000

13.1 两个世界的桥梁

虽然 Swift 喊着要杀掉 OC，但 Apple 还是留了一手：完美的互操作性（Interoperability）。你可以在同一个项目里，左边是 .swift，右边是 .m。

13.2 这一侧：Swift 调用 OC

只要你在 Bridging-Header.h 里把 OC 的头文件 #import 进去，Swift 就能看见它们。而且 Swift 会自动把 OC 的 API “翻译”得更 Swift 一点：

initWithString: -> init(string:)
NS_ENUM -> Swift Enum

这是最舒服的方向。Swift 就像吃自助餐一样享用现有的海量 OC 库。

13.3 那一侧：OC 调用 Swift

这就有点难受了。首先，Swift 的类必须继承自 NSObject。其次，你想暴露给 OC 的属性和方法前，必须加上 @objc 关键字。只有这样，Swift 才会为它们生成动态的派发表，OC 才能通过 Runtime 找到它们。

13.4 Nullability 的救赎

OC 最初是没有 Optional 的概念的。为了让 Swift 知道 OC 的返回值到底会不会是 nil，OC 后来引入了标注：

nonnull: 绝非空。
nullable: 可能是空。
NS_ASSUME_NONNULL_BEGIN / END: 宏包围，省得一个个写。

如果没写这些，Swift 会把 OC 的对象识别为 Implicitly Unwrapped Optional (Type!)，这是一个充满危险的信号。一旦它是空，你访问它，就崩了。

13.5 总结

混编是目前大型 App 的常态（尤其是国内大厂）。但是混编会带来编译时间的直线上升，以及调试时的各种莫名其妙的报错。如果可以，尽量保持模块间的纯净。不要在同一个模块里纠缠不清。

第十四章：战况报告 —— OC 还没死，只是在养老院

Sat, 24 Jan 2026 00:00:00 +0000

14.1 国内 vs 国外：不同的风景

在中国，Objective-C 的生命力依然顽强得惊人。原因很简单：存量巨大。像微信、支付宝、淘宝这种超级 App，底层有着数百万行的 OC 和 C++ 代码。重写？不存在的。哪怕是像字节跳动这样相对年轻的大厂，核心业务线里依然流淌着大量的 OC 血液。

所以在国内面试，你依然会被问到 RunLoop、Runtime、Block 底层实现。这不仅是考察技术，更是为了确认你能维护那些比你岁数还大的老代码。

在国外，尤其是硅谷的创业公司，Swift 已经是绝对的主流。如果你在 2026 年还在用 OC 开新项目，可能会被同行用异样的眼光看着：“伙计，你是穿越来的吗？”

14.2 它是基础设施

Objective-C 正在经历它的“COBOL 化”。它不会消失。它会沉淀到底层。 Foundation 框架、UIKit 框架，它们的内部依然是 OC（或者是 C++）。只要 Apple 不把 Cocoa Touch 重写一遍（目前看来它们正在用 Swift 重写，比如 SwiftUI），OC 就永远在那里。

14.3 OC 程序员的未来

如果你是一个精通 OC 的程序员，恭喜你，你正在成为非物质文化遗产传承人。未来，随着懂 OC 的人越来越少，维护老项目的薪水可能会反而变高（参考现在的 COBOL 程序员）。但请不要只守着 OC。拥抱 Swift，拥抱 Rust，拥抱 AI。让 OC 成为你压箱底的绝活，而不是你唯一的拐杖。

第十五章：给 Swift 原住民的生存指南

Sat, 24 Jan 2026 00:00:00 +0000

15.1 别找了，没有 `var` 和 `let`

在 OC 里，变量就是变量，它总是可变的（除非你用 const，但很少人用）。

Swift: let name = "Jack"
OC: NSString *name = @"Jack"; (注意那个 *，那是你的命)

那个星号 * 意味着这是一个指针。 Swift 帮你隐藏了引用类型的本质，但 OC 把内脏都掏出来给你看。如果你忘了写 *，比如 NSString name，编译器会觉得你想在栈上创建一个对象，然后报错报到你怀疑人生。

15.2 为什么要有两个文件？

Swift: class Person { ... } (一个文件搞定) OC: Person.h + Person.m

试着去欣赏这种分离。 .h 是你对外承诺的接口。 .m 是你不想让人看见的脏乱差的代码。当你只想知道这个类怎么用时，看 .h 就够了。这是一种强制的文档化。

15.3 字符串的坑

Swift: String 是值类型。
OC: NSString 是不可变引用类型，NSMutableString 是可变引用类型。

如果你把一个 NSMutableString 传给了一个属性，而那个属性是从 copy 声明的，那么它变成了一个 NSString（不可变）。如果你试图修改它，Crash。

15.4 最后的建议

不要试图把 OC 写成 Swift。不要到处用点语法（除了属性访问）。试着去感受“发消息”的禅意。

第十六章：给 C/C++ 老兵的战地手册

Sat, 24 Jan 2026 00:00:00 +0000

16.1 别想了，没有模板 (Templates)

OC 的泛型（Generics）是假的。 NSArray<NSString *> 只是给编译器看的。在运行时，它就是个装满 id 的数组。所以，别想着用模板元编程。别想着用 SFINAE。 OC 是动态语言，它的多态靠的是 Duck Typing（鸭子类型）和 Runtime 查找，而不是编译期生成代码。

16.2 智能指针 vs ARC

C++ 11 有 std::shared_ptr。 OC 有 ARC (Automatic Reference Counting)。它们在原理上几乎一样：引用计数。

但是 OC 的对象统一继承自 NSObject，系统级别内置了计数器。

std::shared_ptr -> strong property
std::weak_ptr -> weak property (而且 OC 的 weak 指针指向的对象死后会自动置为 nil，这是最伟大的发明之一，再也不用担心野指针了)。

16.3 名字空间？不存在的

C++: namespace MyLib { ... } OC: (没有)

所以你会看到：NSObject, UIView, AFNetworking。前缀（Prefix）就是我们的名字空间。如果你写一个库，请务必加上你的前缀（比如 AGPerson），否则你会和别人的 AGPerson 冲突，然后导致 Linker Error。

16.4 拥抱运行时

C++ 的 RTTI (运行时类型识别) 被很多人认为是恶魔。但在 OC 里，Introspection (内省) 是日常。 isMemberOfClass:, isKindOfClass:, respondsToSelector:。尽情地问对象它是什么吧。

第十七章：OC 讲笑话时间

Sat, 24 Jan 2026 00:00:00 +0000

17.1 史上最长的方法名

OC 程序员最喜欢的运动：敲键盘。

Java 程序员觉得他们罗嗦： AbstractSingletonProxyFactoryBean

OC 程序员笑了： application:didReceiveRemoteNotification:fetchCompletionHandler: 这还只是个起手式。

有人在 GitHub 上发起过挑战，寻找 Cocoa 框架里最长的方法名。冠军通常是 CoreData 或 AVFoundation 的某个 API，长度通常超过 80 个字符。比如： constraintsAffectingLayoutForAxis:ofItem:withConstant:priority: (其实这个是 AutoLayout 的，还算短的)

结论：OC 程序员的键盘空格键（用来敲代码补全）通常是最先坏的。

17.2 方括号

A: “为什么你们 OC 程序员喜欢用方括号？” B: “[因为 [我们 [觉得 [这 [很 [酷]]]]]]]”

有传言说，OC 的 parser 实际上就是一个只会数括号的计数器。

17.3 关于 nil

A: “我的程序崩了，因为空指针。” B: (Java/C++ 程序员) “NullPointerException? Segmentation Fault?” C: (OC 程序员) “崩了？不可能。给 nil 发消息什么都不会发生。除非你把 nil 塞进了 NSArray。”

是的，[NSArray arrayWithObject:nil] 是 OC 程序员最猝不及防的翻车现场。

第十八章：结语 —— 永远的 ``

Sat, 24 Jan 2026 00:00:00 +0000

18.1 最后的告别

如果我们把编程语言比作城市，Objective-C 就像是那座曾经辉煌的老工业基地。年轻人们搬去了 Swift 那个由玻璃和钢铁建成的现代化新区，那里有类型安全的高速公路，有自动化的内存回收工厂。

但偶尔，你会怀念老城区。你会怀念那种可以直接把手伸进机器齿轮里的粗糙感（Runtime），你会怀念那些用铆钉和方括号敲打出来的坚固建筑（Cocoa）。

Objective-C 也许再也不会有新的特性加入了。但只要 Apple 的操作系统还在，只要 libobjc.A.dylib 还在系统里，它就活着。它活在每一个 iOS App 的底层，活在每一次 objc_msgSend 的跳动中。

18.2 参考资料

Objective-C Programming Language (Apple Documentation Archive)
Effective Objective-C 2.0 by Matt Galloway (必读经典)
Cocoa Design Patterns
Apple Open Source: https://opensource.apple.com/source/objc4/

18.3 后记

写作本书的过程中，我仿佛又回到了那个对着 Xcode 3 调试内存泄漏的下午。希望这本书能让你不仅学会语法，更能感受到那代程序员的快乐与痛苦。

再见，Objective-C。你好，未来。

(全书完)

前言：致那个方括号的时代

Sat, 24 Jan 2026 00:00:00 +0000

在这个SwiftUI漫天飞舞、声明式编程大行其道的2026年，你可能会问：“为什么？为什么要写一本关于Objective-C的书？”

好问题。这就像是在电动车满街跑的时代，突然有人要把一台满身油污的V12内燃机搬上讲台，然后兴致勃勃地教你如何调整化油器。

确实，Objective-C（以下简称OC）已经老了。它老到它的很多语法看起来像是在和编译器吵架；它老到它的方括号 [] 常常让习惯了点语法 . 的新一代程序员感到手指抽筋；它老到苹果在每年的WWDC上都在用Swift一点点地把它埋进历史的尘埃里。

但是，朋友，你听说过“余晖”吗？

OC不仅是一门语言，它是一段传奇。它是乔布斯离开苹果后在NeXT的复仇利剑，它是iPhone改变世界时的幕后功臣。每一个滑动解锁的流畅动画背后，都有一次 objc_msgSend 的疯狂奔跑；每一个App Store奇迹的背后，都有无数个 [retain] 和 [release] 的血泪史。

我们怀念它，不是因为它完美（天哪，它离完美差得远了），而是因为它真实。它让你直面内存的恐惧，它让你理解什么是“动态运行时”的魔法。在Swift那个安全得像婴儿房的世界里待久了，有时候你会想念OC这片狂野的西部荒野——在那里，你可以随心所欲地把一个对象变成另一个对象（isa swizzling），把一个方法换成另一个方法（method swizzling），只要你胆子够大，编译器就不敢管你。

这本书不是为了让你用OC去写下一个抖音（虽然你完全可以），而是为了让你看懂移动开发这座大厦的地基。理解了OC，你就理解了iOS的灵魂。

而且，说实话，我觉得 [receiver message] 这种发消息的写法，有一种古典的、慢条斯理的优雅。就像在微信秒回的时代，偶尔写一封手写的信。

所以，请坐好。我们要发车了。目标：1980年代。

致谢与献词

献给 Brad Cox 和 Tom Love，感谢你们在那个C++刚刚想要统治世界的年代，选择了另一条名叫Smalltalk的小径。

献给 Steve Jobs，感谢你把它带回了苹果。

最重要的是，献给 nil。在OC里，向 nil 发送消息永远是安全的（它只会默默地返回0），不像某些现代语言里的 Optional，动不动就因为强制解包而崩溃给你看。nil，你是我们最沉默也最温柔的守护者。

也献给所有的iOS开发者，无论你是从MRC时代一路 autorelease 过来的老兵，还是从未见过 *.m 文件的Swift原生代新人。希望这本书能让你会心一笑，或者至少了解一下，你的前辈们当年都在和什么东西搏斗。

Objective-C 的余晖 on 错误的，

Objective-C 的余晖

Book Description

第一章：那只薛定谔的猫 —— OC的诞生

1.1 C语言的狂野与Smalltalk的优雅

1.2 NeXT：被流放国王的复仇之剑

1.3 如果你觉得现在的Xcode难用……

1.4 总结

第二章：黄金时代 —— 当方括号统治世界

2.1 逆袭：NeXT 吞并 Apple

2.2 Cocoa 与 Carbon 的战争

2.3 2008：寒武纪大爆发

第三章：战壕里的故事 —— 你的 App 为什么又崩了？

3.1 手动挡的乐趣（与恐惧）

3.2 经典的崩溃：Unrecognized Selector

3.3 那些年我们写的宏

3.4 总结

第四章：遗产 —— 它留下了什么？

4.1 好的遗产：命名即文档

4.2 坏的遗产：头文件地狱

4.3 永远的方括号

第五章：方括号的艺术 —— 不是调用，是发消息

5.1 从 object.method() 到 [object method]

5.2 多参数的魅力：像写句子一样写代码

5.3 嵌套的方括号：无数个框

第六章：关键词大观园 —— 那些带 @ 的家伙

6.1 @interface 与 @implementation

6.2 +/- 号的分野

6.3 @property 的魔力

6.4 别的 @ 伙伴

第七章：文件与头文件 —— 你的入场券

7.1 .h 与 .m 的分离

什么是 .mm？

7.2 #import 与 @class

7.3 pch 与 module

第八章：实战 —— Hello, Object!

8.1 一个完整的 OC 程序

8.2 解读

8.3 Categories (分类)

8.4 总结

第九章：灵魂 —— Runtime 运行时

9.1 面向对象的谎言

9.2 objc_msgSend 的魔法

9.3 黑魔法：Method Swizzling

9.4 消息转发：死前的挣扎

9.5 总结

第十章：现代化的救赎 —— Block 与 GCD

10.1 Block：闭包的方括号版本

10.2 GCD：把线程扔进队列

第十一章：设计的哲学 —— OC 的七种武器

11.1 单例（Singleton）：只有一个

11.2 代理（Delegate）：一对一的纠缠

11.3 通知（Notification）：一对多的广播

11.4 KVO (Key-Value Observing)：暗中观察

11.5 总结

第十二章：双城记 —— OC vs Swift

12.1 安全感 vs 自由度

12.2 值类型 vs 引用类型

12.3 动态派发 vs 静态派发

12.4 总结

第十三章：鹊桥会 —— OC 与 Swift 的混编

13.1 两个世界的桥梁

13.2 这一侧：Swift 调用 OC

13.3 那一侧：OC 调用 Swift

13.4 Nullability 的救赎

13.5 总结

第十四章：战况报告 —— OC 还没死，只是在养老院

14.1 国内 vs 国外：不同的风景

14.2 它是基础设施

14.3 OC 程序员的未来

第十五章：给 Swift 原住民的生存指南

15.1 别找了，没有 var 和 let

15.2 为什么要有两个文件？

15.3 字符串的坑

15.4 最后的建议

第十六章：给 C/C++ 老兵的战地手册

16.1 别想了，没有模板 (Templates)

16.2 智能指针 vs ARC

16.3 名字空间？不存在的

16.4 拥抱运行时

5.1 从 `object.method()` 到 `[object method]`

15.1 别找了，没有 `var` 和 `let`