我计划通过这个库在android中实现 Socket.io，用于基于聊天的应用程序。据我所知，图书馆似乎相当不错。我想知道如何在整个应用程序中始终保持单个套接字连接？在这里，我列出了实现的方法，在这些方法中，我需要最好和稳定的方法。
三种方式
主要应用类扩展应用程序
通过这种方式，我们有一个很好的范围，即套接字连接在主线程（或应用程序的生命周期）中保持，并且每当从活动中需要套接字实例时，我们都可以轻松获得它。但这也是问题所在。它可能会阻塞主线程。
绑定服务
通过这种方式，我们可以将服务与活动绑定，并且可以简单地使用它。在单独的线程中执行操作是实现 IO/网络调用的方法。但是，跨处理传输比在同一进程中直接访问更昂贵。
单身 人士
在 Singleton 中保持连接也有意义。但是我们不知道实例何时被进程杀死，因为它在活动生命周期中不起作用。
如果我有意义，请帮助我。如果没有注释掉它。
我已经给出了更适合我的答案。
首先，应用程序在您的用例中无关紧要，因为当线程首次在非服务代码中启动时，您不能在后台运行该线程。onCreate()
另外，我建议使用Google Cloud Messaging而不是创建自己的机制。这对设备的电池寿命和更少的代码来说是最好的。
如果您确实想完全靠自己实现该聊天，这是您唯一的选择。您也可以将其与单例结合使用，但我不建议使用这种方法。您可以使用广播和在 和 之间进行通信，我认为它比绑定服务更容易，因为绑定到服务是异步的，与简单的广播相比，它会产生很多混乱。ServiceBroadcastReceiverServiceActivity
socket根据Ofek Ron提到的是一个比更好的主意。因为这是一个繁琐的沟通过程。我也推荐广播方式，比如或（我自己建议Otto by Square，这是干净而出色的api）。ServiceBroadcaseReceiverBoundServicepub/subOttoEventBus
奥托
的优点 1.清洁剂 API
2.您可以在任何 、 、 类中订阅和发布。
解耦。（您必须在代码中尽可能少地耦合）。ActivityFragmentService
还有一点是使用START_STICKY在它被销毁后启动服务。请参阅此参考。onStartCommand()
最佳做法是在 扩展 中启动服务。因为当存在内存约束或用户从堆栈强制关闭应用程序时，应用程序将被终止。因此，不会像我们在活动中实现的那样频繁调用。MainApplicationApplicationonStartCommand()
您只需在类中实现即可实现联机状态，该类具有活动的大部分生命周期回调，并将在回调中收到通知。通过这种方式，您可以简单地实现状态，而无需任何样板代码。（如果有人需要帮助，请告诉我）。Application.LifeCycleCallbacksMainApplicationOnline
最佳做法是通过 实现，因为它在单独的线程中运行。我保证哪个会提供最佳性能，因为它是由Android本身处理的，而不是像我们创建的线程一样。IntentService
