Rxjava2最全面的解析

時間  2019-11-30
標籤 rxjava2 rxjava 全面 解析 欄目 Java 简体版
原文   原文鏈接

前言

因爲公司從新規劃的部門，我調到了另一個部門，因此負責的項目也換了，仔細看了下總體的項目，rxjava+retrofit。總體的一套。衆所周知，rxjava+retrofit是目前網上最流行的網絡解析框架。而目前網絡上的文章大多仍是關於rxjava1的。關於RxJava2的少之又少，因而，便有了此文。java

此文的目的有三個： 1. 給對 RxJava2感興趣的人一些入門的指引 2. 給正在使用 RxJava2但仍然心存疑惑的人一些更深刻的解析 3.給想從RxJava1替換成RxJava2的人給出直接的對比。react

RxJava概念介紹

RxJava=reactive+extension。 那麼接下來我會分別對這兩點進行總體的介紹。reactive又稱reactive programming。也就是響應式編程。在往簡單的說，rxjava能夠很方便的處理線程切換的問題。說到這個，咱們就會想到異步操做。handler？AsyncTask？但你要知道，隨着請求的數量愈來愈多，代碼邏輯將會變得愈來愈複雜。而rxjava卻仍能夠保持清晰的邏輯。它的原理就是建立一個Observable對象來搞事情。而後使用各類操做符經過建造者模式創建成一系列的鏈式操做。就如流水線同樣，把事情搞完。而後發射給Observer進行處理。android

觀察者模式

rxjava的實現主要是經過觀察者模式實現的。那麼什麼是觀察者模式，我這邊作一個簡單的介紹。數據庫

栗子：觀察者對被觀察者進行一個簡單，當被觀察者被改變時，要當即作出反應。好比，你認爲隔壁老王和你媳婦有一腿，但卻沒證據，此時，只要當隔壁老王進了你媳婦房門的時候，你就要去捕獲他。在這個例子中，你是觀察者，老王是被觀察者。（記得當初我常常搞反了）。那麼，觀察者模式是不是一對一呢？很明顯不是的，就上面的例子，你能夠叫三千城管監聽着老王。只要他有不軌之心。就打斷他的第三條腿。也就是說多個觀察者對應一個被觀察者。字看累了來看圖：編程


其實在android中也有不少自帶的觀察者模式。最明顯的莫過於點擊事件。說個最簡單的例子，點擊按鈕後彈一個吐司。那麼，咱們在點擊按鈕的時候，告知系統，此時，我須要彈一個吐司。那麼就這麼彈出來了。那麼，這個時候問題來了。我是否須要實時去監聽這個按鈕呢？答案是不須要的。這就和前面的舉例有的差距了。換句話說。我只要在此按鈕進行點擊時進行監聽就能夠了。這種操做被稱爲訂閱。也就是說Button經過setOnClickListener對OnclickListener進行了訂閱了操做，來監聽onclick方法。json

extension

  • 不只支持事件序列，還支持數據流。事件-->動態的，沒法預知，例如：事件點擊，服務器的推送等等 數據流-->靜態的，可預知的，例如：讀取本地文件，播放音視頻等等。數組

  • 經過操做符對中間事件的處理。緩存

  • 線程操做的便捷。關於這些具體的實現。我會在後面一一舉例。bash

RxJava1與RxJava2的區別

說到區別，可能有的小夥伴會問，我沒看過rxjava1。能夠直接看rxjava2麼。我的以爲沒必要要，由於 rxjava2.x 是按照 Reactive-Streams specification 規範徹底的重寫的，徹底獨立於 rxjava1.x 而存在，它改變了以往 rxjava1的用法。換句話說，我學java需不須要先學C語言同樣。服務器

那麼二者的區別體如今哪呢？主要是以下幾個方面：

  • 空指針問題這應該是一個很大的變化，用過rxjava1的人都知道，咱們能夠在發射事件的時候傳入NULL。但這在rxjava2中是不存在的。不信你試試？分分鐘給你來一個NullPointerExpection。

  • Function相關的在rxjava1中，咱們有各類Func1，Func2......，但在rxjava2中只有Function了。依舊記得看凱哥的文章的時候把我整蒙了。愣是沒發現，後來才注意到被替換了。而且，他們都增長了throw exception。

  • 背壓—backpressure 關於backpressure，這個就厲害了。厲害到我都不懂了。好了，開個玩笑，咱們繼續說。咱們知道在Rxjava1中Observable對backpressure是支持的。但在Rxjava2中Observable取消了對backpressure的支持。而且引進了一個叫作Flowable的來支持backpressure。

