Android Instant Messaging Development Summary (i)

"Android Instant Messaging Development Summary " based on various common problems of IM andriod development, combined with the practice of instant communication technology of NetEase Cloud , I make a comprehensive summary of IM development.

Related recommended reading:,

Summary of Android Instant Messaging development (II.)

Mobile IM Development Guide 1: How to choose a technology

Mobile IM Development Guide 2: Heart rate Instructions

Mobile IM Development Guide 3: How to optimize login modules

Client architecture

As an IM software, one of the most important features is to guarantee the rate and real-time of the message. The reach rate is affected by server performance and design protocols, and is discussed later. The real-time nature depends on whether the client process is long-term and whether the connection is maintained consistently.

Process slicing

In Android, apps have little control over the life of their app, and the system can kill your process at any time without giving any notice and calling you up when it thinks it's right. No notification will be given to the process before and after the session. However, the process of life and death control also has some rules, generally speaking, the more resources the process occupies (memory, CPU time, etc.), the less important for the user (foreground process--visual process---------Daemon process----), the easier it is to be killed. Therefore, the process should be as small as possible and have a high priority.

If an application itself is small, a process is sufficient, the main thread is responsible for the UI, and another background thread runs a service. And if the application is very large, it is a better choice to separate the push service. The main process is responsible for user interaction and the main business logic, occupying a huge amount of resources, when back to the background, at any time to be killed is irrelevant. The push process is only responsible for interacting with the server and maintaining minimal business logic processing.

The network connection and login status are tied together, and after logging in, synchronizing the data is also a necessary operation. As a result, both logging and synchronizing data need to be done in the push process, and in addition, other businesses are handed over to the UI process. When the push process receives a protocol that it does not own, it throws the data to the UI process for processing.

There is no alternative to communication between the two processes, only aidl, the difficulty lies in the design of the interface. The complexity of the IM business logic makes it impossible for us to implement a AIDL interface for each invocation, so we will certainly package the interface call as a control command pass. The easy way to identify control commands is to use what is similar to Message, we assign a command number to each control command (or add a sub-command number), and specify the corresponding command data format, the receiving end of the command number and then back to the data processing. This approach is cumbersome and maintainable. The more elegant way is to use a remote procedure call, the sender declares the calling interface of the business, and implements these interfaces at the far end, and when the sender invokes these interfaces, the remote invokes the implementation of the corresponding interface directly. In addition to using a variety of third-party frameworks, Java's own Proxy can also implement this function. A little different from the push process to the UI process, the UI process can be killed at any time, and the Aidl call might return a failure, in which case you can choose to pass the data Intent way and evoke the functionality of the UI process.

Life Insurance

KeepAlive is divided into three aspects, one is the system API provides an interface, the application of their own can do, which is "legitimate", the second is the use of system defects, avoid the system review, this is considered "illegal", or "gray", three is a number of apps alliance, wake Up each other, this is bullying, who will win the camp.

The first is the system alarm clock, the broadcastreceiver of various events, the callback notification of the task being removed, and so on.

The second known is that on the 4.4 and previous versions, the native process was used, and the process was detached from the davilk parent process and hooked up to the INIT process to avoid the system's Avira. Then in this native process, the timing evokes the application. To make this native process lighter, you can use exec to start an executable file to get rid of the Zygote process environment that the direct fork is brought into. In addition, this approach is used to pop up the survey window when listening to your app being uninstalled.

The third Way is now the major Internet companies are in use, the way is very simple, call each other the designated Service, or send a designated broadcast. As long as you start a Ali-department app, other Ali-department apps will be aroused. You launch an app with the Friends League SDK, other apps with the Friends League SDK, and the Ali app will wake up.

Usually, the first is a must, the second and the third will appear in a companion, Rogue to the end.

Communication protocol Selection

Another guarantee of the real-time nature of messages is the long connection. Of course, you can also use a short connection polling, but this is generally only in the short-term web chat use, in the Android background unlimited polling no one can be affected. The long connection type can be either traditional TCP or use a newer WebSocket. The benefit of using the latter is mainly the server, their set of connections can serve the App side and the Web side.

IM Communication protocol Selectivity is many, open source has xmpp,mqtt, and so on, the advantage of using open source agreement is to get started quickly, more information. Most mainstream IM, in general, will design proprietary communication protocols. Using private protocols, you can design more traffic-efficient protocols for your own business logic, while still protecting your ecosystem, just as Android phones can't fit the Apple system, and easy-credit users can't send messages to the user.

The protocol content of the private agreement is similar to the Open source protocol, which can contain a generic protocol header and then add the payload package. When packaging, in order to pursue readability, you can use the text protocol, in order to seek to save traffic, it is generally used binary protocol.

When designing a private agreement, the message must be a place to focus. Because of the complexity of the mobile network, it is possible that messages are passed between the client and the server. When the client sends a message to the server, the client is not sure that the message will be received by the server, it needs the server to give the client a feedback after receiving the message, and if the client does not receive the feedback, it needs to resend after a certain timeout. There is a problem here is the possibility that the server has received, but the feedback package is discarded, this will cause the message to repeat, in order to go heavy, we need to allocate the same UUID for the same message for the receiver to go heavy. Similarly, when the server forwards the message to the receiving end, the server can not guarantee that the receiving end will be able to receive, need to receive the server a receipt, tell the server this message I have received, you do not send me again.

Android Instant Messaging Development Summary (ii) will be from the "establish a secure Connection", "Heartbeat", "disconnection", "Multimedia data Management", "Picture", "voice" and other issues, combined with the real-time NetEase Cloud communication technology practice, For a detailed introduction and summary.

Android Instant Messaging Development Summary (i)