Today, I will talk about pushing this small matter. Although it is small, it is not easy to do well.

Push hard, difficult to heaven.

When we talk about push on Android phones, most of the time we’re talking about integrating third-party push, because even big companies like wechat need to be added to their startup whitelist to stay online.

IOS phones use Apple Push Notification Service (APNs) for Push, while Android phones also have Google Cloud Messaging (GCM) as the official Push support. However, in China, users need to climb over the wall to use the phone, and Google Service is required to be installed on the phone, which is quite harsh.

In this way, the push of domestic mobile phones becomes a problem and an opportunity.

Due to the international version of wechat, GCM is used as an auxiliary public channel, but it is only used to activate wechat’s own Push channel, and data is not transmitted through GCM, which is also to reuse the heartbeat optimization strategy and data processing logic.

The latest version of GCM is FCM (Firebase Cloud Messaging)

The implementation of push

To summarize a few push implementations, some of which we only need to know about because they are historical solutions that are now deprecated.

1. The polling

The client regularly asks the server if there is any new message. The biggest disadvantage of this method is the contradiction between performance and real-time performance. The polling time is too long or too short.

2. The message

This method is not allowed even before birth. Firstly, operators will not cooperate. Secondly, intercepting SMS is a high-risk permission, and most users will not pay for it.

3. Long even

At present, the most common solution is that the client establishes a TCP long connection with the server and sends heartbeat packets periodically. When there is a new message, the server pushes it through the long connection channel.

Here is a brief description of long connection and heartbeat packets.

Long connection is the establishment of a connection, the two parties to send data to each other, sent not active disconnection.

However, in some cases the long connection will be disconnected. The problem is the disconnect, and this must be known by the client, because the client can reconnect to the server, and the server can no longer contact the client. This confirms that the heartbeat packet must be sent from the client to the server. So the function of the heartbeat packet is to tell the server that the client is alive, and if the server is down, the client will know, so keeping alive means keeping both sides alive.

NAT timeouts are a typical example of some of the situations described above.

The number of IPv4 IP addresses is limited. The IP addresses assigned to mobile phones by carriers are Intranet IP addresses of carriers. To connect mobile phones to the Internet, Network Address Translation (NAT) needs to be performed by carriers’ gateways. In a nutshell, the carrier gateway needs to maintain a mapping between the external IP address, port, and internal IP address to ensure that mobile phones on the Intranet can communicate with servers on the Internet. When there is no data communication on a link for a period of time, most mobile wireless network operators eliminate the corresponding entries in the NAT table, resulting in link interruption. Therefore, the interval between long-link heartbeat beats must be shorter than the AGing-time (NAT timeout). If no heartbeat is performed after the aging time, the TCP long-link link is interrupted and the server cannot send messages to the client. In this case, the client can receive messages only after the next heartbeat failure.

With long connection, even in sleep mode, a push message will wake up the Android system. This is determined by the system mechanism, so we just need to know the conclusion.

For more information, see resources at the end of this article.

Pushed indicators

There are several core metrics to consider when accessing push services:

1. The rate of online

Online rate = Number of online users/Total number of online users

Push service background to keep online method

  • The Push process resides in the background, requiring the user to manually resident the application
  • A shared connection channel, such as an aurora or a push, through which a shared connection evokes the app when a push arrives

Obviously, the latter is closer to GCM in terms of experience.

2. Arrival rate

Arrival rate = Actual arrivals/number of intended users

Number of online users -> number of target users -> Number of successful deliveries. These two data will be inaccurate if there is a problem in back-end calculation or invocation

Online number -> Actual Number of arrivals -> Number of displays. After the data is received, whether to display the data depends on whether the user has turned on the notification permit switch of the application. You can judge by the following method

notificationManagerCompat.areNotificationsEnabled();Copy the code

3. The power consumption

The power consumption is affected by many aspects. If you receive a lot of push and open the application frequently, the power consumption will naturally increase, but the user can accept it. Users are disgusted by the following factors of power consumption:

  • The power consumed by apps waking up to each other because it belongs to another app that the user has no intention of turning on
  • Power consumption caused by incorrect retry. Optimization of retry policy includes accumulation and resetting of retry time

Push the selection

As mentioned above, the push we are talking about here is a third-party push, so some developers want to ask, why not do their own push? It’s not impossible to do it yourself, but there are a few things to consider:

  • Development cost, whether ROI is acceptable
  • If you are not whitelisted, there is no one to sing resurrection magic to you once the app is killed

Third-party push includes vendor push and non-vendor push

  • Huawei, Xiaomi, Meizu push
  • A push, aurora, friendship alliance
  • Alibaba, Tencent, Baidu

Among them, the selection of several factors

  • Vendor push notification system channel (all vendor supported)
  • Whether vendor push transparent transmission is a system channel (meizu only)
  • Non-vendor pushed market share (affecting the probability of shared connections evoking each other)

