Android---利用Google的雲訊息

 

Google的雲訊息（GCM）是一個用於給Android裝置發送訊息的免費服務。GCM能夠極大的提高使用者的體驗。你的應用程式會保持最新的狀態，而不用擔心因喚醒無線訊號所造成的電池電量的浪費，也不用使用輪詢來詢問伺服器是否有更新。還有，GCM允許把一個單一的訊息綁定到1000個接收端，這樣你就可以在恰當的時機快速的聯絡到大量的使用者，同時最大限度的減少了伺服器的工作負載。

本文討論一些把GCM整合到應用程式中的最佳實務，並且假設你已經熟悉了這個服務的基本實現，如果你還不熟悉，請閱讀“GCM樣本指南”

高效的發送組播訊息

在GCM中最有用的功能之一是支援高達1000個接收端來接收單一訊息。這種能力讓它很容易的把重要的訊息發送給整個使用者群。例如，你需要把一個訊息發送給1,000,000個使用者，並且你的伺服器能夠每秒鐘發送大約500個訊息。如果把每個訊息只發送給一個接收端，那麼需要1,000,000/500=2,000秒，大約有半個小時。但是，如果把每個訊息綁定到1,000個接收端，那麼把一個訊息發送給1,000,000個接收端所需要的總的時間是(1,000,000/1,000)/500 = 2秒。這對於時間敏感型資料是非常有用的，如自然災害警報或體育成績等，間隔30分鐘才發送資訊就沒有意義了。

這個功能是很容易使用的。如果你使用用於Java的GCM的輔助類庫，那麼只需簡單的給send或sendNoRetry方法提供一個註冊ID的List集合，而不是一個單一的註冊ID。

// This method name is completely fabricated, but you getthe idea.
List regIds = whoShouldISendThisTo(message);

// If you want the SDK to automatically retry a certain numberof times, use the
// standard send method.
MulticastResult result = sender.send(message, regIds, 5);

// Otherwise, use sendNoRetry.
MulticastResult result = sender.sendNoRetry(message, regIds);

對於那些實現GCM支援的Java以外的語言，要構建一個帶有下列資料前序的HTTP POST請求：

Authorization: key=YOUR_API_KEY

Content-type: application/json

然後把相關參數編碼到一個JSON對象中，其中的registratioin_ids鍵要列出所有的註冊ID。在下例中，除了registration_ids之外的所有參數都是可選的，嵌套在data中的項目代表了使用者定義的承載，它不是GCM定義的參數。這個HTTP POST訊息會被發送到https://android.googleapis.com/gcm/send。

{ collapse_key: score_update,
time_to_live: 108,
delay_while_idle: true,
data: {
score: 4 x 8,
time: 15:16.2342
},
registration_ids:[4, 8, 15, 16, 23, 42]
}
對於完整的組播GCM訊息的介紹，請看GCM指南中的發送訊息章節。

可以被替換的摺疊訊息

為了重新整理資料，GCMMessage Service會經常性的告訴行動裝置 App串連相關伺服器。在GCM中，對於這種情況可以建立可摺疊的訊息（並且建議要這樣做），就是用新的訊息替換就的訊息。例如體育成績的更新。如果你把某項比賽的最新成績發送給所有的使用者，並且在15分鐘後，該項比賽成績被更新了，那麼早先的那個訊息就不再重要了。因此對於那些沒有接收到第一條訊息的使用者，沒有必要兩條都發送，並在只有一條重要的訊息時強制裝置反應兩次（並提醒使用者）。

當你定義了一個摺疊的鍵，並且對於同一使用者有多個訊息在GCM服務中排隊時，只有該摺疊鍵關聯的最後的那個訊息會被發送。對於像體育成績這樣的訊息，這樣就會節省裝置不必要的工作，以及潛在的過度的通知使用者。對於服務同步相關的操作（如檢查郵件），這樣做可減少大量的裝置同步操作。例如，如果在伺服器上有10封郵件，並且這個10封“新郵件”的通知已經發送給裝置，那麼裝置只需同步一次郵件就可以了。

