对于上下文，我正在阅读Tejas Lagvankar在this very good blog post找到的Android中的线程机制的比较。在这篇文章中，以及Android文档的许多其他帖子甚至领域中，＆＃34;长期运行＆＃34;任务被反复使用，但我还没有看到一个真正的定义是什么限定任务长期运行。
鉴于我们必须根据应用程序API级别和其他受支持的限定符考虑不同的设备功能，因此对于符合条件的任务而言，下限是什么？＃34;长时间运行＆＃34;。 （最好是以毫秒为单位的测量单位）。
答案 0 :(得分：2)
如果主线程被阻止超过5秒，Android将声明“应用程序无响应”或ANR。实际上，用户会注意到小到100毫秒的延迟，因此这是一个“最坏情况”的起点。如果您的操作可以以任何方式阻止（文件I / O，图像解码，网络访问等），那么您应该遵循bg线程。
答案 1 :(得分：2)
我不会尝试在一段时间内定义长时间运行的任务，而是通过这项任务的全部内容来定义。您可以成功地在UI线程上执行文件I / O操作，因为在您的测量中它们需要几毫秒，但可能会发生I / O阻塞并且您的代码将导致ANR。另一个例子是当你解析json数据时，如果它很小，那么它会很快，但如果它变大，那么它也可能导致ANR，甚至可能导致OOM（Out Of Memory）异常。因此，我认为通过查看此类任务正在执行的操作并考虑其如何扩展（如果数据变大会发生什么），可以更安全地对长期运行的任务进行分类。
为了安全起见，总是在工作线程中进行I / O，数据解析/处理，网络通信（这里实际上你别无选择）。
答案 2 :(得分：1)
我还没有看到过长期运行的任务合格的真正定义
在很大程度上，这取决于具体情况。而且，你假设每个人都使用“长期运行”这个词。是以同样的方式这样做。
恕我直言，这无法真正以抽象的方式回答。合格任务的下限为＆＃34;长时间运行＆＃34;
所以，例如：
在避免＆＃34; jank＆＃34;的背景下（丢帧），我认为＆＃34;长跑＆＃34;是任何需要超过1毫秒的回调。我们的许多回调都需要作为UI渲染的一部分进行调用，如果它们的总数花费太长时间，我们可能会删除一帧（即，应该在发生更新时不更新屏幕）。在实践中，如果你没有丢帧，那么＆＃34;长时间运行＆＃34;的确切阈值。取决于你，虽然在数学上它显然必须小于16毫秒。
在一个线程/ AsyncTask的上下文中，由一个活动分叉，由于活动被破坏而结束无意义（例如，BACK按钮），我会考虑＆＃34;长时间运行＆ ＃34; <数百毫秒。
在存在流程终止风险的情况下中断您的后台工作 - 如果您真的需要完成工作，何时考虑使用服务的阈值 - 我会考虑＆＃34;长时间运行＆＃ 34;大约一秒钟。
在存在设备入睡风险的情况下，因此需要考虑WakeLock来保持CPU的正常运行，我会考虑＆＃34;长时间运行＆＃34;大约15秒，因为这是用户可以指定的最低不活动超时。并假设用户是触发这一特定背景工作的用户;在其他情况下（例如AlarmManager，GCM消息），您需要WakeLock来处理任何事情。
等等。
虽然我的选择背后有一些数学，但最终，他们是我的选择，而其他Android专家可能会有其他人。