概述

ReactiveCocoa（以下簡稱“RAC”）是一個函數響應式編程框架，它能讓我們脫離Cocoa API的束縛，給我們提供另外一套編碼的思路與可能性，它能在宏觀層面上提升代碼易讀性與穩定性，讓程序員寫出富有“詩意”的代碼，因此倍受業內推崇。本文略過RAC基本概念與基礎使用（有些技術點可以參考美團點評技術博客之前的幾篇文章：RACSignal，冷信號與熱信號系列，內存洩漏。），著重介紹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的完整訂閱過程：

• 管線的設計－createSignal:

RACSignal *pipeline = [RACSignal createSignal:^RACDisposable*(idsubscriber) {
    [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在創建時並不去設定要輸出的數據，而是通過實現協議，允許外部直接使用[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實現了協議，向外提供了[RACSubject sendNext:]、[RACSubject sendError:]、[RACSubject sendComplete:]方法。以sendNext舉例，每當使用 [RACSubject sendNext] 時，RACSubject就會遍歷一遍自己的subscribers數組，並調用各數組元素(subscriber)准備好的sendNextBlock (1)。

- (void)sendNext:(id)value 
{
    [self enumerateSubscribersUsingBlock:^(idsubscriber) {
        [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：

(1) bind函數會返回一個新的信號N。整體思路是對原信號O進行訂閱，每當信號O產生一個值就將其轉變成一個中間信號M，並馬上訂閱M, 之後將信號M的輸出作為新信號N的輸出。管線圖如下:

具體來看源碼（為方便理解，去掉了源代碼中RACDisposable, @synchronized, @autoreleasepool相關代碼)。當新信號N被外部訂閱時，會進入信號N 的didSubscribeBlock(1處)，之後訂閱原信號O (2)，當原信號O有值輸出後就用bind函數傳入的bindBlock將其變換成中間信號M (3), 並馬上對其進行訂閱(4)，最後將中間信號M的輸出作為新信號N的輸出 (5), 如上圖所示。可以說ReactiveCocoa是根據 Monad 的概念搭建起來的，而bind函數是monad的重要實現函數。

- (RACSignal *)bind:(RACStreamBindBlock (^)(void))block {
    return [RACSignal createSignal:^(idsubscriber) { // (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輸出值的集合。

(2) 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;
        };
    }];
}

(3) 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)
    };
}

(4) flatten: 該操作主要作用於信號的信號。原信號O作為信號的信號，在被訂閱時輸出的數據必然也是個信號(signalValue)，這往往不是我們想要的。當我們執行[O flatten]操作時，因為flatten內部調用了flattenMap (1)，flattenMap裡對應的中間信號就是原信號O輸出signalValue (2)。按照之前分析的經驗，在flattenMap操作中新信號N輸出的結果就是各中間信號M輸出的集合。因此在flatten操作中新信號N被訂閱時輸出的值就是原信號O的各個子信號輸出值的集合。這好比將多管線匯聚成單管線，將原信號壓平(flatten)，如下圖所示。

代碼如下：

- (instancetype)flatten
{
    return [self flattenMap:^(RACSignal *signalValue) { // (1)
        return [signalValue]; // (2)
    };
}

(5) switchToLatest：與flatten相同，其主要目的也是用於"壓平"信號的信號。但與flatten不同的是，flatten是在多管線匯聚後，將原信號O的各子信號輸出作為新信號N的輸出，但switchToLatest僅僅只是將O輸出的最新信號L的輸出作為N的輸出。用管線圖表示如下：

看下代碼，當O送出信號A後，新信號N會馬上訂閱信號A ，但這裡用了[A takeUntile O] (1) 。這裡的意思就是如果之後原始信號O又送出子信號B，那麼之前新信號N對於中間信號A的訂閱也就停止了, 如果O又送出子信號C, 那麼N又會停止對B的訂閱。也就是說信號N訂閱的永遠都是O派送出來的最新信號。

- (RACSignal*)switchToLatest 
{
    return [RACSignal createSignal:^(idsubscriber) {
        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:^{
        }];
    }];
}

另外作為鋪墊，這裡再提兩個操作:

(6) scanWithStart : 該操作可將上次reduceBlock處理後輸出的結果作為參數，傳入當次reduceBlock操作，往往用於信號輸出值的聚合處理。scanWithStart內部仍然用到了核心操作bind。它會在bindBlock中對value進行操作，同時將上次操作得到的結果running作為參數帶入 (1)，一旦本次reduceBlock執行完，就將結果保存在running中，以便下次處理時使用，最後再將本次得出的結果用信號包裝後，傳遞出去 (2)。

代碼如下:

- (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)
        };
    }];
}

(7) throttle:這個操作接收一個時間間隔interval作為參數，如果Signal發出的next事件之後interval時間內不再發出next事件，那麼它返回的Signal會將這個next事件發出。也就是說，這個方法會將發送比較頻繁的next事件捨棄，只保留一段“靜默”時間之前的那個next事件。這個操作常用於處理輸入框等信號(用戶打字很快)，因為它只保留用戶最後輸入的文字並返回一個新的Signal，將最後的文字作為next事件參數發出。管線流圖表示如下:

前面從代碼層面具體剖析了幾個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

可以發現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。就如一句老話所說"開車不需要知道離合器是怎麼工作的，但如果知道離合器原理，那麼車子可以開得更平穩"。