• 同一個裝置上的同一個APP多次繫結返回的user_id相同，channel_id也相同。

• 同一個APP在不同的裝置上繫結user_id是不相同的，channel_id也不相同。

• 同一臺裝置對應唯一一個channel_id。（多個APP共用一條通道）,所以在同一臺裝置上的多個APP繫結時，它們的channel_id是相同的。

• 同一臺裝置上的不同APP對應不同的user_id。

• 不同裝置上的相同APP對應不同的一對[channel_id, user_id]

• 怎麼讓自定義賬戶體系的id跟推送賬戶[channel_id,user_id] 對應 ?

目前百度雲推送訊息只能到

• 自定義賬戶體系的id跟推送賬戶[channel_id,user_id] 對應是一次繫結就可以了嗎?

  不是！因為自定義賬戶在APP上，可能會在不同的裝置上登入，裝置對應的

  [channel_id,user_id]就會不同，所以需要實時繫結並維護對應關係。當自定義使用者登入APP時，就要重新繫結下對應關係。當用戶退出APP，就要刪除對應關係。

• 賬號傳送訊息需要注意什麼問題？

  服務端給對應的自定義使用者傳送訊息，需要通過維護的關係，來找到雲推送的

  [channel_id,user_id], 如果找不到對應關係，說明該賬號暫時未線上，自動放棄當前訊息對雲推送服務的呼叫。雲推送的前提就是，雲推送客戶端相對於雲推送伺服器是線上的。相對於業務來說，[channel_id,user_id] 對應的客戶端APP上的登陸使用者，正好是我們希望推送的使用者。這樣才完成我們賬戶體系上的一次成功推送。

• 考慮過同一臺裝置上同一APP上賬戶的切換問題麼？

  同一臺裝置上同一APP上，對應的[channel_id,user_id] 是一樣的，所以

  a賬戶登出，b賬戶登入。如果後端有需要推送的訊息給a，那麼如果不及時去除賬戶a的繫結對應關係，那麼就很會出現b會收到a的推送訊息的情況。所以後臺再處理推送的時候，由於前端在不斷的登陸登出的變化，使用者的對應關係也在變化。服務端在推送訊息，要確保獲取即時的賬戶繫結對應關係，從而告知雲推送服務端正確的推送的客戶端。

• 延遲問題

即使獲取到再即時的繫結對應關係，由於APP上切換賬號的迅速，再加上雲推送伺服器的延遲問題，那麼當訊息推送到客戶端的時候，很可能當前APP上的登入使用者，已經不是發出推送的目標使用者了，這樣就會出現推送發錯的問題。為了避免這樣的問題，訊息體格式，需要有接受使用者id（專案編號）標記，在APP端，需要增加訊息校驗，當前訊息是否是自己的訊息，如果不是，則丟棄掉，並將告知我們服務端該訊息發錯，需要重新發送。