為了使用這個功能，只要給要發出的訊息添加一個摺疊鍵。如果你正在使用GCM輔助類庫，請使用Message類的collapseKey(String key)方法。

Message message = new Message.Builder(regId)
.collapseKey(game4_scores) // The key for game4.
.ttl(600) // Time in seconds to keep message queued ifdevice offline.
.delayWhileIdle(true) // Wait for device to become active beforesending.
.addPayload(key1, value1)
.addPayload(key2, value2)
.build();

如果沒有使用輔助類庫，只需簡單把帶有collapse_key欄位名的變數添加到你構造的POST頭中，並且把該鍵所對應的字串設定為要更新的值。

直接把資料嵌入到GCM訊息中

通常，GCM訊息就是一個簡單的通知，或是指示裝置在伺服器上有新的資料等待重新整理。但是，一個GCM訊息可達4KB，因此有時可利用GCM訊息自己來發送資料，這樣裝置就不必串連伺服器了。在以下狀態下可考慮使用這種方法：

總的資料量要限制在4KB以內；

每個訊息都是重要的，並要予以保留；

沒有必要把多個GCM訊息摺疊成一個單一的伺服器上的新資料。

例如，簡訊或基於回合制網路遊戲中遊戲者移動的編碼都是把資料直接嵌入到一個GCM訊息中的很好的例子。把Email嵌入到GCM訊息中不是一個好的用例，因為Email的訊息經常會大於4KB，並且使用者不需要為每個Email郵件來等待來自伺服器上的GCM訊息。

在發送組播訊息時也可以考慮使用這種方法，這樣就不必告訴你使用者群中每個裝置為了更新而同時訪問你的伺服器。

因為以下幾個原因，這種策略不適合用於發送大資料：

1.用速率限制來防止惡意的或不良代碼的應用程式向個人裝置散發訊息；

2.訊息不保證是按順序到達的；

3.即使裝置以最大每秒1K的速率，或更大的速率來接收一個GCM訊息，也不能保證訊息發出後就能立即到達。

如果使用得當，直接把資料嵌入到GCM訊息可以提升應用接收資料的速度，因為它跳過了對你的伺服器的訪問。

讓GCM訊息發揮智能化的作用

你的應用程式不應該只是接收GCM訊息，而應該發揮智能化作用。如何發揮作用則要依賴其內容。

不要討人嫌

當接收大提醒使用者重新整理資料的訊息時，很容易跨越從“有用”到“煩人”的界限。如果你的應用程式使用的是狀態列通知，就要更新既存的通知，而不是建立一個新的通知。如果你使用蜂鳴聲或震動來提醒使用者，就要考慮建立一個計時器。每分鐘的提醒不要多於一次，從而避免使用者卸載你的應用程式，或關閉裝置。

智能化的同步

當使用GCM來指示裝置有新的資料需要從伺服器中下載時，記住你有4KB的中繼資料，它可以協助你的智能化的把資料發送給你的應用程式。例如，你有一個閱讀資料的應用程式，並且你的使用者有100份相關的資料，就可以使用GCM訊息來協助你的應用程式實現從伺服器上智能化的下載資料。看下面的的執行個體，GCM訊息是如何發揮作用的：

1. refresh---這是一種基本的方式，它會告訴你的應用程式下載每個相關的資料。你的應用程式既可以向100個不同的伺服器請求發送資料請求，如果這些資料都集中在你的伺服器上，也可以給你的伺服器發送一個擷取請求，每次更新，都會綁定並傳輸100份不同的資料。

2. refresh, feedID---這是一種比較好的方式，這樣你的應用程式就會知道要更新指定的資料。

3. refresh, feedID, timestamp---這種方式最好。如果在GCM訊息到達之前，使用者進行了手動重新整理，那麼應用程式就可以比較時間戳記，來確定是否需要做一些事情。