Android Push Notification推播機制(8)-問答篇

撰寫時間︰2012/02/07 12:45

更新時間︰2012/02/14 11:50

文章更新次數︰2

以下是Google I/O 2010 - Building push applications for Android 
37:40開始的會後提問。

提問1.

觀眾︰C2DM整個流程裡是否存在「延遲」問題？包括C2DM通知App Server或是收到BroadCast廣告訊息之類的？

Debajit Ghosh: 這完全取決於網路速度，由其是你的Server和我們的Server之間，或者裝置和C2DM之間的網路速度。但它是非常快的。

提問2.

觀眾︰有沒有手機傳資訊回網站，例如雙向溝通等等的方式或API架構？

(Is there an API or a mechanism to go the other way around, from the device back to the Web to do something like a two-way chat in the same manner?)

Debajit Ghosh: 一般來說，App只用標準的HTTP與其它的App Server做整合。

提問3.

觀眾︰有2個問題，你說C2DM機制目前需要Froyo2.2，意思是否是之後也能在模擬器上運行C2DM機制？

Debajit Ghosh:  2.2 SDK就已經提供這個機制了。你可以用SDK去做App測試。

觀眾︰第2個問題，若要攢寫code是否也包含要攢寫App Engine的部份？

(Does the code side also have code for the App Engine side of the code?)

Debajit Ghosh: 當然，這個機制是很完整的。
以Chrome-to-phone的範例來說，他的架構有Chrome擴充套件、Android App和一個App Engine的後端。
以JumpNote來說，有GWT和App Engine和Android App。
我們會提供所有的資源出來做分享。

提問4.

觀眾︰您剛才說如果手機目前在閒置狀態，Server會將訊息保留住直到手機狀態可能是在"忙碌"的情況下。但想請教你們是如何定義"閒置"這件事的呢？因為它可能是使用者他們執行App，像是執行背景的Service，然後就把它丟在桌上，關了螢幕。因為可能那個Service被拿來等待接收訊息。

Debajit Ghosh: 我想你的問題是我們如何定義"閒置"這件事吧？我們是基於「螢幕是否被關閉」來做決定的。如果螢幕被關閉了一段時間，我們就把手機認作閒置或非啟用狀態。因為使用者實際上也真的沒有在看任何畫面。

觀眾︰但是程式也有可能有一支Service在背後等待接收訊息啊！

Debajit Ghosh: 如果你不想使用延遲的功能，你就不用用idle parameter功能。你如果想要有延遲功能，才需要那麼做。還有問題嗎？

觀眾︰哦，你可以再說一次嗎？

Debajit Ghosh: 抱歉，我聽不到。

觀眾︰可以再麻煩你解釋一下嗎？如果Service在背景等待訊息，而螢幕卻是關閉的，你要如何避免這種狀況呢？

Debajit Ghosh:  你的問題是「當螢幕被關閉時，如何避免訊息被延遲送出」嗎？如果你不想要訊息被延遲送出，你就不要指定idle parameter的延遲時間。parameter是選擇性使用的功能。

觀眾︰了解了，謝謝。

提問5.

觀眾︰訊息推播是否支援時區或地域性？像是指定出特定的鄉村或類似的概念？

Debajit Ghosh: 你是指地域性的問題嗎？那取決於你的App，因為你知道 - C2DM機制就只是喚醒你的裝置，你的App能做任何你想做的事。並沒有任何像你App提供的UI元件來做繼承C2DM使用的相關元件。

提問6.

觀眾︰你剛才說C2DM只支援2.2以上，但...(笑)很多人都還沒有2.2手機，也不行升到2.2。是否能夠向下支援呢？

Debajit Ghosh: 答案是否定的，因為這是新功能。我們一直不斷的在革新新功能，這是2.2提供的一個新功能。

觀眾︰意思是我們在2.2以前只能用Poll機制嗎？

Debajit Ghosh:  是的，你可以用Poll機制，當然也可以建構自己的推播系統，如果你想要，都能自己建立。

觀眾︰再一個問題，你說手機如果要收訊息，必須要先跟Server註冊才能做出發送動作。但如果說我的App已註冊了，那我們可以發送訊息給每個人，讓他們得知特定訊息嗎？

Debajit Ghosh: 你的問題是「是否能將訊息發送至所有有含該boradcast的手機裡」。這是不行的，RegistrationID是依每個app、每個裝置來做區分的。他們在裝置和app之間彼此是有劃分的，因此一則訊息無法寄到另一個App裡。你必須在你的Server端處理一連串C2DM的訊息。

提問7.

觀眾︰這個服務是不用錢的嗎？還是有任何的使用費用？在傳訊息上面是否有什麼使用上的限制？

Debajit Ghosh: 是不用錢的。而使用限制的話⋯我們會依每一位傳訊的人或依傳到特定裝置的總計來檢查是否有傳訊超量的問題。如果屆時你有用到那個量時，也許我們可以來討論這個配額(quotas)。

提問8.

觀眾︰兩個問題，當在特定時間後訊息仍未發出時，有方法去指定訊息的TTL嗎？假設使用者是離線狀態，可能訊息會超過2分鐘。

Debajit Ghosh: 問題是「是否能替訊息設定TTL？」，答案是現在還不行。但如果你真的有興趣，可以給我們一些意見回應。

提問9.

觀眾︰你剛才說如果每5分鐘就跟server要資料，會花費每天超過5~10%的電池電力。但你能說明一下C2DM機制對於電池電力減少的相關介紹嗎？舉例來說，你說當螢幕關閉狀態下，C2DM的回應時間在2秒以內，你是如何讓電池電力的使用量降低的？

