仿RXJava功能--Android自制流处理框架思路及实现

前言及准备

背景

最近重温了RxJava的机制，且正在学习结构化思维。故打算以结构化思维的方式，从零开始自己编写一个与RxJava功能接近的Android框架练手。

技术准备

在阅读该文章之前，我们至少应该掌握Java语法基础、Android开发基础、泛型、观察者模式、Rxjava概要。
本文主要用于锻炼思维，暂不引入注解、反射、APT等框架常见优化技术，仅以纯Java代码方式设计。

思路及实现

本节我们将一步一步开设设计与实现我们自己的架构。我们需要从RxJava解决了什么、设计并实现自己的框架、复盘与改进三大方面来一步一步完成我们的框架。
###RxJava解决了什么
在我们的代码中，经常会有如下形式的代码结构（伪代码）：

optionA();
optionB();
optionC();
...
optionN();

这种一写到底的代码结构，大概是我们初学编程时候最简单了形式了吧，如果所有代码都能一直这样写下去就好了。

然而，由于业务场景的需要，我们按部就班的顺序执行代码并不能解决所有问题。比如一个按钮的点击需要点击事件触发、一个网络的请求需要等待数据···
所以，我们又产生了如下的代码结构（伪代码）：

//option可能是一次点击事件，也可能是一次线程切换，或者一次网络请求回调。
optionA(new CallBack(){
    @Override
    doSomething(){
        ···
        optionB(new CallBack(){
                @Override
                doSomething(){
                    ···
                    optionC(new CallBack(){
                            @Override
                            doSomething(){
                                ...
                            }
                    });
                    ···
                }
        });
        ···
    }
});

上述代码可以解决顺序结构无法解决的问题，但缺点是代码冗杂，耦合性高。
冗杂: 我们的直观感受，就是这类代码嵌套了好多层，导致结构复杂。如果在其内部填充大量代码的话，看起来将更加冗杂。
耦合高: 上述代码中，如果我们想去掉optionB操作，使optionA操作之后直接进行OptionC，那么我们无法简单的调整，而是需要将OptionC及其内部所有代码移植到OptionA的回调下。这需要考虑对整个结构的影响，代码复杂的话会很麻烦。

那么有什么方法可以使上述代码变得简洁、耦合低呢？有，那就是RxJava。
RxJava可以输入一个事件流，经过中间的各步骤转化后，输出另外一个事件流。而中间的转化过程，我们也可以灵活调整。且RxJava不会导致层级过多。

设计并实现自己的框架

我们设计框架时只参考RxJava的作用，而不参考RxJava的逻辑。故命名、细节会与RxJava完全不同

首先，我们分析多层嵌套的回调代码，不难发现，其代码结构可以分解为一个一个的独立单元（后续都称其为单元）：

option(new CallBack(){
      doSomething{
        ···
      }
});

这个单元既可以作为其外层回调中的内容，又可以作为其它内容的外层回调。只不过它被回调与回调功能，都是通过增加代码层级的方式来进行的，这也是产生问题的根源。

//option作为其外层回调中的内容的场景
optionA(new CallBackA(){
    @Override
    doSomething(){
        ···
        option(new CallBack(){
                @Override
                doSomething(){
                }
        });
        ···
    }
});

//option作为其它内容的外层回调的场景
option(new CallBack(){
    @Override
    doSomething(){
        ···
        optionA(new CallBackA(){
                @Override
                doSomething(){
                }
        });
        ···
    }
});

那么，我们只需要一个组件（后续都将称其为组件），使其可以接管各个单元的回调与被回调方式，并且可以自由组装每个单元，那么就可以完美解决这个问题了。

到现在，我们的编码目标已经很明确了，创建一个类，使其可以成为一个“组件”：

• 接管单元回调： 暴露一个方法“doSomething”给用户进行单元的装载。回调单元执行完成后可触发下一组件的回调。
• 支持组件组装： 支持绑定下一个组件的实例，使其成为链式结构。用于在自己的单元执行完成后触发下一个组件的回调
  伪代码如下：

//Assembly意为组件，表示这是一个组件。
class Assembly{
    private Assembly assembly;//装载下一个单元的组件。

    void setAssembly(Assembly a){
        assembly = a;//用于装配下一个组件
    }

    abstract doSomething();  //自己的回调方法，暴露给用户。用于使用户装载单元进来，并使用户自行调用下一个组件的回调
}


//使用方式

//1、创建组件并装载单元
Assembly a = new Assembly(){
    @Override
    doSomething(){
        //一个单元
        option(new CallBack(){
              ...
              assembly.doSomething();//自己的代码处理完成后，执行下一个组件的回调方法
        })
    }
}；

