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:
1234567891011RACSignal *pipeline = [RACSignal createSignal:^RACDisposable*(id 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:
1RACSubscriber *worker = [RACSubscriber subscriberWithNext:nextBlock error:errorBlock completed:completedBlock];
Subscriber我們一般稱之為訂閱者，它負責處理Signal傳出的資料。Subscriber初始化的時候會傳入nextBlock、 errorBlock、completeBlock，正是這三個block用於處理不同型別的資料訊號（或是將處理後的資料拋往下一段管線，或是當做成品送給使用方）。Subscriber好比是管線上的工人，負責加工管線上傳遞過來的各種訊號值，不過一旦Subscriber接收到error訊號或complete訊號，Subscriber會通過相關的RACDisposal主動取消這次訂閱，停止管線的運作。那麼管線有了，管線上的裝配工人有了，如何啟動管線? - 啟動管線 － subscribe：
1RACDisposable *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: subcriber]統一封裝到[signal subscribeNext: error: completed:]方法中了，如下圖所示。這種封裝成功遮蔽掉了Subscriber這個概念，進一步簡化訊號的訂閱邏輯，使其更加便於使用。（PS：流水線worker永遠都在默默付出！！）
可以發現，按照上面的訂閱流程，訊號只有被訂閱時才會送出訊號值，這種訊號我們稱之為冷訊號(cold signal)。既然有冷訊號的概念，就肯定有與之對應的熱訊號(hot signal)。冷訊號好比只有給管線分配工人後，管線才會開啟。而熱訊號就是在管線建立之後，不管是否有配套的工人，管線都會開始運作，可以隨時根據外部條件送出資料。送出資料時，如果管線上有工人，資料被工人加工處理，如果沒有工人，資料將被拋棄。以下我們仍然從訊號的訂閱步驟對比冷熱訊號:（熱訊號對應的類RACSubject）
- 建立訊號。與冷訊號不同，RACSubject在被建立後將維護一個訂閱者陣列（subscribers)，用於隨時儲存加入進來的Subscriber。此外不同於RACDynamicSignal，RACSubject在建立時並不去設定好要輸出資料，而是通過實現協議，允許外部直接使用[RACSubject sendNext:]隨時輸出資料。
- 建立訂閱者。該建立過程與冷訊號完成相同，都是提前準備好Subscriber對應的nextBlock、errorBlock、completedBlock。
1RACSubscriber *worker = [RACSubscriber subscriberWithNext:nextBlock error:errorBlock completed:completedBlock];
- 訂閱。RACSubject(hotSignal)與RACDynamicSignal(coldSignal)內部都有繼承於父類RACSignal的subscribe方法，但實現卻完全不同。RACDynamicSignal的subscribe會去執行createSignal時準備好的didSubscribedBlock，同時將subscriber傳給didSubscribedBlock，讓subscriber按照設定好的方式處理相應的資料值。 而熱訊號RACSubject僅僅只是將subscriber加入到訂閱者陣列中，其它啥事不幹。
- 熱訊號沒有提前規劃訂閱時訊號的輸出，因而它需要由外部來控制訊號何時輸出何種資料值，於是RACSubject實現了協議，向外提供了[RACSubject sendNext:]、[RACSubject sendError:]、[RACSubject sendComplete:]方法。以sendNext舉例，每當使用 [RACSubject sendNext] 時，RACSubject就會遍歷一遍自己的subcribers陣列，並呼叫各陣列元素(subscriber)準備好的sendNextBlock (1)。
|
1 2 3 4 5 |
- (void)sendNext:(id)value { [self enumerateSubscribersUsingBlock:^(id 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), 如上圖所示。
12345678910111213141516171819202122232425261. (RACSignal *)bind:(RACStreamBindBlock (^)(void))block {return [RACSignal createSignal:^(id 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。
12345678910111213- (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結果的目的。
|
1 2 3 4 5 6 7 8 |
- (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程式碼如下：
|
1 2 3 4 5 6 |
- (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派送出來的最新訊號。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
- (RACSignal*)switchToLatest { return [RACSignal createSignal:^(id 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程式碼如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
- (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程式碼:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[[[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 funtional, more elegant”。可以毫不誇張的說，阻礙RAC發揮的瓶頸只有想象力，當我們接到需求後，仔細推敲資料的走向並設計好相關資料的操作，只要RAC資料流圖繪製出來，剩下的程式碼工作也就信手拈來。介紹完RAC資料流後，我們再從資料流的角度看看RAC中的另外兩個常用元素RACCommand與RACChannel。
RACCommand
RACCommand是RAC很重要的組成部分，通常用來表示某個action的執行。RACCommand提供excutingSignals、 excuting、 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)。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
- (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 excute:]後，就會將一個執行訊號新增到activeExecutionSignals陣列中。RACCommand裡設定了兩個對activeExecutionSignals的觀察訊號。第一個觀察訊號用於監控RACCommand是否正在執行，可以參考上圖下端的資料流。activeExecutionSignals是內部執行訊號的合集，一旦activeExecutionSignals內部元素髮生變化，就會根據執行訊號的數量判斷RACCommand當前是否正在執行 (1)。
|
1 2 3 4 5 6 7 8 9 |
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”壓平”後，才可以獲取到所有當前執行訊號的輸出值。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
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.excuting訊號輸出的訊號值決定是否彈出小菊花，可以通過command.excutingSignals訊號獲取當前正在執行的訊號，並得到執行結果，也可以從command.error訊號中拿到我們需要提示給使用者的錯誤資訊，使用起來十分方便。
RACChannel
RACChannel可能相對來說比較陌生，但它也可以在訊號流中扮演重要的角色。它提供雙向繫結功能，一個RACChannel的兩端配有RACChannelTerminal，分別是leadingT、 followingT。我們可以將leadingT 與 followingT想象成一根水管的兩頭，只要任何一端輸入訊號值，另外一端都會有相同的訊號值輸出。有了這個概念下我們再來看看RACChannelTerminal。首先
|
1 |
@interface RACChannelTerminal : RACSignal |
可以發現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傳遞給它的訂閱者(參考圖中藍色管線)。
|
1 2 3 4 5 6 |
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中資料的雙向繫結。
|
1 2 3 |
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。就如一句老話所說”開車不需要知道離合器是怎麼工作的，但如果知道離合器原理，那麼車子可以開得更平穩”。