专访融云杨威：移动端即时通讯服务如何做到极致优化

杨威：因为融云提供的是面向开发者的云服务，我们十分重视性能和用户体验。我们在提供即时通讯服务上有三个 基本原则：节省客户的资源，让客户可扩展和可定制，和提供尽量好的功能质量。根据这三个原则我们其实是有一些指标的，我们内部比较关注5个性能指标，分别 是流量、电量、速度、质量和包大小。

不过，在很多时候这些指标之间其实是互相矛盾或者冲突的，所以需要权衡，不可能在每一个方面都做到完美。

目前市面上比较主流的通讯协议有哪些？融云在通讯协议方面做了哪些优化，和业界主流或标准相比有哪些优势？

杨威：对于通讯协议，可能不了解的人觉得它很神秘，但像我们这种整天面对它们的人觉得并没有什么特别的地方。用通俗的话来讲，就是两者之间制定一条规则，然后遵守这个规则我把一个东西传给你，你确认收到了，这个规则就是通讯协议。在通信、电信行业里，比较常 用的 IM 协议可以举三个例子：

第一类常用的是 SIP/SIMPLE 等协议，这个在电信网络用的比较多，包括全球运营商都在推广的下一代融合通信。这类协议的特点是非常健壮， 但是规范非常复杂，光是看英文规范文档可能就要学习一两年，它能够让信息在通信节点之间传输得到很好的安全保障，非常高的互通行，扩展性，同时在私有部署 的时候也可裁剪，所以实际上现在仍然非常多的业务在使用这类协议。

第二类常用的就是 XMPP 协议，XMPP 是互联网开源标准的典范。常用的还是C/S 架构。XMPP 协议的初衷是为互联网设计的一套协议，基于 XML 协议，是可扩展的，所以理论上你可以将它扩展和配置成你想要的业务。但是，XMPP 协议是基于互联网早期标准所衍生的，所以它在某些特性上是不适合 移动端的，更适合于 PC 端，比如它的数据包比较大，另外在断线重连上做的也不够好。一般来讲，我还是推荐初学者用 XMPP 来搭建系统，因为有非常丰富的开 源资源，但往往在一段时间之后你会发现进入瓶颈，比如丢消息，延迟响应慢等等，根源还在于 XMPP 机制上更多的还是考虑了稳定的网络环境设计的。XMPP 虽然是开源的软件，开源代表免费，但开源不代表不需要花时间，很多时候为了解决一个小小的问题，你必须通读它的源代码，你才知道问题出在哪里，如何解决。 我们接触了很多客户，都是因为解决不了开源协议带来的复杂问题而重新改变了方案。

第三类常用是物联网协议，比如目前比较知名的 MQTT 协议，这是 IBM 开发的一款支持多平台的，非常节省资源的一套通信协议。这类协议的特点就是预设场景很简单，发送和接收信息都是一次，报文尽量简短。融云在设计自己的协议 的时候参考了物联网协议，当然，我们也参考了其他业界比较优秀的协议，比如我们还要发送图片、多媒体内容，所以加了很多自己的业务模型在基本协议里。

这第三类例子，其实代表的是业内很大一部分的通讯协议，即各个公司私有定制的通信协议，从互联网早期的雅虎，MSN，到移动互联网时代的微信， 它们其实都是私有协议。这些私有协议支撑的是一种 OTT 业务，跨过电信运营商来提供即时通讯服务。移动互联网时代，App 开发者和他们的用户们其实并不需 要关心底层是怎么实现的，只要一个用户能和另一个用户发送信息就可以，对于这样的场景，其实根据它们的需求定制一套私有协议是最好的，事实上，这也是即时通讯（软件）领域主流甚至唯一的实现方法。

你们在省电上做了哪些优化？

