真的需要 RoboSpice shouldStop() 吗？

Question

我想知道 SpiceManager 的 shouldStop() 方法是否需要。我认为它应该将可能的侦听器与活动/片段解除绑定，但如果活动无论如何都会被杀死，是吗？事情？垃圾收集器仍将清理活动/片段，后台服务仍将单独完成。或者我在这里错了吗？当您忘记后台线程中的某些引用时，Android 真的会泄漏吗？

source code 中有一些（误导性的）cmets：对于 shouldStop()，它表示它将异步执行解除绑定，对于 shouldStopandJoin() 则同步执行。但是shouldStop调用shouldStopAndJoin，shouldStopAndJoin评论说它主要是一种测试方法。那么我们真的需要在activity的onStop()回调中调用shouldStop吗？

我问这个是因为我想在 Application 上下文中有一个 spicemanager 实例，它没有处理清理或停止事物的特殊方法。所以我想确保没有泄漏或类似的事情。需要明确的是，并不是真正在应用程序上下文中，而是从应用程序上下文启动并管理所有后台内容（如 robospice 请求或位置内容）的自定义“控制器”。我正在尝试模拟 MVC 模式，其中所有逻辑都真正独立于只有 @Subscribe 方法来更改 UI 的活动和片段。

编辑：实际上，如果我从应用程序上下文中调用它，那么它与 Activity 或 Fragment 的情况不同。即使活动或片段确实泄漏，应用程序也不应该，对吧？

感谢任何cmets。

Answer 1

当您忘记后台线程中的某些引用时，Android 真的会泄漏吗？

是的，确实如此。这正是制造泄漏的好方法。

那么我们真的需要在 Activity 的 onStop() 回调中调用 shouldStop 吗？

是的，您这样做是为了 1) 防止泄漏，2) 防止在启动上下文死亡后触发您的回调，这会导致崩溃。 但你是对的，javadocs 可能会导致混乱。调用 ShouldStopAndJoin 进行测试（将其视为私有 + 测试）并且 shouldStop 是公共的。

即使活动或片段确实泄漏，应用程序也不应该，对吧？

没错。当应用程序死掉时，这意味着整个应用程序进程都死了，并且没有任何东西可以泄漏到 Java 中的 VM 之外。因此，对于应用程序类，无法正确调用 shouldStop，也不需要。