Android---利用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指南中的發送消息章節。

可以被替換的折疊消息

為了刷新數據，GCM消息服務會經常性的告訴移動應用連接相關服務器。在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消息到達之前，用戶進行了手動刷新，那麼應用程序就可以比較時間戳，來確定是否需要做一些事情。