那麼什麼是背壓： 聽不懂的含義：上游的生產速度大於下游的處理速度，致使下游處理不急，這種操做被稱爲backpressure。

這種狀況看似很常見，但實際上，這種狀況並不常見，或者能夠說成很是罕見。那麼遇到了怎麼辦？若是它出現了，直接丟棄。what the fuck？你tm在逗我？但事實就是這樣，若是咱們在開發過程當中，遇到了backpressure，咱們就應該丟棄它。

聽得懂的含義：對於可丟棄的事件，上游生產速度過快致使事件堆積，當堆積到超出buffer上限的時候，就叫作backpressure。

處理方案是什麼： 一、丟棄新事件；二、不丟棄，繼續堆積。（忽略了backpressure，至關於Observable）。

適合backpressure的狀況： 在線直播流：好比說，正在直播的時候，忽然網絡出現了卡頓，頁面卡住了。那麼當網絡好了以後確定不會是在接着以前的頁面繼續的，就至關於，你網絡卡了多久，他就丟棄了多長時間的數據。

backpressure的關鍵點是什麼：不可控，可丟棄。

基本使用

講了一大堆理念知識，接下來就是開工幹活了。那麼關於Rxjava2的基本實現主要是三點：建立Observable，建立Observer，進行綁定。那麼咱們一個個的看。

建立Observable

Observable是什麼？觀察者仍是被觀察者？我又忘了。哈哈。開個玩笑，固然是後者了。爲何是先建立Observable而不是Observer？固然了，前後順序的無所謂的。可是考慮到後面的鏈式調用。因此我這邊就先寫了先建立Observable了。

Observable<String> observable = Observable.create(new ObservableOnSubscribe<String>() {
            @Override
            public void subscribe(ObservableEmitter<String> emitter) throws Exception {
                emitter.onNext("Hello");
                emitter.onNext("Rxjava2");
                emitter.onNext("My name is Silence");
                emitter.onNext("What's your name");
                //一旦調用onComplete,下面將不在接受事件
                emitter.onComplete();
            }
        });複製代碼

如今我來解釋一下上面的ObservableEmitter究竟是什麼。字面意思是可觀察的發射器。沒錯，這個就是被觀察者用來發送事件的。它能夠發出三種類型的事件，經過調用emitter的onNext(T value)、onError(Throwable error)和onComplete()就能夠分別發出next事件、error事件和complete事件。至於這三個事件到底什麼意思。不急，咱們後面說。

建立Observer

如今咱們來建立一個觀察者，它決定了在觀察中到底應該有着什麼樣的行爲操做。

Observer<String> observer = new Observer<String>() {
            @Override
            public void onSubscribe(Disposable d) {
                Log.i(TAG, "onSubscribe: " + d);
                result += "onSubscribe: " + d + "\n";
            }
​
            @Override
            public void onNext(String string) {
                Log.i(TAG, "onNext: " + string);
                result += "onNext: " + string + "\n";
            }
​
            @Override
            public void onError(Throwable e) {
                Log.i(TAG, "onError: " + e);
                result += "onError: " + e + "\n";
            }
​
            @Override
            public void onComplete() {
                Log.i(TAG, "onComplete: ");
                result += "onComplete: " + "\n";
            }
        };複製代碼

其中onSubscribe、onNext、onError和onComplete是必要的實現方法，其含義以下：

  • onSubscribe：它會在事件還未發送以前被調用，能夠用來作一些準備操做。而裏面的Disposable則是用來切斷上下游的關係的。

  • onNext：普通的事件。將要處理的事件添加到隊列中。

  • onError：事件隊列異常，在事件處理過程當中出現異常狀況時，此方法會被調用。同時隊列將會終止，也就是不容許在有事件發出。

  • onComplete：事件隊列完成。rxjava不只把每一個事件單獨處理。並且會把他們當成一個隊列。當再也不有onNext事件發出時，須要觸發onComplete方法做爲完成標識。

進行Subscribe

訂閱其實只須要一行代碼就夠了：

observerable.subscribe(Observer);複製代碼

運行一個看看效果先：

和以前介紹的同樣，先調用onSubscribe，而後走了onNext，最後以onComplete收尾。

神奇的操做符

