Rxjava有三个原因：
第一个是代码的简洁度，链式。
第二个是响应式框架，观察者模式。
第三个就是它是一个异步的框架，线程切换功能极其强大，可任意指定观察者发生的线程以及被观察者的线程，随意调整极其强大（观察者发生的线程只能更改一次，被观察的可以随意切换
Observable和Subscriber大家已经很熟悉了，分别是被观察者和观察者
在使用RxJava过程中我们一般都是三步
第一步创建Observable，第二部创建Subscriber，第三步通过subscribe（）方法达到订阅的目的
subscribeOn()只能定义一次，而observerOn()方法可以定义多次，也就是可以通过observerOn方法实现线程位置的多重转换
通过subscribeOn(Schedulers.io())，
observeOn(AndroidSchedulers.mainThread())轻松的实现线程的切换
schedule.newThread()：直接开启一个新的线程。
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() 指定
schedule.io()：顾名思义，开启一个io线程，完成对网络请求和文件读写数据库增删改查等操作。可能这时候有人就要问了，那io和newThread有什么区别呐？其实区别在于，newThread不管有没有线程，他都会去重新开启一个新的线程来进行操作，并且没线程池维护。但是io的线程是无上限的，并且最大的一个好处是它会去重用空闲的线程，而不是每次都开启一个线程来使用，效率上比newThread要高。所以，一般我们在使用的时候是直接使用io这个方法。
android有一个专门的线程，AndroidSchedule.mainThread()，专门用来指定操作在主线程完成。
subscribeOn是影响生产者（Observable）生产数据的线程的，通常我们只需要指定生产者在某一个特定的线程生产数据就可以满足我们的需求，至少我还没遇到过需要在生产数据的过程中去切换生产者所在的线程的情况。绝大多数我们需要变化线程的场景都是在数据生产之后，Rx里面就使用observeOn来指定各种operator和subcriber的线程，因为这些本质上都是数据的消费者。消费者可以任意切换自己接受处理数据的线程，足以满足我们的需求
结论
多线程通信，只能是线性来实现
Hanlder 是基于生产消费模式来进行现实的
observeOn修改的是他 下面 的代码执行的线程 向下的订阅
subscribeOn修改的是他 上面 执行代码的线程 向上的订阅
Rxandroid 子线程执行后，在subscribe（）时，会一步一步去执行observable.onSubscribe.call(),对于SubscribeOn来说他的call（）方法的真正实现就是在这里。那么还要注意一点的是这个call（）的回调时机，这里要和ObserveOn（）做比较，稍后再分析。回到这里的call方法，首先通过外部传入的scheduler创建Worker - inner对象，接着在inner中执行了一段代码，Action0中call（）方法这段代码就在worker线程中执行了，也就是此刻线程进行了切换。
注意最后一句代码source.unsafeSubscribe(s)就是将当前的Observable与上一个Observable通过onSubscribe关联起来。那么如果上一个Observable也是一个subscribeOn（）产生的那么会出现什么情况？很显然最终会切换到上一个subscribeOn指定的线程中
https://blog.csdn.net/chenkai19920410/article/details/52515771