Assembly b = new Assembly(){
    @Override
    doSomething(){
        //一个单元
        ...
        assembly.doSomething();//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；

Assembly c = new Assembly(){
    @Override
    doSomething(){
        //一个单元
        ...  
        assembly.doSomething();//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；
...
//组装组件
a.setAssembly(b);
b.setAssembly(c);
...
//触发事件流
a.doSomething();

可以看到，上述的代码结构，已经可以使我们的回调变得不再无限加深嵌套，并且可以自由组装，降低了耦合性。

那我们的框架就此完成了吗？答案是否定的。
我们可以回到我们最初的场景，我们为什么需要编写多次嵌套回调的代码？究其原因有两种：

• 事件流前后顺序限制（如线程切换）
• 数据流前后顺序限制（如网络请求等）

我们上述的框架，是针对事件流的。而由于我们改变了代码嵌套的形式，所以下层单元无法拿到上层单元的数据了。 这是我们引入的新问题。

那么，我们需要基于上述组件新增如下功能：

• 支持传递上层单元给到的数据（用于用户进行操作转化为其它数据）
• 支持传出下层单元所需的数据（数据为单元逻辑转化后的数据）

我们暂时将数据格式统一视为Object类型，那么框架的伪代码改动点为：

class Assembly{
    ...
    abstract doSomething(Object o);  //新增了形参“Object o”。即可实现数据的传输
}

//使用方式
//创建组件并装载单元
Assembly a = new Assembly(){
    @Override
    doSomething(Object a){
        //一个单元
        option(new CallBack(){
              a parsedTo b
              assembly.doSomething(b);//自己的代码处理完成后，执行下一个组件的回调方法
        })
    }
}；

Assembly b = new Assembly(){
    @Override
    doSomething(Object a){
        //一个单元
        a parsedTo b
        assembly.doSomething(b);//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；

Assembly c = new Assembly(){
    @Override
    doSomething(Object a){
        //一个单元
        a parsedTo b
        assembly.doSomething(b);//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；
...

//组装组件
a.setAssembly(b);
b.setAssembly(c);
...
//触发事件流（带源数据）
a.doSomething(objectInstance);//objectInstance：原始数据

我们的功能基本已经完成，接下来我们使用泛型代替Object，提高代码可读性，减少Object强转为各种数据类型的操作，并且使用链式调用来装载各个单元，简化代码：

//Assembly意为组件，表示这是一个组件。
//泛型中的数据类型代表数据是由A类型转化为B类型。即A为源数据类型，B为转化后的数据类型
class Assembly<A,B>{  
    private Assembly<B,?> assembly;//装载下一个单元的组件实例。其源数据是当前单元转化后的类型B。

    Assembly<B,?> setAssembly(Assembly<B,?> a){
        assembly = a//用于装配下一个组件
        return assembly;
    }
    
    abstract doSomething(A a);  //用于装载自己的单元，自己的单元需要转化前的数据A。
}


//使用方式
//创建组件并装载单元
Assembly<String,Integer> a = new Assembly<String,Integer>(){
    @Override
    doSomething(String a){
        //一个单元
        option(new CallBack(){
              ...
              a parseto b  //b被转化为Integer类型
              assembly.doSomething(b);//自己的代码处理完成后，执行下一个组件的回调方法
        })
    }
}；

Assembly<Integer,Integer> b = new Assembly<Integer,Integer>(){
    @Override
    doSomething(Integer a){
        //一个单元
        ...
        a parseTo b  //a与b都是Integer类型
        assembly.doSomething();//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；

Assembly<Integer,Float> c = new Assembly<Integer,Float>(){
    @Override
    doSomething(Integer a){
        //一个单元
        ...  
        a parseTo b  //b被转化为Float类型
        assembly.doSomething();//自己的代码处理完成后，执行下一个组件的回调代码
    }
}；
...

//组装单元
a
  .setAssembly(b)
  .setAssembly(c);
...
//触发
a.doSomething(str);//输入String类型数据

上述代码传入的源数据经历了String > Integer > Integer >String的转化。
至此，我们嵌套回调所带来的所有问题得到了解决。

复盘与改进

总结： 我们构建自己的框架时，首先确认了需要解决的问题，然后进行问题的解决，接着思考问题解决后是否引入了新的问题，最后进行查漏补缺，完善框架。使一个框架在解决痛点的同时，不引入新的痛点。
自夸： 本文在写作过程中，紧抓核心思想，围绕着解决问题的主流程，使得框架设计达到了极简，在使用了最少的代码的前提下，表达了完整的框架思想。
缺点： 该框架目前还有很多不完善的地方。比如没有实现背压、泛型使用复杂等。还有很大完善控件，目前仅供学习使用。

关于背压问题：RxJava的一个重要优势。而我们要做到背压，其核心思想是数据流不直接调用，在下一个组件完成任务处理后，通知上层组件。这样就可以由上层组件控制当前未处理完成的任务数量，然后就山高凭鱼跃，通过各种机制实现自己的背压（比如仿线程池的机制）。
关于泛型问题：目前泛型存在的问题为：链式连续调用装配组件的方法，会导致第三个组件的装配方法所需入参为Assembly<?,?>。从而导致传入的类型不匹配，编译器报错。目前需要单独创建组件为一个变量规避类型校验。优化方法其实有很多，比如不使用泛型，而是使用注解加APT生成有固定数据类型的类，然后调用该类。
当然，我们也可以内部封装多种已装载常用单元的组件来当工具类（比如线程切换组件）等。还有更多新功能需要根据实际情况不断的迭代维护。
#后记
写这一篇文章之前，我自己着手写过一个框架雏形。但是写作过程中，又找到了诸多改进点。所以说学无止境，多学多练。思维也是在一次次的优化中升华的，当一件事情练习了一定的次数，那么总会找到自己的方法论，使自己变得更强，共勉。

此篇文章用于学习交流，个人经验仅供参考，有错误欢迎指正