答案当然是肯定的，AppJoint 就是这样一个轻量级的工具，如果你不想组件化，那么你完全可以把它当成一个只是用来解决跨模块方法调用的问题的小工具。

问题背景

假设目前已经从 app 模块拆出了一个 module1 模块，app 模块是主 app 模块， 而 module1 模块是 library 模块。如果 module1 模块想要调用 app 模块的功能，那么肯定需要存在一个接口，这个接口两个模块要都能访问到。所以这个接口存在的位置就只能是 app 模块和 module1 模块都依赖的公共模块。这里的这个公共模块，它可以是已有的公共模块，也可以是新创建的公共模块。我们在这个公共模块里声明这个接口，即 app 模块希望被 module1 模块调用的方法的接口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

interface AppService {

  // start Activity from app module
  fun startActivityOfApp(context: Context)

  // get Fragment from app module
  fun obtainFragmentOfApp(): Fragment

  // call synchronous method from app module
  fun callMethodSyncOfApp(): String

  // call asynchronous method from app module
  fun callMethodAsyncOfApp(callback: AppCallback<AppEntity>)

  // get RxJava Observable from app module
  fun observableOfApp(): Observable<AppEntity>
}

这个接口由于处于公共模块，所以两个模块都能访问到这个接口。接下来我们就来解决这个问题，即在 module1 模块里调用 app 模块的方法。

问题解决

在声明上面这个接口以后，我们在 app 模块里实现这个接口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@ServiceProvider
class AppServiceImpl : AppService {
  override fun startActivityOfApp(context: Context) {
    AppActivity.start(context)
  }

  override fun obtainFragmentOfApp(): Fragment {
    return AppFragment.newInstance()
  }

  override fun callMethodSyncOfApp(): String {
    return "syncMethodResultApp"
  }

  override fun callMethodAsyncOfApp(callback: AppCallback<AppEntity>) {
    Thread { callback.onResult(AppEntity("asyncMethodResultApp")) }.start()
  }

  override fun observableOfApp(): Observable<AppEntity> {
    return Observable.just(AppEntity("rxJavaResultApp"))
  }
}

需要注意一点，我们在实现类上标记了 @ServiceProvider 注解。然后我们就可以像下面这样，从 module1 模块里调用 app 模块里的方法了：

1
2
3
4
5
6
7

val appService = AppJoint.service(AppService::class.java)

// call methods inside AppService
appService.callMethodSyncOfApp()
appService.observableOfApp().subscribe()
appService.startActivityOfApp(context)
...

即使我们没有引入组件化的任何概念，我们也能轻松解决模块化中最常遇见的跨模块方法调用的这一类问题。

关于如何在项目中引入 AppJoint，可以前往 AppJoint 的 Github 主页：https://github.com/PrototypeZ/AppJoint, 核心代码不超过 500 行，您可以使用开箱即用的版本，也可以自行在项目中引入。

参考资料

在模块化之后，您可能会对项目的组件化产生兴趣，欢迎继续阅读我的组件化经验分享 『回归初心：极简 Android 组件化方案 — AppJoint』，希望可以给您的项目组件化带去一点点帮助，谢谢！ : )

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

Solution

In order to solve this problem, I wrote a simple tool called AppJoint. With AppJoint, now we can call any methods from any module in anywhere.

Assuming our project structure is like below:

1
2
3
4

projectRoot
  +--app
  +--module1
  +--module2

Here, app is an application module and module1/module2 are library modules. app module depends on module1 and module2:

If we wish the app module to provide services to other modules like module1 and module2, we need to create a new library first and define service interfaces inside it and make all modules have the dependency of this new module.

For example, I create a new library module named service and create several kotlin interfaces which representing the services that each module wants to provide for other modules to use:

1
2
3
4
5
6
7
8
9
10
11

projectRoot
  +--app
  +--module1
  +--module2 
  +--service
  |  +--main
  |  |  +--kotlin
  |  |  |  +--com.yourPackage
  |  |  |  |  +--AppService.kt
  |  |  |  |  +--Module1Service.kt
  |  |  |  |  +--Module2Service.kt

• Methods in AppService are provided by the app module for other modules to use
• Methods in Module1Service are provided by the module1 module for other modules to use
• Methods in Module2Service are provided by the module2 module for other modules to use

All modules should include the service module excluding the service module itself:

1
2
3
4

dependencies {
    ...
    implementation project(":service")
}

Maybe our AppService.kt source codes are like below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

interface AppService {

  // start Activity from app module
  fun startActivityOfApp(context: Context)

  // get Fragment from app module
  fun obtainFragmentOfApp(): Fragment

  // call synchronous method from app module
  fun callMethodSyncOfApp(): String

  // call asynchronous method from app module
  fun callMethodAsyncOfApp(callback: AppCallback<AppEntity>)

  // get RxJava Observable from app module
  fun observableOfApp(): Observable<AppEntity>
}

And then we write an implementation of AppService in the app module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@ServiceProvider
class AppServiceImpl : AppService {
  override fun startActivityOfApp(context: Context) {
    AppActivity.start(context)
  }

  override fun obtainFragmentOfApp(): Fragment {
    return AppFragment.newInstance()
  }

  override fun callMethodSyncOfApp(): String {
    return "syncMethodResultApp"
  }

  override fun callMethodAsyncOfApp(callback: AppCallback<AppEntity>) {
    Thread { callback.onResult(AppEntity("asyncMethodResultApp")) }.start()
  }

  override fun observableOfApp(): Observable<AppEntity> {
    return Observable.just(AppEntity("rxJavaResultApp"))
  }
}

Note that we add a @ServiceProvider annotation on the AppServiceImpl class.

Now, if we need to call methods of AppService inside module1 or module2, we just need to write codes as below:

1
2
3
4

val appService = AppJoint.service(AppService::class.java)

// call methods inside AppService
appService.callMethodSyncOfApp()

That’s all, the @ServiceProvider annotation and the AppJoint.service method are the only two API.

Getting started

It’s easy to include AppJoint.

1. Add the AppJoint plugin dependency to the build.gradle file in project root:

1
2
3
4
5
6
7

buildscript {
    ...
    dependencies {
        ...
        classpath 'io.github.prototypez:app-joint:{latest_version}'
    }
}

2. Add the AppJoint dependency to every module：

1
2
3
4

dependencies {
    ...
    implementation "io.github.prototypez:app-joint-core:{latest_version}"
}

3. Apply the AppJoint plugin to your main app module：

1
2

apply plugin: 'com.android.application'
apply plugin: 'app-joint'

Conclusion

Github of AppJoint: https://github.com/PrototypeZ/AppJoint

Have fun!

主要的原因是在调研了诸多组件化方案之后，发现尽管它们都有各自的优点，但是依然有一些地方不是令人十分满意。而其中最重要的一个因素就是引入组件化方案成本较高，对已有项目改造过大。我想这一点应该很多人都有相同的体会，很多时候 我们对于项目的重构是需要与新需求的迭代同步进行的 ，几乎很难停下来只做项目的组件化。

另外一点，我不太希望自己的项目和某一款组件化框架 强耦合。 Activity 的路由方案也好，跨模块的同步或异步方法调用也好，我希望能够沿用项目已有的调用方式，而不是使用某款组件化框架自己特定的调用方式。例如某个接口已经基于 RxJava 封装为了 Observable 的接口，我就不太希望因为组件化的关系，这个接口位于另一个模块之后，我就不得不用这个组件化框架定义的方式去调用，我还是希望以 RxJava 的方式去调用。

回归初心

我认为目前想要进行组件化的项目应该可以分为两类：

• 包含有一个 application 模块，以及一些技术组件的 library 模块（业务无关）。
• 除了 application 模块以外，已经存在若干包含业务的 library 模块和技术的 library 模块。

无论是哪种类型的项目，面临的问题应该都是类似的，那就是项目大起来以后，编译实在是太慢了。

除此以外，就是 跨模块的功能调用非常不便 ，这个问题主要体现在上面列举的第二种类型的项目。本人所在的项目在组件化之前就是上面列举的第二种类型的项目，application 模块最早用来承载业务逻辑代码，随着业务发展，大概是某位开发人员觉得， “不行，这样下去 application 模块代码数量会失控的”，于是后续新的业务模块都会新开一个 library 模块进行开发，就这样断断续续目前有了大概 20+ 个 library 模块（业务相关模块，技术模块不包含在内）。

这种做法是符合软件工程思想的，但是也带来了一些棘手的问题，由于 application 模块里的业务功能和 library 模块里的业务功能在逻辑地位上是平等的，所以难免会有互相调用的情况，但是它们在项目依赖层次上却不是处于相等的地位，application 调用 library 倒没事，但是反过来调用就成了问题。另外，剩下这 20 + 个 library 模块在依赖层次中也不全是属于同一层次的，library 模块之间互相依赖也很复杂。

所以我期望的组件化方案要求解决的问题很简单：

• 业务模块单独编译，单独运行，而不是耗费大量时间全量编译整个 App
• 跨模块的调用应该优雅，无论两个模块在依赖树中处于什么样的位置，都可以很简单的互相调用
• 不要有太多的学习成本，沿用目前已有的开发方式，避免代码和具体的组件化框架绑定
• 组件化的过程可以是渐进的，立即拆分代码不是组件化的前置条件
• 轻量级，不要引入过多中间层次（例如序列化反序列化）导致不必要的性能开销以及维护复杂度

基于上述的思想，我们开发了 AppJoint 这个框架用来帮助我们实现组件化。

AppJoint 是一个非常简单有效的方案，引入 AppJoint 进行组件化所有的 API 只包含 3 个注解，加 1 个方法，这可能是目前最简单的组件化方案了，我们的框架不追求功能要多么复杂强大，只专注于框架本身实用、简单与高效。而且整体实现也非常简单，核心源码 不到500行。

模块独立运行遇到的问题

本人接触最早的组件化方案是 DDComponentForAndroid，学习这个方案给了我很多启发，在这个方案中，作者提出，可以在 gradle.properties 中新增一个变量 isRunAlone=true ，用来控制某个业务模块是 以 library 模块集成到 App 的全量编译中 还是 以 application 模块独立编译启动 。不知道是不是很多人也受了相同的启发，后面很多的组件化框架都是使用类似的方案:

1
2
3
4
5

if (isRunAlone.toBoolean()) {    
    apply plugin: 'com.android.application'
} else {  
    apply plugin: 'com.android.library'
}

根据我本人的实践，这种方式有一些缺点。首先有一些开源框架在 library 模块中和在 application 模块中使用方法是不一样的，例如 ButterKinfe , 在 application 中使用 R.id.xxx，在 library 模块中使用 R2.id.xxx ，如果想组件化，代码必须保证在两种情况下都可用，所以基本只能抛弃 ButterKnife 了，这会给项目带来巨大的改造成本。

除此以外，还有一些开源框架是只能在 application 模块中配置的，配置完以后对整个项目的所有 library 模块都生效的，例如一些字节码修改的框架（比如 AOP 一类的），这是一种情况。还有一种情况，如果原先项目已经是多模块的情况下，可能多个模块的初始化都是放在 application 模块里，因为 application 模块是 上帝模块，他可以访问到项目中任意一块代码，所以在这里做初始化是最省事的。但是现在拆分为模块之后，因为每个模块需要独立运行，所以模块需要负责自身的初始化，可是有时候这个模块的初始化是只能在 application 模块里才可以做的，我们把这段逻辑下放到 library 之后，如何初始化就成了问题。

这两种情况，如果我们使用 gradle.properties 中的变量来切换 application 和 library 的话，我们势必需要在这个模块中维护两套逻辑，一套是在 application 模式下的启动逻辑，一套是在 library 模式下的启动逻辑。原先这个模块是专注自己本身的业务逻辑的，现在不得不为了能够独立作为 application 启动，而加入许多其他代码。一方面 build.gradle 文件中会充满很多 if - else，另一方面 Java 源码中也会加入许多判断是否独立运行的逻辑。

最终 Release App 打包时，这些模块是作为 library 存在的，但是我们为了组件化已经在这个模块中加入了很多帮助该模块独立运行（以 application 模式）的代码（例如模块需要单独运行，需要一个属于这个模块的 Laucher Activity），虽然这些代码在线上不会生效，可是从洁癖的角度来讲，这些代码其实不应该被打包进去。其实说了这么多无非就是想说明，如果我们希望通过某个变量来控制模块以 application 形式还是以 library 形式存在，那么我们肯定要在这个模块中加入维护两者的差异的代码，而且可能代码量还不少，最后代码呈现的状态可能是不太优雅的。

此外模块中的 AndroidManifest.xml 也需要维护两份：

1
2
3
4
5

if (isRunAlone.toBoolean()) {
    manifest.srcFile 'src/main/runalone/AndroidManifest.xml'
} else {
    manifest.srcFile 'src/main/AndroidManifest.xml'
}

但是 xml 毕竟不是代码，没有封装继承这些面向对象的特性，所以每当我们增加、修改、删除四大组件的时候，都需要记得要在两个 AndroidManifest.xml 都做对应的修改。除了 AndroidManifest.xml 以外，资源文件也存在这个问题，虽然工作量不至于特别巨大，但这样的做法其实已经违背了面向对象的设计原则。

最后还有一个问题，每当模块在 application 模式和 library 模式之间进行切换的时候，都需要重新 Gradle Sync 一次，我想既然是需要组件化的项目那肯定已经是那种编译速度极慢的项目了，即使是 Gradle Sync 也需要等待不少时间，这点也是我们不太能接收的。

创建多个 Application 模块

我们最后是如何解决模块的单独编译运行这个问题的呢？答案是 为每个模块新建一个对应的 application 模块 。也许你会对此表示怀疑：如果为每个业务模块配一个用于独立启动的 application 模块，那模块会显得特别多，项目看起来会非常的乱的。但是其实我们可以把所有用于独立启动业务模块的 application 模块收录到一个目录中：

1
2
3
4
5
6
7

projectRoot
  +--app
  +--module1
  +--module2
  +--standalone
  |  +--module1Standalone
  |  +--module2Standalone

在上面这个项目结构图中，app 模块是全量编译的 application 模块入口，module1 和 module2 是两个业务 library 模块， module1Standalone 和 module2Standalone 是分别使用来独立启动 module1 和 module2 的 2 个 application 模块，这两个模块都被收录在 standalone 文件夹下面。事实上，standalone 目录下的模块很少需要修改，所以这个目录大多数情况下是属于折叠状态，不会影响整个项目结构的美观。

这样一来，在项目根目录下的 settings.gradle 里的代码是这样的：

1
2
3
4
5
6
7
8

// main app
include ':app'
// library modules
include ':module1'
include ':module2'
// for standalone modules
include ':standalone:module1Standalone'
include ':standalone:module2Standalone'

在主 App 模块（app 模块）的 build.gradle 文件里，我们只需要依赖 module1 和 module2 ，两个 standalone 模块只和各自对应的业务模块的独立启动有关，它们不需要被 app 模块依赖，所以 app 模块的 build.gradle 中的依赖部分代码如下：

1
2
3
4

dependencies {
    implementation project(':module1')
    implementation project(':module1')
}

那些用于独立运行的 application 模块里的 build.gradle 文件中，就只有一个依赖，那就是需要被独立运行的 library 模块。以 standalone/module1Standalone 为例，它对应的 build.gradle 中的依赖为：

1
2
3

dependencies {
    implementation project(':module1')
}

在 Android Studio 中创建模块，默认模块是位于项目根目录之下的，如果希望把模块移动到某个文件夹下面，需要对模块右键，选择 “Refactor – Move” 移动到指定目录之下。

当我们创建好这些 application 模块之后，在 Android Studio 的运行小三角按钮旁边，就可以选择我们需要运行哪个模块了：

这样一来，我们首先可以感受到的一点就是模块不再需要改 gradle.properties 文件切换 library 和 application 状态了，也不再需要忍受 Gradle Sync 浪费宝贵的开发时间，想全量编译就全量编译，想单独启动就单独启动。

由于专门用于单独启动的 standalone 模块 的存在，业务的 library 模块只需要按自己是 library 模块这一种情况开发即可，不需要考虑自己会变成 application 模块，所以无论是新开发一个业务模块还是从一个老的业务模块改造成组件化形式的模块，所要做的工作都会比之前更轻松。而之前提到的，为了让业务模块单独启动所需要的配置、初始化工作都可以放到 standalone 模块 里，并且不用担心这些代码被打包到最终 Release 的 App 中，前面例子中提到的用来使模块单独启动的 Launcher Activity，只要把它放到 standalone 模块 模块即可。

AndroidManifest.xml 和资源文件的维护也变轻松了。四大组件的增删改只需要在业务的 library 模块修改即可，不需要维护两份 AndroidManifest.xml 了，standalone 模块 里的 AndroidManifest.xml 只需要包含模块独立启动时和 library 模块中的 AndroidManifest.xml 不同的地方即可（例如 Launcher Activity 、图标等），编译工具会自动完成两个文件的 merge。

