To say that Android external push is annoying, actually has two meanings: first, it is difficult to implement, so far the industry has not found a perfect solution, Android programmers usually need to integrate multiple push platforms at the same time (if there is their own push, also need to consider with the push); Secondly, the market status quo of Android push is quite chaotic. No matter which one to choose, people will be entangled and upset. No matter how much work you put in and how much optimization you put into it, it’s still possible that your push will fail or be delayed.

There has been a lot of discussion about Android push on the Web, but very few articles have been written from the perspective of App developers (especially the startup teams that make apps). The purpose of this article is to focus on two aspects from the perspective of an App development team:

  • How to select the technology of each push platform;
  • What issues should be focused on when integrating the SDKS of various push platforms?

Why does this article only discuss end-out-push?

In general, Dachang apps distinguish between in-side push and out-side push (end-side refers to the client). Specifically,

  • When the App is running in the foreground, the push is called intra-end push. In-app push is generally a set of push system implemented by the App itself: the push server is its own, and the client maintains a long connection to its own push server, independent of any third-party push system.
  • When the App exits from the foreground to the background, the App’s own long connection remains valid until the App is not killed for a short period of time. At this time, the push can still go through the App’s own push system. The so-called “Android process alive” is designed to prolong this period of time in the background.
  • When the App has been running in the background for a long time, the App process is cleaned or for other reasons, and the long connection of the App itself is disconnected. At this time the push is called the end push, can only go to a third-party push platform.

From the perspective of this process, dachang’s App push strategy can be summarized as follows: give priority to using its own push, and turn to a third-party push platform if necessary. Why is that? Because their push system is faster and more secure:

  • It’s faster because the push you give to a third-party push platform has to queue up with a lot of other apps. If an App suddenly sends a large number of push messages (promotions, or bugs) to a push platform in a short period of time, then other apps on that push platform can be affected and push delays become significant. Such a situation is likely to happen. For example, in the technical communication group of a push platform, you will see someone Shouting irregularly: “is push blocked again……”
  • More secure. Large factories usually have a special team to maintain and push relevant services. Problems can be quickly promoted and optimized.

Although we are not a big factory, the micro-love App we maintain also has its own independent push inside the end, and outside the end adopts several other push platforms, we will talk about it in detail later.

So why does this article only discuss end-out-push? Because talking about in-side pushing and talking about out-side pushing are two completely different topics. In the discussion of external push, we mainly discussed how to choose different push platforms and what problems we should pay attention to when integrating various SDKS. This is often what startup teams need more.

In the discussion of in-side push, we should mainly discuss the specific implementation of a push system, which is a relatively complex issue, not a single article can discuss clearly. Here, we’ll give you a glimpse of what the topic might involve, but not the discussion:

  • What protocol is used? XMPP or MQTT or custom binary protocol? Do you need to push binary data (such as short voice and thumbnail data) like wechat?
  • How to ensure that the rear head connection is not dead? It involves the question of “keeping alive”.
  • How can YOU really ensure that you don’t lose data? It involves all aspects of the system, such as message confirmation, data synchronization between client and server, transaction guarantee of client data storage, and how to design background message queue to ensure not to lose data. If IM is used, how to deal with offline data?
  • Long connection Keep Alive and connection status detection and maintenance. For example, XMPP is equivalent to a never-ending XML stream that uses a space as a Keep Alive message.
  • Long connection security. Authentication and encryption.

To sum up, the focus of this article is to discuss end-out push.

What platforms are there to choose from?

We have to rely on third-party push platforms.

This is actually a similar situation on iOS. When the long connection of the in-end push system fails, we can only complete it through other push platforms. On iOS we just use APNs.

On Android, the service corresponding to APNS is Google Cloud Messaging (GCM), but it is a pity that its availability is not high in China (mainly due to mobile phone manufacturers’ customization of Android system, which may reduce GCM services, as well as some restrictions of domestic carriers). If we are doing an overseas application, then the end push basically only needs to consider GCM.

That domestic Android push platform which can choose?

Based on my personal knowledge, I have listed the following (in no particular order) :

  • MiPush
  • Huawei Push (Huawei Push)
  • U-push
  • A push
  • The aurora push
  • Alibaba Cloud Channel Service
  • Tencent pigeon push
  • Baidu Cloud Push

Which feed did we choose? What are the selection criteria?

The push platforms mentioned above can be roughly divided into three categories:

  • Big mobile phone manufacturers push: Xiaomi push, Huawei push.
  • Professional third-party push: Friendship push, push, push aurora
  • BAT factory’s platform push: Ali Cloud mobile push, Tencent carrier pigeon push, Baidu cloud push.

