Thinking about the processing mechanism of android after receiving the push message

       As we know, there are the following usage scenarios:

       When we use QQ or YY, the message pushed by the server, I can't help but think, how do they deal with it?

      

       Question 1: After the user logs in, he does not know whether to pull messages from the server or push unread messages from the server?

                    So does the server need to save the user's unread messages? When using the computer client, the mobile client, the computer client and the mobile client at the same time, how is the push message processed?

       Conjecture: When a message comes, the server classifies the message by id and pushes it to the mobile client and the computer client respectively. But what if the user is not online? I think most of it is to first determine whether the user is online, if not, mark the message, and when there is a user's heartbeat packet, push the marked unread message to the past. Personally, I think it is unlikely that the client will take the initiative to get the message, because if there are few messages from the user, every time the user takes the initiative to get the message, it will not only waste the memory of the client, but also every time the server actively accesses it every time. To query, a lot of wasted server memory. If it's a single machine, it's ok, but if there are thousands of users, it's not worth it.

       Conclusion: The server marks unread messages. When there is a heartbeat packet, push it. If there is a client and a server at the same time, push the two at the same time. If there is only one, push the one, and then remove the label.

       

       Question 2: From question 3, we can learn about the messages pushed from time to time, so how does the client process these messages in different interfaces?

       Guess: If I did it, I would throw the received message to the service, and then bind the interface to the service. The reason is: a service in android is a new thread created by the background serviceManager, and we can do anything in it without affecting the running of the software. But if there are two interfaces associated with this message, such as the message list and the message chat box, how can one push a message and modify the data sources of the two interfaces at the same time? What is the first to save to the database, and then modify the data source? Or save to the database first, then get the message from the database, and then modify the interface?

                   Personally, it is better to choose to save to the database first, and then modify the data source. Because, if you read messages from the database every time, you have to judge, which wastes a lot of resources. If there is a lot of data in the database, the problem will be very prominent. The advantage of this is that the data can be saved according to the push interface. For example: if it is a message interface, I can get the current message, then add one to the number of unread messages, and then save the message as unread. If it's a chat message, I can also get the current message and save the message as read. But there is still a question, when in the chat box, this message has been read, so when I return, how to display the current latest news? At this time, the message interface and the service have been unbound. Why use the binding pull? The reason is that the binding can be reused directly with the Binder in the interface, but there is only one Binder for the interaction between the Biner and the server, so we need to do a lot with this Binder. thing.

             The following graphic can explain their relationship:



 

             

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326657345&siteId=291194637