Binder调用自己进程中的方法时，是否会经过Binder驱动？
不会：通过queryLocalInterface()方法判断，若返回本地接口（如IStudentInterface），则直接调用本地方法，不经过驱动。
示例：在onServiceConnected回调中，若service与调用者同进程，asInterface()返回本地接口，无Binder事务。
- Binder线程、主线程、Client请求线程的区别？
Binder线程：执行Binder服务的载体，负责处理跨进程请求。
主线程：UI线程，处理用户交互和界面更新。
Client请求线程：发起跨进程请求的线程，需注意同步与异步调用的选择。
Binder与Socket都在安卓系统中有使用，请问如何选着？
选择Binder的场景
需要系统权限验证（如调用系统API）
高频小数据量通信（< 1MB）
需要同步返回结果的RPC调用
系统服务集成（必须通过ServiceManager）
需要死亡通知（linkToDeath机制）
选择Socket的场景
持续数据流传输（传感器、音频）
跨设备/网络通信
Input事件传递（系统级事件分发）
实时性要求高但数据量大
总结
Binder——用于精确控制、命令传递、权限管理，适合结构化API调用。
Socket——用于大量数据流传输，适合实时性要求高的连续数据。
为什么Android要自研Binder，而不用Linux已有的进程通信？
传统的IPC方式有很多，比如管道，socket，共享内存，消息队列，信号量等，但为何google就选中了binder作为IPC方式呢？
1.易用binder可以很好的实现c-s架构
android系统提供的各种服务实现都由不同的server提供，当client需要获取某个server的服务时，只需要client向server发送相应的请求，server收到请求后进行处理，再将结果返回给client.但是传统的IPC通信手段中，只有socket支持c-s的通信方式，但是socket主要用于网络间通信和本机进程间的低速通信，传输效率太低。
2.性能优势，binder的传输效率和可操作性好
传统的IPC通信，比如消息队列，管道采用的存储-转发的方式，使用它们进行IPC通信时，需要经过2次内存拷贝，效率太低。而采用binder机制的话，只需要一次内存拷贝即可，而共享内存虽然进行内存拷贝的次数为0，但是共享内存操作复杂，也不适合这种场景。当然，socket也要其适用的场景，比如android系统中的Input系统，而管道也在android looper中发挥着重要作用。
3.安全性，binder的安全性高
传统的IPC机制没有安全措施，完全依赖上层协议来保证。接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份，而binder机制则为每个进程分配了UID/PID来作为鉴别身份的标识，并且在binder通信时会根据UID/PID进行有效性检测，这样就保证了通信的安全性，是其它IPC通信方式所不能及的。
一次拷贝的具体含义
我们看到从client到binder驱动，再到server 端，有大量的copy过程，不论是copy_to_user()，还是copy_from_user()，好像拷贝过程无处不在，那么我们常见的说binder的优势在于一次拷贝，到底优在何处呢？其实这个拷贝说的是一次binder通信过程，即client到binder驱动，再到server端，这是一次binder通信过程，在这个过程中，从client把数据拷贝到binder驱动，是一次拷贝过程，不论这个过程中调用了多少次copy_from_user()，而从binder驱动到server，是一次映射过程，不用拷贝，这就是所谓的一次拷贝。而拷贝的数据，也仅仅是业务所需要的parcel数据，而用于binder驱动交互的一些命令等数据，还是需要拷贝的。
具体流程可以用下图说明：
