Android开发需要了解的 IM 知识

引言
即便在通讯如此发达的今天，IM 也依然是诸多场景下非常重要的基础能力。因此做为 一名 Android 开发，不可避免的会遇到一些IM 相关的需求或问题。本文以一个Android开发的角度来讲述IM 开发相关的基础知识。

想要阅读更多技术干货、行业洞察，欢迎关注网易云信博客。
了解网易云信，来自网易核心架构的通信与视频云服务。
IM开发需要面对的问题
网络问题，如何高效快速的传输数据？
协议问题，消息如何封装？
及时性问题，如何进行进程保活？
网络问题
  TCP 的三次握手建立连接是一个非常耗时的过程。在 IM 场景下，数据的传输将会非常的频繁，如果每次传输都建立一个 TCP 连接，那么这个效率是不能接受的，并且频繁的建立连接可能会发生socket错误，所以我们需要 “复用”TCP连接，也就是平时所说的TCP长连接。
TCP 长连接
短连接在建立后，当数据传输完毕时会立即关闭，下次需要传输数据时需要重新建立连接，在日常的业务场景非常常见，比如通过 http/https 请求获取Server 数据。而长连接在传输完数据后并不会关闭，这样下次需要传输数据时就可以直接使用已经建立好的连接，这中间省去了连接建立的时间。但是建立一个 TCP 长连接却并不是“建立后不关闭”那么简单，因为 TCP 长连接会“被动”关闭。
网络地址转换 (NAT)
   IPv4的容量是有限的，随着接入Internet的计算机数量的不断猛增，IP地址资源也就愈加显得捉襟见肘，于是也就产生了 NAT技术。简单来说，NAT就是在局域网内部网络中使用内部地址，而当内部节点要与外部网络进行通讯时，就在网关（可以理解为出口，打个比方就像院子的门一样）处，将内部地址替换成公用地址，从而在外部公网（Internet）上正常使用，NAT可以使多台计算机共享Internet连接，这一功能很好地解决了公共 IP地址紧缺的问题。通过这种方法，可以只申请一个合法IP地址，就把整个局域网中的计算机接入Internet中。

  而我们就处于运营商（移动/联通/电信。。。）的局域网内。当我们接入运营商的网络后，会分配到一个运营商的内部 IP地址，于是我们就可以使用这个IP地址建立连接向外传输数据了。但是当这个IP闲置了一段时间（NAT超时时间）后，运营商为了节约资源，会把分配给我们IP回收掉。此时如果我们还继续使用之前那个未关闭的连接去传输数据，那么毫无疑问会失败的。下面是一些运营商的 NAT超时时间。
网络NAT超时时间中国移动3G/2G5 min中国联通2G5 min中国电信3G大于 28 min
   要想长连接一直有效，那么闲置时间就不能太长，所以在闲置时我们需要向外（Server）传输一些数据包，这也就是常说的“心跳包”，用于告诉运营商这个 IP 还在被使用，告诉Server 客户端还在线。
心跳策略
  心跳策略一般分为两种：
    1. 固定心跳
    2. 动态心跳
这里讲一下固定心跳，动态心跳可以参考 微信心跳 。固定心跳其实就是间隔固定时间发送一个心跳包。

心跳间隔 X 的值需要参考运营商的 NAT 超时时间确定，不能大于最小的 NAT超时时间，也不能太小，要不Server 的负担非常重。一般取一个比较接近最小的NAT超时时间，比如4分钟。
协议问题
   协议决定是消息以什么样的形式传输，即发送时如果对消息进行封装，接收时如何解析。比如可以将消息体以 XML 的形式进行处理，这也就是 XMPP 协议，参考下面一个消息示意：
隔壁老王：你儿子长的比你帅多了。
老李：嘿嘿，谢谢夸奖！
<message>

<from>隔壁老王</from>
<to>老李</to>
<context>你儿子长的比你帅多了。</context>
<type>text</type>

</message>

<message>

<from>老李</from>
<to>隔壁老王</to>
<context>嘿嘿，谢谢夸奖！</context>
<type>text</type>

</message>
  从上面的消息示意，我们可以发现一条消息的内容可以拆分成很多属性，而协议就是把这些属性组合起来。
以 XML 的形式传输消息，最大的一个问题，就是冗余数据太多了，特别是当消息的属性比较多时。
  那么有没什么格式能尽可能有减小冗余数据？
  其实无论消息如何封装，最终传输的肯定是二进制流，那么完全可以直接用二进制的形式对消息进行封装，这也就是二进制协议。下面是一个简单二进制协议的实现示意。

  一条消息由from + to + context + type这几个属性组成，那么我们完全可以按顺序存储在二进制中，由于内容长度不确定，所以每个属性的开头我们可以使用固定字节数来记录这个属性的内容长度。当然，这里只是展示了一个二进制协议的例子，实际的消息会比这复杂多了，但是核心思路就是这么简单，最终无非是设计与实现形式上的差距。
及时性问题
  IM的作为即时通讯，如果无法保证消息及时触达，那么意义就大打折扣。要保证消息及时触达，最关键要做到以下两点：
   1. App 进程要尽量存活，也就是进程保活 ；
   2. 在 App进程挂掉后，能够唤醒起来；
进程保活
  进程保活其实是属于 Android 平台的一个话题，相信大家日常开发也遇到过，细节就不在这长篇大论了，简单的说下几个原则：
   1. 优化内存，减小内存的占用，会大大的减小被 kill 的机率；
   2. 多进程，将 UI 进程与 IM 进程独立出来，这样 IM 的进程负担就会小很多；
进程唤醒
  严格意义上来说进程唤醒是属于进程保活的一个分支，这里单独列出来，是因为进程唤醒关注的是进程挂掉之后的动作。对于进程唤醒，这里也只列些原则，详细的可以去查阅相关资料。
   1. 静态注册监听广播（<7.0）
   2. Alarm定时任务，定时去检查进程是否存活。
   3. JobScheduler定时任务，定时去检查进程是否存活( >5.0 )
   4. 接入厂商推送
网易云信（NeteaseYunXin）是集网易18年IM以及音视频技术打造的PaaS服务产品，来自网易核心技术架构的通信与视频云服务，稳定易用且功能全面，致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API，即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。