Android: Delay in Receiving message in FCM(onMessageReceived)

后端 未结 3 1415
不知归路
不知归路 2021-01-03 19:34

In Test app, I have implemented FCM for sending notification messages using

https://github.com/firebase/quickstart-android/tree/master/messaging

For testing

相关标签:
3条回答
  • 2021-01-03 19:49

    This issue tracker is dedicated to issues related to the Android Quickstart. The gurus working on this project don't have access to any diagnostics to help troubleshoot FCM issues. Please contact support . https://firebase.google.com/support/

    0 讨论(0)
  • 2021-01-03 19:59

    This could be caused by the unrealistic heartbeat intervals in Firebase Cloud Messaging.

    FCM works by maintaining an idle socket connection from an Android device to Google’s servers. This is great because it barely consumes battery power (contrary to polling), and it allows the device to be woken up instantly when a message arrives.

    To make sure that the connection remains active, Android will send a heartbeat every 28 minutes on mobile connection and every 15 minutes on WiFi. If the heartbeat failed, the connection has been terminated, and FCM will re-establish it and attempt to retrieve any pending push notifications. The higher the heartbeat interval, the less battery consumed and the less times the device has to be woken up from sleep.

    However, this comes at a great price: the longer the heartbeat interval, the longer it takes to identify a broken socket connection. Google has not tested these intervals in real-life situations thoroughly enough before deploying FCM. The problem with these intervals is caused by network routers and mobile carriers, who disconnect idle socket connections after a few minutes of inactivity.

    More info is available on my blog:

    http://eladnava.com/google-cloud-messaging-extremely-unreliable/

    As a workaround, please consider Pushy (https://pushy.me), a drop-in replacement for GCM/FCM which greatly improves notification speed & reliability (Full disclosure - I founded Pushy).

    0 讨论(0)
  • 2021-01-03 20:11

    My best guess is that this has to do with the message priority.

    From the docs:

    Setting the priority of a message

    You have two options for assigning delivery priority to downstream messages on Android: normal and high priority. Delivery of normal and high priority messages works like this:

    Normal priority. This is the default priority for data messages. Normal priority messages won't open network connections on a sleeping device, and their delivery may be delayed to conserve the battery. For less time-sensitive messages, such as notifications of new email or other data to sync, choose normal delivery priority.

    High priority. This is the default priority for notification messages. FCM attempts to deliver high priority messages immediately, allowing the FCM service to wake a sleeping device when possible and open a network connection to your app server. Apps with instant messaging, chat, or voice call alerts, for example, generally need to open a network connection and make sure FCM delivers the message to the device without delay. Set high priority if the message is time-critical and requires the user's immediate interaction, but beware that setting your messages to high priority contributes more to battery drain compared with normal priority messages.

    I am not certain, but I believe that normal priority is used when you send a message to "All Android devices", which it seems you are doing in the question above. It is also possible that it is being sent to a FCM topic, which is optimized for throughput rather than latency

    So, setting the priority to high, or sending to one specific device rather than a topic, should reduce the delay you are seeing.

    Also; Be aware that push messages are based on best effort. There are no guarantees that the message will be delivered by a given time, or at all.

    0 讨论(0)
提交回复
热议问题