在基于应用程序的线程或基于服务的线程中下载一个小文件？

Question

我很确定使用Service和AsyncTask处理异步文件下载是标准做法。这样，你可以杀死原始活动，继续你的快乐方式。但是，当您不需要生命周期管理，远程进程通信或服务的其他主要功能时，似乎有点矫枉过正。

由于Service仍然是整个Application的相同进程和生命周期的一部分，为什么不简单地在Application的上下文中运行后台线程（vs Activity，尽管不一定在扩展的Application类中）？有什么理由说这会是一个特别糟糕的主意吗？

Answer 1

  

我很确定使用Service和AsyncTask处理异步文件下载是标准做法。

AsyncTask中的Service无用，因为您没有理由对Service中的主应用程序线程执行任何操作。使用IntentService进行下载，因为它会为您提供后台线程，并且在没有其他工作要做的时候会自动停止。

  

为什么不简单地在应用程序的上下文中运行后台线程...有什么理由为什么这会是一个特别糟糕的主意？

因为您的应用不可靠。

虽然很多人专注于服务的独立生命周期，但这并不是你为这样的事情使用服务的原因。您使用服务作为操作系统的标志，您的进程仍在执行某些操作。

一旦您不再处于前台，Android可以随时终止您的流程。特别是如果有很多内存压力，这可能是你的应用程序离开前台的毫秒数。

但是，Android通常优先考虑在包含正在运行的服务的进程之前终止空进程（没有运行活动或服务的进程）和仅活动进程。在这里，“通常”意味着带有服务的流程不会永远存在，但它们很可能不会很快被终止。

因此，使用IntentService向操作系统发出信号，告知您仍在向用户提供价值（下载文件），并且应该让您的流程单独处理，直到您的IntentService停止为止（因为下载完成了）或者你的服务运行所以很长，以至于它可能丢失了它的虚拟大理石。

Application 不 a Service。每个进程都有一个Application实例。下载由Application“管理”是没有意义的 - 您也可以在任何Context之外运行裸线程。而且，最重要的是，没有任何东西告诉操作系统您正在做任何有意义的事情，所以一旦离开前台就可以终止您的过程。

  

但是，当您不需要生命周期管理，远程进程通信或服务的其他主要功能时，似乎有点矫枉过正。

在清单条目之外编写IntentService并不比编写AsyncTask复杂得多。调用IntentService并不比调用AsyncTask复杂得多。