對於rxjava來講，有一句話，我以爲說的很對，叫作：若是你天天研究一個操做符，最少一個半月，若是你想理解原理。最少半年。換句話說，有關rxjava的知識徹底能夠寫一本書。那麼本文確定不會講那麼細。在這邊我會給大家介紹一些經常使用的操做符。保證平常開發的流程足矣。

建立操做符

通常建立操做符是指，剛開始建立觀察者的時候調用的。在基本使用中我已經介紹了create操做符，那麼這邊咱們就要說到just，fromarray和interval了。

just

此操做符是將傳入的參數依次發出來。

Observable observable = Observable.just("Hello", "Rxjava2", "My name is Silence","What's your name");
// 將會依次調用：
// onNext("Hello");
// onNext("Rxjava2");
// onNext("My name is Silence");
// onNext("What's your name");
// onCompleted();複製代碼
fromarray

將傳入的數組經過座標一次發送出去。

String[] words = {"Hello", "Rxjava2", "My name is Silence","What's your name"};
Observable observable = Observable.from(words);
// 將會依次調用：
// onNext("Hello");
// onNext("Rxjava2");
// onNext("My name is Silence");
// onNext("What's your name");
// onCompleted();複製代碼
interval

這個其實就是定時器，用了它你能夠拋棄CountDownTimer了。如今咱們看看怎麼用：

Observable.interval(2, TimeUnit.SECONDS).subscribe(
                new Consumer<Long>() {
                    @Override
                    public void accept(Long aLong) throws Exception {
                        Log.i(TAG, "accept: "+aLong.intValue());
                    }
                }
        );複製代碼

咱們看看結果：


上面就是咱們每隔2s打印一次long的值。

變換操做符

變換操做符的做用是對Observable發射的數據按照必定規則作一些變換操做，而後講變換後的數據發射出去。變換操做符有map，flatMap，concatMap，switchMap，buffer，groupBy等等。這裏咱們會講解最經常使用的map，flatMap、concatMap以及compose。

map

map操做符經過指定一個Function對象，將Observable轉換爲一個新的Observable對象併發射，觀察者將收到新的Observable處理。直接上代碼：

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                emitter.onNext(1);
                emitter.onNext(2);
                emitter.onNext(3);
                emitter.onNext(4);
            }
        }).map(new Function<Integer, String>() {
            @Override
            public String apply(Integer integer) throws Exception {
                return "This is result " + integer + "\n";
            }
        }).subscribe(new Consumer<String>() {
            @Override
            public void accept(String str) throws Exception {
                Log.i("--->", "accept: "+str);
                string += str;
            }
        });
        tv_first.setText(string);複製代碼

輸入結果以下：


仔細看，map()方法中，咱們把一個integer對象轉換成了一個String對象。而後當map()調用結束時，事件的參數類型也從integer轉換成了String。這就是最多見的變換操做。

flatMap

flatmap的操做符是將Observable發射的數據集合變成一個Observable集合。也就是說它能夠講一個觀察對象變換成多個觀察對象，可是並不能保證事件的順序。想保證事件的順序？那你過會看下面降到的concatMap。

那麼什麼叫做數據集合變成一個Observable集合呢？仍是用上面的例子，我有一組integer集合。我想轉換成string集合怎麼辦？那就繼續看代碼：

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                emitter.onNext(1);
                emitter.onNext(2);
                emitter.onNext(3);
            }
        }).flatMap(new Function<Integer, ObservableSource<String>>() {
            @Override
            public ObservableSource<String> apply(Integer integer) throws Exception {
                final List<String> list = new ArrayList<>();
                for (int i = 0; i < 3; i++) {
                    list.add("I am value " + integer + "\n");
                }
                return Observable.fromIterable(list);
            }
        }).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.i("--->", "accept: "+s);
                string += s;
            }
        });
        tv_first.setText(string);複製代碼

咱們來看結果：


打住打住，是否是有問題？WTF？有啥問題？還記不記得我上面說過flatMap不能保證事件執行順序。那麼這邊事件爲何都是按順序執行的？不急，咱們在發射事件的時候給他加一個延遲在看看結果：

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                emitter.onNext(1);
                emitter.onNext(2);
                emitter.onNext(3);
            }
        }).flatMap(new Function<Integer, ObservableSource<String>>() {
            @Override
            public ObservableSource<String> apply(Integer integer) throws Exception {
                final List<String> list = new ArrayList<>();
                for (int i = 0; i < 3; i++) {
                    list.add("I am value " + integer + "\n");
                }
                return Observable.fromIterable(list).delay(100,TimeUnit.MILLISECONDS);
            }
        }).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.i("--->", "accept: "+s);
                string += s;
            }
        });
        tv_first.setText(string);複製代碼

