的程度上鼓励我们和其他进程协作,通过协作的进程来完成一个复杂的任务,而不是把什么功能都做到一个大而全的程序里面。不过上文还有一些细节没有提到,例如如果一个intent有多个可匹配的处理组件,系统如何处理?这就要分响应消息的组件类型来说了,如果是service,那么这些service都可以启动并处理消息,如果是Activity,则android会弹出一个对话框让用户进行选择。比如我们安装了多个可以处理在线视频的软件,当我们在浏览器中点击一个在线视频的链接时,系统会让用户选择使用哪个软件来观看。另外大家一定会想到安全性的问题,如果不同进程间的组件可以通过隐式消息互相通信,那我们的程序不是可以轻易调用到其他的程序或者系统中的一些敏感程序的组件,这样会不会很不安全呢?其实Android在安全方面有一个统一,完备和轻便的安全策略模型,Intent的安全自然是被考虑在内的,关于android的安全模型我会在后续的系列blog中专门说明。 最后,除了Intent这种基于消息的进程内和进程间通信模型外,android中也有一种相比起来稍显笨重一些的IPC机制,它采用类似远程方法调用的方案,通过接口定义文件AIDL来定义一个IPC接口,然后通过接收方实现接口,调用方调用接口的本地代理实现来完成IPC。这种模型只适用于Activity和Service间的通信,之所以需要这种稍显重量的模式,是因为Activity除了发送intent去启动一个service外,可能还需要能够在Service的运行过程中连接到service,对Service发送一些控制请求。例如音乐播放程序,其后台的播放服务往往独立运行,以方便我们在使用其他程序界面时也能听到音乐。同时这个后台播放服务也会定义一个控制接口,包含比如播放,暂停,快进之类的方法,任何时候播放程序的界面都可以通过使用bindService API连接到播放服务,获取这个接口的包含IPC细节的实现代理,通过这组控制接口方法对其进行控制,这时这种IPC的方案就显的更方便更直观一些了。有关使用AIDL这种IPC的更详细描述, google的官方文档="">已做了详细的讲解。