“Android instant messaging development summary” based on IM Andriod development of various common problems, combined with the practice of netease yunxin instant messaging technology, IM development to do a comprehensive summary.
Recommended reading
Android Instant Messaging
Mobile IM Development Guide 1: How to select technology
Mobile IM development Guide 2: Heartbeat instructions in detail
Mobile IM Development Guide 3: How to optimize the Login module
Establishing a Secure Connection
Security is another hard requirement for IM software. If communication data is intercepted by a third party during message transmission, ensure that no one else can obtain the real content. In the secure connection process, the server sends the certificate to the client using HTTPS. The client generates a symmetric key, encrypts the key using the server certificate, and sends the key to the server. All subsequent communications are encrypted using the symmetric key. However, there are two differences between HTTPS and HTTPS. The first one is how to obtain a certificate. In HTTPS, a special institution verifies the validity of the certificate, but the IM client does not do this. The possible method is to type the certificate directly into the client installation package. The certificate can be upgraded with the client software upgrade or through the protocol upgrade after the encrypted connection. The second problem is the choice of symmetric encryption algorithm, because the life cycle of the key follows a connection and the time is not long, and mobile App is very sensitive to power consumption, so the encryption algorithm should try to choose a relatively simple type, such as RC4.
Heart jump
The heartbeat can be divided into TCP protocol-layer heartbeat and App application-layer heartbeat. We usually use application-layer heartbeat, both for server scalability (for example, someday we can switch to UDP) and for more flexibility in heartbeat interval control.
The heartbeat protocol is only used for connection keepalive, and its content should be simplified as much as possible. The optional header of the packet body does not exist except the necessary part of the packet header.
For different network environments, the heartbeat interval can be different. In different network environments, you can refer to wechat intelligent heartbeat scheme for interval selection.
Break line reconnection
There are two reasons for a client connection failure: the client network is down, and the server is down. There are two types of client network failure. One is that the local computer can sense the network disconnection, and the other is that the local network is good, but the Internet connection is different, which correspond to the Android API, namely, NetworkInfo isAvailable and isConnected. Of course, the isConnected of this place may not be reliable, because it is determined by connecting to the formulation server, who knows whether there is a problem with that server.
After the offline, different reconnection intervals are selected according to different state requirements. If the local network fails, you do not need to periodically disconnect the network. In this case, you only need to monitor the network status and reconnect the network after it recovers. If the network changes very frequently, especially when the App is running in the background, certain frequency control can be added for reconnection, so as to ensure the real-time performance of certain messages and avoid excessive power consumption.
If the connection is down because the local network is disconnected from the Internet, or the server is down, the choice of reconnection interval is very important.
First of all, if the program is in the foreground and users are using our App, the reconnection interval should be more frequent to make users’ feedback more timely. If the program is running in the background, the reconnection interval can be appropriately extended to save electricity.
Second, as the number of reconnections increases, the likelihood of a server recovering in a short time decreases, and the reconnection interval should also be extended (multiple increase). However, a maximum reconnection interval should be set, and when the maximum interval is reached, it will not be increased.
Third, the increase in the reconnection interval should not be fixed, but a random retreat strategy should be added. Otherwise, if the server goes offline due to a server breakdown, the reconnection time of all clients is the same. After the server recovers, all clients connect to the server at the same time, causing the server to break down again. Live examples please refer to last year’s outage of huanxin.
To sum up, the reconnection interval can be expressed as follows:
Multimedia data Management
Another big deal in IM systems is multimedia data. Because the mobile network is relatively slow, and the traffic is expensive, in the mobile end to deal with these problems must be done. In the upload, as far as possible to reduce the upload time, when downloading, so that users can see the content as soon as possible. At the same time, try to save traffic, reduce unnecessary traffic consumption.
Text messages can be transmitted directly over long connections because they are small. However, it is not suitable for multimedia files to be transmitted through long connection. The long connection server will not optimize the transmission of large files, and a large amount of multimedia file data will directly preempt the loan resources of other signaling messages and text messages. Therefore, multimedia messages are accessed through a separate channel to a dedicated file server.
Different prefetch policies can be used for different network environments. With WiFi, we don’t have to worry about traffic, so we can download the multimedia files as soon as we receive them. On a mobile network, you should wait until the user actually sees the multimedia message before downloading it.
image
When uploading, the pixel of mobile phone camera is often tens of millions, and a picture can be several meters easily. However, the quality requirements of pictures transmitted through IM software are not too high. If we directly upload several meters of pictures, it is often laborious and unpleasing. Before uploading, the image pixel is reduced and compressed, which can significantly reduce the time of uploading to chrysanthemum and reduce user traffic consumption. If the user does require image quality, an original image option is provided.
If HTTP is used, large files are divided into multiple data blocks to be uploaded. After the first data block is successfully transferred, the next data block is transferred. When retransmission is interrupted, data blocks are also used as the minimum weight flyer element. The data block size varies according to network types. In a good network (wifi/ 4G / 3G), the data block can be relatively large, which can reduce the interaction time and speed up the transmission perusal, while in a weak network environment, the data block should be set relatively small to reduce the probability of transmission failure and reduce the retransmission traffic consumption.
Another optimization technique for using HTTP uploads is the use of pipelines. Without pipeline, a block is uploaded until the previous block is successfully transferred, and the data channel is simplex. Pipeline can turn the data channel into duplex. After a data block is transmitted, the next data packet can be directly uploaded without waiting for packet return, which can save a data packet return delay.
When downloading, the message display area usually displays only a small image. In this case, you only need to download the thumbnail of the corresponding size instead of downloading the original image. Even smaller than the thumbnail image binary data can be directly sent into the message body, and a Gaussian blur effect is shown to the user, while ensuring the minimum availability, reduce the user wait time, improve the user experience.
pronunciation
For different network environments, different quality speech coding algorithms are adopted. In a good network, high-quality speech is used, while in a weak network environment, low quality speech is used to ensure availability first.
In order to reduce the user waiting time, you can also use the strategy of recording and sending. Because the recording time is relatively long, in the recording process, we can first transmit the recorded part to the server. When the recording is completed, we only need to upload the last data packet and inform the server that the recording is completed. Basically, we can complete the recording immediately without waiting.
Voice messages don’t have thumbnails, so voice downloads are basically just the original file.
The above is netease Yunxin for Android instant messaging development summary, welcome to actively ask questions, common discussion.