共用方式為


通知中心概觀

Azure 通知中心提供易於使用的基礎結構,讓您可以從任何後端將行動推播通知傳送到任何行動平台。

透過通知中心您可以輕鬆地傳送跨平台、個人化的推播通知、擷取不同平台通知系統的詳細資料 (PNS)。 使用單一 API 呼叫,您可以跨所有裝置將目標設為個別使用者或整個對象區段 (包含數百萬個使用者)。

在企業和消費者案例中,您可以使用通知中樞。 例如:

  • 將即時新聞通知傳送給數百萬名使用者 (通知中樞強力支援所有 Windows 和 Windows Phone 裝置上已預先安裝的 Bing 應用程式),且延遲性低。

  • 將位置型折價券傳送至使用者區段。

  • 將事件通知傳送給運動/財金/遊戲應用程式使用者或群組。

  • 通知使用者有關企業事件 (例如新訊息/電子郵件) 和潛在業務機會。

  • 傳送 Multi-Factor Authentication 所需的一次性密碼。

什麼是推播通知?

智慧型手機和平板電腦能夠在事件發生時「通知」使用者。 在 Windows 市集和 Windows Phone 應用程式中,通知會產生快顯通知 (一種非強制回應視窗,出現在畫面上方) 或在開始畫面上出現更新方塊。 同樣地,在 Android 和 Apple iOS 裝置上,通知會以群組方式出現在通知窗格中,您可以輕易地從畫面上方存取。

推播通知協助應用程式後端在行動裝置上顯示最新的資訊,即使該應用程式在裝置上並非使用中狀態。

推播通知是透過平台特定的基礎結構傳送,這個基礎結構稱為「平台通知系統」(Platform Notification System,PNS)。 PNS 提供準系統功能 (也就是不支援廣播或個人化),且以平台為基礎的 PNS 沒有通用介面。 例如,為了傳送通知到 Windows 市集應用程式,開發人員必須連絡 WNS (Windows 通知服務)。 相同的開發人員必須連絡 APNS (Apple 推播通知服務),並再次傳送訊息,才能將通知傳送給 iOS 裝置。 此程序與 Windows Phone 8 和 Android 應用程式相似。

從高階層面來看,所有平台通知系統皆遵守相同的行為模式:

  1. 用戶端應用程式會連絡 PNS 擷取其控制代碼。 控制代碼類型視系統而定。 針對 WNS,它是 URI 或「通知通道」。針對 APNS,它是權杖。

  2. 用戶端應用程式將此權杖存放在應用程式後端,供日後使用。 在 WNS,後端通常是雲端服務。 在 Apple,系統叫做提供者

  3. 若要傳送推播通知,應用程式後端會使用控制代碼連絡 PNS,鎖定特定用戶端應用程式的執行個體為目標。

  4. PNS 會將通知轉送至控制代碼所指定的裝置。

Notification Hubs

實作此流程所需的基礎結構非常複雜,且大部分與應用程式的主要商務邏輯無關。 建置隨選推播基礎結構的挑戰包括:

  • 平台相依性。 為了將通知傳送給不同平台上的裝置,您必須在後端以程式碼編寫多個介面。 不只低階細節不同,且通知的呈現方式 (磚、快顯通知、或徽章) 依平台而異。 這些差異導致複雜且難以維護的後端程式碼。

  • 擴充。 此基礎結構的調整可分為兩個層面:

    • 根據 PNS 準則,在每次啟動應用程式時,都必須重新整理裝置權杖。 這會造成極大流量 (及後續的資料庫存取),只為了維持最新的裝置權杖。 當裝置數量成長 (可能到數百萬個),建立及維謢此基礎結構的成本十分驚人。

    • 大部分 PNS 不支援向多個裝置廣播。 結果是,若向數百萬個裝置廣播,會產生數百萬個 PNS 呼叫。 要擴充這些要求是件難事,因為通常應用程式開發人員想要維持低的總延遲 (例如,在傳送通知的 30 分鐘後,最後一個接收訊息的裝置不應接收通知,因為在許多情況下,這會破壞使用推播通知的目的)。

  • 路由。 PNS 提供將訊息傳送至裝置的途徑。 然而,在大多數應用程式中,通知的目標是使用者及/或利益群組 (例如,所有指派給特定客戶帳戶的員工)。 結果是,應用程式後端必須維護讓利益群組與裝置權杖產生關聯的登錄,才能將通知路由到正確裝置。 這項負擔會增加應用程式的上市時間和維護成本。

  • 監控與遙測。 追蹤及彙總數百萬筆通知的結果並非易事,這對於任何使用推播通知的解決方案來說通常都是重要的元件。

使用通知中心

通知中樞會消除一大複雜性:您不需要管理推播通知的挑戰。 而是,您可以使用通知中樞。 通知中樞採用完整的多平台、向外延展的推播通知基礎結構,可大幅減少應用程式後端所執行的推播專用程式碼。 通知中樞可實作推播基礎結構的所有功能。 裝置只需註冊其 PNS 控制代碼即可,後端會負責將平台共用格式訊息傳送給使用者或相關群組 (如下圖所示):

Notification Hubs

通知中心提供的推播基礎結構具備以下優點:

  • 多平台

    • 支援所有主要的行動平台 (Windows/Windows Phone、iOS、Android)。

    • 沒有特定平台的通訊協定。 應用程式只會與通知中樞通訊。

    • 裝置控制代碼管理。 通知中樞會維護控制代碼登錄以及來自 PNS 的意見。

  • 與任何後端搭配使用。 例如雲端或內部部署、NET、PHP、Java、節點等等。

  • 擴充。 通知中心可擴充到數百萬個裝置,不需要重新架構或分區化。 所有區域都有提供。

  • 豐富的傳遞模式集。 將標籤與裝置相關聯,表示邏輯使用者或利益團體。

    • 廣播:允許使用單一 API 呼叫幾乎同時廣播到數百萬個裝置。

    • 單播/多播:推送至代表個別使用者的標記,包括其所有裝置;或較寬的群組;例如, (平板電腦與手機) 不同的尺寸規格。

    • 分割:推送至標籤運算式所定義的複雜區段 (例如,紐約的裝置遵循) 。

  • 個人化。 每台裝置可以擁有一或多個範本,以達成不用影響後端程式碼就能進行每台裝置的本地化和個人化作業。

  • 安全性: 共用存取密碼 (SAS) 或同盟驗證。

  • 豐富型遙測。 可在入口網站和以程式設計方式取得。

總結

  • 推播通知已成為新型應用程式不可或缺的一部分,因為它們可以增加消費者應用程式的使用者互動體驗和企業應用程式的功效。

  • 通知中心提供易用、多平台、向外擴充的推播基礎結構,可大幅減少程式碼和應用程式後端程式碼的維護。

  • 通知中心可以供任何後端使用 (雲端或內部部署) 以傳送推播通知到所有主要的行動平台 (Windows/Windows Phone、iOS、Android)。

其他資源

客戶如何使用通知中樞

通知中樞教學課程和指南

通知中心入門教學課程:

通知中心相關的 .NET managed API 參照位於:

Microsoft.WindowsAzure.Messaging.NotificationHub

Microsoft.ServiceBus.Notifications