椎锋陷陈

推送的意义「推送机制」为我们提供了一条可以「直接触达用户」的路径，使移动设备终端的「全时信息传播」成为可能，是C端运营人员提高用户活跃度、提高应用留存率的常规途径之一，以助于其「更高效地完成运营目标」。推送的技术实现难点自建推送通道主流的推送方案实现，是由客户端和服务端建立一条TCP长连接通道，并由客户端定期向服务端发送心跳包，以保持长连接可用。服务端有消息要推送时，即可通过这个长连接通道直接下发到客户端。然而，要实现这样一套自建推送通道，却没有以上所描述的那样简单。且不说服务端需要应对海量长连

启动阶段的数据同步但凡是社交类或带有一点社交属性的App，其不可避免的一项常规工作就是「好友数据的维护」，常见的好友数据包括但不限于：好友资料更新新增好友申请好友关系变更(密友/拉黑/删除等)…当发生诸如此类的好友数据变动时，通常要求能将变动及时同步到用户端。否则一旦同一好友链上的多个用户的信息不一致，就有可能出现很多莫名其妙的现象。用户在线时，可以考虑直接通过长连接通道下发「控制消息」(如好友资料更新通知、好友关系变动通知等)，主动通知客户端进行相应的数据更新操作。这种做法可以进行较细粒

介绍ACK(Acknowledgement)机制，即确认机制。在即时通讯开发领域，ACK机制是为了应对复杂多变的网络环境，确保消息的可靠投递而设计的。这套机制的核心，是接收方在成功收到消息并正确处理后，需要回复给发送方一个确认应答数据包(ACK应答包)，用来表示消息已确认接收无误。失败重试发送方通常需要在本地维护一个等待ACK的队列，如果在一定时间内未收到指定消息对应的ACK应答包，则会尝试重新发送当前的消息。一般会设置一个重试次数的上限，达到此上限之后就不再发送，转而在客户端显示发送失败的提醒。

「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！前言随着本系列所讨论技术点的逐步深入，仅靠之前提到的官方测试服务器已经不能满足我们演示的需要了，于是我们有必要尝试在本地搭建自己的WebSocket服务器，今天这篇文章就是介绍这方面的内容。由于不属于原先的写作计划之内，同时也为了保持系列文章的连贯性，因此特意将本篇文章命名为「番外篇」。Netty简单介绍还记得前面的文章「Android即时通讯系列文章(2)网络通信协议选型：应以什么样的标准去选择适合你应用的网络通信协议

「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！文章开篇，让我们先来解答一下上篇文章中留下的疑问，即：为什么要设计多个Entity？以「分离关注点」为原则的分层式架构，是我们在进行应用架构设计时经常采用的方案，例如为人熟知的MVC/MVP/MVVM等架构设计模式下，划分出的表示层、业务逻辑层、数据访问层、持久层等。为了保持应用架构分层之后的独立性，通常需要在各个层次之间定义不同的数据模型，于是不可避免地要面临数据模型之间的相互转换问题。常见的不同层次的数据模型包括：VO

「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！前言在前一篇文章《多进程：为什么要把消息服务拆分到一个独立的进程？》中我们出于保证连接的稳定性的目的，将应用拆分成了「主进程」和「通讯进程」，并为二者定义了相互通信的接口。即便如此，我们也只是实现了客户端一侧的进程间通信，而要实现与完整聊天系统中另一端的角色——服务端的通信，则需依靠「网络通信协议」来协助完成，在此我们选用的是WebSocket协议。什么是WebSocket？WebSocket一词，从词面上可以拆解为 Web

「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！这是即时通讯系列文章的第一篇，正式开始对IM开发技术的讲解之前，我们先来谈谈客户端在完整聊天系统中所扮演的角色，为此，我们必须先明确客户端的职责。现今主流的IM应用几乎都是采用服务器中转的方式来进行消息传输的，为的是更好地支持离线、群组等业务。在这种模式下，所有客户端都需连接到服务端，服务端将不同客户端发给自己的消息根据消息里携带的用户标识进行转发或广播。因此，作为消息收发的终端设备，客户端的重要职责之一就是保持与服务端的连接

「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！为什么想要写这个系列的文章？2018年年末，由于所在公司的战略方向转向东南亚一隅，意欲打造一款面向东南亚市场的即时通讯应用，并且高层在综合考量之后决定采用自研技术，于是机缘巧合之下我被安排到IM项目组，从而再次接触到了即时通讯技术。为什么说是再次呢？因为我之前参与开发的两个商业项目同样运用到了即时通讯技术，一个是用到 XMPP+Openfire+Smack，另外一个是用到MQTT，只是当时由于工作经验的关系都只停留在环境的搭建