咱們在當他發射事件的時候給他加一個100ms的延遲看看結果：


看到沒有，我說啥的？不能保證執行順序。因此萬事容我慢慢道來。先喝杯茶壓壓驚。咱們在接着往下講。

concatMap

上面我也介紹了concatMap。除了保證了執行順序，其餘都和concatMap一毛同樣。你說保證就保證啊。您先喝杯茶，接着往下看：

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                emitter.onNext(1);
                emitter.onNext(2);
                emitter.onNext(3);
            }
        }).concatMap(new Function<Integer, ObservableSource<String>>() {
            @Override
            public ObservableSource<String> apply(Integer integer) throws Exception {
                final List<String> list = new ArrayList<>();
                for (int i = 0; i < 3; i++) {
                    list.add("I am value " + integer + "\n");
                }
                return Observable.fromIterable(list).delay(1000,TimeUnit.MILLISECONDS);
//                return Observable.fromIterable(list);
            }
        }).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.i("--->", "accept: "+s);
                string += s;
            }
        });
        tv_first.setText(string);複製代碼

爲了咱們能看的更明顯一點，我這邊直接設置了一秒鐘的延遲。下面咱們來看效果圖：


能夠從執行順序和打印時間看出，的的確確是延遲了一秒鐘。

compose

這個操做符就很厲害了。他的變換是怎麼作的呢？咱們知道rxjava是經過建造者的模式經過鏈式來調用起來的。那麼多個鏈式就須要多個Observable。而這個操做符就是把多個Observable轉化成一個Observable。聽起來是否是很厲害~。具體如何操做，咱們接着看：

​
    public  <T> ObservableTransformer<T, T> applyObservableAsync() {
        return new ObservableTransformer<T, T>() {
            @Override
            public ObservableSource<T> apply(Observable<T> upstream) {
                return upstream.subscribeOn(Schedulers.io())
                        .observeOn(AndroidSchedulers.mainThread());
            }
        };
    }複製代碼

上面代碼能夠看出，我把子線程和主線程進行了一個封裝，而後返回了一個ObservableTransformer對象。那麼咱們只要這邊作就能夠了：

Observable.just(1, 2, 3, 4, 5, 6)
                .compose(this.<Integer>applyObservableAsync())
                .subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer strings) throws Exception {
                Log.i("-->", "accept: " + strings);
                string += strings;
            }
        });
        tv_first.setText(string);複製代碼

過濾操做符

過濾操做符用於過濾和選擇Observable發射的數據序列。讓Observable只返回知足咱們條件的數據。過濾操做符有buffer，filter，skip，take，skipLast，takeLast等等，這邊我會介紹到filter，buffer，skip，take，distinct。

filter

filter操做符是對源Observable產生的結果進行有規則的過濾。只有知足規則的結果纔會提交到觀察者手中。例如：

Observable.just(1,2,3).filter(new Predicate<Integer>() {
            @Override
            public boolean test(Integer integer) throws Exception {
                return integer < 3;
            }
        }).subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer s) throws Exception {
                Log.i("--->", "accept: " + s);
                string += s;
            }
        });
        tv_first.setText(string);
    }複製代碼

代碼很簡單，咱們發送1，2，3；可是咱們加上一個filter操做符，讓它只返回小於3的的內容。那麼咱們來看一下結果：


distinct

這個操做符其實就更簡單了。好比說，我要在一組數據中去掉重複的內容，就要用到它。也就是去重。它只容許尚未發射的數據項經過。發射過的數據項直接pass。

Observable.just(1,2,3,4,2,3,5,6,1,3)
                .distinct().subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer s) throws Exception {
                Log.i("--->", "accept: " + s);
                string += s;
            }
        });
        tv_first.setText(string);複製代碼

那麼輸出結果就很簡單了：


buffer

這個其實也不難，主要是緩存，把源Observable轉換成一個新的Observable。這個新的Observable每次發射的是一組List，而不是單獨的一個個的發送數據源。

Observable.just(1,2,3,4,5,6)
                .buffer(2).subscribe(new Consumer<List<Integer>>() {
            @Override
            public void accept(List<Integer> strings) throws Exception {
                for (Integer integer : strings) {
                    Log.i("-->", "accept: "+integer);
                    string+=strings;
                }
                Log.i("-->", "accept: ----------------------->");
            }
        });
        tv_first.setText(string);複製代碼

