理解響應式程式設計

我們先來聊一聊響應式的由來，對於它的由來，我們可能需要先從一段常見的**片段看起

int a=1;
int b=a+1;
system.out.print(「b=」+b) // b=2
a=10;
system.out.print(「b=」+b) // b=2

上面是一段很常見的**，簡單的賦值列印語句，但是這種**有乙個缺陷，那就是如果我們想表達的並不是乙個賦值動作，而是b和a之間的關係,即無論a如何變化，b永遠比a大1。那麼可以想見，我們就需要花額外的精力去構建和維護乙個b和a的關係。

而響應式程式設計的想法正是企圖用某種操作符幫助你構建這種關係。

它的思想完全可以用下面的**片段來表達：

int a=1;
int b <= a+1; // <= 符號只是表示a和b之間關係的操作符
system.out.print(「b=」+b) // b=2
a=10;
system.out.print(「b=」+b) // b=11

這就是是響應式的思想，它希望有某種方式能夠構建關係，而不是執行某種賦值命令。

說回響應式，前期由於真實的程式設計環境中並沒有構建關係的操作符，主流的程式語言並不支援這種構建關係的方式，所以一開始響應式主要停留在想的層面，直到出現了rx和一些其他支援這種思想的框架,才真正把響應式程式設計引入到了實際的**開發中。

rx是響應式拓展，即支援響應式程式設計的一種拓展,為響應式在不同語言中的實現提供指導思想

說完了了響應式的由來，我們就可以談談什麼是響應式程式設計了。

事物的關係

關於rx的資料流有很多說法，比如「everything is a stream」,「thinking with stream」等等。雖然我明白這只是想強調流的重要性，可是這些話折射出來的程式設計思路其實是很虛無縹緲的，只會讓開發者對於rx程式設計更加迷惑。

實際上，資料流只是事物之間溝通的橋梁。

但是，只有資料流是不能完全正確的構建出事物之間的關係的。我們依然需要非同步程式設計。

非同步程式設計本身是有很多優點的，比如挖掘多核心cpu的能力，提高效率，降低延遲和阻塞等等。但實際上，非同步程式設計也給我們構建事物的關係提供了幫助。

總的來說，非同步和資料流都是為了正確的構建事物的關係而存在的。只不過，非同步是為了區分出無關的事物，而資料流（事件流）是為了聯絡起有關的事物。

observable.just(context)
.map((context)->)
.map((context)->)
.map((context)->)
.subscribeon(schedulers.newthread())
.subscribe((context)->)

其實，這種寫法並不是響應式的，本質上還是建立乙個子執行緒，然後順序呼叫**最後跳轉頁面。這種**依然沒有忠實反映業務之間的關係。

在我心目中，響應式的**應該是這樣的

observable obserinitsdk=observable.create((context)->).subscribeon(schedulers.newthread())
observable obserinitdb=observable.create((context)->).subscribeon(schedulers.newthread())
observable obserlogin=observable.create((context)->)
.map((islogin)->)
.subscribeon(schedulers.newthread())
observable observable = observable.merge(obserinitsdk,obserinitdb,obserlogin)
observable.subscribe(()->)

大家應該能很明顯看到兩段**的區別，第二段**完全遵照了業務之間客觀存在的關係，可以說**和業務關係是完全對應的。

那麼這帶來了什麼好處呢？當initsdk，initdb,login都是耗時較長的操作時，遵照業務關係編寫響應式**可以極大的提高程式的執行效率，降低阻塞。

理論上講，遵照業務關係執行的**在執行效率上是最優的。

根據個人經驗來看，響應式程式設計至少有如下好處：

接下來，我就以我們團隊目前的一款產品的頁面為例，詳細點介紹運用響應式程式設計的正確姿勢。

首先，ui和產品溝通後，可能會給我們這樣的設計圖（加上一些尺寸的標註）。但是我們並不需要急忙編碼，我們首先要做的是區分其中相對獨立的模組。

構建了業務之間的關係圖，其實我們的工作已經完成了一半了，接下來就是用**實現這個關係圖。在這裡，我就以其中一小段業務關係來編寫**給大家示範。

以上是我手寫的偽**，可能細節上有些問題，但大體思路就是這樣。

有人可能會說，那是因為你運用操作符比較熟練才能這麼寫。其實操作符都是我查的，我記不住那麼多操作符，所以基本上我都是先理清楚業務之間的關係，需要和並邏輯的時候，就去去查合併類的操作符，需要條件判斷來分流的邏輯時去找條件判斷類的操作符。基本上都能滿足需求。你瞧，寫**就是這麼簡單，後續即使需要增加需求，**修改起來也很清晰，因為無關的業務已經被你分離好了。

所以，趕緊在你的專案中引入響應式程式設計吧！

理解響應式程式設計

響應式程式設計什麼是響應式程式設計

響應式程式設計

響應式程式設計（一）什麼是響應式程式設計

理解響應式程式設計

響應式程式設計 什麼是響應式程式設計

響應式程式設計

響應式程式設計（一）什麼是響應式程式設計

相關推薦

響應式程式設計什麼是響應式程式設計