Android 中的持久服务/线程
我最近刚刚开始使用 android 框架，正在寻找用于以下情况的建议/设计模式：
应用程序是服务器/客户端结构。服务器应始终运行（或至少在终止后不久重新创建），但客户端可以根据需要关闭。为了完成服务器，我知道我想要扩展 Service 并使用 START_STICKY 功能并在后台运行它。
我有点不知道如何继续的部分是我想在服务器内部创建几个持久的网络连接。连接是线程化的并且可以异步运行，这一点很重要。很多文档都指向使用 AsyncTask 来实现此目的，但我根本不需要从网络线程引用 UI 线程，并且连接永远不会终止，所以我希望有人可以为我指明更好的方向？
我的概念想法是让网络线程绑定到服务来存储事件，然后客户端也可以绑定到服务来检索事件。我不确定用于这些网络线程的结构。
I've just recently started working with the android framework and am looking for advice/design patterns to use for the following situation:
Application is a server/client structure. The server should be running at all times (or at least be recreated shortly after termination), but the client can close as need be. To accomplish the server, I understand that I want to extend Service and use START_STICKY functionality and run it in the background.
The part where I'm a bit lost of how to proceed is that I want to create several persistent network connections inside the server. It is important that the connections are threaded and can run asynchronously. A lot of documents point towards using AsyncTask for this, but I don't need to reference the UI thread at all from the network threads and the connections wont ever be terminated, so I'm hoping someone could point me in a better direction?
My conceptual idea was to have the network threads bind to the service to store events, and the client can then also bind to the service to retrieve the events. I'm unsure of the structure to use for these network threads.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很少有应用程序需要它。从统计上来说，你的可能不是其中之一。用户使用任务杀手等攻击像您这样的人，并在市场上给予一星评级，以损害他们对设备的使用。我强烈建议您重新考虑这个设计决策。
普通的普通 Java 线程就可以了。根据线程的性质，您可能会考虑使用线程池。这部分与其他 Java 环境没有显着不同。请记住，当今绝大多数 Android 设备都是单核的，并且您只有这么多的堆空间（只有 16MB），因此拥有大量线程并不是很好。
网络线程是服务的一部分，因此不需要绑定到它。
There are very very few applications that need this. Statistically speaking, yours probably isn't one of them. Users attack people like you with task killers and the like, plus give out one-star ratings on the Market for harming their use of their device. I strongly encourage you to reconsider this design decision.
Plain old ordinary Java threads are just fine. Depending on the nature of the threads, you might consider using a thread pool. This part is not significantly different than in other Java environments. Bear in mind that the vast majority of Android devices today are single-core, and you only have so much heap space (as little as 16MB), so having tons o' threads isn't exactly great.
The network threads are part of the service, and therefore don't need to bind to it.