android 群聊架构,[Android]搭建原生聊天架构 _发送

项目已交接，暂不再更新。
-----------------------------------------------------分割线-----------------------------------------------------------
新做了聊天业务，和后台一起，都是原生搭建的。目前为止开发了聊天室，还没有做聊天房间列表。已经开发出简版~ 过程有很多弯路和坑，留下记录，给小伙伴们提供思路，也希望能一起讨论还有什么可以改进的地方。
(边开发边记录，慢慢更新。文章太长，作者太懒…)
本文不会重点记录代码，主要记录重点部分的实现逻辑。
本文撰写过程中，老大对后台架构做了改版，新版非常强大，原来客户端的很多控制和判断都不再需要，膜拜老大。
(这个老大真的很厉害，我们办公室有很多人减肥，都减不下来，但他从某天决定开始减肥之后，一个月瘦10斤，现在保持健身。很有意志力。)
聊天流程
已更新。新架构下的流程：
进入房间，通过url得到 topic(相当于服务器中以房间为单位的业务处理器)，连接，请求到未读消息存入本地数据库，然后通过数据库获取消息来显示。
每次发送和接收消息，都存入数据库。
发送时，通过消息队列实现超时时间内的持续发送(刚听说这种实现有个高大上的名字叫做消费者——生产者模式)，兼容网络不稳定的情况。在1.3中有详细说明。
发送成功和失败后需要在页面上(View)和数据库(Model)里改变发送状态。
业务内容：
消息的各种状态处理
超时时间内持续发送
网络自动重连
1. 关键技术点：
1.1 消息3次握手
1.2 重连
1.3 消息队列
1.4 图片加载——被迫造轮子
2. 逻辑绕弯点：
2.1 显示方案——消息如何排序
2.2 聊天对话框的复用(左右 -> 融合两侧隐藏一边)
2.3 图片复用非常重要，还要及时释放！
3. 其他问题：
3.1 全屏下竖屏的系统缺陷(系统bug)
3.2 发送表情时，不能滚动到底部
理想功能：
未发送成功的消息记录，在下一次打开社区时发送到远程，真正实现多端历史记录同步(未验证微信QQ是否有此功能，有待验证)
【android 群聊架构,[Android]搭建原生聊天架构】1.关键技术点
1.1 每条消息的3次握手
握手过程图：
消息的3次握手示意图.png
第一次：客户端发送消息到服务器
第二次：服务器成功接收消息，返回反馈信息到客户端

文章插图
第三次：本地接收到反馈信息，发送已收到反馈到服务器
握手的3个环节中，任何一个环节都有可能发送失败。将导致牵扯出消息重复、客户端与服务端记录的消息状态不同步、退出聊天页面再次进入后历史消息有重叠等等的可能情况，鉴于太过复杂，开发周期太长，目前的初版有很多处理还没有开发。暂留做升级功能。
-------------------更新--------------------
部门老大出手对后台改了架构，服务器把消息发送到服务端时对TCP的发送状态做了监听，所以3次握手成功省略掉第3个环节，进化成2次握手~ ！鼓掌庆祝~！
所以发送成功的处理与客户端分离，客户端只需要接收消息并显示，成功回归无脑本质，非常nice 。
1.2 聊天的基础——
保持连接——轮询联网
因为聊天功能的实时通讯性质，必须与服务器保持连接，所以聊天时，持续的连接是必须的。每次断开，都要能自动重连上。
所以这就是第一个轮询：重连机制。
之所以列为机制的地位，必然是踩了不少坑。
以下是轮询相关代码：