1

我看过一些关于这个主题的帖子，但没有一个给出令人满意的答案。

假设我Activity在其onCreate()方法中从我的 main (one-and-only) 启动了一个工作线程。然后我打电话finish()导致Activity终止。

此时，它所属的任务被销毁（因为其中不再有任何任务Activity）。应用程序（以及运行它的进程）可能会继续存在，但是，以空的“骨架”形式存在，因此可以在需要时快速重新启动它（尽管它很容易被系统杀死）。

假设以上是正确的——工作线程什么时候被杀死？只有当系统主动销毁进程时才被杀死？

就我而言，我的工作线程作为蓝牙连接的侦听器存在；收到后，它将Activity再次启动所需的内容。在这种情况下，没有正在运行的组件（Activity、或）。在我看来，这应该可行，只是有些东西正在杀死我的工作线程。ServiceContentProviderBroadcastReceiver

我知道我可以通过使用背景来做到这一点（并且痛苦更少）Service。但是，我很好奇为什么这不起作用。

谢谢，巴里

4

4 回答 4

1

工作线程什么时候被杀死？只有当系统主动销毁进程时才被杀死？

-> 工作线程在其函数中的所有代码run执行后是熟练的。即使你的activity被摧毁，它仍然会运行。

就我而言，我的工作线程作为蓝牙连接的侦听器存在；收到后，它将再次启动所需的活动。在这种情况下，没有主动运行的组件（Activity、Service、ContentProvider 或 BroadcastReceiver）。在我看来，这应该可行，只是有些东西正在杀死我的工作线程。

为了使其正常工作，您需要service在这种情况下拥有背景，并从您的工作线程或更简单地使用softEventBus从您的as 启动任何组件：weakserviceService

 EventBus.getDefault().post(new BlueToothEvent()); // call in your worker thread
// do something in your service
onBlueToothEventFired(BlueToothEvent  e);
于 2016-12-31T04:13:33.253 回答
0

Android 应用程序生命周期有一个很好的例子，非常符合主题：

进程生命周期错误的一个常见示例是 BroadcastReceiver，它在其 BroadcastReceiver.onReceive() 方法中接收到 Intent 时启动线程，然后从函数返回。一旦它返回，系统就认为 BroadcastReceiver 不再处于活动状态，因此不再需要它的托管进程（除非其他应用程序组件在其中处于活动状态）。因此，系统可能随时终止进程以回收内存，并在这样做时终止进程中运行的衍生线程。

简而言之，如果您的线程有机会运行直到终止或进程被提前终止，那么它真的不是很可预测，您绝对不应该依赖任何顺序/行为。

值得一提的是，即使您完成（）它，它也很容易与线程一起 泄漏您的活动，但如果它是您的最后/唯一活动，它不会改变图片

于 2016-12-31T03:39:18.320 回答
0

当您启动一个线程时，它独立于启动它的父级。在您的情况下，这是您的应用程序活动。这意味着在 Run 方法完全执行之前，您的线程将继续存在。

如果您退出应用程序（并因此调用 Activity 的 onStop 方法），线程仍将存在，您将导致内存泄漏。如果内存不足，它最终会被系统杀死。

由于您提到您创建了一个侦听器来侦听蓝牙连接，因此您的线程可能在收到任何事件之前就死了（如果没有任何代码片段，我不可能知道）。它也可能会崩溃，这将结束线程。

于 2016-12-31T03:46:18.260 回答
-1

Android 中有一个主（也称为 UI）线程。这是您的应用程序使用的唯一线程，除非它通过等显式启动一个Thread.start()。AsyncTask.execute()所有活动、服务、广播接收器等都在该主线程上运行它们的所有生命周期方法。请注意，我包括了服务——一个服务在主线程上运行，除非它启动自己的线程（例外是一个IntentService，它确实在自己的线程上运行）。

您创建的AThread将继续，直到Runnable其传递的从其运行函数返回（或者当然进程终止）。这可以持续到Activity/Service它创建的末尾。然而，这样的线程仍然存在于组件的原始实例中，并且如果在没有大量特殊工作的情况下重新启动一个新实例，则将无法访问新实例的变量（参见加载器模式）。

于 2016-12-31T03:27:44.270 回答