工信部出面“净化”推送，手机厂商、推送服务商干戈化解

近日，工信部旗下泰尔终端实验室发布消息称，安卓统一的推送服务（Unified Push Service，简称UPS）技术标准制定目前已取得阶段性成果。未来将由终端厂商提供系统级推送服务（类似APNS的唯一推送通道），确保App的推送消息接收。

据悉，该标准的制定是从半年前就开始着手的，参与者覆盖推送生态的上下游企业，包括：华为、小米、VIVO、OPPO、三星、魅族、中兴、酷派等国内终端厂商；百度、阿里、腾讯、奇虎科技为代表的互联网企业；个推、极光等第三方推送商；以及运营商。

对此，我们跟个推CTO叶新江聊了聊，作为第三方推送商，他全程参与标准起草，并给到了一些解读：

企业App的推送功能，此前要么是自己出人力做开发，要么是用第三方推送商。后来，手机厂商也出推送功能。这之间就存在一些博弈：比如，有的手机厂商会规定，在用户休屏时，接受不到App推送消息，再比如，第三方做推送需要在后台开进程，会消耗电量和流量，有时用户选择省电模式，手机厂商就会杀进程。而App方面自然是希望全部触达用户，尤其是当有地震预警等紧急消息时应该强力推送，所以App为了保证成功率也会采取一些技术手段，例如“相互拉起”——假设用户A、B两个应用都使用了个推的服务，若A在后台运行着，此时服务器发送了一个推送给B，虽然B没有运行，一样可以唤醒B应用收到通知（因为A和B都是使用的同一个服务也就是个推的服务）。

也就是说，终端厂商和APP厂商在消息推送服务的“限制—保活”对抗中陷入了“囚徒困境”。并且，对于企业App来说，若想利益最大化，需要同时对接第三方服务商和手机厂商的SDK，而各自的协议、标准不一，工程量不在小数。工信部认为，这是双输的局面，不如大家坐下来制定统一标准。

协商的结果就是，终端手机厂商提供一条通道，类似苹果的APNs(Apple Push Notification service）推送机制，消息不再是App层面的推送，而是经底层系统级推送通道下发，这样就保证了App的利益。

同时，对推送的内容和手段也做了约束。例如，上面提到的“相互拉起”明确规定不被允许，利用透传消息拉起App的行为也被禁止。为了保证用户体验，原则上也不支持推送消息的定制化（包括消息样式的定制化以及提示音的个性化，通知栏图标不允许使用外链），保证消息推送的公平性和用户界面的一致性。

此外，对于开发者来说，也节约成本。由于推送API的统一，未来各终端厂商将提供系统级API实现推送功能（即App无需嵌入各通道SDK）。考虑到实际情况，为了兼容已有机型，手机端还是会提供一个简单的SDK，判断手机是否支持统一推送。若支持则可以直接调用ROM API，否则按照当前已有方式进行推送（为了适配已有机型还需要保留推送SDK）。随着手机的自然更替，未来支持统一推送的终端数目会不断更加，从而逐步实现统一推送的平滑演进。