Android binder连接中，服务端如何知道客户端断开情况

在IPC 利用 binder连接过程中，客户端断连，服务端如何知道呢？

这里的客户端和服务端都运行在不同的进程。

一般来说，我们使用Android的binder，都直接用aidl帮我们生成java代码，再利用service进行ServiceConnection连接。

也许你会说，利用ServiceConnection的onServiceDisconnected()就可以知道断开连接了。

可是回想一下，onServiceDisconnected()是回调到Client端，也就是说，Client端可以知道自己跟Server断开的情况，但是Server端却永远都不知道什么时候跟Client端断开。

回忆一下，我们知道，binder有一个方法，可以传入一个死亡代理，即binder.linkToDeath(IBinder.DeathRecipient)。

这样做的好处就是当对应的跟服务端连接的binder断开的时候，就可以收到DeathRecipient的binderDied()方法回调了。

在《Android艺术开发探索》里，作者把DeathRecipient使用在了ServiceConnection收到对应的service的binder上面，这样达到的效果跟ServiceConnection的onServiceDisconnected()一样，就是Client知道binder断开了，然后Server端依然还是不知道，下面是举例代码：

//在ServiceConnection中抽出的代码
override fun onServiceConnected(name: ComponentName?, binder: IBinder?) {
   
   
    mProxy = RemoteService.Stub.asInterface(binder)
    binder?.linkToDeath(object: IBinder.DeathRecipient {
   
    //加上死亡代理
        override fun binderDied() {
   
   
            Log.e(TAG, "remote Server is died") // binder已经died了
        }
    }, 0)
}

虽然上面都是客户端知道binder断开的情况，但是可以推出，只要服务端拿到客户端的任意一个binder，也就可以通过binder.linkToDeath(IBinder.DeathRecipient)，让服务端知道binder断开的情况了。

这样引申的问题就是：服务端怎么拿到客户端的binder？

服务端怎么拿到客户端的binder

很显然，我们可以通过Service的onBind(Intent intent)方法，把客户端的binder放在intent中传给Service就好了。

哈哈，这样就错了。

不同的客户端连接同一个Service，onBind() 会触发多少次？

答案是一次。不同的进程的Activity对同一个Service进行bindService()返回IBinder，根据直觉肯定是都会调用Service的onBind()方法，事实上并不是这样的。

因为，在对应的Service进程的ActivityManagerService的ActivityServices中，所以当有外部需要的时候直接返回binder，不需要每次都调用Service的onBind()方法。

可以见 《Android中bindService的细节之三：多次调用bindService()，为什么onBind()只执行一次？》

Service对应的onBind只会走一次，那么之后如果调用bindService()之后，其实走的都是onRebind()方法，前提是onUnbind()的返回为tru