Location analysis of low-rate of cloud push message arrival in Baidu

When we made this product last year, SE designed a push function on the client, and SE researched and decided to integrate Baidu's cloud push SDK on both Android and iOS to support this push feature. The recent leadership in doing operational analysis, found that the cloud push reports show that the Android side of the message is very low, the device's online rate fluctuations are relatively large, sometimes high sometimes very low.

Our product after nearly two years of frustrating progress is obvious to all, at this year's GSMA World Mobile conference in Barcelona won the "Best Mobile Music App" award, let us the bitter force of nearly two years of the cock silk morale vibration, Leadership is also delighted and decided to take the quality strategy to the end, any factors affecting our product development is impossible to tolerate, and push the function is undoubtedly the promotion of products and user retention are very important, and now found this phenomenon, the leadership of course can not tolerate, so decided to analyze the reasons, I "unfortunate" was a point, The leader also asked for Friday to give an analytical conclusion before work.

Received this task a little confused, although our product integration Baidu's push SDK has been nearly a year, but I did not study deeply, has been responsible for the person, now responsible for the people are not in our team, and time is short, Wednesday when the task under the time, that is, only two days. Of course, confused and confused, the matter or to do the problem or to solve.

First of all, a quick study of the integration of the SDK, fortunately, the SDK is still relatively simple to use, basically follow the document to do, and Baidu also provides a demo for reference. Of course to solve the problem of the light know how to use definitely not, the next is to begin to analyze the problem.

To analyze the message arrival rate is low, it is best to know which phone to receive the message is a problem, fortunately our test found in his MATE7 mobile phone can not receive our app's push message, even if we open our app is not, and there is a strange phenomenon, on his mobile phone opened a "Palm business" application, The message received is normal.

This phenomenon is rather strange, because I am not familiar with this SDK, so at that time think the quickest way should be directly asked Baidu engineer, Baidu also provides customer service answer questions, and there are some special discussion Push SDK QQ group, but the results are relatively disappointed, QQ group to ask questions basically no one, And there are a lot of people I asked the question is soon drowned, in the developer's website asked customer service problem, the response is very slow, the first night asked the question the next afternoon only to reply, and give the answer perfunctory, it seems blocked, even if customer service can help me solve the problem estimated time is too early. Later thought of college students in degrees Niang do engineers, so hurriedly contact, let him help find see can do in-house SDK engineer to help me answer. Students use his relationship to finally find the push team engineers, hurriedly add, that handsome proposal plus hi, so add Hi, at that time in hi chat people later did not respond to, later thought may be too late, tomorrow morning in say. The next morning on the computer hi to send messages, so did not, may be the mother of the work more full of people who do not have the leisure time to control us those who do not know it.

It seems to be on their own, so try to decompile the SDK jar package, through the code to see how it works, but it is very regrettable that the jar has been confusing the reading is very difficult, and the core code is not inside the jar package but in the so library can not decompile.

Look at the code is not the first to read the document, so I took my question carefully read every word in the document, finally I found in the document two important clues:

Baidu Push SDK uses a single-service single-channel strategy, that is, if the mobile phone installed a number of applications integrated with the push SDK, these applications will share the same service and long connection, in order to give users the power to save traffic, good see here finally solved my first question: Why the "Palm Office" started After our application will be able to receive push message, because "pocket business" also integrates Baidu's push SDK, through the PS command to see the process of mobile phone really found there is a Baidu related process (the problem is in the company positioning, blog is written at home, so did not bring out).

Another important clue is that the latest SDK version in the documentation addresses the adaptation of some high-system versions of the phone, The latest SDK version is 4.4.0, I look at our application integration version is 3.2.0, obviously this version is already very old, and this MATE7 phone is recently new out of the phone, so there is no possibility because of the version issue? Hurry to try, decided to start with a new version of the demo to try, before the trial in order to compare the old version of the demo test to see if there is a problem in the phone, after testing is problematic. Next with a new version of the demo to try, surprise found with the new demo can receive the message, so immediately the new version of the SDK integration into our project, the code does not change simply modify the configuration in the manifest, compared with the old version, The new version needs to add a intent-filter action to Pushservice and add a service declaration commandservice:

      <service            android:name= "Com.baidu.android.pushservice.PushService"            android:exported= "true"            android:process= ": Bdservice_v1" >            <intent-filter >                <action android:name= " Com.baidu.android.pushservice.action.PUSH_SERVICE "/>            </intent-filter>        </service>        <!--4.4 version of the new Commandservice statement to boost the actual push arrival rate on Xiaomi and Meizu phones--        <service            android:name= " Com.baidu.android.pushservice.CommandService "            android:exported=" true "/>        <!--push End--

