CombineRxSwiftPerformance 是一個在 GitHub 知名的專案, 在 wwdc 2019 剛發表 Combine 的時候, 這個 repo 就已經存在了.
GitHub repo: https://github.com/quickbirdstudios/CombineRxSwiftPerformance
CombineRxSwiftPerformance 在介紹 RxSwift 與 Combine 之間的效能差異, 並在 Blog: Should you switch to Combine? 介紹 Combine 的差異, 對於原本就知曉 ReactiveX 的人來說, 是一邊很有幫助的文章; 對於第一次接觸響應式編程的朋友, 這邊可以是一邊講古的文章, 尤其是在 ReactiveX 在 RxJava, RxJS... 都有實作, 若是未來有機會接觸不同程式語言, 這部分的歷史是不可不知的知識.
ReativeX 源自於 FRP(Function Reactive Programming), 在 OOP當道的現在, 有所謂的 Observe design pattern, delegate, callBack等等方法, 因此常會有狀態轉變與 UI 變化的顧慮. 在 Apple 生態係下, MVC 架構時常會用 MVVM 取代.
Back-pressure 是在 zip
常出現的一個情形, 尤其在上游的發生頻率差異大的時候, 而 RxSwift 在這部分沒有很好的處理, Combine 使用 Demand 的方式就可以處理, 在這部分就有一些分水嶺出現了.
在 blog 中有提到, Combine 的出現讓更多人知道 RxSwift 的存在, 由於 Combine 擁有 iOS SDK 的最低限制, 因此 RxSwift 會是目前(2019 年) MVVM 的首選, 但是隨著 iOS 版本的更迭, 相信 Combine 將是 Swift 的中流砥柱!
Back-pressure應該是指當上游產生速度過快而下游來不及消耗產生的溢出 跟是不是用zip沒太大關係 例如我有一個timer每五秒產生一個訊號 但是我處理要花五秒以上 就會產生溢出
不過我沒試過RxSwift是會crash還是直接ignore溢出的訊號
Back-pressure 在單一上游時是這樣沒錯的! 我沒有實際使用 RxSwift,感謝分享!
而 zip 會有事件訊號堆積的情形是上游發布的頻率差異過大,慢的上游的時間更新延遲會影響快的上游的最新事件的迴響時間點,這部分可以用接受慢的上游更新的次數限定,來捨棄快的上游已產生的訊號堆積!
其實這樣沒有處理到上面我說的問題 你處理時間大於訊號產生的時間就會GG 假設我zip不管幾個上游最後綜合結果也是每五秒送一個訊號 我下游處理要超過五秒就會溢出