① android开发中跨进程通信有几种方式
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来请求端口，连通后就可以进行通信。
② 033 Android多进程-共享内存
要使用一块共享内存
还是先看共享内存的使用方法，我主要介绍两个函数：
通过 shmget() 函数申请共享内存,它的入参如下
通过 shmat() 函数将我们申请到的共享内存映射到自己的用户空间，映射成功会返回地址，有了这个地址，我们就可以随意的读写数据了，我们继续看一下这个函数的入参
共享内存的原理是在内存中单独开辟的一段内存空间，这段内存空间其实就是一个tempfs（临时虚拟文件），tempfs是VFS的一种文件系统，挂载在/dev/shm上，前面提到的管道pipefs也是VFS的一种文件系统。
由于共享的内存空间对使用和接收进程来讲，完全无感知，就像是在自己的内存上读写数据一样，所以也是 效率最高 的一种IPC方式。
上面提到的IPC的方式都是 在内核空间中开辟内存来存储数据 ，写数据时，需要将数据从用户空间拷贝到内核空间，读数据时，需要从内核空间拷贝到自己的用户空间，
共享内存就只需要一次拷贝 ，而且共享内存不是在内核开辟空间，所以可以 传输的数据量大 。
但是 共享内存最大的缺点就是没有并发的控制，我们一般通过信号量配合共享内存使用，进行同步和并发的控制 。
共享内存在Android系统中主要的使用场景是 用来传输大数据 ，并且 Android并没有直接使用Linux原生的共享内存方式，而是设计了Ashmem匿名共享内存 。
之前说到有名管道和匿名管道的区别在于有名管道可以在vfs目录树中查看到这个管道的文件，但是匿名管道不行， 所以匿名共享内存同样也是无法在vfs目录中查看到 的， Android之所以要设计匿名共享内存 ，我觉得主要是为了安全性的考虑吧。
我们来看看共享内存的一个使用场景，在Android中，如果我们想要将当前的界面显示出来，需要将当前界面的图元数据传递Surfaceflinger去做图层混合，图层混合之后的数据会直接送入帧缓存，送入帧缓存后，显卡就会直接取出帧缓存里的图元数据显示了。
那么我们如何将应用的Activity的图元数据传递给SurfaceFlinger呢？想要将图像数据这样比较大的数据跨进程传输，靠binder是不行的，所以这儿便用到匿名共享内存。
从谷歌官方提供的架构图可以看到，图元数据是通过BufferQueue传递到SurfaceFlinger去的，当我们想要绘制图像的时候， 需要从BufferQueue中申请一个Buffer，Buffer会调用Gralloc模块来分配共享内存 当作图元缓冲区存放我们的图元数据。
可以看到Android的匿名共享内存是通过 ashmem_create_region() 函数来申请共享内存的，它会在/dev/ashmem下创建一个虚拟文件，Linux原生共享内存是通过shmget()函数，并会在/dev/shm下创建虚拟文件。
匿名共享内存是通过 mmap() 函数将申请到的内存映射到自己的进程空间，而Linux是通过*shmat()函数。
虽然函数不一样，但是Android的匿名共享内存和Linux的共享内存在本质上是大同小异的。
。
③ Android多进程通信之 Binder
在 Linux 中一个进程空间可以分为 用户空间 和 内核空间 ，不同的进程它们的用户空间数据不可共享，但是它们的内核空间的数据可共享，即所有进程共用 1 个内核空间。进程内用户空间和内核空间进行交互需通过系统调用。
Android 系统时基于 Linux 内核的，Linux 已经提供了多种 IPC 方式，如下：
所以，Android 为啥又单独弄出一个 Binder 呢？主要有如下原因：
直观地说，Binder 是 Android 中的一个类，它实现了 IBinder 接口；从 Android Framework 角度来说，Binder 是 ServiceManager 连接各种 Manager(ActivityManager、WindowManager...) 和相应 ManagerService 的桥梁；从 Android 应用层来说，Binder 是客户端和服务端进行通信的媒介，当 bindService 的时候，服务端会返回一个包含了服务端业务调用的 Binder 对象，通过这个 Binder 对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于 AIDL 服务。
Binder 定义了四个角色：Server，Client，ServiceManager 和 Bidner 驱动，其中 Server、Client、ServiceManager 运行于用户空间，Binder 驱动运行于内核空间。
Binder 工作原理：