作者：冬冬/小明本文原创，转载请注明作者及出处

如果你是安卓开发者，你应该知道国内的 App 推送环境与国外不太一样，是比较混乱的。就在 10 月中旬，沪江作为开发者代表，参加了由工信部带头举办的“统一推送联盟成立大会”。对你没有听错，国家要统一 App 推送了。下面你看到的，是对这次大会的介绍，以及我们的思考。

国内安卓推送的“乱象”

由于各种各样的原因，谷歌的统一推送服务（FCM & GCM）无法在国内使用。因此，第三方服务商与手机厂商纷纷自建推送通道提供给 App 开发者使用，并维护各自 SDK 与推送服务器的长链接。

但是，维持长链接会消耗流量，以及对移动设备来说至关重要的电量，尤其当程序不在前台运行时，系统完全无法判断众多长链接的合理性，所以会“杀掉”它认为不必要的长链接。链接不存在，推送自然无法触达。为了保证触达效率，推送服务商往往都通过 App “互相唤醒”的方式，维持推送SDK 后台进程的存活与长链接。这些 SDK 进程在后台常驻或者经常唤醒，会大量消耗用户手机的电量。

于是，手机厂商开始在 ROM 级别对 App 存活进行限制，同时自建通道提供推送服务。为了保证推送效率，开发者往往都会花费成本接入各家手机厂商的自有推送服务。因此，一个 App 中会同时存在多个推送 SDK 同时发挥作用，省电的问题仍然没有得到太好的解决。另一方面，很多国内开发者在 App 推送对用户体验影响的认知上仍然不足，往往会为了用户活跃和留存指标滥用推送。

正是因为 App 开发者与手机厂商立场的“不同”，推送生态面临着“无解”的囚徒困境：厂商为了系统的纯净限制进程存活，而 App 为了推送到达率执着于后台进程的保活，整个推送体验和生态在“限制-保活”的对抗中变的越来越糟糕。

国内安卓推送生态的囚徒困境

而Android O 的出现，更是在系统层加强管控，这对目前国内包括手机厂商自建通道在内的App 推送体系是破坏性的。

这些众多的因素造成了国内安卓用户的糟糕体验和推送生态的混乱，因此建立统一的系统级推送通道变得刻不容缓。

统一推送联盟的成立

为了规范化国内的推送环境，工信部带头邀请各大手机厂商、推送服务商、App 开发者成立了统一推送联盟（United Push Alliance），在行业发展层面，技术接口层面给出规范和标准，从而解决现在推送生态混乱的问题。规范和标准会充分权衡用户，App 开发商，推送服务商，手机厂商等各方的利益，还有对于现有推送存量的兼容情况也会充分考虑。

联盟的三个夙愿

良好的用户体验。良好的推送体验，这是联盟成立之初的夙愿。为了能够实现这个夙愿，联盟提出了几个明确的工作目标，即：做到推送省电，省资源，省流量，减少用户打扰。这在一定程度上为未来的工作指明了工作方向。

共建良好生态。联盟的另外一个夙愿是希望共建良好生态，联盟希望通过多方合作，优化资源，避免重复建设，通过资源共享快速形成能力，同时需要各企业加强行业自律。只有这样，才能在国内形成一个良好的推送生态环境，才能有助于行业的长足发展。

信息安全与内容可控。联盟对推送安全，推送内容审核方面也有着严格的要求。在安全方面，所有相关接口都需要鉴权，同时引入 HTTP/2 、内容加密加强内容安全；内容审核方面，所有的推送内容需要可溯源，能够快速定位到问题内容的责任方。

推送标准的统一

在技术架构标准上，联盟已经有了初步的方向：概括来说，App 方只要接入一个统一的SDK（UPSSDK，United Push Service SDK）实现推送功能。

要实现接入一个 SDK 解决现有多推送通道的问题，需要在接口层面统一。下图详细展示了统一推送目前的架构设计：

统一推送技术架构

下面来解读这个技术架构方案。整个架构中，有四个不同职责的角色：