How do I check what push an app is using on my Android phone?

adb shell dumpsys activity services | grep igexinCopy the code

As you can see, all of these apps are using a push

Dianping, Babytree, Ele. me, Didi, Jianshu, linkedin, WPS Office, Guevara.

Push access

How to decouple

Since the interface definition of each push SDK is different, in order to reduce coupling, we use the form of multiple modules for access.

  • app
  • jikepush
    • PushServiceImpl
  • 1 push_ manufacturers
    • PushPlatformImpl
  • 2 push_ manufacturers
    • PushPlatformImpl
  • Push_ not manufacturer
    • PushPlatformImpl
  • jikecore
    • PushService
    • PushPlatform

The required PushPlatform is registered in the app layer, and then called through the PushService interface. The implementation of the startup and switch is in the PushServiceImpl.

In fact, most push platforms have similar interface standards, except for naming differences, so we use PushPlatform to mask this difference.

For push start and switch operations, put them in PushService.

When a push service is started, other push services are turned off, and only one push service remains in the background.

registeration id

Usually when we start a push service, we will receive a registeration ID (reg ID for short) and bind this REG ID to our own server.

One important thing to note here is that we need to call the binding operation twice.

  • After pushservice.start () Some pushes no longer trigger the receive REg ID after receiving the reg ID
  • After Receive Reg ID The reG ID is asynchronously received after the initial startup push

After receiving the REG ID, the push SDK will save it for next use, but sometimes we can’t get it when we use the SDK method. The reason is that we don’t save the REG ID by ourselves, so we also need to save such important things as Reg ID.

Push required system permissions

The push SDK needs to obtain the IMEI number of the mobile phone as a necessary element to synthesize REG ID, which requires the following two permissions

  • Manifest.permission.READ_PHONE_STATE
  • Manifest.permission.WRITE_EXTERNAL_STORAGE

You need to determine permissions when starting the push service.

Push switchover policy

It is suggested to choose the ROM rather than the phone model as the switching condition, so that some users can solve the problem of swiping, such as Nexus phone swiping MIUI.

After obtaining ROM information, there are three push switching strategies

A strategy

The client automatically selects which push to use based on ROM information

  • Advantages: No back-end workload, no need to switch
  • Cons: No way to temporarily switch to another feed once one has been suspended for a day

Strategy two

The client reports ROM information, and the back end selects which push to use

  • Advantages: Flexible switch push
  • Disadvantages: There is a lag in switching push to rebind the REg ID

Three strategies

Use push SDK’s own integration solution, when the SDK’s own push service is offline, switch to vendor push

  • Advantages: Ensure the stability of push to the greatest extent
  • Disadvantages: The instability of integration scheme itself affects the stability of push

Push type

Push types include notification and transparent transmission

notice

  • Vendor arrival rate has advantages
  • The development cost is high, and the interface standard needs to adapt to different vendors

passthrough

  • Can parse, display, jump, high flexibility
  • Low development cost, once adaptation (usually via JSON)
  • Some vendors do not have vendor advantage in pass-through arrival rates

Integrated way

Generally we integrate push SDKS in two ways

  • The maven integration
  • Manual integration

From a maintenance perspective, maven integration is less expensive to maintain than manual integration, but I recommend manual integration for several reasons.

Appid, AppKey, and AppSecret should be injected in the manifest placeholder mode by the SDK. However, this mode needs to be injected in the build.gradle of the app layer, which is more coupling.

Another drawback of Maven integration is that it’s the SDK developers’ problem to be precise. There are always some resource files that we don’t need. I only need a JAR package, not the whole AAR.

Manual integration can be tricky to write the MANIFEST for the first time, but you can simply replace the JAR and so files later because the MANIFEST doesn’t change very often unless there is a major release update.

Display of push

Next comes Notification, which has been customized by vendors and has had some trouble adapting.

Vendor push style differences

Part of the vendor

  • Does not support NotificationCompat. BigTextStyle (this can not support)
  • Does not support NotificationCompat. MediaStyle (this can also understand)
  • Action Button is not supported
  • Do not support the Ticker
  • Custom style height limits

Push style differences in the native Android version

  • 4. X large icon needs to be square
  • X 6. X by setColor setting background color and small icon together to form large icon
  • 7. X setColor affects the title color

Notification jump

  • Transparent transmission: The Url is used to forward data
  • Notification: Jumps with the Intent parameter

So much for the small matter of pushing.

Looking to the future

Recently, the Android unified push seminar led by Thiel LABS is underway, and there is a reminder of the “progress of unified Android Push service”. Let’s pay attention to the changes in the Android push ecosystem.

Use an advertising slogan to describe the love between the manufacturer and app: Hello, I am all right.

The resources

Research on Android push technology

Android wechat intelligent heartbeat solution