android上Activity的生命周期图并不能保证onDestroy()会被调用，但是进程可能会被杀掉，Activity会被突然移除。 android 上 Service 的生命周期图确实保证会调用 onDestroy()。所以我有两个关于这种差异的问题。
首先，如果 Service 与 Activity 属于同一进程，那么 Service onDestroy() 是否被调用，而 Activity onDestroy() 没有被调用？我认为不会，因为“杀死进程”表明操作系统正在停止其线程并释放其资源。
如果是这样的话，一个仅服务进程会被操作系统突然杀死吗？
【问题讨论】：
我不确定您在哪里看到服务可以保证调用onDestroy()。据我所知，情况并非如此。如果您阅读文档的this 页面，它描述了服务可能被终止的条件。因此，如果您询问是否正在终止同时托管活动和服务的进程，是否会在服务上调用onDestroy()（但不在活动上），那么答案是否定的；不一定会调用服务的onDestroy()。至于一个只服务的进程是否可以被操作系统突然杀死：是的，可以。当您有很多工作要做时尤其如此，并且您的 onStartCommand 调用仅将工作排队等待异步执行。然后服务将花费大部分时间不在受保护的onCreate、onStartCommand 或onDestroy 方法中。
【讨论】：
有两点需要考虑：
Android 可能会在某个时候决定关闭进程，当内存 低并且其他更直接的进程需要 为用户服务。在进程中运行的应用程序组件 杀死因此被摧毁。再次启动一个进程 当他们再次有工作要做时，这些组件。 Source
在这种情况下，onDestroy() 不会被调用，因为 Android 操作系统无论如何都会回收资源（这通常是操作系统的基本任务）。
服务既可以启动也可以绑定连接。在 在这种情况下，系统将保持服务运行，只要 它要么已启动，要么与它有一个或多个连接 Context.BIND_AUTO_CREATE 标志。一旦这两种情况都没有 持有，服务的 onDestroy() 方法被调用，服务是 有效终止。所有清理（停止线程，注销 接收器）应在从返回时完成 销毁（）。 Source
因此，当 Android 操作系统注意到 Service 已完成其工作并且不再需要它时，它将被销毁。操作系统让应用程序有机会释放服务的资源以防止内存泄漏。 在这种情况下，onDestroy() 被称为，因为这是应用程序可以释放其资源的地方。当然，在这种情况下，应用程序的进程保持不变（因为其中可能正在运行其他服务/活动）。
【讨论】：
Once neither of these situations hold != guaranteed != always
Once neither of these situations hold, the service's onDestroy() method is called。这仍然意味着即使在两种情况下都不会在没有调用 onDestroy 的情况下杀死服务。在实践中，这恰好是真的。
Service 以正常方式停止时调用（例如通过stopSelf）。当Service 被杀死（被系统）时，它并不总是被调用