科客點評：工信部終于出面解決這一安卓難題， 以后安卓推送內(nèi)容將更加純凈。

　　近日，工信部旗下泰爾終端實驗室發(fā)布消息稱，安卓統(tǒng)一的推送服務(wù)（Unified Push Service，簡稱UPS）技術(shù)標(biāo)準(zhǔn)制定目前已取得階段性成果。未來將由終端廠商提供系統(tǒng)級推送服務(wù)（類似APNS的唯一推送通道），確保App的推送消息接收。

　　據(jù)悉，該標(biāo)準(zhǔn)的制定是從半年前就開始著手的，參與者覆蓋推送生態(tài)的上下游企業(yè)，包括：華為、小米、VIVO、OPPO、三星、魅族、中興、酷派等國內(nèi)終端廠商；百度、阿里、騰訊、奇虎科技為代表的互聯(lián)網(wǎng)企業(yè)；個推、極光等第三方推送商；以及運營商。

　　對此，我們跟個推CTO葉新江聊了聊，作為第三方推送商，他全程參與標(biāo)準(zhǔn)起草，并給到了一些解讀：

　　企業(yè)App的推送功能，此前要么是自己出人力做開發(fā)，要么是用第三方推送商。后來，手機廠商也出推送功能。這之間就存在一些博弈：比如，有的手機廠商會規(guī)定，在用戶休屏?xí)r，接受不到App推送消息，再比如，第三方做推送需要在后臺開進程，會消耗電量和流量，有時用戶選擇省電模式，手機廠商就會殺進程。而App方面自然是希望全部觸達用戶，尤其是當(dāng)有地震預(yù)警等緊急消息時應(yīng)該強力推送，所以App為了保證成功率也會采取一些技術(shù)手段，例如“相互拉起”——假設(shè)用戶A、B兩個應(yīng)用都使用了個推的服務(wù)，若A在后臺運行著，此時服務(wù)器發(fā)送了一個推送給B，雖然B沒有運行，一樣可以喚醒B應(yīng)用收到通知（因為A和B都是使用的同一個服務(wù)也就是個推的服務(wù)）。

　　也就是說，終端廠商和APP廠商在消息推送服務(wù)的“限制—?；睢睂怪邢萑肓恕扒敉嚼Ь场?。并且，對于企業(yè)App來說，若想利益最大化，需要同時對接第三方服務(wù)商和手機廠商的SDK，而各自的協(xié)議、標(biāo)準(zhǔn)不一，工程量不在小數(shù)。工信部認(rèn)為，這是雙輸?shù)木置妫蝗绱蠹易聛碇贫ńy(tǒng)一標(biāo)準(zhǔn)。

　　協(xié)商的結(jié)果就是，終端手機廠商提供一條通道，類似蘋果的APNs(Apple Push Notification service）推送機制，消息不再是App層面的推送，而是經(jīng)底層系統(tǒng)級推送通道下發(fā)，這樣就保證了App的利益。

　　同時，對推送的內(nèi)容和手段也做了約束。例如，上面提到的“相互拉起”明確規(guī)定不被允許，利用透傳消息拉起App的行為也被禁止。為了保證用戶體驗，原則上也不支持推送消息的定制化（包括消息樣式的定制化以及提示音的個性化，通知欄圖標(biāo)不允許使用外鏈），保證消息推送的公平性和用戶界面的一致性。

　　此外，對于開發(fā)者來說，也節(jié)約成本。由于推送API的統(tǒng)一，未來各終端廠商將提供系統(tǒng)級API實現(xiàn)推送功能（即App無需嵌入各通道SDK）?？紤]到實際情況，為了兼容已有機型，手機端還是會提供一個簡單的SDK，判斷手機是否支持統(tǒng)一推送。若支持則可以直接調(diào)用ROM API，否則按照當(dāng)前已有方式進行推送（為了適配已有機型還需要保留推送SDK）。隨著手機的自然更替，未來支持統(tǒng)一推送的終端數(shù)目會不斷更加，從而逐步實現(xiàn)統(tǒng)一推送的平滑演進。添加科客公眾號kekebat，獲取更多精彩資訊。（36氪，原標(biāo)題《工信部出面“凈化”推送，手機廠商、推送服務(wù)商干戈化解》）