For mobile apps, IM functions are becoming more and more important, which can create connections between people. In social products, communication between users can produce better user stickiness.
In the complex Android ecosystem, a variety of factors can cause the message push to fail to reach the client in time. In addition, the unstable mobile network also adds obstacles to the speed and reliability of data transmission.
This article explains in detail the exploration and experience of NetEase Yunxin IM SDK in dealing with weak network environment, mobile terminal hardware restrictions and the complex ecological status of Android. How to achieve the background live without affecting the user experience, the improved long connection plus push combination scheme, and the optimization practice of large data transmission in weak network environment.
Recommended reading:
Netease Yunxin Instant Messaging Push Guarantee and Network Optimization Details (I) How to make a long connection plus push combination scheme
Netease Yunxin Instant Messaging Push Guarantee and Network Optimization Details (III) How to optimize big data transmission in a weak network environment
How to make long connection
about IM For example, timely message push and low power consumption are not incompatible. Traditionally, each IM client will maintain a long connection with the server, and its messages and signaling will be delivered on this long connection. Each APP also has its own heartbeat, disconnection and reconnection.
This mode is relatively simple. Different APPs are completely isolated and will not affect each other. But his shortcomings are also very obvious. First, he did a lot of repetitive things, resulting in unnecessary consumption of flow and power; Second, it is difficult to ensure that all processes can run in the background. The direction of optimization is very obvious, that is, sharing connections. Now most push SDKs do the same. From these APPs, choose an APP that is currently running or has the lowest probability of being killed as the general agent. Only this agent establishes a connection with the server. All other APPs on a mobile phone communicate with the server through this agent. However, IM has a very basic requirement that cannot be met in this mode: security. All APP messages are transferred through the proxy, and the connection between the proxy and the server is encrypted and secure. But when the proxy arrives, the messages are unlocked, so the proxy can theoretically see all other APP messages. Therefore, this method of sharing long connections is not applicable to IM.
Although the shared long connection mode is not suitable, it still provides an optimization idea. On this basis, there is another way to desensitize shared connections: secure long connections plus push connections.
Each APP still uses its own secure long connection independently when using and actually transferring data. When the APP retreats to the background for a period of time, it disconnects the long connection, and then each APP starts a push agent, and selects one of them to establish a connection with the NetEase Cloud Messenger push server. Then, when the APP has new messages, they are delivered through this push connection. The APP can control the security level of the sent push message by itself. It can include the speaker and message content, only the speaker, or just a simple reminder file with new messages arriving. After the push arrives, if it is the proxy APP's own message, it can be directly passed to the proxy APP. If it is other APP messages, as mentioned earlier, direct wake-up may fail and lead to unnecessary power consumption. Therefore, instead of passing the reminder directly to the target APP, a notification bar will be sent by the caller. The target APP will not wake up until the user clicks the notification bar to remind.
Among domestic ROMs, Huawei and Xiaomi originally had a push system, which was open to third-party APPs. On these two systems, using the system's push channel will obviously be more stable and save resources. Therefore, on the MIUI, the switching process from the long connection to the push channel is still the same as before, except that instead of using its own push connection, the message is forwarded to the MIUI push server, then to the MIUI system's push agent, and then to the Netease Yunxin's APP. The process of Huawei's push system is the same. However, there are some differences between the push implementation of Huawei and MIUI. For example, the notification notification of MIUI is completed in its own push agent, while Huawei sends the notification notification to the APP itself. In addition, their notification notification management interface also has many differences. If the APP is not disabled, both can receive push. If the APP is disabled, the notification bar reminder method of MIUI can also deliver push, while other push methods cannot.
The above is all that can be done to ensure message push. If more systems open their own push systems in the future, you can also choose to gradually access them to improve the timeliness of push arrival and reduce resource consumption. However, we also have to bear the disadvantage of constantly adding push SDKs to various systems and increasing the size of the release package.
Three characteristics of mobile communication network
The first is slow, especially for 2G and 3G networks.
The second is disconnection. The mobile phone keeps moving with people, and the network also keeps switching. From wifi to mobile network, from one base station to another, from signal to no signal, the network may be interrupted. In some standard networks, answering and making calls will also cause the data network to be disconnected. In addition, the mobile BTS also has a NAT timeout. After a connection is idle for a long time, the BTS will silently disconnect the connection without any notification.
The third one is expensive, so don't mention it.
Three long connection types
stay Netease Yunxin There are three types of connections in the whole communication system: TCP, UDP, and HTTP. Although these three protocols are not the same layer, they are all in the lower layer of the application, so it is OK to divide them in this way. The three types of protocols correspond to different business applications. TCP is mainly a user long connection, that is, the transmission of ordinary IM messages and signaling. UDP is used to transmit real-time audio and video data streams, while HTTP is mainly used to upload and download audio, pictures and other files. For different businesses, the focus of SDK optimization may be different.
![]()
How to optimize IM long connection?
The first is the choice of protocol. As mentioned earlier, the usage of long connections is the largest, so it is very important to choose an appropriate protocol. If you are new to IM development, you will generally choose some open source protocols, such as XMPP, SIP, etc. This is a sample request of the XMPP protocol. You can see that it is a piece of text data in XML format.
![]()
This is a sample request of the SIP based SIMPLE protocol. You can see that it is a piece of text data similar to the HTTP protocol. The advantages of these protocols lie in open source, mature solutions that can be used, good scalability, and even interconnection with other systems. The readability of these protocols is also very good. However, it is generally bloated and has many redundant fields, which is wasteful in expensive mobile networks. Netease Yunxin uses a private binary protocol. This is a sample of the requested data. Here, the binary data is converted to hexadecimal and displayed. Each byte is displayed as two characters. It can be seen that the feature of binary protocol is that it completely loses readability, but it brings high expression efficiency. Compared with text protocol, it can save a lot of data traffic.
Another example is login optimization. Since the mobile network is often disconnected, login is often the protocol with the most interactions besides heartbeat. The greater the usage, the more meaningful the optimization. Generally speaking, login will go through these steps.
![]()
The first step is LBS. LBS here is not often called address based service. It may be called differently by different manufacturers. Anyway, it is used to obtain the IP address of the server. Systems like Yunxin that need to provide global services need to deploy servers around the world. When users log in, they must choose an optimal server access service. Through lbs, the client can obtain the IP address of the server connector that is closest to the client and has the best connectivity, and the server can also perform load balancing accordingly.
After getting the IP address of the server connection machine, the client will connect to the server.
If the connection is successful, a handshake is required. This handshake is not a TCP triple handshake, but to establish a secure connection, negotiate the encryption algorithm and encryption key with the server.
Then the login request will be sent, with user authentication information, local device information and other data.
After the login is successful, the data is synchronized, including offline messages, user information, group information, etc. Generally speaking, instead of full synchronization, incremental synchronization based on timestamp is adopted.
On the mobile network, each interaction takes a long time, and the power consumption of each network request is also large. Therefore, the direction of optimization is to minimize the number of interactions, and the rule is to merge requests, parallel operations, and omit requests.
LBS and connection can be completed in parallel. If LBS has been obtained previously, the previous cache address can be available here. If not, a default address can be connected first.
Secondly, handshake and login can also be operated in parallel. In the handshake package, you can directly bring the encrypted login package. If it is disconnected and reconnected, NetEase can also simplify the login and directly bring the session ID of the last login to reduce the server authentication pressure. On the other hand, it can directly bring back whether there are unread messages and other data during the disconnection. If not, it can directly omit the synchronization step. If there is, synchronization can also be only partially synchronized, and only offline messages can be pulled. Wait until the APP switches to the foreground to synchronize other information.
Through these optimizations, the login time can be reduced to 1/2 to 1/3 of the original, and the login traffic consumption can also be saved by about 30%.
