給初學者的RxJava2.0教程(九)

Outline

[TOC]

前言

好久不見朋友們，最近一段時間在忙工作上的事情，沒來得及寫文章，這兩天正好有點時間，趕緊寫下了這篇教程，免得大家說我太監了。

正題

先來回顧一下上上節，我們講Flowable的時候，說它采用了響應式拉的方式，我們還舉了個葉問打小日本的例子，再來回顧一下吧，我們說把上游看成小日本, 把下游當作葉問, 當調用Subscription.request(1)時, 葉問就說我要打一個! 然后小日本就拿出一個鬼子給葉問, 讓他打, 等葉問打死這個鬼子之后, 再次調用request(10), 葉問就又說我要打十個! 然后小日本又派出十個鬼子給葉問, 然后就在邊上看熱鬧, 看葉問能不能打死十個鬼子, 等葉問打死十個鬼子后再繼續要鬼子接著打。

但是不知道大家有沒有發現，在我們前兩節中的例子中，我們口中聲稱的響應式拉并沒有完全體現出來，比如這個例子：

Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
                Log.d(TAG, "emit 2");
                emitter.onNext(2);
                Log.d(TAG, "emit 3");
                emitter.onNext(3);
                Log.d(TAG, "emit complete");
                emitter.onComplete();
            }
        }, BackpressureStrategy.ERROR).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;  
                        s.request(1);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                        mSubscription.request(1);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

雖然我們在下游中是每次處理掉了一個事件之后才調用request(1)去請求下一個事件，也就是說葉問的確是在打死了一個鬼子之后才繼續打下一個鬼子，可是上游呢？上游真的是每次當下游請求一個才拿出一個嗎？從上上篇文章中我們知道并不是這樣的，上游仍然是一開始就發送了所有的事件，也就是說小日本并沒有等葉問打死一個才拿出一個，而是一開始就拿出了所有的鬼子，這些鬼子從一開始就在這兒排隊等著被打死。

有個故事是這么說的：

楚人有賣盾與矛者，先譽其盾之堅，曰：“吾盾之堅，物莫能陷也。”俄而又譽其矛之利，曰：“吾矛之利，萬物莫不陷也。”市人詰之曰："以子之矛陷子之盾，何如？”其人弗能應也。眾皆笑之。

沒錯，我們前后所說的就是自相矛盾了，這說明了什么呢，說明我們的實現并不是一個完整的實現，那么，究竟怎樣的實現才是完整的呢？

我們先自己來想一想，在下游中調用Subscription.request(n)就可以告訴上游，下游能夠處理多少個事件，那么上游要根據下游的處理能力正確的去發送事件，那么上游是不是應該知道下游的處理能力是多少啊，對吧，不然，一個巴掌拍不響啊，這種事情得你情我愿才行。

那么上游從哪里得知下游的處理能力呢？我們來看看上游最重要的部分，肯定就是FlowableEmitter了啊，我們就是通過它來發送事件的啊，來看看它的源碼吧(別緊張，它的代碼灰常簡單)：

public interface FlowableEmitter<T> extends Emitter<T> {
    void setDisposable(Disposable s);
    void setCancellable(Cancellable c);

    /**
     * The current outstanding request amount.
     * <p>This method is thread-safe.
     * @return the current outstanding request amount
     */
    long requested();

    boolean isCancelled();
    FlowableEmitter<T> serialize();
}

FlowableEmitter是個接口，繼承Emitter，Emitter里面就是我們的onNext(),onComplete()和onError()三個方法。我們看到FlowableEmitter中有這么一個方法：

long requested();

方法注釋的意思就是當前外部請求的數量，哇哦，這好像就是我們要找的答案呢. 我們還是實際驗證一下吧.

先來看同步的情況吧：

 public static void demo1() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "current requested: " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

這個例子中，我們在上游中打印出當前的request數量，下游什么也不做。

我們先猜測一下結果，下游沒有調用request()，說明當前下游的處理能力為0，那么上游得到的requested也應該是0，是不是呢？

來看看運行結果：

D/TAG: onSubscribe
D/TAG: current requested: 0

哈哈，結果果然是0，說明我們的結論基本上是對的。

那下游要是調用了request()呢，來看看：

 public static void demo1() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "current requested: " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(10); //我要打十個！
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

這次在下游中調用了request(10)，告訴上游我要打十個，看看運行結果：

D/TAG: onSubscribe
D/TAG: current requested: 10

果然！上游的requested的確是根據下游的請求來決定的，那要是下游多次請求呢？比如這樣：

public static void demo1() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "current requested: " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(10);  //我要打十個!
                        s.request(100); //再給我一百個！
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

