简单套接字客户端应用程序的模式或最佳实践

Question

(葡萄牙语也提出了这个问题.)

首先,为长文本道歉,并在一个问题中提出这么多要点.我认为这样做是最好的,因为它们是相互关联的,也因为我认为任何有这种应用经验的人(Android套接字客户端与服务器保持持久连接以发送/接收消息)都能够回答所有或许多要点.基本上我正在询问有关一些设计决策的建议,我不确定"推荐的Android操作方式"是什么.

我正在尝试确定在Android中实现此类应用程序(套接字客户端)的最佳方法.它将使用诸如WebSocket,Socket.IO,TCP等的套接字通信技术来保持与远程服务器的持久连接以交换信息.我没有特别提到的案例,除了它可能不是聊天应用程序,因为它的优先技术是推送通知(GCM或类似的东西).我正在考虑一个应用程序,只要用户"登录"它就可以保持连接打开.

连接不应该与应用程序的活动相关联,即在用户离开应用程序之后仍然可以接收消息(最终创建通知).

我正在尝试回答的问题,以便定义这样的应用程序:

1. 是否应将连接处理(连接/断开连接)和消息发送委托给单独的类(例如Singleton)？

2. 选择广播将收到的消息传递给当前Activity似乎没问题; 有更合适的解决方案吗？Service即使应用程序架构相当简单,事件总线或绑定是否更可取？

3. 考虑到连接必须在进程终止之间持续存在(因为系统通常会释放内存),最好的方法是将'connect'操作委托给一个Service带有重写startCommand()方法返回START_STICKY(这允许Service重新启动时尽快重启)系统的内存可用)？这是最合适的方法吗？我想是这样的,因为AlarmManager在这种情况下设置定期连接检查是不必要的,并且使用startForeground()不会阻止应用程序被杀死(它只是使得不太可能发生)并且还向用户显示不期望的通知应用程序是运行.

4. 当我们就设计达成一致时,我认为需要添加唤醒锁,以防止设备在处理传入/传出数据时保持睡眠状态.我不知道如何将它们添加到最终设计中,我要求澄清.我想到了以下额外的考虑因素:

   a)进入的数据预计会唤醒设备,但不能保证在它恢复睡眠之前完全处理;

   b)设备在连接到服务器时处于睡眠状态(通过CONNECTIVITY_CHANGE广播发出信号)这一事实不应该阻止在应用程序中排队的多个外发消息被发送,但我不知道如何为此设计添加唤醒锁定以确保队列完全处理;

   c)我的协议库可以准备与Android一起工作(即处理一个或多个非UI线程中的I/O),但可能无法保证其回调可以在非UI线程中运行(库可以将它们委托给UI线程).这可能会影响我通过代码处理唤醒锁的方式.

5. 我是否需要保持一个主动运行的线程循环才能保持连接打开？我怎么能绕过那个？

对这些问题的任何反馈表示赞赏.