推荐在 standalone 模块 内指定一个不同于主 App 的 applicationId，即模块单独启动的 App 与主 App 可以在手机内共存。

我们分析一下这个方案，和原先的比，首先缺点是，引入了很多新的 standalone 模块，项目似乎变复杂了。但是优点也是明显的，组件化的逻辑更加清晰，尤其是在老项目改造情况下，所需要付出的工作量更少，而且不需要在开发期间频繁 Gradle Sync。 总的来说，改造后的组件化项目更符合软件工程的设计原则，尤其是开闭原则（open for extension, but closed for modification）。

介绍到这里为止，我们还没有使用任何 AppJoint 的 API，我们之所以没有借助任何组件化框架的 API 来实现模块的独立启动，是因为本文一开始提出的，我们不希望项目和任何组件化框架强绑定, 包括 AppJoint 框架本身，AppJoint 框架本身的设计是与项目松耦合的，所以使用了 AppJoint 框架进行组件化的项目，如果今后希望可以切换到其它更优秀的组件化方案，理论上是很轻松的。

为每个模块准备 Application

在组件化之前，我们常常把项目中需要在启动时完成的初始化行为，放在自定义的 Application 中，根据本人的项目经验，初始化行为可以分为以下两类：

• 业务相关的初始化。例如服务器推送长连接建立，数据库的准备，从服务器拉取 CMS 配置信息等。
• 与业务无关的技术组件的初始化。例如日志工具、统计工具、性能监控、崩溃收集、兼容性方案等。

我们在上一步中，为每个业务模块建立了独立运行的 standalone 模块 ，但是此时还并不能把业务模块独立启动起来，因为模块的初始化工作并没有完成。我们在前面介绍 AppJoint 的设计思想的时候，曾经说过我们希望组件化方案最好 『不要有太多的学习成本，沿用目前已有的开发方式』，所以这里我们的解决方案是，在每个业务模块里新建一个自定义的 Application 类，用来实现该业务模块的初始化逻辑，这里以在 module1 中新建自定义 Application 为例：

1
2
3
4
5
6
7
8
9
10

@ModuleSpec
public class Module1Application extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        // do module1 initialization
        Log.i("module1", "module1 init is called");
    }
}

如上面的代码所示，我们在 module1 中新建一个自定义的 Application 类，名为 Module1Application。那我们是不是应该把与这个模块有关的所有初始化逻辑都放在这个类里面呢？并不完全是这样。

首先，对于前面提到的当前模块的 业务相关的初始化 ，毫无疑问应该放在这个 Module1Application 类中，但是针对前面提到的该模块的 与业务无关的技术组件的初始化 放在这里就不是很合适了。

首先，从逻辑上考虑，业务无关的技术组件的初始化应该放在一个统一的地方，把它们放在主 App 的自定义 Application 类中比较合适，如果每个模块为了自己可以独立编译运行，都要自己初始化一遍，那么所有代码最后一起全量编译的时候，这些初始化行为就会在代码中出现好几次，这样既不合理，也可能会造成潜在问题。

那么，如果我们在 Module1Application 中做判断，如果它自身处于独立编译运行状态，就执行技术组件的初始化，反之，若它处于全量编译运行状态中，就不执行技术组件的初始化，由主 App 的 Application 来实现这些逻辑，这样是否可以呢？理论上这种方案可行，但是这么做就会遇到和前面提到的 『在 gradle.properties 中维护一个变量来控制模块是否独立编译』同样的问题，我们不希望把和业务无关的逻辑（用于业务模块独立启动的逻辑）打包进最终 Release 的 App。

那应该如何解决这个问题呢？解决方案和前面一小节类似，我们不是为 module1 模块准备了一个 module1Standalone 模块吗？既然技术相关的组件的初始化并不是 module1 模块的核心，只和 module1 模块的独立启动有关，那么放在 module1Standalone 模块里是最合适的，因为这个模块只会在 module1 的独立编译运行中使用到，它的任何代码都不会被打包到最终 Release 的 App 中。我们可以在 module1Standalone 中定义一个 Module1StandaloneApplication 类，它从 Module1Application 继承下来：

1
2
3
4
5
6
7
8
9
10

public class Module1StandaloneApplication extends Module1Application {

    @Override
    public void onCreate() {
        // module1 init inside super.onCreate()
        super.onCreate();
        // initialization only used for running module1 standalone
        Log.i("module1Standalone", "module1Standalone init is called");
    }
}

并且我们在 module1Standalone 模块的 AndroidManifest.xml 中把 Module1StandaloneApplication 设置为 Standalone App 使用的自定义 Application 类：

1
2
3
4
5
6
7
8
9
10
11
12

<application
    android:icon="@mipmap/module1_launcher"
    android:label="@string/module1_app_name"
    android:theme="@style/AppTheme"
    android:name=".Module1StandaloneApplication">
    <activity android:name=".Module1MainActivity">
        <intent-filter>
            <action android:name="android.intent.action.MAIN"/>
            <category android:name="android.intent.category.LAUNCHER"/>
        </intent-filter>
    </activity>
</application>

在上面的代码中，我们除了设置了自定义的 Application 以外，还设置了一个 Launcher Activity (Module1MainActivity)，这个 Activity 即为模块的启动 Activity，由于它只存在于模块的独立编译运行期间，App 全量打包时是不包含这个 Module1MainActivity 的，所以我们可以在里面定义一些方便模块独立调试的功能，例如快速前往某个页面以及创建 Mock 数据。

这样，只要我们单独运行 module1Standalone 这个模块的时候，使用的 Application 类就是 Module1StandaloneApplication。在开发时，我们需要单独调试 module1 时，我们只需要启动 module1Standalone 这个模块进行调试即可；而在 App 需要全量编译时，我们则正常启动原来的主 App 。无论是哪种情况， module1 这个模块始终是以 library 形式存在的，这意味着，如果我们希望把原先的业务模块改造成组件化模块，需要的改造量缩小很多，我们改造的过程主要是在 增加代码，而不是 修改代码，这点符合软件工程中的『开闭原则』。

写到这里，我们其实还有一个问题没有解决。Module1Application 目前除了被 Module1StandaloneApplication 继承以外，没有被任何其它地方引用到。您可能会有疑问：那我们如何保证 App 全量编译运行时，Module1Application 里的初始化逻辑会被调用到呢？细心的您可能早就已经发现了：我们在上面定义 Module1Application 时，同时标记了一个注解 @ModuleSpec:

1
2
3
4

@ModuleSpec
public class Module1Application extends Application {
    ...
}

这个注解的作用是告知 AppJoint 框架，我们需要确保当前模块该 Application 中的初始化行为，能够在最终全量编译时，被主 App 的 Application 类调用到。所以对应的，我们的主 App 模块（app 模块）的自定义 Application 类也需要被一个注解 – AppSpec 标记，代码如下所示：

1
2
3
4

@AppSpec
public class App extends Application {
    ...
}

上面代码中的 App 为主 App 对应的自定义 Application 类，我们给这个类上方标记了 @AppSpec 注解，这样系统在执行 App 自身初始化的同时会一并执行这些子模块的 Application 里对应声明周期的初始化。即：

• App 执行 onCreate 方法时，保证也同时执行 Module1Application 和 Module2Application 的 onCreate 方法 。
• App 执行 attachBaseContext 方法时，保证也同时执行 Module1Application 和 Module2Application 的 attachBaseContext 方法。
• 依次类推，当 App 执行某个生命周期方法时，保证子模块的 Application 的对应的生命周期方法也会被执行。

这样，我们通过 AppJoint 的 @ModuleSpec 和 @AppSpec 两个注解，在主 App 的 Application 和子模块的 Application 之间建立了联系，保证了在全量编译运行时，所有业务模块的初始化行为都能被保证执行。

到这里为止，我们已经处理好了业务模块在 独立编译运行模式 和 全量编译运行模式 这两种情况下的初始化问题，目前关于 Application 还有一个潜在问题，我们的项目在组件化之前，我们经常会在 Applictaion 类的 onCreate 周期保存当前 Appliction 的引用，然后在应用的任何地方都可以使用这个 Application 对象，例如下面这样：

1
2
3
4
5
6
7
8
9
10

public class App extends Application {

    public static App INSTANCE;

    @Override
    public void onCreate() {
        super.onCreate();
        INSTANCE = this;
    }
}

这么处理之后，我们可以在项目任意位置通过 App.INSTANCE 使用 Application Context 对象。但是，现在组件化改造以后，以 module1 为例，在独立运行模式时，应用的 Application 对象是 Module1StandaloneApplication 的实例，而在全量编译运行模式时，应用的 Application 对象是主 App 模块的 App 的实例，我们如何能像之前一样，做到在项目中任何一个地方都能获取到当前使用的 Application 实例呢？

我们可以把项目中所有自定义 Application 内部保存的自身的 Application 实例的类型，从具体的自定义类，改为标准的 Application 类型，以 Module1Application 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13

@ModuleSpec
public class Module1Application extends Application {
    
    public static Application INSTANCE;

    @Override
    public void onCreate() {
        super.onCreate();
        INSTANCE = (Application)getApplicationContext()
        // do module1 initialization
        Log.i("module1", "module1 init is called");
    }
}

我们可以看到，如果按原来的写法， INSTANCE 的类型一般是具体的自定义类型 Module1Application，现在我们改成了 Application。同时 onCreate 方法里为 INSTANCE 赋值的语句不再是 INSTANCE = this，而是 INSTANCE = (Application)getApplicationContext()。这样处理以后，就可以保证 module1 里面的代码，无论是在 App 全量编译模式下，还是独立编译调试模式下，都可以通过 Module1Application.INSTANCE 访问当前的 Application 实例。这是由于 AppJoint 框架 保证了当主 App 的 App 对象被调用 attachBaseContext 回调时，所有组件化业务模块的 Application 也会被调用 attachBaseContext 这个回调。

这样，我们在 module1 这个模块里的任何位置使用 Module1Application.INSTANCE 总能正确地获得 Application 的实例。对应的，我们使用相同的方法在 module2 这个模块里，也可以在任何位置使用 Module2Application.INSTANCE 正确地获得 Application 的实例，而不需要知道当前处于独立编译运行状态还是全量编译运行状态。

一定不要 依赖某个业务模块自身定义的 Application 类的实例（例如 Module1Application 的实例），因为在运行时真正使用的 Application 实例可能不是它。

我们已经解决业务模块在 单独编译运行模式 下和在 App 全量编译模式 下，初始化逻辑应该如何组织的问题。我们沿用了我们熟悉的自定义 Application 方案，来承载各个模块的初始化行为，同时利用 AppJoint 这个胶水，把每个模块的初始化逻辑集成到最终全量编译的 App 中。而这一切和 AppJoint 有关的 API 仅仅是两个注解，这里很好的说明了 AppJoint 是个学习成本低的工具，我们可以沿用我们已有的开发方式而不是改造我们原有的代码逻辑导致项目和组件化框架造成过度耦合。

跨模块方法的调用

虽然目前每个模块已经有独立编译运行的可能了，但是开发一个成熟的 App 我们还有一个重要的问题没有解决，那就是跨模块的方法调用。因为我们的业务模块无论是从业务逻辑上考虑还是从在依赖树上的位置考虑，都应该是具有同等的地位的，体现在依赖层次上，这些业务模块应该是平级的，且互相之间没有依赖：

上图是我们比较理想情况下的组件化的最终状态，App 模块不承载任何业务逻辑，它的作用仅仅是作为一个 application 壳把 Module1 ~ Module(n) 这个 n 个模块的功能都集成在一起成为一个完整的 App。Module1 ~ Module(n) 这 n 个模块互相之间不存在任何交叉依赖，它们各自仅包含各自的业务逻辑。这种方式虽然完成了业务模块之间的解耦，但是给我们带来的新的挑战：业务模块之间互相调用彼此的功能是非常常见且合理的需求，但是由于这些模块在依赖层次上位于同一层次，所以显然是无法直接调用的。

此外，上图的这种形态是组件化的最终的理想状态，如果我们要将项目改造以达到这种状态，毫无疑问需要付出巨大的时间成本。在业务快速迭代期间，这是我们无法承担的成本，我们只能逐渐地改造项目，也就是说，App 模块内的业务代码是被逐渐拆解出来形成新的独立模块的，这意味着在组件化过程的相当长一段时间内，App 内还是存在业务代码的，而被拆解出来的模块内的业务逻辑代码，是有可能调用到 App 模块内的代码的。这是一种很尴尬的状态，在依赖层次中，位于依赖层次较低位置的代码反而要去调用依赖层次较高位置的代码。

针对这种情况，我们比较容易想到，我们再新建一个模块，例如 router 模块，我们在这个模块内定义 所有业务模块希望暴露给其它模块调用的方法，如下图：

1
2
3
4
5
6
7
8
9
10
11
12

projectRoot
  +--app
  +--module1
  +--module2
  +--standalone
  +--router
  |  +--main
  |  |  +--java
  |  |  |  +--com.yourPackage
  |  |  |  |  +--AppRouter.java
  |  |  |  |  +--Module1Router.java
  |  |  |  |  +--Module2Router.java

在上面的项目结构层次中，我们在新建的 router 模块下定义了 3 个 接口：

• AppRouter 接口声明了 app 模块暴露给 module1、module2 的方法的定义。
• Module1Router 接口声明了 module1 模块暴露给 app、module2 的方法的定义。
• Module2Router 接口声明了 module2 模块暴露给 module1、app 的方法的定义。

以 AppRouter 接口文件为例，这个接口的定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public interface AppRouter {

    /**
     * 普通的同步方法调用
     */
    String syncMethodOfApp();

    /**
     * 以 RxJava 形式封装的异步方法
     */
    Observable<String> asyncMethod1OfApp();

    /**
     * 以 Callback 形式封装的异步方法
     */
    void asyncMethod2OfApp(Callback<String> callback);
}

我们在 AppRouter 这个接口内定义了 1 个同步方法，2 个异步方法，这些方法是 app 模块需要暴露给 module1 、 module2 的方法，同时 app 模块自身也需要提供这个接口的实现，所以首先我们需要在 app 、module1 、module2 这三个模块的 build.gradle 文件中依赖 router 这个模块：

1
2
3
4
5

dependencies {
    // Other dependencies
    ...
    api project(":router")
}

这里依赖 router 模块的方式是使用 api 而不是 implementation 是为了把 router 模块的信息暴露给依赖了这些业务模块的 standalone 模块，app 模块由于没有别的模块依赖它，不受上面所说的限制，可以写成 implementation 依赖。

然后我们回到 app 模块，为刚刚在 router 定义的 AppRouter 接口提供一个实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@ServiceProvider
public class AppRouterImpl implements AppRouter {

    @Override
    public String syncMethodOfApp() {
        return "syncMethodResult";
    }

    @Override
    public Observable<String> asyncMethod1OfApp() {
        return Observable.just("asyncMethod1Result");
    }

    @Override
    public void asyncMethod2OfApp(final Callback<String> callback) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                callback.onResult("asyncMethod2Result");
            }
        }).start();
    }
}

我们可以发现，我们把 app 模块内的方法暴露给其它模块的方式和我们平时写代码并没有什么不同，就是声明一个接口提供给其它模块，同时在自己内部编写一个这个接口的实现类。无论是同步还是异步，无论是 Callback 的方式，还是 RxJava 的方式，都可以使用我们原有的开发方式。唯一的区别就是，我们在 AppRouterImpl 实现类上方标记了一个 @ServiceProvider 注解，这个注解的作用是用来通知 AppJoint 框架在 AppRouter 和 AppRouterImpl 之间建立联系，这样其它模块就可以通过 AppJoint 找到一个 AppRouter 的实例并调用里面的方法了。

假设现在 module1 中需要调用 app 模块中的 asyncMethod1OfApp 方法，由于 app 模块已经把这个方法声明在了 router 模块的 AppRouter 接口中了，module1 由于也依赖了 router 模块，所以 module1 内可以访问到 AppRouter 这个接口，但是却访问不到 AppRouterImpl 这个实现类，因为这个类定义在 app 模块内，这时候我们可以使用 AppJoint 来帮助 module1 获取 AppRouter 的实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

AppRouter appRouter = AppJoint.service(AppRouter.class);

// 获得同步调用的结果        
String syncResult = appRouter.syncMethodOfApp();
// 发起异步调用
appRouter.asyncMethod1OfApp()
        .subscribe((result) -> {
            // handle asyncResult
        });
// 发起异步调用
appRouter.asyncMethod2OfApp(new Callback<String>() {
    @Override
    public void onResult(String data) {
        // handle asyncResult
    }
});

在上面的代码中，我们可以看到，除了第一步获取 AppRouter 接口的实例我们用到了 AppJoint 的 API AppJoint.service 以外，剩下的代码，module1 调用 app 模块内的方法的方式，和我们原来的开发方式没有任何区别。AppJoint.service 就是 AppJoint 所有 API 里唯一的那个方法。

