友好 RxJava2.x 源码解析（三）zip 源码分析

系列文章：
友好 RxJava2.x 源码解析（一）基本订阅流程
友好 RxJava2.x 源码解析（二）线程切换
友好 RxJava2.x 源码解析（三）zip 源码分析

本文基于 RxJava 2.1.9

• 前言
• 示例代码
• 源码解析
• 可视化
• 后记

前言

距离前两篇文章已经过去三个月之久了，终于补上第三篇了。第三篇预期就是针对某一个操作符的源码进行解析，选择了 Observable.zip 的原因一是司里这块用的比较多，再一个笔者觉得这个操作符十分强大，想去探索一番 zip 操作符是如何实现这样的骚操作，如果读者还不了解 zip 操作符，建议查看文档并上手一番，文档地址：Zip · ReactiveX文档中文翻译

示例代码

import io.reactivex.Observable;
import io.reactivex.ObservableSource;
import io.reactivex.functions.BiFunction;

public class Test {
    @SuppressWarnings("ResultOfMethodCallIgnored")
    public static void main(String[] args) {
        Observable.zip(first(), second(), zipper())
                .subscribe(System.out::println);
    }

    private static ObservableSource first() {
        return Observable.create(emitter -> {
                    Thread.sleep(1000);
                    emitter.onNext("11");
                    emitter.onNext("12");
                    emitter.onNext("13");
                }
        );
    }

    private static ObservableSource second() {
        return Observable.create(emitter -> {
                    emitter.onNext("21");
                    Thread.sleep(2000);
                    emitter.onNext("22");
                    Thread.sleep(3000);
                    emitter.onNext("23");
                }
        );
    }

    private static BiFunction zipper() {
        return (s1, s2) -> s1 + "，" + s2;
    }
}

hello world 级别的代码就是为了 hello world. —— 鲁迅

如上所示，操作过 zip 操作符的读者们应该都知道，会在一秒后输出【11，21】，紧接着两秒后输出【12，22】，再紧接着三秒后输出【13，23】。

源码解析

经过前两篇文章的阅读，笔者相信读者们能很快地找到 ObservableZip 这个类，这个类就是实现具体 zip 操作的核心类，同样地，直接针对该类的 subscribeActual(Observer) 解析，简化后源码如下：

public void subscribeActual(Observer s) {
    // sources 是上游 ObservableSource 数组
    // 在本案例中也就是上面 first() 和 second() 方法传回的 ObservableSource
    ObservableSource[] sources = this.sources;
    
    ZipCoordinator zc = new ZipCoordinator(s, zipper, count, delayError);
    zc.subscribe(sources, bufferSize);
}

简化后可以看到还是很简单的，所以下步就是了解 ZipCoordinator 类和其 subscribe() 方法的实现了，ZipCoordinator 构造函数和 ZipCoordinator#subscribe() 代码简化如下 ——

    ZipCoordinator(Observer actual, int count) {
        this.actual = actual;
        this.observers = new ZipObserver[count];
        this.row = (T[])new Object[count];
    }

    public void subscribe(ObservableSource[] sources, int bufferSize) {
        ZipObserver[] s = observers;
        int len = s.length;
        for (int i = 0; i < len; i++) {
            s[i] = new ZipObserver(this, bufferSize);
        }
        actual.onSubscribe(this);
        for (int i = 0; i < len; i++) {
            sources[i].subscribe(s[i]);
        }
    }

大致做了以下几件事：

• 构造函数中初始化了一个和上游 ObservableSource 一样数量大小（在本案例中是2） 的 ZipObserver 数组和 T 类型的数组。
• ZipCoordinator#subscribe() 中初始化了 ZipObserver 数组并让上游 ObservableSource 分别订阅了对应的 ZipObserver。

经过前面的文章分析我们知道，上游的 onNext(T) 方法会触发下游的 onNext(T) 方法，所以下一步来看看 ZipObserver 的 onNext(T) 方法实现 ——

@Override
public void onNext(T t) {
    queue.offer(t);
    parent.drain();
}

可以看到，源码十分的简单，一是入队，二是调用 ZipCoordinator#drain() 方法，精简如下 ——