To choose these push platforms, we should first know what the advantages of each push platform are.

First of all, the push services of mobile phone manufacturers belong to system-level services on their own mobile phones. Theoretically, mobile phone systems have the least restrictions on their own push services.

For example, on xiaomi mobile phone, the background Service declared by the App will not run automatically after the phone is restarted if the App is not in the system startup list. However, as a mobile phone system level service, Xiaomi push can still receive push.

Similarly, the technical team promoted by Huawei also announced (quote) :

Huawei Push is system-level service on Huawei mobile phones, and stability and other aspects will definitely be better.

However, even system-level push services are not 100% guaranteed to deliver messages. Here’s what’s weird about Huawei’s tweet. Here’s what their technical support says:

On huawei mobile phones: on Emui3.0, Push broadcast is highly likely to be limited, such as Mate7 3.0, honor 6plus, P7 3.0, 4X, 4A, etc. On Emui3.1, Push broadcasting is basically unrestricted, but some models have problems, such as Honor 5X, etc. Emui4.0 and above, Push broadcast has a high probability of being restricted, and the models that are not restricted are: honor free 4C, honor free 4X, Mate S, P8 MAX, etc. If broadcasting is restricted, set the application as the startup option. So for applications that require very high timeliness or arrival rates, we recommend that applications consider alternatives. In the follow-up Push version, Huawei will adopt a new design scheme to solve the limited problems, but the release plan is yet to be determined.

In addition, as for the limitation, huawei SDK can still receive push messages. When a message is sent to an application through broadcast, if the mobile phone manager finds that the application is in the stop state, it will intercept the broadcast.

The feeling after watching it: It’s so fucking complicated!

In short, huawei mobile push, Huawei push itself is not quite able to handle. But, on second thought, there seemed to be no better option.

The second category: professional third-party push. What are their advantages? Look at their “survival” and “mutual pull” ability. For example, let’s say you’re connected to Umeng, and Toutiao happens to be connected to Umeng. One day your App is killed, but the number of devices installed in Toutiao is probably larger than yours. When the user starts toutiao, the push system will deliver your push message to the phone via the shared push channel, and maybe wake up your process as well.

In this case, it is important to choose a third-party push platform, and the scale effect of the push platform is very important. How do you know their size and market share? The best way is to ask friends on the inside. Otherwise, in fact, there is no good way, every affirmation outside said their best ah. A less precise way is to look at the big apps among their cooperative customers by looking at the cooperation cases on their official website. This information should not be scribbled.

What about the push of BAT factory? There doesn’t seem to be any advantage. The “family bucket” adopted the “live” camp and push channel, and they opened up a different thing. For example, you should not think that if you use Tencent messenger pigeon push, you can occupy the light of wechat.

What needs to be mentioned separately here is the mobile push of Ali Cloud. In their official website mentioned that mobile taobao is using ali Cloud push. However, a closer look reveals that Mobile Taobao is also using other third-party push platforms (such as Umeng Push). Which of the two platforms borrows more power from which? I don’t know.

Based on the above analysis, the push scheme we use in The Android client of Micro love is basically as follows:

  • Use the push of micro love itself in the terminal;
  • End external Xiaomi mobile phone to use Xiaomi push;
  • Huawei push is used on huawei mobile phones outside the terminal.
  • Other mobile phones outside the terminal use a unified push, that is, a push platform in the list above. I don’t know which one it is, but we’ll call it X-push for this article.

Note: Xiaomi Push certainly works on non-Xiaomi phones, but it’s not a system-level service, so it’s a bit more limited. The same goes for Huawei phones. We chose this way so that the different pushes would run in the environment that they were good at.

The basic architecture diagram is as follows:

Originally, the choice of push platform should end here. However, a recent incident that made us feel cheated by X-Push made us suddenly aware of a selection trap. Now share it so you can be sure to keep your eyes peeled.

Here’s what happened: When we started integrating with x-Push, we used the free version of the service. But after we’d been using it for a while, their salesman called. Claiming that the “care feature” in their SDK is a paid feature, if not, the tech side will do something to turn it off. The “caregiving function” they are referring to here is presumably the ability to “keep alive” and “pull together” mentioned earlier in this article.

