移動端推送服務主要指通過特定的服務器把實時信息及時的發送給客戶端。而在實現該功能的同時會伴隨著紅點機制或是相應的類似彈出框形式的信息展現。

推送在好的產品設計中是一個有效提高用戶活躍的功能，也是對用戶進行精準營銷的有效手段。

首先我們看下iOS的具體實現原理（以下兩種圖估計被用爛了）：

第一步，擁有推送功能的應用向iOS注冊推送服務；

第二步，應用所在的iOS操作系統向蘋果的APNS服務器請求device token，APNS根據對應的證書以及設備信息生成device token，并把該device token返回給相應的應用進行存儲；

第三步，應用把APNS返回的device token發送給具體的推送服務器。

通過以上三步具有推送功能的應用、APNS服務器、推送服務器便都具有了device token這一個標識，而具體的發送推送的過程，在可以看下圖：

Provider(推送服務器)首先把推送消息發送給APNS，APNS通過獲得推送服務器提供的device token匹配自己保持的device token列表，找到對應的能夠接受推送的手機設備，并把消息發送到對應的iOS操作系統，操作系統接受到推送消息后再在系統內通過相應的機制送達我們的APP 。

以上是iOS的整個推送流程，這部分在網上已經有許多的介紹文章，對應的我把相關的文章鏈接貼出來，有興趣的可以在仔細看下這兩篇文章：

1. ?ios推送消息的基本原理
2. iPhone的UDID與push中使用的device?token的關系

在具體的項目中主要基于第三方推SDK 實現了廣播推送、自定義定時推送、按設備標簽推送這三個功能，其中的波折只能用欲哭無淚來形容（技術人員的實力在此處有了很好的體現）。

廣播推送：一般的主流第三方推送都會提供的簡單內容推送，通過設置推送源的相關屬性，可以使得所有保持連接的用戶無差別接收推送消息，并且在點擊通知欄信息時可以進行直接跳轉。

自定義定時推送：借助第三方推送SDK進行二次開發，實現在后臺編輯內容并設置推送時間后，用戶可以在特定時候接收到推送消息，并且在設定時間內打開應用可以直接彈出推送信息的入口彈窗。

按設備標簽推送：簡單的精準推送，可以在用戶的某些行為下產生用戶標簽并進行記錄，然后再通過在發送推送時設置不同的標簽實現對不同的用戶推送不同的消息。

通過以上兩篇文章，相信你一定可以詳細的了解推送功能的機制。我也不再累贅，以下主要說下我遇到的一些坑（很多都是淚?。?/p>

1、在設計推送功能時一定要配套的規劃好紅點的機制。

推送只會到達應用外層，不會對應用內的功能進行控制（除非已經做了一些特定推送功能的開發）。如果光有推送功能，會在用戶的手機的通知欄產生相應的提示信息；用戶若是直接點擊通知欄提示信息，那么可以通過設置推送內容直接進行跳轉。

但大量的事實告訴我們用戶很多時候不會通過點擊通知欄進入應用，而是直接點擊應用圖標進入應用（推送會觸發應用icon產生紅點，而紅點的用戶習慣已經被普遍培養起來了）；此時在用戶在進入用戶的首頁時，并不知道你剛剛推送的消息具體是那個模塊的。如此推送的作用便由于沒有引導物而不能產生價值。

2、在以上分析原理的文章中，一再提到一個叫做device token的東西，可能很多人會問這是個什么東西（這個東西只在iOS中存在）？

簡單的說就是APNS識別iOS操作系統的唯一標識符，通過這個東西APNS才能找到對應APP所在的手機。而這個東西又會和應用的證書有一定的關聯性，而這個證書在具體的應用開發中讓我這個產品經理踩了好多坑。

一次是技術人員由于證書要到期的原因，重新生成了證書，但是由于我們在線上的證書還是老版本，所以造成推送功能沒法使用。另外證書在iOS的開發中一般是存在兩個的，一個測試證書一個正式環境的證書，而如果對這兩個證書的使用稍有不當不單單是對推送功能會產生影響，還會在具體的測試中造成不必要的麻煩。

3、上面第二點主要是在iOS中遇到的坑，在說說在安卓中遇到的。

安卓的推送和iOS稍微有點不同，在國內一般不存在像APNS這種官方的中間服務器，所以一般都是通過推送服務器和客戶端保持長鏈接而實現推送的。但一般情況下系統因為本身機制的問題，會不斷的殺死長鏈接（續航、內存管理等機制）；從而導致很多的情況下推送是不能送達客戶端的；而這種能夠維持穩定長鏈接的問題還是很有技術難度的，故我們在費了很多精力去設計并實現推送功能時，往往因為到達率過低而讓你沮喪。

而不同廠商改造后的安卓系統對推送功能的支持也是不一樣的，最大的區別在于推送在應用icon上產生紅點的機制，很多廠商的操作系統是不會因為推送觸發應用icon上的紅點。而解決這類問題只有提升技術實力，但是作為一個產品汪，我也是無力殺敵啊，最后對于安卓的具體實現情況我只能妥協，只祈禱著技術實力的提升。

4、安卓中另一個問題就是測試了。由于在安卓中是沒有所謂的推送測試環境的，所以一定要注意在設計之初就想好測試推送功能的方式。

我想到的有兩種：把測試和正式環境一開始就區分開。

如果是用第三方最好是有一個測試賬號還有一個正式賬號，如果是自己開發則一定要預先便把兩個環境都搭好，千萬別讓兩個環境互相干擾。

第二種就是在代碼中設置測試標簽，一般的推送都是支持按特定的標簽推送的只要預先在代碼中寫死測試系統的標簽即可，再通過設置測試標簽區分正式和測試環境。

不過推薦使用第一中方式，會安全很多。

5、關于精準推送。

現在大部分的主流第三方推送都可以做到定向推送按設備標簽、按設備號等。而在設計這種功能時一定要預先想好標簽的獲取方式，以及不同標簽的組合方式，在第三方推送的后臺中只會支持標簽之間的“或”關系；如果想要通過不同的標簽組合縮小推送用戶范圍是沒辦法實現的，最好的方式就是自己進行二次開發。而這種精準推送在測試時也是很困難的，標簽的不同組合的效果都要測試，而設備獲得標簽的時機又是比較特定的所以測試用例也是相當考驗測試人員專業性的。

以上就是我在基于第三方推送設計推送功能時遇到的若干個坑，有些是自己在設計之初對推送原理認識不夠造成的，而有些就是在項目進展中被其他的相關人員埋了坑?？偨Y這些也是希望自己在后續的產品設計中可以預先想好相應的應對方案，使自己對項目掌控的更好，減少不必要的麻煩。

同時希望自己把遇到的坑，以及填坑的過程講出來，可以和大家一起討論！

本文由 @劉志科（微信號cainiaoPM） 原創發布于人人都是產品經理?，未經許可，禁止轉載。