RxJava2线程调度源码分析(二)

RxJava2源码浅析(一) 里我们分析RxJava2最简单的用法,实际上就是复杂一点的回调.今天一起来看看线程调度的神秘面纱,一步一步的分析,同样的我们拿一段代码来分析.

本文基于:
compile 'io.reactivex.rxjava2:rxjava:2.0.1'
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'

public static void debug() {
        Observable<Integer> observable = Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
   ①         public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "Observable thread is : " + Thread.currentThread().getName());
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
            }
        });

   ②    Consumer<Integer> consumer = new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) throws Exception {
                Log.d(TAG, "Observer thread is :" + Thread.currentThread().getName());
                Log.d(TAG, "onNext: " + integer);
            }
        };

   1.     observable.observeOn(AndroidSchedulers.mainThread())
   2.               .subscribeOn(Schedulers.newThread())
   3.               .subscribe(consumer);
    }

开始两段代码就是预处理Observable和consumer, 是很普通的对象生成.
然后在标号为1和2的两句里则是传入scheduler调度器并进行包装, 这个就是类名看起来好复杂, 经常不知道传入的对象是哪个跟哪个,还好AS的调试器比较强大,这2句代码便于方便记忆,我画了一张图.

Observable调用链.png

加上了自己的理解,能看懂就好,哈哈,最后一句是因为在初始化LambdaObserver的时候传了2个空实现.
它后面的我没画是因为跳转太深,直接贴代码:

parent.setDisposable(scheduler.scheduleDirect(new Runnable() {
            @Override
            public void run() {
                source.subscribe(parent);
            }
        }));

parent.setDisposable() 是一个set方法, 里面是安全判断.那重点就是scheduler.schedulerDirect()方法了,跟进去

public Disposable scheduleDirect(Runnable run) {
        return scheduleDirect(run, 0L, TimeUnit.NANOSECONDS);
}

public Disposable scheduleDirect(Runnable run, long delay, TimeUnit unit) {
        final Worker w = createWorker();

        final Runnable decoratedRun = RxJavaPlugins.onSchedule(run);

        w.schedule(new Runnable() {
            @Override
            public void run() {
                try {
                    decoratedRun.run();
                } finally {
                    w.dispose();
                }
            }
        }, delay, unit);

        return w;
}

首先生成了一个Worker, 它是抽象调度器scheduler的一个抽象内部类,我们就把它想象成实际工作的工人吧,它的工作需要我们指定一个调度.由谁来执行它呢,看代码:

public Worker createWorker() {
        return new NewThreadWorker(THREAD_FACTORY);
}

public NewThreadWorker(ThreadFactory threadFactory) {
        executor = SchedulerPoolFactory.create(threadFactory);
}

由一个调度池工厂方法生成一个执行者 executor.就是说当我们创建了工人后,它的领导就附带上了.
再回到scheduleDirect()方法中,下一步就是Hook检测,然后就是w.schedule正式工作了

public ScheduledRunnable scheduleActual(final Runnable run, long delayTime, TimeUnit unit, DisposableContainer parent) {
        Runnable decoratedRun = RxJavaPlugins.onSchedule(run);

        ScheduledRunnable sr = new ScheduledRunnable(decoratedRun, parent);

        if (parent != null) {
            if (!parent.add(sr)) {
                return sr;
            }
        }

        Future<?> f;
        try {
            if (delayTime <= 0) {
                f = executor.submit((Callable<Object>)sr);
            } else {
                f = executor.schedule((Callable<Object>)sr, delayTime, unit);
            }
            sr.setFuture(f);  //收尾工作
        } catch (RejectedExecutionException ex) {
            parent.remove(sr);
            RxJavaPlugins.onError(ex);
        }

        return sr;
    }

这里又new了一个Runnable . 有什么不一样吗?

public final class ScheduledRunnable extends AtomicReferenceArray<Object>
implements Runnable, Callable<Object>, Disposable {
...
}

继承了AtomicReferenceArray,看名称就是原子性的操作, 其实在Rxjava中,大量的类都继承了原子特性.有一个很重要的方法compareAndSet.

public final boolean compareAndSet(int i, E expect, E update) 

作用是以原子方式赋值.如果当前值expect==内存值,则将i位置的值以update更新,否则返回false.
再继续跟进,由于delayTime默认为0,则只需executor.submit()方法, 这个方法就是最终的执行者了.然后代码会进入ScheduledRunnable线程的run.

    @Override
    public Object call() {
        // Being Callable saves an allocation in ThreadPoolExecutor
        run();
        return null;
    }

    @Override
    public void run() {
        try {
            try {
                actual.run();
...

很明显actual就是我们的decoratedRun了. 这个run从一开始new 出来的Runnable->decoratedRun ->sr经历了3层封装,一切都为了数据安全,不难想象,它最终的回调也是一层一层往回走的.即又会回到

parent.setDisposable(scheduler.scheduleDirect(new Runnable() {
            @Override
            public void run() {
        >>>    source.subscribe(parent);    <<<
            }
        }));

请注意,此时还在子线程中呢.而且source就是ObservableObservOn对象,可以对照那张png图片看看.
但是ObservableObservOn并没有实现subscribe(), 因此由Observable来执行.

@SchedulerSupport(SchedulerSupport.NONE)
    @Override
    public final void subscribe(Observer<? super T> observer) {
        ObjectHelper.requireNonNull(observer, "observer is null");
        try {
            observer = RxJavaPlugins.onSubscribe(this, observer);

            ObjectHelper.requireNonNull(observer, "Plugin returned null Observer");

            subscribeActual(observer);
        } catch (NullPointerException e) { //
...
}

当执行到subscribeActual()时,又回到了ObservableObservOn

    @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));
        }
    }