咱們讓他每次緩存2個，下面咱們來看結果：


skip 、take

skip操做符將源Observable發射過的數據過濾掉前n項，而take操做則只取前n項；另外還有skipLast和takeLast則是從後往前進行過濾。先來看看skip操做符。

Observable.just(1, 2, 3, 4, 5, 6)
                .skip(2).subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer strings) throws Exception {
                Log.i("-->", "accept: " + strings);
                string += strings;
            }
        });
        tv_first.setText(string);複製代碼

結果以下：


接下來咱們把skip換成take看看。

Observable.just(1, 2, 3, 4, 5, 6)
                .take(3).subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer strings) throws Exception {
                Log.i("-->", "accept: " + strings);
                string += strings;
            }
        });
        tv_first.setText(string);複製代碼

結果以下：


組合操做符

merge

merge是將多個操做符合併到一個Observable中進行發射，merge可能讓合併到Observable的數據發生錯亂。（並行無序）

Observable<Integer> observable1=Observable.just(1,2,3);
        Observable<Integer> observable2=Observable.just(1,2,3);
        Observable.merge(observable1,observable2).subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) throws Exception {
                Log.i(TAG, "accept: "+integer);
            }
        });複製代碼

結果以下：


concat

將多個Observable發射的數據進行合併而且發射，和merge不一樣的是，merge是無序的，而concat是有序的。（串行有序）沒有發射完前一個它必定不會發送後一個。

Observable<Integer> observable1=Observable.just(1,2,3);
        Observable<Integer> observable2=Observable.just(4,5,6);
        Observable.concat(observable1,observable2).subscribe(new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) throws Exception {
                Log.i(TAG, "accept: "+integer);
            }
        });複製代碼

結果以下：


zip

此操做符和合並多個Observable發送的數據項，根據他們的類型就行從新變換，併發射一個新的值。

Observable<Integer> observable1=Observable.just(1,2,3);
        Observable<String> observable2=Observable.just("a","b","c");
        Observable.zip(observable1, observable2, new BiFunction<Integer, String, String>() {
​
            @Override
            public String apply(Integer integer, String s) throws Exception {
                return integer+s;
            }
        }).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.i(TAG, "apply: "+s);
            }
        });複製代碼

結果以下：


concatEager

前面說道串行有序，而concatEager則是並行且有序。咱們來看看若是修改：

Observable<Integer> observable1=Observable.just(1,2,3);
        Observable<String> observable2=Observable.just("a","b","c");
        Observable.concatEager(Observable.fromArray(observable1,observable2)).subscribe(new Consumer<Serializable>() {
            @Override
            public void accept(Serializable serializable) throws Exception {
                Log.i(TAG, "accept: "+serializable);
            }
        });複製代碼

結果以下：


線程控制

其實線程控制也是一種操做符。但它不屬於建立、變換、過濾。因此我這邊把它單獨拉出來說講。

subscribeOn是指上游發送事件的線程。說白了也就是子線程。屢次指定上游的線程只有第一次指定的有效, 也就是說屢次調用subscribeOn() 只有第一次的有效, 其他的會被忽略。

observerOn是指下游接受事件的線程。也就是主線程。屢次指定下游的線程是能夠的, 也就是說每調用一次observeOn() , 下游的線程就會切換一次。

舉個栗子：

Observable.just(1, 2, 3, 4) // IO 線程，由 subscribeOn() 指定
    .subscribeOn(Schedulers.io())
    .observeOn(Schedulers.newThread())
    .map(mapOperator) // 新線程，由 observeOn() 指定
    .observeOn(Schedulers.io())
    .map(mapOperator2) // IO 線程，由 observeOn() 指定
    .observeOn(AndroidSchedulers.mainThread) 
    .subscribe(subscriber);  // Android 主線程，由 observeOn() 指定複製代碼

在RxJava中, 已經內置了不少線程選項供咱們選擇, 例若有

  • Schedulers.io() ：I/O操做（讀寫文件、數據庫，及網絡交互等）所使用的Scheduler。行爲模式和newThread()差很少。區別在於io()的內部實現是用一個無數量上限的線程池。能夠重用空閒的線程。所以多數狀況下io()比newThread()更有效率。

  • Schedulers.immediate()： 直接在當前線程運行。

  • Schedulers.computation() ：計算所使用的Scheduler，例如圖形的計算。這個Scheduler使用固定線程池，大小爲CPU核數。不要把I/O操做放在computation中。不然I/O操做的等待會浪費CPU。

  • Schedulers.newThread()：表明一個常規的新線程

  • Schedulers.trampoline()： 當咱們想在線程執行一個任務時（不是當即執行），能夠用此方法將它加入隊列。這個調度器將會處理它的隊列而且按序執行隊列中的每個任務。

  • AndroidSchedulers.mainThread() ：表明Android的主線程

