推送通知需要很长时间才能到达答案

【问题标题】：Push Notifications take too long to arrive推送通知需要很长时间才能到达
【发布时间】：2015-09-30 12:31:17
【问题描述】：

我在适用于 iOS 和 Android 的 adobe air 应用程序中遇到了一个奇怪的推送通知问题。

我正在使用 Milkman Games 的 Easy Push ANE 以及 One Signal 服务。

问题是通知确实会到达，但有时（随机）消息在发送后可能需要长达 15 分钟才能到达设备。

这对我的应用程序（出租车预订应用程序）至关重要，因为我依靠推送通知在出租车应用程序和用户应用程序之间进行通信。因此，例如，如果用户请求打车，最多可能需要 15 分钟才能通知打车应用。

与 One Signal 支持人员交谈，据他们说一切都很好，如果我查看 One Signal 仪表板，通知几乎始终会立即发送。

延迟的原因可能是什么？我能做些什么来让事情变得更好？

谢谢。

【问题讨论】：

我从未使用过推送通知，但我认为这不是那样工作的。我认为通知（消息）是由您的应用服务器发送到推送通知服务服务器的，该服务器会将其推送到用户的设备（到您的应用程序）。但是您说的是另一种感觉：您的用户通过您的应用发出请求以发送到您的应用服务器，在这里您甚至不需要通常以相反方式完成工作的推送通知服务！
如果您的消息时间紧迫，则说明您使用了错误的推送通知工具。这是一项尽力而为的服务，即不保证时间或交付。 It is not intended to deliver data to your app, only to notify the user that there is new data available.
@Brian 我明白了，因此无法保证时间或交付。这真是太糟糕了，那我应该用什么工具呢？
您能做的最好的事情就是让应用轮询消息服务器。只要设备具有连接性，就是这样。
这很可能是由于 GCM/FCM 中的心跳间隔不切实际，导致蜂窝网络运营商和廉价 Wi-Fi 路由器断开底层连接并阻止您的通知按时到达。查看 Pushy (pushy.me)，它旨在通过使用具有 5 分钟心跳间隔的微调 MQTT 套接字来解决此问题。全面披露——我创立了 Pushy。

标签： android ios push-notification air onesignal

【解决方案1】：

通常推送通知会很快到达。但在极少数情况下，我们发现它们会延迟：

Android 设备上的通知延迟：

某些家用和商用 wifi 路由器会导致设备与 Google 的 GCM 服务器的连接关闭。设备稍后会重新打开连接并接收延迟通知。（此处讨论：https://groups.google.com/forum/#!topic/android-gcm/Y33c9ib54jY）
某些自定义版本的 Android 操作系统具有节电设置，可能会导致通知延迟或被忽略。例如，索尼 Xperia 设备具有“耐力模式”。（此处讨论：https://talk.sonymobile.com/t5/Xperia-Z3-Compact/Notifications-not-Working-When-Phone-in-Sleep-Mode/td-p/879641）
某些 Android 设备在电池电量不足时会进入低电量模式，这可能会导致接收通知略有延迟。

iOS 设备上的通知延迟：

在向具有开发配置文件的设备版本发送通知时，Apple 的 APNS 服务器有时可能会降低速度或降低可靠性。您可以比较使用 AdHoc 配置文件和生产推送证书构建的应用程序版本，看看它是否工作得更好。在不久的将来，Apple 将改变这个系统的工作方式，这样这个问题就会消失。
与 Android 一样，某些 wifi 路由器会导致 iOS 通知传递延迟。
如果为应用选中了“限制后台数据”，如果在高级设置中打开了 Wifi-Optimization，或者如果启用了优先模式，则通知可能会延迟。

WhatsApp 的常见问题页面底部有一个很好的关于解决延迟的 Android 和 iOS 通知的说明列表：https://www.whatsapp.com/faq/en/android/20887936

总体而言，上述问题很少见，几乎所有用户都会及时收到通知。但是，对于您的特定用例，您可能会发现短信是一种更可靠的工具。

【讨论】：

我也在 iOS 上看到了这个问题，而不仅仅是 android。短信是什么意思？
我添加了解决 iOS 延迟问题的说明。通过短信，我的意思是通过像 Twilio 这样的服务使用短信。 (twilio.com)

【解决方案2】：

