所有客户端解绑后跨进程Android绑定服务未销毁的原因及解决方法

• 最容易引发误判的核心：服务组件的销毁调度，和服务所在进程的回收调度，是两个完全独立的系统逻辑
  同进程场景下你观察到“解绑后B被正常销毁”，本质是B服务的绑定引用计数清零后，服务实例从AMS的服务注册表中移除；因为A、B本来就共享应用的主进程，主进程本身就会被系统长期保留，你根本不会对这个进程的存在产生感知。
  等你给B配上android:process独立跑起来之后，一旦这个独立进程被创建，哪怕B服务本身已经满足“没有绑定客户端、没有走onStartCommand启动流程”的销毁条件，系统也会优先把这个进程加到空缓存池里留着——这是Android默认的性能优化手段，目的是下次启动B服务的时候，不用重复走fork进程、初始化运行环境的流程，加快启动速度。这种情况下你在进程列表看到B的独立进程还活着，根本不代表B服务本身还在运行，只要服务的onDestroy回调正常走了，就说明它完全符合官方绑定服务的生命周期规则，根本不是异常。
• 如果确认B服务的onDestroy压根没被回调，那才是真的异常，根源基本都是AMS侧维护的B服务绑定引用计数没清零——这个问题在跨进程场景下特别容易出现
  同进程的绑定计数是本地内存里的直接增减，几乎不会出错；但跨进程绑定的计数要经过Binder IPC和AMS全局同步，很容易出现计数匹配不上的问题：
  • 调用bindService的时候用了一个临时的ServiceConnection实例，后面解绑的时候又new了一个新的实例传进去，AMS根本匹配不到对应的绑定关系，计数一直卡在没扣减的状态
  • 应用里的单例、全局静态缓存无意中持有了B服务返回的IBinder代理，这个代理是强引用类型，系统会把它判定为有效绑定关系，让AMS一直以为还有客户端在使用B服务

• 先把认知校准了，别把系统的进程缓存当服务未销毁：在B服务的onDestroy里打个日志，等所有客户端都解绑完，看看这个方法有没有正常回调。只要回调走了，就说明服务已经符合规则完成销毁了，独立进程被系统临时缓存的行为完全不需要额外处理，等系统内存不够的时候自然会把它回收掉。
• 如果确认onDestroy确实没触发，优先排查绑定计数不匹配的问题：
  • 核对所有绑定、解绑的代码，确保调用bindService传入的ServiceConnection，和对应unbindService用的是同一个实例，绝对不能出现绑定和解绑用不同连接对象的情况
  • 顺着B服务返回的IBinder对象的引用链排查，看看是不是有全局缓存、单例无意义地持有了这个代理引用，导致绑定计数一直降不下来
• 如果业务上要求所有客户端解绑完，必须立刻销毁B服务，不想等系统的缓存调度，可以在B服务的onUnbind回调里主动调stopSelf()：当服务没被start过、绑定客户端数为0的时候，这个方法会直接触发服务的销毁流程，不管服务跑在哪个进程，都不会被系统的进程缓存逻辑拖住。

内容的提问来源于stack exchange，提问作者mango