Debajit Ghosh:  基本原理是「我們只有一個連線」。我們在很多的App之中緩衝連線。如果沒有連線能力而無法接收或傳送時，那只會耗相當低的電力。我們實際上去分配heartbeats - 你知道，比每5分鐘還更少的次數。我們將heartbeats分配的非常長，因此，閒置的裝置底下，如果裝置沒有去取得資料，就不會對電力造成大量的影響。當然，如果你想要大量使用，C2DM一直去喚醒手機，這當然就會造成所謂電量使用過大的問題，因此我們才會有"attenuation(防電量衰減)"功能，也因此我們才提供您可以選擇是否用「當裝置閒置時延遲發送」的機制。

提問10.

觀眾︰系統是否有5分鐘延遲？Is there a five-minute latency in the system?

Debajit Ghosh: 並沒有。heartbeats並不是每5分鐘跳一次。heatbeats的次數會比每5分鐘一次還少。你知道，有時候會到半個小時。我們去設定那個heatbeats，目的也是要保持連線能力是存活的。因為一旦你建立連線，你只是重新連線，但卻耗了更大量的資源。所以我們才會試著讓連線一直存活著。當連線是存活的狀況下，訊息也會被以非常、非常快速的時間被傳送。因此不是5分鐘的延遲時間。

提問11.

觀眾︰有任何OMA push的兼容計劃嗎？

Debajit Ghosh: 現在還沒有。

觀眾︰所以即使我有push server，我也無法用？我必須照著Google設計的方式去使用，是嗎？

Debajit Ghosh: 沒錯。如果你要用C2DM，你就要用C2DM的API。如果你想要在App上建立你想要的服務，因為這是Android，所以，你還是能自己去做你想要做的服務，像是連到OMA push server。

提問12.

觀眾︰你說你在多數App裡緩衝連線，預設的應用程式連線也是Google push服務去完成的，他們也是用這種連線方式嗎？還是說只有開發者去設定才能用這樣的功能？

Debajit Ghosh: 你的問題是「C2DM的使用方式跟原本的設計是分開的還是在一起的」，很明確的回答你他們是同一個連線，我們只是使用這個功能。我們用這個功能來推播Gmail連線人、同步行事曆和其它等等大量的需求。我們也開放到讓您完全知悉的地步。


提問13.

觀眾︰可以設定接收時段嗎？譬如早上和下午不想收到太多的訊息？

Debajit Ghosh: 還沒有那樣的功能。那些邏輯你可以設計在你的App中。

觀眾︰如果我一次發太多訊息出去，Google是不是會針對此狀況做調整？

Debajit Ghosh: 是的，那就是attenuation機制的作用。

提問14.

觀眾︰如何保證傳訊安全？我的意思是有時候訊息的內容可能是敏感話題，流程中有使用任何加密的方式嗎？

Debajit Ghosh: 使用SSL加密是一貫的機制，但記住，整體的設計並沒有要去確定訊息內容，你可以自己使用加密方式，你也可以使用payload。那些都是App層可以做的事情。喚醒手機的App並直接去跟server抓敏感性的訊息也是一種方式。我們也是用這種方式在做同步的功能的。

觀眾︰所以C2DM並不適合拿來使用在這種狀況中，是嗎？

Debajit Ghosh: 如同剛才所說，可以在App中自己攢寫此功能。

觀眾︰那訊息的認証方式為何？

Debajit Ghosh:  你的意思是要如何認證你的RegistractionID已確保別人不會偷用你的RegistractionID嗎？關於這點有2個資訊可供參考︰第1是建立RegistractionID的那個人的身份。當App server想要去發怖訊息至RegistractionID時，HTTP POST會去檢驗那個身份是否符合原來的那個人。你可以依你的喜好，可能像設密碼之類的。第2是因為RegistractionID是建在每一個App、每一臺裝置上的，你的App能和App Server互傳資訊，不要把其中的相關資訊洩漏出去，這也是一個方式。

提問15.

觀眾︰訊息的使用size為何？假設使用者在離線狀態下，訊息能儲存多久？

Debajit Ghosh: 你的問題是每封訊息的size最大能用多少嗎？答案是1K。 能存久，大概是幾個星期或1個月。

提問16.

觀眾︰從產生訊息的server的觀點來看，是否有射後不理(fire and forget)機制，或者可以收到一個確認通知(acknowledgement)？

Debajit Ghosh:  當訊息發送出去後，App server會收到一組ID，如果收到這個ID，代表訊息已經送到那隻手機上面了，並無法點對點做出傳送到達的返回通知。但是，老話一句，你仍然可以用App的邏輯，去做到當一收到通知，就馬上回報你的App server。

提問17.

觀眾︰抱歉我可能有漏掉幾個重點。這個機制一定要用Wi-Fi才能用嗎？家裡的路由器有支援嗎？

Debajit Ghosh: 你的問題是Wi-Fi能用嗎？是的，只要你有資料的連線能力，手機就有能力連到我們的server，我的意思是，你當然也就可以跟你的server溝通之類的。

相關文章︰

Android Push Notification推播機制(1)-簡介篇
Android Push Notification推播機制(2)-實務篇
Android Push Notification推播機制(3)-collapse key
Android Push Notification推播機制(4)-[狀況1]手機在飛航模式下
Android Push Notification推播機制(5)-Attenuation
Android Push Notification推播機制(6)-[狀況2]手機在待機下
Android Push Notification推播機制(7)-[實例分享]以Chrome to Phone為例
官方技術公報 - Android Cloud To Device Messaging