也就是说，如果一个模块需要提供方法供其他模块调用，需要做以下步骤：

• 把接口声明在 router 模块中
• 在自己模块内部实现上一步中声明的接口，同时在实现类上标记 @ServiceProvider 注解

完成这两步以后就可以在其它模块中使用以下方式获取该模块声明的接口的实例，并调用里面的方法：

1
2
3

AppRouter appRouter = AppJoint.service(AppRouter.class);
Module1Router module1Router = AppJoint.service(Module1Router.class);
Module2Router module2Router = AppJoint.service(Module2Router.class);

这种方法不仅仅可以保证处于相同依赖层次的业务模块可以互相调用彼此的方法，还可以支持从业务模块中调用 app 模块内的方法。这样就可以 保证我们组件化的过程可以是渐进的 ，我们不需要一口气把 app 模块中的所有功能全部拆分到各个业务模块中，我们可以逐渐地把功能拆分出来，以保证我们的业务迭代和组件化改造同时进行。当我们的 AppRouter 里面的方法越来越少直到最后可以把这个类从项目中安全删除的时候，我们的组件化改造就完成了。

模块独立编译运行模式下跨模块方法的调用

上面一个小结中我们已经介绍了使用 AppJoint 在 App 全量编译运行期间，业务模块之间跨模块方法调用的解决方案。在全量编译期间，我们可以通过 AppJoint.service 这个方法找到指定模块提供的接口的实例，但是在模块单独编译运行期间，其它的模块是不参与编译的，它们的代码也不会打包进用于模块独立运行的 standalaone 模块，我们如何解决在模块单独编译运行模式下，跨模块调用的代码依然有效呢？

以 module1 为例，首先为了便于在 module1 内部任何地方都可以调用其它模块的方法，我们创建一个 RouterServices 类用于存放其它模块的接口的实例：

1
2
3
4
5
6

public class RouterServices {
    // app 模块对外暴露的接口
    public static AppRouter sAppRouter = AppJoint.service(AppRouter.class);
    // module2 模块对外暴露的接口
    public static Module2Router sModule2Router = AppJoint.service(Module2Router.class);
}

有了这个类以后，我们在 module1 内部如果需要调用其它模块的功能，我们只需要使用 RouterServices.sAppRouter 和 RouterServices.sModule2Router 这两个对象就可以了。但是如果是刚刚提到的 module1 独立编译运行的情况，即启动的 application 模块是 module1Standalone， 那么 RouterServices.sAppRouter 和 RouterServices.sModule2Router 这两个对象的值均为 null ，这是因为 app 和 module2 这两个模块此时是没有被编译进来的。

如果我们需要在这种情况下保证已有的 module1 内部的通过 RouterServices.sAppRouter 和 RouterServices.sModule2Router 进行跨模块方法调用的代码依然能工作，我们就需要对这两个引用手动赋值，即我们需要创建 Mock 了 AppRouter 和 Module2Router 功能的类。这些类由于只对 module1 的独立编译运行有意义，所以这些类最合适的位置是放在 module1Standalone 这个模块内，以 AppRouter 的 Mock 类 AppRouterMock 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class AppRouterMock implements AppRouter {
    @Override
    public String syncMethodOfApp() {
        return "mockSyncMethodOfApp";
    }

    @Override
    public Observable<String> asyncMethod1OfApp() {
        return Observable.just("mockAsyncMethod1OfApp");
    }

    @Override
    public void asyncMethod2OfApp(final Callback<String> callback) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                callback.onResult("mockAsyncMethod2Result");
            }
        }).start();
    }
}

已经创建好了 Mock 类，接下来我们要做的是，在 module1 独立编译运行的模式下，用 Mock 类的对象，去替换 RouterServices 里面的对应的引用，由于这些逻辑只和 module1 的独立编译运行有关，我们不希望这些逻辑被打包进真正 Release 的 App 中，那么最合适的地方就是 Module1StandaloneApplication里了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Module1StandaloneApplication extends Module1Application {

    @Override
    public void onCreate() {
        // module1 init inside super.onCreate()
        super.onCreate();
        // initialization only used for running module1 standalone
        Log.i("module1Standalone", "module1Standalone init is called");

        // Replace instances inside RouterServices
        RouterServices.sAppRouter = new AppRouterMock();
        RouterServices.sModule2Router = new Module2RouterMock();
    }
}

有了上面的初始化动作以后，我们就可以在 module1 内部安全地使用 RouterServices.sAppRouter 和 RouterServices.sModule2Router 这两个对象进行跨模块的方法调用了，无论当前是处于 App 全量编译模式还是 modul1Standalone 独立编译运行模式。

跨模块启动 Activity 和 Fragment

在组件化改造过程中，除了跨模块的方法调用之外，跨模块启动 Activity 和跨模块引用 Fragment 也是我们经常遇到的需求。目前社区中大多数组件化方案都是使用自定义私有协议，使用 URL-Scheme 的方式来实现跨模块 Activity 的启动，这一块已经有很多成熟的方案了，有的组件化方案直接推荐使用 ARouter 来实现这块功能。但是 AppJoint 没有使用这类方案。

本文开头曾经介绍过，AppJoint 所有的 API 只包含 3 个注解加 1 个方法，而这些 API 我们在前文中已经都介绍完了，也就是说，我们没有提供专门的 API 来实现跨模块的 Activity / Fragment 调用。

我们回想一下，在没有实现组件化时，我们启动 Activity 的推荐写法如下，首先在被启动的 Activity 内实现一个静态 start 方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class MyActivity extends AppCompatActivity {

    public static void start(Context context, String param1, Integer param2) {
        Intent intent = new Intent(context, MyActivity.class);  
        intent.putExtra("param1", param1);  
        intent.putExtra("param2", param2);  
        context.startActivity(intent);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
    }
}

然后我们如果在其它 Activity 中启动这个 MyActivity 的话，写法如下：

1

MyActivity.start(param1, param2);

这里的思想是，服务的提供者应该把复杂的逻辑放在自己这里，而只提供给调用者一个简单的接口，用这个简单的接口隔离具体实现的复杂性，这是符合软件工程思想的。

那么如果目前 module1 模块中有一个 Module1Activity，现在这个 Activity 希望能够从 module2 启动，应该如何写呢？首先，在 router 模块的 Module1Router 内声明启动 Module1Activity 的方法：

1
2
3
4
5

public interface Module1Router {
    ...
    // 启动 Module1Activity
    void startModule1Activity(Context context);
}

然后在 module1 模块里 Module1Router 对应的实现类 Module1RouterImpl 中实现刚刚定义的方法：

1
2
3
4
5
6
7
8
9
10
11

@ServiceProvider
public class Module1RouterImpl implements Module1Router {

    ...

    @Override
    public void startModule1Activity(Context context) {
        Intent intent = new Intent(context, Module1Activity.class);
        context.startActivity(intent);
    }
}

这样， module2 中就可以通过下面的方式启动 module1 中的 Module1Activity 了。

1

RouterServices.sModule1Router.startModule1Activity(context);

跨模块获取 Fragment 实例也是类似的方法，我们在 Module1Router 里继续声明方法：

1
2
3
4
5
6
7
8

public interface Module1Router {
    ...
    // 启动 Module1Activity
    void startModule1Activity(Context context);

    // 获取 Module1Fragment
    Fragment obtainModule1Fragment();
}

差不多的写法，我们只要在 Module1RouterImpl 里接着实现方法即可:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@ServiceProvider
public class Module1RouterImpl implements Module1Router {
    @Override
    public void startModule1Activity(Context context) {
        Intent intent = new Intent(context, Module1Activity.class);
        context.startActivity(intent);
    }

    @Override
    public Fragment obtainModule1Fragment() {
        Fragment fragment = new Module1Fragment();
        Bundle bundle = new Bundle();
        bundle.putString("param1", "value1");
        bundle.putString("param2", "value2");
        fragment.setArguments(bundle);
        return fragment;
    }
}

前面提到过，目前社区大多数组件化方案都是使用 自定义私有协议，利用 URL-Scheme 的方式来实现跨模块页面跳转 的，即类似 ARouter 的那种方案，为什么 AppJoint 不采用这种方案呢？

原因其实很简单，假设项目中没有组件化的需求，我们在同一个模块内进行 Activity 的跳转，肯定不会采用 URL-Scheme 方式进行跳转，我们肯定是自己创建 Intent 进行跳转的。其实说到底，使用 URL-Scheme 进行跳转是 不得已而为之，它只是手段，不是目的，因为在组件化之后，模块之间彼此的 Activity 变得不可见了，所以我们转而使用 URL-Scheme 的方式进行跳转。

现在 AppJoint 重新支持了使用代码进行跳转，只需要把跳转的逻辑抽象为接口中的方法暴露给其它模块，其它模块就可以调用这个方法实现跳转逻辑。除此以外，使用接口提供跳转逻辑相比 URL-Scheme 方式还有什么优势呢？

1. 类型安全。充分利用 Java 这种静态类型语言的编译器检查功能，通过接口暴露的跳转方法，无论是传参还是返回值，如果类型错误，在编译期间就能发现错误，而使用 URL-Scheme 进行跳转，如果发生类型上的错误，只能在运行期间才能发现错误。

2. 效率高。即使是使用 URL-Scheme 进行跳转，底层仍然是构造 Intent 进行跳转，但是却额外引入了对跳转 URL 进行构造和解析的过程，涉及到额外的序列化和反序列化逻辑，降低了代码的执行效率。而使用接口提供的跳转逻辑，我们直接构造 Intent 进行跳转，不涉及到任何额外的序列化和反序列化操作，和我们日常的 Activity 跳转逻辑执行效率相同。

3. IDE 友好。使用 URL-Scheme 进行跳转，IDE 无法提供任何智能提示，只能依靠完善的文档或者开发者自身检查来确保跳转逻辑的正确性，而通过接口提供跳转逻辑可以最大限度发挥 IDE 的智能提示功能，确保我们的跳转逻辑是正确的。

4. 易于重构。使用 URL-Scheme 进行跳转，如果遇到跳转逻辑需要重构的情况，例如 Activity 名字的修改，参数名称的修改，参数数量的增删，只能依靠开发者对使用到跳转逻辑的地方一个一个修改，而且无法确保全部都修改正确了，因为编译器无法帮我们检查。而通过接口提供的跳转逻辑代码需要重构时，编译器可以自动帮助我们检查，一旦有地方没有改对，直接在编译期报错，而且 IDE 都提供了智能重构的功能，我们可以方便地对接口中定义的方法进行重构。

5. 学习成本低。我们可以沿用我们熟悉的开发方式，不需要去学习 URL-Scheme 跳转框架的 API。这样还可以保证我们的跳转逻辑不与具体的框架强绑定，我们通过接口隔离了跳转逻辑的真正实现，即使使用 AppJoint 进行跳转，我们也可以在随时把跳转逻辑切换到其他方案，包括 URL-Scheme 方式。

我个人的实践，目前项目中同一进程内的页面跳转已经全部由 AppJoint 的方式实现，目前只有跨进程的页面启动交给了 URL-Scheme 这种方式（例如从浏览器唤醒 App 某个页面）。

最后再提一点，由于跨模块启动 Activity 沿用了跨模块方法调用的开发方式，在业务模块单独编译运行模式下，我们也需要 Mock 这些启动方法。既然我们是在独立调试某个业务模块，我们肯定不是真的希望跳转到那些页面，我们在 Mock 方法里直接输出 Log 或者 Toast 即可。

现在就开始组件化

到这里为止，使用 AppJoint 进行组件化的介绍就已经结束了。AppJoint 的 Github 地址为：https://github.com/PrototypeZ/AppJoint 。核心代码不超过 500 行，您完全可以快速掌握这个工具加速您的组件化开发，只要 Fork 一份代码即可。如果您不想自己引入工程，我们也提供了一个开箱即用的版本，您可以直接通过 Gradle 引入。

1. 在项目根目录的 build.gradle 文件中添加 AppJoint插件 依赖：

1
2
3
4
5
6
7

buildscript {
    ...
    dependencies {
        ...
        classpath 'io.github.prototypez:app-joint:{latest_version}'
    }
}

2. 在主 App 模块和每个组件化的模块添加 AppJoint 依赖：

1
2
3
4

dependencies {
    ...
    implementation "io.github.prototypez:app-joint-core:{latest_version}"
}

3. 在主 App 模块应用 AppJoint插件：

1
2

apply plugin: 'com.android.application'
apply plugin: 'app-joint'

写在最后

通过本文的介绍，我们其实可以发现 AppJoint 是个思想很简单的组件化方案。虽然简单，但是却直接而且够用，尽管没有像其它的组件化方案那样提供了各种各样强大的 API，但是却足以胜任大多数中小型项目，这是我们一以贯之的设计理念。

如果您感觉这个项目对您有帮助，希望可以点一个 Star ，谢谢 : ) 。文章很长，感谢您耐心读完。由于本人能力有限，文章可能存在纰漏的地方，欢迎各位指正，再次谢谢大家！

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

我们在本系列开篇中，曾经留了一个问题：RxJava 是否可以让我们的代码更简洁？作为本系列的最后一篇分享，我们将详细地探讨这个问题。承接前面两篇 “时间维度” 和 “空间维度” 的探讨，我们首先从 RxJava 的维度 开始说起。

RxJava 的维度

在前面两篇分享中，我们解读了很多案例，最终得出结论：RxJava 通过 Observable 这个统一的接口，对其相关的事件，在空间维度和事件维度进行重新组织，来简化我们日常的事件驱动编程。

前文中提到：

有了 Observable 以后的 RxJava 才刚刚插上了想象力的翅膀。

RxJava 所有想象力的基石和源泉在于 Observable 这个统一的接口，有了它，配合我们各种各样的操作符，才可以在时间空间维度玩出花样。

我们回想一下原先我们基于 Callback 的编程范式：

1
2
3

btn.setOnClickListener(v -> {
    // handle click event
})

在基于 Callback 的编程范式中，我们的 Callback 是 没有维度 的。它只能够 响应孤立的事件，即来一个事件，我处理一个事件。假设同一个事件前后存在依赖关系，或者不同事件之间存在依赖关系，无论是时间维度还是空间维度，如果我们还是继续用 Callback 的方式处理，我们必然需要新增许多额外的数据结构来保存中间的上下文信息，同时 Callback 本身的逻辑也需要修改，观察者的逻辑会变得不那么纯粹。

但是 RxJava 给我们的事件驱动型编程带来了新的思路，RxJava 的 Observable 一下子把我们的维度拓展到了时间和空间两个维度。如果事件与事件间存在依赖关系，原先我们需要新增的数据结构以及在 Callback 内写的额外的控制逻辑的代码，现在都可以不用写，我们只需要利用 Observable 的操作符对事件在时间和空间维度进行重新组织，就可以实现一样的效果，而观察者的逻辑几乎不需要修改。

所以如果把 RxJava 的编程思想和传统的面向 Callback 的编程思想进行对比，用一个词形容的话，那就是 降维打击。

这是我认为目前大多数与 RxJava 有关的技术分享没有提到的一个非常重要的点，并且我认为这才是 RxJava 最精髓最核心的思想。RxJava 对我们日常编程最重要的贡献，就是提升了我们原先对于事件驱动型编程的思考的维度，给人一种大梦初醒的感觉，和这点比起来，所谓的 “链式写法” 这种语法糖什么的，根本不值一提。

生产者消费者模式中 RxJava 扮演的角色

无论是同步还是异步，我们日常的事件驱动型编程可以被看成是一种 “生产者——消费者” 模型：

在异步的情况下，我们的代码可以被分为两大块，一块生产事件，一块消费事件，两者通过 Callback 联系起来。而 Callback 是轻量级的，大多数和 Callback 相关的逻辑就仅仅是设置回调和取消设置的回调而已。

如果我们的项目中引入了 RxJava ，我们可以发现，“生产者——消费者” 这个模型中，中间多了一层 RxJava 相关的逻辑层：

而这一层的作用，我们在之前的讨论中已经明确，是用来对生产者产生的事件进行重新组织的。这个架构之下，生产者这一层的变化不会很大，直接受影响的是消费者这一层，由于 RxJava 这一层对事件进行了“预处理”，消费者这一层代码会比之前轻很多。同时由于 RxJava 取代了原先的 Callback 这一层，RxJava 这一层的代码是会比原先 Callback 这一层更厚。

这么做还会有什么其他的好处呢？首先最直接的好处便是代码会更易于测试。原先生产者和消费者之间是耦合的，由于现在引入了 RxJava，生产者和消费者之间没有直接的耦合关系，测试的时候可以很方便的对生产者和消费者分开进行测试。比如原先网络请求相关逻辑，测试就不是很方便，但是如果我们使用 RxJava 进行解耦以后，观察者仅仅只是耦合 Observable 这个接口而已，我们可以自己手动创建用于测试的 Observable，这些 Observable 负责发射 Mock 的数据，这样就可以很方便的对观察者的代码进行测试，而不需要真正的去发起网络请求。