public void drain() {
    final ZipObserver[] zs = observers;
    final Observer a = actual;
    // row 在我们前面提到过
    final T[] os = row;


    for (; ; ) {
        int i = 0;
        int emptyCount = 0;
        for (ZipObserver z : zs) {
            if (os[i] == null) {
                boolean d = z.done;
                T v = z.queue.poll();
                boolean empty = v == null;

                if (!empty) {
                    os[i] = v;
                } else {
                    emptyCount++;
                }
            } else {
                // ...
            }
            i++;
        }

        if (emptyCount != 0) {
            break;
        }

        R v = zipper.apply(os.clone();

        a.onNext(v);

        Arrays.fill(os, null);
    }
}

先从实际场景解析流程，再来总结 ——

第一个事件应该是上游 first() 返回的 ObservableSource 中发射的【11】，最终在 ZipObserver#onNext(T) 方法中，该事件首先被塞入队列，再触发上述的 ZipCoordinator#drain()，在 drain() 方法中会进入 ZipObserver 的遍历 ——

• 第一次：【11】作为第一个事件，此时 os 中所有元素应该都是 null，所以会走入上面的分支，接着从第一个 ZipObserver 的队列中 poll 一个值，这时队列中有且只有刚刚塞入的【11】事件，它将被填入 os[0] 的位置中。
• 第二次：os[1] 为 null，同样会走入上分支，此时试图从第二 ZipObserver 中 poll 一个值，但是此时第二个 ZipObserver 中队列中肯定是没有值的，因为【21】这个事件1000毫秒后才会被发射出来，所以 emptyCount++。

for 循环跳出后，由于 emptyCount 不为0，死循环结束。

第二个事件也是由 first() 发射过来的（【12】）， 当第二个事件发射过来的时候——

• 第一次：os[0] 不为 null，走下分支，然而下分支在大部分情况下并不会执行什么逻辑，所以笔者在此处省略了。
• 第二次：os[1] 为 null，接着 emptyCount++，结束死循环。

同样地，第三个事件（【13】）发射过来的时候，走同样的逻辑。

但是1000毫秒后，第「四」个事件由 second() 发射（也就是【21】）的时候，事情就不一样了——

• 第一次：os[0] 不为 null，走下分支，忽略。
• 第二次：os[1] 为 null，走上分支，此时试图从第二个 ZipObserver 中 poll 一个值，此时有值吗？有——【21】此时出队并被塞入 os[1] 中。

for 循环跳出后，经过 zipper 操作合并后两个事件被传输给下游 Observer 的 onNext(T) 中，此时打印台就输出了【11，21】了。当然，最后还会将 os 数组中元素全部填充为 null，为下一次数据填充做准备。

所以实际上 zip 操作符的原理在于就是依靠队列+数组，当一个事件被发射过来的时候，首先进入队列，再去查看数组的每个元素是否为空 ——

• 如果为空，就去指定队列中 poll
  • 如果 poll 出来 null，说明该队列中还没有事件被发射过来，emptyCount++。
  • 如果不为 null 则填充到数组的指定位置。
• 如果不为空，则跳过此次循环。

直到最后，判定 emptyCount 是否不为0，不为0则意味着数组没有被填满，某些队列中还没有值，所以只能结束此次操作，等待下一次上游发射事件了。而如果 emptyCount 为0，那么说明数组中的值被填满了，这意味着符合触发下游 Observer#onNext(T) 的要求了，当然，不要忘了将数组内部元素置 null，为下次数据填充做准备。

妈个鸡，是不是还没懂？笔者也觉得挺难懂的，谁要跟我这么说我也听不懂啊！画图吧 ——

可视化

第一次事件由「第一个」事件源发出：

当【11】入队后，数组开始遍历，数组 0 的位置试图将第一个队列 poll 的值填入，此时为【11】；数组 1 的位置试图将第二个队列 poll 的值填入，但是此时为 null，所以最终结束操作，等待下一次上游的事件发射。

第二次事件仍然是由「第一个」事件源发出的 ——

当【12】入队后，数组开始遍历，数组 0 位置已经被填入值，数组 1 的位置试图将第二个队列 poll 的值填入，但是此时为 null，结束操作。

另一种情况则是第二次事件是由「第二个」事件源发出：

当【21】入队后，数组开始遍历，数组 0 位置已经被填入值，数组 1 的位置试图将第二个队列 poll 的值填入，此时为【21】。循环结束后，emptyCount 依旧为0，符合条件，触发下游 Observer#onNext(T)，然后将数组中元素置 null，为下一次数据填充做准备。

后记

ZipCoordinator 为了应对高并发引入了 CAS，同时也利用 CAS 优化 ZipCoordinator#drain() 实现，另外如果各位读者对 rxjava 有一定的了解，一定知道有一些和 zip 一类的操作符被称为组合操作符，而里面的 concat 操作符的实现，和 zip 操作符的实现有着异曲同工之妙，感兴趣的读者可以去自行去源码中一探究竟，感受下 rxjava 的魅力。