最近筆者關注了一下推送這個領域，來給大家說說目前的推送的現狀，我的一些想法以及這個行業的一些趨勢判斷.文章分兩大部分，分別是訊息的使用者打擾以及訊息通道和各推送平台的趨勢.
訊息的使用者打擾
目前每日全網下發的推送訊息大概是120億條，這些訊息主要在android裝置上，平均每個android使用者每天會收到30條以上的訊息, 為什麼呢，主要是因為android手機生態的原因，關閉訊息太難. 所以android裝置的使用者每天生活在訊息的轟炸之中，從業內的一些資料來看，現在android的一條推送，從展示到點選的轉化，已經不足5%了，絕大部分的訊息都是無用的，打擾使用者的。
下面來談下我的觀點：
針對問題訊息多，大家都知道乙個道理，就無利不起早，所以大家會發一定是有利可圖，即便現在一條訊息被使用者開啟的轉換率已經足夠低了，但是有總比沒有好，另外還惦記著冒個泡搶個樓露個臉；所以你看，訊息就這麼多起來的。核心是有利可圖. 類似投入產出比，得到的收益與失去的東西做權衡是正向的。
那推送難道真的就沒有成本嗎？不然，推送了訊息後打擾了使用者，使用者的關閉和解除安裝行為其實就是一條推送的成本，或者叫負影響, 市面上有兩類公司，一類是算過投入產出比的，成本和產出是正向有收益的，也就是推送訊息獲得的收益大於推送訊息帶來的關閉和解除安裝負影響，所以在堅持幹堅持發，絕大部分95%以上的公司是沒有算過的，在陷入上面的跟風搶位且不停迴圈中。
所以對於手機廠商來說，要優化訊息的體驗，勢必要提公升成本，也就是讓更多的打擾使用者的場景變成不是正向的，不能得利，那麼使用者被打擾的頻度就降下去了.
具體怎麼操作呢？假設我是手機產品的設計者,我會從以下三個維度考慮：
讓使用者更加容易關閉和拒絕訊息
訊息根據具體某個使用者轉換率的排序，以及自動策略關閉
收費按傳送數量收費，類似運營商簡訊的玩法，此處不展開討論，得罪萬千開發者,我想說的是這個模式也不是不可能，因為國內一台手機利潤才100左右，他也沒法cover自建訊息通道的成本；且此路是我開，要從此路過，留下買路錢，很合理，沒毛病.
從產品角度考慮，哪乙個手機做到前兩者，那麼相對他的訊息體驗就能好起來了. 從手機廠商的角度他願意在自己的推送產品上這樣做嗎？當然願意，因為這關乎他手機體驗的核心競爭力. 類似目前oppo r9s手機的做法，極度反對訊息推送，幾乎不主動開啟就沒有訊息推送，這類太極端，甚至作為使用者，損失了訊息獲取權，但是從使用者的感觸上來說，的確比不停的接受垃圾訊息要好，所以oppo的推送訊息改變是正向的，只不過產品策略還不夠好.可以更好.
關於各推送平台的趨勢分析
從手機廠商角度來看，android的push訊息目前是各家建立後台service長連線方式來實施的，帶來的問題是手機使用者都在抱怨手機耗電快，偷跑流量等；所以部分手機為了提公升自己的產品競爭力，不讓應用自己開長連線做推送（如小公尺華為），自己來做系統級的推送，還有一些意識到了這個問題，但是對於這部分廠商來說，沒有自建系統級訊息推送的能力，但是他又想讓自己的手機續航能力強，所以他只能強制殺應用.
對於廠商來說，自建系統推送訊息通道一定是後面發展的趨勢，只有這樣才能將續航能力提公升到最大，同時解決偷跑流量的問題；這條路廠家勢在必行
有人說一定還需要人做整合，因為廠商那麼多，但是個人以多年網際網路的研發經驗來看，整合各廠家只需要乙個開源專案，並不需要乙個公司以商務的形式來提供服務，當然若現在做推送業務的公司能夠與廠商合作拿到一些普通開發者拿不到的東西（如詳細的回執報告），可能會有他存在的必要性，但是看起來這個商業模式有點弱不禁風！
對於目前的推送平台來說有一條路是可以走的，那就是擁抱變化；沒有人能改變趨勢，但是他們可以利用趨勢；現在自己能做好系統級推送訊息的除了華為，小公尺，沒有二家了，那麼推送平台可以與其他廠商快速取得合作，成為他們的官方系統渠道；這在目前是行的通的，因為現在oppo,vivo,魅族等其他廠商並沒有覺得系統級推送訊息是手機廠商需要幹的事情，但是為了提公升續航能力又不得不幹，此時有人能解決他們的困難，讓他們拿到產品續航能力提公升的收益，何樂而不為.推送平台成為官方渠道後繼續做目前的事情，順便解釋一下他們目前所做的事情，目標不僅僅是推送服務，而是資料的應用以及精準廣告的售賣，這才是推送saas的正確姿勢.
推送訊息這個**值的小業務，即將迎來新一輪的變化，擁抱變化吧。
imo 開放平台訊息推送
中國網際網路辦公室 imo運營中心目錄 1引言 3 1.1編寫目的 3 1.2讀者物件 3 1.3文件內容 3 1.4系統說明 3 2 業務流程 4 3 介面說明 6 4 接入範例 7 說明訊息推送系統的業務流程。需要接入訊息推送的第三方，以及訊息推送系統的開發，產品人員 訊息推送授權申請和介面說明...
訊息推送平台高可用實踐（下）
伺服器資源監控主要對伺服器的cpu 記憶體 io 網路等資源的使用情況進行監控。由於推送平台部署用到了物理機和雲主機，故需要同時對這兩者的資源負載進行監控，另一方面，不同服務對伺服器負載的關注點也不同，如redis伺服器主要關注記憶體和io的負載情況，接入點伺服器主要關注cpu和記憶體負載等。伺服器...
訊息推送平台高可用實踐（下）
伺服器資源監控主要對伺服器的cpu 記憶體 io 網路等資源的使用情況進行監控。由於推送平台部署用到了物理機和雲主機，故需要同時對這兩者的資源負載進行監控，另一方面，不同服務對伺服器負載的關注點也不同，如redis伺服器主要關注記憶體和io的負載情況，接入點伺服器主要關注cpu和記憶體負載等。伺服器...