杨威：省电也是开发者和用户比较关心的问题，特别是安卓平台。电量问题分为两类，一类是前台耗电，就是应用 启动时消耗的电量，另一类是后台耗电，就是应用被关闭或屏幕熄灭时候的耗电。前台耗电的主要指标是：1)流量，2)内存，3）方法。第一在手机上，当我们 在使用数据网络传输时的耗电量是使用Wi-Fi或者不使用网络时候的几倍到上百倍之间，因为通信芯片的功耗是非常高的，所以减小流量就是减小电量的消耗， 同时还有减少通信次数，同样的留言，发送两次和发送一次，电量消耗其实差别很大；第二就是内存，尽量不使用压缩算法和其他消耗内存大的方法，消耗内存越 大，使用内存越频繁，耗电量也越高。这里提到压缩算法，其实就是指标冲突的一个例子，像你用压缩算法将内容体积减少一半，流量减少一半，但是使用内存多 了，增加了耗电量，这是个度的问题，如何选择，需要反复的测试和调整。因为我们传输的数据本来就是二进制数据，压缩作用不大，所以选择不压缩。最后就是流 程问题，不必要的操作和数据会加大耗电量。在序列化和反序列化方面我们使用 JSON 和 protobuffer，这是谷歌官方推荐的省流量省内存的方法，当 然这也是业内比较通用的方案。

还有后台耗电，IM 类服务在后台时为了保持长连接，需要向服务端发送心跳包。这里我们除了做了减少心跳包大小这样常规的优化以外，还做了智能心 跳的优化，在不同的网络条件下发送心跳的间隔时间不同，比如2G连接和响应速度慢，会消耗更多的电量。这里面的很多数据其实是一种“Magic Number”，因为这是根据大量的经验和测试数据对比，以及内部的数据得到的，并经常调整。

最后其实很多用户都有一个误区，因为安卓手机比较耗电，其实根据我们的测试，后台耗电其实还是远远小于前台耗电的。耗电往往是因为手机软件有各 种bug。一些开发者会觉得 IM 类的软件比较耗电，其实 IM 类的软件一定是相对最耗电软件品类，因为你要不断跟其他人保持通信，如果其他软件耗电超过了 IM 软件，那才是问题。之所以大家觉得安卓手机后台耗电大的原因，一是因为手机上不止装一个 IM 软件，二是不光IM软件发心跳，其实所有的app都在做类 似的事情，融云作为开发包的提供者，每个版本都会对电量和流量进行监控和测试，我们对此会比应用开发者付出更多的努力，也会有更强的保证。

你们在快速响应和传输速度上做了哪些优化？

融云在 SDK 上是否做了多路复用，安卓后台服务如何防杀死？

杨威：多路复用是肯定的，如果后台有多个使用我们SDK的应用在运行，我们可以保证它们同时只使用一个心 跳。另外还有一个方面，就是我们在后台其实是需要保持两个通道的，一个是 TCP 的长连接，就是 IM 的，另外还有一个推送的长连接。对于移动 IM 来说，推送 是必须要有的，因为手机熄屏后其实后台的服务已经停止工作了，只有推送能够提醒用户有新消息。对于这两个通道，我们也将它合并为一个心跳，只需要一个心跳 就可以保持和服务端的两个长连接。另外在前台，我们的多路复用使用进程池，保证多条消息的收、发能够同时进行，这些进程池在使用后也会回收掉。总之就是， 能少发出一个心跳消息，我们尽量少发出去一次，同时还要一定确保通信链路的稳定。

至于后台进程防杀这是个比较敏感的问题，因为现在用户不喜欢有一堆进程在后台消耗它的电量，而且国内的各个 ROM 厂商也在这方面做了一些工作， 有些应用长时间占用系统资源的做法可能会被封禁。以前业内一般常用的做法是做了很多技术性工作来保证后台进程永远杀不死，因为唤醒率对于很多App厂商都 是很重要的评测指标，把后台杀死消息就收不到了。不过融云作为一家服务提供商，我们优先还是要对客户负责，因此所有的灰色地带都是不碰的，我们现在的 SDK 默认设置是一定不触犯系统或者 ROM 厂商的红线，如果系统一定要杀进程还不想你重启，那我们的后台就不再启动，我们一定优先遵从手机操作系统的规 定，也就是用户的意愿。

融云用户目前有哪些使用场景，针对这些场景做过哪些优化？