包含ipcandroid的词条

为什么 Android 要采用 Binder 作为 IPC 机制

1）从性能的角度

数据拷贝次数：Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder性能仅次于共享内存。

（2）从稳定性的角度

Binder是基于C/S架构的，简单解释下C/S架构，是指客户端(Client)和服务端(Server)组成的架构，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。

仅仅从以上两点，各有优劣，还不足以支撑google去采用binder的IPC机制，那么更重要的原因是：

（3）从安全的角度

传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机的安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。

Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。Android 6.0，也称为Android M，在6.0之前的系统是在App第一次安装时，会将整个App所涉及的所有权限一次询问，只要留意看会发现很多App根本用不上通信录和短信，但在这一次性权限权限时会包含进去，让用户拒绝不得，因为拒绝后App无法正常使用，而一旦授权后，应用便可以胡作非为。

针对这个问题，google在Android M做了调整，不再是安装时一并询问所有权限，而是在App运行过程中，需要哪个权限再弹框询问用户是否给相应的权限，对权限做了更细地控制，让用户有了更多的可控性，但同时也带来了另一个用户诟病的地方，那也就是权限询问的弹框的次数大幅度增多。对于Android M平台上，有些App开发者可能会写出让手机异常频繁弹框的App，企图直到用户授权为止，这对用户来说是不能忍的，用户最后吐槽的可不光是App，还有Android系统以及手机厂商，有些用户可能就跳果粉了，这还需要广大Android开发者以及手机厂商共同努力，共同打造安全与体验俱佳的Android手机。

Android中权限控制策略有SELinux等多方面手段，下面列举从Binder的一个角度的权限控制：

Android源码的Binder权限是如何控制？ -Gityuan的回答

传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。

说到这，可能有人要反驳，Android就算用了Binder架构，而现如今Android手机的各种流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗？没错，确实存在，但这不能说Binder的安全性不好，因为Android系统仍然是掌握主控权，可以控制这类App的流氓行为，只是对于该采用何种策略来控制，在这方面android的确存在很多有待进步的空间，这也是google以及各大手机厂商一直努力改善的地方之一。在Android 6.0，google对于app的权限问题作为较多的努力，大大收紧的应用权限；另外，在Google举办的Android Bootcamp 2016大会中，google也表示在Android 7.0 （也叫Android N）的权限隐私方面会进一步加强加固，比如SELinux，Memory safe language(还在research中)等等，在今年的5月18日至5月20日，google将推出Android N。

（4）从语言层面的角度

大家多知道Linux是基于C语言(面向过程的语言)，而Android是基于Java语言(面向对象的语句)，而对于Binder恰恰也符合面向对象的思想，将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。从语言层面，Binder更适合基于面向对象语言的Android系统，对于Linux系统可能会有点“水土不服”。

另外，Binder是为Android这类系统而生，而并非Linux社区没有想到Binder IPC机制的存在，对于Linux社区的广大开发人员，我还是表示深深佩服，让世界有了如此精湛而美妙的开源系统。也并非Linux现有的IPC机制不够好，相反地，经过这么多优秀工程师的不断打磨，依然非常优秀，每种Linux的IPC机制都有存在的价值，同时在Android系统中也依然采用了大量Linux现有的IPC机制，根据每类IPC的原理特性，因时制宜，不同场景特性往往会采用其下最适宜的。比如在Android OS中的Zygote进程的IPC采用的是Socket（套接字）机制，Android中的Kill Process采用的signal（信号）机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互。

(5) 从公司战略的角度

总所周知，Linux内核是开源的系统，所开放源代码许可协议GPL保护，该协议具有“病毒式感染”的能力，怎么理解这句话呢？受GPL保护的Linux Kernel是运行在内核空间，对于上层的任何类库、服务、应用等运行在用户空间，一旦进行SysCall（系统调用），调用到底层Kernel，那么也必须遵循GPL协议。

而Android 之父 Andy Rubin对于GPL显然是不能接受的，为此，Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议（允许基于Android的开发商不向社区反馈源码），同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证授权方法，有效隔断了GPL的传染性，仍有较大争议，但至少目前缓解Android，让GPL止步于内核空间，这是Google在GPL Linux下 开源与商业化共存的一个成功典范。

相关问答

Q1: Android中IPC的几种方式详细分析与优缺点分

Android是基于linux内核的。所以linux支持的IPC，android都用到了。比如命名管道，共享内存。 除此外，android还使用了一套自己独特的IPC方式 binder. 主要用于2个进程间的远程调用。但是这里就牵扯远程调用如何传递参数，如何回传结果。 这需要调用者对数据进行打包和解包，是一个繁琐的过程。为此，android引入了aidl(android interface description launguage). 开发人员定义好aidl，android会根据aidl的描述生产stub代码，帮助调用者对数据打包，解包。开发人员所要做的事是继承stub代码，实现stub代码中的函数。这些函数是你在aidl中定义的。

Q2: 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方法即可。

Q3: Android的IPC机制

IPC是内部进程通信的简称， 是共享”命名管道”的资源。Android中的IPC机制是为了让Activity和Service之间可以随时的进行交互，故在Android中该机制，只适用于Activity和Service之间的通信，类似于远程方法调用，类似于C/S模式的访问。通过定义AIDL接口文件来定义IPC接口。Servier端实现IPC接口，Client端调用IPC接口本地代理。