注：本文翻譯自Google官方的Android Developers Training文檔，譯者技術(shù)一般，由于喜愛安卓而產(chǎn)生了翻譯的念頭，純屬個人興趣愛好。

原文鏈接： http://developer.android.com/training/cloudsync/gcm.html

谷歌云消息（GCM）是一個用來給Android設(shè)備發(fā)送消息的免費服務(wù)。GCM消息可以極大地提升用戶體驗。你的應(yīng)用可以一直保持更新的狀態(tài)而不用在喚醒無線電和在沒有更新的使用對服務(wù)器發(fā)起詢問等事情上消耗電量。同時，GCM可以讓你最多單一的消息可以發(fā)送給1000個人，使得你可以在恰當(dāng)?shù)貢r候很輕松地聯(lián)系大量的用戶，同時大量地減輕你的服務(wù)器負(fù)擔(dān)。

這節(jié)課將包含將GCM集成到你的應(yīng)用中的一些最佳實踐方法，假定你已經(jīng)對該服務(wù)的基本實現(xiàn)有了一個了解。如果不是這樣的話，你可以先閱讀一下： GCM demo app tutorial 。

一）. 高效地發(fā)送多播消息

一個GCM所支持的最有用的特性是單條消息最多可以發(fā)送給1,000個接受者。這個功能可以更加簡單地將重要消息發(fā)送給你的所有用戶群體。例如，比方說你有一條消息需要發(fā)送給1,000,000個人，而你的服務(wù)器每秒能發(fā)送500條消息。如果你每次只給一個接受者發(fā)送消息，那么將會耗時1,000,000/500=2,000秒，大約半小時。然而，如果一條消息可以一次性地發(fā)送給1,000個人的話，那么耗時將會是1,000,000/1,000/5,00=2秒。這不僅僅體現(xiàn)在功能的實用性上，對于具有高時效性的消息而言，比如災(zāi)難預(yù)警或者體育比分播報，如果延遲了30分鐘，消息的價值就大打折扣了。

想要利用這一功能非常簡單。如果你使用Java的 GCM helper library ，只需要像“ send ”或者“ sendNoRetry ”方法提供一個注冊ID的List就行了（不要只給單個的注冊ID）。 ?

      
        //
      
      
         This method name is completely fabricated, but you get the idea.
      
      

List regIds =
      
         whoShouldISendThisTo(message);




      
      
        //
      
      
         If you want the SDK to automatically retry a certain number of times, use the


      
      
        //
      
      
         standard send method.
      
      

MulticastResult result = sender.send(message, regIds, 5
      
        );




      
      
        //
      
      
         Otherwise, use sendNoRetry.
      
      

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

對于除了Java之外的語言，要實現(xiàn)GCM的支持，可以構(gòu)建一個帶有下列頭部信息的HTTP POST請求：

• Authorization: key=YOUR_API_KEY
• Content-type: application/json

之后將你想要的參數(shù)編碼程一個JSON對象，列出所有在“ registration_ids ”這個key下 的注冊ID。下面的代碼片段是一個例子。除了“ registration_ids ”之外的所有參數(shù)都是可選的，在“ data ”內(nèi)的項目代表了用戶定義的載荷數(shù)據(jù)，而非GCM定義的參數(shù)。這個HTTP POST消息將會發(fā)送到： 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"
      
      
        ]
      
      
        

}
      
      ?
    

關(guān)于更多GCM多播的消息格式，可以閱讀： Sending Messages 。

二）. 對可替換的消息執(zhí)行折疊

GCM經(jīng)常被用作為一個觸發(fā)器，告訴移動應(yīng)用向服務(wù)器發(fā)起聯(lián)系刷新數(shù)據(jù)。在GCM中，可以（也推薦）在新消息要替代舊消息時，使用可折疊的消息（collapsible messages）。我們用體育比賽作為例子，如果你向所有用戶發(fā)送了一條消息包含了比賽的比分，然后再15分鐘后，又發(fā)送了一條消息更新新的比分，那么第一條消息就沒有意義了。對于那些還沒有收到第一條消息的用戶，就沒有必要接收兩條消息，并且如果接收了兩條消息，那么設(shè)備不得不響應(yīng)兩次（比如對用戶發(fā)出通知或警告），但實際上兩條消息中只有一條是重要的。

當(dāng)你定義了一個折疊鍵，如果多個消息在GCM服務(wù)器中，對于相同的用戶形成了一個隊列，那么只有最后的那一條消息會被發(fā)出。對于之前所說的體育比分的例子，這樣做能讓設(shè)備免于處理不必要的任務(wù)，也不會讓設(shè)備對用戶造成太多打擾。對于其他的一些場景比如與服務(wù)器同步數(shù)據(jù)（檢查郵件接收），這樣做的話可以減少設(shè)備需要執(zhí)行的同步次數(shù)。例如，如果有10封郵件在服務(wù)器中等待被接收，那么實際上只需要發(fā)送一個GCM，讓設(shè)備一次性把10封郵件都同步了。

