又是周一的一个开始，今天我上班还迟到了，真是尴尬啊，好了废话不多说了，今天我们来总结下subscribeOn，我们先来段代码：
上面我使用了2次subscribeOn，经常有人说道，我们不管使用多少次subscribeOn，我们都是以最上面的那个为准，为啥这样说呢，今天我们来根据源码来说说
我们点击最后一个subscribeOn的源码
public final class ObservableSubscribeOn<T> extends AbstractObservableWithUpstream<T, T> {
final Scheduler scheduler;
public ObservableSubscribeOn(ObservableSource<T> source, Scheduler scheduler) {
super(source);//C部分的
this.scheduler = scheduler;
}
//省略了
在这里我想说下你最好也打开源码跟着看不然到了后面可能会混乱，首先我们传入了source进来，然后我们对它进行保存了，因为我们调用了super(source)，source是什么？它是我们的ObservableMap转换成的Observable，也就是我们C部分的东西，我给你们看看map的代码：
public final <R> Observable<R> map(Function<? super T, ? extends R> mapper) {
ObjectHelper.requireNonNull(mapper, "mapper is null");
return RxJavaPlugins.onAssembly(new ObservableMap<T, R>(this, mapper));
}
以上者段代码是map里面的，它最后返回的是Observable，
所以source就是指的map这里的这个Observable
public final Observable<T> subscribeOn(Scheduler scheduler) {
ObjectHelper.requireNonNull(scheduler, "scheduler is null");
//这里的this，就表示了map里面的Observable
return RxJavaPlugins.onAssembly(new ObservableSubscribeOn<T>(this, scheduler));
}
我们调用完第二个subscribeOn就去订阅了
public final class ObservableSubscribeOn<T> extends AbstractObservableWithUpstream<T, T> {
final Scheduler scheduler;
public ObservableSubscribeOn(ObservableSource<T> source, Scheduler scheduler) {
super(source);
this.scheduler = scheduler;
}
//直接执行这里的代码
@Override
public void subscribeActual(final Observer<? super T> s) {
//这里new了一个SubscribeOnObserver
final SubscribeOnObserver<T> parent = new SubscribeOnObserver<T>(s);
//这里的这个s，指的是我们E部分的
//subscribe(new Observer<String>() {onSubscribe}里面这么一个东西
s.onSubscribe(parent);
// setDisposable()将子线程的操作加入Disposable管理中
//我们回通过线程来调用这里的run方法
parent.setDisposable(scheduler.scheduleDirect(new Runnable() {
@Override
public void run() {
//这里的soruce是指的是C部分的，它会去执行C部分里面的subscribeActual
source.subscribe(parent);
}
}));
}
static final class SubscribeOnObserver<T> extends AtomicReference<Disposable> implements Observer<T>, Disposable {
final Observer<? super T> actual;//这里指的是E部分的代码
final AtomicReference<Disposable> s;
SubscribeOnObserver(Observer<? super T> actual) {
this.actual = actual;
this.s = new AtomicReference<Disposable>();
}
@Override
public void onSubscribe(Disposable s) {
DisposableHelper.setOnce(this.s, s);
}
@Override
public void onNext(T t) { //map
actual.onNext(t);//调用E部分的代码
}
@Override
public void onError(Throwable t) {
actual.onError(t);//调用E部分的代码
}
@Override
public void onComplete() {
actual.onComplete();//调用E部分的代码
}
@Override
public void dispose() {
DisposableHelper.dispose(s);
DisposableHelper.dispose(this);
}
@Override
public boolean isDisposed() {
return DisposableHelper.isDisposed(get());
}
//这个方法在上面的parent.setDisposable中被手动调用，为了将Schedulers返回的Worker加入管理
void setDisposable(Disposable d) {
DisposableHelper.setOnce(this, d);
}
}
actual始终表示我们的下一级
如果你要问我为啥会直接去调用了ObservableSubscribeOn的代码呢，你先看看我前面分析的文章吧，嘻嘻，我就不想多写了
SubscribeOnObserver 继承了AtomicReference，实现了Observer，其实跟map里面的MapObserver很类似了，都是一个包装类
上面代码中，我们看看scheduler.scheduleDirect（new Runnable()）的源码
public Disposable scheduleDirect(Runnable run) {
return scheduleDirect(run, 0L, TimeUnit.NANOSECONDS);
}
//传入了Runnable，然后立即去执行
scheduleDirect代码：
public Disposable scheduleDirect(Runnable run, long delay, TimeUnit unit) {
//Worker是实现了Disposable
final Worker w = createWorker();
//这个不重要
final Runnable decoratedRun = RxJavaPlugins.onSchedule(run);
//Worker中的线程执行任务，
w.schedule(new Runnable() {
@Override
public void run() {
try {
//decoratedRun这里的这个就是我们传递进来的接口，去调用我们的run()方法
decoratedRun.run();
} finally {
w.dispose();
}
}
}, delay, unit);
return w;
}
现在它去执行了run方法
parent.setDisposable(scheduler.scheduleDirect(new Runnable() {
@Override
public void run() {
//source我们的C部分代码，它就会去执行
//关系的订阅就发生在了线程里面
source.subscribe(parent);
//ObservableMap里面的subscribeActual，这样是不是就跟我们之前讲解map的时候一样了
}
}));
这样你们是否就想明白了呢？那么我们现在就可以简化下代码了现在代码变成这样了，我们现在就当没有刚刚的那最后一个subScribeOn，然后再来想想刚刚我讲解的subScribeOn
如果你懂了之前的Observable.create 和 map的话，以及刚刚无所讲的subscribeOn你应该很快就想明白了，下面我再弄张图，你应该会想明白了
也就是我们每次去执行构造的时候，都会保存上次的source
我不知道这样对不对，如有错误的地方，请指正
上一篇文章：http://www.jianshu.com/p/460c27d900fe
参考文章：http://blog.csdn.net/zxt0601/article/details/61614799
