谈谈移动端 IM 开发中登录请求的优化

作者：项望烽，毕业于浙江大学，目前是网易云信 iOS 端研发负责人。

1、前言

到底是“登陆”还是“登录”？这是很多处女坐开发者纠结的问题，不过它不是本文本讨伦的内容。本文将针对移动端IM的登陆功能给出相应的优化建议。

关于移动端网络的优化手段总结性文章可参见《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》、《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》、《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》、《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》。。

2、源起

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

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

• 1）请求 lbs；
• 2）连接 link；
• 3）收发登录请求；
• 4）同步 IM 数据。
  

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

3、优化负载均衡 LBS 请求

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

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

4、DNS 优化

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

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

• 1）lbs 返回服务器 ip 而非域名
• 2）本地缓存 lbs ip 地址备用，请求 lbs 时优先使用 ip 而非域名
  

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

有关移动端网络的DNS各种杂症，你还可以读一读：《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》。

5、登录认证请求优化

事实上，登录认证请求环节其实并没有多大的优化空间。一旦你连接上了服务器，接下去要做的事无非是加密当前连接和发送并接收登录反馈。这两步缺一不可。

而如何优化又往往会和具体的业务相关：假如我们使用类似于 HTTPS 一般的三步协商的加密流程，安全性的确可以得到保证，但是一来一回的次数过多，整个登录耗时就会增加。取巧的方法自然是将加密和登录请求合并，而这往往会涉及到对登录请求的改造。

6、数据同步策略优化

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

• 1）好友列表；
• 2）好友个人信息；
• 3）群组列表；
• 4）群成员列表；
• 5）群成员个人信息；
• 6）离线消息。
  

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

显然全同步是无法接受的，改进的方法自然是按时间戳同步。客户端永远只更新比本地缓存数据新的数据。这是一个常规的优化方向。

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

7、作者的其它文章

• 《基于TCP协议的移动端IM仍然需要心跳保活机制》
• 《移动端IM开发需要面对的技术问题》
• 《iOS端移动网络调优的8条建议》
  

（原文链接：点此进入）

附录：更多相关文章

1）关于网络通信的基础文章：

• 如果您对网络通信知识了解甚少，建议阅读《网络编程懒人入门系列文章》、《脑残式网络编程入门系列》，更高深的网络通信文章可以阅读《不为人知的网络编程系列文章》。
  

2）涉及移动端网络优化的文章：

• 《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
• 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》（推荐）
• 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》（推荐）
• 《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》
• 《美图App的移动端DNS优化实践：HTTPS请求耗时减小近半》
• 《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》（推荐）
• 《百度APP移动端网络深度优化实践分享(二)：网络连接优化篇》（推荐）
• 《百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇》
• 《爱奇艺移动端网络优化实践分享：网络请求成功率优化篇》（推荐）
• 《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
• 《谈谈移动端 IM 开发中登录请求的优化》
• 《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
• 《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
• 《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
  

3）如果您觉得有些网络问题，已无法从应用层找到答案，那么以下这个系列是你的“菜”：
    以下文章为IM/推送技术开发的边界知识，但有助于你从物理层理解各种网络问题。如无兴趣，可忽略之！

• 《IM开发者的零基础通信技术入门(十一)：为什么WiFi信号差？一文即懂！》
• 《IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
• 《IM开发者的零基础通信技术入门(十三)：为什么手机信号差？一文即懂！》
• 《IM开发者的零基础通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》
  

准确地讲，这两步：
1）连接 link
2）收发登录请求

如果能在一个即时通讯连接的过程中也同时完成登陆请求，那就不就能合并成一步了？

文章里的LBS，跟普通的HTTP类LBS不一样。准确地讲，应该只是LBS前置服务器，目的是为客户端维护可以连接的目标服务器列表，本身不提供即时通讯服务，客户机的即时通讯只能跟某台机器一对一才可（因为即时通讯需要双向通信），这是跟传统单向c/s或b/s模式的单向服务不一样的（传统单向服务只能由Client主动发起）。

请教一个问题：用户获取到服务list后，直接连接其中一个，但是服务器怎么知道当前连接是哪个用户的连接

引用：慢慢行 发表于 2021-01-04 22:22
请教一个问题：用户获取到服务list后，直接连接其中一个，但是服务器怎么知道当前连接是哪个用户的连接

这需要服务端有个用户和连接的map表

感谢分享，目前正在做服务器登录优化，受教了。

引用：JackJiang 发表于 2021-01-04 23:30
这需要服务端有个用户和连接的map表

好的 谢谢楼主

引用：慢慢行 发表于 2021-01-04 22:22
请教一个问题：用户获取到服务list后，直接连接其中一个，但是服务器怎么知道当前连接是哪个用户的连接

服务端仅返回一个可用IP，具体选择那个IP可由服务端判断返回。

除了每次登录成功后的数据同步，也可以在用户在线时，直接通过长连接通道下发「控制消息」(好友资料更新通知、好友关系变动通知等)，触发客户端更新本地缓存数据吧。这样就可以进行较细粒度的更新，更及时，也减少了下次数据同步的数据量。

引用：椎锋陷陈 发表于 2021-11-03 10:14
除了每次登录成功后的数据同步，也可以在用户在线时，直接通过长连接通道下发「控制消息」(好友资料更新通 ...

说的对