退出应用时调用stopService的位置及Activity切换时保活Service的方案

问题根源是Android 绑定服务（Bound Service） 的默认生命周期规则：当所有绑定的客户端都调用unbindService()后，系统会立即销毁服务。你在每个Activity的onResume()绑定、onPause()解绑的逻辑下，两个Activity切换时，旧Activity先触发onPause()执行解绑，此时服务没有活跃绑定的客户端，就会被销毁，新ActivityonResume()执行绑定时就会触发服务重新创建。

问题1：使用startService()保活时，stopService()的合适放置位置 #

startService()启动的服务生命周期独立于绑定逻辑，只有主动调用stopSelf()或者stopService()才会被销毁，推荐的调用位置有两种：

• 若应用有明确的退出入口（比如首页按返回键弹窗确认退出），直接在确认退出的逻辑中调用stopService()，调用前要先完成当前活跃Activity的解绑操作，避免抛出泄露异常
• 若没有明确的退出入口，可在全局Application类的onTrimMemory()回调中判断，当回调等级level == TRIM_MEMORY_UI_HIDDEN时（即应用所有UI页面都退到后台），如果业务允许后台不需要保留服务，就可以在此处调用stopService()
• 禁止在单个Activity的onDestroy()中调用stopService()，会出现单页面销毁但还有其他前端页面运行时，误杀服务的问题

问题2：无需依赖startService()的保活方案 #

有三种成熟的替代方案可选：

• 调整绑定解绑的生命周期时机：把每个Activity的绑定解绑逻辑从onResume()/onPause()，改成在onCreate()/onDestroy()中执行。Activity切换时旧页面要等新页面完全创建完成后才会执行onDestroy()，全程始终有至少一个Activity保持和服务的绑定，服务就不会被销毁，注意要做好异常销毁场景下的解绑兜底，避免泄露报错
• 单例持有Binder引用：自定义Binder类时用静态单例存储已经初始化的Binder实例，首次绑定成功后就把实例存入静态字段，后续Activity绑定时如果已经存在实例直接复用，不会触发服务重新创建，所有页面退出后要手动清空静态引用，避免内存泄露
• 使用前台服务：如果服务属于用户可感知的后台运行场景（比如音乐播放、导航），可以直接使用前台服务，优先级远高于普通绑定服务，不会因为绑定全部解绑就被系统回收，注意要按规则展示前台通知，符合Android后台权限要求

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