取消订阅与 Scheduler

取消订阅这个功能也是我们在观察者模式中经常用到的一个功能点，尤其是在 Android 开发领域，由于 Activity 生命周期的关系，我们经常需要将网络请求与 Activity 生命周期绑定，即在 Activity 销毁的时候取消所有未完成的网络请求。

常规面向 Callback 的编程方式我们无法在观察者这一层完成取消订阅这一逻辑，我们常常需要找到事件生产者这一层才能完成取消订阅。例如我们需要取消点击事件的订阅时，我们不得不找到点击事件产生的源头，来取消订阅：

1

btn.setOnClickListener(null);

然而在 RxJava 的世界里，取消订阅这个逻辑终于下放到观察者这一层了。事件的生产者需要在提供 Observable 的同时，实现当它的观察者取消订阅时，它应该实现的逻辑（例如释放资源）；事件的观察者当订阅一个 Observable 时，它同时会得到一个 Disposable ，观察者希望取消订阅事件的时候，只需要通过这个接口通知事件生产者即可，完全不需要了解事件是如何产生的、事件的源头在哪里。

至此，生产者和消费者在 RxJava 的世界里已经完成了彻底的解耦。除此以外，RxJava 还提供了好用的线程池，在 生产者——消费者 这个模型里，我们常常会要求两者工作在不同的线程中，切换线程是刚需，RxJava 完全考虑到了这一点，并且把切换线程的功能封装成了 subscribeOn 和 observerOn 两个操作符，我们可以在事件流处理的任何时机随意切换线程，鉴于这一块已经有很多资料了，这里不再详细展开。

面向 Observable 的 AOP：compose 操作符

这一块不属于 RxJava 的核心 Feature，但是如果掌握好这块，可以让我们使用 RxJava 编程效率大大提升。

我们举一个实际的例子，Activity 内发起的网络请求都需要绑定生命周期，即我们需要在 Activity 销毁的时候取消订阅所有未完成的网络请求。假设我目前已经可以获得一个 Observable<ActivityEvent>, 这是一个能接收到 Activity 生命周期的 Observable（获取方法可以借鉴三方框架 RxLifecycle，或者自己内建一个不可见 Fragment，用来接收生命周期的回调）。

那么用来保证每一个网络请求都能绑定 Activity 生命周期的代码应如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public interface NetworkApi {
    @GET("/path/to/api")
    Call<List<Photo>> getAllPhotos();
}

public class MainActivity extends Activity {

    Observable<ActivityEvent> lifecycle = ...
    NetworkApi networkApi = ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // 发起请求同时绑定生命周期
        networkApi.getAllPhotos()
            .compose(bindToLifecycle())
            .subscribe(result -> {
                // handle results
            });
    }

    private <T> ObservableTransformer<T, T> bindToLifecycle() {
        return upstream -> upstream.takeUntil(
            lifecycle.filter(ActivityEvent.DESTROY::equals)
        );
    }
}

如果您之前没有接触过 ObservableTransformer, 这里做一个简单介绍，它通常和 compose 操作符一起使用，用来把一个 Observable 进行加工、修饰，甚至替换为另一个 Observable。

在这里我们封装了一个 bindToLifecycle 方法，它的返回类型是 ObservableTransformer，在 ObservableTransformer 内部，我们修饰了原 Observable, 使其可以在接收到 Activity 的 DESTROY 事件的时候自动取消订阅，这个逻辑是由 takeUntil 这个操作符完成的。其实我们可以把这个 bindToLifecycle 方法抽取出来，放到公共的工具类，这样任何的 Activity 内部发起的网络请求时，都只需要加一行 .compose(bindToLifecycle()) 就可以保证绑定生命周期了，从此再也不必担心由于网络请求引起的内存泄漏和崩溃了。

事实上我们还可以有更多玩法， 上面 ObservableTransformer 内部的 upstream 对象，就是一个 Observable，也就是说可以调用它的 doOnSubscribe 和 doOnTerminate 方法，我们可以在这两个方法里实现 Loading 动画的显隐：

1
2
3
4
5
6
7
8
9
10

private <T> ObservableTransformer<T, T> applyLoading() {
    return upstream -> upstream
        .doOnSubscribe(() -> {
            loading.show();
        })
        .doOnTerminae(() -> {
            loading.dismiss();
        });    
    );
}

这样，我们的网络请求只要调用两个 compose 操作符，就可以完成生命周期的绑定以及与之对应的 Loading 动画的显隐了：

1
2
3
4
5
6

networkApi.getAllPhotos()
    .compose(bindToLifecycle())
    .compose(applyLoading())
    .subscribe(result -> {
        // handle results
    });

操作符 compose 是 RxJava 给我们提供的可以面向 Observable 进行 AOP 的接口，善加利用就可以帮我们节省大量的时间和精力。

RxJava 真的让你的代码更简洁？

在前文中，我们还留了一个问题尚未解答：RxJava 真的更简洁吗？本文中列举了很多实际的例子，我们也看到了，从代码量看，有时候使用 RxJava 的版本比 Callback 的版本更少，有时候两者差不多，有时候 Callback 版本的代码反而更少。所以我们可能无法从代码量上对两者做出公正的考量，所以我们需要从其他方面，例如代码的阅读难度、可维护性上去评判了。

首先我想要明确一点，RxJava 是一个 “夹带了私货” 的框架，它本身最重要的贡献是提升了我们思考事件驱动型编程的维度，但是它与此同时又逼迫我们去接受了函数式编程。函数式编程在处理集合、列表这些数据结构时相比较指令式编程具有先天的优势，我理解框架的设计者，由于框架本身提升了我们对事件思考的维度，那么无论是时间维度还是空间维度，一连串发射出来的事件其实就可以被看成许许多多事件的集合，既然是集合，那肯定是使用函数式的风格去处理更加优雅。

原先的时候，我们接触的函数式编程只是用于处理静态的数据，当我们接触了 RxJava 之后，发现动态的异步事件组成的集合居然也可以使用函数式编程的方式去处理，我不由地佩服框架设计者的脑洞大开。事实上，RxJava 很多操作符都是直接照搬函数式编程中处理集合的函数，例如：map, filter, flatMap, reduce 等等。

但是，函数式编程是一把双刃剑，它也会给你带来不利的因素，一方面，这意味着你的团队都需要了解函数式编程的思想，另一方面，函数式的编程风格，意味着代码会比原先更加抽象。

比如在前面的分享中 “实现一个具有多种类型的 RecyclerView” 这个例子中， combineLatest 这个操作符，完成了原先 onOk() 方法、resultTypes、responseList 一起配合才完成的任务。虽然原先的版本代码不够内聚，不如 RxJava 版本的简练，但是如果从可阅读性和可维护性上来看，我认为原先的版本更好，因为我看到这几个方法和字段，可以推测出这段代码的意图是什么，可是如果是 combineLatest 这个操作符，也许我写的那个时候我知道我是什么意图，一旦过一段时间回来看，我对着这个这个 combineLatest 操作符可能就一脸懵逼了，我必须从这个事件流最开始的地方从上往下捋一遍，结合实际的业务逻辑，我才能回想起为什么当时要用 combineLatest 这个操作符了。

再举一个例子，在 “社交软件上消息的点赞与取消点赞” 这个例子中，如果我不是对这种“把事件流中相邻事件进行比较”的编码方式了如指掌的话，一旦隔一段时间，我再次面对这几个 debounce 、zipWith、flatMap 操作符时，我可能会怀疑自己写的代码。自己写的代码都如此，更何况大多数情况下我们需要面对别人写的代码。

这就是为什么 RxJava 写出的代码会更加抽象，因为 RxJava 的操作符是我们平时处理业务逻辑时常用方法的高度抽象。 combineLatest 是对我们自己写的 onOk 等方法的抽象，zipWith 帮我们省略了本来要写的中间变量，debounce 操作符替代了我们本来要写的计时器逻辑。从功能上来讲两者其实是等价的，只不过 RxJava 给我们提供了高度抽象凝练，更加具有普适性的写法。

在本文前半部分，我们说到过，有的人认为 RxJava 是简洁的，而有的人的看法则完全相反，这件事的本质在于大家对 简洁 的期望不同，大多数人认为的简洁指得是代码简单好理解，而高度抽象的代码是不满足这一点的，所以很多人最后发现理解抽象的 RxJava 代码需要花更多的时间，反而不 “简洁” 。认为 RxJava 简洁的人所认为的 简洁 更像是那种类似数学概念上的那种 简洁，这是因为函数式编程的抽象风格与数学更接近。我们举个例子，大家都知道牛顿第二定律，可是你知道牛顿在《自然哲学的数学原理》上发表牛顿二定律的时候的原始公式表示是什么样的吗：

公式中的 p 表示动量，这是牛顿所认为的”简洁”，而我们大多数人认为简单好记的版本是 “物体的加速度等于施加在物体上的力除以物体的质量”。

这就是为什么，我在前面提前下了那个结论：对于大多数人，RxJava 不等于简洁，有时候甚至是更难以理解的代码以及更低的项目可维护性。

而目前大多数我看到的有关 RxJava 的技术文章举例说明的所谓 “逻辑简洁” 或者是 “随着程序逻辑的复杂性提高，依然能够保持简洁” 的例子大多数都是不恰当的。一方面他们仅仅停留在 Callback 的维度，举那种依次执行的异步任务的例子，完全没有点到 RxJava 对处理问题的维度的提升这一点；二是举的那些例子实在难以令人信服，至少我并没有觉得那些例子用了 RxJava 相比 Callback 有多么大的提升。

RxJava 是否适合你的项目

综上所述，我们可以得出这样的结论，RxJava 是一个思想优秀的框架，而且是那种在工程领域少见的带有学院派气息和理想主义色彩的框架，他是一种新型的事件驱动型编程范式。 RxJava 最重要的贡献，就是提升了我们原先对于事件驱动型编程的思考的维度，允许我们可以从时间和空间两个维度去重新组织事件。

此外，RxJava 好在哪，真的和“观察者模式”、“链式编程”、“线程池”、“解决 Callback Hell”等等关系没那么大，这些特性相比上面总结的而言，都是微不足道的。

我是不会用“简洁”、“逻辑简洁”、“清晰”、“优雅” 那样空洞的字眼去描述 RxJava 这个框架的，这确实是一个学习曲线陡峭的框架，而且如果团队成员整体对函数式编程认识不够深刻的话，项目的后期维护也是充满风险的。

当然我希望你也不要因此被我吓到，我个人是推崇 RxJava 的，在我本人参与的项目中已经大规模铺开使用了 RxJava。本文前面提到过：

RxJava 是一种新的 事件驱动型 编程范式，它以异步为切入点，试图一统 同步 和 异步 的世界。

在我参与的项目中，我已经渐渐能感受到这种 “天下大同” 的感觉了。这也是为什么我能听到很多人都会说 “一旦用了 RxJava 就很难再放弃了”。

也许这时候你会问我，到底推不推荐大家使用 RxJava ？我认为是这样，如果你认为在你的项目里，Callback 模式已经不能满足你的日常需要，事件之间存在复杂的依赖关系，你需要从更高的维度空间去重新思考你的问题，或者说你需要经常在时间或者空间维度上去重新组织你的事件，那么恭喜你， RxJava 正是为你打造的；如果你认为在你的项目里，目前使用 Callback 模式已经很好满足了你的日常开发需要，简单的业务逻辑也根本玩不出什么新花样，那么 RxJava 就是不适合你的。

（完）

本文属于 “RxJava 沉思录” 系列，欢迎阅读本系列的其他分享：

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

在上一篇分享中，我们应该已经对 Observable 在空间维度上重新组织事件的能力 印象深刻了，那么自然而然的，我们容易联想到时间维度，事实上就我个人而言，我认为 Observable 在时间维度上的重新组织事件的能力 相比较其空间维度的能力更为突出。与上一篇类似，本文接下来将通过列举真实的例子来阐述这一论点。

点击事件防抖动

这是一个比较常见的情景，用户在手机比较卡顿的时候，点击某个按钮，正常应该启动一个页面，但是手机比较卡，没有立即启动，用户就点了好几下，结果等手机回过神来的时候，就会启动好几个一样的页面。

这个需求用 Callback 的方式比较难处理，但是相信用过 RxJava 的开发者都知道怎么处理：

1
2
3
4
5
6

RxView.clicks(btn)
    .debounce(500, TimeUnit.MILLISECONDS)
    .observerOn(AndroidSchedulers.mainThread())
    .subscribe(o -> {
        // handle clicks
    })

debounce 操作符产生一个新的 Observable, 这个 Observable 只发射原 Observable 中时间间隔小于指定阈值的最大子序列的最后一个元素。 参考资料：Debounce

虽然这个例子比较简单，但是它很好的表达了 Observable 可以在时间维度上对其发射的事件进行重新组织 , 从而做到之前 Callback 形式不容易做到的事情。

社交软件上消息的点赞与取消点赞

点赞与取消点赞是社交软件上经常出现的需求，假设我们目前有下面这样的点赞与取消点赞的代码：

1
2
3
4
5
6
7
8
9
10
11
12

boolean like;

likeBtn.setOnClickListener(v -> {
    if (like) {
        // 取消点赞
        sendCancelLikeRequest(postId);
    } else {
        // 点赞
        sendLikeRequest(postId);
    }
    like = !like;
});

以下图片素材资源来自 Dribbble

如果你碰巧实现了一个非常酷炫的点赞动画，用户可能会玩得不亦乐乎，这个时候可能会对后端服务器造成一定的压力，因为每次点赞与取消点赞都会发起网络请求，假如很多用户同时在玩这个点赞动画，服务器可能会不堪重负。

和前一个例子的防抖动思路差不多，我们首先想到需要防抖动：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

boolean like;
PublishSubject<Boolean> likeAction = PublishSubject.create();

likeBtn.setOnClickListener(v -> {
    likeAction.onNext(like);
    like = !like;
});

likeAction.debounce(1000, TimeUnit.MILLISECONDS)
    .observerOn(AndroidSchedulers.mainThread())
    .subscribe(like -> {
        if (like) {
            sendCancelLikeRequest(postId);
        } else {
            sendLikeRequest(postId);
        }
    });

写到这个份上，其实已经可以解决服务器压力过大的问题了，但是还是有优化空间，假设当前是已赞状态，用户快速点击 2 下，按照上面的代码，还是会发送一次点赞的请求，由于当前是已赞状态，再发送一次点赞请求是没有意义的，所以我们优化的目标就是将这一类事件过滤掉：

1
2
3
4
5
6
7
8
9
10
11
12
13

Observable<Boolean> debounced = likeAction.debounce(1000, TimeUnit.MILLISECONDS);
debounced.zipWith(
    debounced.startWith(like),
    (last, current) -> last == current ? new Pair<>(false, false) : new Pair<>(true, current)
)
    .flatMap(pair -> pair.first ? Observable.just(pair.second) : Observable.empty())
    .subscribe(like -> {
        if (like) {
            sendCancelLikeRequest(postId);
        } else {
            sendLikeRequest(postId);
        }
    });

zipWith 操作符可以把两个 Observable 发射的相同序号(同为第 x 个)的元素，进行运算转换，得到的新元素作为新的 Observable 对应序号所发射的元素。参考资料：ZipWith

上面的代码，我们可以看到，首先我们对事件流做了一次 debounce 操作，得到 debounced 事件流，然后我们把 debounced 事件流和 debounced.startWith(like) 事件流做了一次 zipWith 操作。相当于新的这个 Observable 中发射的第 n 个元素（n >= 2）是由 debounced 事件流中的第 n 和 第 n-1 个元素运算得到的（新的这个 Observable 中发射的第 1 个元素是由 debounced 事件流中的第 1 个元素和原始点赞状态 like 运算而来）。

运算的结果是得到一个 Pair 对象，它是一个双布尔类型二元组，二元组第一个元素为 true 代表这个事件不该被忽略，应该被观察者观察到；若为 false 则应该被忽略。二元组的第二个元素仅在第一个元素为 true 的情况下才有意义，true 表示应该发起一次点赞操作，而 false 表示应该发起一次取消点赞操作。上面提到的“运算”具体运算的规则是，比较两个元素，若相等，则把二元组的第一个元素置为 false，若不相等，则把二元组的第一个元素置为 true, 同时把二元组的第二个元素置为 debounced 事件流发射的那个元素。

随后的 flatMap 操作符完成了两个逻辑，一是过滤掉二元组第一个元素为 false 的二元组，二是把二元组转化回最初的 Boolean 事件流。其实这个逻辑也可由 filter 和 map 两个操作符配合完成，这里为了简单用了一个操作符。