App 推送后台：App 推送后台向手机厂商推送服务器（推送通道）推送一条消息，当然这个过程可以走第三方推送服务厂商转发到各个手机厂商推送服务。

手机厂商推送服务：手机厂商推送服务是使用了统一技术标准的 UPS Server，将消息推送到厂商自己的手机上。各个厂商、第三方服务商的 UPSserver 对上游 App 服务器、下游设备都使用统一的接口标准。统一推送标准同时考虑 UPS 服务器之间数据可以进行一定程度上的互通。

手机设备：手机设备（固件）内置了 USP-Client（对 UPS-SDK 接口的具体实现），UPS-Client 接收到消息，对消息进行分发。由于 UPS-Client 是内置在手机固件里面的，所有应用共用唯一推送服务，所以推送服务的心跳可以在系统层保持，不需要唤醒 App，App 方也不需要做保活了，从根本上解决了耗电的问题。

App 方：对于 App 就简单了，App 方只需要接入统一的 SDK（UPS-SDK），不需要关心厂商推送通道。理论上你用什么手机就是走什么手机的推送通道了，只需要接收消息，处理消息即可。

因此，整个架构设计会保证遵守如下原则：

SDK 轻量化，尽可能只定义接口，将实现隐藏在服务侧
对接口保证统一，隐藏不同厂商（包括第三方推送）的底层技术差异
保持基本行为一致，保证不同的系统上有相同的基本行为，降低不必要的维护成本
采用业界统一的开发技术和标准
保持灵活性和扩展性

目前，整体技术标准的制定进程比较顺利。虽然还有很多技术细节尚待确认，但是我们相信，面向开发者的统一推送 SDK 测试版本在不久的将来就能和大家见面了。

推送生态的思考

推送联盟要考虑的，当然不只是只有技术标准。更难的是构建一个健康的推送生态。在这里，我提出自己的一些思考。

联盟到底维护谁的利益？

整个推送生态的角色繁多，国家（工信部）、手机厂商、推送服务商、App 开发者都有不同的利益点和诉求，想要平衡、顾及各方的利益，是十分复杂并且有难度的问题，需要在推进统一推送标准的过程中不断的思考。

但是，无论生态如何构建，商业模式如何制定，我们都应该守住最基本的底线：维护用户的利益，保证用户的推送体验是良好的。很明显，用户才是整个安卓推送甚至安卓生态的基石。没有用户，又谈何生态呢？

建立生态“增强回路”

那我们该如何维护用户的利益？根据系统动力学的理论，用户在整个推送生态的大系统中仍然是一个重要的存量，我们能直观地感受到：整体推送生态中的用户越多，生态的商业价值总体来看必然是越大的。那如何建设这样一个自增的“增强回路”？

统一推送联盟不仅仅是在技术上建立一个稳定的通道，还要在用户的体验上建设良好的产品和体验标准。我认为统一推送联盟在产品与用户体验的标准上需要做到以下两点：

用户能够自主做出选择。 目前国内对手机系统通知权限的控制都不太敏感，大部分手机厂商在应用安装时会默认打开通知权限；此外，通知权限的开关设置，厂商的入口也不尽相同，很难找到。用户如果被通知骚扰，不知道如何把通知关闭，最终只能卸载 App 甚至不使用手机。

因此，通知权限的开启与否需要适时地让用户知晓，并拥有控制权；同时，用户能够方便地找到通知权限设置的入口，随时能够开启或关闭通知。在产品设计上，我们可以适当借鉴 iOS 系统，将接收通知权限交还给用户。

将消息分层。不同消息对用户的重要程度是不一样的。一个用户的手机会安装数十甚至上百个 App，每个 App 都有可能发送通知。对用户来说，有的 App 通知需要第一时间就看到，有的等等再看也 OK，有的希望能够折叠起来一起处理。在 App 通知也处于“信息爆炸”的现状下，通知的分层管理非常必要。个别国内厂商、Android O 已经在消息分层上进行一些尝试，而这个也是必然的趋势。

