Android AsyncTask vs Thread + Handler vs rxjava

Question

我知道这是被问了很多次的问题。然而，我从来没有找到答案。所以希望有人能给我一些启示。

我们都知道AsyncTask和Thread是执行后台任务以避免ANR问题的选项。建议asynctask只能用于短时间运行的任务，而线程可用于长时间运行的任务。 asynctask不应该用于长时间任务的原因众所周知，这是由于asynctask可能导致的泄漏，因为它可能会在某个活动被破坏后继续运行。这是令人信服的。但是，它也会导致一些其他问题：

1. 线程是否也独立于活动生命周期？因此，asynctask的风险也可以应用于线程。那么为什么线程适合长时间运行的任务呢？
2. 看起来asynctask的风险只适用于与活动一起使用。如果我们在服务中使用它（不是IntentService，因为IntentService在其工作完成后停止），并且只要我们可以保证在服务停止时取消asyntask，我们可以将它用于长时间运行的任务吗？这是不是意味着在服务中使用asynctask是无风险的？
3. 我玩过rxjava一段时间，真的很喜欢它。它消除了对线程操作的担心（除非你必须决定在哪个线程中订阅和观察发送的数据）。从我所看到的，rxjava（与其他一些libs一起，如retrofits）似乎是asynctask和thread的完美替代品。我想知道我们是否可以完全忘记它们，或者有任何特定情况下rxjava无法实现asynctask和thread可以做的事情，我应该知道的是什么？

感谢

Answer 1

由于没有人的回复。那么我正在回答我自己的问题。

1. 为什么AsyncTask建议只是短期的任务（约5秒），原因是没有方法来取消正在运行的AsyncTask。存在调用onCancelled(Result result)的称为AsyncTask.cancel(true)的方法。但是，根据文档，此方法“在调用cancel（boolean）并且doInBackground（Object []）完成后在UI线程上运行。” （https://developer.android.com/reference/android/os/AsyncTask.html）。另一方面，Thread可以用Thread.interrupt()停止。
2. 在Service内运行AsyncTask应该没有任何问题，前提是您知道AsyncTask的取消限制，并且可以由AsyncTask创建内存泄漏的可能性。请注意，在工作线程中已经运行的IntentService中显然不需要使用AsyncTask。
3. 这是一个非常基于经验的问题。我想这不会有完整的答案。我们所能做的就是了解Rx并意识到它的局限性，以确定何处适合使用它。在我的开发工作中，我始终使用RxJava而没有任何问题。请注意，相同的内存泄漏问题也适用于RxJava。您也许可以找到其中一个具体问题here。还有一大堆关于处理泄漏/屏幕旋转的讨论，RxJava可以通过Google搜索轻松找到。

Answer 2

的AsyncTask和线程+处理器没有精心设计和实施。 RxJava，Akka和其他用于异步执行的框架似乎更加精心开发。

每种技术都有其局限性。 AsyncTask适用于具有在UI上显示进度的单个并行任务。但是，如果活动重新生成（例如由于屏幕旋转），则与用户界面的连接丢失（此问题的一种可能解决方案是https://github.com/rfqu/AsyncConnector）。

Thread+Handler即使在没有要处理的消息时也为线程堆栈保留内存。这限制了可能的线程数量。您可以拥有比处理程序线程多得多的Akka actors或RxJava Subscribers，具有类似的功能。