虽然上面用了不少篇幅解释了每个操作符的意义，但其实核心思想是简单的，就是在原先 debounce 操作符的基础上，把得到的事件流里每个元素和它的上一个元素做比较，如果这个元素和上个元素相同（例如在已赞状态下再次发起点赞操作）, 就把这个元素过滤掉，这样最终的观察者里只会在在真正需要改变点赞状态的时候才会发起网络请求了。

我们考虑用 Callback 实现相同逻辑，虽然比较本次操作与上次操作这样的逻辑通过 Callback 也可以做到，但是 debounce 这个操作符完成的任务，如果要使用 Callback 来实现就非常复杂了，我们需要定义一个计时器，还要负责启动与关闭这个计时器，我们的 Callback 内部会掺杂进很多和观察者本身无关的逻辑，相比 RxJava 版本的纯粹相去甚远。

检测双击事件

首先，我们需要定义双击事件，不妨先规定两次点击小于 500 毫秒则为一次双击事件。我们先使用 Callback 的方式实现：

1
2
3
4
5
6
7

long lastClickTimeStamp;

btn.setOnClickListener(v -> {
    if (System.currentTimeMillis() - lastClickTimeStamp < 500) {
        // handle double click
    }
});

上面的代码很容易理解，我们引入一个中间变量 lastClickTimeStamp, 通过比较点击事件发生时和上一次点击事件的时间差是否小于 500 毫秒，来确认是否发生了一次双击事件。那么如何通过 RxJava 来实现呢？就和上一个例子一样，我们可以在时间维度对 Observable 发射的事件进行重新组织，只过滤出与上次点击事件间隔小于 500 毫秒的点击事件，代码如下：

1
2
3
4
5
6
7
8
9

Observable<Long> clicks = RxView.clicks(btn)
    .map(o -> System.currentTimeMillis())
    .share();
    
clicks.zipWith(clicks.skip(1), (t1, t2) -> t2 - t1)
    .filter(interval -> interval < 500)
    .subscribe(o -> {
        // handle double click
    });

我们再一次用到了 zipWith 操作符来对事件流自身相邻的两个元素做比较，另外这次代码中使用了 share 操作符，用来保证点击事件的 Observable 被转为 Hot Observable。

在RxJava中，Observable可以被分为Hot Observable与Cold Observable,引用《Learning Reactive Programming with Java 8》中一个形象的比喻（翻译后的意思）：我们可以这样认为，Cold Observable在每次被订阅的时候为每一个Subscriber单独发送可供使用的所有元素，而Hot Observable始终处于运行状态当中，在它运行的过程中，向它的订阅者发射元素（发送广播、事件），我们可以把Hot Observable比喻成一个电台，听众从某个时刻收听这个电台开始就可以听到此时播放的节目以及之后的节目，但是无法听到电台此前播放的节目，而Cold Observable就像音乐 CD ，人们购买 CD 的时间可能前后有差距，但是收听 CD 时都是从第一个曲目开始播放的。也就是说同一张 CD ，每个人收听到的内容都是一样的， 无论收听时间早或晚。

仅仅是上面这个双击检测的例子，还不能体现 RxJava 的优越性，我们把需求改得更复杂一点：如果用户在“短时间”内连续多次点击，只能算一次双击操作。这个需求是合理的，因为如果按照上面 Callback 的写法，虽然可以检测出双击操作，但是如果用户快速点击 n 次（间隔均小于 500 毫秒，n >= 2）, 就会触发 n - 1 次双击事件，假设双击处理函数里需要发起网络请求，会对服务器造成压力。要实现这个需求其实也简单，和上一个例子类似，我们用到了 debounce 操作符：

1
2
3
4
5
6
7
8

Observable<Object> clicks = RxView.clicks(btn).share()

clicks.buffer(clicks.debounce(500, TimeUnit.MILLISECONDS))
    .filter(events -> events.size >= 2)
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(o -> {
        // handle double click
    });

buffer 操作符接受一个 Observable 为参数，这个 Observable 所发射的元素是什么不重要，重要的是这些元素发射的时间点，这些时间点会在时间维度上把原来那个 Observable 所发射的元素划分为一系列元素的组，buffer 操作符返回的新的 Observable 发射的元素即为那些“组”。
参考资料: Buffer

上面的代码通过 buffer 和 debounce 两个操作符很巧妙的把点击事件流转化为了我们关心的 “短时间内点击次数超过 2 次” 的事件流，而且新的事件流中任意两个相邻事件间隔必定大于 500 毫秒。

在这个例子中，如果我们想要使用 Callback 去实现相似逻辑，代码量肯定是巨大的，而且鲁棒性也无法保证。

搜索提示

我们平时使用的搜索框中，常常是当用户输入一部分内容后，下方就会显示对应的搜索提示，以支付宝为例，当在搜索框输入“蚂蚁”关键词后，下方自动刷新和关键词相关的结果：

为了简化这个例子，我们不妨定义根据关键词搜索的接口如下：

1
2
3
4

public interface Api {
    @GET("path/to/api")
    Observable<List<String>> queryKeyword(String keyword);
}

查询接口现在已经确定下来，我们考虑一下在实现这个需求的过程中需要考虑哪些因素：

1. 防止用户输入过快，触发过多网络请求，需要对输入事件做一下防抖动。
2. 用户在输入关键词过程中可能触发多次请求，那么，如果后一次请求的结果先返回，前一次请求的结果后返回，这种情况应该保证界面展示的是后一次请求的结果。
3. 用户在输入关键词过程中可能触发多次请求，那么，如果后一次请求的结果返回时，前一次请求的结果尚未返回的情况下，就应该取消前一次请求。

综合考虑上面的因素以后，我们使用 RxJava 实现的对应的代码如下：

1
2
3
4
5
6
7

RxTextView.textChanges(input)
    .debounce(300, TimeUnit.MILLISECONDS)
    .switchMap(text -> api.queryKeyword(text.toString()))
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(results -> {
        // handle results
    });

switchMap 这个操作符与 flatMap 操作符类似，但是区别是如果原 Observable 中的两个元素，通过 switchMap 操作符都转为 Observable 之后，如果后一个元素对应的 Observable 发射元素时，前一个元素对应的 Observable 尚未发射完所有元素，那么前一个元素对应的 Observable 会被自动取消订阅，尚未发射完的元素也不会体现在 switchMap 操作符调用后产生的新的 Observable 发射的元素中。
参考资料：SwitchMap

我们分析上面的代码，可以发现: debounce 操作符解决了问题 1，switchMap 操作符解决了问题 2、3。这个例子可以很好的说明，RxJava 的 Observable 可以通过一系列操作符从时间的维度上重新组织事件，从而简化观察者的逻辑。这个例子如果使用 Callback 来实现，肯定是十分复杂的，需要设置计时器以及一堆中间变量，观察者中也会掺杂进很多额外的逻辑，用来保证事件与事件的依赖关系。

（未完待续）

本文属于 “RxJava 沉思录” 系列，欢迎阅读本系列的其他分享：

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

在上一篇分享中，我们澄清了目前有关 RxJava 的几个最流行的误解，它们分别是：“链式编程是 RxJava 的厉害之处”，“RxJava 等于异步加简洁”，“RxJava 是用来解决 Callback Hell 的”。在上一篇的最后，我们了解了 RxJava 其实给我们最基础的功能就是帮我们统一了所有异步回调的接口。但是 RxJava 并不止于此，本文我们将首先介绍 Observable 在空间维度上重新组织事件的能力。

从一个简单的例子说起

情景：有一个相册应用，从网络获取当前用户的照片列表，展示在 RecyclerView 里：

1
2
3
4

public interface NetworkApi {
    @GET("/path/to/api")
    Call<List<Photo>> getAllPhotos();
}

上面是使用 Retrofit 定义的从网络获取照片的 API 的接口。大家都知道，如果我们使用 Retrofit 的 RxJavaCallAdapter 就可以把接口中的返回类型从 Call<List<Photo>> 转为 Observable<List<Photo>>:

1
2
3
4

public interface NetworkApi {
    @GET("/path/to/api")
    Observable<List<Photo>> getAllPhotos();
}

那么我们使用这个接口展示照片的代码应该长下面这样：

1
2
3
4
5
6
7
8

NetworkApi networkApi = ...
networkApi.getAllPhotos()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(photos -> {
        adapter.setData(photos);
        adapter.notifyDataSetChanged();
    });

现在新加一个需求，请求当前用户照片列表这个网络请求，需要加入缓存功能（缓存的是网络响应中的图片的URL，图片的 Bitmap 缓存交给专门的图片加载框架，例如 Glide），也就是说，当用户希望展示图片列表时，先去缓存读取用户的照片列表进行加载（如果缓存里有这个接口的上次访问的数据），同时发起网络请求，待网络请求返回之后，更新缓存，同时使用使用最新的返回数据刷新照片列表。如果我们选择使用 JakeWharton 的 DiskLruCache 作为我们的缓存介质，那么上面的代码将变为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

DiskLruCache cache = ... 
DiskLruCache.Snapshot snapshot = cache.get("getAllPhotos");
if (snapshot != null) {
    // 读取缓存数据并反序列化
    List<Photo> cachedPhotos = new Gson().fromJson(
        snapshot.getString(VALUE_INDEX),
        new TypeToken<List<Photo>>(){}.getType()
    );
    // 刷新照片列表
    adapter.setData(photos);
    adapter.notifyDataSetChanged();
}
NetworkApi networkApi = ...
networkApi.getAllPhotos()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(photos -> {
        adapter.setData(photos);
        adapter.notifyDataSetChanged();

        // 更新缓存
        DiskLruCache.Editor editor = cache.edit("getAllPhotos");
        editor.set(VALUE_INDEX, new Gson().toJson(photos)).commit();
    });

上面的代码就是最直观的可以解决需求的代码，我们进一步思考一下，读取文件缓存也属于耗时操作，我们最好把它封装为异步任务，既然网络请求已经被封装成 Observable 了，我们尝试把读取文件缓存也封装为 Observable :

1
2
3
4
5
6
7
8
9
10
11

Observable<List<Photo>> cachedObservable = Observable.create(emitter -> {
    DiskLruCache.Snapshot snapshot = cache.get("getAllPhotos");
    if (snapshot != null) {
        List<Photo> cachedPhotos = new Gson().fromJson(
            snapshot.getString(VALUE_INDEX),
            new TypeToken<List<Photo>>(){}.getType()
        );
        emitter.onNext(cachedPhotos);
    } 
    emitter.onComplete();
});

到目前为止，发起网络请求和读取缓存这两个异步操作都被我们封装成了 Observable 的形式，前面做了这么多铺垫，接下来进入正题：把原先的面向 Callback 的异步操作统一改写为 Observable 的形式以后，首先带来的好处就是可以对 Observable 在空间维度上进行重新组织。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

networkApi.getAllPhotos()
    .doOnNext(photos -> 
        // 更新缓存
        cache.edit("getAllPhotos")
            .set(VALUE_INDEX, new Gson().toJson(photos))
            .commit()
    )
    // 读取现有缓存
    .startWith(cachedObservable)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(photos -> {
        adapter.setData(photos);
        adapter.notifyDataSetChanged();
    });

调用 startWith 操作符后，会生成一个新的 Observable，新的 Observable 会首先发射传入的 Observable 包含的元素，而后才会发射原来的 Observable 包含的元素。例如 Observable A 包含 a1, a2 两个元素， Observable B 包含 b1, b2 两个元素，那么 b.startWith(a) 返回的新 Observable 发射序列顺序为： a1, a2, b1, b2。—— 参考资料：StartWith

在上面的例子中，我们连接了网络请求和读取缓存这两个 Observable，原先需要分别处理结果的两个异步任务，我们现在把它们结合成了一个，指定了一个观察者就满足了需求。这个观察者会被回调 2 次，第一次是来自缓存的结果，第二次是来自网络的结果，体现在界面上就是列表刷新了两次。

这里引发了我们的思考，原先 Callback 的写法，如果我们有 n 个异步任务，我们就需要指定 n 个回调；而如果在 n 个异步任务都已经被封装成 Observable 的情况下，我们就可以对 Observable 进行分类、组合、变换，经过这样的处理以后，我们的观察者的数量就会减少，而且职责会变的简单而直接，只需要对它所关心的数据类型做出响应，而不需要关心数据从何而来，经历过怎样的变化。

我们再进一步，上面的例子再加一个需求：如果从网络请求回来的数据和缓存中提前响应的数据一致，就不需要再刷新一次了。也就是说，如果缓存数据和网络数据一致，那缓存数据刷新一次列表以后，网络数据不需要再去刷新一次列表了。

我们考虑一下，如果我们使用传统 Callback 的形式，指定了两个 Callback 去处理这个需求，为了保证第二次网络请求回来的相同数据不刷新，我们势必需要在两个 Callback 之外，定义一个变量来保存缓存数据，然后在网络请求的回调内，比较两个值，来决定是否需要刷新界面。

但如果我们用 RxJava 如何来实现这个需求，该如何写呢：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

networkApi.getAllPhotos()
    .doOnNext(photos -> 
        cache.edit("getAllPhotos")
            .set(VALUE_INDEX, new Gson().toJson(photos))
            .commit()
    )
    .startWith(cachedObservable)
    // 保证不会出现相同数据
    .distinctUntilChanged()
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(photos -> {
        adapter.setData(photos);
        adapter.notifyDataSetChanged();
    });

distinctUntilChanged 操作符用来确保 Observable 发射的元素里，相邻的两个元素必须是不相等的。 参考资料：Distinct

与原先的写法相比，只多了一行 .distinctUntilChanged() ( 我们假设用于比较两个对象是否相等的 equals 方法已经实现 )，就可以满足，在网络数据和缓存数据一致的情况下，观察者只回调一次。

我们比较一下使用 Callback 的写法和使用 Observable 进行组装的写法，可以发现，使用 Callback 的写法，经常会由于需求的变化，导致 Callback 内部的逻辑发生变动，而使用 Observable 的写法，观察者的核心逻辑则较为稳定，很少发生变化（本例中为刷新列表）。Observable 通过内置的操作符对自身发射的元素在空间维度上重新组织，或者与其他的 Observable 一起在空间维度上进行重新组织，使得观察者的逻辑简单而直接，不需要关心数据从何而来，从而使观察者的逻辑较为稳定。

一个复杂的例子

情景：实现一个具有多种类型的 RecyclerView，如图所示：

假设列表中有 3 种类型的数据，这 3 种类型共同填充了一个 RecyclerView，简单起见，我们定义 Retrofit 接口如下：

1
2
3
4
5
6
7
8

public interface NetworkApi {
    @GET("/path/to/api")
    Observable<List<ItemA>> getItemListOfTypeA();
    @GET("/path/to/api")
    Observable<List<ItemB>> getItemListOfTypeB();
    @GET("/path/to/api")
    Observable<List<ItemC>> getItemListOfTypeC();
}

到目前为止，情况还是简单的, 我只要维护 3 个 RecyclerView 并分别各自更新即可。但是我们现在接到新加需求，这 3 种类型的数据在列表中出现的顺序是可配置的，而且 3 种类型数据不一定全部需要展示，也就是说可能展示 3 种，也可能只展示其中 2 种。我们定义与之对应的接口：

1
2
3
4
5
6
7
8
9
10
11

public interface NetworkApi {
    @GET("/path/to/api")
    Observable<List<ItemA>> getItemListOfTypeA();
    @GET("/path/to/api")
    Observable<List<ItemB>> getItemListOfTypeB();
    @GET("/path/to/api")
    Observable<List<ItemC>> getItemListOfTypeC();
    // 需要展示的数据顺序
    @GET("/path/to/api")
    Observable<List<String>> getColumns();
}

新加的 getColumns 接口，返回的数据形如：

• ["a", "b", "c"]
• ["b", "a"]
• ["b", "c"]

首先考虑使用普通的 Callback 形式如何来实现这个需求。由于 3 种数据现在顺序可变，数量也无法确定，如果还是考虑由多个 RecyclerView 来维护的话需要在布局中调用 addView, removeView
来添加移除 RecyclerView，这样的话性能上不够好，我们考虑把所有数据填充到一个 RecyclerView 中，不同类型的数据通过不同 ItemType 进行区分。下面的代码中我依然使用了 Observable ，只是我仅仅把它当成普通的 Callback 功能使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

private NetworkApi networkApi = ...
// 不同类型数据出现的顺序
private List<String> resultTypes;
// 这些类型对应的数据的集合
private LinkedList<List<? extends Item>> responseList;

public void refresh() {
    networkApi.getColumns().subscribe(columns -> {
        // 保存配置的栏目顺序
        resultTypes = columns;
        responseList = new LinkedList<>(Collections.nCopies(columns.size(), new ArrayList<>()));
        for (String type : columns) {
            switch (type) {
                case "a":
                    networkApi.getItemListOfTypeA().subscribe(data -> onOk("a", data));
                    break;
                case "b":
                    networkApi.getItemListOfTypeB().subscribe(data -> onOk("b", data));
                    break;
                case "c":
                    networkApi.getItemListOfTypeC().subscribe(data -> onOk("c", data));
                    break;
            }
        }
    });
}