有一点,那就是这个方法的参数是谁?它就是上上片代码的parent

final SubscribeOnObserver<T> parent = new SubscribeOnObserver<T>(s);

就是在回调时带过来的,而source成员变量是谁呢? 就是png图片中的ObservableCreate对象, scheduler呢, 是AndroidSchedulers.mainThread()生成的handlerScheduler.
紧接着主线程调度器生成了worker. 同样的,ObservableCreate也没有实现subscribe(), 被他的父类Observable执行,最后也同样的来到了subscribeActual:

    @Override
    protected void subscribeActual(Observer<? super T> observer) {
        CreateEmitter<T> parent = new CreateEmitter<T>(observer);
        observer.onSubscribe(parent);

        try {
       5.     source.subscribe(parent);
        } catch (Throwable ex) {
            Exceptions.throwIfFatal(ex);
            parent.onError(ex);
        }
    }

很熟悉的代码段,只是比上一篇的参数较复杂而已,它的类型ObservableObserveOn#ObserveOnObserver , 反正也是Oberver. 然后来到它的onSubscribe()

        @Override
        public void onSubscribe(Disposable s) {
            if (DisposableHelper.validate(this.s, s)) {
                ...
                queue = new SpscLinkedArrayQueue<T>(bufferSize);

                actual.onSubscribe(this);
            }
        }

这个actual还记得吧.就是构造ObserveOnObserver的参数SubscribeOnObserver,它的onSubscribe():

       @Override
        public void onSubscribe(Disposable s) {
            DisposableHelper.setOnce(this.s, s);
        }

数据检查的作用.回到标号5的代码.很显然实现了线程的回调.即①的位置
在执行emitter.onNext(1);时

        @Override
        public void onNext(T t) {
           ...
            if (!isDisposed()) {
                observer.onNext(t);
            }
        }

此时的observer类型是ObservableObserveOn#ObserveOnObserver,进入他的onNext():

        @Override
        public void onNext(T t) {
            if (done) {
                return;
            }

            if (sourceMode != QueueDisposable.ASYNC) {
                queue.offer(t);
            }
            schedule();
        }

queue添加了一个t (Integer)

void schedule() {
        if (getAndIncrement() == 0) {
            worker.schedule(this);
        }
    }

这个worker在执行subscribeActual时就是handlerScheduler,this是observer,紧跟着进入HandlerScheduler

        @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;
        }

看到没,线程调度的面目原来是handler来处理的.消息发送后处理run了,run是上面的this传来的,别忘了
这个执行完后,它并不是直接去运行run参数的run方法.而是先处理sr.setFuture(f) // 收尾工作. 子线程处理完成后才到达run.run()

private static final class ScheduledRunnable implements Runnable, Disposable {
        private final Handler handler;
        private final Runnable delegate;

        private volatile boolean disposed;

        ScheduledRunnable(Handler handler, Runnable delegate) {
            this.handler = handler;
            this.delegate = delegate;
        }

        @Override
        public void run() {
            try {
                delegate.run();
            } catch (Throwable t) {

剩下的就往回调了,进入ObservableObserveOn drainNormal()方法:

 void drainNormal() {
            int missed = 1;

            final SimpleQueue<T> q = queue;
            final Observer<? super T> a = actual;            
            ...

                    a.onNext(v);
                }

                missed = addAndGet(-missed);
                if (missed == 0) {
                    break;
                }
            }
        }

a = actual . actual 显然是ObservableSubscribeOn#SubscribeOnObserver对象,png上写的它真正的Observer, 真的是贯穿始末啊.a.onNext()后,进入ObservableSubscribeOn

        @Override
        public void onNext(T t) {
            actual.onNext(t);
        }

这个actual就是LambdaObserver,紧跟着进入它的onNext吧:

    @Override
    public void onNext(T t) {
        if (!isDisposed()) {
            try {
                onNext.accept(t);
            } catch (Throwable e) {
                Exceptions.throwIfFatal(e);
                onError(e);
            }
        }
    }

这个onNext地球人都知道了.
还记得吗,从进入ScheduledRunnable后子线程就死亡了,然后一直在主线程.可以说,线程的转折点就在这里

结束

当然本文只是基于一开始的代码示例,更复杂的也是同样的,加入了上游事件的循环.谢谢大家!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容