在小7写的上一篇文章《android IPC通信机制梳理》里,我讲到了如果activity要想和一个跨进程的Service进行通信就需要通过Binder框架,获取到IBinder对象,并调用transact()方法来达到通信的目的。该方法里的第一个参数是整数型的code,表示的是请求的服务类型,比如说我想请求使用某播放器服务,我就需要制定一个规则:当code为1时表示开始播放,当code为2时表示停止播放,当code为3时表示下一首歌曲。。。这中方法有几个问题:
这个规则需要Activity和Service这对交互的双方共同知晓,也就是说,Service必须很清楚code的每个值代表对方要求哪个操作,这种形式非常不直观,也容易出错。
这种方法在需要请求的操作数量较少的时候还可以忍受。可是如果数量非常多的时候,维护起来可就有点蛋疼了,而且在Service端实现自己的Binder对象方法里面不可避免需要写大量的if else块说着是switch case块,非常的不简洁又很难维护。
除了维护code不方便外,假如通信的时候需要一些额外的参数的话,Activity需要用一个Parcel对象把需要的参数依次写进去,再把该Parcel对象作为transact()方法的另一个参数传给Service。当Service这边的Binder对象得到该参数后,也必须按照之前写进去的次序依次读出来。看到了这么多不人性的交互方式,还能忍吗?所以找到一个更加人性化更加优雅的方法进行通信势在必行。
这个时候我们可以想一个办法,在Activity和IBinder对象之间找到这么一个中介,它要做的就是明白我们人类都懂的人性化接口比如:
interface IDoor{ <