下游先調用了request(10), 然后又調用了request(100)，來看看運行結果：

D/TAG: onSubscribe
D/TAG: current requested: 110

看來多次調用也沒問題，做了加法。

誒加法？對哦，只是做加法，那什么時候做減法呢？

當然是發送事件啦！

來看個例子吧：

 public static void demo2() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(final FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "before emit, requested = " + emitter.requested());

                        Log.d(TAG, "emit 1");
                        emitter.onNext(1);
                        Log.d(TAG, "after emit 1, requested = " + emitter.requested());

                        Log.d(TAG, "emit 2");
                        emitter.onNext(2);
                        Log.d(TAG, "after emit 2, requested = " + emitter.requested());

                        Log.d(TAG, "emit 3");
                        emitter.onNext(3);
                        Log.d(TAG, "after emit 3, requested = " + emitter.requested());

                        Log.d(TAG, "emit complete");
                        emitter.onComplete();

                        Log.d(TAG, "after emit complete, requested = " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(10);  //request 10
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

代碼很簡單，來看看運行結果：

D/TAG: onSubscribe                        
D/TAG: before emit, requested = 10        
D/TAG: emit 1                             
D/TAG: onNext: 1                          
D/TAG: after emit 1, requested = 9        
D/TAG: emit 2                             
D/TAG: onNext: 2                          
D/TAG: after emit 2, requested = 8        
D/TAG: emit 3                             
D/TAG: onNext: 3                          
D/TAG: after emit 3, requested = 7        
D/TAG: emit complete                      
D/TAG: onComplete                         
D/TAG: after emit complete, requested = 7

大家應該能看出端倪了吧，下游調用request(n) 告訴上游它的處理能力，上游每發送一個next事件之后，requested就減一，注意是next事件，complete和error事件不會消耗requested，當減到0時，則代表下游沒有處理能力了，這個時候你如果繼續發送事件，會發生什么后果呢？當然是MissingBackpressureException啦，試一試：

public static void demo2() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(final FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "before emit, requested = " + emitter.requested());

                        Log.d(TAG, "emit 1");
                        emitter.onNext(1);
                        Log.d(TAG, "after emit 1, requested = " + emitter.requested());

                        Log.d(TAG, "emit 2");
                        emitter.onNext(2);
                        Log.d(TAG, "after emit 2, requested = " + emitter.requested());

                        Log.d(TAG, "emit 3");
                        emitter.onNext(3);
                        Log.d(TAG, "after emit 3, requested = " + emitter.requested());

                        Log.d(TAG, "emit complete");
                        emitter.onComplete();

                        Log.d(TAG, "after emit complete, requested = " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(2);   //request 2
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

還是這個例子，只不過這次只request(2), 看看運行結果：

 D/TAG: onSubscribe
 D/TAG: before emit, requested = 2
 D/TAG: emit 1
 D/TAG: onNext: 1
 D/TAG: after emit 1, requested = 1
 D/TAG: emit 2
 D/TAG: onNext: 2
 D/TAG: after emit 2, requested = 0
 D/TAG: emit 3
 W/TAG: onError: io.reactivex.exceptions.MissingBackpressureException: create: could not emit value due to lack of requests
                 at io.reactivex.internal.operators.flowable.FlowableCreate$ErrorAsyncEmitter.onOverflow(FlowableCreate.java:411)
                 at io.reactivex.internal.operators.flowable.FlowableCreate$NoOverflowBaseAsyncEmitter.onNext(FlowableCreate.java:377)
                 at zlc.season.rxjava2demo.demo.ChapterNine$4.subscribe(ChapterNine.java:80)
                 at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:72)
                 at io.reactivex.Flowable.subscribe(Flowable.java:12218)
                 at zlc.season.rxjava2demo.demo.ChapterNine.demo2(ChapterNine.java:89)
                 at zlc.season.rxjava2demo.MainActivity$2.onClick(MainActivity.java:36)
                 at android.view.View.performClick(View.java:4780)
                 at android.view.View$PerformClick.run(View.java:19866)
                 at android.os.Handler.handleCallback(Handler.java:739)
                 at android.os.Handler.dispatchMessage(Handler.java:95)
                 at android.os.Looper.loop(Looper.java:135)
                 at android.app.ActivityThread.main(ActivityThread.java:5254)
                 at java.lang.reflect.Method.invoke(Native Method)
                 at java.lang.reflect.Method.invoke(Method.java:372)
                 at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
                 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
 D/TAG: after emit 3, requested = 0
 D/TAG: emit complete
 D/TAG: after emit complete, requested = 0

到目前為止我們一直在說同步的訂閱，現在同步說完了，我們先用一張圖來總結一下同步的情況：

同步request.png

這張圖的意思就是當上下游在同一個線程中的時候，在下游調用request(n)就會直接改變上游中的requested的值，多次調用便會疊加這個值，而上游每發送一個事件之后便會去減少這個值，當這個值減少至0的時候，繼續發送事件便會拋異常了。

我們再來說說異步的情況，異步和同步會有區別嗎？會有什么區別呢？帶著這個疑問我們繼續來探究。

同樣的先來看一個基本的例子：

public static void demo3() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "current requested: " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

這次是異步的情況，上游啥也不做，下游也啥也不做，來看看運行結果：

D/TAG: onSubscribe
D/TAG: current requested: 128

哈哈，又是128，看了我前幾篇文章的朋友肯定很熟悉這個數字啊！這個數字為什么和我們之前所說的默認的水缸大小一樣啊，莫非？

帶著這個疑問我們繼續來研究一下：

 public static void demo3() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "current requested: " + emitter.requested());
                    }
                }, BackpressureStrategy.ERROR)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(1000); //我要打1000個！！
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

