Android 终止服务时是否有任何迹象?

发布于 2024-12-19 06:27:47 字数 186 浏览 2 评论 0原文

我有一个服务在它自己的进程中运行。晚上看起来还不错,但在我入睡后,我认为 Android 会对其采取行动。

我的想法是否正确,当 Android 终止服务时,不会调用 onDestroy() ?如果没有,还有其他地方记录了杀戮吗?

我想我需要研究 AlarmManager

I have a service running in its own process. It appears fine in the evening, but after I've gone to sleep I think Android takes its axe to it.

Am I right in thinking that onDestroy() won't be called when Android kills a service? If not, is there any other place the kill is registered?

I think I'm going to need to research the AlarmManager.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

烟雨凡馨 2024-12-26 06:27:47

我有一个服务在它自己的进程中运行。

为什么它在它自己的进程中?

我认为当 Android 终止服务时 onDestroy() 不会被调用,对吗?

可能会,也可能不会。

如果没有,还有其他地方登记了杀戮吗?

不。

我想我需要研究 AlarmManager。

用户讨厌永远存在的服务,这就是任务杀手流行的原因。他们更讨厌在自己的进程中运行的服务,因为它们消耗额外的 RAM、CPU 和电池,通常没有充分的理由。

如果您的目标是定期执行某些操作,请使用 AlarmManager - 这就是它存在的原因。

I have a service running in its own process.

Why is it in its own process?

Am I right in thinking that onDestroy() won't be called when Android kills a service?

It may, it may not.

If not, is there any other place the kill is registered?

No.

I think I'm going to need to research the AlarmManager.

Users hate services that live forever, which is why task killers are popular. They hate services that run in their own process even more, because they consume extra RAM, CPU, and battery, typically for no good reason.

If your objective is to do something on a periodic basis, please use AlarmManager -- that's why it is there.

不奢求什么 2024-12-26 06:27:47

符合服务生命周期开发者文档中,当服务被终止或停止时,onDestroy() 方法将被调用。

另外,如果一个应用程序有一个在后台运行的服务(即在后台播放的音乐播放器),系统会认为该应用程序处于活动状态,并且不会终止其进程,除非极端条件(我认为它不会发生在实践)。

文档中说:

Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it. 

在这里,我想到的是,如果一个服务被操作系统杀死,操作系统稍后会尝试重新启动它。但是,在这种情况下,是否调用了 onDestroy() 方法?我不确定。有人测试过这个吗?

Accordint to the Service lifecycle in the developer document, the onDestroy() method will be called when the service is killed or stops.

Also, if an app has a service running in the background(i.e a music player playing in the background), the system will consider that app is active and won't kill its process except extreme conditions( I don't think it happens in practice).

The document says:

Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it. 

Here, what I am thinking about is that if a service is killed by the os, the os will try to restart it later. But, in this case, is the onDestroy() method called?I'm not sure. Have someone tested on this?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文