我是3y，一年CRUD經驗用十年的markdown程序員👨🏻💻常年被譽爲職業八股文選手
今天繼續更新Austin，給Austin新增一個發送渠道（PUSH通知欄推送）
Push通知欄消息是非常常見的，幾乎每個APP都會做這個功能（沒有消息推送的APP不是一個好的APP）
一般我們認爲Push消息能做以下的事情：
1、喚醒用戶，提高用戶的留存率，提高產品活躍度。我手機下載了APP，但我似乎把它已經忘記了(好久沒用了)，如果此時這個APP給我推送一條我有興趣的內容。我可能會繼續用這個APP，甚至從此活躍起來（購買消費)
2、告訴用戶我有新的產品上線了(帶動功能模塊使用率)。本來APP是做商城的，現在做起直播來了。但好多用戶好像都不咋留意到，此時我推送一條直播的消息給用戶，可能用戶就愛起直播了。
Push消息能夠在你手機閉屏時(即便你沒有打開APP)，通過通知來給你推送信息，是一種能夠直接觸達用戶的消息推送。相對短信而言：成本低、樣式多樣(支持標題/簡介/圖片)、鏈接跳轉直接到APP。
不過如果用戶收到不感興趣的推送可能會導致：用戶把通知消息給關閉了甚至把APP給卸載了
01、技術上如何發送通知欄消息？
要給用戶下發消息，我們得維護APP 客戶端和服務端的「長連接心跳」。這個長連接心跳如果由我們自行來維護，難度會很大，絕大部分的公司不會自建推送服務。目前我們流行手機的操作系統類型分爲兩種：安卓和iOS。
1、iOS我們默認走的是官方推送的渠道APNS。iOS 在系統層面與蘋果 APNs（Apple Push Notification service）服務器建立連接，系統收到 APNs 服務器消息後會幫我們轉發到相應的APP上。iOS端我們可以直接接入APNs服務器下發推送消息
2、安卓由於Google在國內訪問不穩定，在國內暫未統一掉推送服務（工信部牽頭成立的“安卓統一推送聯盟”還在期待中）。目前更多的是衆多的手機廠商在其定製的系統中也內置了推送功能，如小米、華爲等。由於接入成本的問題，也出現了大量的第三方推送服務提供商，比如個推、極光、友盟、信鴿等等。第三方推送服務提供商也會接入對應的手機廠商來實現對消息的下發
接入第三方服務商推送的流程大致下：
02、使用Demo SDK
正常發送PUSH是需要客戶端開發的，Austin更多關注的是服務端推送，而非客戶端的內容，所以我直接用個推提供的SDK Demo做調試。
文檔如下：https://docs.getui.com/getui/start/product/
從文檔裏以及我的實踐後發現要使用該SDK，可以分爲以下步驟：
1、登錄註冊個推賬號，得到appid、appkey、appsecret
2、下載Android版本的消息推送Demo：https://docs.getui.com/download.html
3、下載Android Studio來打開剛纔下載的SDK：https://developer.android.com/studio
4、修改config.gradle文件的賬號相關參數值：
5、編譯成功後，直接build出對應的apk
6、將apk文件給安卓的手機下載，就完事了
03、服務端推送消息
服務端文檔： https://docs.getui.com/getui/server/rest_v2/introduction/
從文檔可得知接入無非就是調用HTTP時帶有需要token（鑑權）參數。這個好辦，我們在接入釘釘工作消息的時候有過類似的操作了，寫個定時任務刷新下就完事了：
爲了照顧部分還沒把xxl-job這個定時任務框架的部署起來的同學，我專門寫了個手動刷新Token的接口。
至於服務端其他的貌似沒什麼好說，無非就增加了一點細節，直接看代碼吧：com.java3y.austin.handler.handler.impl.PushHandler
04、瞭解些技術之外的消息推送
推送的內容又可以簡單分爲以下的幾類：
- 系統功能類(消息提醒)：比如快遞簽收通知，發貨通知，關注的主播開播(上新)啦
- 營銷類（活動/優惠類）：比如某某時間開始大促，趕緊搶購
- 內容類：比如曉明哥經典語錄，穿搭風格教程
- 資訊類：新聞、時事內容推送
針對上面所說的Push推送好處以及壞處，這就非常考驗我們到底推送些什麼內容給用戶了
1、推的內容好：提高用戶留存率、提高產品活躍度、提高用戶對APP的粘度
2、推的內容差：用戶對你的內容變得麻木、直接關閉通知消息、甚至卸載APP
那麼一般我們會考慮些什麼因素呢？有以下幾個：文案、推送頻率、推送時機、、推送的人羣
關於文案，有一個叫做愛達法則（AUDA）公式：
愛達法則
相信大家都聽過UC標題，如果有一個好的文案內容那吸引用戶點擊的概率就更高一些。目前一般的推送會用一些小技巧去提高用戶的
- 在文案末尾後加上引導話術：
“點我揭曉”、“→”、“>>” - 多多利用
數字：衆多品牌3折起，更有10元的褲子，你還等什麼？ - 增加emoji表情
- 結合熱點：今天曉明哥又出新語錄！
- 更強的關聯性：比如除夕的時候，你微信收到N個祝福消息，但一看就是羣發的，沒啥意思。但此時，有個朋友給你發了條消息：“3y 春節快樂”。你就覺得有點溫馨了，是不是！
- ....
關於推送頻率，推送的頻率要控制得當，假設我在一天裏：
- 9-10點給你推條：關注這些，你的Java水平一定能提高！
- 12-14點給你推條：三年大佬經驗總結，買了就是賺到！
- 18-19點給你推條：耗時一個月整理的英語資源！一次性全部分享給你！
- 21-22點給你推條：價值1999的大數據資源，免費送給你！
那顯然，你肯定會取關我，是不是。一般來說一天用戶不能收到3天以上的推送，消息多了，算是騷擾了，甚至不能每天都給用戶推送（可能隔天推一次會好一些）。
關於推送時機，如果是資訊類的，推送的時機顯然是越早越好了，不然別人家的都推送完了，用戶都知道了。你才推送，那誰還點進去啊。
（同時作爲是官方推送的，還應保持準確性）
一般推送內容，我們都是希望在大家相對空閒的時間去推送，比如：
上班路上及早餐時間（9-10點）、午休（12-14點）、下班路上（6-7點）、睡前（21-22點）
不同的用戶羣體，時間可會有一定的調整。所以這就得尋找相對適宜的時間了。
我正寫着代碼，正在煩躁着這個Bug怎麼這麼的無厘頭時，此時一個Push推送過來：“你有一張代金券即將到期！”，那此時我真的是XXX了。
關於推送人羣，現在互聯網公司都有自己的用戶畫像系統，給同一類人推送合適的消息是較合適的。比如說：
- 有一批用戶剛註冊平臺，給這批用戶推送個優惠券，促進他的購買慾
- 有一批用戶可能身高150+，給這批用戶推薦些矮小的搭配風格推薦
- 有一批用戶的地址位置在廣州，給這批用戶推薦一下：廣州就該這麼穿，你就是整條街最靚的仔！
- …這兒可以跟文案關聯起來，這樣的推送會更加精準一些，用戶可能會點擊的概率會更高一些。
我是一個學Java的，收到的通知消息卻是：“Excel從入門到精通，只要30天！”(關鍵是我也沒關注過Excel的內容)，那此類的推送如果多了，我很可能就把這個APP刪了。
4.1 推送消息容易產生事故
爲什麼會經常出現類似的事故呢？我認爲最主要的原因是：預發和線上的環境是同一套。
衆所周知，我們的系統都有幾套的環境（比如說本地/線下/預發/線上 環境），其中大多數公司的預發和線上環境數據庫是同一套的，只是預發環境調用的是預發環境的接口，線上環境調用的是線上環境的接口而已。
推送這種系統的線上和預發環境其實沒多大的區別，因爲在底層是調用外部的接口來實現發送的，所以預發和線上環境其實調的都是同一個接口。
於是我們會在預發環境下配置了「白名單」，在白名單內的用戶才能收到消息來儘可能避免環境的問題
其次，在大多數情況下，推送事故往往是「運營」的推送導致的。運營要推送消息給用戶，首先需要圈選一個人羣去推送。
人羣量需要管控：我們在圈選的時候，如果運營圈定的人數大於一個閾值，我們會走郵箱讓主管確認是否需要圈選這麼一個大的人羣去推送。這塊有兩個目的：
1、首先我們是認爲推送的人羣應該是精細化的，什麼標籤的人羣應該收到什麼的推送。不應該圈定一個龐大的人羣去推送同一條文案的消息（新聞APP除外）。
2、即便出了事故，也只是一部分用戶能收到，而不是全體用戶。
對於很多系統其實都不需要全體用戶推送這個功能
在運營圈定人羣后，我們會有單獨的測試功能去「測試單個用戶」是否能正常下發消息，文案鏈接是否存在問題。這一個步驟是必須要做的，給用戶發出的消息，首先要經過自己的校驗。
當確認鏈接和文案都無問題後，則提交任務，走工單審批後才能發送。
如果在啓動之後發現文案/鏈接存在問題，還可以攔截剩餘未發甚至撤回部分的消息。
在線上環境消息應該有「平臺性去重」的邏輯：
1、在某段時間內，過濾掉重複消息
2、運營類消息推送（圈定人羣的方式去下發消息）同一個用戶需要相隔一段時間才能下發一次。
雖然說，我們制定了很多的規則去儘量避免事故的發生，但不得不說推送平臺還是一個容易出現事故的系統。
推薦Java開源項目
如果想學Java項目的，我還是強烈推薦我的開源項目消息推送平臺Austin，可以用作畢業設計，可以用作校招，又可以看看生產環境是怎麼推送消息的。
倉庫地址（求各位兄弟們三連喲！）
- 項目Gitee倉庫鏈接：http://gitee.com/zhongfucheng/austin
- 項目GitHub倉庫鏈接：http://github.com/ZhongFuCheng3y/austin