這次我們在下游調用了request（1000）告訴上游我要打1000個，按照之前我們說的，這次的運行結果應該是1000，來看看運行結果：

D/TAG: onSubscribe
D/TAG: current requested: 128

臥槽，你確定你沒貼錯代碼？

是的，真相就是這樣，就是128，蜜汁128。。。

what happened?

I don't know !

為了答疑解惑，我就直接上圖了：

異步request.png

可以看到，當上下游工作在不同的線程里時，每一個線程里都有一個requested，而我們調用request（1000）時，實際上改變的是下游主線程中的requested，而上游中的requested的值是由RxJava內部調用request(n)去設置的，這個調用會在合適的時候自動觸發。

現在我們就能理解為什么沒有調用request，上游中的值是128了，因為下游在一開始就在內部調用了request(128)去設置了上游中的值，因此即使下游沒有調用request()，上游也能發送128個事件，這也可以解釋之前我們為什么說Flowable中默認的水缸大小是128，其實就是這里設置的。

剛才同步的時候我們說了，上游每發送一個事件，requested的值便會減一，對于異步來說同樣如此，那有人肯定有疑問了，一開始上游的requested的值是128，那這128個事件發送完了不就不能繼續發送了嗎？

剛剛說了，設置上游requested的值的這個內部調用會在合適的時候自動觸發，那到底什么時候是合適的時候呢？是發完128個事件才去調用嗎？還是發送了一半才去調用呢？

帶著這個疑問我們來看下一段代碼：

 public static void request() {
        mSubscription.request(96); //請求96個事件
    }

public static void demo4() {
        Flowable
                .create(new FlowableOnSubscribe<Integer>() {
                    @Override
                    public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                        Log.d(TAG, "First requested = " + emitter.requested());
                        boolean flag;
                        for (int i = 0; ; i++) {
                            flag = false;
                            while (emitter.requested() == 0) {
                                if (!flag) {
                                    Log.d(TAG, "Oh no! I can't emit value!");
                                    flag = true;
                                }
                            }
                            emitter.onNext(i);
                            Log.d(TAG, "emit " + i + " , requested = " + emitter.requested());
                        }
                    }
                }, BackpressureStrategy.ERROR)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

這次的上游稍微復雜了一點點，首先仍然是個無限循環發事件，但是是有條件的，只有當上游的requested != 0的時候才會發事件，然后我們調用request（96）去消費96個事件（為什么是96而不是其他的數字先不要管），來看看運行結果吧：

D/TAG: onSubscribe
D/TAG: First requested = 128
D/TAG: emit 0 , requested = 127
D/TAG: emit 1 , requested = 126
D/TAG: emit 2 , requested = 125
  ...
D/TAG: emit 124 , requested = 3
D/TAG: emit 125 , requested = 2
D/TAG: emit 126 , requested = 1
D/TAG: emit 127 , requested = 0
D/TAG: Oh no! I can't emit value!

首先運行之后上游便會發送完128個事件，之后便不做任何事情，從打印的結果中我們也可以看出這一點。

然后我們調用request(96)，這會讓下游去消費96個事件，來看看運行結果吧：

D/TAG: onNext: 0
D/TAG: onNext: 1
  ...
D/TAG: onNext: 92
D/TAG: onNext: 93
D/TAG: onNext: 94
D/TAG: onNext: 95
D/TAG: emit 128 , requested = 95
D/TAG: emit 129 , requested = 94
D/TAG: emit 130 , requested = 93
D/TAG: emit 131 , requested = 92
  ...
