Mobile IM Development Guide 3: How to optimize login modules

The Mobile IM Development Guide Series article will cover all aspects of an IM app, including technology selection, landing optimization, and more. In addition, the author will combine his experience in the development of iOS IM SDK in netease Cloud For many years, in-depth analysis of various common problems in real development.

Recommended Reading

Mobile IM Development Guide 1: How to choose a technology

Mobile IM Development Guide 2: Heart rate Instructions

In the mobile IM module, the most complex module of the core is the login module. A login module that has not been well-optimized often takes a long time and wastes traffic: a single login is a short 10 seconds, a few minutes long, while synchronizing hundreds of KB or even a few m of data.

A simple login step can be divided into the following steps:

L Request lbs

L Connect Link

l Send and receive login requests

L Synchronous IM Data

And every step here is a possibility of optimization. (In fact, many of the following ideas are universal, not only the IM APP can be used)

Optimize LBS requests

In the PC era, we tend to request lbs and connect the server to do a series, after all, only after the request is completed lbs can get the real link server address, so as to connect operations. In the specific operation, the general LBS request is an HTTP request, where the time-consuming imaginable. So a simple optimization idea is to remove this link from the login process.

However, direct rough removal of lbs request is not advisable, if we directly built-in domain name or IP, bring the biggest problem is naturally unable to do load balancing. Therefore, it is more recommended to asynchronously send the LBS request: Do not do the LBS request at login, while the network is idle and change the request and cache, each login is directly from the local cache to get the link address.

DNS optimization

The use of TCP will inevitably encounter the problem of DNS resolution, after all, we can not always use IP as the server address. In the PC age, DNS parsing is hardly a bother. However, after entering the wireless era, DNS-related problems are becoming more and more serious. On the one hand, in the mobile network, DNS resolution is extremely fast, the time of DNS resolution can even catch a TCP connection time, a few seconds, more than 10 seconds, or even three, 40 seconds of request time are very common. On the other hand, because of the operator's omission and act, the DNS of the mobile network also presents low resolution accuracy and is often hijacked state.

There are also many open-source implementations, such as Httpdnslib, that you can consider using HTTP Dns,github for these scenarios. The most radical approach is naturally the same as the previous optimization lbs, in each link to avoid DNS parsing:

L LBS returns the server IP instead of the domain name

L Local cache lbs IP address standby, request lbs priority use IP instead of domain name

This method can not only avoid the time-consuming of DNS request, but also can evade the problem of DNS hijacking to some extent. The disadvantage is that the client needs to consider a series of other problems: How to choose a valid address from the IP list, determine the timing of re-request, load balance, save traffic and so on.

Login Request

In fact, the login request link actually does not have much to optimize the space. Once you are connected to the server, the next thing to do is to encrypt the current connection and send and receive login feedback. These two steps are indispensable. And how optimization is often related to the specific business: if we use an HTTPS-like three-step negotiation encryption process, security can be guaranteed, but one back too many times, the entire login time will increase. The trickery approach is to combine encryption and login requests, which often involves the modification of login requests.

Synchronization policy Optimization

After logging in, the client needs to synchronize from the server, and a regular IM APP needs to synchronize the following data:

L Friends List

L Friends Personal Information

L Group List

L Group Members List

L Group Members Personal information

L Offline messages

Assuming that a user has 1000 friends, 20 50 people, and an average of about 200 bytes per item, then a full sync takes approximately 0.2 * (+ + + + + + 2) = KB of data, which is unacceptable for a mobile IM , not to mention the amount of data that is a slightly lighter user.

Obviously full synchronization is unacceptable, and the improved method is naturally synchronized by timestamp. The client always updates only new data than the locally cached data. This is a general optimization direction, and there are optimizations that can be implemented based on business requirements: Deferred updates and on-demand updates. Take the group member personal information for example, in fact, the user does not care about its real-time, after all, these group members are not necessarily user friends, their information changes can be completely in the user to review the update (the strategy). And friends personal information is the same, for most of the interface, they only care about the user Id, Avatar and nickname of the three basic information, and some icing on the profile information can be a user to view the appropriate interface when the time-stamped update.

Mobile IM Development Guide 3: How to optimize login modules