做了很久很久的IM(即时通讯)的开发，今天来偷偷盘一盘在IM中的那二三四五点事。
具体产品的内容我就不详细描述了，因为基本是内部产品，所以我怕被发现后，明天工位就没了，在职期间主要负责是IM(web 端)与sdk 以及其他附属产品的开发与维护。
长连接与短连接以及websocket
虽然是即使通讯的产品，但是并不是意味着短连接就可以不用使用，使用长连接的目的是为了保证数据的实时性，但当遇到了如用户登录与头像请求以及个人信息拉取等场景的时候，还是短连接的主场，而且曾经http轮询的方式也是保证消息实时性的一种方法，只是不断的http请求很浪费资源，而且无论是长轮询还是短轮询，都存在着请求之间的窗口期，这也导致了无法保证数据的实时性，虽然后来出现了长连接，可以通过维护该请求来保证数据的实时性，但是也需要消耗资源，直到现在websocket成为了即时通讯的利器。
ACK与NTF
ACK(应答消息) 与NTF(通知消息)，ACK作为保证了IM可靠性的机制，不仅仅指TCP的ACK机制,为了避免数据在到达服务端之前丢失，也会在应用层实现一套ACK,可以康康ACK与NTF机制为我们做了什么
已读不回
当消息推送到服务端并且成功进入消息队列后，会ACK给我们一条消息，这时候我们就知道消息未读，对面的小姐姐这时候点开聊天会话，前端开始给服务端传纸条，告诉服务端你的小姐姐查收了未读消息，服务端开始给你发送NTF消息，告诉你，你的小姐姐已读......但是不回复你
离线消息
离线消息也是作为即时通讯中一个比较常见的场景，为了确保你在离线状态也不会丢失消息，服务端专门会给你存储起来，在确保了你接受到后会从离线消息的队列中删除，留着下次你不在线的时候再帮你存
长列表
产品中最常见的长列表主要是最近联系人列表与聊天会话，最近联系人由于可以固定每个item的告诉，所以可以通过虚拟列表或者懒加载的方式来做优化，不过你还是需要维护整个会话列表，因为你需要随时准备新消息推送过来后更新列表，但是会话列表中因为需要处理文字，图片以及图文等消息内容，每个消息的高度并不能很好的把控，这个时候怎么办呢，怎么办呢，技术不太好实现，于是从业务下手，直接固定一个历史消息拉取的页数，这样即使全部展示出来也不会太影响体验....嘿嘿嘿
消息拉取与缓存
由于会话消息的序列化是在服务端处理的，所以这里不做详细的展开，我们使用微信可以发现如果长时间用手机微信再使用pc微信，pc微信的消息还停留在很久前，需要等很久才能正常，这个过程被称为消息拉取跟补齐，为了避免用户进入群的时候，消息不是最新的，在页面进入的时候，会根据最近联系人的会话列表顺序，做优先的消息补齐，因为主要是内部使用，大家基本上都是用公司电脑来使用，所以我们会做最近几条会话的缓存，如果最新的消息与缓存中的时间相同，则不去做消息拉取（虽然用web缓存历史消息并不推荐，但是这个也是根据业务场景的优先选择了），有最新的消息了，会拉取最新的消息并且覆盖缓存，这样可以避免打开消息后焦鸡（焦急）的等待嗷~
一个小尾巴
做了这么久的IM，其实会发现其中有很多细节的东西，这些在网络课程上不会教你，也有些是因为业务相关，有时候跟不懂的人说我是做IM的，他们都说IM这么简单....我真的好羞愧啊，孩子哭了啊，篇幅原因，很多IM的东西没有被展示出来，有疑问的可以在下面评论提问嗷
故事到这里已经结束，那么，让我们异世相遇，尽享美味吧~奥里给
