什么是Binder？
作为远程对象的基类，通过 IBinder 被定义为一个轻量级远程过程调用机制（RPC）的核心部分。这个类一个是 IBinder 的实现类，提供了这种对象的标准的本地实现。
绝大部分开发者不是直接实现这个类，而是为了描述所需接口使用 aidl 工具，使用它生成合适的 Binder 子类。然而你也可以继承 Binder 类实现自定义 RPC，或者作为能够在进程间共享的媒介使用简单实例化的原生 Binder 对象。
这个类只是一个原始 IPC 的基础；它没有影响一个应用的生命周期，只要进程在运行时创建了 Binder，它就有效。为了正确的使用它，你必须在高级的让系统知道你的进程应该保持运行的应该组件（Service，Activity 或 ContentProvider）的上下文中工作。
你必须关注你的进程可能消失的情况，这种情况下，需要你在进程再次开始的时候，重新创建和连接 Binder。例如：如果你在一个 Activity 中使用 Binder，在 Activity 没有显示的时候，你的 Activity 进程可能随时被杀死；如果Activity是之后重新创建的，你需要创建一个新的 Binder，并且把它放回所在的位置；你需要注意，你的进程可能是通过其他原因（比如接受广播）启动，这种情况下，需要重新创建Activity，并且新建一个新的 Binder 对象。
简单描述下它的工作过程和使用场景
Binder 通信采用C/S架构，从组建角度来说，包含Client，Server，ServiceManager以及 binder 驱动，其中 ServiceManager 用于管理系统中的各种服务。架构图如下所示：
可以看出无论是注册服务和获取服务的过程都需要 ServiceManager，需要注意的是此处的 ServiceMananger 是指 Native 层的 ServiceManager（C++），并非指 framework 层的 ServiceMananger（Java）。ServiceManager 是整个 Binder 通信机制的大管家，是 Android 进程间通信机制 Binder 的守护进程。当Service Manager启动之后，Client 端和 Server 端通信时都需要先回去 Service Manager 接口，才能开始通信服务。
图中 Client/Server/ServiceManager 之间的相互通信都是基于 Binder 机制。既然基于 Binder 机制通信，那么同样也是 C/S 架构，则图中的 3 大步骤都是有相应的 Client 端与 server 端。
- 注册服务（addService）：Server 进程要先注册 Service 到 ServiceManager。该过程：Server 是客户端，ServiceManager 是服务器。
- 获取服务（getService）：Client 进程使用某个 Service 前，须先向 ServiceManager 中获取相应的 Server。该过程：Client 是客户端，ServiceManager 是服务器。
- 使用服务器：Client 根据得到的 Service 信息建立与 Service 所在的 Server 进程通信的道路，然后就可以直接与 Service 交互。改过程 client 是客户端，server 是服务器。
图中的 Client，Server，ServiceManger 之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过 Binder 驱动进行交互的，从而实现 IPC 通信方式。其中 Binder 驱动位于内核空间，Client，Server，ServiceManager 位于用户空间。Binder 驱动和 ServiceManager 可以看做是 Android 平台的基础架构，而 Client 和 Server 是 Android 的应用层，开发人员只需要自定义实现 Client、Server 端，借助 Android 的基本平台架构便可以直接进行 IPC 通信。
应用场景一般为有一个独立运行的Service端，从客户端（一个独立进程）访问Service端（另一个独立进程），例如可以在后台运行的音乐播放Service，以及音乐播放控制界面(客户端）。
