简介

安卓系统默认提供的广播，aidl等机制默认也是可以达到跨进程通信的，为什么此时自己还要自定义一套这样的机制，首先广播这种机制，的确十分方便，但是他的缺点也很明显，那就是时间太常，广播的延时基本上都是上百ms 的，aidl 性能提升的确挺好的，但是于此同时，aidl 操作的繁琐性的弊端，也就出现了，因此我就出现了两种想法去实现各个应用间的通信

一. socket 通信，这种通信也是java 上常见的ipc 通信方式，但是这种方式我实现应用间通信，没多久，就被自己推翻了， socket port code 的管理让自己甚是烦恼，这点也让自己深深体会到了谷歌开发为什么使用mmap这种通信方式，自己竟然抛弃了最简单实现方式，反而走了最艰难的一条道路

二.基于bundle system service 通信机制

系统级别的应用ipc.png

1. 注册一个system service
   这个service 用于全局代理， 用于打理应用之间的通信
   至于system sevice 的注册流程8.0 以上请参考上一篇博客
   https://www.jianshu.com/p/5fe2e6d730b8

2. 建立一个Manager 并对外公共注册用于操作service
   Manage public 注册流程
   https://www.jianshu.com/p/5fe2e6d730b8

3. 建立对应接口，应用实现对应的接口， 并注册对应的bundle 到manager, manager 通过bundle 将该应用bundle 对象注册到service, 这样service就可以通过应用的bundle 对象进行操作，进而实现通知指定应用和通知所有应用的接口

---

华丽的分界线

通过 1，2，3 步骤我们实现应用间的通信，后边我们开始优化这部分
以上三个点实现，只能说我们可以进行应用间ipc通信，但是这个流程需要一些前提支撑

1. 应用需要注册到系统中

2. 进程需要存活
   为了上边两点我做了以下优化

   
   应用注册流程.png

3. sysetmUI 初始化化时， 发送一个广播

4. 没个应用在接受到广播时，启动自己service,在service 中将自己的bundle注册service 中

后续可以根据自己的需求加一些自己操作，例如应用service 崩溃，怎么重新启动， 怎么确保某些信息已经被应用收到的回馈机制建立等等