通过产品与用户体验标准上的一系列优化，我们能够创建自适应的反馈机制：“好”的开发者给用户推送有价值的信息，用户乐于查看，为开发者创造价值；“坏”的开发者滥用推送，消息被屏蔽，受到惩罚，不得不变成“好”的开发者。

推送生态的自我调节

身为普通的 App 开发者，我该怎么做？

做一名自律的开发者

身为一名 App 开发者，你真正的目的是为用户创造价值，而不是为了 DAU 这些指标。你需要不断思考如何给你的用户推送真正有价值的信息，而不是为了指标一股脑将消息推送给所有的用户。

诚然，用户的数据指标仍然是非常重要的。建立用户画像，大数据精准推送的手段是同时保证用户体验和数据指标的手段，但需要投入不小的成本（尽管这必须要去做）。在过渡期间，该如何更好地约束自己？

开发者滥用 App 推送的局面，一定程度上是因为忽视了负面指标。因此，除了日活之外，可以将更多的负面指标引入 App 推送的效果观察中。通知关闭、App 卸载、以及留存降低能直观地反应一条推送带来的负面影响，有了这些指标参考，你自然就会考虑去降低推送对用户带来的伤害。

建立“简单”的推送系统

统一推送的标准离正式开始启用仍然有一定的时间，因此目前阶段送达率仍然是开发者需要重点解决的问题。

如果要保证送达率，直接的办法是同时对接多家厂商通道，甚至维护通道设备 ID 的数据。但这种做法的成本比较高，作为中小开发者，真正应该关注的是自己的业务，而不是建设一个复杂的推送系统。那如何建立一个“简单”又兼顾送到率的推送系统呢？

维护通道设备 ID 不是必要的，有其他的替代方案。不管你的产品是不是有帐号体系，你都可以通过通道的“别名”能力将你用户的 ID 或设备 ID 转化为推送的别名，你只需要通过别名推送即可。

同时，考虑把推送通道“外包”出去。同时接入多家通道是每个开发者的痛点，而现在一些推送服务商已经开始推出一系列厂商通道的整合服务，来降低开发者的接入成本。你可以根据自己的实际情况，去尝试接触这些服务商。

推送的未来

移动互联网的发展其实已经在慢慢步入尾声，有人会认为国家现在出来规范推送生态是否太慢了，其实不然。推送本质上是对用户的一种帮助。而随着技术与行业的发展，这种帮助基于推送这样的形式会越来越贴合用户的诉求，带来更多的价值：

未来的 App 推送，一定是串联多个场景的。设想一下这样一个场景：你明天要出差，并预定了明天下午的飞机票。飞机起飞前 3 个小时，你的手机收到一条推送，提醒你现在可以出发了，并根据当前路况拟定了最优的路线；刚到达机场，你也收到一条推送，告诉你现在需要前往的登机口；飞机即将到达，你又收到一条推送，告诉你行李传送带的号码......谷歌的 Google Now 就是典型的例子。它围绕你要去外地出差这一个事件，在一个事件的不同场景中通过推送适时地提醒你，成为了你真正的“生活管家”。国内的厂商 ROM 也在进行这样的尝试，我们可以预见，基于一个或多个事件，将不同场景串联起来的推送服务将会被越来越广泛的应用。

未来的 App 推送，一定是智能的。无论是上文提到的Google Now，还是消息分层，AI 技术都能发挥它的作用。Google Now 对你 Gmail 中的机票预定邮件进行文本分析，能够“猜”到你明天要坐飞机，并通过推送来帮助你规划行程；手机系统能够基于推送通知的行为，将你不想收到的消息进行折叠。未来越来越多的手机和智能设备会内置机器学习的 TPU 处理器，在设备本地就可以对用户行为进行机器学习，不断优化用户的推送体验。

面对中国特色的推送环境，大家热切希望统一推送联盟尽快成立却又对它的发展深感顾虑。是的，以目前的现状，要统一并规范中国推送环境，是有困难的，但是这个事情又必须要去做，因为规范推送环境是直接有利于用户的，也是有利于产业长远发展的。让我们拭目以待吧。