這篇以及之后的文章主要會對 ReactiveObjc v2.5 的實現進行分析，從最簡單的例子中了解 ReactiveCocoa 的工作原理以及概念，也是筆者個人對于 RAC 學習的總結與理解。本文主要會圍繞 RAC 中核心概念 RACSignal 展開，詳細了解其底層實現。
狀態驅動
2015 年的夏天的時候，做了幾個簡單的開源框架，想做點其它更有意思的框架卻沒什么思路，就開始看一些跟編程沒有太大關系的書籍。
其中一本叫做《失控》給了我很大的啟發，其中有一則故事是這樣的：
布魯克斯開展了一個雄心勃勃的研究生課題項目，研發更接近昆蟲而非恐龍的機器人。
布魯克斯的設想在一個叫「成吉思」的機巧裝置上成形。成吉思有橄欖球大小，像只蟑螂似的。布魯克斯把他的精簡理念發揮到了極致。小成吉思有 6 條腿卻沒有一丁點兒可以稱為「腦」的東西。所有 12 個電機和 21 個傳感器分布在沒有中央處理器的可解耦網絡上。然而這 12 個充當肌肉的電機和 21 個傳感器之間的交互作用居然產生了令人驚嘆的復雜性和類似生命體的行為。
成吉思的每條小細腿都在自顧自地工作，和其余的腿毫無關系。每條腿都通過自己的一組神經元——一個微型處理器——來控制其動作。每條腿只需管好自己！對成吉思來說，走路是一個團隊合作項目，至少有六個小頭腦在工作。它體內其余更微小的腦力則負責腿與腿之間的通訊。昆蟲學家說這正是螞蟻和蟑螂的解決之道——這些爬行昆蟲的足肢上的神經元負責為該足肢進行思考。
------ 《失控》第三章·第二節 快速、廉價、失控
書中對于機器人的介紹比較冗長，在這里就簡單總結一下：機器人的每一條腿都單獨進行工作，通過傳感器感應的狀態做出響應：
- 如果腿抬起來了，那么它要落下去；
- 如果腿在向前動，要讓另外五條腿距離它遠一點；
這種去中心化的方式，簡化了整個系統的構造，使得各個組件只需要關心狀態，以及狀態對應的動作；不再需要一個中樞系統來組織、管理其它的組件，并負責大多數的業務邏輯。這種自底向下的、狀態驅動的構建方式能夠使用多個較小的組件，減少臃腫的中樞出現的可能性，從而降低系統的復雜度。
ReactiveCocoa 與信號
ReactiveCocoa 對于狀態的理解與《失控》一書中十分類似，將原有的各種設計模式，包括代理、Target/Action、block、通知中心以及觀察者模式各種『輸入』，都抽象成了數據流或者信號（也可以理解為狀態流）讓單一的組件能夠對自己的響應動作進行控制，簡化了視圖控制器的負擔。
在 ReactiveCocoa 中最重要的信號，也就是 RACSignal 對象是這一篇文章介紹的核心；文章中主要會介紹下面的代碼片段出現的內容：
RACSignal *signal = [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
[subscriber sendNext:@1];
[subscriber sendNext:@2];
[subscriber sendCompleted];
return [RACDisposable disposableWithBlock:^{
NSLog(@"dispose");
}];
}];
[signal subscribeNext:^(id _Nullable x) {
NSLog(@"%@", x);
}];
在上述代碼執行時，會在控制臺中打印出以下內容：
1
2
dispose
代碼片段基本都是圍繞 RACSignal 類進行的，文章會分四部分對上面的代碼片段的工作流程進行簡單的介紹：
- 簡單了解
RACSignal - 信號的創建
- 信號的訂閱與發送
- 訂閱的回收過程
RACSignal 簡介
RACSignal 其實是抽象類 RACStream 的子類，在整個 ReactiveObjc 工程中有另一個類 RACSequence 也繼承自抽象類 RACStream：
RACSignal 可以說是 ReactiveCocoa 中的核心類，也是最重要的概念，整個框架圍繞著 RACSignal 的概念進行組織，對 RACSignal 最簡單的理解就是它表示一連串的狀態：
在狀態改變時，對應的訂閱者 RACSubscriber 就會收到通知執行相應的指令，在 ReactiveCocoa 的世界中所有的消息都是通過信號的方式來傳遞的，原有的設計模式都會簡化為一種模型，這篇文章作為 ReactiveCocoa 系列的第一篇文章并不會對這些問題進行詳細的展開和介紹，只會對 RACSignal 使用過程的原理進行簡單的分析。
這一小節會對 RACStream 以及 RACSignal 中與 RACStream 相關的部分進行簡單的介紹。
RACStream
RACStream 作為抽象類本身不提供方法的實現，其實現內部原生提供的而方法都是抽象方法，會在調用時直接拋出異常：
+ (__kindof RACStream *)empty {
NSString *reason = [NSString stringWithFormat:@"%@ must be overridden by subclasses", NSStringFromSelector(_cmd)];
@throw [NSException exceptionWithName:NSInternalInconsistencyException reason:reason userInfo:nil];
}
- (__kindof RACStream *)bind:(RACStreamBindBlock (^)(void))block;
+ (__kindof RACStream *)return:(id)value;
- (__kindof RACStream *)concat:(RACStream *)stream;
- (__kindof RACStream *)zipWith:(RACStream *)stream;
上面的這些抽象方法都需要子類覆寫，不過 RACStream 在 Operations 分類中使用上面的抽象方法提供了豐富的內容，比如說 -flattenMap: 方法：
- (__kindof RACStream *)flattenMap:(__kindof RACStream * (^)(id value))block {
Class class = self.class;
return [[self bind:^{
return ^(id value, BOOL *stop) {
id stream = block(value) ?: [class empty];
NSCAssert([stream isKindOfClass:RACStream.class], @"Value returned from -flattenMap: is not a stream: %@", stream);
return stream;
};
}] setNameWithFormat:@"[%@] -flattenMap:", self.name];
}
其他方法比如 -skip:、-take:、-ignore： 等等實例方法都構建在這些抽象方法之上，只要子類覆寫了所有抽象方法就能自動獲得所有的 Operation 分類中的方法。
RACSignal 與 Monad
如果你對 Monad 有所了解，那么你應該知道
bind和return其實是 Monad 中的概念，但 Monad 并不是本篇文章所覆蓋的內容，并不會具體解釋它到底是什么。
ReactiveCocoa 框架中借鑒了很多其他平臺甚至語言中的概念，包括微軟中的 Reactive Extension 以及 Haskell 中的 Monad，RACStream 提供的抽象方法中的 +return: 和 -bind: 就與 Haskell 中 Monad 完全一樣。
很多人都說 Monad 只是一個自函子范疇上的一個幺半群而已；在筆者看來這種說法雖然是正確的，不過也很扯淡，這句話解釋了還是跟沒解釋一樣，如果有人再跟你用這句話解釋 Monad，我覺得你最好的回應就是買一本范疇論糊他一臉。如果真的想了解 Haskell 中的 Monad 到底是什么？可以從代碼的角度入手，多寫一些代碼就明白了，這個概念理解起來其實根本沒什么困難的，當然也可以看一下 A Fistful of Monads，寫寫其中的代碼，會對 Monad 有自己的認知，當然，請不要再寫一篇解釋 Monad 的教程了（手動微笑）。
首先來看一下 +return 方法的 實現：
+ (RACSignal *)return:(id)value {
return [RACReturnSignal return:value];
}
該方法接受一個 NSObject 對象，并返回一個 RACSignal 的實例，它會將一個 UIKit 世界的對象 NSObject 轉換成 ReactiveCocoa 中的 RACSignal：
而 RACReturnSignal 也僅僅是把 NSObject 對象包裝一下，并沒有做什么復雜的事情：
+ (RACSignal *)return:(id)value {
RACReturnSignal *signal = [[self alloc] init];
signal->_value = value;
return signal;
}
但是 -bind: 方法的 實現 相比之下就十分復雜了：
- (RACSignal *)bind:(RACSignalBindBlock (^)(void))block {
return [[RACSignal createSignal:^(id<RACSubscriber> subscriber) {
RACSignalBindBlock bindingBlock = block();
return [self subscribeNext:^(id x) {
BOOL stop = NO;
id signal = bindingBlock(x, &stop);
if (signal != nil) {
[signal subscribeNext:^(id x) {
[subscriber sendNext:x];
} error:^(NSError *error) {
[subscriber sendError:error];
} completed:^{
[subscriber sendCompleted];
}];
}
if (signal == nil || stop) {
[subscriber sendCompleted];
}
} error:^(NSError *error) {
[subscriber sendError:error];
} completed:^{
[subscriber sendCompleted];
}];
}] setNameWithFormat:@"[%@] -bind:", self.name];
}
筆者在這里對
-bind:方法進行了大量的省略，省去了其中對各種RACDisposable的處理過程。
-bind: 方法會在原信號每次發出消息時，都執行 RACSignalBindBlock 對原有的信號中的消息進行變換生成一個新的信號：
在原有的
RACSignal對象上調用-bind:方法傳入RACSignalBindBlock，圖示中的右側就是具體的執行過程，原信號在變換之后變成了新的藍色的RACSignal對象。
RACSignalBindBlock 可以簡單理解為一個接受 NSObject 對象返回 RACSignal 對象的函數：
typedef RACSignal * _Nullable (^RACSignalBindBlock)(id _Nullable value, BOOL *stop);
其函數簽名可以理解為 id -> RACSignal，然而這種函數是無法直接對 RACSignal 對象進行變換的；不過通過 -bind: 方法就可以使用這種函數操作 RACSignal，其實現如下：
- 將
RACSignal對象『解包』出NSObject對象； - 將
NSObject傳入RACSignalBindBlock返回RACSignal。
如果在不考慮 RACSignal 會發出錯誤或者完成信號時，-bind: 可以簡化為更簡單的形式：
- (RACSignal *)bind:(RACSignalBindBlock (^)(void))block {
return [[RACSignal createSignal:^(id<RACSubscriber> subscriber) {
RACSignalBindBlock bindingBlock = block();
return [self subscribeNext:^(id x) {
BOOL stop = NO;
[bindingBlock(x, &stop) subscribeNext:^(id x) {
[subscriber sendNext:x];
}];
}];
}] setNameWithFormat:@"[%@] -bind:", self.name];
}
調用 -subscribeNext: 方法訂閱當前信號，將信號中的狀態解包，然后將原信號中的狀態傳入 bindingBlock 中并訂閱返回的新的信號，將生成的新狀態 x 傳回原信號的訂閱者。
這里通過兩個簡單的例子來了解 -bind: 方法的作用：
RACSignal *signal = [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
[subscriber sendNext:@1];
[subscriber sendNext:@2];
[subscriber sendNext:@3];
[subscriber sendNext:@4];
[subscriber sendCompleted];
return nil;
}];
RACSignal *bindSignal = [signal bind:^RACSignalBindBlock _Nonnull{
return ^(NSNumber *value, BOOL *stop) {
value = @(value.integerValue * value.integerValue);
return [RACSignal return:value];
};
}];
[signal subscribeNext:^(id _Nullable x) {
NSLog(@"signal: %@", x);
}];
[bindSignal subscribeNext:^(id _Nullable x) {
NSLog(@"bindSignal: %@", x);
}];
上面的代碼中直接使用了 +return: 方法將 value 打包成了 RACSignal * 對象：
在 BindSignal 中的每一個數字其實都是由一個
RACSignal包裹的，這里沒有畫出，在下一個例子中，讀者可以清晰地看到其中的區別。
上圖簡要展示了變化前后的信號中包含的狀態，在運行上述代碼時，會在終端中打印出：
signal: 1
signal: 2
signal: 3
signal: 4
bindSignal: 1
bindSignal: 4
bindSignal: 9
bindSignal: 16
這是一個最簡單的例子，直接使用 -return: 打包 NSObject 返回一個 RACSignal，接下來用一個更復雜的例子來幫助我們更好的了解 -bind: 方法：
RACSignal *signal = [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
[subscriber sendNext:@1];
[subscriber sendNext:@2];
[subscriber sendCompleted];
return nil;
}];
RACSignal *bindSignal = [signal bind:^RACSignalBindBlock _Nonnull{
return ^(NSNumber *value, BOOL *stop) {
NSNumber *returnValue = @(value.integerValue * value.integerValue);
return [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
for (NSInteger i = 0; i < value.integerValue; i++) [subscriber sendNext:returnValue];
[subscriber sendCompleted];
return nil;
}];
};
}];
[bindSignal subscribeNext:^(id _Nullable x) {
NSLog(@"%@", x);
}];
下圖相比上面例子中的圖片更能精確的表現出 -bind: 方法都做了什么：
信號中原有的狀態經過 -bind: 方法中傳入 RACSignalBindBlock 的處理實際上返回了多個 RACSignal。
在源代碼的注釋中清楚地寫出了方法的實現過程：
- 訂閱原信號中的值；
- 將原信號發出的值傳入
RACSignalBindBlock進行轉換； - 如果
RACSignalBindBlock返回一個信號，就會訂閱該信號并將信號中的所有值傳給訂閱者subscriber； - 如果
RACSignalBindBlock請求終止信號就會向原信號發出-sendCompleted消息； - 當所有信號都完成時，會向訂閱者發送
-sendCompleted； - 無論何時，如果信號發出錯誤，都會向訂閱者發送
-sendError:消息。
如果想要了解 -bind: 方法在執行的過程中是如何處理訂閱的清理和銷毀的，可以閱讀文章最后的 -bind: 中對訂閱的銷毀 部分。
信號的創建
信號的創建過程十分簡單，-createSignal: 是推薦的創建信號的方法，方法其實只做了一次轉發：
+ (RACSignal *)createSignal:(RACDisposable * (^)(id<RACSubscriber> subscriber))didSubscribe {
return [RACDynamicSignal createSignal:didSubscribe];
}
+ (RACSignal *)createSignal:(RACDisposable * (^)(id<RACSubscriber> subscriber))didSubscribe {
RACDynamicSignal *signal = [[self alloc] init];
signal->_didSubscribe = [didSubscribe copy];
return [signal setNameWithFormat:@"+createSignal:"];
}
該方法其實只是創建了一個 RACDynamicSignal 實例并保存了傳入的 didSubscribe 代碼塊，在每次有訂閱者訂閱當前信號時，都會執行一遍，向訂閱者發送消息。
RACSignal 類簇
雖然 -createSignal: 的方法簽名上返回的是 RACSignal 對象的實例，但是實際上這里返回的是 RACDynamicSignal，也就是 RACSignal 的子類；同樣，在 ReactiveCocoa 中也有很多其他的 RACSignal 子類。
使用類簇的方式設計的 RACSignal 在創建實例時可能會返回 RACDynamicSignal、RACEmptySignal、RACErrorSignal 和 RACReturnSignal 對象：
其實這幾種子類并沒有對原有的 RACSignal 做出太大的改變，它們的創建過程也不是特別的復雜，只需要調用 RACSignal 不同的類方法：
RACSignal 只是起到了一個代理的作用，最后的實現過程還是會指向對應的子類：
+ (RACSignal *)error:(NSError *)error {
return [RACErrorSignal error:error];
}
+ (RACSignal *)empty {
return [RACEmptySignal empty];
}
+ (RACSignal *)return:(id)value {
return [RACReturnSignal return:value];
}
以 RACReturnSignal 的創建過程為例：
+ (RACSignal *)return:(id)value {
RACReturnSignal *signal = [[self alloc] init];
signal->_value = value;
return signal;
}
這個信號的創建過程和 RACDynamicSignal 的初始化過程一樣，都非常簡單；只是將傳入的 value 簡單保存一下，在有其他訂閱者 -subscribe: 時，向訂閱者發送 value：
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
return [RACScheduler.subscriptionScheduler schedule:^{
[subscriber sendNext:self.value];
[subscriber sendCompleted];
}];
}
RACEmptySignal 和 RACErrorSignal 的創建過程也異常的簡單，只是對傳入的數據進行簡單的存儲，然后在訂閱時發送出來：
// RACEmptySignal
+ (RACSignal *)empty {
return [[[self alloc] init] setNameWithFormat:@"+empty"];
}
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
return [RACScheduler.subscriptionScheduler schedule:^{
[subscriber sendCompleted];
}];
}
// RACErrorSignal
+ (RACSignal *)error:(NSError *)error {
RACErrorSignal *signal = [[self alloc] init];
signal->_error = error;
return signal;
}
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
return [RACScheduler.subscriptionScheduler schedule:^{
[subscriber sendError:self.error];
}];
}
這兩個創建過程的唯一區別就是一個發送的是『空值』，另一個是 NSError 對象。
信號的訂閱與信息的發送
ReactiveCocoa 中信號的訂閱與信息的發送過程主要是由 RACSubscriber 類來處理的，而這也是信號的處理過程中最重要的一部分，這一小節會先分析整個工作流程，之后會深入代碼的實現。
在信號創建之后調用 -subscribeNext: 方法返回一個 RACDisposable，然而這不是這一流程關心的重點，在訂閱過程中生成了一個 RACSubscriber 對象，向這個對象發送消息 -sendNext: 時，就會向所有的訂閱者發送消息。
信號的訂閱
信號的訂閱與 -subscribe: 開頭的一系列方法有關：
訂閱者可以選擇自己想要感興趣的信息類型 next/error/completed 進行關注，并在對應的信息發生時調用 block 進行處理回調。
所有的方法其實只是對 nextBlock、completedBlock 以及 errorBlock 的組合，這里以其中最長的 -subscribeNext:error:completed: 方法的實現為例（也只需要介紹這一個方法）：
- (RACDisposable *)subscribeNext:(void (^)(id x))nextBlock error:(void (^)(NSError *error))errorBlock completed:(void (^)(void))completedBlock {
RACSubscriber *o = [RACSubscriber subscriberWithNext:nextBlock error:errorBlock completed:completedBlock];
return [self subscribe:o];
}
方法中傳入的所有 block 參數都應該是非空的。
拿到了傳入的 block 之后，使用 +subscriberWithNext:error:completed: 初始化一個 RACSubscriber 對象的實例：
+ (instancetype)subscriberWithNext:(void (^)(id x))next error:(void (^)(NSError *error))error completed:(void (^)(void))completed {
RACSubscriber *subscriber = [[self alloc] init];
subscriber->_next = [next copy];
subscriber->_error = [error copy];
subscriber->_completed = [completed copy];
return subscriber;
}
在拿到這個對象之后，調用 RACSignal 的 -subscribe: 方法傳入訂閱者對象：
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
NSCAssert(NO, @"This method must be overridden by subclasses");
return nil;
}
RACSignal 類中其實并沒有實現這個實例方法，需要在上文提到的四個子類對這個方法進行覆寫，這里僅分析 RACDynamicSignal 中的方法：
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
RACCompoundDisposable *disposable = [RACCompoundDisposable compoundDisposable];
subscriber = [[RACPassthroughSubscriber alloc] initWithSubscriber:subscriber signal:self disposable:disposable];
RACDisposable *schedulingDisposable = [RACScheduler.subscriptionScheduler schedule:^{
RACDisposable *innerDisposable = self.didSubscribe(subscriber);
[disposable addDisposable:innerDisposable];
}];
[disposable addDisposable:schedulingDisposable];
return disposable;
}
這里暫時不需要關注與
RACDisposable有關的任何內容，我們會在下一節中詳細介紹。
RACPassthroughSubscriber 就像它的名字一樣，只是對上面創建的訂閱者對象進行簡單的包裝，將所有的消息轉發給內部的 innerSubscriber，也就是傳入的 RACSubscriber 對象：
- (instancetype)initWithSubscriber:(id<RACSubscriber>)subscriber signal:(RACSignal *)signal disposable:(RACCompoundDisposable *)disposable {
self = [super init];
_innerSubscriber = subscriber;
_signal = signal;
_disposable = disposable;
[self.innerSubscriber didSubscribeWithDisposable:self.disposable];
return self;
}
如果直接簡化 -subscribe: 方法的實現，你可以看到一個看起來極為敷衍的代碼：
- (RACDisposable *)subscribe:(id<RACSubscriber>)subscriber {
return self.didSubscribe(subscriber);
}
方法只是執行了在創建信號時傳入的 RACSignalBindBlock：
[RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
[subscriber sendNext:@1];
[subscriber sendNext:@2];
[subscriber sendCompleted];
return [RACDisposable disposableWithBlock:^{
NSLog(@"dispose");
}];
}];
總而言之，信號的訂閱過程就是初始化 RACSubscriber 對象，然后執行 didSubscribe 代碼塊的過程。
信息的發送
在 RACSignalBindBlock 中，訂閱者可以根據自己的興趣選擇自己想要訂閱哪種消息；我們也可以按需發送三種消息：
而現在只需要簡單看一下這三個方法的實現，就能夠明白信息的發送過程了（真是沒啥好說的，不過為了湊字數完整性）：
- (void)sendNext:(id)value {
@synchronized (self) {
void (^nextBlock)(id) = [self.next copy];
if (nextBlock == nil) return;
nextBlock(value);
}
}
-sendNext: 只是將方法傳入的值傳入 nextBlock 再調用一次，并沒有什么值得去分析的地方，而剩下的兩個方法實現也差不多，會調用對應的 block，在這里就省略了。
訂閱的回收過程
在創建信號時，我們向 -createSignal: 方法中傳入了 didSubscribe 信號，這個 block 在執行結束時會返回一個 RACDisposable 對象，用于在訂閱結束時進行必要的清理，同樣也可以用于取消因為訂閱創建的正在執行的任務。
而處理這些事情的核心類就是 RACDisposable 以及它的子類：
這篇文章中主要關注的是左側的三個子類，當然
RACDisposable的子類不止這三個，還有用于處理 KVO 的RACKVOTrampoline，不過在這里我們不會討論這個類的實現。
RACDisposable
在繼續分析討論訂閱的回收過程之前，筆者想先對 RACDisposable 進行簡要的剖析和介紹：
類 RACDisposable 是以 _disposeBlock 為核心進行組織的，幾乎所有的方法以及屬性其實都是對 _disposeBlock 進行的操作。
關于 _disposeBlock 中的 self
這一小節的內容是可選的，跳過不影響整篇文章閱讀的連貫性。
_disposeBlock 是一個私有的指針變量，當 void (^)(void) 類型的 block 被傳入之后都會轉換成 CoreFoundation 中的類型并以 void * 的形式存入 _disposeBlock 中：
+ (instancetype)disposableWithBlock:(void (^)(void))block {
return [[self alloc] initWithBlock:block];
}
- (instancetype)initWithBlock:(void (^)(void))block {
self = [super init];
_disposeBlock = (void *)CFBridgingRetain([block copy]);
OSMemoryBarrier();
return self;
}
奇怪的是，_disposeBlock 中不止會存儲代碼塊 block，還有可能存儲橋接之后的 self：
- (instancetype)init {
self = [super init];
_disposeBlock = (__bridge void *)self;
OSMemoryBarrier();
return self;
}
這里，剛開始看到可能會覺得比較奇怪，有兩個疑問需要解決：
- 為什么要提供一個
-init方法來初始化RACDisposable對象？ - 為什么要向
_disposeBlock中傳入當前對象？
對于 RACDisposable 來說，雖然一個不包含 _disposeBlock 的對象沒什么太多的意義，但是對于 RACSerialDisposable 等子類來說，卻不完全是這樣，因為 RACSerialDisposable 在 -dispose 時，并不需要執行 disposeBlock，這樣就浪費了內存和 CPU 時間；但是同時我們需要一個合理的方法準確地判斷當前對象的 isDisposed：
- (BOOL)isDisposed {
return _disposeBlock == NULL;
}
所以，使用向 _disposeBlock 中傳入 NULL 的方式來判斷 isDisposed；在 -init 調用時傳入 self 而不是 NULL 防止狀態被誤判，這樣就在不引入其他實例變量、增加對象的設計復雜度的同時，解決了這兩個問題。
如果仍然不理解上述的兩個問題，在這里舉一個錯誤的例子，如果 _disposeBlock 在使用時只傳入 NULL 或者 block，那么在 RACCompoundDisposable 初始化時，是應該向 _disposeBlock 中傳入什么呢？
- 傳入
NULL會導致在初始化之后isDisposed == YES，然而當前對象根本沒有被回收； - 傳入
block會導致無用的 block 的執行，浪費內存以及 CPU 時間；
這也就是為什么要引入 self 來作為 _disposeBlock 內容的原因。
-dispose: 方法的實現
這個只有不到 20 行的 -dispose: 方法已經是整個 RACDisposable 類中最復雜的方法了：
- (void)dispose {
void (^disposeBlock)(void) = NULL;
while (YES) {
void *blockPtr = _disposeBlock;
if (OSAtomicCompareAndSwapPtrBarrier(blockPtr, NULL, &_disposeBlock)) {
if (blockPtr != (__bridge void *)self) {
disposeBlock = CFBridgingRelease(blockPtr);
}
break;
}
}
if (disposeBlock != nil) disposeBlock();
}
但是其實它的實現也沒有復雜到哪里去，從 _disposeBlock 實例變量中調用 CFBridgingRelease 取出一個 disposeBlock，然后執行這個 block，整個方法就結束了。
RACSerialDisposable
RACSerialDisposable 是一個用于持有 RACDisposable 的容器，它一次只能持有一個 RACDisposable 的實例，并可以原子地換出容器中保存的對象：
- (RACDisposable *)swapInDisposable:(RACDisposable *)newDisposable {
RACDisposable *existingDisposable;
BOOL alreadyDisposed;
pthread_mutex_lock(&_mutex);
alreadyDisposed = _disposed;
if (!alreadyDisposed) {
existingDisposable = _disposable;
_disposable = newDisposable;
}
pthread_mutex_unlock(&_mutex);
if (alreadyDisposed) {
[newDisposable dispose];
return nil;
}
return existingDisposable;
}
線程安全的 RACSerialDisposable 使用 pthred_mutex_t 互斥鎖來保證在訪問關鍵變量時不會出現線程競爭問題。
-dispose 方法的處理也十分簡單：
- (void)dispose {
RACDisposable *existingDisposable;
pthread_mutex_lock(&_mutex);
if (!_disposed) {
existingDisposable = _disposable;
_disposed = YES;
_disposable = nil;
}
pthread_mutex_unlock(&_mutex);
[existingDisposable dispose];
}
使用鎖保證線程安全，并在內部的 _disposable 換出之后在執行 -dispose 方法對訂閱進行處理。
RACCompoundDisposable
與 RACSerialDisposable 只負責一個 RACDisposable 對象的釋放不同；RACCompoundDisposable 同時負責多個 RACDisposable 對象的釋放。
相比于只管理一個 RACDisposable 對象的 RACSerialDisposable，RACCompoundDisposable 由于管理多個對象，其實現更加復雜，而且為了性能和內存占用之間的權衡，其實現方式是通過持有兩個實例變量：
@interface RACCompoundDisposable () {
...
RACDisposable *_inlineDisposables[RACCompoundDisposableInlineCount];
CFMutableArrayRef _disposables;
...
}
在對象持有的 RACDisposable 不超過 RACCompoundDisposableInlineCount 時，都會存儲在 _inlineDisposables 數組中，而更多的實例都會存儲在 _disposables 中：
RACCompoundDisposable 在使用 -initWithDisposables:初始化時，會初始化兩個 RACDisposable 的位置用于加速銷毀訂閱的過程，同時為了不浪費內存空間，在默認情況下只占用兩個位置：
- (instancetype)initWithDisposables:(NSArray *)otherDisposables {
self = [self init];
[otherDisposables enumerateObjectsUsingBlock:^(RACDisposable *disposable, NSUInteger index, BOOL *stop) {
self->_inlineDisposables[index] = disposable;
if (index == RACCompoundDisposableInlineCount - 1) *stop = YES;
}];
if (otherDisposables.count > RACCompoundDisposableInlineCount) {
_disposables = RACCreateDisposablesArray();
CFRange range = CFRangeMake(RACCompoundDisposableInlineCount, (CFIndex)otherDisposables.count - RACCompoundDisposableInlineCount);
CFArrayAppendArray(_disposables, (__bridge CFArrayRef)otherDisposables, range);
}
return self;
}
如果傳入的 otherDisposables 多于 RACCompoundDisposableInlineCount，就會創建一個新的 CFMutableArrayRef 引用，并將剩余的 RACDisposable 全部傳入這個數組中。
在 RACCompoundDisposable 中另一個值得注意的方法就是 -addDisposable:
- (void)addDisposable:(RACDisposable *)disposable {
if (disposable == nil || disposable.disposed) return;
BOOL shouldDispose = NO;
pthread_mutex_lock(&_mutex);
{
if (_disposed) {
shouldDispose = YES;
} else {
for (unsigned i = 0; i < RACCompoundDisposableInlineCount; i++) {
if (_inlineDisposables[i] == nil) {
_inlineDisposables[i] = disposable;
goto foundSlot;
}
}
if (_disposables == NULL) _disposables = RACCreateDisposablesArray();
CFArrayAppendValue(_disposables, (__bridge void *)disposable);
foundSlot:;
}
}
pthread_mutex_unlock(&_mutex);
if (shouldDispose) [disposable dispose];
}
在向 RACCompoundDisposable 中添加新的 RACDisposable 對象時，會先嘗試在 _inlineDisposables 數組中尋找空閑的位置，如果沒有找到，就會加入到 _disposables 中；但是，在添加 RACDisposable 的過程中也難免遇到當前 RACCompoundDisposable 已經 dispose 的情況，而這時就會直接 -dispose 剛剛加入的對象。
訂閱的銷毀過程
在了解了 ReactiveCocoa 中與訂閱銷毀相關的類，我們就可以繼續對 -bind: 方法的分析了，之前在分析該方法時省略了 -bind: 在執行過程中是如何處理訂閱的清理和銷毀的，所以會省略對于正常值和錯誤的處理過程，首先來看一下簡化后的代碼：
- (RACSignal *)bind:(RACSignalBindBlock (^)(void))block {
return [[RACSignal createSignal:^(id<RACSubscriber> subscriber) {
RACSignalBindBlock bindingBlock = block();
__block volatile int32_t signalCount = 1;
RACCompoundDisposable *compoundDisposable = [RACCompoundDisposable compoundDisposable];
void (^completeSignal)(RACDisposable *) = ...
void (^addSignal)(RACSignal *) = ...
RACSerialDisposable *selfDisposable = [[RACSerialDisposable alloc] init];
[compoundDisposable addDisposable:selfDisposable];
RACDisposable *bindingDisposable = [self subscribeNext:^(id x) {
BOOL stop = NO;
id signal = bindingBlock(x, &stop);
if (signal != nil) addSignal(signal);
if (signal == nil || stop) {
[selfDisposable dispose];
completeSignal(selfDisposable);
}
} completed:^{
completeSignal(selfDisposable);
}];
selfDisposable.disposable = bindingDisposable;
return compoundDisposable;
}] setNameWithFormat:@"[%@] -bind:", self.name];
}
在簡化的代碼中，訂閱的清理是由一個 RACCompoundDisposable 的實例負責的，向這個實例中添加 RACSerialDisposable 以及 RACDisposable 對象，并在 RACCompoundDisposable 銷毀時銷毀。
completeSignal 和 addSignal 兩個 block 主要負責處理新創建信號的清理工作：
void (^completeSignal)(RACDisposable *) = ^(RACDisposable *finishedDisposable) {
if (OSAtomicDecrement32Barrier(&signalCount) == 0) {
[subscriber sendCompleted];
[compoundDisposable dispose];
} else {
[compoundDisposable removeDisposable:finishedDisposable];
}
};
void (^addSignal)(RACSignal *) = ^(RACSignal *signal) {
OSAtomicIncrement32Barrier(&signalCount);
RACSerialDisposable *selfDisposable = [[RACSerialDisposable alloc] init];
[compoundDisposable addDisposable:selfDisposable];
RACDisposable *disposable = [signal completed:^{
completeSignal(selfDisposable);
}];
selfDisposable.disposable = disposable;
};
先通過一個例子來看一下 -bind: 方法調用之后，訂閱是如何被清理的：
RACSignal *signal = [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
[subscriber sendNext:@1];
[subscriber sendNext:@2];
[subscriber sendCompleted];
return [RACDisposable disposableWithBlock:^{
NSLog(@"Original Signal Dispose.");
}];
}];
RACSignal *bindSignal = [signal bind:^RACSignalBindBlock _Nonnull{
return ^(NSNumber *value, BOOL *stop) {
NSNumber *returnValue = @(value.integerValue);
return [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber> _Nonnull subscriber) {
for (NSInteger i = 0; i < value.integerValue; i++) [subscriber sendNext:returnValue];
[subscriber sendCompleted];
return [RACDisposable disposableWithBlock:^{
NSLog(@"Binding Signal Dispose.");
}];
}];
};
}];
[bindSignal subscribeNext:^(id _Nullable x) {
NSLog(@"%@", x);
}];
在每個訂閱創建以及所有的值發送之后，訂閱就會被就地銷毀，調用 disposeBlock，并從 RACCompoundDisposable 實例中移除：
1
Binding Signal Dispose.
2
2
Binding Signal Dispose.
Original Signal Dispose.
原訂閱的銷毀時間以及綁定信號的控制是由 SignalCount 控制的，其表示 RACCompoundDisposable 中的 RACSerialDisposable 實例的個數，在每次有新的訂閱被創建時都會向 RACCompoundDisposable 加入一個新的 RACSerialDisposable，并在訂閱發送結束時從數組中移除，整個過程用圖示來表示比較清晰：
紫色的
RACSerialDisposable為原訂閱創建的對象，灰色的為新信號訂閱的對象。
總結
這是整個 ReactiveCocoa 源代碼分析系列文章的第一篇，想寫一個跟這個系列有關的代碼已經很久了，文章中對于 RACSignal 進行了一些簡單的介紹，項目中絕大多數的方法都是很簡潔的，行數并不多，代碼的組織方式也很易于理解。雖然沒有太多讓人意外的東西，不過整個工程還是很值得閱讀的。
References
方法實現對照表
| 方法 | 實現 |
|---|---|
+return: |
RACSignal.m#L89-L91 |
-bind: |
RACSignal.m#L93-176 |
Github Repo：iOS-Source-Code-Analyze
Follow: Draveness · GitHub
Source: http://draveness.me/racsignal
