进程一般指一个执行单元，在电脑和移动设备上指一个程序或者一个应用。
我们通过系统提供的ContentProvider去查询数据的时候，其实也是一种进程间通信，只不过通信细节被系统内部屏蔽了。
给一个应用开启多进程模式——android:process，除此之外没有其他办法，也就是说我们无法给一个线程或者一个实体类指定其运行时所在的进程。
一个应用默认进程的进程名为包名。
进程名为“:”开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程里，而进程名不以“:”开头的进程属于全局进程，其他应用通过ShareUID方式可以和它跑在一个进程里。
Android系统为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。在这种情况下，他们可以互相访问对方的私有数据，比如data目录、组件信息等，不管它们是否跑在同一个进程里。如果跑在同一个进程里，除了能共享data数据目录，组件信息，还可以共享内存数据，看上去就像同一个应用的两个部分。
ShareUID
android:sharedUserId 即上文中提到的UID和ShareUID是同一个概念。
Android给每个app进程分配一个单独的用户空间,其manifest中的userid就是对应一个Linux用户Shared User id
通过Shared User id,拥有同一个User id的多个app可以配置成运行在同一个进程中.所以默认就是可以互相访问任意数据. 也可以配置成运行成不同的进程, 同时可以访问其他APK的数据目录下的数据库和文件.就像访问本程序的数据一样.
多进程模式的运行机制和需要注意的问题
静态变量不能在多进程间同步。
Android为每个应用分配了一个独立的虚拟机，或者说为每个进程都分配了一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，这就导致了不同的虚拟机中访问同一个类的对象会产生多个副本。
所有运行在不同进程中的四大组件，只要它们之间需要通过内存来共享数据，都会共享失败，这也是多进程带来的主要影响。所以在运用IPC时要考虑共享的是不是内存数据。
一般来说，使用多进程会造成以下几方面的问题
- 静态成员和单例模式完全失败
- 线程同步机制完全失败
- SharedPreferences的可靠性下降。因为SharedPreferences不支持- 两个进程同时执行写操作，否则会有一定几率的数据丢失。
- Application会多次创建。运行在同一个进程中的组件是属于同一个虚拟机和同一个Application的，同理，运行在不同进程里的组件就属于两个不同的虚拟机和Application。
我们可以这么理解同一个应用间的多进程：它就相当于两个不同的应用采用了ShareUID的模式，这样能够更加直接的理解多进程模式的本质。
Serializable和Parcelable
Serializable是Java中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化过程需要大量的I/O操作。
Parcelable是android中的序列化方式，在android平台上，效率很高。
Parcelable主要用在内存序列化上，通过Parcelable将对象序列化到存储设备中或者将对象序列化后通过网络传输也都是可以做到，但是这个过程会稍显复杂，因此在这两种情况下建议大家使用Serializable。
关于Binder
需要额外注意的两点是：首先，当客户端发起远程请求时，由于当前线程会被挂起，直到服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程中发起此远程请求。其次，由于服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式实现，因为它已经运行在一个线程中了。
Messenger是一种轻量级的IPC方案，底层实现是AIDL，由于它一次处理一个请求，因此在服务端，我们不用考虑线程同步的问题，因为服务端不存在并发执行的情形。Messenger是用串行的方式处理客户端发来的请求，如果有大量并发请求，那么使用Messenger就不太合适了。Messenger的作用主要是为了传递消息，很多时候我们可能需要跨进程调用服务端的方法，这种情形用Messenger就无法做到了。但是我们可以用AIDL来实现跨进程的方法调用。
Binder连接池的作用和工作机制
当有多个业务模块都用到AIDL进行跨进程通信时，每个业务模块创建自己的AIDL接口并实现此接口。这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的Binder对象；对于服务端而言，只需要一个Service就可以了，服务端提供一个queryBinder接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了，由此可见，BInder连接池的主要作用就是将每个业务模块的Binder请求统一转发给远程Service中去执行，从而避免了重复创建Service的过程。
AIDL的oneway
oneway可以用来修饰在interface之前，这样会造成interface内所有的方法都隐式地带上oneway；
oneway也可以修饰在interface里的各个方法之前。
被oneway修饰的方法不可以有返回值。
oneway关键字用于修改远程调用的行为
- 本地调用（同步调用）——如果用于本地调用，则不会有任何影响，调用仍然是同步调用
- 远程调用（异步调用）——使用oneway修饰的方法，远程调用时不会阻塞；Client端调用该方法时，只是发送数据并立即返回。接口的实现类最终接收此调用时，是以正常的远程调用形式将其作为常规的binder调用来接收。
oneway主要有两个特性：异步调用和串行化处理。
- 异步调用是指Client端向binder驱动发送调用请求后不需要挂起线程等待binder驱动的回复，而是直接结束。向一些系统服务调用应用进程的时候就会使用oneway，比如AMS调用应用进程启动Activity，这样就算应用进程中做了耗时的任务，也不会阻塞系统服务的运行。
- 串行化处理是指对于一个Server的AIDL接口而言，所有的oneway方法不会同时执行，binder驱动会将它们串行化处理，排队一个一个调用。
binder的相关协议
涉及到的 binder 命令也有规律，由外部发送给 binder 驱动的都是 BC_ 开头，由 binder 驱动发往外部的都是 BR_开头。
waiteventinterruptible方法
Client端调用Server端的非oneway方法时，会造成Client端线程挂起等待远程方法返回，这个等待操作，底层调用的是Linux系统函数waiteventinterruptible()方法。相当于Thread的sleep方法，调用后，线程就不会占用CPU资源。
而用到waiteventinterruptible()方法的地方，还有Handler机制中，Looper的阻塞，其实质是MessageQueue的next()方法中，调用了nativePollOnce()，它的底层实现也调用了waiteventinterruptible()方法。
Binder机制的原理
BInder通信机制采用是的C/S架构，其中包括4个主要的角色：Client、Server、ServiceManager和Binder驱动。其中Client、Server和SerivceManager都是在用户空间，他们都在各自的进程，Binder驱动是属于内核空间。关于内核空间和用户空间，是Linux中的概念，每个Linux(Android)进程默认都对应4G的虚拟地址空间，其中0~1G是内核空间，1G到4G是用户空间，每个进程的用户空间都是相互独立的，内核空间是可共享的。
Binder机制的流程可以这样理解：
- （1）注册服务 Server端注册service对象到ServiceManager，在ServiceManager中生成映射关系表。这个过程中，Server相当于客户端，ServiceManager相当于服务端。
- （2）获取服务 Client向ServiceManager发送请求，获取service对象，而ServiceManager会返回一个service的代理对象给Client。这个过程中，Client相当于客户端，ServiceManager相对于服务端。
-
（3）Client获取到service的代理对象，调用service代理对象的对应方法并获取执行结果，实现Client和Server的跨进程通信。这个过程中，Client就是客户端，Server就是服务端。
Binder机制流程
但是以上三个步骤中的，双方都不是直接交互的，都是通过Binder驱动实现IPC通信的过程。比如步骤（2）中，ServiceManager是通过Binder驱动生成service的代理对象，然后将代理对象转发给Client。而在步骤（3）中，Client调用service代理对象对应方法时，会向Binder驱动发送消息，然后由Binder驱动通知Server端，执行service对象的同名方法，并将执行结果发送给BInder驱动，再将其转发给Client。从Client端的视角来看，就相当于，它直接调用了service对象的方法。
Binder机制实现IPC的优势：
- 性能相比于socket、管道和消息队列要高。因为socket、管道和消息队列都是采用存储-转发方式，即数据先从发送方拷贝到内核缓冲区，再从内核缓冲区拷贝到接收方。需要两次拷贝过程。而Binder机制只需要一次数据拷贝。
- 稳定性 Binder基于C/S架构，架构清晰，职责明确又相对独立。
- 安全性 传统的IPC方法，接收端无法获得发送端的UID/PID，也就无法鉴别发送方的身份。而Android系统中给每个进程都分配了UID，可以当做鉴别进程身份的重要标识。传统的IPC只能由用户将UID填写在数据包里，容易被截获利用。其次，传统的IPC访问接入点是开放的，只要知道接入点，就可以与对端建立连接，这样就容易被恶意程序猜测到接入点而与接收方建立连接。同时，Binder既支持实名Binder又支持匿名BInder，安全性高。
binder机制基于mmap一次拷贝的实现原理
Client端和Server端处于不同的进程有些不同的虚拟地址规则，所以无法直接通信，而一个页框可以映射给多个页，那么就可以将一块物理内存分别与Client和Server的虚拟内存块进行映射，如图所示，Client向Server发消息，只需调用copy_from_user进行一次数据拷贝，Server进程就能读取到数据了，另外映射的虚拟内存块大小将近1M（1M~8K），所以IPC通信的数据量也被限制为这个值。通过Intent向Acivity或者Service等组件传参时，也因为这个映射内存的大小问题，也会影响到Intent传递数据的大小。
通过Intent传递数据的大小具体限制
1.1传512K以下的数据的数据可以正常传递。
1.2传512K~1024K的数据会出错，闪退。
1.3传1024K以上的数据会报错：TransactionTooLargeException。
1.4考虑到Intent还包括要启动的Activity等信息，实际可以传的数据略小于512K
原文链接：https://blog.csdn.net/pingfangx/article/details/52093225
怎么理解页和页框
页框是指一块实际的物理内存，页是指程序的一块内存数据单元，内存数据一定是存储在实际的物理内存上，即页必然对应于一个页框，页数据实际上是存储在页框上的。
页和页框一样大，都是内核对内存的分块单位。一个页框可以映射给多个页，也就是说一块实际的物理存储空间可以映射给多个进程的多个虚拟内存空间，这也是mmap机制依赖的基础规则。
Binder的整体架构
Client通过ServiceManager或者AMS获取到的远程binder实体，一般会用Proxy做一层封装，比如ServiceManagerProxy、AIDL生成的Proxy类。而被封装的远程binder实体是一个BInderProxy。
BpBinder和BinderProxy其实是一个东西，远程binder实体，只不过一个Native层，一个Java层。BpBinder内部持有一个binder句柄值handle。
ProcessState是进程单例，负责启动binder驱动以及mmap；IPCThreadState是线程单例，负责与binder驱动进行具体的命令通信。
由Client端通过Proxy发起远程方法调用，会将数据打包到Parcel中，层层向下调用到BpBinder，在BpBinder中调用IPCThreadState的transact()方法并传入handle句柄值，IPCThreadState再去执行具体的binder命令。
由binder驱动到Server端的大概流程是：Server端通过IPCThreadState接收到Client端的请求后，层层向上，最后回调Stub的onTransact() 方法。
以上不代表所有IPC的流程，比如Service Manager作为Server端时，便没有上层的封装，也没有借助IPCThreadState，而是初始化后通过binder_loop()方法直接和binder驱动通信的。
本文参考：
https://blog.csdn.net/qq_42300133/article/details/103402635
https://blog.csdn.net/zhwadezh/article/details/79301909?depth_1-utm_source=distribute.pc_relevant_right.none-task&utm_source=distribute.pc_relevant_right.none-task
https://mp.weixin.qq.com/s/Mp8A1VreFsuj2USbyHRZjw
https://blog.csdn.net/u011033906/article/details/89316543
https://mp.weixin.qq.com/s/Jc2mrxeMVTJXudoPx5K4-w
https://blog.csdn.net/anlian523/article/details/98476033
https://blog.csdn.net/u010164190/article/details/73292012
