去年筆者寫了一篇 《安卓推送這件小事》 ，現在回過頭來再看，不少地方已有些過時，趁著春節，重新思考和整理下推送這件事，這篇文章的目標受眾不僅是對客戶端推送實踐感興趣的工程師，還包括對推送的使用者體驗現狀不滿的使用者。
推送分推送需求和推送技術，推送技術由工程師實現，推送需求來自使用者，這裡的使用者包括如下幾個角色：
不同角色對推送的需求不同，或者說對推送的度量的容忍度不同。主要有以下度量維度：
而我們最該關心的是普通使用者的需求，即推送的到達率和推送內容。如果不理清上面的需求分析，即使推送技術實現得再好，也無法在實際場景獲得成功。作為工程師不能埋頭做技術，任何一項業務背後都有它的核心需求。
以上說明了做推送這個需求時的考慮問題的優先順序，在不斷的迭代過程中，還是需要把各方面都做到盡善盡美的。
在人力成本受限的情況下，客戶端實現推送不可憑一己之力，整個推送的實現過程與其說是開發，不如說是專案管理。我們來看看推送需要和哪些業務夥伴打交道：
那麼筆者是如何來看這個問題的呢，首先需要進行一次專案管理的需求轉換，上面幾個業務夥伴的分類不便管理，需要做一次重新分類，具體如下：
上面分類後是不是邏輯清楚了很多呢，但是還不夠，我們只是進行了功能上的劃分，在時序上還要想明白：
推送和通知的依賴關係，總是先收到推送，然後才有通知
需求抽象到這裡，那麼實現也就水到渠成了。
現在很多任務程師 uml 圖都懶得畫，雖然 uml 不等於架構能力，但是確實是提公升抽象和架構能力的乙個很好的工具。
圖中的每乙個方法是對推送概念的乙個抽象。
別忽視這些細節，關鍵時候可能會讓你的整個推送用起來不爽。
在這裡提到的 sdk 是推送實現的 aar 或者 jar 。
我們的推送平台策略是服務端下發的，會根據下發的vendor來決定開啟指定平台的推送，關閉其他平台的推送。但之前經常有使用者通過系統工具看到後台跑了兩個推送程序，這是怎麼回事呢？原來，推送實現為了滿足不被殺掉的需求，會盡可能地讓自己的推送程序活著，即使手動呼叫了 sdk 的 stop 方法也沒用。
這個時候只能上大殺器了，我們在 stop 方法之後延時幾百毫秒呼叫process.killprocess()方法。
大家知道 fcm 推送是要滿足一定條件的，並且即使滿足條件，也不一定可以收到推送，那麼就需要對條件的判斷有乙個策略，這個策略還在迭代，等到穩定後再講。
任何涉及到業務夥伴的事情，如果只關心技術文件或者**，可能會事倍功半，因為**是人寫的，既然你引入了別人寫的 sdk ，那麼就要去建立一條溝通路徑，包括如下方式：
相信我，當你真的發生問題的時候，直接聯絡相關人員，遠比自己除錯**來得容易。
說到這裡，是不是理解了筆者之前說的，推送這件事，本質是專案管理而不僅僅是開發呢，其實其他事情也一樣，明白了根源在**，解決問題的思路就會很不同，不會糾結於具體的技術細節，而是先確保大方向的正確性。
上面這些只是不斷迭代實踐得來的經驗，推送這件事任重而道遠，去年如火如荼的「安卓統一推送聯盟」，正是為了解決這一問題而來，但由於歷史原因和各方利益的博弈，到最終解決問題還是有不少路要走。
可能使用者最不滿意的還是前面提到的：該推的不推，不該推的瞎推。
這也是筆者寫這篇文章的目的之一，通過背後的這些思考告訴使用者，不是看不見你們的不滿，我們在努力讓推送這件事變得美好，而你們現在馬上可以做的，就是去自己關注的主題下，明確自己的推送需求，把不需要的全部關掉就好，其他事情由我們來解決。
IOS訊息推送。
本來ios開發工程師說要使用個推，但是我們是做金融的，可能需要給使用者推送訂單狀態等等。這樣的話用起來就會很不方便，於是在網上找了找資料自己動手寫了乙個。就是簡易基礎的，希望大家看了能夠有用。需要引入幾個jar包 import com.notnoop.apns.apns import com.not...
APNS推送訊息
解釋 2.當蘋果apns推送服收到來自你應用的註冊訊息就會返回一串device token給你 很重要 3.將應用收到的device token傳給你本地的push伺服器 4.當你需要為應用推送訊息的時候，你本地的推送伺服器會將訊息，以及device token打包傳送到蘋果的apns服 5.apn...
swoole訊息推送
socket.php 注釋的部分是學習的筆記 建立websocket伺服器物件，監聽0.0.0.0 9502埠 ws new swoole websocket server 0.0.0.0 9501 監聽websocket連線開啟事件 客戶端想伺服器傳送資訊是呼叫函式 ws websocket 伺服...