D/TAG: emit 219 , requested = 4
D/TAG: emit 220 , requested = 3
D/TAG: emit 221 , requested = 2
D/TAG: emit 222 , requested = 1
D/TAG: emit 223 , requested = 0
D/TAG: Oh no! I can't emit value!

可以看到，當下游消費掉第96個事件之后，上游又開始發事件了，而且可以看到當前上游的requested的值是96(打印出來的95是已經發送了一個事件減一之后的值)，最終發出了第223個事件之后又進入了等待區，而223-127 正好等于 96。

這是不是說明當下游每消費96個事件便會自動觸發內部的request()去設置上游的requested的值啊！沒錯，就是這樣，而這個新的值就是96。

朋友們可以手動試試請求95個事件，上游是不會繼續發送事件的。

至于這個96是怎么得出來的（肯定不是我猜的蒙的啊），感興趣的朋友可以自行閱讀源碼尋找答案，對于初學者而言應該沒什么必要，管它內部怎么實現的呢對吧。

好了今天的教程就到這里了！通過本節的學習，大家應該知道如何正確的去實現一個完整的響應式拉取了，在某一些場景下，可以在發送事件前先判斷當前的requested的值是否大于0，若等于0則說明下游處理不過來了，則需要等待，例如下面這個例子。

實踐

這個例子是讀取一個文本文件，需要一行一行讀取，然后處理并輸出，如果文本文件很大的時候，比如幾十M的時候，全部先讀入內存肯定不是明智的做法，因此我們可以一邊讀取一邊處理，實現的代碼如下：

 public static void main(String[] args) {
        practice1();
        try {
            Thread.sleep(10000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void practice1() {
        Flowable
                .create(new FlowableOnSubscribe<String>() {
                    @Override
                    public void subscribe(FlowableEmitter<String> emitter) throws Exception {
                        try {
                            FileReader reader = new FileReader("test.txt");
                            BufferedReader br = new BufferedReader(reader);

                            String str;

                            while ((str = br.readLine()) != null && !emitter.isCancelled()) {
                                while (emitter.requested() == 0) {
                                    if (emitter.isCancelled()) {
                                        break;
                                    }
                                }
                                emitter.onNext(str);
                            }

                            br.close();
                            reader.close();

                            emitter.onComplete();
                        } catch (Exception e) {
                            emitter.onError(e);
                        }
                    }
                }, BackpressureStrategy.ERROR)
                .subscribeOn(Schedulers.io())
                .observeOn(Schedulers.newThread())
                .subscribe(new Subscriber<String>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        mSubscription = s;
                        s.request(1);
                    }

                    @Override
                    public void onNext(String string) {
                        System.out.println(string);
                        try {
                            Thread.sleep(2000);
                            mSubscription.request(1);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }

                    @Override
                    public void onError(Throwable t) {
                        System.out.println(t);
                    }

                    @Override
                    public void onComplete() {
                    }
                });
    }

運行的結果便是：

poetry.gif

好了，本次的教程就到這里了，謝謝大家捧場！下節見，敬請期待！
（PS：我這么用心的寫文章，你們也不給個贊嗎？）

最后編輯于：2017.12.05 07:04:24

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 228,119評論 6贊 531
死咒
序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
沈念sama閱讀 98,382評論 3贊 415
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
開封第一講書人閱讀 176,038評論 0贊 373
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 62,853評論 1贊 309
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
茶點故事閱讀 71,616評論 6贊 408
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發上，一...
開封第一講書人閱讀 55,112評論 1贊 323
城市分裂傳說
那天，我揣著相機與錄音，去河邊找鬼。笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,192評論 3贊 441
雙鴛鴦連環套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
開封第一講書人閱讀 42,355評論 0贊 288
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
沈念sama閱讀 48,869評論 1贊 334
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內容為張勛視角年9月15日...
茶點故事閱讀 40,727評論 3贊 354
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 42,928評論 1贊 369
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 38,467評論 5贊 358
?日本核電站爆炸內幕
正文年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
茶點故事閱讀 44,165評論 3贊 347
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 34,570評論 0贊 26
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 35,813評論 1贊 282
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個月前我還...
沈念sama閱讀 51,585評論 3贊 390
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
茶點故事閱讀 47,892評論 2贊 372

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

給初學者的RxJava2.0教程(九)

給初學者的RxJava2.0教程(九)

前言

正題

實踐

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

給初學者的RxJava2.0教程(九)

前言

正題

實踐

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频