標簽： iOS RAC
概述
ReactiveCocoa是一個函數響應式編程框架，它能讓我們脫離Cocoa API的束縛，給我們提供另外一套編碼的思路與可能性，它能在宏觀層面上提升代碼易讀性與穩定性，讓程序員寫出富有詩意的代碼，因此備受業內推崇。本文略過RAC基本概念與基礎使用，著重介紹RAC數據流方面的內容，剖析RAC核心元素與RAC Operation在數據流中扮演的角色，并從數據流的角度切入，介紹RACComand與RACChannel。
RAC核心元素與管線
在繪制UI時，我們常希望能夠直接獲取所需數據，但大多數情況下，數據需要經過多個步驟處理后才可使用，好比UI使用到的數據是經過流水線加工后最后一端產出的成品。眾所周知，流水線是由多個片段管線組成，上端管線處理后的已加工品成為下端管線的待加工品，每段管線都有對應的管線工人來完成加工工作，直至成品完成。RAC則為我們提供了構建數據流水線的能力，通過組合不同的加工管線來導出我們想要的數據。想要構建好RAC的數據流水線，我們需要先了解流水線中的組成元素－RAC管線。RAC管線的運作實質上就是RAC中一個信號被訂閱的完整過程。下面我們來分析下RAC中一個完整的訂閱過程，并由此來了解RAC中的核心元素。
RAC核心是Signal，對應的類為RACSignal。它其實是一個信號源，Signal會給它的訂閱者（Subscriber）發送一連串的事件，一個Signal可比作流水線中的一段管線，負責決定管線傳輸什么樣的數據。Subscriber是Signal的訂閱者，我們將Subscriber比作管線上的工人，它在拿到數據后對其進行加工處理。數據經過加工后要么進入下一條管線繼續處理，要么直接被當做成品使用。通過RAC管線這個比方，我們來詳細了解下RAC中Signal的完整訂閱過程：
- 管線的設計－createSingal:
RACSignal *pipeline = [RACSignal createSignal:^RACDisposable*(id<RACSubscriber> subscriber) {
[subscriber sendNext:@(1)];
[subscriber sendNext:@(2)];
[subscriber sendNext:@(3)];
[subscriber sendCompleted]; // (1)
return[RACDisposable disposableWithBlock:^{ // (2)
NSLog(@"the pipeline has sent 3 values, and has been stopped");
}];
}];
這里RAC通過類簇的方式，使用RACSignal 的createSignal 方法創建了一個RACDynamicSignal對象(RACSignal的子類)， 同時傳入對應的didSubscribeBlock 參數。這個block里，我們定義了該Signal將按何種方式、發送何種信號值。如文中的pipeline signal在順序發出了 1、 2、 3 三個數據后，發出結束信號 (1)，并且安排好信號終止訂閱時的收尾工作 (2)，這個過程好比是我們預先設計好一段管線，設定好管線啟動后按照何種邏輯，傳送出何種數據。但管線傳送出待加工數據后需要有工人對其進行加工處理，于是RAC引入了Subscriber。
- 管線工人 － Subscriber:
RACSubscriber *worker = [RACSubscriber subscriberWithNext:nextBlock error:errorBlock completed:completedBlock];
Subscriber我們一般稱之為訂閱者，它負責處理Signal傳出的數據。Subscriber初始化的時候會傳入nextBlock、 errorBlock、completeBlock，正是這三個block用于處理不同類型的數據信號，處理后的數據或者被拋往下一段管線，亦或者被當做成品送給使用方。Subscriber好比是管線上的工人，負責加工管線上傳遞過來的各種信號值，不過一旦Subscriber接收到error信號或complete信號，Subscriber會通過相關的RACDisposal主動取消這次訂閱，停止管線的運作。那么管線有了，管線上的裝配工人有了，如何啟動管線?
- 啟動管線 － subscribe：
RACDisposable *disposable = [pipeline subscribe:worker]
通過RACDynamicSignal中的subscribe方法，pipeline signal(RACSignal)開始被worker(RACSubscriber)訂閱。在subscribe方法中, pipeline會在執行createSignal時傳入didSubscribeBlock，執行的過程遵循之前關于管線的設定，worker將接受到3個數據值與一個complete信號，并使用subscriber中的nextBlock與completeBlock對信號值分別進行處理。管線啟動后，會返回一個RACDisposable對象。外部可以通過[RACDisposable dispose]方法隨時停止這段管線的工作。一旦管線停止，subscriber worker將不再處理管線傳送過來的任何類型的數據。詳細的剖析可以參看http://tech.meituan.com/RACSignalSubscription.html。
以上三個步驟構成了一個普通信號的訂閱流程。但往往在使用RAC時，我們看不到后兩者，這是因為RAC將Subscriber的初始化以及[signal subscribe: subscriber]統一封裝到[signal subscribeNext: error: completed:]方法中了，如下圖所示。這種封裝成功屏蔽掉了Subscriber這個概念，進一步簡化信號的訂閱邏輯，使其更加便于使用。（PS：流水線worker永遠都在默默付出！！）
可以發現，按照上面的訂閱流程，信號只有被訂閱時才會送出信號值，這種信號我們稱之為冷信號(cold signal)。既然有冷信號的概念，就肯定有與之對應的熱信號(hot signal)。冷信號好比只有給管線分配工人后，管線才會開啟。而熱信號就是在管線創建之后，不管是否有配套的工人，管線都會開始運作，可以隨時根據外部條件送出數據。送出數據時，如果管線上有工人，數據被工人加工處理，如果沒有工人，數據將被拋棄。以下我們仍然從信號的訂閱步驟對比冷熱信號:（熱信號對應的類RACSubject）
創建信號。與冷信號不同，RACSubject在被創建后將維護一個訂閱者數組（subscribers)，用于隨時存儲加入進來的Subscriber。此外不同于RACDynamicSignal，RACSubject在創建時并不去設定要輸出的數據，而是通過實現<RACSubscriber>協議，允許外部直接使用[RACSubject sendNext:]隨時輸出數據。
創建訂閱者。該創建過程與冷信號完成相同，都是提前準備好Subscriber對應的nextBlock、errorBlock、completedBlock。
RACSubscriber *worker = [RACSubscriber subscriberWithNext:nextBlock error:errorBlock completed:completedBlock];
訂閱。RACSubject(hotSignal)與RACDynamicSignal(coldSignal)內部都有繼承于父類RACSignal的subscribe方法，但實現過程卻完全不同。RACDynamicSignal的subscribe會去執行createSignal時準備好的didSubscribeBlock，同時將subscriber傳給didSubscribeBlock，讓subscriber按照設定好的方式處理相應的數據值。 而熱信號RACSubject僅僅只是將subscriber加入到訂閱者數組中，其它啥事不干。
熱信號沒有提前規劃訂閱時信號的輸出，因而它需要由外部來控制信號何時輸出何種數據值，于是RACSubject實現了<RACSubscriber>協議，向外提供了[RACSubject sendNext:]、[RACSubject sendError:]、[RACSubject sendComplete:]方法。以sendNext舉例，每當使用 [RACSubject sendNext] 時，RACSubject就會遍歷一遍自己的subscribers數組，并調用各數組元素(subscriber)準備好的sendNextBlock (1)。
- (void)sendNext:(id)value
{
[self enumerateSubscribersUsingBlock:^(id<RACSubscriber> subscriber) {
[subscriber sendNext:value]; // (1)
}];
}
以上是冷、熱信號在執行層面上的異同。有時為了減少副作用或著其它某種原因，我們需要將冷信號轉成熱信號，讓它具備熱信號的特性。 這時候我們可以用到[RACDynamicSignal multicast: RACSubject] ，這個方法究其原理也是利用到了RACSubject可隨時sendNext的這一特性。具體冷熱信號的轉換可參見：http://tech.meituan.com/talk-about-reactivecocoas-cold-signal-and-hot-signal-part-3.html 。此外，RACSubject有個子類RACReplaySubject。相較于RACSubject，RACReplaySubject能夠將之前信號發出的數據使用valuesReceived數組保存起來, 當信號被下一個Subscriber訂閱時，它能夠將之前保存的數據值按順序傳送給新的Subscriber。
這一節大概介紹了RACDynamicSignal、 RACSubject、 RACSubscriber、 RACDisposal在訂閱過程中扮演的角色, 事實上調度器RACSchedule也是RAC中非常重要的基礎元素。RAC對它的定義是"schedule: control when and where the work the product"，它對GCD做了一層很薄的包裝。它能夠：1.讓RACSignal送出的信號值在線程中華麗地穿梭；2.延遲或周期執行block中的內容； 3.可以添加同步、異步任務，同時能夠靈活取消異步添加的未執行任務。RACSchedule的使用會在下文提到。
RAC信號流
RAC流水線由多段管線組合而成，上節介紹了單條RAC管線的運作，這一節主要介紹：1.RAC管線間的銜接 — RAC Operation；2.RAC信號流的構建。
RAC Operation 作為信號值的中轉站，它會返回一個新信號N。如下圖所示，RAC Operation對原信號O傳出的值進行加工，并將處理好的數值作為新信號N的輸出，這個過程好比將原管線數據加工后拋往一段新的管線，一條RAC流水線就是由各種各樣的RAC Operation組合而成的。RAC 提供了許多RACSignal Operation方便我們使用 ，其中[RACSignal bind:]操作是信號變換的核心。因此在剖析RAC Operation的時候，我們主要針對bind以及其衍生出來的flattenMap、 map、flatten進行介紹。隨后將RAC流水線應用于一個具體業務需求，詳細了解整段RAC信號流的構建。
首先我們來解讀bind極其衍生出來的幾個Operation：
-
bind函數會返回一個新的信號N。整體思路是對原信號O進行訂閱，每當信號O產生一個值就生成一個中間信號M，并馬上訂閱M, 之后將信號M的輸出作為新信號N的輸出。管線圖如下:
flattenMap/bind
具體來看源碼（為方便理解，去掉了源代碼中RACDisposable, @synchronized, @autoreleasepool相關代碼)。當新信號N被外部訂閱時，會進入信號N 的didSubscribeBlock( 1處)，之后訂閱原信號O (2)，當原信號O有值輸出后就用bind函數傳入的bindBlock將其變換成中間信號M (3), 并馬上對其進行訂閱(4)，最后將中間信號M的輸出作為新信號N的輸出 (5), 如上圖所示。
1. (RACSignal *)bind:(RACStreamBindBlock (^)(void))block {
return [RACSignal createSignal:^(id<RACSubscriber> subscriber) { // (1)
RACStreamBindBlock bindingBlock = block();
[self subscribeNext:^(id x) { // (2)
BOOL stop = NO;
id middleSignal = bindingBlock(x, &stop); // (3)
if (middleSignal != nil) {
RACDisposable *disposable = [middleSignal subscribeNext:^(id x) { // (4)
[subscriber sendNext:x]; // (5)
} error:^(NSError *error) {
[subscriber sendError:error];
} completed:^{
[subscriber sendCompleted];
}];
}
} error:^(NSError *error) {
[subscriber sendError:error];
} completed:^{
[subscriber sendCompleted];
}];
return nil
}];
}
看完代碼，我們再回到bind的管線圖。每當original signal送出一個紅球信號后，bind方法內部就會生成一個對應的middle signal。第一個middle signal送出的是綠球，第二個middle signal送出的是紫球，第三個middle signal送出是藍球。由于在bind操作中，中間信號的輸出將直接作為新信號的輸出，因此我們可以看到圖中的new signal輸出的就是綠球、紫球、藍球等，它相當于是所有middle signal輸出值的集合。
- flattenMap：在RAC的使用中，flattenMap這個操作較為常見。事實上flattenMap是對bind的包裝，為bind提供bindBlock。因此flattenMap與bind操作實質上是一樣的(管線圖可直接參考bind)，都是將原信號傳出的值map成中間信號，同時馬上去訂閱這個中間信號，之后將中間信號的輸出作為新信號的輸出。不過flattenMap在bindBlock基礎上加入了一些安全檢查 (1)，因此推薦還是更多的使用flattenMap而非bind。
- (instancetype)flattenMap:(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); // (1)
return stream;
};
}];
}
- map ：map操作可將原信號輸出的數據通過自定義的方法轉換成所需的數據， 同時將變化后的數據作為新信號的輸出。它實際調用了flattenMap, 只不過中間信號是直接將mapBlock處理的值返回 (1)。代碼與管線圖如下。此外，我們常用的filter內部也是使用了flattenMap。與map相同，它也是將filter后的結果使用中間信號進行包裝并對其進行訂閱，之后將中間信號的輸出作為新信號的輸出，以此來達到輸出filter結果的目的。
- (instancetype)map:(id(^)(id value))block
{
Class class = self.class;
return[self flattenMap:^(id value) {
return[class return:block(value)]; // (1)
};
}
-
flatten: 該操作主要作用于信號的信號。原信號O作為信號的信號，在被訂閱時輸出的數據必然也是個信號(signalValue)，這往往不是我們想要的。當我們執行[O flatten]操作時，因為flatten內部調用了flattenMap (1)，flattenMap里對應的中間信號就是原信號O輸出signalValue (2)。按照之前分析的經驗，在flattenMap操作中新信號N輸出的結果就是各中間信號M輸出的集合。因此在flatten操作中新信號N被訂閱時輸出的值就是原信號O的各個子信號輸出值的集合。這好比將多管線匯聚成單管線，將原信號壓平(flatten)，如下圖所示。
flatten
代碼如下：
- (instancetype)flatten
{
return [self flattenMap:^(RACSignal *signalValue) { // (1)
return [signalValue]; // (2)
};
}
-
switchToLatest：與flatten相同，其主要目的也是用于"壓平"信號的信號。但與flatten不同的是，flatten是在多管線匯聚后，將原信號O的各子信號輸出作為新信號N的輸出，但switchToLatest僅僅只是將O輸出的最新信號L的輸出作為N的輸出。用管線圖表示如下：
swichToLatest
看下代碼，當O送出信號A后，新信號N會馬上訂閱信號A ，但這里用了[A takeUntile O] (1) 。這里的意思就是如果之后原始信號O又送出子信號B，那么之前新信號N對于中間信號A的訂閱也就停止了, 如果O又送出子信號C, 那么N又會停止對B的訂閱。也就是說信號N訂閱的永遠都是O派送出來的最新信號。
- (RACSignal*)switchToLatest
{
return [RACSignal createSignal:^(id<RACSubscriber> subscriber) {
RACMulticastConnection *connection = [self publish];
[[connection.signal flattenMap:^(RACSignal *signalValue) {
return [signalValue takeUntil:[connection.signal concat:[RACSignal never]]]; // (1)
}] subscribe:subscriber];
RACDisposable *connectionDisposable = [connection connect];
return [RACDisposable disposableWithBlock:^{
}];
}];
}
另外作為鋪墊，這里再提兩個操作:
-
scanWithStart : 該操作可將上次reduceBlock處理后輸出的結果作為參數，傳入當次reduceBlock操作，往往用于信號輸出值的聚合處理。scanWithStart內部仍然用到了核心操作bind。它會在bindBlock中對value進行操作，同時將上次操作得到的結果running作為參數帶入 (1)，一旦本次reduceBlock執行完，就將結果保存在running中，以便下次處理時使用，最后再將本次得出的結果用信號包裝后，傳遞出去 (2)。
scanWithStart.png
代碼如下:
- (instancetype)scanWithStart:(id)startingValue reduceWithIndex:(id(^)(id,id,NSUInteger))reduceBlock
{
Class class =self.class;
return [self bind:^{
__block id running = startingValue;
__block NSUIntegerindex = 0;
return^(id value, BOOL*stop) {
running = reduceBlock(running, value, index++); // (1)
return [class return:running]; // (2)
};
}] ;
}
-
throttle:這個操作接收一個時間間隔interval作為參數，如果Signal發出的next事件之后interval時間內不再發出next事件，那么它返回的Signal會將這個next事件發出。也就是說，這個方法會將發送比較頻繁的next事件舍棄，只保留一段“靜默”時間之前的那個next事件。這個操作常用于處理輸入框等信號(用戶打字很快)，因為它只保留用戶最后輸入的文字并返回一個新的Signal，將最后的文字作為next事件參數發出。管線流圖表示如下:
throttle
前面從代碼層面具體剖析了幾個RAC Operation。接著我們借著一個特定的需求，試著將這些RAC管線拼湊成一條RAC數據流。假定一個搜索業務如下：用戶在searchBar中輸入文本，當停止輸入超過0.3秒，認為seachBar中的內容為用戶的意向搜索關鍵字searchKey，將searchKey作為參數執行搜索操作。搜索內容可能是多樣的，也許包括搜單聊消息、群聊消息、公眾號消息、聯系人等，而這些信息搜索的方式也有不同，有些從本地獲取，有些是去服務器查詢，因此返回的速度快慢不一。我們不能等到數據全部獲取成功時才顯示搜索結果頁面，而應該只要有部分數據返回時就將其拋到主線程渲染顯示。在這個需求中，從數據輸入到最后搜索數據的顯示可以具象成一條數據流，數據流中各處對于數據的操作都可以使用上面提到的RAC Operation來完成，通過組合Operation完成以下RAC數據流圖：
從數據流圖來看，RAC有點類似太極，太極生兩儀，兩儀生四象，四象生八卦，八卦生萬物。我們可以用它的百變性來契合產品的業務需求。按照上面的數據流圖，我們可以輕易地寫出對應的RAC代碼:
[[[self.searchBar rac_textSignal]
throttle:0.3]
subscribeNext:^(NSString*keyString) {
RACSignal *searchSignal = [self.viewModel createSearchSignalWithString:keyString];
[[[searchSignal
scanWithStart:[NSMutableArray array] reduce:^NSMutableArray *(NSMutableArray *running, NSArray *next) {
[running addObjectsFromArray:next];
return running;
}]
deliverOnMainThread]
subscribeNext:^(id x) {
// UI Processing
}];
}];
可以看到，使用RAC構建數據流后，聲明式的代碼顯得優雅且清晰易讀，看似復雜的業務需求在RAC的組織下，一兩句代碼就得以輕松搞定。反觀，如果使用常規方法，估計一個throttle對應的操作就會讓邏輯代碼散落各處，另一個scanWithStart的對應操作也應該會加入不少中間變量，這些無疑都會大大提升了代碼的維護成本。數據流的設計也會讓編碼者感覺自己更像是代碼的設計者，而并非代碼的搬運工，讓人樂此不疲_。
本節內容我們首先從源碼層級剖析了幾個RAC Operation，相信通過介紹這幾個Operation相應的 信號銜接細節后，閱讀其它的Operation應該不再是什么難事。之后使用RAC數據流處理了一個具體的業務需求。事實上，RAC提供了非常豐富的操作，通過這些操作的組合，我們基本可以處理日常的業務邏輯。當然，需求是多樣且奇特的，或許在特定情況下無法找到現成的RAC Operation，因此如果有需要，我們也可以直接拓展RACSignal操作或添加自定義UIKit的RAC拓展，從而讓我們的代碼 "more functional, more elegant”。可以毫不夸張的說，阻礙RAC發揮的瓶頸只有想象力，當我們接到需求后，仔細推敲數據的走向并設計好相關數據的操作，只要RAC數據流圖繪制出來，剩下的代碼工作也就信手拈來。
介紹完RAC數據流后，我們再從數據流的角度看看RAC中的另外兩個常用元素RACCommand與RACChannel。
RACCommand
RACCommand是RAC很重要的組成部分，通常用來表示某個action的執行。RACCommand提供executionSignals、 executing、 error等一連串公開的信號，方便外界對action執行過程與執行結果進行觀察。executionSignals是signal of signals，如果外部直接訂閱executionSignals，得到的輸出是當前執行的信號，而不是執行信號輸出的數據，所以一般會配合flatten或switchToLatest使用。 errors，RACCommand的錯誤不是通過sendError來實現的，而是通過errors屬性傳遞出來的。 executing，表示該command當前是否正在執行。它常用于監聽按鈕點擊、網絡請求等。
使用時，我們通常會去生成一個RACCommand對象，并傳入一個返回signal對象的block。每次RACCommand execute 執行操作時，都會通過傳入的這個signal block生成一個執行信號E (1)，并將該信號添加到RACCommand內部信號數組activeExecutionSignals中 (2)，同時將信號E由冷信號轉成熱信號(3)，最后訂閱該熱信號(4)并將其返回(5)。
- (RACSignal *)execute:(id)input
{
RACSignal *signal = self.signalBlock(input); //（1）
RACMulticastConnection *connection = [[signal
subscribeOn:RACScheduler.mainThreadScheduler]
multicast:[RACReplaySubject subject]]; // (3)
@weakify(self);
[self addActiveExecutionSignal:connection.signal]; // (2)
[connection.signal subscribeError:^(NSError *error) {
@strongify(self);
[self removeActiveExecutionSignal:connection.signal];
} completed:^{
@strongify(self);
[self removeActiveExecutionSignal:connection.signal];
}];
[connection connect]; // (4)
return [connection.signal]; // (5)
}
以上是RACCommand執行過程，而RACCommand又是如何對執行過程進行監控的呢？
如上圖所示，RACCommand內部維護了一個activeExecutionSignals數組。上面提到，每當[RACCommand execute:]后，就會將一個執行信號添加到activeExecutionSignals數組中。RACCommand里設置了兩個對activeExecutionSignals的觀察信號。第一個觀察信號用于監控RACCommand是否正在執行，可以參考上圖下端的數據流。activeExecutionSignals是內部執行信號的合集，一旦activeExecutionSignals內部元素發生變化，就會根據執行信號的數量判斷RACCommand當前是否正在執行 (1)。
RACSignal *immediateExecuting = [RACObserve(self, activeExecutionSignals) map:^(NSArray *activeSignals) {
return @(activeSignals.count > 0); // (1)
}];
_executing = [[[[immediateExecuting
deliverOn:RACScheduler.mainThreadScheduler]
startWith:@NO]
distinctUntilChanged]
replayLast];
第二個觀察信號用于監控RACCommand當前正在執行的信號與信號產生的error，可以參考上圖上端數據流。每當activeExecutionSignals有新的執行信號添加進數組，newActiveExecutionSignals就會有相應的信號輸出(信號newActiveExecutionSignals輸出的是信號，因此newActiveExecutionSignals是信號的信號)。由于newActiveExecutionSignals之后需要轉成executionSignals、error信號，并分別被外界訂閱，為避免產生多余的副作用，這里使用publish將activeExecutionSignals對應的觀察信號由冷信號轉成了熱信號（1）。之后executionSignals將newActiveExecutionSignals的輸出值拋送到主線程上 (2)。當我們去訂閱executionSignals信號時，拿到的就是當前正在執行的信號。要是我們關心的是當前執行信號的輸出值，我們得使用 [executionSignals flatten]方法(參考上節的flatten操作)將executionSignals”壓平”后，才可以獲取到所有當前執行信號的輸出值。
RACSignal *newActiveExecutionSignals = [[[[[self
rac_valuesAndChangesForKeyPath:@keypath(self.activeExecutionSignals) options:NSKeyValueObservingOptionNew observer:nil]
reduceEach:^(id _, NSDictionary *change) {
NSArray *signals = change[NSKeyValueChangeNewKey];
return [signals.rac_sequence signalWithScheduler:RACScheduler.immediateScheduler];
}]
concat]
publish] // (1)
autoconnect];
_executionSignals = [[newActiveExecutionSignals
map:^(RACSignal *signal) {
return [signal catchTo:[RACSignal empty]];
}]
deliverOn:RACScheduler.mainThreadScheduler]; // (2)
同時如果執行信號拋出了錯誤，newActiveExecutionSignals通過flattenMap，直接將產生的錯誤包裝成錯誤信號拋往主線程，并通知訂閱者。
RACMulticastConnection *errorsConnection = [[[newActiveExecutionSignals
flattenMap:^(RACSignal *signal) {
return [[signal
ignoreValues]
catch:^(NSError *error) {
return [RACSignal return:error];
}]
deliverOn:RACScheduler.mainThreadScheduler]
publish];
_errors = [errorsConnection.signal setNameWithFormat:@"%@ -errors", self];
[errorsConnection connect];
因此，RACCommand主要是對成員變量activeExecutionSignals數組的變化進行觀察, 并將觀察結果轉變成外部感興趣的信號，從而使得RACCommand的執行過程與結果可被外部監控。我們往往將RACCommand與UI響應配合使用，比如在button被點擊后，去執行一個網絡請求的command。我們可以通過command.executing信號輸出的信號值決定是否彈出小菊花，可以通過command.executionSignals信號獲取當前正在執行的信號，并得到執行結果，也可以從command.error信號中拿到我們需要反饋給用戶的錯誤提示信息，使用起來十分方便。
RACChannel
RACChannel可能相對來說比較陌生，但它也可以在信號流中扮演重要的角色。它提供雙向綁定功能，一個RACChannel的兩端配有RACChannelTerminal，分別是leadingT、 followingT。我們可以將leadingT 與 followingT想象成一根水管的兩頭，只要任何一端輸入信號值，另外一端都會有相同的信號值輸出。有了這個概念下我們再來看看RACChannelTerminal。首先
@interface RACChannelTerminal : RACSignal <RACSubscriber>
可以發現RACChannelTerminal因為繼承了RACSignal， 因此它具有信號的特性，可以被訂閱。比如：在RACChannel中 [leadingT subscribeNext:]，這里leadingT扮演的就是signal的角色，當它被訂閱時輸出的就是followingT送出的值。同時RACChannelTerminal又實現了RACSubscriber的協議。這樣就意味著它又能夠像訂閱者一樣調用sendNext: sendError: sendComplete方法。 如果followingT被訂閱了，那么一旦leadingT sendNext:value，信號值value就會穿過leadingT與followingT，被followingT的訂閱者捕獲到。正是由于RACChannelTerminal擁有這種既可被訂閱，又可主動輸出信號值的屬性，當它被放到RACChannel兩端時，就可讓兩端信號相互影響。
通常我們很少直接使用RACChannel，最常用到的就是RACChannelTo，下面我們來詳細了解下：
借著上面的RACChannelTo的數據流圖，我們拿RAC提供的示例代碼舉例。RACChannelTo宏實際生成了一個RACKVOChannel，RACKVOChannel內部是將其一端的leadingT與相關keypath上的integerProperty綁定，并將其另外一端followingT(對應示例代碼中的integerChannelT)暴露出來。當我們拿到integerChannelT后，使用[integerChannelT sendNext:@“5”] (1)， 信號值就會傳到RACKVOChannel的另一端，影響integerProperty(參考圖中紅色管線)。同時當integerChannelT被訂閱時，只要另一端integerProperty因變化產生了對應信號值A，那么integerChannelT就會將信號值A傳遞給它的訂閱者(參考圖中藍色管線)。
RACChannelTerminal *integerChannelT = RACChannelTo(self, integerProperty, @42);
[integerChannelT sendNext:@5]; // (1)
[integerChannelT subscribeNext:^(id value) { // (2)
NSLog(@"value: %@", value);
}];
事實上，RAC為很多類提供了RACChannel相關的拓展，如
- [NSUserDefaults rac_channelTerminalForKey:]
- [UIDatePicker rac_newDateChannelWithNilValue:]
- [UISegmentedControl rac_newSelectedSegmentIndexChannelWithNilValue:]
- [UISlider rac_newValueChannelWithNilValue:]
- [UITextField rac_newTextChannel:]
這些函數都會返回一個對應的RACChannelTerminal。有了這個RACChannelTerminal，一方面我們可以通過它去觀察對應控件內核心變量的變化情況，并作出響應。另一方面我們也可通過這個RACChannelTerminal直接去改變這個控件里的核心變量。比如我們可以使用[UITextField rac_newTextChannel:]返回的RACChannelTerminal用以下方式實現控件與viewModel中數據的雙向綁定。
RACChannelTerminal *textFieldChannelT = textField.rac_newTextChannel;
RAC(self.viewModel, property) = textFieldChannelT;
[RACObserve(self.viewModel, property) subscribe:textFieldChannelT];
整體而言，RACChannelTerminal用起來十分順手，如果契合業務使用，RACChannel能夠提供非常大的價值。
總結
本文從源碼層面剖析了RAC信號的訂閱過程，了解了RAC核心元素在其中扮演的角色。之后著重介紹了RAC數據流構建與它的使用價值。本文沒有對所有的RAC Operation進行覆蓋性的介紹，而是挑出了幾個重要的Opration，借助源碼與數據流圖介紹其內部運作細節，希望能從底層闡述構建原理，幫助大家更好的理解使用RAC。就如一句老話所說"開車不需要知道離合器是怎么工作的，但如果知道離合器原理，那么車子可以開得更平穩"。
