RxJava
v3.1.9
RXJAVAは、反応性拡張機能のJava VM実装です。観察可能なシーケンスを使用して、非同期およびイベントベースのプログラムを作成するためのライブラリです。
観察者パターンを拡張して、データ/イベントのシーケンスをサポートし、低レベルのスレッド、同期、スレッド安全性、同時データ構造などに関する懸念を抽象化しながら、シーケンスを宣言的に一緒に構成できるオペレーターを追加します。
Wiki HomeでRXJava全般の詳細をご覧ください。
2.xからアップグレードする際の変更と移行情報の詳細については、3.0の違いをお読みください。
2.xバージョンは、2021年2月28日現在の終了です。さらなる開発、サポート、メンテナンス、PRS、更新は行われません。最後のバージョンのJavadoc 2.2.21は、アクセス可能なままになります。
1.xバージョンは、2018年3月31日現在の終末期です。さらなる開発、サポート、メンテナンス、PRS、更新は行われません。最後のバージョンのJavadoc 1.3.8は、アクセス可能なままになります。
最初のステップは、Gradle Compileの依存関係として、RXJava 3をプロジェクトに含めることです。
implementation " io.reactivex.rxjava3:rxjava:3.x.y " （ xとy最新のバージョン番号に置き換えてください：）
2つ目は、 Hello Worldプログラムを作成することです。
package rxjava . examples ;
import io . reactivex . rxjava3 . core .*;
public class HelloWorld {
public static void main ( String [] args ) {
Flowable . just ( "Hello world" ). subscribe ( System . out :: println );
}
} RXJAVA 3コンポーネントは、 io.reactivex.rxjava3およびio.reactivex.rxjava3.coreの下に住む基本クラスとインターフェイスの下に住んでいることに注意してください。
RXJAVA 3は、オペレーターを見つけることができるいくつかの基本クラスを備えています。
io.reactivex.rxjava3.core.Flowable ：0..nフロー、リアクティブストリームと逆圧力をサポートしますio.reactivex.rxjava3.core.Observable ：0..nフロー、バックプレッシャーなし、io.reactivex.rxjava3.core.Single ：正確に1つのアイテムまたはエラーのフロー、io.reactivex.rxjava3.core.Completable ：アイテムのないフローが完了またはエラー信号のみ、io.reactivex.rxjava3.core.Maybe ：アイテムなし、正確に1つのアイテムまたはエラーがないフロー。RXJavaのデータフローは、ソース、ゼロ以上の中間ステップに続くデータ消費者またはコンビネーターステップ（ステップがデータフローを消費する責任がある場合）で構成されています。
source . operator1 (). operator2 (). operator3 (). subscribe ( consumer );
source . flatMap ( value -> source . operator1 (). operator2 (). operator3 ());ここで、 operator2で自分自身を想像する場合、ソースに向かって左に目を向けることは上流と呼ばれます。サブスクライバー/消費者に向かって右に目を向けることは、下流と呼ばれます。これは、各要素が別の行に書かれている場合に、しばしばより明白です。
source
. operator1 ()
. operator2 ()
. operator3 ()
. subscribe ( consumer )RXJavaのドキュメントでは、排出、放出、アイテム、イベント、信号、データ、およびメッセージが同義語と見なされ、データフローに沿って移動するオブジェクトを表します。
データフローが非同期ステップを実行すると、各ステップは異なる速度で異なるものを実行する場合があります。通常、一時的なバッファリングやデータのスキップ/ドロップの必要性によるメモリ使用量の増加として現れるようなステップの圧倒を避けるために、いわゆるバックプレッシャーが適用されます。彼らは処理する準備ができていますか？これにより、一般的に上流のアイテムがそれに送信するアイテムの数を知る方法が一般にない状況でデータフローのメモリ使用量を制約することができます。
RXJAVAでは、専用のFlowableクラスは、逆圧力をサポートするように指定されており、 Observable非閉鎖操作（短いシーケンス、GUI相互作用など）に専念しています。他のタイプ、 Single 、 Maybe 、そしてCompletable 、逆圧力をサポートしないこともそうすべきではありません。一時的に1つのアイテムを保存する余地が常にあります。
さまざまな中間演算子を適用することによるデータフローの準備は、いわゆるアセンブリ時間で発生します。
Flowable < Integer > flow = Flowable . range ( 1 , 5 )
. map ( v -> v * v )
. filter ( v -> v % 3 == 0 )
;この時点で、データはまだ流れておらず、副作用は発生していません。
これはsubscribe()内部的に処理ステップのチェーンを確立するフローで呼び出される場合の一時的な状態です。
flow . subscribe ( System . out :: println )これは、サブスクリプションの副作用がトリガーされる場合です（ doOnSubscribe参照）。一部のソースは、この状態ですぐにアイテムの放出をブロックまたは開始します。
これは、フローがアイテム、エラー、または完了信号を積極的に放出している状態です。
Observable . create ( emitter -> {
while (! emitter . isDisposed ()) {
long time = System . currentTimeMillis ();
emitter . onNext ( time );
if ( time % 2 != 0 ) {
emitter . onError ( new IllegalStateException ( "Odd millisecond!" ));
break ;
}
}
})
. subscribe ( System . out :: println , Throwable :: printStackTrace );実際には、これは上記の特定の例の本文が実行されるときです。
RXJAVAの一般的なユースケースの1つは、いくつかの計算、バックグラウンドスレッドでネットワーク要求を実行し、UIスレッドに結果（またはエラー）を表示することです。
import io . reactivex . rxjava3 . schedulers . Schedulers ;
Flowable . fromCallable (() -> {
Thread . sleep ( 1000 ); // imitate expensive computation
return "Done" ;
})
. subscribeOn ( Schedulers . io ())
. observeOn ( Schedulers . single ())
. subscribe ( System . out :: println , Throwable :: printStackTrace );
Thread . sleep ( 2000 ); // <--- wait for the flow to finishこのスタイルのチェーン方法は、ビルダーパターンに似た流fluent APIと呼ばれます。ただし、Rxjavaの反応型は不変です。各メソッド呼び出しは、動作を追加して新しいFlowableを返します。説明するために、例は次のように書き直すことができます。
Flowable < String > source = Flowable . fromCallable (() -> {
Thread . sleep ( 1000 ); // imitate expensive computation
return "Done" ;
});
Flowable < String > runBackground = source . subscribeOn ( Schedulers . io ());
Flowable < String > showForeground = runBackground . observeOn ( Schedulers . single ());
showForeground . subscribe ( System . out :: println , Throwable :: printStackTrace );
Thread . sleep ( 2000 );通常、 subscribeOnを介して計算を移動したり、IOを他のスレッドにブロックしたりできます。データの準備ができたら、 observeOn介して前景またはGUIスレッドで処理されるようにすることができます。
RXJAVAオペレーターは、 Thread SやExecutorService Sを直接動作するのではなく、いわゆるScheduler Sでは、均一なAPIの背後にある同時性のソースを抽象化します。 RXJAVA 3には、 Schedulersユーティリティクラスを介してアクセス可能ないくつかの標準スケジューラがあります。
Schedulers.computation() ：バックグラウンドで固定数の専用スレッドで計算集中作業を実行します。ほとんどの非同期演算子は、これをデフォルトのSchedulerとして使用します。Schedulers.io() ：動的に変化するスレッドのセットでI/O-Likeまたはブロック操作を実行します。Schedulers.single() ：シーケンシャルとFIFOの方法で単一のスレッドで作業を実行します。Schedulers.trampoline() ：通常、テストのために、参加するスレッドの1つで、順次およびFIFOの方法で作業を実行します。これらはすべてのJVMプラットフォームで利用できますが、Androidなどの一部の特定のプラットフォームには、独自の典型的なScheduler sが定義されています： AndroidSchedulers.mainThread() 、 SwingScheduler.instance()またはJavaFXScheduler.platform() 。
さらに、既存のExecutor （およびExecutorServiceなどのサブタイプ）をSchedulers.from(Executor)を介してSchedulerにラップするオプションがあります。これは、たとえば、より大きいがまだ固定されたスレッドのプールを持つために使用できます（それぞれcomputation()とio()とは異なります）。
Thread.sleep(2000);最後に偶然はありません。 RXJavaでは、デフォルトのSchedulerがデーモンスレッドで実行されます。これは、Javaメインスレッドが終了すると、すべてが停止し、バックグラウンドの計算が発生しないことを意味します。この例でしばらく寝ると、コンソールのフローの出力が時間をかけて確認できます。
RXJavaのフローは、相互に同時に実行される可能性のある処理段階に分割されています。
Flowable . range ( 1 , 10 )
. observeOn ( Schedulers . computation ())
. map ( v -> v * v )
. blockingSubscribe ( System . out :: println );この例のフローは、計算Schedulerの1から10の数値を正方形にし、「メイン」スレッドで結果を消費します（より正確には、 blockingSubscribeの発信者スレッド）。ただし、Lambda v -> v * vこの流れに対して並行して実行されません。同じ計算スレッドで次々と値1〜10を受信します。
数値を並行して1〜10の処理を処理すると、もう少し関与します。
Flowable . range ( 1 , 10 )
. flatMap ( v ->
Flowable . just ( v )
. subscribeOn ( Schedulers . computation ())
. map ( w -> w * w )
)
. blockingSubscribe ( System . out :: println );実際には、rxjavaの並列性とは、独立したフローを実行し、結果を単一の流れに統合することを意味します。オペレーターのflatMap 、最初に各数値を1〜10に独自の個々のFlowableにマッピングすることでこれを行い、それらを実行し、計算された正方形をマージします。
ただし、 flatMap順序を保証せず、内側のフローからのアイテムがインターリーブされる可能性があることに注意してください。代替演算子があります：
concatMapとconcatMapEagerは、出力フローがこれらの内部フローが作成された順になります。あるいは、 Flowable.parallel()演算子とParallelFlowable処理パターンを達成するのに役立ちます。
Flowable . range ( 1 , 10 )
. parallel ()
. runOn ( Schedulers . computation ())
. map ( v -> v * v )
. sequential ()
. blockingSubscribe ( System . out :: println );flatMapは強力なオペレーターであり、多くの状況で役立ちます。たとえば、 Flowable返すサービスを考えると、最初のサービスによって放出される値を持つ別のサービスを呼び出したいと思います。
Flowable < Inventory > inventorySource = warehouse . getInventoryAsync ();
inventorySource
. flatMap ( inventoryItem -> erp . getDemandAsync ( inventoryItem . getId ())
. map ( demand -> "Item " + inventoryItem . getName () + " has demand " + demand ))
. subscribe ( System . out :: println );時々、アイテムが利用可能になったとき、それに依存した計算を実行したいと思います。これは継続と呼ばれることもあり、何が起こるべきか、どのタイプが関係しているかに応じて、達成するためにさまざまなオペレーターが関与する場合があります。
最も典型的なシナリオは、値を与え、別のサービスを呼び出し、その結果を待って継続することです。
service . apiCall ()
. flatMap ( value -> service . anotherApiCall ( value ))
. flatMap ( next -> service . finalCall ( next ))多くの場合、後のシーケンスが以前のマッピングから値を必要とすることもあります。これは、外側のflatMap以前のflatMapの内側部分に移動することで実現できます。
service . apiCall ()
. flatMap ( value ->
service . anotherApiCall ( value )
. flatMap ( next -> service . finalCallBoth ( value , next ))
)ここでは、元のvalue内側のflatMap内で利用可能になります。これは、Lambda Variable Captureの厚意によるものです。
他のシナリオでは、最初のソース/データフローの結果は無関係であり、準独立した別のソースを継続したいと考えています。ここでは、 flatMapも機能します。
Observable continued = sourceObservable . flatMapSingle ( ignored -> someSingleSource )
continued . map ( v -> v . toString ())
. subscribe ( System . out :: println , Throwable :: printStackTrace );ただし、この場合の継続は、より適切なSingleではなく、 Observableままです。 （これは理解できます。FlatMapsIngleの観点から、 flatMapSingle sourceObservable多値のソースであるため、マッピングが複数の値になる可能性があるため）。
多くの場合、メディエーターとそのオペレーターとしてCompletable andThen他の何かと一緒に再開することにより、やや表現力豊かな（そして架空の頭上）の方法がありますが：
sourceObservable
. ignoreElements () // returns Completable
. andThen ( someSingleSource )
. map ( v -> v . toString ()) sourceObservableとsomeSingleSourceの唯一の依存関係は、後者が消費されるためには、前者が正常に完了することです。
時には、以前のシーケンスと、何らかの理由で「通常のチャネル」を流れていない新しいシーケンスとの間には、暗黙のデータ依存性があります。次のような継続を書く傾向があります。
AtomicInteger count = new AtomicInteger ();
Observable . range ( 1 , 10 )
. doOnNext ( ignored -> count . incrementAndGet ())
. ignoreElements ()
. andThen ( Single . just ( count . get ()))
. subscribe ( System . out :: println );残念ながら、 Single.just(count.get())データフローがまだ実行されていないアセンブリ時に評価されるため、これは0印刷します。メインソースが完了するランタイムまで、このSingleソースの評価を扱うものが必要です。
AtomicInteger count = new AtomicInteger ();
Observable . range ( 1 , 10 )
. doOnNext ( ignored -> count . incrementAndGet ())
. ignoreElements ()
. andThen ( Single . defer (() -> Single . just ( count . get ())))
. subscribe ( System . out :: println );または
AtomicInteger count = new AtomicInteger ();
Observable . range ( 1 , 10 )
. doOnNext ( ignored -> count . incrementAndGet ())
. ignoreElements ()
. andThen ( Single . fromCallable (() -> count . get ()))
. subscribe ( System . out :: println );場合によっては、ソースまたはサービスが、それで動作するはずのフローとは異なるタイプを返します。たとえば、上記のインベントリの例では、 getDemandAsync Single<DemandRecord>を返すことができます。コードの例が変更されていない場合、これによりコンパイル時のエラーが発生します（ただし、多くの場合、過負荷の欠如に関する誤解を招くエラーメッセージがあります）。
このような状況では、通常、変換を修正するための2つのオプションがあります。1）目的のタイプに変換するか、2）異なるタイプをサポートする特定のオペレーターの過負荷を見つけて使用します。
各リアクティブベースクラスには、他のタイプに合わせてプロトコル変換を含むこのような変換を実行できる演算子が機能します。次のマトリックスは、利用可能な変換オプションを示しています。
| フロー可能 | 観察可能 | シングル | 多分 | 完了します | |
|---|---|---|---|---|---|
| フロー可能 | toObservable | first 、 firstOrError 、 single 、 singleOrError 、 last 、 lastOrError 1 | firstElement 、 singleElement 、 lastElement | ignoreElements | |
| 観察可能 | toFlowable 2 | first 、 firstOrError 、 single 、 singleOrError 、 last 、 lastOrError 1 | firstElement 、 singleElement 、 lastElement | ignoreElements | |
| シングル | toFlowable 3 | toObservable | toMaybe | ignoreElement | |
| 多分 | toFlowable 3 | toObservable | toSingle | ignoreElement | |
| 完了します | toFlowable | toObservable | toSingle | toMaybe |
1 ：多値のソースを単一値のソースに変えるとき、結果として多くのソース値を考慮すべきかを決定する必要があります。
2 ： Observable Flowableに変えるには、追加の決定が必要です。ソースの制約のない流れをObservableなものとするものはどうすればよいですか？ BackpressureStrategyパラメーターを介して、またはonBackpressureBuffer 、 onBackpressureDrop 、 onBackpressureLatestなどの標準的なFlowable演算子を介して、いくつかの戦略（バッファリング、ドロップ、最新の維持など）があります。
3 ：（せいぜい）1つのソースアイテムのみがある場合、下流が消費する準備ができるまで常に保存できるため、バックプレッシャーに問題はありません。
頻繁に使用される多くのオペレーターには、他のタイプに対処できるオーバーロードがあります。これらは通常、ターゲットタイプの接尾辞と呼ばれます。
| オペレーター | 過負荷 |
|---|---|
flatMap | flatMapSingle 、 flatMapMaybe 、 flatMapCompletable 、 flatMapIterable |
concatMap | concatMapSingle 、 concatMapMaybe 、 concatMapCompletable 、 concatMapIterable |
switchMap | switchMapSingle 、 switchMapMaybe 、 switchMapCompletable |
これらの演算子が単に異なる署名で同じ名前を持つだけでなく、接尾辞を持っている理由はタイプ消去です。 Javaはoperator(Function<T, Single<R>>)やoperator(Function<T, Maybe<R>>)異なり）とは見なさず、消去により、2つのoperatorは最終的にsが終わるでしょう。同じ署名を持つ複製メソッドとして。
名前が長く、表現力豊かで、キャプチャし、簡単に思い出深いものであると予想されるため、プログラミングの命名は最も難しいことの1つです。残念ながら、ターゲット言語（および既存の規則）は、この点であまり助けを与えない場合があります（使用不可能なキーワード、タイプ消去、タイプのあいまいさなど）。
元のrx.netでは、単一のアイテムを発してから完了する演算子がReturn(T)と呼ばれます。 Javaコンベンションではreturn(T)小文字の文字がメソッド名を開始することであるため、これはJavaのキーワードであるため、利用できません。したがって、RXJavaはこのオペレーターjust(T)を名前を付けることを選択しました。 switchOnNextという名前のオペレータSwitchにも同じ制限が存在します。さらに別の例は、 onErrorResumeNextと名付けられたCatchです。
ユーザーがリアクティブタイプを返す関数を提供することを期待する多くの演算子はFunction<T, X>そのようなメソッドシグネチャを複製に変換するため、過負荷にすることはできません。 rxjavaは、タイプを接尾辞として追加することにより、そのようなオペレーターに名前を付けることを選択しました。
Flowable < R > flatMap ( Function <? super T , ? extends Publisher <? extends R >> mapper )
Flowable < R > flatMapMaybe ( Function <? super T , ? extends MaybeSource <? extends R >> mapper )特定のオペレーターはタイプの消去から問題はありませんが、特にJava 8とLambdasを使用する場合、その署名が曖昧になる可能性があります。たとえば、他のさまざまな反応性ベースタイプを引数として取得するためのいくつかのconcatWith負荷があります（基礎となる実装で利便性とパフォーマンスの利点を提供するため）：
Flowable < T > concatWith ( Publisher <? extends T > other );
Flowable < T > concatWith ( SingleSource <? extends T > other ); PublisherとSingleSource両方が機能的なインターフェイス（1つの抽象的な方法を持つタイプ）として表示され、ユーザーがLambdaの表現を提供しようとすることを奨励する場合があります。
someSource . concatWith ( s -> Single . just ( 2 ))
. subscribe ( System . out :: println , Throwable :: printStackTrace );残念ながら、このアプローチは機能せず、例はまったく印刷2れません。実際、バージョン2.1.10以来、少なくとも4つのconcatWith負荷が存在し、コンパイラがコードを曖昧に見つけるため、コンパイルさえしません。
このような状況のユーザーは、おそらくsomeSourceが完了するまで計算を延期したいと考えていたため、正しい明確なオペレーターはdeferべきでした。
someSource . concatWith ( Single . defer (() -> Single . just ( 2 )))
. subscribe ( System . out :: println , Throwable :: printStackTrace );時々、コンパイルするかもしれないが間違ったタイプを生成する可能性のある論理的なあいまいさを避けるために、接尾辞が追加されることがあります。
Flowable < T > merge ( Publisher <? extends Publisher <? extends T >> sources );
Flowable < T > mergeArray ( Publisher <? extends T >... sources );これは、機能的なインターフェイスタイプがタイプ引数Tとして関与すると、あいまいになる可能性があります。
データフローは失敗する可能性があり、その時点でエラーは消費者に放出されます。ただし、複数のソースが失敗する場合があります。その時点で、すべてのソースが完了するか失敗するかを待つかどうかがあります。この機会を示すために、多くのオペレーター名にDelayError単語が付いています（他のオペレーターは、過負荷の1つにdelayErrorまたはdelayErrorsブールフラグを備えています）：
Flowable < T > concat ( Publisher <? extends Publisher <? extends T >> sources );
Flowable < T > concatDelayError ( Publisher <? extends Publisher <? extends T >> sources );もちろん、さまざまな種類のサフィックスが一緒に表示される場合があります。
Flowable < T > concatArrayEagerDelayError ( Publisher <? extends T >... sources );基本クラスは、静的およびインスタンスのメソッドの数が多いため、重いと見なすことができます。 RXJava 3のデザインは、リアクティブストリームの仕様の影響を強く受けていました。したがって、ライブラリには、各リアクティブタイプごとにクラスとインターフェイスがあります。
| タイプ | クラス | インタフェース | 消費者 |
|---|---|---|---|
| 0..Nバックプレス | Flowable | Publisher 1 | Subscriber |
| 0..Nバウンドされていません | Observable | ObservableSource 2 | Observer |
| 1つの要素またはエラー | Single | SingleSource | SingleObserver |
| 0..1要素またはエラー | Maybe | MaybeSource | MaybeObserver |
| 0要素またはエラー | Completable | CompletableSource | CompletableObserver |
1 org.reactivestreams.Publisher 、外部Reactive Streamsライブラリの一部です。これは、リアクティブストリームの仕様によって支配される標準化されたメカニズムを介して、他の反応性ライブラリと対話するメインタイプです。
2インターフェイスの命名規則は、半伝統的なクラス名にSourceを追加することでした。 Publisher Reactive Streams Libraryによって提供されているため、 FlowableSourceありません（そして、相互操作にも役立たなかったでしょう）。ただし、これらのインターフェイスは、リアクティブストリームの仕様の意味では標準ではなく、現在RXJava固有のみです。
デフォルトでは、RXJava自体はProguard/R8の設定を必要とせず、問題なく動作するはずです。残念ながら、バージョン1.0.3がjarにJava 9クラスファイルが埋め込まれているため、リアクティブストリームの依存関係は、プレーンのプロゲアードで警告を発する可能性があります。
Warning: org.reactivestreams.FlowAdapters$FlowPublisherFromReactive: can't find superclass or interface java.util.concurrent.Flow$Publisher
Warning: org.reactivestreams.FlowAdapters$FlowToReactiveProcessor: can't find superclass or interface java.util.concurrent.Flow$Processor
Warning: org.reactivestreams.FlowAdapters$FlowToReactiveSubscriber: can't find superclass or interface java.util.concurrent.Flow$Subscriber
Warning: org.reactivestreams.FlowAdapters$FlowToReactiveSubscription: can't find superclass or interface java.util.concurrent.Flow$Subscription
Warning: org.reactivestreams.FlowAdapters: can't find referenced class java.util.concurrent.Flow$Publisher
アプリケーションのproguard-rulesetファイルに次のよう-dontwarnエントリをセットアップすることをお勧めします。
-dontwarn java.util.concurrent.Flow*
R8の場合、RXJAVA JARには、同じ注意なしの節を持つMETA-INF/proguard/rxjava3.proが含まれており、自動的に適用する必要があります。
詳細については、Wikiを参照してください。
バージョン3.xが開発中です。バグフィックスは2.xと3.xの両方のブランチに適用されますが、新しい機能は3.xにのみ追加されます。
わずかな3.x増分（3.1、3.2などなど）は、非自明な新しい機能が追加されるか、いくつかのエッジケースに影響を与える可能性のある行動の変化を持つ可能性のある重要な機能強化またはバグ修正が発生した場合に発生します（から生じる行動への依存などが発生しますバグ）。これが以前にサポートしていなかったオペレーターにリアクティブプルバックプレッシャーサポートを追加することであるため、分類する強化の例です。これは逆方向に互換性があるはずですが、異なる動作をします。
パッチ3.xyの増分（3.0.0-> 3.0.1、3.3.1-> 3.3.2など）は、バグの修正と些細な機能（メソッドの過負荷の追加など）で発生します。 @Betaまたは@Experimentalアノテーションでマークされた新しい機能をパッチリリースに追加して、不安定な新しい機能の迅速な調査と反復を可能にすることもできます。
クラスまたはメソッドレベルでの@BetaアノテーションでマークされたAPIは、変更される可能性があります。いつでも変更するか、削除することさえできます。コードがライブラリ自体である場合（つまり、コントロール外のユーザーのクラスパスで使用されています）、再パッケージ（Proguard、Shadingなどを使用するなど）を再パッケージしない限り、ベータAPIを使用しないでください。
クラスレベルまたはメソッドレベルでの@ExperimentalアノテーションでマークされたAPIは、ほぼ確実に変更されます。いつでも変更するか、削除することさえできます。生産コードでそれらを使用または依存しないでください。純粋に幅広いテストとフィードバックを許可するためです。
クラスまたはメソッドレベルでの@Deprecated AnnotationでマークされたAPIは、次の主要なリリースまでサポートされたままですが、それらの使用を停止することをお勧めします。
io.reactivex.rxjava3.internal.*パッケージ内のすべてのコードは、プライベートAPIと見なされ、まったく依存してはなりません。いつでも変更できます。
http://reactivex.io/RxJava/3.x/javadoc/3.xy/ Maven、Ivy、Gradleなどのバイナリと依存情報は、http：//search.maven.orgで見つけることができます。
Gradleの例：
implementation ' io.reactivex.rxjava3:rxjava:x.y.z 'そしてメイベンのために：
< dependency >
< groupId >io.reactivex.rxjava3</ groupId >
< artifactId >rxjava</ artifactId >
< version >x.y.z</ version >
</ dependency >そしてアイビーのために：
< dependency org = " io.reactivex.rxjava3 " name = " rxjava " rev = " x.y.z " />2021年5月1日以降のスナップショットは、https：//oss.sonatype.org/content/repositories/snapshots/io/reactivex/rxjava3/rxjava/から入手できます。
repositories {
maven { url ' https://oss.sonatype.org/content/repositories/snapshots ' }
}
dependencies {
implementation ' io.reactivex.rxjava3:rxjava:3.0.0-SNAPSHOT '
}Javadoc Snapshotsはhttp://reactivex.io/rxjava/3.x/javadoc/snapshotで入手できます
構築するには：
$ git clone [email protected]:ReactiveX/RxJava.git
$ cd RxJava/
$ ./gradlew build
建物の詳細については、Wikiの開始ページをご覧ください。
バグ、質問、ディスカッションについては、GitHubの問題を使用してください。
Copyright (c) 2016-present, RxJava Contributors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
