如何排查服务销毁原因？能否区分用户与系统触发的服务销毁？

嘿，这个问题我之前帮不少开发者排查过，刚好能给你一些实用的思路！咱们先从区分用户主动停止和系统销毁说起，再一步步讲排查和优化的方法。

核心思路是给两种销毁场景做「标记」，从回调和状态上区分：

• 主动设置停止标记：在调用stopService(myService)之前，给服务传递一个「用户主动停止」的信号。比如在Service类里定义一个布尔变量private boolean isUserStopped = false，然后通过Binder或者Intent额外参数把这个标记设为true。当onDestroy()触发时，检查这个变量：如果为true，就是用户主动操作；否则基本可以判定是系统销毁的。
  举个简单的例子，调用stop前通过Intent传递：

  Intent stopIntent = new Intent(this, MyService.class);
  stopIntent.putExtra("USER_STOP", true);
  stopService(stopIntent);
  

  然后在Service的onDestroy()里读取这个参数或者之前设置的变量。
• 利用系统回调差异：用户主动调用stopService()时，onDestroy()会直接触发，而且一般不会伴随系统的低内存警告回调；而系统销毁服务几乎都是因为内存不足，这时候会先触发onTrimMemory(int level)或者onLowMemory()。你可以在这两个方法里打日志，后续看日志就能知道是不是系统因为内存压力动手的。

系统销毁后台服务大多和内存管理有关，但也有其他可能，你可以从这几个方向入手：

• 加全生命周期日志：在Service的onCreate()、onStartCommand()、onTrimMemory()、onLowMemory()、onDestroy()里都打印详细日志，包括：
  • 时间戳
  • 当前可用内存（用ActivityManager.MemoryInfo获取）
  • 进程优先级（Process.getThreadPriority(Process.myTid())）
    比如在onTrimMemory()里打印level值：TRIM_MEMORY_RUNNING_LOW表示后台内存紧张，TRIM_MEMORY_COMPLETE说明系统要大规模回收内存了，这些都是系统要销毁服务的前兆。
• 查Logcat系统日志：过滤ActivityManager相关的日志，系统销毁进程时会输出类似这样的信息：

  Low Memory: Killing process com.your.package (pid 1234) with reason: background
  或者
  Process com.your.package (pid 1234) has died: fore OOM
  这些日志会直接告诉你系统销毁的原因（OOM、后台进程优先级低等）。

• 检查服务启动模式：在onStartCommand()的返回值很关键，如果返回START_STICKY，系统内存充足时会重启服务；如果返回START_NOT_STICKY，销毁后就不会自动重启。你可以在日志里记录返回的类型，看是不是因为返回值导致服务没恢复。
• 排查绑定关系：如果你的服务绑定了Activity，当Activity销毁且调用了unbindService()，同时服务没有其他绑定者、也不是前台服务，系统就会销毁它。检查你的绑定和解绑逻辑，确保服务在需要运行时不会因为解绑被误杀。

既然你的服务是采集加速度计数据，属于需要持续运行的场景，可以试试这些优化：

• 转为前台服务：调用startForeground()显示一个轻量通知（Android 8.0+要先创建通知渠道），前台服务的优先级远高于后台服务，系统不会轻易销毁它。
• 优化内存占用：及时释放不再需要的对象，比如加速度计的监听器在服务暂停时要取消注册，避免内存泄漏。可以用LeakCanary工具检测是否有内存泄漏问题，泄漏会让进程内存占用越来越高，更容易被系统盯上。
• 合理调整任务调度：如果不需要实时采集，比如每隔几秒采集一次，可以用WorkManager来定时执行任务，让系统在合适的时间调度，避免服务一直后台驻留占用内存。

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