上一篇文章：Rxjava2源碼淺析（一）
分析了最基礎的一套流程，今天呢就略加一些常用的操作吧。
使用范例
上次我們在建立關系的時候就是這樣光禿禿的一句話
observable.subscribe(observer);
這在平時使用的時候顯然是不夠用的，Rxjava的優勢是什么？切換線程肯定要算一個啊，所以我們看一下下面這種使用方法。
observable.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(observer);
這樣就完成了在newThread中運行被觀察者，在主線程中觀察。下面就進入源碼時間了~
先從參數開始看起：
public static Scheduler newThread() {
return RxJavaPlugins.onNewThreadScheduler(NEW_THREAD);
}
然后又調用了
@NonNull
public static Scheduler onNewThreadScheduler(@NonNull Scheduler defaultScheduler) {
Function<? super Scheduler, ? extends Scheduler> f = onNewThreadHandler;
if (f == null) {
return defaultScheduler;
}
return apply(f, defaultScheduler);
}
這里的onNewThreadHandler又是什么呢？
static volatile Function<? super Scheduler, ? extends Scheduler> onNewThreadHandler;
可以看到是一個類型轉換的Funtion<>，暫時不用去管它，因為現在肯定是為空的，所以就會返回我們傳進去的defaultScheduler也就是NEW_THREAD，這個是Schedulers內的一個變量
static final Scheduler NEW_THREAD;
這個NEW_THREAD又是什么呢？跟蹤它在Schedulers內部的調用。
NEW_THREAD = RxJavaPlugins.initNewThreadScheduler(new Callable<Scheduler>() {
@Override
public Scheduler call() throws Exception {
return NewThreadHolder.DEFAULT;
}
});
發現了有個static字段內部對它進行了初始化操作。
還是從參數開始分析，發現這是一個Callable對象，和Runable大同小異不過可以返回結果，這里就在call方法中返回了一個Scheduler對象NewThreadHolder.DEFAULT
static final class NewThreadHolder {
static final Scheduler DEFAULT = new NewThreadScheduler();
}
這里就將創建線程的任務從Schedulers移到了NewThreadScheduler
static {
int priority = Math.max(Thread.MIN_PRIORITY, Math.min(Thread.MAX_PRIORITY,
Integer.getInteger(KEY_NEWTHREAD_PRIORITY,Thread.NORM_PRIORITY)));
THREAD_FACTORY = new RxThreadFactory(THREAD_NAME_PREFIX, priority);
}
private static final RxThreadFactory THREAD_FACTORY;
public NewThreadScheduler() {
this(THREAD_FACTORY);
}
public NewThreadScheduler(ThreadFactory threadFactory) {
this.threadFactory = threadFactory;
}
我們看到NewThreadScheduler初始化中還包含著RxThreadFactory的初始化，至于它的作用到現在還不得而知，暫且擱置，回到主方法中。接著從從subscribeon開始分析：
public final Observable<T> subscribeOn(Scheduler scheduler) {
ObjectHelper.requireNonNull(scheduler, "scheduler is null");
return RxJavaPlugins.onAssembly(new ObservableSubscribeOn<T>(this, scheduler));
}
上來第一行還是老樣子先進行非空判斷，然后第二行這個我們是不是也看著很眼熟呢？沒錯。。。
public static <T> Observable<T> create(ObservableOnSubscribe<T> source) {
ObjectHelper.requireNonNull(source, "source is null");
return RxJavaPlugins.onAssembly(new ObservableCreate<T>(source));
}
這跟第一個步驟中的create長的簡直一模一樣。所以重點就來到了
new ObservableSubscribeOn<T>(this, scheduler)
該方法為：
public ObservableSubscribeOn(ObservableSource<T> source, Scheduler scheduler) {
super(source);
this.scheduler = scheduler;
}
暫時沒啥好說的。。。先跳過。。。
subscribeon就先擱置一下，
然后看observeron,參數就不分析了，和subscribeon的流程大同小異,唯一不同的就是其中是通過Looper.getMainLooper()來得到主線程的。后面有機會的話也會專門來寫一篇文章記錄一下自己關于Looper和Handler的線程和消息機制的學習。
@CheckReturnValue
@SchedulerSupport(SchedulerSupport.CUSTOM)
public final Observable<T> observeOn(Scheduler scheduler) {
return observeOn(scheduler, false, bufferSize());
}
這里的buffersize
public static int bufferSize() {
return Flowable.bufferSize();
}
public static int bufferSize() {
return BUFFER_SIZE;
}
static final int BUFFER_SIZE;
static {
BUFFER_SIZE = Math.max(16, Integer.getInteger("rx2.buffer-size", 128));
}
可以看到這個buffersize就是一個緩沖區的大小，一個int類型的參數，不過和flowable牽扯在了一起，這個flowable也是Rxjava2的新特性--背壓，這里先不多講了，都放到后面的文章來說。主要來看這個observeon
public final Observable<T> observeOn(Scheduler scheduler, boolean delayError, int bufferSize) {
ObjectHelper.requireNonNull(scheduler, "scheduler is null");
ObjectHelper.verifyPositive(bufferSize, "bufferSize");
return RxJavaPlugins.onAssembly(new ObservableObserveOn<T>(this, scheduler, delayError, bufferSize));
}
它的前兩行
ObjectHelper.requireNonNull(scheduler, "scheduler is null");
ObjectHelper.verifyPositive(bufferSize, "bufferSize");
都是驗證合理性的。第一行出現很多次就不用說了。第二行
public static int verifyPositive(int value, String paramName) {
if (value <= 0) {
throw new IllegalArgumentException(paramName + " > 0 required but it was " + value);
}
return value;
}
就是說我們的buffersize一定要是一個正數，這也是合情合理且應該的。
然后就又看到我們的老朋友了RxJavaPlugins.onAssembly。。。
我們前面的分析也有了經驗，所以這里會return 里面的參數 new ObservableObserveOn< T >(this, scheduler, delayError, bufferSize)向上轉型為一個Observable，之前也分析過，
ObservableObserveOn < T > 中會重寫
@Override
protected void subscribeActual(Observer<? super T> observer) {
if (scheduler instanceof TrampolineScheduler) {
source.subscribe(observer);
} else {
Scheduler.Worker w = scheduler.createWorker();
source.subscribe(new ObserveOnObserver<T>(observer, w, delayError, bufferSize));
}
}
這里的scheduler.createWorker是AndroidScheduler.MainThread
@Override
public Worker createWorker() {
return new HandlerWorker(handler);
}
而這個createWork（）
@Override
public Worker createWorker() {
return new HandlerWorker(handler);
}
private static final class HandlerWorker extends Worker {
private final Handler handler;
private volatile boolean disposed;
HandlerWorker(Handler handler) {
this.handler = handler;
}
@Override
public Disposable schedule(Runnable run, long delay, TimeUnit unit) {
if (run == null) throw new NullPointerException("run == null");
if (unit == null) throw new NullPointerException("unit == null");
if (disposed) {
return Disposables.disposed();
}
run = RxJavaPlugins.onSchedule(run);
ScheduledRunnable scheduled = new ScheduledRunnable(handler, run);
Message message = Message.obtain(handler, scheduled);
message.obj = this; // Used as token for batch disposal of this worker's runnables.
handler.sendMessageDelayed(message, Math.max(0L, unit.toMillis(delay)));
// Re-check disposed state for removing in case we were racing a call to dispose().
if (disposed) {
handler.removeCallbacks(scheduled);
return Disposables.disposed();
}
return scheduled;
}
@Override
public void dispose() {
disposed = true;
handler.removeCallbacksAndMessages(this /* token */);
}
@Override
public boolean isDisposed() {
return disposed;
}
}
在new ObserveOnObserver< T >(observer, w, delayError, bufferSize)中，我們就選兩個方法來看一下就可以了
@Override
public void onSubscribe(Disposable s) {
if (DisposableHelper.validate(this.s, s)) {
this.s = s;
if (s instanceof QueueDisposable) {
@SuppressWarnings("unchecked")
QueueDisposable<T> qd = (QueueDisposable<T>) s;
int m = qd.requestFusion(QueueDisposable.ANY | QueueDisposable.BOUNDARY);
if (m == QueueDisposable.SYNC) {
sourceMode = m;
queue = qd;
done = true;
actual.onSubscribe(this);
schedule();
return;
}
if (m == QueueDisposable.ASYNC) {
sourceMode = m;
queue = qd;
actual.onSubscribe(this);
return;
}
}
queue = new SpscLinkedArrayQueue<T>(bufferSize);
actual.onSubscribe(this);
}
}
@Override
public void onNext(T t) {
if (done) {
return;
}
if (sourceMode != QueueDisposable.ASYNC) {
queue.offer(t);
}
schedule();
}
其中的schedule方法比較重要
void schedule() {
if (getAndIncrement() == 0) {
worker.schedule(this);
}
}
而這個schedule
@NonNull
public Disposable schedule(@NonNull Runnable run) {
return schedule(run, 0L, TimeUnit.NANOSECONDS);
}
就調用了之前的HandlerScheduler里面的schedule方法
@Override
public Disposable schedule(Runnable run, long delay, TimeUnit unit) {
if (run == null) throw new NullPointerException("run == null");
if (unit == null) throw new NullPointerException("unit == null");
if (disposed) {
return Disposables.disposed();
}
run = RxJavaPlugins.onSchedule(run);
ScheduledRunnable scheduled = new ScheduledRunnable(handler, run);
Message message = Message.obtain(handler, scheduled);
message.obj = this; // Used as token for batch disposal of this worker's runnables.
handler.sendMessageDelayed(message, Math.max(0L, unit.toMillis(delay)));
// Re-check disposed state for removing in case we were racing a call to dispose().
if (disposed) {
handler.removeCallbacks(scheduled);
return Disposables.disposed();
}
return scheduled;
}
其中
run = RxJavaPlugins.onSchedule(run);
ScheduledRunnable scheduled = new ScheduledRunnable(handler, run);
Message message = Message.obtain(handler, scheduled);
message.obj = this;
// Used as token for batch disposal of this worker's runnables.
handler.sendMessageDelayed(message, Math.max(0L, unit.toMillis(delay)));
就完成了在MainThread中的觀察，因為我們的handler就是剛剛new Handler（）的時候傳入了Looper.getMainLooper（）。
至于subscribeon是如何切換線程的。。還沒看出來。。明天再說吧。。。
