Android进程间通讯的几种方式

定义多进程

Android应用中使用多进程只有一个办法（用NDK的fork来作除外），就是在AndroidManifest.xml中声明组件时，用android:process属性来指定。

不知定process属性，则默认运行在主进程中，主进程名字为包名。

android:process = package:remote，将运行在package:remote进程中，属于全局进程，其余具备相同shareUID与签名的APP能够跑在这个进程中。

android:process = :remote ，将运行在默认包名:remote进程中，并且是APP的私有进程，不容许其余APP的组件来访问。

多进程引起的问题

静态成员和单例失效：每一个进程保持各自的静态成员和单例，相互独立。

线程同步机制失效：每一个进程有本身的线程锁。

SharedPreferences可靠性降低：不支持并发写，会出现脏数据。

Application屡次建立：不一样进程跑在不一样虚拟机，每一个虚拟机启动会建立本身的Application，自定义Application时生命周期会混乱。

综上，不一样进程拥有各自独立的虚拟机，Application，内存空间，由此引起一系列问题。

 进程间通讯

Bundle/Intent传递数据：

可传递基本类型，String，实现了Serializable或Parcellable接口的数据结构。Serializable是Java的序列化方法，Parcellable是Android的序列化方法，前者代码量少（仅一句），但I/O开销较大，通常用于输出到磁盘或网卡；后者实现代码多，效率高，通常用户内存间序列化和反序列化传输。

文件共享：

对同一个文件前后写读，从而实现传输，Linux机制下，能够对文件并发写，因此要注意同步。顺便一提，Windows下不支持并发读或写。

Messenger：

Messenger是基于AIDL实现的，服务端（被动方）提供一个Service来处理客户端（主动方）链接，维护一个Handler来建立Messenger，在onBind时返回Messenger的binder。

双方用Messenger来发送数据，用Handler来处理数据。Messenger处理数据依靠Handler，因此是串行的，也就是说，Handler接到多个message时，就要排队依次处理。

AIDL：

AIDL经过定义服务端暴露的接口，以提供给客户端来调用，AIDL使服务器能够并行处理，而Messenger封装了AIDL以后只能串行运行，因此Messenger通常用做消息传递。

经过编写aidl文件来设计想要暴露的接口，编译后会自动生成响应的java文件，服务器将接口的具体实现写在Stub中，用iBinder对象传递给客户端，客户端bindService的时候，用asInterface的形式将iBinder还原成接口，再调用其中的方法。

ContentProvider：

系统四大组件之一，底层也是Binder实现，主要用来为其余APP提供数据，能够说天生就是为进程通讯而生的。本身实现一个ContentProvider须要实现6个方法，其中onCreate是主线程中回调的，其余方法是运行在Binder之中的。自定义的ContentProvider注册时要提供authorities属性，应用须要访问的时候将属性包装成Uri.parse("content://authorities")。还能够设置permission，readPermission，writePermission来设置权限。 ContentProvider有query，delete，insert等方法，看起来貌似是一个数据库管理类，但其实能够用文件，内存数据等等一切来充当数据源，query返回的是一个Cursor，能够自定义继承AbstractCursor的类来实现。

Socket：

学过计算机网络的对Socket不陌生，因此不须要详细讲述。只须要注意，Android不容许在主线程中请求网络，并且请求网络必需要注意声明相应的permission。而后，在服务器中定义ServerSocket来监听端口，客户端使用Socket来请求端口，连通后就能够进行通讯。