1.ReactiveCocoa是什么误趴？
ReactiveCocoa（簡(jiǎn)稱為RAC）,是由Github開源的一個(gè)應(yīng)用于iOS和OS開發(fā)的新框架,Cocoa是蘋果整套框架的簡(jiǎn)稱变隔，是一套基于Cocoa的FRP框架即函數(shù)響應(yīng)式響應(yīng)式編程哼转，其優(yōu)點(diǎn)是用隨時(shí)間改變的函數(shù)表示用戶輸入沮峡，這樣就不需要可變狀態(tài)了吮旅。。
2.導(dǎo)入ReactiveCocoa框架
這里使用CocoaPods來(lái)導(dǎo)入
打開終端萍鲸，進(jìn)入工程文件的同級(jí)目錄
新建一個(gè)profile文件或在原來(lái)的該文件上闷叉，輸入以下內(nèi)容并保存
use_frameworks!
pod 'ReactiveCocoa', '~> 2.5'
3.什么是冷信號(hào)與熱信號(hào)
冷熱信號(hào)的概念源于.NET框架Reactive Extensions(RX)中的Hot Observable和Cold Observable，兩者的區(qū)別是：
3.1 Hot Observable是主動(dòng)的脊阴，盡管你并沒(méi)有訂閱事件握侧，但是它會(huì)時(shí)刻推送，就像鼠標(biāo)移動(dòng)嘿期；而Cold Observable是被動(dòng)的品擎，只有當(dāng)你訂閱的時(shí)候，它才會(huì)發(fā)布消息备徐。
3.2 Hot Observable可以有多個(gè)訂閱者萄传，是一對(duì)多，集合可以與訂閱者共享信息蜜猾；而Cold Observable只能一對(duì)一秀菱，當(dāng)有不同的訂閱者，消息是重新完整發(fā)送蹭睡。
這里面的Observables可以理解為RACSignal衍菱。
以上簡(jiǎn)單地創(chuàng)建了一個(gè)信號(hào)，并且依次發(fā)送@1肩豁，@2脊串，@3作為值。下面分別有兩個(gè)訂閱者在不同的時(shí)間段進(jìn)行了訂閱清钥，運(yùn)行的結(jié)果如下：
2015-08-25 17:14:21.338 MVVM[3083:94636] Signal was create.
2015-08-25 17:14:21.440 MVVM[3083:94636] Subcriber 1 reveive: 1
2015-08-25 17:14:21.441 MVVM[3083:94636] Subcriber 1 reveive: 2
2015-08-25 17:14:21.441 MVVM[3083:94636] Subcriber 1 reveive: 3
2015-08-25 17:14:22.435 MVVM[3083:94636] Subcriber 2 reveive: 1
2015-08-25 17:14:22.436 MVVM[3083:94636] Subcriber 2 reveive: 2
2015-08-25 17:14:22.436 MVVM[3083:94636] Subcriber 2 reveive: 3
例外修改下代碼如下
2015-08-25 17:23:46.418 MVVM[3232:100902] Signal was created.
2015-08-25 17:23:48.512 MVVM[3232:100902] Subcriber 1 receive: 2
2015-08-25 17:23:49.625 MVVM[3232:100902] Subcriber 1 receive: 3
2015-08-25 17:23:49.625 MVVM[3232:100902] Subscriber 2 recveive: 3
上面代碼
1.我創(chuàng)建了一個(gè)信號(hào)琼锋，在1秒、2秒循捺、3秒分別發(fā)送1斩例、2、3這三個(gè)值从橘，4秒發(fā)送結(jié)束信號(hào)。
2.對(duì)這個(gè)信號(hào)調(diào)用publish方法得到一個(gè)RACMulticastConnection础钠。
3.讓connection進(jìn)行連接操作恰力。
4.獲得connection的信號(hào)。
5.分別在1.1秒和2.1秒訂閱獲得的信號(hào)旗吁。
首先- [RACSignal publish]踩萎、- [RACMulticastConnection connect]、- [RACMulticastConnection signal]這幾個(gè)操作生成了一個(gè)熱信號(hào)很钓。
冷熱信號(hào)的如下特點(diǎn)：
1.熱信號(hào)是主動(dòng)的香府，即使你沒(méi)有訂閱事件董栽，它仍然會(huì)時(shí)刻推送。如第二個(gè)例子企孩，信號(hào)在46秒被創(chuàng)建锭碳，47秒的時(shí)候1這個(gè)值就推送出來(lái)了，但是當(dāng)時(shí)還沒(méi)有訂閱者勿璃。而冷信號(hào)是被動(dòng)的擒抛，只有當(dāng)你訂閱的時(shí)候，它才會(huì)發(fā)送消息补疑。如第一個(gè)例子歧沪。
2.熱信號(hào)可以有多個(gè)訂閱者，是一對(duì)多莲组，信號(hào)可以與訂閱者共享信息诊胞。如第二個(gè)例子，訂閱者1和訂閱者2是共享的锹杈，他們都能在同一時(shí)間接收到3這個(gè)值撵孤。而冷信號(hào)只能一對(duì)一，當(dāng)有不同的訂閱者嬉橙，消息會(huì)重新完整發(fā)送早直。如第一個(gè)例子，我們可以觀察到兩個(gè)訂閱者沒(méi)有聯(lián)系市框，都是基于各自的訂閱時(shí)間開始接收消息的霞扬。
4.為什么要區(qū)分冷熱信號(hào)
我們來(lái)分析副作用與冷熱信號(hào)的關(guān)系。既然iOS編程中少不了副作用枫振，那么RAC在實(shí)際的使用中也不可避免地要接觸副作用喻圃。下面通過(guò)一個(gè)業(yè)務(wù)場(chǎng)景，來(lái)看看冷信號(hào)中副作用的坑：
如果你去嘗試運(yùn)行這段代碼粪滤，你會(huì)驚奇的發(fā)現(xiàn)斧拍，這個(gè)網(wǎng)絡(luò)請(qǐng)求發(fā)送了3次。沒(méi)錯(cuò)杖小，是3次請(qǐng)求肆汹。我們也可以想象到類似的代碼存在其他副作用的問(wèn)題，重新刷新了3次tableView予权。
下面來(lái)分析昂勉，為什么是3次網(wǎng)絡(luò)請(qǐng)求呢？首先根據(jù)上面的知識(shí)扫腺，可以推斷出名為fetchData信號(hào)是一個(gè)冷信號(hào)岗照。那么這個(gè)信號(hào)在訂閱的時(shí)候就會(huì)執(zhí)行里面的過(guò)程。那這個(gè)信號(hào)是在什么時(shí)候被訂閱了呢？仔細(xì)回看了代碼攒至，我們發(fā)現(xiàn)并沒(méi)有訂閱這個(gè)信號(hào)厚者，只是調(diào)用這個(gè)信號(hào)的flattenMap產(chǎn)生了兩個(gè)新的信號(hào)。
這里有一個(gè)很重要的概念迫吐，就是任何的信號(hào)轉(zhuǎn)換即是對(duì)原有的信號(hào)進(jìn)行訂閱從而產(chǎn)生新的信號(hào)库菲。
導(dǎo)致3次網(wǎng)絡(luò)請(qǐng)求的原因就是flattenMap中會(huì)對(duì)原有的fetchData信號(hào)進(jìn)行訂閱。
由此可以看到渠抹，不熟悉冷熱信號(hào)對(duì)業(yè)務(wù)造成的影響蝙昙。我們可以想象對(duì)用戶流量的影響，對(duì)服務(wù)器負(fù)載的影響梧却，對(duì)統(tǒng)計(jì)的影響奇颠，如果這是一個(gè)點(diǎn)贊的接口，會(huì)不會(huì)造成多次點(diǎn)贊放航？后果不堪設(shè)想啊烈拒。而這些都可以通過(guò)將fetchData轉(zhuǎn)換為熱信號(hào)來(lái)解決。
5.怎么處理冷信號(hào)與熱信號(hào)
待續(xù)广鳍。荆几。。
