作者：项望烽

网易杭州研究院·网易云信 iOS端负责人

【往期回顾】项望烽：移动 IM 开发之心跳

源起

在移动 IM 模块中，最核心最复杂的模块莫过于登录模块。一个没有经过很好优化的登录模块往往耗时久且浪费流量：一次登录短则数十秒，长则几分钟，同时同步下几百 KB 甚至几M的数据。

一个简单的登录步骤可以分为如下几步：

• 请求 lbs

• 连接 link

• 收发登录请求

• 同步 IM 数据

而这里的每一步都是有优化的可能性。(事实上下面的很多思路都是普适的，不是只有 IM APP 才用得到)

优化 lbs 请求

在 PC 时代，我们往往将请求 lbs 和连接服务器做一个串联，毕竟只有先请求完毕 lbs 才能够拿到真正的 link 服务器地址，从而进行连接操作。在具体操作上，一般 lbs 请求就是一次 HTTP 请求，这里的耗时可想而知。所以一个朴素的优化想法就是从登录流程中移除这个环节。

然而直接粗暴去除 lbs 请求并不可取，如果我们直接内置域名或 ip，带来最大问题自然是无法做负载均衡。所以更推荐将 lbs 请求异步化：不在登录时做 lbs 请求，而在网络空闲和发生变化时进行请求并缓存，每次登录则直接从本地缓存获取 link 地址。

DNS 优化

使用 TCP 时不可避免会碰到 DNS 解析的问题，毕竟我们不可能一直使用 IP 作为服务器地址。在 PC 时代，DNS 解析几乎不费事。但进入无线时代后，DNS 相关问题越来越严重。一方面，在移动网络下，DNS 解析速度无比龟速，一次 DNS 解析的时间甚至能赶上一次 TCP 连接的时间，几秒，十几秒，甚至三，四十秒的请求时间都很常见。另一方面，由于运营商的不作为和作为，移动网络下 DNS 也呈现了解析准确度低和经常被劫持的状态。

针对这些情况可以考虑使用 HTTP DNS，github 也有很多开源的实现，比如HttpDNSLib。而最激进的方法自然是像前面优化 lbs 一样，在个个环节中避免 DNS 解析：

• lbs 返回服务器 ip 而非域名

• 本地缓存 lbs ip 地址备用，请求 lbs 时优先使用 ip 而非域名

这种方式不仅可以避免 DNS 请求的耗时，也可以一定程度上规避 DNS 被劫持的问题。而弊端是针对这种情况需要在客户端考虑一系列的其他问题：如何从 ip list 选择有效地址，确定重新请求时机，负载均衡，节约流量等。

登录请求

事实上，登录请求环节其实并没有多大的优化空间。一旦你连接上了服务器，接下去要做的事无非是加密当前连接和发送并接收登录反馈。这两步缺一不可。而如何优化又往往会和具体的业务相关：假如我们使用类似于 HTTPS 一般的三步协商的加密流程，安全性的确可以得到保证，但是一来一回的次数过多，整个登录耗时就会增加。取巧的方法自然是将加密和登录请求合并，而这往往会涉及到对登录请求的改造。

同步策略优化

登录完毕后，客户端需要从服务器同步，一个常规的 IM APP 需要同步如下数据：

• 好友列表

• 好友个人信息

• 群组列表

• 群成员列表

• 群成员个人信息

• 离线消息

假设一个用户有 1000 个好友， 20 个 50 人群，平均每一项大约 200 个字节，那么一次全同步大约需要 0.2 * (1000 + 1000 + 20 + 1000 * 2) = 800 KB 的数据，这对于一个移动 IM 是无法接受的，更何况这还是一个较轻度用户的数据量。

显然全同步是无法接受的，改进的方法自然是按时间戳同步。客户端永远只更新比本地缓存数据新的数据。这是一个常规的优化方向，还有一些根据业务需求可以实施的优化：延迟更新和按需更新。以群成员个人信息为例，其实用户并不关心其实时性，毕竟这些群成员并不一定是用户好友，他们的信息变动完全可以在用户进行查看时再更新（微信的策略）。而好友个人信息也是同理，对于大部分界面而言，他们只关心用户 Id，头像和昵称这三个基础信息，而一些锦上添花的 Profile 信息完全可以在用户查看相应界面时进行一次按时间戳的更新。

· END ·

【精彩回顾】

项望烽：移动 IM 开发之心跳

项望烽：移动IM开发那些事儿

项望烽：iOS App开发那些事儿

网易云信|真正稳定的IM云服务

http://netease.im  长按关注，干货不断