1 Binder简介
出于安全及系统稳定性考虑，Android不允许应用程序间直接访问，只能通过socket、管道、共享内存等方式间接来通信。进程间Binder通信机制是Android特有的，其本质也是通过驱动层去实现进程间的共享内存来实现的。
进程间的访问不是指简单的函数调用，比如SystemUI源文件里面完全可以import锁屏的包名，然后调用锁屏工程目录里面的接口，这样的方式并不是这两个进程间的通信，而只是单纯在编译期间完成SystemUI功能的编写，实质还是在SystemUI一个程序里面运行。进行间的通信是指两个运行的进程进行资源的互相访问，这样，在进程A中才能实时访问到进程B中的数据（这些数据是可以随着进程B的运用实时进行动态刷新的）。要完成这样的操作，可以在进程B中专门为A->B的通信开辟一个子线程，来进行接口的调用。因为，在一个进程中，多个子线程是可以共享数据资源的。实质上，Binder通信就是这样做的。每一次客户端向服务端的binder通信请求，都会在服务端进程中为这次请求开辟一个binder子线程。而系统设定了，每个服务端进程中同时运行的binder子线程最多为16个。当异常情况下，binder调用异常，导致binder子线程无法结束，而同时出现大量binder调用，超过16个时，则会导致该服务进程直接卡顿ANR。如果出现这中情况的服务进程是系统进程system_server，则会导致整个系统卡顿甚至手机重启，出现各种应用模块的ANR。由于ActivityManagerService/PowerManagerService/PackageManagerService等系统服务都运行在system_server进程中，而应用层app会频繁调用到这些服务，所以system_server进程中出现16个binder被占满的现象比较普遍出现。分析稳定性问题时可以从这方面进行分析。
2Binder表现形式
2.1 Binder两种实现方式
其实服务端就是一个binder对象，有两种实现方式：
2.1.1通过AIDL实现
以状态栏管理服务为例，服务端一般都是如下形式：
StatusBarManagerService extends IStatusBarService.Stub{