Rx在一個(gè)項(xiàng)目上實(shí)踐后的總結(jié)：
1、需求，還是要把需求理清野哭；否則就算是Rx也幫不上你
先對(duì)需求做功能分解，每個(gè)子功能之間可以有先后依賴幻件，以及包含關(guān)系拨黔，但功能之間的邏輯必須完全獨(dú)立，不能有依賴傲武、包含關(guān)系蓉驹；
2、Rx vs 傳統(tǒng)
傳統(tǒng)方式（過程式）做好的話揪利，也有上面的分解動(dòng)作态兴，但缺點(diǎn)很明顯，所有需求的實(shí)現(xiàn)都是HardCode疟位，基本上主流程只有一個(gè)瞻润，當(dāng)需求變化時(shí)（現(xiàn)代社會(huì)這是常事），在一處修改代碼實(shí)現(xiàn)了功能甜刻，往往需要在多處修補(bǔ)Bug绍撞，才能不破壞原有的功能，導(dǎo)致該主流程會(huì)越發(fā)臃腫得院，甚至?xí)竭_(dá)不可維護(hù)的地步傻铣；
Rx就是為了解決這個(gè)問題，拋棄了由HardCode實(shí)現(xiàn)功能的方式（此路“最終”不通）祥绞，而是采用聲明式編程（編碼方式為：定義什么情況下要做什么事）非洲，由情況（Event流）來把整個(gè)需求要做的事情串起來。
3蜕径、Rx的正確使用姿勢(shì)
需求理清的基礎(chǔ)上两踏，子功能也都分解成獨(dú)立的了，為每個(gè)子功能定義觸發(fā)的條件兜喻；
然后為該條件定義一個(gè)Observable變量梦染，功能的處理就是該Observable的訂閱（聲明式）；
這些已定義的Observable就是樹的葉子朴皆，還需要找到并定義事件的源頭—即樹的根帕识；
【重點(diǎn)】仔細(xì)設(shè)計(jì)根和葉子之間的關(guān)系，從葉子這端開始回溯遂铡，只要2個(gè)葉子有重復(fù)處理的部分渡冻，就需要新建一個(gè)Observable，并定義為分杈忧便；2個(gè)分杈重復(fù)處理的族吻，再新建定義為父分杈帽借，直到最后該分杈可以單線聯(lián)系到根；
最終達(dá)到：該樹的根到每個(gè)葉子都有且只有一條“唯一路徑”超歌；
剩下就很簡(jiǎn)單砍艾，在葉子Observable上添加訂閱函數(shù)即可。
簡(jiǎn)單來說就是：定義Observable巍举，然后訂閱處理脆荷。
【反例】如果把需求實(shí)現(xiàn)插入到其他地方-如doOnNext，或一個(gè)訂閱處理了多個(gè)邏輯懊悯，就會(huì)造成邏輯混亂蜓谋，和傳統(tǒng)方式（過程式）面臨的問題一樣，而且還會(huì)更糟炭分。
反模式太多桃焕，可以認(rèn)為除了這條最佳實(shí)踐外的都存在反模式嫌疑，且了解價(jià)值不大捧毛，遂略去观堂。
