c# - 为什么当用户不再使用应用程序或应用程序长时间处于空闲状态时，Azure 推送通知会停止工作？

Question

我的推送通知存在问题，该通知有时会起作用，但当用户不再使用该应用程序时，它会在一段时间后停止工作。我的应用程序在启动时使用 Web API 2.0 后端向 Azure 注册推送通知。用户成功登录应用程序后，它会更新注册记录以将用户名添加为 Tag 。据我所知，Azure注册的生命周期很长，应该是在9999/12/31 23:59:59的某个时间。我的问题是，Android FCM 和 IOS APNS 的 PNS 处理程序是否都会过期，如果过期，如果用户一段时间不使用该应用程序，我如何才能再次向 Azure 注册该应用程序，这样他们就不会错过通知？

Answer 1

Azure 通知中心客户最常见的问题之一是，当从应用程序发送的通知未出现在客户端设备上时，如何进行故障排除。他们想知道通知被丢弃的位置和原因，以及如何解决问题。本文介绍了通知可能被丢弃或设备无法接收的原因。了解如何分析和确定根本原因。

首先了解通知中心服务如何将通知推送到设备至关重要。

在典型的发送通知流程中，消息从应用程序后端发送到通知中心。通知中心对所有注册进行一些处理。该处理考虑了配置的标签和标签表达式来确定“目标”。目标是所有需要接收推送通知的注册。这些注册可以跨越我们支持的任何或所有平台:iOS、Google、Windows、Windows Phone、Kindle 和百度(适用于中国 Android)。

建立目标后，通知中心服务会将通知推送到设备平台的推送通知服务。示例包括 Apple 的 Apple 推送通知服务 (APN) 和 Google 的 Firebase 云消息传递 (FCM)。通知中心将通知分为多批注册。通知中心根据您在 Azure 门户中的“配置通知中心”下设置的凭据，使用相应的推送通知服务进行身份验证。然后，推送通知服务将通知转发到相应的客户端设备。

通知传递的最后一段发生在平台推送通知服务和设备之间。推送通知过程中的四个主要组件(客户端、应用程序后端、通知中心和平台推送通知服务)中的任何一个都可能导致通知被丢弃。

在初始测试/暂存阶段可能会发生无法发送通知的情况。在此阶段丢弃的通知可能表明存在配置问题。如果在生产中发生通知传送失败的情况，部分或全部通知可能会被丢弃。在这种情况下，表明存在更深层次的应用程序或消息传递模式问题。

下面是一篇非常好的文章，它解释了断开连接的诊断，以及我们如何配置通知中心设置，以便 wi 不会出现任何断开连接。

Notification Hubs Push Notification Fixer

这里我列出了一些我们通常会做的常见错误配置

* Ensure that your notification hub name (without typos) is the same in each of these locations:
    * Where you register from the client.
    * Where you send notifications from the back end.
    * Where you configured the push notification service credentials.
* Ensure that you use the correct shared access signature configuration strings on the client and on the application back end. Generally, you must use **DefaultListenSharedAccessSignature** on the client and **DefaultFullSharedAccessSignature** on the application back end (grants permissions to send notifications to Notification Hubs).

You must maintain two different hubs: one hub for production, and another hub for testing. This means that you must upload the certificate that you use in a sandbox environment to a separate hub than the certificate and hub that you are going to use in production. Don't try to upload different types of certificates to the same hub. This might cause notification failures.

If you inadvertently upload different types of certificates to the same hub, we recommend that you delete the hub and start fresh with a new hub. If for some reason you can't delete the hub, at a minimum, you must delete all the existing registrations from the hub.

1. Ensure that the *server key* that you obtained from Firebase matches the server key that you registered in the Azure portal.

![Firebase server key][3]

2. Ensure that you have configured **Project ID** on the client. You can obtain the value for **Project ID** from the Firebase dashboard.

![Firebase Project ID][1]

希望这有帮助。