Official Daddy's pain: Why does Apple get a push and not Android?

The article started in "Blog Park-Chen Shuyi", click to jump to the original "Official Dad's pain: Why Apple can receive the push, but not Android?" 》

Do you remember the experiment we did last time?

We get a push after the IOS device kills the process, and the Android device doesn't. This problem can be confused the small tree for a long time, this day while working leisurely, and ran to the small black station to consult.

Xiao Hei drank tea and began to say that we are now all push messages are launched through a third-party push. So it's important to understand how third-party push is implemented.

When our app launches, it also launches the third-party vendor's push service that comes with our app, and the app process has a long Socket connection that remains with the third-party vendor's push server. When we have a message that needs to be pushed to the user's device, we can pass in the corresponding alias by invoking the third-party vendor's push interface.

Little Tree hear alias feeling a little confused, what is an alias ah?

An alias is an identity that a third-party vendor uses to mark a unique user.

When our app launches, the vendor requires the app to pass the alias and the set other Devicetoken parameters to the vendor at the appropriate time to establish a binding relationship.

So in essence, third-party vendors end up using Devicetoken to identify which App to push to which device.

This alias, in general, is also to be able to uniquely identify a user. So many times we use the user ID as an alias and bind it to the Devicetoken.

After listening to the small tree found that you can draw a flowchart to comb the entire process.

App启动 -> 启动第三方推送服务 -> 注册别名和DeviceToken -> 等待推送消息

The painting is very good, very clear expression of the third-party push process, said Xiao Black.

For the background development of small brother, if you want to send a push to the user, only need to alias and push content as a parameter to call the third-party vendor interface.

But this doesn't seem to answer the question before, why does the IOS device receive the push when the APP process is killed, and the Android device doesn't?

The young man really chase, I am not yet finished speaking, don't worry Ah. Little Black calmly said.

The situation that we have mentioned above applies only when the APP process has not been killed. However, when our App process is killed, the process of the third-party service provider will be erased as well.

At this point, it is clear that we will not be able to perform the push message reception through the device and the Socket long connection established by the third Party vendor. Therefore, the Android device will not be able to receive the push.

IOS devices can also receive push after the App process dies, because third-party vendors automatically call Apple's official APNS service for message push after they detect that their connection to the iOS device is broken.

The official push service for IOS devices is always available as long as the device is powered on. So our IOS device is able to get pushed even if the App process is killed. Although this push push function is very limited, but can be delivered to the user is better than not delivery.

Android devices cannot receive a push after the App process dies, because there is no official push support.

But there are also situations where Android devices can receive a push when the App is not open.

Little Tree heard there is such a trick, hurriedly asked what is the way ah?

Whether this can be achieved depends on the power of the third-party vendor's services.

Let's say that we have two apps on our phone, namely "Cherish the net" and "Know It", and they all use the same push service.

When we launched two apps, this time there will be two on the process of push service process, one belongs to "Cherish the network"app, one belongs to "know" this App.

When we put "Cherish net"app Kill, cherish the web App corresponding to the push process is finished. " But this time is not aware of the App in this push. Some manufacturers take advantage of this, through some technical means, using "know"app of the push service to wake up "cherish the network"app push service, so that cherish the Web App users can also receive push.

Originally this can still play ah, sure enough is his service can have infinite imagination space ah. The little tree regrets the way. It would be nice if I could implement one of my own push services, so we wouldn't have to rely on third-party vendors to do more custom services.

Although the self-built push service seems beautiful, the development cost and maintenance cost are very high. If the company's business is small, it is more reliable to use third-party push services.

However, the size of our company is not small, there are nearly hundreds of millions of users, daily business push the magnitude of the level also reached the millions. The company has organized the development team in the development of the elite, immersed in dry for 2 months, finally made a can use push service.

The little tree heard the unusual delight, and felt that there was something to learn.

But today still don't say so much, afraid you learn too much absorb not. There is a chance we'll talk about how to design a push system from scratch, and then how to do it one step at a time.

The article started in "Blog Park-Chen Shuyi", click to jump to the original "Official Dad's pain: Why Apple can receive the push, but not Android?" 》

Official Daddy's pain: Why does Apple get a push and not Android?