在 Virgil Dobjanschi 的演讲“开发 Android REST 客户端应用程序”(链接 here )中，他说了一些让我吃惊的事情。包括:
不要在您的 Activity 生成的线程中运行 http 查询。相反，与服务进行通信以执行这些操作，并将信息存储在 ContentProvider 中。使用 ContentObserver 接收更改通知。
始终在服务中执行长时间运行的任务，从不在您的 Activity 中执行。
完成后停止您的服务。
我知道他在谈论 REST API，但我正在努力使其符合我对应用程序的一些其他想法。我一直在使用的 API 之一在他们的聊天界面中使用了长轮询。有一个循环的http查询，大部分都会超时。
这意味着，只要应用程序没有被操作系统杀死，或者用户没有特别关闭聊天功能，我就永远不会用完服务，它会永远保持打开状态.这似乎不太理想。
长问短:
对于使用长轮询模拟推送和即时响应的聊天应用程序，使用服务执行 HTTP 查询并将信息存储在 ContentProvider 中是否仍然是最佳实践？
最佳答案
Don't run http queries in threads spawned by your activities. Instead, communicate with a service to do them, and store the information in a ContentProvider. Use a ContentObserver to be notified of changes.
虽然我已经查看了幻灯片，但我还没有查看演示文稿。我对所提议架构的 ContentProvider 部分持严重保留意见。
Always perform long running tasks in a Service, never in your Activity.
每个人都有自己喜欢的“总是”和“从不”的陈述，包括我自己。我会犹豫是否将其归入“始终”类别。使用 Service 作为长时间运行任务的基地是一个很好的策略，但它也有它的问题(例如，在屏幕旋转中，unbindService() 会破坏Service 在下一个 bindService() 启动之前，如果没有其他绑定(bind)的连接，如果你有一个复杂的应用程序，你就会留下大量的连接簿记)。
For a chat application that uses long polling to simulate push and immediate response, is it still best practice to use a Service to perform the HTTP queries, and store the information in a ContentProvider?
这是一种习惯。恕我直言，对于这是否是最佳实践，目前还没有定论。
关于android - 聊天应用程序与 REST 应用程序 - 在 Activity 中使用线程还是在服务中使用线程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3029055/