优雅的Activity通信方式

 

概述

android对Activity的设计采用了严格的代码隔离，两个Activity之间不经过特殊的处理很难直接进行通信（保存静态变量），坏处呢，当然就是提高了交互成本，使得开发和阅读都会变得困难。好处的话是，代码边界有效的屏蔽了代码影响的扩散，保证了整个APP的稳定性。事实上，多进程Activity交互，也都是基于充分代码隔离的基础上，设计出来的。

 

 

 

传统交互方式

 

 

 

代码示例

 

 

 

说明

 

这种交互方式，有三个问题：

 

• 通过code码来区分请求，不仅不利于阅读，后期维护也困难
• 参数的定义分散，对于使用者来说需要阅读代码才知道需要传哪些参数，哪些是必须的，哪些是非必须的。（一般情况下会维护一个页面接口文档，但这样无疑增加了使用者的学习成本）。
• 代码逻辑分散，请求和响应是分开来的，这样交互方式使得我们很难设计出高内聚的方法，因为一个功能，无论如何都需要分开成两个方法来做。

 

 

 

优雅方案

 

 

类比网络请求

采用类比的方法，我们常用的另一个请求响应模型就是“网络请求”。随便看下常见的网络库volley的使用方式：

 

这样的交互方式，逻辑是内聚的，对于网络请求需要的参数，可以封装在方法参数中，并添加注释的方法进行解释说明。

 

 

 

Activity实现

 

 

 

对外暴露方法的定义完成了，看起来比之前简洁了很多，而且更有利于代码的跟踪和阅读。但是我们知道，Activity之间只可以传递基本数据、和可序列化的对象，OnResultCallBack不能传递过去。不过好在可以使用putBinder来实现：

 

 

putBinder：为了跨进程通信提供的binder方法，在非多进程情况下会使用原始对象

 

 

大概解释下，这个是aidl生成的binder通信代码，如果binder在该进程下，则返回原始对象。如果不在同一进程下则返回代理对象。因为putBinder接受的是IBinder接口了对象，所以我们需要对我们的CallBack接口进行改造，如下：

 

 

 

如果直接实现IBinder接口的话，对于使用者需要实现一堆不需要的方法，所以现在将接口改造成抽象类。另外，上面代码只适用于同进程通信的情况，如果想同时支持跨进程通信，可以将代码改造成下面这样：

 

首页将接口定义成AIDL方式，对于接受参数的方式也需要更改：

 

 

这种方式即支持跨进程、也支持同进程通信的方式。