Android系统是否会终止已启动服务并调用Service.onDestroy？

是否需要在onDestroy()中中断或关闭线程池 #

完全有必要，没什么可纠结的。

• 这是组件生命周期对应的基本资源回收逻辑：线程池是服务持有的重量级资源，本身就该放在服务销毁的统一出口做回收，不要把回收逻辑散落在各个调用stopSelf()的业务节点里，后续业务迭代只要漏写一处，就会留下资源泄漏的坑。
• 你预设的「所有任务执行完成才调用stopSelf()」只是理想状态下的正常执行路径，服务存在很多你业务逻辑控制外的销毁场景，这些场景下你写在stopSelf()之前的线程池回收逻辑根本不会触发，只有onDestroy()是所有销毁路径都会经过的回调。
• 实现逻辑也很简单：在onDestroy()里先调用线程池的shutdown()拒绝新任务提交，设置一个短超时等待已提交的任务执行完成；如果遇到异常销毁的场景，再配合shutdownNow()给运行中的任务发送中断信号，避免僵尸线程残留。

操作系统是否会在不杀死进程的情况下直接销毁服务实例、触发onDestroy() #

会，这类场景并不少见，不要误以为只有进程被杀死时服务才会终止。

• 首先要明确：你配置的android:exported="false"属性，只能阻止第三方普通应用通过Context.stopService()停止你的服务，Android系统本身拥有最高权限，不受这个属性限制，完全可以在不杀死进程的前提下单独销毁服务实例。
• 常见的非杀进程触发服务销毁的场景包括：
  • 极端内存不足场景：前台服务的优先级只是高于普通后台服务、后台Activity，远低于系统核心进程、用户当前正在交互的前台Activity。当设备内存紧张到一定阈值，系统会按优先级从低到高回收组件，完全可能先销毁你的前台服务、暂时保留进程作为缓存，这时候会正常触发onDestroy()回调。
  • 前台服务合规校验失败：Android 12及以上版本对前台服务有严格的规则限制，比如调用startForeground()后10秒内没有展示合规的前台通知、前台服务在后台运行时长超出系统限制、服务声明的前台服务类型和实际运行行为不匹配，系统都会直接停止违规的前台服务，不会杀死整个应用进程，同时触发onDestroy()。
  • 系统省电策略触发：当应用进入深度休眠状态、应用待机分组降到受限等级，系统也可能停止应用正在运行的前台服务，保留进程缓存，触发onDestroy()。
• 要特别注意：这种非杀进程的服务销毁场景下，你提交到线程池里的任务不会自动停止，会作为游离线程继续在进程中运行，不仅会浪费CPU、内存资源，还可能因为任务持有的服务实例、Context对象无法被回收造成内存泄漏，这也是必须在onDestroy()中统一处理线程池回收的核心原因。

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