これは非常に良い質問です。2つの世界を比較することは非常に困難です。Rxは、C＃、Java、JSなどの他の言語のReactive Extensionsの移植版です。
Reactive Cocoaは、Functional Reactive Programmingに触発されましたが、ここ数か月間、Reactive Extensionsにも触発されたと指摘されています。結果は、Rxといくつかのものを共有するフレームワークですが、FRPに起源を持つ名前があります。
Conalの概念の定義によれば、最初に言うべきことは、RACもRxSwiftも機能的リアクティブプログラミング実装ではないということです。この時点から、各フレームワークが副作用や他のいくつかのコンポーネントを処理する方法にすべてを削減できます。
コミュニティとメタテック関連のものについて話しましょう：
- RACは3年前のプロジェクトで、Objective-Cで進行中の作業を完全に削除した後、Objective-Cで3.0リリース用に（ブリッジ付きで）Swiftに移植されました。
- RxSwiftは数か月前のプロジェクトで、現在コミュニティーに勢いがあるようです。RxSwiftにとって重要なことの1つは、ReactiveX組織の下にあり、他のすべての実装が同じように機能していることです。RxSwiftを処理する方法を学ぶことで、Rx.Net、RxJava、またはRxJSでの作業が簡単なタスクになり、問題になります。言語構文の。それは一度学んだ哲学に基づいていると言えるでしょう。
さあ、技術系の時間です。
エンティティの作成/監視
RAC 3.0には2つの主要エンティティがSignalありSignalProducer、最初のエンティティはサブスクライバが接続されているかどうかに関係なくイベントをパブリッシュし、2番目のエンティティはstart実際に信号/イベントを生成するために必要です。この設計は、多くの開発者にとって混乱の元となってきた、ホットとコールドのオブザーバブルの面倒な概念を分離するために作成されました。これが、副作用をどのように管理するかという違いを減らすことができる理由です。
RxSwiftではSignal、にSignalProducer変換するObservableと混乱を招くように聞こえるかもしれませんが、これら2つのエンティティは実際にはRxの世界では同じものです。ObservableRxSwiftにsが含まれるデザインは、それらが高温か低温かを考慮して作成する必要がありますが、不必要な複雑さとして聞こえるかもしれませんが、それらがどのように機能するかを理解したら（また、高温/低温/高温は、サブスクライブ/監視中の副作用にすぎません） ）彼らは飼いならすことができます。
両方の世界では、サブスクリプションの概念は、RACが導入されていることを一つの小さな違いがあります、基本的に同じであるinterruptionイベントSignal終了イベントが送信される前に配置されているが。まとめると、次のようなイベントがあります。
Next、新しい受信値を計算するError、エラーを計算してストリームを完成させ、すべてのオブザーバーの登録を解除しますComplete、ストリームに完了のマークを付け、すべてのオブザーバの登録を解除します
さらに、RACは、正しくまたはエラーで完了する前にが破棄さinterruptedれたときに送信Signalされます。
手動で書く
RACでは、Signal/ SignalProducerは読み取り専用のエンティティであり、外部から管理することはできませんObservable。RxSwiftの場合と同じです。有効にするにはSignal/をSignalProducer書き込み可能エンティティに、あなたが使用する必要がpipe()手動で制御項目を返す関数を。Rxスペースでは、これはと呼ばれる別のタイプSubjectです。
読み取り/書き込みコンセプト音が不慣れな場合は、との素敵なアナロジーFuture/をPromise行うことができます。A FutureはSignal/ SignalProducerやのような読み取り専用のプレースホルダーです。Observable一方、はPromisefor pipe()やのように手動で実行できますSubject。
スケジューラー
このエンティティは両方の世界でほとんど同じ概念ですが、RACはシリアルのみであり、代わりにRxSwiftは同時スケジューラも備えています。
組成
コンポジションは、リアクティブプログラミングの重要な機能です。ストリームを構成することは、両方のフレームワークの本質であり、RxSwiftでは、それらはシーケンスとも呼ばれます。
RxSwiftのすべての観測可能なエンティティは型であるObservableTypeので、我々はのインスタンスを構成するSubjectと、Observable余分な心配せずに、同じ事業者とします。
RAC空間上、SignalおよびSignalProducer2つの異なる実体であると我々が持っているlift上SignalProducerのインスタンスで生成されるものを構成することができるようにSignal。2つのエンティティには独自の演算子があるため、物事を混合する必要がある場合は、特定の演算子が使用可能であることを確認する必要があります。反対側では、ホット/コールドオブザーバブルを忘れます。
この部分について、コリン・エバーハートはそれをうまくまとめました：
現在のAPIを見ると、信号操作は主に「次の」イベントに焦点が当てられているため、値を変換したり、スキップしたり、遅延させたり、組み合わせたり、さまざまなスレッドで監視したりできます。一方、シグナルプロデューサーAPIは、then、flatMap、takeUntil、catchなどの操作を伴うシグナルライフサイクルイベント（完了、エラー）に主に関係しています。
追加
RACにはの概念もActionありますProperty。前者は主にユーザーの操作に関連する副作用を計算するタイプで、後者は値を監視して値が変更されたときにタスクを実行する場合に役立ちます。RxSwiftでは、Actionは再びに変換されますObservable。これはRxCocoa、iOSとMacの両方のRxプリミティブの統合であるによく示されています。RAC はRxSwiftで（または）にProperty変換できます。VariableBehaviourSubject
Property/ Variableは、必須の世界をリアクティブプログラミングの宣言的な性質に橋渡しするための方法であることを理解することが重要です。そのため、サードパーティのライブラリやiOS / Macスペースのコア機能を処理するときに、基本的なコンポーネントになることがあります。
結論
RACとRxSwiftは2つの完全に異なる獣であり、前者はCocoaスペースで長い歴史を持ち、多くの貢献者がいます、後者はかなり若いですが、Java、JS、または他の言語で効果的であることが証明されている概念に依存しています。ネット。どちらがより良いかの決定は好みにあります。RACは、ホット/コールドオブザーバブルの分離が必要であり、それがフレームワークのコア機能であると述べています。RxSwiftは、それらの統合は分離よりも優れていると言います。ここでも、副作用の管理/実行の方法についてです。
RAC 3.0は、割り込みの概念、2つのエンティティ間で演算子を分割startし、信号の生成を開始するなどのいくつかの命令的な動作を導入するなど、ホット/コールドオブザーバブルを分離するという主要な目標に加えて、予期しない複雑さを導入したようです。一部の人々にとっては、これらのことは素晴らしいことであり、キラー機能でさえあるかもしれませんし、一部の人々にとっては、それらは単に不必要であるか、あるいは危険でさえあるかもしれません。覚えておくべきもう一つは、そのRACを使用すると、経験豊富なココアのDevをしているそうだとすれば、あなたは、可能な限りのCocoaの規約に追いつくためにしようとしているされなければならないことではなく、RxSwiftとの仕事に、より快適に感じます。
一方、RxSwiftは、ホット/コールドオブザーバブルなどのすべてのマイナス面だけでなく、Reactive Extensionsの良い点も備えています。RxJS、RxJava、またはRx.NetからRxSwiftへの移行は簡単なことであり、すべての概念は同じであるため、これにより資料がかなり興味深いものになり、おそらく現在直面しているのと同じ問題がRxJavaとソリューションで解決されましたプラットフォームを考慮して再適用できます。
どちらを選ぶ必要があるかは、間違いなく好みの問題であり、客観的な観点から、どちらが優れているかを判断することは不可能です。唯一の方法は、Xcodeを起動して両方を試し、より快適に操作できる方法を選択することです。これらは、同じ目的を達成しようとする、同様の概念の2つの実装です。ソフトウェア開発の簡素化です。