在Android应用程序中使用哪个WebSocket库?

x-r*_*ray 124 android websocket node.js

我想在我的Android应用程序中添加一个服务,该应用程序在后台运行,持有WebSocket连接(可能需要几个小时甚至几天),并定期将一些数据发送到服务器.

现在似乎有一堆用于Java的WebSocket库,我不确定应该使用哪一个:

此外,Android 还有一个原生的socket.io客户端库:

使用socket.io Android客户端对我来说很方便,因为我计划使用nodejs/socket.io作为web前端.但本土客户很年轻,有几个未解决的问题.除此之外,我的理解是Android应用程序没有使用socket.io客户端库的任何好处(除了与socket.io 1.0服务器兼容),因为可以在客户端确保WebSocket支持.

我的要求如下:

  • 与Android API 9及更高版本的兼容性
  • 可以通过SSL连接
  • 保持连接很长一段时间,而不必持有永久的唤醒锁
  • 与可用的nodejs websocket服务器实现或与socket.io的兼容性

对于这些要求,哪一个是正确的库?

Tak*_*aki 121

一些笔记.

  • koush/AndroidAsync不执行RFC 6455所需的结束握手.请参阅了解详情.

  • Project Tyrus适用于Android,但要确保其许可证(带有CPE的CDDL 1.1和GPL 2)及其大小(使用ProGuard减少WebSocket客户端jar大小)符合您的要求.另请注意,当文本大小很大时,Tyrus可能会抛出异常(这可能是一个错误).请参阅了解详情.

  • Jetty:一个2年前在jetty-users邮件列表中的电子邮件帖子说:"我们目前没有Android兼容的Jetty 9 WebSocket客户端.有计划尝试将Jetty WebSocket客户端从JDK 7反向移植到JDK 5/6 for android使用,但它的优先级低于完成JSR-356 Java WebSocket API(javax.websocket)的实现." Jetty目前关于其WebSocket Client API的文档没有提及有关Android的任何内容.

  • codebutler/android-websocket不执行RFC 6455所要求的结束握手,并且可能在关闭时抛出异常.看到这个.

  • Atmosphere/wasync使用AsyncHttpClient/async-http-client作为其WebSocket实现.因此,应该提到AsyncHttpClient/async-http-client.

  • firebase/TubeSock无法验证Sec-WebSocket-Accept.这违反了RFC 6455.此外,TubeSock在构建短信时存在错误.如果您对文本消息使用多字节UTF-8字符,您迟早会遇到该错误.见第3期喜悦-IM/Android的DDP约TubeSock问题的一个长长的清单.

考虑点

选择用Java编写的WebSocket客户端实现的注意事项:

  1. 合规.并非少数实现不实现RFC 6455所需的结束握手.(如果未执行结束握手会怎样?请参阅此内容.)
  2. 必需的Java版本.Java SE 5,6,7,8或Java EE?甚至可以在Android上运行?
  3. 大小.一些实现具有许多依赖性.
  4. WSS支持.
  5. HTTP代理支持.
  6. wss over HTTP proxy support.请参阅HTML5 Web套接字如何与代理服务器交互,了解WebSocket客户端库必须采取哪些措施来支持HTTP代理上的wss.
  7. SSL配置的灵活性.SSLSocketFactory并且SSLContext应该能够在没有不必要限制的情况下使用.
  8. 打开握手中的自定义HTTP标头,包括基本身份验证.
  9. HTTP代理协商中的自定义HTTP标头,包括代理服务器上的身份验证.
  10. 能够发送所有帧类型(继续,二进制,文本,关闭,ping和pong)或不发送.大多数实现都没有为开发人员提供手动发送碎片帧未经请求的 pong帧的方法.
  11. 侦听器接口,用于接收各种WebSocket事件.糟糕的界面让开发人员感到沮丧.丰富的界面可帮助开发人员编写健壮的应
  12. 能否查询WebSocket状态.RFC 6455定义了CONNECTING,OPEN,CLOSING和CLOSED状态,但很少有实现以定义的方式维护其内部状态转换.
  13. 能够为套接字连接设置超时值.(相当于方法的第二个参数)Socket.connect(SocketAddress endpoint, int timeout)
  14. 能够访问底层的原始套接字.
  15. 直观易用的API或不.
  16. 记录良好或不记录.
  17. RFC 7692(WebSocket的压缩扩展)支持(aka permessage-deflate).
  18. 重定向(3xx)支持.
  19. 摘要式身份验证支持.

nv-websocket-client涵盖了除最后两个之外的所有内容.此外,它的一个小而方便的功能是定期发送ping/pong帧.它可以通过调用setPingInterval/setPongIntervalmethods来实现(参见 JavaDoc).

免责声明:Takahiko Kawasaki是nv-websocket-client的作者.

  • 对于wss,我尝试了okhttp和autobahn(也怀疑这个答案中的自我推销).高速公路很简单,但没有SSL.OkHttp几乎没有(合并)文档(2016年2月).我浪费了很多时间阅读他们的代码和他们的例外,因为我不知道解决方法(比如将超时设置为0,或关闭传入的消息)以获得一个简单的示例工作.倾倒那两个(和我的沮丧),我发现nv(令人耳目一新)记录良好; 它没有大惊小怪. (7认同)
  • 我不知道有关OkHttp的详细信息.对不起,我很忙[Authlete,Inc.](https://www.authlete.com/)的创始人("[API安全创业公司Authlete筹集了120万美元的种子资金](https:// www.techinasia.com/authlete-gets-seed-funding-500-startups)")我没有时间去研究OkHttp并更新考虑点列表.关于自我的回答后的更改,请参阅[CHANGES.md](https://github.com/TakahikoKawasaki/nv-websocket-client/blob/master/CHANGES.md).请注意nv-websocket-client只是我的爱好,而OkHttp似乎是一个拥有138个贡献者的大项目. (2认同)