private void onOk(String type, List<? extends Item> response) {
    // 按配置的顺序，更新对应位置上的数据
    responseList.set(resultTypes.indexOf(type), response);
    // 把当前已返回的数据填充到一个 List 中
    List<Item> data = new ArrayList<>();
    for (List<? extends Item> itemList: responseList) {
        data.addAll(itemList);
    }
    // 更新列表
    adapter.setData(data);
    adapter.notifyDataSetChanged();
}

上面的代码，为了避免 Callback Hell 出现，我已经提前把 onOk 提到了外部层次，使代码便于从上往下阅读。但是不知道你有没有和我相同的感觉，就是类似这样的代码总给人一种不是很 “内聚” 的感觉，就是为了把 Callback 展平，导致一些中间变量被暴露到了外层空间。

带着这个问题，我们先分析一下数据流动：

1. refresh 方法发起第一次请求，得到需要被展示的 n 种数据的类型以及顺序。
2. 根据第一次请求的结果，发起 n 次请求，分别得到每种数据的结果。
3. onOk 方法作为观察者, 会被回调 n 次，按照第一个接口里返回的顺序正确的汇总 2 中每个数据接口返回的结果，并且通知界面更新。

有点像写作文一样，这是一种 总——分——总 的结构。

Observable 在空间维度重新组织事件

接下来我们使用 RxJava 来实现这个需求，我们会用到 RxJava 的一些操作符，来对 Observable 进行重新组织：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

NetworkApi networkApi = ...

networkApi.getColumns()
    .map(types -> {
        List<Observable<? extends List<? extends Item>>> requestObservableList = new ArrayList<>();
        for (String type : types) {
            switch (type) {
                case "a":
                    requestObservableList.add(
                        networkApi.getItemListOfTypeA().startWith(new ArrayList<ItemA>())
                    );
                    break;
                case "b":
                    requestObservableList.add(
                        networkApi.getItemListOfTypeB().startWith(new ArrayList<ItemB>())
                    );
                    break;
                case "c":
                    requestObservableList.add(
                        networkApi.getItemListOfTypeC().startWith(new ArrayList<ItemC>())
                    );
                    break;
            }
        }
        return requestObservableList;
    })
    .flatMap(requestObservables -> Observable.combineLatest(requestObservables, objects -> {
        List<Item> items = new ArrayList<>();
        for (Object response : objects) {
            items.addAll((List<? extends Item>) response);
        }
        return items;
    }))
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(data -> {
        adapter.setData(data);
        adapter.notifyDataSetChanged();
    });

我们一步一步分析 RxJava 处理的具体步骤。首先是第一步，获取需要展示的栏目列表，这是最简单的，networkApi.getColumns() 这个方法返回是一个只发射一个元素的 Observable，这个元素即为展示的栏目列表，为了方便后续讨论，假设栏目的顺序为 ["a", "b", "c"], 如下图所示：

接下来的操作符是 map 操作符，原来的 Observable 进行了变换，变成了一个新的 Observable，新的 Observable 还是只发射一个元素，这个元素的类型还是 List ，只不过 List 内部的数据类型从原先的字符串（代表数据类型）变成了 Observable。Observable 发射的元素还可以是 “Observable 的 List ” 吗？是的，没有什么不可以 : )

map 操作符负责把一个 Observable 里发射的元素全部进行转换，生成一个发射新的元素的 Observable，元素的种类会发生改变，但是发射的元素的数量不会发生改变。 参考资料：Map

这个操作，在业务上的含义是，根据上一步取回的栏目列表，即 ["a", "b", "c"]，根据不同的数据类型，分别发起请求去获取对应栏目的数据列表，例如栏目类型是 a 的话，就对应发起 networkApi.getItemListOfTypeA() 请求。这里有一点值得注意，就是每一个具体的请求后面都跟了一个 .startWith(new ArrayList<>())，也就是说每个具体请求栏目内容的 Observable 在返回真正的数据 List 之前都会返回一个空的 List ，这里这么处理的原因我们会在下一步中解释。

接下来这一步可能是最难理解的一步了，map 操作之后，紧接着是 flatMap 操作符，而 flatMap 操作符传入的 lambda 表达式内部，又调用了 Observable.combineLatest 操作符，我们先从里面的 combineLatest 操作符开始讲起，请看下图：

combineLatest 操作符的第一个参数 requestObservables，它的类型是 Observable 的 List，它就是上一步中 map 操作符进行变换之后，新的 Observable 发射的数据，即由

• networkApi.getItemListOfTypeA().startWith(...)
• networkApi.getItemListOfTypeB().startWith(...)
• networkApi.getItemListOfTypeC().startWith(...)

3 个 Observable 组成的 List。

combineLatest 操作符的第二个参数是个 lambda 表达式，这个 lambda 表达式的参数类型是 Object[]，这个数组的长度等于 requestObservables 的长度，Object[] 数组中每个元素即为 requestObservables 中每个 Observable 发射的元素，即：

• Object[0] 对应 requestObservables[0] 发射的元素
• Object[1] 对应 requestObservables[1] 发射的元素
• Object[2] 对应 requestObservables[2] 发射的元素

那这个 lambda 表达式被调用的时机是什么时候呢？当 requestObservables 中任意一个 Observable 发射一个元素时，这个元素便会和 requestObservables 中剩余的所有 Observable 最近一次 发射的元素一起，作为参数调用这个 lambda 表达式。

那么整个 combineLatest 操作符的作用就是，返回一个新的 Observable, 根据第一个参数里输入的一组 Obsevable，按照上面说的时机，调用第二个参数里的那个 lambda 表达式，把这个 lambda 表达式的返回值，作为新的 Observable 发射的值，lambda 被调用几次，就发射几个元素。

参考资料：CombineLatest

我们这里 lambda 表达式内部的逻辑比较简单，就是把 3 个接口里返回的数据进行汇总，组成一个新的 List 。我们再回过头看上面那张图，我们可以看到，Observable.combinLatest 返回的新的 Observable 一共发射了 4 个元素，它们分别是：

• []
• [{ItemB}, {ItemB}, ...]
• [{ItemA}, {ItemA}, ..., {ItemB}, {ItemB}, ...]
• [{ItemA}, {ItemA}, ..., {ItemB}, {ItemB}, ..., {ItemC}, {ItemC}, ...]

前面留了一个问题没有解释，为什么 3 个获取具体的栏目数据的接口需要调用 startWith 操作符发射一个空白列表，就像这样：networkApi.getItemListOfTypeA().startWith(...)，现在这个答案应该清晰了，如果不调用这个操作符，那么 combineLatest 操作符生成的新 Observable 将会只发射一个元素, 即上面 4 个元素的最后一个，从用户的感受来看，必须要等所有栏目全部请求成功以后才会一次性展示，而不是渐进地展示。

说完了内部的 combineLatest 操作符，现在该说外层的 flatMap 操作符了，flatMap 操作符也会生成一个新的 Observable，它会通过传入的 lambda 表达式，把旧的 Observable 里发射的每一个元素都映射成一个 Observable，然后把这些 Observable 发射的所有元素作为新的 Observable 发射的元素。

参考资料：FlatMap

由于我们这里的情况，调用 flatMap 之前的 Observable 只发射了一个元素，所以 flatMap 之后生成的新 Observable 发射的元素，就是 flatMap 操作符传入的那个 lambda 表达式执行完生成的那个 Observable 所发射的元素，也就是说 flatMap 操作符执行完后的那个新的 Observable 发射的元素，和我们刚刚讨论的 combineLatest 操作符执行完后的 Observable 发射的元素是一致的。

到这里为止，RxJava 实现的版本的每一步我们都解释完了，我们回过头重新梳理一下 RxJava 对 Observable 进行变换的过程，如下图：

通过 RxJava 的操作符，我们把 networkApi 里的 4 个接口返回的 4 个 Observable，在空间维度进行了重新组织，最终把它们转成了一个 Observable，这个 Observable 发射的元素类型是 List<Item>，而这正是我们的观察者 – Adapter 所关心的数据类型，观察者只需要监听这个 Observable ，并更新数据即可。

我们在讲 RxJava 实现的这个版本之前的时候，说到过 Callback 实现的版本不够 内聚，比较一下现在这个 RxJava 的版本，确实可以发现的确 RxJava 这个版本更内聚。但是并非 Callback 版本没有办法做到更内聚，我们可以把 Callback 版本里的 onOk, refresh，resultTypes, responseList 这几个方法和字段封装到一个对象中，对外只暴露 refresh 方法和一个设置观察者的方法，也可以做到一样的内聚，但是这就需要额外的工作量了。可如果我们使用 RxJava 就不一样了，它提供了一堆现成的操作符，通过 Observable 之间的变换与重组，直接就可以写出内聚的代码。

在上面代码里出现的所有操作符中，最核心的一个操作符就是 combineLatest 操作符，仔细比较 RxJava 版本和 Callback 版本就可以发现，combineLatest 操作符的功能其实和 Callback 版本里的 onOk 方法前半部分, resultTypes, responseList 合在一起功能是相当的，一方面负责收集多个接口返回的数据，另一方面保证收集回来的数据的顺序是和上一个接口返回的应该展示的数据的顺序是一致的。

一种更加函数式的写法

从代码量上来看，RxJava 版本与 Callback 版本相差无几，对函数式编程比较擅长的人来说，RxJava 版本里 for 循环的写法，不够 “函数式”，我们可以把原来的写法改成一种更紧凑、更函数式的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

NetworkApi networkApi = ...

netWorkApi.getColumns()
    .flatMap(types -> Observable.fromIterable(types)
        .map(type -> {
            switch (type) {
                case "a": return netWorkApi.getItemListOfTypeA().startWith(new ArrayList<ItemA>());
                case "b": return netWorkApi.getItemListOfTypeB().startWith(new ArrayList<ItemB>());
                case "c": return netWorkApi.getItemListOfTypeC().startWith(new ArrayList<ItemC>());
                default: throw new IllegalArgumentException();
            }
        })
        .<List<Observable<? extends List<? extends Item>>>>collectInto(new ArrayList<>(), List::add)
        .toObservable()
    )
    .flatMap(requestObservables -> Observable.combineLates(requestObservables, objects -> objects))
    .flatMap(objects -> Observable.fromArray(objects)
        .<List<Item>>collectInto(new ArrayList<>(), (items, o) -> items.addAll((List<Item>) o))
        .toObservable()
    )
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(data -> {
        adapter.setData(data);
        adapter.notifyDataSetChanged();
    });

这里引入了一个新的操作符 collectInto，用于把一个 Observable 里面发射的元素，收集到一个可变的容器内部，本例中用它来替换 for 循环相关逻辑，具体内容这里不再详细展开。
参考资料：CollectInto

小结

第二个例子花了这么大篇幅来讲，超出了我一开始的预期，这也可以看出来的确 RxJava 学习的曲线是陡峭的，不过我认为这个例子很好的表达我这一小节要阐述的观点，即 Observable 在空间维度上对事件的重新组织，让我们的事件驱动型编程更具想象力 ，因为原先的编程中，我们面对多少个异步任务，就会写多少个回调，如果任务之间有依赖关系，我们的做法就是修改观察者（回调函数）逻辑以及新增数据结构保证依赖关系，RxJava 给我们带来的新思路是，Observable 的事件在到达观察者之前，可以先通过操作符进行一系列变换（当然变换的规则还是和具体业务逻辑有关的），对观察者屏蔽数据产生的复杂性，只提供给观察者简单的数据接口。

那么是否在这个例子中，是否 RxJava 的版本更好呢，我个人的观点是虽然 RxJava 版本展现了其更有想象力的编程方式，但是就这个具体的例子，两者并没有太大的差距。RxJava 可以写出更短更内聚的代码，但是编写和理解的难度较大；Callback 版本虽然朴实无华，但是便于编写以及理解，可维护性更好。对于两者的好坏，我们也不要过于着急下结论，不妨继续看看 RxJava 还有什么其他的优势。

（未完待续）

本文属于 “RxJava 沉思录” 系列，欢迎阅读本系列的其他分享：

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

随后工作中有机会使用 RxJava 重构了项目的网络请求以及缓存层，期间陆陆续续又重构了数据访问层，以及项目中其他的一些功能模块，无一例外，我们都选择使用了 RxJava 。

最近翻看一些技术文章，发现涉及 RxJava 的文章还是大多以入门为主，我尝试从一个初学者的角度阅读，发现很多文章都没讲到关键的概念点，举的例子也不够恰当。回想起两年前刚刚学习 RxJava 的自己，虽然看了许多 RxJava 入门的文章，但是始终无法理解 RxJava 究竟好在哪里，所以一定是哪里出问题了。于是有了这一篇反思，希望能和你一起重新思考 RxJava，以及重新思考 RxJava 是否真的让我们的开发变得更轻松。

观察者模式有那么神奇吗?

几乎所有 RxJava 入门介绍，都会用一定的篇幅去介绍 “观察者模式”，告诉你观察者模式是 RxJava 的核心，是基石:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

observable.subscribe(new Observer<String>() {
    @Override
    public void onNext(String s) {
        Log.d(tag, "Item: " + s);
    }

    @Override
    public void onCompleted() {
        Log.d(tag, "Completed!");
    }

    @Override
    public void onError(Throwable e) {
        Log.d(tag, "Error!");
    }
})

年少的我不明觉厉：“好厉害，原来这是观察者模式”，但是心里还是感觉有点不对劲：“这代码是不是有点丑？接收到数据的回调名字居然叫 onNext ? ”

但是其实观察者并不是什么新鲜的概念，即使你是新手，你肯定也已经写过不少观察者模式的代码了，你能看懂下面一行代码说明你已经对观察者模式了然于胸了：

1

button.setOnClickListener(v -> doSomething());

这就是观察者模式，OnClickListener 订阅了 button 的点击事件，就这么简单。原生的写法对比上面 RxJava 那一长串的写法，是不是要简单多了。有人可能会说，RxJava 也可以写成一行表示：

1

RxView.clicks(button).subscribe(v -> doSomething());

先不说这么写需要引入 RxBinding 这个第三方库，不考虑这点，这两种写法最多也只是打个平手，完全体现不出 RxJava 有任何优势。

这就是我要说的第一个论点，如果仅仅只是为了使用 RxJava 的观察者模式，而把原先 Callback 的形式，改为 RxJava 的 Observable 订阅模式是没有价值的，你只是把一种观察者模式改写成了另一种观察者模式。我是实用主义者，使用 RxJava 不是为了炫技，所以观察者模式是我们使用 RxJava 的理由吗？当然不是。

链式编程很厉害吗?

链式编程也是每次提到 RxJava 的时候总会出现的一个高频词汇，很多人形容链式编程是 RxJava 解决异步任务的 “杀手锏”：

1
2
3
4
5
6
7

Observable.from(folders)
    .flatMap((Func1) (folder) -> { Observable.from(file.listFiles()) })
    .filter((Func1) (file) -> { file.getName().endsWith(".png") })
    .map((Func1) (file) -> { getBitmapFromFile(file) })
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe((Action1) (bitmap) -> { imageCollectorView.addImage(bitmap) });

这段代码出现的频率非常的高，好像是 RxJava 的链式编程给我们带来的好处的最佳佐证。然而平心而论，我看到这个例子的时候，内心是平静的，并没有像大多数文章写得那样，内心产生“它很长，但是很清晰”的心理活动。

首先，flatMap, filter, map 这几个操作符，对于没有函数式编程经验的初学者来讲，并不好理解。其次，虽然这段代码用了很多 RxJava 的操作符，但是其逻辑本质并不复杂，就是在后台线程把某个文件夹里面的以 png 结尾的图片文件解析出来，交给 UI 线程进行渲染。

上面这段代码，还带有一个反例，使用 new Thread() 的方式实现的版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

new Thread() {
    @Override
    public void run() {
        super.run();
        for (File folder : folders) {
            File[] files = folder.listFiles();
            for (File file : files) {
                if (file.getName().endsWith(".png")) {
                    final Bitmap bitmap = getBitmapFromFile(file);
                    getActivity().runOnUiThread(new Runnable() {
                        @Override
                        public void run() {
                            imageCollectorView.addImage(bitmap);
                        }
                    });
                }
            }
        }
    }
}.start();

对比两种写法，可以发现，之所以 RxJava 版本的缩进减少了，是因为它利用了函数式的操作符，把原本嵌套的 for 循环逻辑展平到了同一层次，事实上，我们也可以把上面那个反例的嵌套逻辑展平，既然要用 lambda 表达式，那肯定要大家都用才比较公平吧：

1
2
3
4
5
6
7
8
9
10
11
12

