在移动 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 选择有效地址，确定重新请求时机，负载均衡，节约流量等。
默认
首页
