‘壹’ 安卓IPC跨进程通讯:AIDL+Retrofit——AndLinker的初步使用
需要用到安卓跨进程通讯，IPC (进程间通信) 的时候，AndLinker是一款android上的IPC (进程间通信) 库，结合了 AIDL 和 Retrofit 的诸多特性，且可以与 Rxjava 和 RxJava2 的Call Adapters无缝结合使用。
个人简单理解就是：简化AIDL流程的一个第三方库。使用时需要先了解一下AIDL、retrofit。
以普通Java接口代替AIDL接口
像 Retrofit 一样生成远程服务接口的IPC实现
支持的Call Adapters：Call， RxJava Observable， RxJava2 Observable & Flowable
支持远程服务回调机制
支持AIDL的所有数据类型
支持AIDL的所有数据定向tag：in，out，inout
支持AIDL的oneway关键字
在服务端以及客户端的项目根目录的build.gradle中添加jcenter()仓库
在App的build.gradle中添加如下依赖
AndLinker支持AIDL所有数据类型：
Java语言中的所有原始类型 (如：int，long，char，boolean，等等)
String
CharSequence
Parcelable
List (List中的所有元素必须是此列表中支持的数据类型)
Map (Map中的所有元素必须是此列表中支持的数据类型)
接口里的方法就是按需求需创建。这里只举几个简单的示例。
‘贰’ Carson带你学Android：全面剖析Binder跨进程通信原理
从而全方位地介绍 Binder ，希望你们会喜欢。
在本文的讲解中，按照 大角度 -> 小角度 去分析 Binder ，即：
从而全方位地介绍 Binder ，希望你们会喜欢。
在讲解 Binder 前，我们先了解一些 Linux 的基础知识
具体请看文章： 操作系统：图文详解 内存映射
Binder 跨进程通信机制 模型 基于 Client - Server 模式
此处重点讲解 Binder 驱动作用中的跨进程通信的原理：
原因：
所以，原理图可表示为以下：
所以，在进行跨进程通信时，开发者只需自定义 Client & Server 进程 并 显式使用上述3个步骤，最终借助 Android 的基本架构功能就可完成进程间通信
注册服务后， Binder 驱动持有 Server 进程创建的 Binder 实体
此时， Client 进程与 Server 进程已经建立了连接
Client 进程 根据获取到的 Service 信息（ Binder 代理对象），通过 Binder 驱动 建立与 该 Service 所在 Server 进程通信的链路，并开始使用服务
步骤1： Client 进程 将参数（整数a和b）发送到 Server 进程
步骤2： Server 进程根据 Client 进要求 调用 目标方法（即加法函数）
步骤3： Server 进程 将目标方法的结果（即加法后的结果）返回给 Client 进程
对比 Linux （ Android 基于 Linux ）上的其他进程通信方式（管道、消息队列、共享内存、
信号量、 Socket ）， Binder 机制的优点有：
特别地，对于从模型结构组成的Binder驱动来说：
不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。
‘叁’ 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 使用Messenger实现跨进程之间通信
以前讲到跨进程通信，我们总是第一时间想到AIDL(Android接口定义语言)，实际上，使用Messenger在很多情况下是比使用AIDL简单得多的。
大家看到Messenger可能会很轻易的联想到Message，然后很自然的进一步联想到Handler——没错，Messenger的核心其实就是Message以及Handler来进行线程间的通信。
以下是如何使用Messenger的步骤:
综上六步就能完成客户端与Service的跨进程双向通信过程:
客户端 -> Service -> 客户端
简单的例子（客户端向服务器端发送消息，服务器接收）：
服务端主要是返给客户端一个IBinder实例，以供服务端构造Messenger，并且处理客户端发送过来的Message。当然，不要忘了要在Manifests文件里面注册.
客户端就主要是发起与服务端的绑定，以及通过onServiceConnected()方法来过去服务端返回来的IBinder，借此构造Messenger，从而可以通过发送Message的方式与服务端进行交互。
服务器接收消息后回复消息给客户端
客户端修改：
客户端需要添加一个handler用于接收消息
服务端修改：
在服务端的handler获取客户端发送的msg.replyTo
‘伍’ 利用Messenger跨进程通信
Android笔记多进程通信之利用Messenger跨进程通信，
提起跨进程通信，大多数人首先会想到AIDL，AIDL，中文名称是android接口描述语言，是android系统中用于进行跨进程通信必须了解的。其实messenger和AIDL作用一样，都可以进行进程间通讯。它是基于消息的进程间通信，通过构建Message来在客户端和服务端之间传递数据，就像Handler发送消息在子线程和UI线程发送消息那样，还不用去写AIDL文件。
Messenger翻译为信使，可以在不同进程中传递Message对象，在Message中放入我们需要传递的信息，然后通过Messenger将Message传递给对方，就可以轻轻松松实现跨进程数据传递。实际上Messenger是一种轻量级的IPC（跨进程通信）方式，它的底层仍然是实现的AIDL。
此外，还支持记录客户端对象的Messenger，然后可以实现一对多的通信；甚至作为一个转接处，任意两个进程都能通过服务端进行通信。
相同点：
1.都与IPC的调用有关；
2.Messenger 是一种轻量级的 IPC方案，底层实现了AIDL，只是进行了封装，开发的时候不用写.aidl文件。
3.都支持实时通信；
不同点：
1. Messenger一次只能处理一个请求（串行）/AIDL一次可以处理多个请求（并行）；
当您需要执行 IPC 时，为您的接口使用 Messenger 要比使用 AIDL 实现更加简单，因为 Messenger 会将所有服务调用排入队列，而纯粹的 AIDL 接口会同时向服务发送多个请求，服务随后必须应对多线程处理。
对于大多数应用，服务不需要执行多线程处理，因此使用 Messenger 可让服务一次处理一个调用。如果您的服务必须执行多线程处理，则应使用 AIDL 来定义接口。
2. Messenger不支持RPC，只能通过message传递消息/AIDL支持RPC；
3. Messenger使用简单，轻量级，不需要创建AIDL文件/AIDL使用复杂，需要创建AIDL文件；
服务端：
1.创建一个handler对象，并实现hanlemessage方法，用于接收来自客户端的消息，并作处理
2.创建一个messenger，封装handler
3.用messenger的getBinder()方法获取一个IBinder对象，通过onBind返回给客户端
客户端：
1.在activity中绑定服务
2.创建ServiceConnection并在其中使用 IBinder 将 Messenger实例化
3.使用Messenger向服务端发送消息，或需要服务器端返回消息，需要创建一个messenger，封装handler，并将这个messenger传递给服务器端。在handler中接收服务器消息。这样就实现了客户端和服务端的双向通信了。
4.解绑服务
5.服务端中在 handleMessage() 方法中接收每个 Message
创建一个service
注册service，当然要设置在不同的进程
注意：Service在声明时必须对外开放，即android:exported="true"
客户端是通过绑定服务端返回的binder来创建Messenger对象，并通过这个Messenger对象来向服务端发送消息。
总结
Message中的Bundle支持多种数据类型，replyTo字段用于传输Messager对象，以便进程间相互通信
Messager以串行的方式处理客户端发来的消息，不适合有大量并发的请求
Messager方法只能传递消息，不能跨进程调用方法
‘陆’ 了解Android进程间通信的四种方式
由于应用程序之间不能共享内存。在不同应用程序之间交互数据（跨进程通讯），在android
SDK中提供了4种用于跨进程通讯的方式。这4种方式正好对应于android系统中4种应用程序组
件：Activity、Content Provider、Broadcast和Service。其中Activity可以跨进程调用其他应
用程序的Activity；Content Provider可以跨进程访问其他应用程序中的数据（以Cursor对象形
式返回），当然，也可以对其他应用程序的数据进行增、删、改操 作；Broadcast可以向
android系统中所有应用程序发送广播，而需要跨进程通讯的应用程序可以监听这些广播；
Service和Content Provider类似，也可以访问其他应用程序中的数据，但不同的是，Content
Provider返回的是Cursor对象，而Service返回的是Java对象，这种可以跨进程通讯的服务叫
AIDL服务。
‘柒’ Android IPC机制
IPC是指两个进程之间进行数据交互的过程，即：跨进程通信。
进程是一个执行单，在移动设备上指一个程序或者一个应用。一个进程可以有多个线程，也可以只有一个线程，即主线程。在Android里边，主线程也叫作UI线程，要是在主线程执行大量耗时任务，就会造成界面无法响应，ANR问题，解决这类问题，把耗时操作放在子线程就好。
在Android中，最有特色的进程间通信就是Binder，Binder轻松的实现了进程间的通信。
给四大组件 Activity、Service、Receiver、ContentProvider 在AndroidMenifeist中指定 android:process 属性，可以指定其运行的进程。
: 开头的线程是当前应用的私有进程，其它应用不可以和它跑在同一个进程中，而不以 : 开头的属于全局进程，其他应用通过ShareUID方式可以和它跑在一个进程中。
Android为了每一个应用（进程）都分配了独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间。
多进程会造成如下几个反面方面的问题：
为了解决这些问题，系统提供了跨进程通信方法，虽然不能直接共享内存，但是可以实现数据共享。Intent来传递数据，共享文件，基于Binder的Messenger，ContentProvider，AIDL和Socket。
当我们需要通过Intent和Binder传输数据，或者我们需要把对象持久化到存储设备上，再或者通过网络传输给其它客户端时，Serializable和Parcelable接口可以完成对象的序列化过程。
Serialzable是java提供的序列化接口，是一个空接口，为对象同序列化和反序列化操作。
想让一个类对象实现序列化，只需要这个类实现Serialzable接口，并声明一个serialVersionUID即可，serialVersionUID可以声明成1L或者IDE根据当前类接口自动生成它的hash值。
没有serialVersionUID不影响序列化，但是可能会影响反序列化。序列化时，系统当前类的serialVersionUID写入序列化文件中，当反序列化时，回去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果不一致，无法完成反序列化。
Seriallizable用起来简单但是开销大，序列化和反序列过程需要大量的I/O操作，而Parcelable是Android序列化方式，更适合Android平台，效率更高。Parcelable主要用于内存序列化上，而Seriallizable更适用于序列化到本地存储设备，或者将对象序列化后通过网络传输到别的客户端。
Activity、Service、Receiver都支持在 Intent中传递Bundle数据，Bundle实现了Pareclable接口,所以它可以方便地在不同进程间传输。
Android基于Linux，使得其并发读写文件可以没有限制的进行，两个进程可以通过读写一个文件来交换数据。共享数据对文件格式没有要求，双反约定就行。使用文件共享很有可能出问题。
SharedPreferences是个特例，虽然也是属于文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对他的读写变得不可靠，高并发的时候，很大可能会丢失数据。
Messenger可以在不同的进程中传递Message对象，在Message中存入我们需要传递的数据，就可以实现数据的跨进程传递。它是一种轻量级的IPC方案，底层实现是AIDL。
Messenger对AIDL做了封装，使得我们可以更便捷的实现跨进程通信，它一次只处理一个请求，在服务端不用考虑线程同步问题，在服务端不存在并发执行的情形。实现一个Messenger有如下几个步骤：
在服务端创建一个Service，同时创建一个Handler，并通过它来创建一个Messenger对象，然后再Service的onBind中返回这个Messenger对象底层Binder即可。
绑定服务端Service，绑定成功后用服务端返回的IBinder对象创建一个Messenger。通过这个对象就可以向服务端发消息了。如果需要服务端回应客户端，就需要和服务端一样，创建一个Handler，并通过它来创建一个Messenger对象，然后把这个Messenger对象通过Message的replyTo参数传给服务端，服务端可以通过这个replyTo参数回应客户端。
首先要创建一个Service用来监听客户端的连接请求，然后创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明，最后在Service中实现AIDL接口即可。
绑定服务端的Service，将服务端返回的Binder对象转成AIDL接口所属的类型，接着就可可以范文AIDL里边的方法了。
在AIDL文件中，并不是所有的额数据类型都是可以使用的。
以上6种数据就是AIDL所支持的所有类型，其中自定义的Parecelable对象和AIDL对象必须显示的import，不管是否和当前的AIDL文件位于同一个包。
AIDL文件中用到了自定义的Parcelable对象，必须新建一个同名的AIDL文件，在其中声明它为parcelable类型。
AIDL中除了基础数据类型，其它类型参数都需要标上方向：in、out、inout，in是输入型参数，out是输出型参数，inout是输入输出型参数。
上面是远程服务端示例，AIDL方法在服务端的Binder线程池中执行，因此各个客户端同时连接的时候，会存在多个线程同时访问的情形，所以要在AIDL中处理线程同步，这个CopyOnWriteArrayList支持并发的读写。
AIDL所支持的是一个抽象的List，只是一个接口，因此虽然服务端返回的是CopyOnWriteArrayList，当时Binder会按照List规范去范文数据并最终形成一个ArrayList传递给客户端。
ServiceConnection 的回调方法在UI线程中运行，服务端的方法有可能很久才能执行完毕，需要考虑ANR的问题。
服务的方法本省就运行再Binder线程池中，本身可以执行大量耗时操作，不要去服务端方法中开县城去进行异步任务。
客户端
服务端
RemoteCallbackList是系统提供专门用于删除跨进程listener的，它的内部有一个Map结构，用来保存所有的AIDL回调，这个Map的key就是Binder类型，value是CallBack类型。
客户端解注册的时候，我们只需要遍历服务端所有的listener，找出那个和接注册listener具有相同的Binder对象的服务端listener并把它删除即可。
RemoteCallbackList的beginBroadcast和finishBroadcast必须配对使用。
ContentProvider是Android专门提供不同应用间进行数据共享的方式。底层实现一样是Binder。
系统预置了许多ContentProvider，比如通讯录，日程信息表，只需要通过ContentResolver的query、update、insert、delete方法即可。
‘捌’ Android进程间和线程间通信方式
进程：是具有一定独立功能的程序关于某个数据集合上的一次运行活动，进程是系统进行资源分配和调度的一个独立单位。
线程：是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位。线程自己基本上不拥有系统资源,只拥有一些在运行中必不可少的资源(如程序计数器,一组寄存器和栈)，但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。
区别：
（1）、一个程序至少有一个进程，一个进程至少有一个线程；
（2）、线程的划分尺度小于进程，使得多线程程序的并发性高；
（3）、进程在执行过程中拥有独立的内存单元，而多个线程共享内存，但线程之间没有单独的地址空间，一个线程死掉就等于整个进程死掉。
---------------------
一、Android进程间通信方式
1.Bundle
由于Activity，Service，Receiver都是可以通过Intent来携带Bundle传输数据的，所以我们可以在一个进程中通过Intent将携带数据的Bundle发送到另一个进程的组件。
缺点：无法传输Bundle不支持的数据类型。
2.ContentProvider
ContentProvider是Android四大组件之一，以表格的方式来储存数据，提供给外界，即Content Provider可以跨进程访问其他应用程序中的数据。用法是继承ContentProvider，实现onCreate,query,update,insert,delete和getType方法，onCreate是负责创建时做一些初始化的工作，增删查改的方法就是对数据的查询和修改，getType是返回一个String，表示Uri请求的类型。注册完后就可以使用ContentResolver去请求指定的Uri。
3.文件
两个进程可以到同一个文件去交换数据，我们不仅可以保存文本文件，还可以将对象持久化到文件，从另一个文件恢复。要注意的是，当并发读/写时可能会出现并发的问题。
4.Broadcast
Broadcast可以向android系统中所有应用程序发送广播，而需要跨进程通讯的应用程序可以监听这些广播。
5.AIDL方式
Service和Content Provider类似，也可以访问其他应用程序中的数据，Content Provider返回的是Cursor对象，而Service返回的是Java对象，这种可以跨进程通讯的服务叫AIDL服务。
AIDL通过定义服务端暴露的接口，以提供给客户端来调用，AIDL使服务器可以并行处理，而Messenger封装了AIDL之后只能串行运行，所以Messenger一般用作消息传递。
6.Messenger
Messenger是基于AIDL实现的，服务端（被动方）提供一个Service来处理客户端（主动方）连接，维护一个Handler来创建Messenger，在onBind时返回Messenger的binder。
双方用Messenger来发送数据，用Handler来处理数据。Messenger处理数据依靠Handler，所以是串行的，也就是说，Handler接到多个message时，就要排队依次处理。
7.Socket
Socket方法是通过网络来进行数据交换，注意的是要在子线程请求，不然会堵塞主线程。客户端和服务端建立连接之后即可不断传输数据，比较适合实时的数据传输
二、Android线程间通信方式
一般说线程间通信主要是指主线程（也叫UI线程）和子线程之间的通信，主要有以下两种方式：
1.AsyncTask机制
AsyncTask，异步任务，也就是说在UI线程运行的时候，可以在后台的执行一些异步的操作；AsyncTask可以很容易且正确地使用UI线程，AsyncTask允许进行后台操作，并在不显示使用工作线程或Handler机制的情况下，将结果反馈给UI线程。但是AsyncTask只能用于短时间的操作（最多几秒就应该结束的操作），如果需要长时间运行在后台，就不适合使用AsyncTask了，只能去使用Java提供的其他API来实现。
2.Handler机制
Handler，继承自Object类，用来发送和处理Message对象或Runnable对象；Handler在创建时会与当前所在的线程的Looper对象相关联(如果当前线程的Looper为空或不存在，则会抛出异常，此时需要在线程中主动调用Looper.prepare()来创建一个Looper对象)。使用Handler的主要作用就是在后面的过程中发送和处理Message对象和让其他的线程完成某一个动作（如在工作线程中通过Handler对象发送一个Message对象，让UI线程进行UI的更新，然后UI线程就会在MessageQueue中得到这个Message对象（取出Message对象是由其相关联的Looper对象完成的），并作出相应的响应）。
三、Android两个子线程之间通信
面试的过程中，有些面试官可能会问Android子线程之间的通信方式，由于绝大部分程序员主要关注的是Android主线程和子线程之间的通信，所以这个问题很容易让人懵逼。
主线程和子线程之间的通信可以通过主线程中的handler把子线程中的message发给主线程中的looper，或者，主线程中的handler通过post向looper中发送一个runnable。但looper默认存在于main线程中，子线程中没有Looper，该怎么办呢？其实原理很简单，把looper绑定到子线程中，并且创建一个handler。在另一个线程中通过这个handler发送消息，就可以实现子线程之间的通信了。
子线程创建handler的两种方式：
方式一：给子线程创建Looper对象：
new Thread(new Runnable() {
public void run() {
Looper.prepare(); // 给这个Thread创建Looper对象，一个Thead只有一个Looper对象
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
Looper.loop(); // 不断遍历MessageQueue中是否有消息
};
}).start();
---------------------
方式二：获取主线程的looper，或者说是UI线程的looper：
new Thread(new Runnable() {
public void run() {
Handler handler = new Handler(Looper.getMainLooper()){ // 区别在这！！！
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
};
}).start();
---------------------
‘玖’ Android ParcelFileDescriptor实现进程间通信
一个通信通道，实现跨进程的的Socket网络通信。
具体的通信通道的图如下。
android进程间通信是使用Binder来传数据，而Binder传输的数据，有一个最为基本的要求，就是要实现Parcelable接口。
ParcelFileDescriptor是android提供的一个数据结构。
ParcelFileDescriptor是可以用于进程间Binder通信的FileDescriptor。支持stream 写入和stream 读出
我们可以使用
来将PacecelFileDescriptor 与File对应起来，以实现进程间的文件共享。
我们也可以使用
来建立一个pipe通信通道，ParcelFileDescriptor数组第一个元素是read端，第二个元素是write端，通过write端的AutoCloseOutputStream和read端的AutoCloseInputStream，我们就可以实现进程见的数据流传输了。
发送端：
1. 业务层调用getOutputStream向通信层发起请求
2. 通信层通过creatPipe 建立一个ParcelFileDescriptor数组，并将write端的pipe[1]返回给业务层
3. 业务层得到pipe[1]（ParcelFileDescriptor）后，可以通过AutoCloseOutputStream写入数据
4. 从通信层的pipe[0]的AutoCloseInputStream中读出数据通过socket发送出去
接收端：
1. 业务层调用getInputStream向通信层发起请求
2. 通信层通过creatPipe 建立一个ParcelFileDescriptor数组，并将read端的pipe[0]返回给业务层
3. 业务层得到pipe 0 后，可以通过AutoCloseInputStream读取数据。（如没有数据，则阻塞，一直等到有数据为止）
4. socket中读取数据，写入到通信层的pipe[1]的AutoCloseOutputStream。（pipe[1]一旦写入，第三步中pipe[2]就可以读取出数据）