After the modification of the operation of the project (test to restart the phone, after the boot as long as there is Baidu push the application ran our application can receive the message), finally our application can also receive messages, but there is a problem, when the first reboot after the start of our application, can not receive messages, Also, the Application management view push service is not started. The following lines of suspicious logs are found in the run log on the helpless (for some reason the more sensitive information is crossed out):

03-19 19:57:25.822 d/utility (7056): Find more higher priority pkg:com.baidu.BaiMap Priority = 408,current Highest pkg:com . smart.softclient.music.baseline Priority = 003-19 19:57:25.822 d/utility (7056): Current highest priority Push packagename:com.baidu.baimap03-19 19:57:25.822 d/pushsdk (7056): Current push service: Com.smart.softclient.music.baseline should stop!!! Highest priority service is:com.baidu.baimap03-19 19:57:25.822 D/pushservice (7056): stopself:exitondestroy=true--- Immediate=true

The log description is relatively clear, our push service at the start because Baidu map this application and immediately stopped, the log also explained that Baidu map priority is relatively high, understand the push service single-service one-channel strategy after this action I can understand, because as long as the guarantee has a push service can be, But the comparison of the soul is to see the service running in the application, found that there is no push related or Baidu map related services, so this should be the SDK judgment rule on a bug, I also put this issue to the degree Niang, not yet give feedback this is not a problem (yesterday, speed you understand ~ ~ ~ ）。 Fortunately, through the study found that this problem can be circumvented, we can set the Android:priority property to Intent-filter to the priority of our application, through the above log can see Baidu map priority is 408, I set our 1000 , simply set the intent-filter for the push service broadcast and push service:

 <!--push required receviver and service declaration--<receiver Android:name= "com.baidu.android.pushservice.PushServiceRece                Iver "android:process=": Bdservice_v1 "> <intent-filter android:priority=" + "> <action android:name= "Android.intent.action.BOOT_COMPLETED"/> <action android:name= "android.ne T.conn.connectivity_change "/> <action android:name=" Com.baidu.android.pushservice.action.notificatio N.show "/> <action android:name=" Com.baidu.android.pushservice.action.media.CLICK "/> </ receiver> <service android:name= "Com.baidu.android.pushservice.PushService" Android Oid:exported= "true" android:process= ": Bdservice_v1" > <intent-filter android:priority= "$" &G                T        <action android:name= "Com.baidu.android.pushservice.action.PUSH_SERVICE"/> </intent-filter> </sErvice> 

After the modification found that the push message is OK, the first time after booting the client will also be able to receive the message, you can view the log found now it is the other application because we have high priority of application and stop the service.

Also mentioned in the Baidu SDK documentation, can be monitored by some system events to improve the survival of our services, the current version of the SDK support to listen to the following system event broadcast after the attempt to restart the push service:

• Cut net
• Plug and Unplug power supply
• Screen unlock
• Phone boot
• SD card Plug and Unplug

In our original configuration we only listened to the net broadcast and the power-on broadcast, so if we put those rogue behavior above should be able to improve the survival of our service, because the long push connection is built in the push service, so the survival of the push service means the device online rate. The push service broadcast (the function of this broadcast is to listen to certain system events after the attempt to start the push service) changed to the following configuration:

<!--push required receviver and service declaration--<receiver Android:name= "com.baidu.android.pushservice.PushServiceRece Iver "android:process=": Bdservice_v1 "> <intent-filter> <action Android:na Me= "Android.intent.action.BOOT_COMPLETED"/> <action android:name= "Android.net.conn.CONNECTIVITY_CHAN                GE "/> <action android:name=" Com.baidu.android.pushservice.action.notification.SHOW "/> <action android:name= "Com.baidu.android.pushservice.action.media.CLICK"/><!--The following four items are optional action declarations, Can greatly improve service survival rate and message arrival speed--><action android:name= "Android.intent.action.MEDIA_MOUNTED"/><action Android : Name= "Android.intent.action.USER_PRESENT"/><action android:name= "android.intent.action.ACTION_POWER_ CONNECTED "/><action android:name=" Android.intent.action.ACTION_POWER_DISCONNECTED "/> </intent-fil Ter> </receiver>

But because these events and the system strong correlation, so there will be an adaptation problem, because the test model is limited, I only tested Moto ME860, Samsung Note4, Xiaomi 2S, MATE7, found that the MATE7 of the boot broadcast did not take effect, the reason has not been clear, So there will be a problem on this MATE7 mobile phone, after the phone restart can not receive the push message, only launched once our app to receive messages normally, after the launch of the application, regardless of the background or exit the application can be normal to receive messages.

From the above analysis, I think the following points can be used to improve the message rate and the survival of the push service:

• Upgrading the SDK to the latest version
• Setting the Android:priority Property
• Add some rogue behavior to try to start the push service in plug-in power, plug-in SD card, screen unlock event

Of course the effect to wait until the product upgrade to see. After nearly two days of tossing and rising posture.

Location analysis of low-rate of cloud push message arrival in Baidu