What’s the point of this?

  1. We have long believed that “caregiving” is one of the most fundamental features of these third-party push platforms. We have received no indication from any source throughout the access development process that there will be a separate charge for the “care feature”. There is no mention of this feature in the public price list on their website, no mention in the support QQ group they access, and no mention in the official development documentation.
  2. This “babysitter” was always included in the SDK throughout our access and testing process, as well as after we went live. It was a shock to be told, after using it for a while, that there was a charge for this basic feature.
  3. If the price is clearly marked, we will take this factor into consideration at the beginning of the selection. However, the platform deliberately hid possible fee traps at the beginning.
  4. They claim that message accessibility is significantly reduced if the carer function is turned off. We can also understand the “free plus charge” business model, but generally speaking, this model is free for basic features and charge for advanced features, and it is rare to see a reduction in service quality as a free condition.

An extra 5,000 words would have been needed if all the details of the affair had been written out. Since the main purpose of this article is to share the experience of technology selection, so here is a point so far, it is good to be able to tell the general course of things. When the dust settles, we may have a chance to revisit the story.

However, you should remember that before you choose a push platform, be sure to find someone to ask the other side of the charging model, there are hidden consumption traps. Remember: No one will tell you.

Don’t ask who this X-push is, just try it out for yourself. It’s enough to serve as a reminder.

Do you need your own in-app push?

For small entrepreneurial teams, the cost of implementing the long connection push system in the end is not small.

In fact, each third-party push platform can also be used in the terminal. Also, they generally have a wrapper around APNs push for iOS as well. Therefore, in the case of resource shortage, small teams can also choose a third-party push platform to provide all their push services at the early stage, which can quickly support push from both Android and iOS platforms. When we have enough staff, we will consider optimizing or adding new push channels.

How to choose, but also depends on your own balance.

Use notification or transparent messages?

Generally, third-party push platforms support two types of push messages: notification messages and transparent messages.

Notification bar messages are directly displayed to users in the form of system notifications after being sent to users’ devices. It’s not going to be passed on to the App.

However, after being sent to the user’s device, transparent messages are routed to the App and then transmitted to the App in the form of a BroadcastReceiver that calls back to the App. The App then decides how to process and display the message.

The two types of messages differ in the guaranteed delivery rate and, of course, in the programming capabilities they provide.

Transparent messages take one more step in the overall message delivery process than notification messages, thus increasing the probability of being limited by the system. Therefore, notification messages should provide a better delivery rate than transparent messages.

For example, xiaomi’s push document describes it like this:

In some Android systems (such as MIUI), applications cannot launch themselves in the background due to the system startup management Settings. In this type of system, if the corresponding application is not started when the message is sent, the transparent message will not be successfully delivered. Therefore, for messages requiring high delivery rate, it is recommended to push messages by notification bar as far as possible

If the App has its own in-app push system, this notification bar push is more appropriate. When the long connection pushed by the end fails, we show the reminder to the user through the notification bar message, and the user arouses our App, and then the real message data is pushed to the client through the end.

In fact, we use notification notification as a way to push.

Transparent messaging, on the other hand, provides more flexible manipulation of message data. The App cannot access the message data itself if it only uses the notification message.

Therefore, if the App does not have its own in-app push system, but uses the third-party push as the in-app push channel, it can only use transparent message.

For another example, if the App wants to customize the style of notification and sound, it can only do this by passing through messages. Notification messages generally do not provide that flexibility in configuration.

One thing to note here is that when a passthrough message arrives on the device, it should ideally “pull up” the App process if it is not there while trying to route inside the App. So, presumably, if the aforementioned X-push turns off “care,” how much of an impact will transparent messaging be? The result is predictable. In addition, x-Push sales said that turning off the “care function” also affected the “message reach effect” of notification messages. Speechless…

Push initialization and push token synchronization

We use the third-party push platform, the most critical place lies in the first two steps:

  • Initialize the push SDK at the appropriate time.
  • After initialization, the App asynchronously receives a push token, which then needs to be synchronized to the App server.

The push token is called differently on different push platforms. For example, it is called REg ID in Xiaomi Push, Token in Huawei Push, CID in Getui, and Device Token in Umeng Push. In short, it is the unique identification of the device by the push platform. We collectively refer to it as “push token” for the convenience of discussion.

After the App client gets it, it must synchronize it to its own server and establish a corresponding relationship with its own user ID. In this way, when we want to push messages to one of our users, we can check the corresponding push token.

