为什么要取消对onDestroy的绑定? [英] Why unbind Service onDestroy?

查看:48
本文介绍了为什么要取消对onDestroy的绑定?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在多个来源中看到它,如果一个Activity绑定一个Service,它应该在onDestroy上解除绑定.为什么?由于活动已被销毁,因此该服务似乎仍然受到限制.如果它是开始的"-无论如何都没关系.而且,如果它是由活动自动启动的-如果没有其他人绑定它,它将以任何方式关闭.

I've seen it mentioned in multiple sources, that if an Activity binds a Service, it should unbind it onDestroy. Why? Since the Activity is destroyed, it seems like the service will be unbound anyway. If it was "started" - it doesn't matter anyway. And if it was auto-started by the activity - it will close anyway if no others bound it.

那为什么要取消绑定呢?

So why unbind it?

推荐答案

活动需要处理配置更改,例如屏幕旋转,用户更改区域设置或设备进入夜间模式时.

Activities need to handle configuration changes, such as when the screen is rotated, or the user changes locales, or the device enters night mode.

当配置发生更改时,前台活动的默认行为是销毁并重新创建它.

The default behavior of the foreground activity, when a configuration change occurs, is for it to be destroyed and recreated.

因此,在Activity上调用bindService()并不是一个好主意.我们希望绑定在整个配置更改中保持不变.否则,我们的服务将与活动一起被销毁并重新创建(假设活动具有一个唯一的绑定,并且没有其他启动服务).

As a result, calling bindService() on an Activity is not a good idea. We want the binding to remain intact across the configuration change. Otherwise, our service will get destroyed and recreated, along with the activity (assuming that the activity has the one-and-only binding and nothing else started the service).

因此,建议的模式是在Application单例上调用bindService().然后,您可以将ServiceConnection从旧的活动实例传递到新的活动实例.保留的碎片对此非常有用,因为您可以在片段onDestroy()中调用unbindService(),这样,当永久"销毁活动时(例如,用户按BACK,则调用finish()),则可以释放您的绑定.

So, the recommended pattern is to call bindService() on the Application singleton. Then, you can pass your ServiceConnection from the old activity instance to the new activity instance. Retained fragments work great for this, as you can then call unbindService() in onDestroy() of the fragment, so that when the activity is "permanently" destroyed (e.g., user presses BACK, you call finish()), your binding can be released.

以所有这些作为背景,着眼于您的特定关注.

With all that as background, on to your specific concern.

首先,您假设一个已销毁的活动会通过在该Activity上调用的bindService()自动与其绑定的任何服务解除绑定.可能会发生这种情况,尽管我不记得它是记录在案的行为,而这是开发人员不应依赖的事情.

First, you assume that a destroyed activity automatically unbinds from any services that it bound to via bindService() called on that Activity. It's possible that this happens, though I do not recall that being documented behavior, and it's the sort of thing that developers should not rely upon.

更重要的是,在大多数情况下,在Activity上调用bindService()是不正确的方法.否则,您将遇到我上面概述的问题.

More importantly, in most cases, calling bindService() on the Activity is not the right approach. Otherwise, you get into the problems that I outlined above.

但是,按照在Application上调用bindService()的模式,我不希望 ever 会进行某种形式的自动解除绑定,因为Application单例是永不毁灭.因此,如果您无法在某个地方(例如,在保留的片段的onDestroy()中)调用unbindService(),则会泄漏您的服务.

But, following the call-bindService()-on-the-Application pattern, I would not expect there ever to be some sort of automatic unbinding, because the Application singleton is never destroyed. So, if you fail to call unbindService() somewhere (e.g., in onDestroy() of the retained fragment), you will leak your service.

这篇关于为什么要取消对onDestroy的绑定?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