Android即时通讯系列文章(0)起源：对接触工作以来所涉及过

为什么想要写这个系列的文章？

2018年年末，由于所在公司的战略方向转向东南亚一隅，意欲打造一款面向东南亚市场的即时通讯应用，并且高层在综合考量之后决定采用自研技术，于是机缘巧合之下我被安排到IM项目组，从而再次接触到了即时通讯技术。

为什么说是再次呢？因为我之前参与开发的两个商业项目同样运用到了即时通讯技术，一个是用到 XMPP+Openfire+Smack，另外一个是用到MQTT，只是当时由于工作经验的关系都只停留在环境的搭建和API的调用，并没有很深入地去挖掘更底层的技术原理。而现在项目采用的则是WebSocket——提供客户端和服务端全双工通信(即双方可同时向对方发送消息)的一种应用层协议。接触过的同类技术多了，自然免不了会去比较三者之间的优劣。而我正是以此为切入点，在工作之余对接触工作以来所涉及过的即时通讯技术进行了全面复盘。

大到网络通信协议、数据传输格式的选型，小到消息实时性、一致性的保持，从在线、离线推送到多端同步、消息漫游，即时通讯技术的博大精深无不令我啧啧称奇，从而得以以更高的架构师的角度去审视当时是为什么这样设计的，做到理论知识与代码实践的一一对应。也理解了即时通讯技术作为的底层架构，为带有社交属性的应用提供实时互动功能的价值所在。

而随着现在项目稳定迭代到了3.x的版本，即将把IM模块剥离出来作为独立SDK接入到新项目，我也得以回顾之前的写的代码并进行适度优化。并想以此为契机，将学习过的知识以技术博客的形式进行输出，强迫自己把知识点组合起来，从而对即时通讯技术有更透彻的理解，促使自己变得更专业。之前写的几篇技术文章，只是作为重新回归撰写技术博客的练手之作，而完整出一个系列的文章则一直是我想要达成的一个成就，希望我能坚持下去。

看这个系列的文章你可以得到什么？

由于我本身是Android开发者，因此我的文章会更多地以Android开发或客户端开发的角度去讲述，对于服务端高并发、高可用等场景，因为不属于我的专业范围内所以我也不会展开来讲。除了会普及一些业内普遍认同的、具有通用性的技术方案外，还会就这些方案在移动设备上实现的局限性进行具体分析。众所周知，客户端作为收发消息的终端设备，是直接面向用户的，但是移动设备又是资源受限的，这意味着在移动设备上实现体验良好的即时通讯功能是极富挑战性的。我会在文章中把我实际开发中遇到的困难跟你阐述，希望我踩过的坑你不会再次踩到。

由于是第一次写系列文章，而即时通讯又是一门比较庞大的技术，所以我暂时不会把整个系列所有要写的东西全部罗列出来，当然还是初步列了要切入的几个点，并计划就一个点写对应的一篇文章，后面如果看哪一个点可以单独摘出来讲述的话我会继续补充，目前规划的几篇文章包括：

• 多进程：为什么要把消息服务拆分到一个独立的进程？ （已发布）
• 数据传输格式选型：资源受限的移动设备上数据传输的困境（已发布）
• 网络通信协议选型：应以什么样的标准去选择适合你应用的网络通信协议？（已发布）
• 网络保活：复杂多变的移动网络下保持全时在线的艰难
• 进程保活：与日渐封闭的Android系统不断地抗争与妥协
• 消息推送：碎片化的Android系统如何提升离线状态下消息的可达性
  ...
  以上基本是接触客户端IM开发会面临的一些问题，如果你是刚开始IM开发的新手，相信这些文章会对你有所帮助，希望你在看完每一篇文章之后都能融入自己的思考，并能实际运用到自己的业务中去。