The initialization and push token synchronization steps mentioned above seem simple, just call the SDK’s ready-made interface and send it to the server. However, good code should not only work under normal circumstances, but should also allow for failure. What kind of failures do we need to consider? Let’s take Xiaomi Push as an example to analyze:

  • Xiaomi push requires initialization in onCreate of the Application object. We can guess that during this initialization operation, the SDK pushed by Xiaomi may need to modify the configuration locally for us, and may also need to contact the server pushed by Xiaomi to apply for a REG ID (i.e. push token). This initialization process may fail, local operations may be limited by the system, and network errors may occur. If the initialization went wrong, would we still get a push token?
  • Assuming we successfully receive a push token (usually in a BroadcastReceiver), we can then send the push token to our own server. We all know that in a mobile environment, the network is likely to be weak network environment. If this synchronization fails, then what opportunity can we wait for the next synchronization?

The first of these initialization errors should be handled by the push SDK. If it fails, it should have a retry mechanism until it successfully obtains the push token, and then it calls the App again to pass the push token. For example, Xiaomi push platform is also claimed that the initialization may occur errors, App developers do not have to consider. If you trust the push platform, this error can be ignored; Otherwise, you can add some chance in the App to check if the initialization has been successful (by checking if you have received a push token), and then call the initialization code again when appropriate. Of course, it’s a good idea to talk to the push platform before doing this to make sure that repeated calls to the initialization code won’t cause any side effects.

The second error is something that App developers have to deal with themselves. Here we actually need to abstract out a strong communication channel between the App client and the server, we put in the synchronous push token request, this communication channel can automatically retry when failure occurs.

It is up to programmers of different levels to determine whether the code is robust enough.

One of the differences between engineering and theoretical research is that failure is properly and comprehensively dealt with.

What does delivery rate have to do with it?

Whether push is done well or not, and whether we choose push platform well or not, the key lies in the high delivery rate. The concept of delivery rate has always been a confusing one, with some platforms claiming delivery rates of 98% or more, while others say the industry average is around 60%.

Why the discrepancy? Because what people are talking about is not actually a delivery rate.

Chen Mosha, the person in charge of the message push business line of Umeng, has written a special article to clarify some misunderstandings about the concept of delivery rate. The article is quite good, and it is suggested that students who do push business must read it:

  • Blog.umeng.com/%E5%B7%A5%E…

The key is to distinguish between “online delivery rate” and “universal delivery rate” as defined in this article.

The “online delivery rate”, optimized to the end of each push platform, may be similar. It is estimated to reach more than 98%.

The “universal delivery rate” is the final delivery rate that is actually pushing messages to your App, and that is the delivery rate that users will ultimately feel. That’s what App developers really need to focus on.

The “universal delivery rate” is roughly the ratio of the number of messages that eventually reach the App to the number of messages that start to be sent (monitored over a certain period of time). There are two factors directly related to this ratio:

  • Service type. For example, if your App is an IM, the general delivery rate may be relatively high, because the MESSAGES from IM are important and need to be read and processed by the recipient as soon as possible. If your App is just to push system news, many people may not even open your App to read it, and the general delivery rate will be low.
  • How push is invoked. This has to do with development. For example, if your push logic always sends messages to users who have uninstalled the App, they will not be able to receive them, resulting in a low general delivery rate. This is especially true in group messages.

Therefore, in this way, different apps have different business and push invocation methods, so their general delivery rates are not substantially comparable.

So how do we know if it’s a good change or a bad change if we optimize it, or if we switch to a better third-party platform someday? The answer is that we can compare ourselves to ourselves. Continuously monitor the general delivery rate and compare the change before and after the change.

Embrace change

Here’s a GitHub thread discussing Android push (created by @Trinea) :

  • Github.com/android-cn/…

Since the discussion started in May 2015, no one has come up with a perfect solution.

Android push is also a topic in constant flux as the market share of various handset vendors changes and the push platform market changes. Today’s conclusions may not be applicable tomorrow.

So, of course, push implementers should embrace change. Make sure your push architecture can easily switch to a third-party push channel.

Years of entrepreneurial experience have taught us that relying on just one platform, not just push services, but many other cloud services, is extremely foolish.

As the major domestic mobile phone manufacturers have made a variety of customized android system, increasing a lot of security restrictions, resulting in push has become a very complicated problem. And no one in the market has the perfect solution to push delivery on all mobile devices. At the same time, due to its first-mover advantage and scale advantage, wechat has entered the protected whitelist of major manufacturers, further opening the distance with other apps in push delivery rate.

If Google had been in China, would there have been such a mess?

(after)

Other selected articles:

  • Manage App numbers and red dot tips with a tree model
  • A diagram to read thread control in RxJava
  • The descriptor of the End of the Universe (2)
  • The Descriptor of the End of the Universe (I)
  • Redis internal data structure details (5) – QuickList
  • Redis internal data structure (4) – Ziplist
  • The programmer’s cosmic timeline
  • Redis internal data structure (1) – dict