融云杨威：移动IM服务如何做到极致优化

美通社-- 近日，全球知名技术媒体InfoQ专访了融云技术副总裁杨威。以下是访谈全文，原文出自InfoQ中文站：

目前，随着移动应用的泛社交化，移动即时通讯（IM）第三方服务被越来越多开发者所接受。对于这类服务，功能和稳定性是开发者关注的重点，但在此之外，性能和体验也是非常重要的因素。InfoQ 记者对融云技术副总裁杨威进行采访，探讨了移动 IM 服务如何做到性能和体验上的极致优化。

受访嘉宾介绍：

杨威，融云技术副总裁，移动通信技术专家，智能终端软件研发专家。北京邮电大学通信工程系学士和硕士学位，长期从事智能移动终端上的软件开发工作，曾在 三 星中国通信研究院工作八年。曾负责第三方软件的本地化开发工作，如高德导航等软件在全部中国三星终端上的商业化过程。曾作为项目经理领导了包括 Galaxy Note 在内等多款商业智能终端的研发和商业化项目工作。作为三星融合通信/RCS产品线研发总负责人和技术专家，参与了中国移动融合通信产品规范的整体设计，带领团队设计了三星 RCS、VoIP/VoLTE 产品线的软件架构，并负责研发和团队管理工作。

InfoQ： 请介绍一下融云在哪些方面做了性能和体验优化？是否设立了性能指标？

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

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

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

杨威： 对于通讯协议，可能不了解的人觉得它很神秘，但像我们这种整天面对它们的人觉得并没有什么特别的地方。用通俗的话来讲，就是两者之间制定一条规则，然后遵守这个规则我把一个东西传给你，你确认收到了，这个规则就是通讯协议。在通信、电信行业里，比较常 用 的 IM 协议可以举三个例子：
第一类常用的是 SIP/SIMPLE 等协议，这个在电信网络用的比较多，包括全球运营商都在推广的下一代融合通信。这类协议的特点是非常健壮， 但 是规范非常复杂，光是看英文规范文档可能就要学习一两年，它能够让信息在通信节点之间传输得到很好的安全保障，非常高的互通行，扩展性，同时在私有部署 的时候也可裁剪，所以实际上现在仍然非常多的业务在使用这类协议。

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

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

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

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

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

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

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

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

杨威： 第一点是数据包尽量小，第二点是我们尽量不分包，一次传输完所有信息，我们目前服务的使用场景，用户 发 送的信息往往比较短的，第三点是链路尽量短，服务器对数据做完处理后就发出去，一些阻塞的操作都是异步进行的，另外一些比较耗时的处理我们会放到客户 端 ，第四点是"先收先发"，比如说在客户端，收到消息之后马上把它展现出来，然后再做其他操作。比如图片这类收发比较慢的消息，我们会优先展示，然后异步 再 收发。

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

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

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

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

杨威： 有用户对我们总结说，融云最大的价值就是提供了一个稳定的长连接，用这个长连接其实可以干很多事。我 们 认为融云最大的价值是服务，客户想到的点子我们可以快速的研发和实现业务。群众的力量是无穷的，我们的用户发掘了很多以前我们从来也想不到的用法。比如 做 视频直播、发信令（遥控器）、弹幕，还有做像滴滴打车一样的实时地理位置共享。像微信一样的聊天界面很容易相信，但很多应用场景的界面完全都不是 IM， 但 其实他就是 IM。比如滴滴打车的首页，因为你可以想一下它那个界面，每个车都定时发送自己的地理位置，然后一起显示，其实原理和聊天室是一样的。我们经 常 和用户沟通，也为这些场景做了很多优化，举个例子，比如视频直播的聊天室，我们之前做 得 比较简单，就是满足了收发信息的需求，但是有些做视频直播的开发 者 还希望有排队、进场顺序等等，对于有些客户，我们会为它做一个定制版系统，有些如果是非常好的建议，我们也会吸收到我们的主系统里面。