我用RxJava 的主要原因是它对我们数据流向的一种抽象，用好了，能梳理好代码结构，不致于让代码写到哪里就是哪里，这种写到哪里就是哪里的代码，真的对别人对自己都很不负责，对别人来说，维护起来想骂人，对于自己来说，其实是给自己挖坑。
很多时候，我发现大部分人用RxJava，看一下网上的demo怎么使用的，然后就模仿着用，结果用着用着就变形了，怎么变形的？因为模仿只能学会一招，接下来发生需求变化的时候，就用这一招来套，结果就出现了很多搞笑的使用场景。
比如，网上介绍的RxJava，大致就是这样的，然后有人模仿用的时候，就记住了这个模式，然后心里面大致知道上面大括号内是运行在子线程，然后下面大括号内，就是主线程。这个时候如果onNext执行完成了，还需要去请求服务器，或者是其他耗时操作，然后有人就来了，灵机一动，我再创建一个Observable.create不就行了，于是在onNext下面又嵌套一层Observable.create，此时，代码应该已经很长了，差不多就是这样：
Observable.create(new ObservableOnSubscribe<String>() {
@Override
public void subscribe(ObservableEmitter<String> emitter) throws Exception {
//请求服务器获取数据
emitter.onNext("数据1");
emitter.onComplete();
}
})
.observeOn(AndroidSchedulers.mainThread())//回调在主线程
.subscribeOn(Schedulers.io())//执行在io线程
.subscribe(new Observer<String>() {
...
@Override
public void onNext(String value) {
Log.e(TAG,"onNext:"+value);
Observable.create(new ObservableOnSubscribe<String>() {
//再次去请求服务器
...
}
}
...
});
这就是还不太了解RxJava是怎么控制数据流的，RxJava做成链式调用的方式，很多时候是为了让每一个步骤都清晰，例如：
source //数据源
.operator1() //操作1，先请求服务器接口
.operator2() //操作2，获取本地数据库信息
.operator3() //操作3，比较本地数据库内容并且更新数据库
.operatorN() //操作N，可能还有很多操作。。。
.subscribe(consumer) // 开始去消费我最终的数据，比如：拿到列表数据，我显示出来列表
按照这样的方式去维护我们的一个数据流程，就能够很好的整理我们的代码流程，一个整体的流程，就知道这整个流是做什么的。
RxJava的整个设计，都是围绕对流做处理，你不需要去关心线程启动关闭，因为人家有任务调度器，就是专门干这个事情的，你只需要
添加指定的任务调度器类型放到subscribeOn中就行了。
当深刻的认识到RxJava的宗旨就是对流做处理，同时又能够保证复杂业务也能梳理的很好的时候，这就很足够了，同时这个将能够帮助你更好的理解源吗的设计。
既然始终是围绕着数据流来设计的框架，那肯定需要考虑到各种各样的流：
合并流（比如你要显示一个内容的时候，需要多种服务器的数据，那么就存在多种数据源，数据源就需要合并，也就有了合并流）
转换流（比如你获取过来的数据需要转换一下数据类型）
一堆对流进行处理的操作符，所以你能看到RxJava中有很多很多的操作符，这些东西本质上就是为了方便你去更好的处理流，刚开始学习RxJava的时候，千万不要给操作符给淹没了，因为他只是一个帮助你提升效率的工具，有它没它，你也可以用好RxJava写出好的数据流向代码，让代码清晰可维护。
RxJava只有你能深刻的理解它是对数据流的控制，保证代码清晰的一种工具，你才能用好它，否者你会发现滥用RxJava将会影响代码阅读带来的反向的效果。
祝君写出更好的代码。
