我想知道是否需要SpiceManager的shouldStop（）方法..我认为它应该从活动/片段解除绑定可能的侦听器，但如果活动将被杀死，那么它是否物？垃圾收集器仍将清理活动/片段，后台服务仍将单独完成。或者我错了吗？当你忘记后台线程中的一些引用时，Android真的会泄漏吗？
source code中有一些（错误的）评论：对于shouldStop()，它表示它会异步进行解除绑定，而shouldStopandJoin()会同步进行解除绑定。但是应该停止调用toStopAndJoin，而且应该停止注释并且注释它主要是一种测试方法。那么我们真的需要在activity的onStop（）回调中调用shouldStop吗？
我问这个是因为我想在Application上下文中有一个spicemanager实例，它没有处理清理或停止事务的特殊方法。所以我想确保没有泄漏或类似的东西。要清楚，不是真的在应用程序上下文中，而是从应用程序上下文启动并管理所有后台内容（如robospice请求或位置内容）的自定义“控制器”。我正在尝试模拟MVC模式，其中所有逻辑实际上都独立于仅具有用于更改UI的@Subscribe方法的活动和片段。
编辑：实际上，如果我从应用程序上下文中调用它，那么它与Activity或Fragment的情况不同。即使活动或碎片确实泄漏，申请也不应该，对吧？
感谢您提出任何意见。
答案 0 :(得分：5)
当您在后台线程中忘记某个引用时Android是否真的泄漏了？
是的，确实如此。这正是造成泄漏的一种非常好的方法。
那么我们真的需要在activity的onStop（）回调中调用shouldStop吗？
是的，你按顺序1）防止泄漏; 2）防止你的回调在启动上下文死亡后被触发，这会导致崩溃。 但你是对的，javadocs可能导致混乱。调用了EatStopAndJoin进行测试（将其视为私有+测试）并且shouldStop是公共的。
即使活动或碎片确实泄漏，应用程序也不应该，对吗？
右。当应用程序死亡时，这意味着整个应用程序进程终止，并且在Java中没有任何方法可以从VM外部泄漏。因此，对于应用程序类，没有办法正确调用shouldStop而且不需要它。