new Thread(() -> {
    File[] pngFiles = new File[]{};
    for (File folder : folders) {
        pngFiles = ArrayUtils.addAll(pngFiles, folder.listFiles());
    }
    for (File file : pngFiles) {
        if (file.getName().endsWith(".png")) {
            final Bitmap bitmap = getBitmapFromFile(file);
            getActivity().runOnUiThread(() -> imageCollectorView.addImage(bitmap));
        }
    }
}).start();

坦率地讲，这段代码除了 new Thread().start() 有槽点以外，没什么大毛病。RxJava 版本确实代码更少，同时省去了一个中间变量 pngFiles，这得益于函数式编程的 API，但是实际开发中，这两种写法无论从性能还是项目可维护性上来看，并没有太大的差距，甚至，如果团队并不熟悉函数式编程，后一种写法反而更容易被大家接受。

回到刚才说的“链式编程”，RxJava 把目前 Android Sdk 24 以上才支持的 Java 8 Stream 函数式编程风格带到了带到了低版本 Android 系统上，确实带给我们一些方便，但是仅此而已吗？到目前为止我并没有看到 RxJava 在处理事件尤其是异步事件上有什么特别的手段。

准确的来说，我的关注点并不在大多数文章鼓吹的“链式编程”这一点上，把多个依次执行的异步操作的调用转化为类似同步代码调用那样的自上而下执行，并不是什么新鲜事，而且就这个具体的例子，使用 Android 原生的 AsyncTask 或者 Handler 就可以满足需求，RxJava 相比原生的写法无法体现它的优势。

除此以外，对于处理异步任务，还有 Promise 这个流派，使用类似这样的 API:

1
2
3
4
5

promise
    .then(r1 -> task1(r1))
    .then(r2 -> task2(r2))
    .then(r3 -> task3(r3))
    ...

难道不是比 RxJava 更加简洁直观吗？而且还不需要引入函数式编程的内容。这种写法，跟所谓的“逻辑简洁”也根本没什么关系，所以从目前看来，RxJava 在我心目只是个 “哦，还挺不错” 的框架，但是并没有惊艳到我。

以上是我要说的第二个论点，链式编程的形式只是一种语法糖，通过函数式的操作符可以把嵌套逻辑展平，通过别的方法也可以把嵌套逻辑展平，这只是普通操作，也有其他框架可以做到相似效果。

RxJava 等于异步加简洁吗?

相信阅读过本文开头介绍的那篇 RxJava 入门文 《给 Android 开发者的 RxJava 详解》 的开发者一定对文中两个小标题印象深刻：

RxJava 到底是什么？ —— 一个词：异步

RxJava 好在哪？ —— 一个词：简洁

首先感谢扔物线，很用心地为初学者准备了这篇简洁朴实的入门文。但是我还是想要指出，这样的表达是不够严谨的。

虽然我们使用 RxJava 的场景大多数与异步有关，但是这个框架并不是与异步等价的。举个简单的例子：

1

Observable.just(1,2,3).subscribe(System.out::println);

上面的代码就是同步执行的，和异步没有关系。事实上，RxJava 除非你显式切换到其他的 Scheduler，或者你使用的某些操作符隐式指定了其他 Scheduler，否则 RxJava 相关代码就是同步执行的。

这种设计和这个框架的野心有关，RxJava 是一种新的 事件驱动型 编程范式，它以异步为切入点，试图一统 同步 和 异步 的世界。
本文前面提到过：

RxJava 把目前 Android Sdk 24 以上才支持的 Java 8 Stream 函数式编程风格带到了带到了低版本 Android 系统上。

所以只要你愿意，你完全可以在日常的同步编程上使用 RxJava，就好像你在使用 Java 8 的 Stream API。( 但是两者并不等价，因为 RxJava 是事件驱动型编程 )

如果你把日常的同步编程，封装为同步事件的 Observable，那么你会发现，同步和异步这两种情况被 RxJava 统一了, 两者具有一样的接口，可以被无差别的对待，同步和异步之间的协作也可以变得比之前更容易。

所以，到此为止，我这里的结论是：RxJava 不等于异步。

那么 RxJava 等于 简洁 吗？我相信有一些人会说 “是的，RxJava 很简洁”，也有一些人会说 “不，RxJava 太糟糕了，一点都不简洁”。这两种说法我都能理解，其实问题的本质在于对 简洁 这个词的定义上。关于这个问题，后续会有一个小节专门讨论，但是我想提前先下一个结论，对于大多数人，RxJava 不等于简洁，有时候甚至是更难以理解的代码以及更低的项目可维护性。

RxJava 是用来解决 Callback Hell 的吗?

很多 RxJava 的入门文都宣扬：RxJava 是用来解决 Callback Hell （有些翻译为“回调地狱”）问题的，指的是过多的异步调用嵌套导致的代码呈现出的难以阅读的状态。

我并不赞同这一点。Callback Hell 这个问题，最严重的重灾区是在 Web 领域，是使用 JavaScript 最常见的问题之一，以至于专门有一个网站 callbackhell.com 来讨论这个问题，由于客户端编程和 Web 前端编程具有一定的相似性，Android 编程或多或少也存在这个问题。

上面这个网站中，介绍了几种规避 Callback Hell 的常见方法，无非就是把嵌套的层次移到外层空间来，不要使用匿名的回调函数，为每个回调函数命名。如果是 Java 的话，对应的，避免使用匿名内部类，为每个内部类的对象，分配一个对象名。当然，也可以使用框架来解决这类问题，使用类似 Promise 那样的专门为异步编程打造的框架，Android 平台上也有类似的开源版本 jdeferred。

在我看来，jdeferred 那样的框架，更像是那种纯粹的用来解决 Callback Hell 的框架。 至于 RxJava，前面也提到过，它是一个更有野心的框架，正确使用了 RxJava 的话，确实不会有 Callback Hell 再出现了，但如果说 RxJava 就是用来解决 Callback Hell 的，那就有点高射炮打蚊子的意味了。

如何理解 RxJava

也许阅读了前面几小节内容之后，你的心中会和曾经的我一样，对 RxJava 产生一些消极的想法，并且会产生一种疑问：那么 RxJava 存在的意义究竟是什么呢？

举几个常见的例子：

1. 为 View 设置点击回调方法:

   1 2 3 4 5 6

   btn.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { // callback body } });

2. Service 组件绑定操作:

   1 2 3 4 5 6 7 8 9 10 11 12 13

   private ServiceConnection mConnection = new ServiceConnection() { @Override public void onServiceConnected(ComponentName className, IBinder service) { // callback body } @Override public void onServiceDisconnected(ComponentName arg0) { // callback body } }; ... bindService(intent, mConnection, Context.BIND_AUTO_CREATE);

3. 使用 Retrofit 发起网络请求:

   1 2 3 4 5 6 7 8 9 10 11

   Call<List<Photo>> call = service.getAllPhotos(); call.enqueue(new Callback<List<Photo>>() { @Override public void onResponse(Call<List<Photo>> call, Response<List<Photo>> response) { // callback body } @Override public void onFailure(Call<List<Photo>> call, Throwable t) { // callback body } });

在日常开发中我们时时刻刻在面对着类似的回调函数，而且容易看出来，回调函数最本质的功能就是把异步调用的结果返回给我们，剩下的都是大同小异。所以我们能不能不要去记忆各种各样的回调函数，只使用一种回调呢？如果我们定义统一的回调如下：

1
2
3

public class Callback<T> {
    public void onResult(T result);
}

那么以上 3 种情况，对应的回调变成了：

1. 为 View 设置点击事件对应的回调为 Callback<View>
2. Service 组件绑定操作对应的回调为 Callback<Pair<CompnentName, IBinder>> (onServiceConnected)、 Callback<CompnentName> (onServiceDisconnected)
3. 使用 Retrofit 发起网络请求对应的回调为 Callback<List<Photo>> (onResponse)、 Callback<Throwable> (onFailure)

只要按照这种思路，我们可以把所有的异步回调封装成 Callback<T> 的形式，我们不再需要去记忆不同的回调，只需要和一种回调交互就可以了。

写到这里，你应该已经明白了，RxJava 存在首先最基本的意义就是 统一了所有异步任务的回调接口 。而这个接口就是 Observable<T>，这和刚刚的 Callback<T> 其实是一个意思。此外，我们可以考虑让这个回调更通用一点 —— 可以被回调多次，对应的，Observable 表示的就是一个事件流，它可以发射一系列的事件（onNext），包括一个终止信号（onComplete）。

如果 RxJava 单单只是统一了回调的话，其实还并没有什么了不起的。统一回调这件事情，除了满足强迫症以外，额外的收益有限，而且需要改造已有代码，短期来看属于负收益。但是 Observable 属于 RxJava 的基础设施，有了 Observable 以后的 RxJava 才刚刚插上了想象力的翅膀。

（未完待续）

本文属于 “RxJava 沉思录” 系列，欢迎阅读本系列的其他分享：

• RxJava 沉思录（一）：你认为 RxJava 真的好用吗？
• RxJava 沉思录（二）：空间维度
• RxJava 沉思录（三）：时间维度
• RxJava 沉思录（四）：总结

如果您对我的技术分享感兴趣，欢迎关注我的个人公众号：麻瓜日记，不定期更新原创技术分享，谢谢！:)

回顾

在上一篇分享中，我根据自己在公司项目中的实践，列举了七点流程框架应该解决的问题。同时也记录了在选型过程中调研和尝试的若干种方案，它们的优点与不足，以及最后为什么放弃的原因，这些方案分别是：

• 简单的基于 startActivityForResult/onActivityResult
• 基于 EventBus 或者其他基于事件总线的方案
• 简单的基于 FLAG_ACTIVITY_CLEAR_TOP 或者设置 launchMode 为 singleTop / singleTask
• 开辟新的 Activity 任务栈

上一篇分享中提出的最后一个方案 – 使用 Fragment 框架封装流程，是我相对而言比较满意的方案，它并不是完美的方案，至少它没有全部解决我自己提出的对流程框架的七个问题，但是从现阶段来看，在复杂程度，易用性和可靠性上，这种方案已经足够满足我们日常开发所需，在我发现更好的方案之前，我认为还是值得介绍一下的:)

简单回顾一下，这种方案就是一个 Activity 对应一个流程，这个 Activity 就是这个流程对外暴露的接口，具体暴露的接口是 startActivityForResult 和 onActivityResult, 任何触发流程的位置，都只通过这两个方法，和代表流程的 Activity 进行交互。

流程的每一个步骤（页面），被封装为一个个 Fragment, Fragment 只和宿主 Activity 交互，通常就是把本步骤的数据传递给宿主 Activity 以及通知宿主 Activity 本步骤已做完。宿主 Activity 即流程 Activity。

流程 Activity 除了担当本流程对外接口任务以外，还要承担流程内部步骤间的流转，其实就是对代表步骤的 Fragment 的添加与移除。

以登录流程为例（包含两个步骤：用户名密码验证、需要手机验证码的两步验证）, 整个流程与流程触发点（例如首页信息流点赞操作）的交互以及流程内部 Fragment 栈如下图所示：

而流程宿主 Activity 与代表流程的每个具体步骤的 Fragment 的交互可以用下图来表示：

如何优化流程与外部交互接口

上一篇分享中，最后有提到基于 startActivityForResult 和 onActivityResult 两个方法来发起流程和接收流程结果是 不优雅 的，而且这种写法也不利于流程在其他位置被复用。例如登录操作在点赞时可能被触发，在评论时也可能被触发，常规写法只会让 Activity / Fragment 过于臃肿。

我们希望的结果是，发起流程可以被封装为一个普通的异步操作，然后我们就可以像对待普通的异步任务那样，为这个流程指派一个观察者来监听异步结果。但是封装的难点在于我们并不容易在 startActivityForResult 的位置获取一个对象，这个对象可以在 onActivityResult 的时候获得回调，根源在于 onActivityResult 并不属于 Activity / Fragment 的生命周期函数，所以无论是 Google 官方的 Lifecycle Component 还是第三方的 RxLifecycle 都不包含这个回调。

但是我们还是有机会通过别的办法在 startActivityForResult 的位置拿到 onActivityResult 这个回调的观察者。其中一种方案就是借鉴 Glide 的思想，Glide 可以为异步操作绑定 Activity 的生命周期，它的原理就是为发起请求的 Activity 添加一个 不可见的 Fragment，大家知道，Fragment 也可以发起 startActivityForResult 操作，并通过 onActivityResult 接受结果。

到这里，我们的思路就清晰了。我们的 Activity 自己不需要发起 startActivityForResult，而是新建一个不可见的 Fragemnt ，然后把这个任务交给它，Fragment 就相当于一个观察者， Activity 持有这个 Fragment 对象，Fragment 可以在自己收到 onActivityResult 的时候把结果通知 Activity。

这种做法有两个好处：首先，

1. 如果我们自己创建一个观察者，那么通常会被放在全局作用空间。那么就需要仔细考虑对象生命周期绑定问题，以防止可能造成的内存泄漏。Fragment 属于 Android 框架的一部分，只要正常使用（例如不要错误使用 static 引用，谨慎使用匿名内部类），就不会造成内存泄漏。

2. 自己创建的观察者对象，在 进程被杀死重新创建 或者 后台Activity被回收 的情况下，可能无法正常恢复，一方面可能导致无法接收到 onActivityResult 的结果，另一方面有可能导致应用 Crash（通常是因为空指针）。而如果我们把观察者的任务交给 Fragment，由于 Fragment 被 Activity 的 FragmentManager 管理，即使 Activity 由于系统的原因被销毁重新创建了，还是可以保证观察者自身被正确恢复，并且正常收到 onActivityResult 回调。

使用 RxJava 进行封装

上一小节提到，我们希望可以像对待一个普通的异步任务一样，对待业务流程。对于像我们这样的已经在项目中引入 RxJava 的团队来说，使用 RxJava 封装自然是首选。

首先，onActivityResult 这个回调中回传给我们的 3 个参数，我们单独封装为一个类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ActivityResult {

    private int requestCode;
    private int resultCode;
    private Intent data;

    public ActivityResult(int requestCode, int resultCode, Intent data) {
        this.requestCode = requestCode;
        this.resultCode = resultCode;
        this.data = data;
    }

    // getters & setters
}

本文在第一节的时候提到：流程 有时候是由于某些条件不满足而触发 的，举一个简单的例子：社交 App 的点赞操作需要登录态才可以进行，那么处理点赞事件的代码很有可能是这样的：

1
2
3
4
5
6
7
8

likeBtn.setOnClickListener(v -> {
    if (LoginInfo.isLogin()) {
        doLike();
    } else {
        startLoginProcess()
            .subscribe(this::doLike);
    }
})

上面的代码中，我们假设 startLoginProcess 为一个封装好的登录流程，它的返回类型为 Observable<ActivityResult>。像这样的条件检测并且发起流程的类似代码很多，一个异步任务，把原本逻辑上流畅的一个代码流程给拆成两部分。为了可以让这部分更优雅，我们其实可以把 LoginInfo.isLogin() 为 true 这种情况也视为 startLoginProcess 这个 Observable 所发射的数据。到目前为止 ActivityResult 这个对象我们已经单独封装好了，我们可以自行实例化这个对象，无需依赖 onActivityResult 回调来构造这个对象：

1
2
3
4
5
6
7

public Observable<ActivityResult> loginState() {
    if (LoginInfo.isLogin()) {
        return Observable.just(new ActivityResult(REQUEST_CODE_LOGIN, RESULT_OK, new Intent()));
    } else {
        return startLoginProcess();
    }
}

这样一来，检测用户是否登录，在 用户已经登录 和 用户一开始没登录但是通过登录流程以后登录成功 的情况下，执行点赞操作的代码就变成了下面这样：

1
2
3
4

likeBtn.setOnClickListener(v -> {
    loginState()
        .subscribe(this::doLike);
})

虽然整体上代码量并没有变少，但是逻辑上更加清晰了，loginState 这个方法也更容易被其他地方所复用了。

接下来的部分是 承担着 onActivityResult 这个方法的观察者 的责任的 Fragment，根据刚刚的讨论结果，这个 Fragment 需要提供一个方法，允许除了在它自己得到 onActivityResult 回调时实例化一个 ActivityResult 这种情况以外，也可以手动插入一个 ActivityResult 对象，这样的封装可以在应对 条件检测 - 发起流程 这类情景时，对外部有更加简洁和一致的接口。具体代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

public class ActivityResultFragment extends Fragment {

    private final BehaviorSubject<ActivityResult> mActivityResultSubject = BehaviorSubject.create();

    @Override
    public void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);
        mActivityResultSubject.onNext(new ActivityResult(requestCode, resultCode, data));
    }

    public static Observable<ActivityResult> getActivityResultObservable(Activity activity) {
        FragmentManager fragmentManager = activity.getFragmentManager();
        ActivityResultFragment fragment = (ActivityResultFragment) fragmentManager.findFragmentByTag(
                ActivityResultFragment.class.getCanonicalName());
        if (fragment == null) {
            fragment = new ActivityResultFragment();
            fragmentManager.beginTransaction()
                    .add(fragment, ActivityResultFragment.class.getCanonicalName())
                    .commit();
            fragmentManager.executePendingTransactions();
        }
        return fragment.mActivityResultSubject;
    }

    public static void startActivityForResult(Activity activity, Intent intent, int requestCode) {
        FragmentManager fragmentManager = activity.getFragmentManager();
        ActivityResultFragment fragment = (ActivityResultFragment) fragmentManager.findFragmentByTag(
                ActivityResultFragment.class.getCanonicalName());
        if (fragment == null) {
            fragment = new ActivityResultFragment();
            fragmentManager.beginTransaction()
                    .add(fragment, ActivityResultFragment.class.getCanonicalName())
                    .commit();
            fragmentManager.executePendingTransactions();
        }
        fragment.startActivityForResult(intent, requestCode);
    }

    public static void insertActivityResult(Activity activity, ActivityResult activityResult) {
        FragmentManager fragmentManager = activity.getFragmentManager();
        ActivityResultFragment fragment= (ActivityResultFragment) fragmentManager.findFragmentByTag(
                ActivityResultFragment.class.getCanonicalName());
        if (fragment == null) {
            fragment = new ActivityResultFragment();
            fragmentManager.beginTransaction()
                    .add(fragment, ActivityResultFragment.class.getCanonicalName())
                    .commit();
            fragmentManager.executePendingTransactions();
        }
        fragment.mActivityResultSubject.onNext(activityResult);
    }
}

在 ActivityResultFragment 这个类中：

1. mActivityResultSubject 即为发射 ActivityResult 的 Observable ；

2. getActivityResultObservable 这个方法是用于在 Activity 中获取不可见 Fragment 对应的 Observable<ActivityResult>，借鉴了 Glide 的思想；

3. onActivityResult 这个方法里，Fragment 把自己接收到的数据封装为 ActivityResult 传递给 mActivityResultSubject；

4. startActivityForResult 这个方法是用来被 Activity 调用的，Activity 把本来应该由自己发起的 startActivityForResult 交给由这个 Fragment 来发起；

5. insertActivityResult 这个方法的作用前面解释过了，是为了给调用流程的调用者，提供一致的接口，主要优化 条件检测 - 发起流程 这种情景。

可复用流程的封装

到目前为止，基于 RxJava，需要封装流程所需的基础设施已经准备完毕。我们来尝试封装一个流程，以登录流程为例，按上一篇讨论的结果，登录流程可能包含多个页面（用户名、密码验证，手机验证码两步验证等），也可能有子流程（忘记密码），但是对于“登录”这个流程，它对外只暴露一个代表它这个流程的 Activity，无论它内部跳转多么复杂，外部与这个登录流程交互也非常简单，只需要通过 startActivityForResult 和 onActivityResult 这两个方法。而这两个方法在上一节已经可以被很方便的封装，我们以登录流程为例，假设登录流程只对外暴露 LoginActivity 这一个 Activity，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class LoginActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        // your other code

        loginBtn.setOnClickListener(v -> {
            // 简单起见，略去请求部分，直接登录成功
            this.setResult(RESULT_OK);
            finish();
        });
    }

    public static Observable<ActivityResult> loginState(Activity activity) {
        if (LoginInfo.isLogin()) {
            ActivityResultFragment.insertActivityResult(
                activity,
                new ActivityResult(REQUEST_CODE_LOGIN, RESULT_OK, new Intent())
            );
        } else {
            Intent intent = new Intent(activity, LoginActivity.class);
            ActivityResultFragment.startActivityForResult(activity, intent, REQUEST_CODE_LOGIN);
        }
        return ActivityResultFragment.getActivityResultObservable(activity)
            .filter(ar -> ar.getRequestCode() == REQUEST_CODE_LOGIN)
            .filter(ar -> ar.getResultCode() == RESULT_OK);
    }
}

