最近做的项目又牵扯到聊天功能（此处发誓我们不是做社交的！），虽然网页聊天和手机应用不大一样，还是想要理一理及时聊天的解题思路，大家可以参考这个模型，自我感觉结构是完整了但有点复杂，非常欢迎任何形式的探讨。先放张效果图：
接下来会把聊天功能的实现分成两个部分来解释，这一篇主要是数据在客户端和服务器之间传输过程；另个篇主要讲讲我怎么设计并区分聊天过程中消息的不同状态的（三个状态：正在发送，发送成功，发送失败，而这张图里貌似没有- -）。
用户第一次打开App的时候网络层已经向服务器发起长链接，并且服务器查数据库将新消息返回给客户端，客户端将新数据保存到本地数据库。
用户第一次进入某个聊天状态的时候，业务层取出本地数据库的聊天数据，并将一些聊天相关的数据保存在内存，以便随时显示和更改。由于服务器和客户端的数据库状态要保持一致（网页聊天就不用了，因为每次都是重新向服务器请求所有聊天记录，除非网页有做缓存。App就不得行，你没网就也要让人家看到历史记录），所以需要把当前聊天的最后一条已读消息ID发给服务器记录。初始化了数据，就启用一个定时器线程来刷新界面，间隔40ms刷新一次，一般用户是感觉不到的。
用户这个时候要发消息了！
A编辑好内容，点击发送按钮想要发给B，客户端程序先把数据存入本地数据库，然后再将数据加入聊天界面显示的列表（记着：刷新界面的线程还在定时工作呢！），此时消息状态应该还处于正在发送中。
开启一个异步任务——发送这条消息到服务器，服务器在保存数据后，需要返回这条记录的ID（问我为什么？上面说了啥，别忘要有两端数据库状态的一致性检验哦！）
接着还不忙返回发送成功的喜讯，服务器先看看B在不在线，如果正巧也在线，就将消息打包立刻发送出去（这里修改了sentflag值，为了表明消息已经发送到B）。
不管B在不在线都要返回发送成功的喜讯啦，客户端收到喜讯就将对应消息的状态改为发送成功，如果由于网络故障等原因，导致一段时间没有返回喜讯，客户端就将对应消息的状态改为发送失败（当然，你也可以一直让状态保持在正在发送，这样做省事但有点反人类）。
