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

，事实上，这也是即时通讯（软件）领域主流甚至唯一的实现方法。

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 厂商的红线，如果系统一定要杀进程