Android的IPC(Inter-progress Commitation)通信:
实现跨进程通信的方式:
1.通过Intent来传递数据,在四大组件(4个进程,不过这4个进程可以通过shareUID和签名,整合在同一台虚拟机中,就有了4个进程同属于一个应用,而一个应用又是一个进程的概念,有点绕)
2.共享文件和sharePreferences
3.基于Binder的Messenger和AIDL
4.socket
实现了Serializable接口时,最好写上serialVersionUID,这样即使在类的一些成员变量增加一点或减少一点,还是能最大程度反序列化类,不然没写这个就反序列化不出。
实现Parcelable接口,可以实现序列化并可以通过Intent和Binder传递,系统为我们提供了一些实现了Parcelable接口的类,例如Intent,Bundle,Bitmap等。Parcelable接口主要用在内存序列化上,也可以使用在网络上,不过比较麻烦,非内存序列化(例如网络通信)建议使用Serializable。
Bundle的使用场景:
除了直接传递数据这种典型的使用场景,它还有一种特殊的使用场景。比如A进程正在计算一个计算,计算完后它要启动B进程的一个组件并把计算结果传递给B进程,可是遗憾的是这个计算结果不支持放入Bundle中,因此无法通过Intent来传输,这个时候如果我们用其他IPC方式就会略显复杂。可以考虑如下方式:我们通过Intent启动进程B的一个Service组件(比如IntentService),让Service也运行在B进程中,所以目标组件就可以直接获取计算结果。 这种方式的核心思想:将原本需要在A进程的计算任务转移到B进程的后台Service中去执行,这样就可以成功避免了进程间通信的问题,而且只用了很小代价。
SharePreferences:也是共享文件的一种形式,在多进程和面对高并发量的读/写访问中,sp有很大几率丢失数据。因此不建议在进程间通信中使用sp。
ContentProvider:
ContentProvider是Android中提供的专门用于不同应用间进行数据共享的方式,从这一点看,它天生适合进程间通信。和Messenger一样,ContentProvider的底层实现同样也是Binder. ContentProvider的细节很多,比如CRUD操作,防止SQL注入和权限控制等。
系统预制了许多ContentProvider,比如通讯录信息,日程表信息等,要跨进程访问这些信息,只需要通过ContentResolver的query,update,insert和delete方法即可,
ContentProvider主要以表格的形式来组织数据,并且可以包含多个表,对于每个表格来说,它们都具有行和列的层次性,行往往对应一条记录,而列对应一条记录中的一个字段,这点和数据库很类似。除了表格的形式,ContentProvider还支持文件数据,比如图片,视频等。文件数据和表格数据的结构不同,因此处理这类数据时可以在ContentProvider中返回文件的句柄给外界从而让文件来访问ContentProvider中的文件信息。 Android系统所提供的MediaStore功能就是文件类型的Content