一个aidl通信功能的重构

既然aidl通信，那必然涉及到至少两个module，或者进程

最初的业务简单，只需一个提供服务，一个绑定使用服务。

具体业务场景如下，一个应用A需要及时的得知是否有新订单，这个应用只是个普通的应用

第一，不使用所谓的进程保活黑科技

第二，不使用推送，因为推送有时推送延迟率不可忍受，造成经济损失。

最后采用的方案是轮询，并且将轮询服务放入一个优先级非常高的应用中，我们的自定义桌面。

当桌面是活的时候（毫无疑问，只要机子是开着的，桌面一定是活得），这样的前提保证了轮询服务的一直活着。

这个轮询服务做的事情如下：

在符合一定的条件下（如门店是营业状态，且人为打开了需要轮询的开关），每隔一定的时间（如1min）询问服务器是否有新订单数据。

（注意这里的“询问”，是一个针对具体业务的接口，包括请求uri，参数，返回值的接口！）

如果没有，默默的按照频率继续工作。

如果有，则将返回数据处理，回调给绑定该服务的client。

因此我们可以看出，该服务

1，既做了轮询的事，

2，也做了业务数据请求处理分发的事。

当业务变化导致接口变化的时候，这个功能的aidl文件得变化，而且只能提供单一的服务，因为接口就一个。

重构方案如下：

将该服务作为基础服务，提供轮询

提供一个通用的轮询接口，接受不同的客户端的需求，返回统一的一套与业务无关的数据结构，当需要真正的业务数据时，回调相应的客户端具体处理

这样就将轮询功能从业务中解耦出来。