為了使用這一特性，只需要在你要發(fā)出的消息中添加一個消息折疊key。如果你在使用GCM幫助庫，那么久使用Message類的 collapseKey(String key) 方法。

      Message message = 
      
        new
      
      
         Message.Builder(regId)

    .collapseKey(
      
      "game4_scores") 
      
        //
      
      
         The key for game 4.
      
      

    .ttl(600) 
      
        //
      
      
         Time in seconds to keep message queued if device offline.
      
      

    .delayWhileIdle(
      
        true
      
      ) 
      
        //
      
      
         Wait for device to become active before sending.
      
      

    .addPayload("key1", "value1"
      
        )

    .addPayload(
      
      "key2", "value2"
      
        )

    .build();
      
    

如果你沒有使用幫助庫，那么就直接在你要構(gòu)建的POST頭部中添加一個變量。 collapse_key作為變量名，你要更新的字段以字符串的形式作為值。

三）. 在GCM消息中嵌入數(shù)據(jù)

通常，?GCM消息作為一個激活器，或者用來告訴設(shè)備，有一些待更新的數(shù)據(jù)需要去服務(wù)器或者別的地方去獲取。然而，一個GCM消息的大小最大可以有4kb，有時候可以在GCM消息中放置一些簡單的數(shù)據(jù)，這樣的話設(shè)備就不需要再去和服務(wù)器發(fā)起連接了。在下列情形都滿足的情況下，我們可以將數(shù)據(jù)放置在GCM消息中：

• 數(shù)據(jù)的總大小在4kb以內(nèi)。
• 每一條消息都很重要，應(yīng)該保留。
• 這些消息不適用于消息折疊的使用情形。

例如，短消息或者回合制網(wǎng)游中玩家的移動數(shù)據(jù)等都是將數(shù)據(jù)直接嵌入在GCM消息中的例子。而電子郵件就是反面例子了。因為電子郵件的數(shù)據(jù)量一般都大于4kb，且用戶不需要對每個郵件都收到一個GCM提醒的消息。

同時在發(fā)送多播消息時，也可以考慮這一方法，這樣的話就不會導(dǎo)致大量用戶在接收到GCM的更新提醒后，同時向你的服務(wù)器發(fā)起連接。

這一策略不適用于發(fā)送大量的數(shù)據(jù)（你可能會想要中這個方法將數(shù)據(jù)分割后發(fā)送），有這么一些原因：

• 為了防止惡意軟件發(fā)送垃圾消息，GCM有發(fā)送頻率的限制。
• 無法保證消息按照既定的順序到達(dá)。
• 無法保證消息可以在你發(fā)送后立即到達(dá)。假設(shè)設(shè)備每一秒都接收一條消息，最大為1K，即8kbps，或者說是1990年代的家庭撥號上網(wǎng)的速度。那么如此大量的消息，一定會讓你的應(yīng)用在Google Play上的評分非常尷尬。

如果恰當(dāng)?shù)厥褂茫苯訉?shù)據(jù)嵌入到GCM消息中，可以加速你的應(yīng)用的“感知速度”，因為它不必再去服務(wù)器獲取數(shù)據(jù)了。

四）. 智能地響應(yīng)GCM消息

你的應(yīng)用不應(yīng)該僅僅對收到的GCM消息進(jìn)行響應(yīng)就夠了，還應(yīng)該響應(yīng)地更智能一些。至于要如何響應(yīng)需要結(jié)合具體情況而定。

不要太過激進(jìn)

當(dāng)提醒用戶區(qū)更新數(shù)據(jù)時，很容易不小心從“ 有用的消息 ”變成“ 干擾消息 ”。如果你的應(yīng)用使用狀態(tài)欄通知，那么應(yīng)該 更新現(xiàn)有的通知 ，而不是創(chuàng)建第二個。如果你通過鈴聲或者震動的方式提醒用戶，一定要設(shè)置一個計時器。不要讓應(yīng)用的提醒時間超過1分鐘，不然的話用戶很可能為不堪其擾二卸載你的應(yīng)用，關(guān)機，或者把手機扔到河里：）

用聰明的辦法同步數(shù)據(jù)，別用笨辦法

當(dāng)使用GCM告知設(shè)備有數(shù)據(jù)需要從服務(wù)器下載時，記住你有4kb的數(shù)據(jù)大小和消息一起發(fā)出，這可以幫助你的應(yīng)用做出更智能地響應(yīng)。例如，如果你有一個源閱讀應(yīng)用，而你的用戶訂閱了100個源，那么這就可以幫助你的應(yīng)用更智能地決定應(yīng)該去服務(wù)器下載什么數(shù)據(jù)。下面的例子說明了在GCM載荷中可以發(fā)送那些數(shù)據(jù)，以及設(shè)備可以做出什么樣的反應(yīng)：

• refresh - 你的應(yīng)用被告知向每一個源請求數(shù)據(jù)。此時你的應(yīng)用可以向100個不同的服務(wù)器發(fā)起獲取源的請求，或者如果你在你的服務(wù)器上有一個聚合服務(wù)，那么可以只發(fā)送一個請求，將100個源的數(shù)據(jù)進(jìn)行打包并獲取，這樣一次性完成更新。
• refresh, freshID - 一種更好的解決方案，你的應(yīng)用可以有針對性的完成更新。
• refresh, freshID, timestamp - 一種更好的解決方案，如果正好用戶在GCM消息收到之前手動做了更新，那么應(yīng)用可以利用時間戳和當(dāng)前的更新時間進(jìn)行對比，并決定是否要執(zhí)行下一步的行動。

【Android Developers Training】 89. 最大化的使用谷歌云消息（Google Cloud Messaging）