我还在处理我手机中大多数应用程序中的延迟通知。最后在互联网上搜索了很长时间并尝试了禁用电池优化、自适应通知和所有那些根本没有帮助的功能等常见建议，我找到了 XDA 开发者论坛，我终于找到了这个问题的根源。

此问题是由称为“DOZE”的功能引起的，该功能自 Android 6 起在 Android 核心中实现。

https://developer.android.com/training/monitoring-device-state/doze-standby

基本上，它会尝试以一种非常激进的方式来保持手机电池寿命，基本上将所有应用程序和网络活动置于待机状态，直到出现维护窗口。维护窗口是一个非常短的时间段，队列中等待的应用程序的所有事件都被立即处理，然后所有应用程序再次进入待机状态，直到下一个维护窗口发生。

问题是，随着每个下一个维护窗口，这些窗口之间的间隔每次都会增加，直到某个较长的限制。因此，如果您有较长时间（例如半小时）没有触摸手机并且事件发生了，您将在下一个维护窗口（可能是从那一刻起几十分钟）收到通知。

我不知道 Google 可以如何行事，因为这没问题。它不是！！对我来说，这导致我的外汇交易应用程序出现严重问题，在事件发生时没有按时显示价格警报，而是在 5、15、30 分钟甚至近 1 小时后显示！这对我没有用，因为交易的机会已经过去了......

因此解决方案是使用 ADB 命令手动禁用手机中的“打瞌睡”。我做到了，它有效，现在我收到即时通知。不幸的是，每次手机重启后都必须这样做，因为它会再次打开打盹。

基本上你只需发出这个 ADB 命令：dumpsys deviceidle disable

您也可以将应用程序放入打盹白名单，但不确定它是否有效，当我显示该列表时，我发现我的交易应用程序已经存在，可能是因为我从省电政策中删除了它，但打盹是可能仍然暂停一切，所以它只在那些维护窗口中工作。我猜它不会使用 DOZE 描述中描述的那些“高优先级 FCM 消息”来立即强制通知。

如果您不熟悉 ADB，这里有一些信息：

https://developer.android.com/studio/command-line/adb

我使用了一个付费应用程序，它允许直接从手机连接本地 ADB，因此我可以在每次重启后禁用 DOZE。更多信息在这里：

https://forum.xda-developers.com/t/say-hello-to-ladb-a-local-adb-shell-without-needing-root-or-a-computer.4204855/

很遗憾，这个作为即时通知的基本功能必须由用户通过开发人员调试界面而不是谷歌来修复，谷歌可以在操作系统本身中修复它......谷歌感到羞耻......

https://forum.xda-developers.com/t/delayed-notification-problems-s21-ultra.4243105/page-5

【讨论】：

【解决方案3】：

就我而言，在我发送到 APNS 的有效负载中，我将“附件”属性作为“”发送。当我将其更改为 null 时，问题就消失了。

替换

"attachment": ""

与

"attachment": null

我不知道为什么，但奇怪的是它导致通知延迟到 1.5 分钟左右。

【讨论】：

【解决方案4】：

貌似网上没有关于打盹模式的详细分析和资料。一些关键问题，如延迟通知、浏览器选项卡和 ui 不断重新加载等，一定是由于 Android 操作系统的打瞌睡和自动杀戮/内存处理。这两件事有时可能联系在一起，因此它们结合在一起。很明显，作为操作系统的 Android 还不稳定（不幸的是多年后），有很多小/大问题，但最糟糕的是，谷歌和他们的开发团队似乎没有做太多事情。也许主要的问题是 Android/Java 本身，也许 Java 不是一个稳定的好操作系统的好选择。或者问题可能是谷歌没有很多优秀的开发人员来处理问题和人们的请求。也许我认为最有可能两者兼而有之。

不管怎样，对于那些想要分析打瞌睡的东西和那些还没有意识到这些的人来说，这里有一些小技巧：

无线调试功能可用于连接设备与计算机/adb 工具。因此，在连接进行测试时无需使用 USB 数据线和为手机充电。我认为由于 Android 11 大多数设备在开发人员选项下都有无线调试选项，因此无需 USB 电缆设置即可本机工作。如果没有可用的 wifi 调试（Android 11 之前的版本），则可以使用 USB 数据线进行设置。
“adb shell dumpsys deviceidle”这个命令总结了一些信息，如打盹状态和子状态，可用于在打盹/应用程序测试期间检查当前状态。
您可以在线查看其他 adb doze 命令及其效果，如强制打盹、启用/禁用等。

【讨论】：