2. 程式人生 > >給初學者的RxJava2.0教程(九)

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

阿新 • • 發佈：2019-02-03

出處：http://www.jianshu.com/p/36e0f7f43a51

前言

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

正題

先來回顧一下上上節，我們講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());

相關推薦

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

出處：http://www.jianshu.com/p/36e0f7f43a51 前言 好久不見朋友們，最近一段時間在忙工作上的事情，沒來得及寫文章，這兩天正好有點時間，趕緊寫下了這篇教程，免得大家說我太監了。 正題 先來回顧一下上上節，我們講Flowable的

給初學者的RxJava2.0教程(二)（轉）

pos 添加 tex 工作 -i com ava gis ket 前言 上一節教程講解了最基本的RxJava2的使用, 在本節中, 我們將學習RxJava強大的線程控制. 正題 還是以之前的例子, 兩根水管: RxJava 正常情況下, 上遊和下遊是工作在同一個

給初學者的RxJava2.0教程(三)（轉）

app 創建 roi 情況下 ids table 因此 next 上下 前言 上一節教程講解了最基本的RxJava2的使用, 在本節中, 我們將學習RxJava強大的線程控制. 正題 還是以之前的例子, 兩根水管: RxJava 正常情況下, 上遊和下遊是工作在

給初學者的RxJava2.0教程(五)（轉）

roi 直接 ror 兩個 defined create 了解 作者 一點 前言 大家喜聞樂見的Backpressure來啦. 這一節中我們將來學習Backpressure. 我看好多吃瓜群眾早已坐不住了, 別急, 我們先來回顧一下上一節講的Zip. 正題 上一節中我們說

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

前言 上一節講解了執行緒排程, 並且舉了兩個實際中的例子, 其中有一個登入的例子, 不知大家有沒有想過這麼一個問題, 如果是一個新使用者, 必須先註冊, 等註冊成功之後再自動登入該怎麼做呢. 很明顯, 這是一個巢狀的網路請求, 首先需要去請求註冊, 待註冊成功回調了再去請求登入的介面.

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

前言 大家喜聞樂見的Backpressure來啦. 這一節中我們將來學習Backpressure. 我看好多吃瓜群眾早已坐不住了, 別急, 我們先來回顧一下上一節講的Zip. 正題 上一節中我們說到Zip可以將多個上游傳送的事件組合起來發送給下游, 那大家有沒有想過一

給初學者的RxJava2.0教程(三)：【操作符：Map、FlatMap、ConcatMap】

前言 上一節講解了執行緒排程, 並且舉了兩個實際中的例子, 其中有一個登入的例子, 不知大家有沒有想過這麼一個問題, 如果是一個新使用者, 必須先註冊, 等註冊成功之後再自動登入該怎麼做呢. 很明顯, 這是一個巢狀的網路請求, 首先需要去請求

給初學者的RxJava2.0教程(二)：【執行緒控制】

前言 上一節教程講解了最基本的RxJava2的使用, 在本節中, 我們將學習RxJava強大的執行緒控制. 正題 還是以之前的例子, 兩根水管: 正常情況下, 上游和下游是工作在同一個執行緒中的, 也就是說上游在哪個執行緒發事件,

從零開始的RxJava2.0教程(四)在安卓中的應用

1. 前言 2. RxAndroid RxAndroid是RxJava針對Android平臺的擴充套件庫。 曾幾何時，RxAndroid確實提供了很多的實用的方法，但後來社群上很多人對這庫的結構有意見，然後作者便進行了重構，現在只保留了Androi

從零開始的RxJava2.0教程(一)基礎

1. 為什麼寫這篇文章 RxJava這些年越來越流行，而上月末(2016.10.29)釋出了2.0正式版，但網上大部分關於RxJava的教程都是1.x的。關於2.0的教程基本是介紹1.x和2.x的區別，對於RxJava的老使用者來說，自然看看和1.x的區別

從零開始的RxJava2.0教程(二)操作符