這些內置的Scheduler已經足夠知足咱們開發的需求, 所以咱們應該使用內置的這些選項, 在RxJava內部使用的是線程池來維護這些線程, 全部效率也比較高。

與Retrofit結合

就目前開發角度而言，retrofit能夠說是最火的網絡框架。其緣由我認爲有兩點，第一：能夠和okhttp結合。第二：能夠和rxjava結合。也就是說Retrofit 除了提供了傳統的 Callback 形式的 API，還有 RxJava 版本的 Observable 形式 API。

若是須要使用retrofit，咱們須要在gradle的配置加上這句：

compile 'com.squareup.retrofit2:retrofit:2.0.1'複製代碼

話很少說，直接上例子：

​
    private static OkHttpClient mOkHttpClient;
    private static Converter.Factory gsonConverterFactory = GsonConverterFactory.create();
    private static CallAdapter.Factory rxJavaCallAdapterFactory = RxJavaCallAdapterFactory.create();
     public static BaseHttpApi getObserve() {
​
        if (baseHttpApi == null) {
            Retrofit retrofit = new Retrofit.Builder()
                    .addConverterFactory(gsonConverterFactory)
                    .addCallAdapterFactory(rxJavaCallAdapterFactory)
                    .client(mOkHttpClient)
                    .baseUrl(BaseUrl.WEB_BASE)
                    .build();
            baseHttpApi = retrofit.create(BaseHttpApi.class);
       }
        return baseHttpApi;
​
    }複製代碼

如上代碼，能夠很清晰的看出，它經過2個工廠模式建立了gson和rxjava。而且經過了鏈式調用將他們進行了綁定。那麼怎麼經過鏈式調用實現網絡請求呢？不急，咱們喝杯茶，接着往下看。

好比，一個post請求，咱們能夠這麼寫：

public interface BaseHttpApi{  
    @FormUrlEncoded
    @POST("seller/cash_flow_log_detail.json")
    Observable<ServiceReward> serviceReward(@Field("requestmodel") String model);
}複製代碼

敲黑板了。注意，我這邊是interface而不是一個class。接下來就是平常調用了，代碼以下：

Network.getObserve()
                .serviceReward(new Gson().toJson(map))
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Observer<ServiceReward>() {
                    @Override
                    public void onCompleted() {
​
                    }
​
                    @Override
                    public void onError(Throwable e) {
​
                    }
​
                    @Override
                    public void onNext(ServiceReward serviceReward) {
                        parseOrderDetail(serviceReward);
                    }
                });複製代碼

看第二行，這就是爲何剛開始爲何要用工廠模式建立gson的緣由。如今咱們只要在parseOrderDetail方法中處理正常的邏輯就能夠了。是否是看起來代碼有點多？那麼咱們能夠這樣：

Network.getObserve()
                .serviceReward(new Gson().toJson(map))
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(serviceReward ->{
                        parseOrderDetail(serviceReward);
                 });複製代碼

一個lamada表達式，是否是感受瞬間代碼少了不少，不過有人要說，我加載的時候是一個彈窗顯示的，若是加載失敗了我這個彈窗豈不是影藏不了？不存在的，若是真有這種狀況怎麼作？咱們接着看：

Network.getObserve()
                .serviceReward(new Gson().toJson(map))
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(serviceReward ->{
                        parseOrderDetail(serviceReward);
                 },throwable ->{do something when net error...});複製代碼

這麼處理豈不是快哉。對於lamada，剛開始可能都是各類不習慣，不過用習慣了就會發現代碼各類簡潔（我最近也在適應中）。

最後

關於rxjava其實對咱們來講很難上手。或者不能這麼說，應該是rxjava的東西太深了，咱們很難掌握透徹。因此我前面也說了若是你天天研究一個操做符，最少一個半月，若是你想理解原理。最少半年。換句話說，有關rxjava的知識徹底能夠寫一本書。但平常開發中，此文中的內容基本能夠解決大部分的平常需求。固然，若是你有心的話，你能夠去嘗試着瞭解rxjava底層的實現原理。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程