这个 Activity 对外提供一个静态的 loginState 方法，返回类型为 Observable<ActivityResult>，在已经登录的情况下，Observable 会立即发送一个 ActivityResult 表示登录成功，在非登录态下, 会唤起登录流程，如果登录流程最后的结果是登录成功，Observable 也会发送一个 ActivityResult 表示登录成功，所以凡是使用到这个登录流程的地方，对这个登录流程的调用，应该如下代码所示(仍然以点赞操作为例)：

1
2
3
4

likeBtn.setOnClickListener(v -> {
    LoginActivity.loginState(this)
        .subscribe(this::doLike);
})

原先需要书写复杂的 startActivityForResult 和 onActivityResult 两个方法，才能完成和登录流程交互，而且还需要在发起流程前先确认是否当前已经是登录态，现在只需要一行 LoginActivity.loginState(), 然后指定一个 Observer 即可达到一样的效果，更重要的是，写法变简单了以后，整个登录流程变得非常容易复用，任何需要检查登录态然后再做操作的地方，都只需要这一行代码即可完成登录态检测，实现了 流程的高度可复用。

这种写法可以在流程完成以后，继续之前的操作（例如本例中点赞），不需要用户重新进行一遍先前被流程所打断的操作（例如本例中的点赞操作）。但是细心的你可能并不这么认为，因为上面的代码本质上是有问题的，问题在于在上面 LoginActivity.loginState() 的调用在 likeBtn.setOnClickListener 的内部回调，那么考虑极端情况，如果登录流程被唤起，而发起登录流程的 Activity 不幸被系统回收，那么当登录流程做完回到的发起登录流程的 Activity 将会是系统重新创建的 Activity，这个全新的 Activity 是没有执行过 likeBtn.setOnClickListener 的内部回调的任何代码的，所以 .subscribe() 方法指定的观察者不会受到任何回调，this::doLike 不会被执行。

为了可以让封装的流程兼容这种情况，可以采用这种方案：修改 loginState 方法，使其返回 ObservableTransformer, 我们重命名 loginState 方法为 ensureLogin:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public static ObservableTransformer<T, ActivityResult> ensureLogin(Activity activity) {
    return upstream -> {
        Observable<ActivityResult> loginOkResult = ActivityResultFragment.getActivityResultObservable(activity)
            .filter(ar -> ar.getRequestCode() == REQUEST_CODE_LOGIN)
            .filter(ar -> ar.getResultCode() == RESULT_OK);

        upstream.subscribe(t -> {
            if (LoginInfo.isLogin()) {
                ActivityResultFragment.insertActivityResult(
                    activity,
                    new ActivityResult(REQUEST_CODE_LOGIN, RESULT_OK, new Intent())
                );
            } else {
                Intent intent = new Intent(activity, LoginActivity.class);
                ActivityResultFragment.startActivityForResult(activity, intent, REQUEST_CODE_LOGIN);
            }
        }

        return loginOkResult;
    }
}

如果您之前没有接触过 ObservableTransformer, 这里做一个简单介绍，它通常和 compose 操作符一起使用，用来把一个 Observable 进行加工、修饰，甚至替换为另一个 Observable。

登录流程的封装，现在对外体现为 ensureLogin 这一个方法，那么其它代码如何调用这个登录流程呢，还是以点赞操作为例，现在的代码应该是这样：

1
2
3

RxView.clicks(likeBtn)
    .compose(LoginActivity.ensureLogin(this))
    .subscribe(this::doLike);

这里的 RxView.clicks 使用了 RxBinding 这个开源库，用于把 View 的事件，转化为 Observable，当然其实你也可以自己封装。改完这种写法以后，刚刚提到的极端情况下也可以正常工作了，即使发起流程的页面在流程被唤起后被系统回收，在流程完成以后回到发起页，发起页被重新创建了，发起页的 Observer 依然可以正常收到流程结果，之前被中端的操作得以继续执行。

现在我们可以稍微总结一下，根据上一篇和本篇提出建议，如何封装一个业务流程：

1. 一个业务流程对应一个 Activity，这个 Activity 作为对外的接口以及流程内部步骤的调度者；
2. 一个流程内部的一个步骤对应一个 Fragment，这个 Fragment 只负责完成自己的任务以及把自己的数据反馈给 Activity；
3. 流程对外暴露的接口应该封装为一个 ObservableTransformer，流程发起者应该提供发起流程的 Observable（例如以 RxView.clicks 的形式提供），两者通过 compose 操作符关联起来。

这是我个人实践出的一套封装流程的经验，它并不是完美的方案，但是在可靠性、可复用程度、接口简单程度上已经足以胜任我个人的日常开发，所以才有了这两篇分享。

我们已经封装了一个最简单的流程 – 登录流程，但是实际项目中往往会遇到更严峻的挑战，例如流程组合与流程嵌套。

复杂流程实践：流程组合

举例：某款基金销售 App，在用户点击购买基金时，可能存在如下图流程：

可用从上图中看出，某个未登录用户想要购买一款基金的最长路径包含：登录 - 绑卡 - 风险测评 - 投资者适当性管理 这几个步骤。但是，并不是所有用户都要经历所有这些步骤，例如，如果用户已登录并且已做过风险测评，那这个用户只需要再做 绑卡 - 适当性管理 这两步就可以了。

这样的一个需求，如果用传统的写法来写，可以预见肯定会在 click 事件处理的地方罗列很多 if - else ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// ...
// 设置点击事件处理函数
buyFundBtn.setOnClickListener(v -> handleBuyFund());


// ...
// 处理结果
public void onActivityResult(int requestCode, int resultCode, Intent data) {
    switch (requestCode) {
        case REQUEST_LOGIN:
        case REQUEST_ADD_BANKCARD:
        case REQUEST_RISK_TEST:
        case REQUEST_INVESTMNET_PROMPT:
            if (resultCode == RESULT_OK) handleBuyFund();  
            break;
    }
} 

// ...
 
private void handleBuyFund() {
    // 判断是否已登录
    if (!isLogin()) {
        startLogin();
        return;
    }
    // 判断是否已绑卡
    if (!hasBankcard()) {
        startAddBankcard();
        return;
    }
    // 判断是否已做风险测试
    if (!isRisktestDone()) {
        startRiskTest();
        return;
    }
    // 判断是否需要按照投资者适当性管理规定，给予用户必要提示
    if (investmentPrompt()) {
        startInvestmentPrompt();
        return;
    }

    startBuyFundActivity();
}

上面这种写法一方面代码比较长，另一方面，流程发起和结果处理分散在两处，代码较为不易维护。我们分析一下，整个大的流程是几个小流程的组合，我们可以把上面的图上的流程换一种画法：

按照上文的思想，我们令每个流程对外暴露一个 Activity，并且已经使用 RxJava ObservableTransformer 封装好，那么前面复杂的代码可以简化为：

1
2
3
4
5
6
7
8
9
10
11

RxView.clicks(buyFundBtn)
    // 确保未登录情况下，发起登录流程，已登录情况下自动流转至下一个流程
    .compose(ActivityLogin.ensureLogin(this))
    // 确保未绑卡情况下，发起绑卡流程，已绑卡情况下自动流转至下一个流程
    .compose(ActivityBankcardManage.ensureHavingBankcard(this))
    // 确保未风险测评情况下，发起风险测评流程，已测评情况下自动流转至下一个流程
    .compose(ActivityRiskTest.ensureRiskTestDone(this))
    // 确保需要适当性提示情况下，发起适当性提示，已提示或不需要提示情况下自动流转至下一个流程
    .compose(ActivityInvestmentPrompt.ensureInvestmentPromptOk(this))
    // 所有条件都满足，进入购买基金页
    .subscribe(v -> startBuyFundActivity(this));

通过 RxJava 的良好封装，我们做到了可以用更少的代码来表达更复杂的逻辑。上面的例子中的 4 个被组合的流程，它们有一个共同的特点，就是彼此独立，互相不依赖其它剩余流程的结果，现实中，我们可能会遇到这样的情况: B 流程启动，需要依赖 A 流程完成的结果，为了能满足这种情况，我们只需要对上面的封装稍作修改。

假设绑卡流程需要依赖登录流程完成后的用户信息，那么首先，在登录流程结束调用 setResult 的位置, 传递用户信息：

1
2
3
4
5

this.setResult(
    RESULT_OK, 
    IntentBuilder.newInstance().putExtra("user", user).build()
);
finish();

然后，修改 ensureLogin 方法，使经过 ObservableTransformer 处理后，返回的新的 Observable 由发射 ActivityResult 改为发射 User：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public static ObservableTransformer<T, User> ensureLogin(Activity activity) {
    return upstream -> {
        Observable<ActivityResult> loginOkResult = ActivityResultFragment.getActivityResultObservable(activity)
            .filter(ar -> ar.getRequestCode() == REQUEST_CODE_LOGIN)
            .filter(ar -> ar.getResultCode() == RESULT_OK)
            .map(ar -> (User)ar.getData.getParcelableExtra("user"));

        upstream.subscribe(t -> {
            if (LoginInfo.isLogin()) {
                ActivityResultFragment.insertActivityResult(
                    activity,
                    new ActivityResult(
                        REQUEST_CODE_LOGIN, 
                        RESULT_OK, 
                        IntentBuilder.newInstance().putExtra("user", LoginInfo.getUser()).build()
                    )
                );
            } else {
                Intent intent = new Intent(activity, LoginActivity.class);
                ActivityResultFragment.startActivityForResult(activity, intent, REQUEST_CODE_LOGIN);
            }
        }

        return loginOkResult;
    }
}

与此同时，原来的 ensureHavingBankcard 方法的 ObservableTransformer 方法接受的 Observable 原来是任意类型 T 的，由于我们现在规定，绑卡流程需要依赖登录流程的结果 User ，所以我们把 T 类型，改为 User 类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public static ObservableTransformer<User, ActivityResult> ensureHavingBankcard(Activity activity) {
    return upstream -> {
        Observable<ActivityResult> bankcardOk = ActivityResultFragment.getActivityResultObservable(activity)
            .filter(ar -> ar.getRequestCode() == REQUEST_ADD_BANKCARD)
            .filter(ar -> ar.getResultCode() == RESULT_OK);

        upstream.subscribe(user -> {
            if (getBankcardNum() > 0) {
                ActivityResultFragment.insertActivityResult(
                    activity,
                    new ActivityResult(
                        REQUEST_ADD_BANKCARD, 
                        RESULT_OK, 
                        new Intent()
                    )
                );
            } else {
                Intent intent = new Intent(activity, AddBankcardActivity.class);
                intent.putExtra("user", user);
                ActivityResultFragment.startActivityForResult(activity, intent, REQUEST_ADD_BANKCARD);
            }
        }

        return bankcardOk;
    }
}

这样，这两个流程之间就有了依赖关系，绑卡依赖登录流程返回的结果，但是组合这两个流程的写法还是不会有任何改变：

1
2
3
4

RxView.clicks(someBtn)
    .compose(ActivityLogin.ensureLogin(this))
    .compose(ActivityBankcardManage.ensureHavingBankcard(this))
    .subscribe(v -> doSomething());

除此以外，绑卡流程还是可复用的，它是依赖可以返回 User 的流程的，所以只要是其他可以返回 User 作为结果的流程，都可以与绑卡流程组合。

复杂流程实践：流程嵌套

举例：登录流程中的登录页面，除了可以选择用户名密码登录外，往往还提供其他选项，最典型的就是注册和忘记密码两个功能：

从直觉上，我们肯定是认为注册和忘记密码应该是不属于登录这个流程的，它们是相对独立的两个流程，也就是说在登录这流程内部，嵌入了其它的流程，我把这种情况称之为流程的嵌套。

按照同样的套路，我们应该先把注册、忘记密码这两个流程使用 ObservableTransformer 进行封装，然后我们把上图流程按照本文思想整理一下，如下：

可以看到，现在的区别是，发起流程的地方不再是一个普通的 Activity，而是另一个流程中的某个步骤，按照先前的讨论，流程中的步骤是由 Fragment 承载的。所以这里有两种处理方法，一种是 Fragment 把发起流程的任务交给宿主 Activity，由宿主 Activity 分配给属于它的“看不见的 Fragment” 去发起流程并处理结果，另一种是直接由该 Fragmnet 发起流程，由于 Fragment 也有属于它自己的 ChildFragmentManager，所以只需要对“使用 RxJava 进行封装”这一节中的相关方法做一些修改即可支持由 Fragment 内部发起流程，具体修改内容为把 activity.getFragmentManager() 改为 fragment.getChildFragmentManager() 即可。

在具体应用中，本人使用的是后一种，即 直接由 Fragment 发起流程，因为被嵌套的流程往往和主流程有关联，即嵌套流程的结果有可能改变主流程的流转分支，所以直接由 Fragment 发起流程并处理结果比较方便一点，如果交给宿主 Activity 可能需要额外多写一些代码进行 Activity - Fragment 的通信才能实现相同效果。

首先，在没有嵌套流程的情况下，登录流程的第一个步骤登录步骤（用户名、密码验证），代码应该如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44