写给 Android 应用工程师的 Binder 原理剖析 - 知乎
二、binder leakbinder leak就是binder内存泄漏，用于binder通信的buffer大概有4M左右（据同事描述，还没拷证具体数值），在binder通信中如果传输中使用的parcel没有有效release，会造成buffer空间越来越少，然后积累到一定程度，就会出现binder传输的消息在另外一端无法接收。
在进程使用binder driver的时候，最大在kernel空间中开启的虚拟内存空间是4M。一般如果使用IPCThread的API去操作binder的时候是会自动往driver发送FREE_BUFFER的指令做释放操作，所以一般很难出现Binder leak的现象。除非是自己对binder去做IOctl。
三、binder线程耗尽binder线程到达上限。这个的情景就是app向service发起请求的频率过高，service端如果对所有的业务执行都加了锁的话，则会导致service端用于接收处理binder事件的线程全部卡住，当线程池（default 16个线程）耗尽之后，就无法再处理请求。如果这个时候app的主线程如果再调用该serivce提供的方法，就很容易出现anr。
为解决这种线程池耗尽的问题，应该从app端去限制请求的频率，设定一定的时间间隔才能保证功能正常。
binder线程池被占满系统对每个process最多分配15个binder线程，这个是谷歌的设计（/frameworks/native/libs/binder/ProcessState.cpp)如果另一个process发送太多重复binder请求，那么就会导致接收端binder线程被占满，从而处理不了其它的binder请求
这时候请求端发起的请求就会阻塞等待了(未设置异步请求的前提下)，这本身就是系统的一个限制，如果应用未按照系统的要求来实现对应逻辑，那么就会造成问题。而系统端是不会（也不建议）通过修改系统行为来兼容应用逻辑，否则更容易造成其它根据系统需求正常编写的应用反而出现不可预料的问题。
判断Binder是否用完，可以在trace中搜索关键字"binder_f"，如果搜索到则表示已经用完，然后就要找log其他地方看是谁一直在消耗binder或者是有死锁发生
anr解决常见问题：https://juejin.cn/post/6844903903868223502
四、如何监听Binder服务终止1、binder死亡代理
作用：我们都知道，在和service进行交互时，service返回一个Binder对象。Binder是工作在service端，如果，由于某种原因，服务端出现故障而死亡，那么该返回的Binder对象也将消失，这时，如果我们在客户端在使用Binder对象进行某些函数调用将会出现错误。为了避免该情况的发生，我们可以为Binder对象设置死亡代理。当出现和服务端连接发生故障时，系统将自动调用死亡代理函数binderDied（）。
2、在onServiceDisconnected中重连远程服务。
五、其他面试题听说你Binder机制学的不错，来面试下这几个问题（一） - 简书