1. 前言 在上一篇中，我介紹了RxJava 2.0的一些基礎知識，同時也介紹了map()操作符。這篇blog將介紹許多RxJava中的操作符，RxJava的強大性就來自於它所定義的操作符。 首先先看一個例子： 2. 準備工作 假設我的 Fl

RxJava2.0教程（一）

學習RxJava2需要先學習RxJava1嗎？ 這個問題就像論壇經常問學Java前需要先學習C語言嗎，這裡就不引戰了！（PHP是世界上最好的語言！！） 答案明顯不是，如果你以前學過RxJava1，那麼對於RxJava2只需要看看更新了哪些東西就行了，其最核心的思想並沒有變化，如果你沒學過RxJava1，沒有

給初學者的weex教程(一)

前言 隨著阿里開源的構建高效能、可擴充套件的原生應用跨平臺開發方案--weex的釋出，相信很多人都湧向了這股浪潮中，我也是從RN中抽了一腿出來踏進了這個“坑”中。隨著阿里勤奮的開發人員和我們不斷踏坑的開發者的填坑，現在weex已經來到V.13.0版本了，相對於剛開始的時

【Unity3D基礎教程】給初學者看的Unity教程（零）：如何學習Unity3D

cos 詳解 component lock index unity3d遊戲 design 技術棧 log 【Unity3D基礎教程】給初學者看的Unity教程（零）：如何學習Unity3D http://www.cnblogs.com/neverdie/p/How_To_

沒有基礎可以學習大資料嗎？0基礎怎麼學習大資料？給初學者支幾招

小白如何學習大資料技術？大資料怎麼入門？怎麼做大資料分析？資料科學需要學習那些技術？大資料的應用前景等等問題，已成為熱門大資料領域熱門問題，以下是對新手如何學習大資料技術問題的解答~ 大資料開發學習可以按照以下內容進行學習 第一階段：JavaSE+MySql+Linux

最簡單易懂的RxJava2.0學習教程之RxJava2的執行緒排程（二）

一、RxJava2執行緒排程 使用RxJava的時候，在沒有切換執行緒的情況下, 上游(observable)和下游(observer)是工作在同一個執行緒中的,即都在主執行緒中。 話不多說上程式碼： Observable<Integer>

最簡單易懂的RxJava2.0學習教程之RxJava2的基本使用（一）

去年RxJava2就釋出了，在這之後一直做專案都在使用Rxjava2，覺得特別好用，目前網上的的資料很多，對於以前使用過RxJava1的朋友來說只需要看看更新文件就知道怎麼使用了，但還有一些以前沒用過RxJava的朋友可能就不知道怎麼辦了，不知道該看RxJava

【Unity3D基礎教程】給初學者看的Unity教程（六）：理解Unity的新GUI系統（UGUI）

理解UGUI的基礎架構 UGUI是Unity在4.6中引入的新的GUI系統，與傳統的中介軟體NGUI相比，這套新GUI系統有幾個核心亮點： 放棄了Atlas的概念，使用Packing Tag的方式來進行圖集的規劃 放棄了depth來確定UI顯示層級的概念，使用Hierarchy的SiblingIndex

【Unity3D基礎教程】給初學者看的Unity教程（二）：所有指令碼元件的基類 -- MonoBehaviour的前世今生

引子 上一次我們講了GameObject，Compoent，Time，Input，Physics，其中Time，Input，Physics都是Unity中的全域性變數。GameObject是遊戲中的基本物件。GameObject是由Component組合而成的，GameObject本身必須有

【Unity3D基礎教程】給初學者看的Unity教程（五）：詳解Unity3D中的協程（Coroutine）

為什麼需要協程 在遊戲中有許多過程（Process）需要花費多個邏輯幀去計算。 你會遇到“密集”的流程，比如說尋路，尋路計算量非常大，所以我們通常會把它分割到不同的邏輯幀去進行計算，以免影響遊戲的幀率。 你會遇到“稀疏”的流程，比如說遊戲中的觸發器，這種觸發器大多數時候什麼也不做，但