关于推送服务，那些隐蔽难躲的“坑”(图文)

推送服务对于app拉新、拉活、引流、保活都有十分显著的作用，其意义不可否认，但是对于推送服务你真的了解吗？文章总结了几个推送服务过程中隐蔽的坑，希望可以给大家一些警示。

随着移动互联网行业发展越来越成熟，各种各样的开发工具与标准化的解决方案，正在急速降低互联网产品的开发成本。推送服务俨然已成为移动开发中的标配服务。作为业务唯一能够主动touch用户的手段，推送服务对于app拉新、拉活、引流、保活都有着非比寻常的意义。

然鹅，作为一个多年奋战在“技术客服”一线的产品经理，我想说对于推送服务——多的是，你不知道的事~~

接下来我就以小米推送为例，跟各位开发者（产品/运营同学）简单讲讲在和形形色色的开发者对接过程中，我所见过的最隐蔽、最难躲的坑。

所有的推送服务使用的第一步，都是注册设备。其实原因和目的都是显而易见的，因为推送本身是一个点对点的行为，每台设备的客户端都需要与服务端建立一个独立的长连接用于收发消息。因此，推送服务需要对每个设备进行标示。

各家推送服务的注册接口叫法都不同，但有两点是一样的：

这一接口均为客户端接口通过调用接口后均会生成一个per app&per 设备的唯一标示

以小米推送为例，客户端注册推送的接口叫做register Push，注册成功后，会生成一个regID，regID在推送系统中是全局唯一的，mipush通过一套复杂的加密算法，保证每个app在每台设备上都不一样。

介绍完背景知识，我们来讲讲在注册设备这个看似最简单最基础的动作中隐藏的坑：设备注册的时机。

由于push SDK需要有客户端工程师手动集成到app之中，register Push的方法也需要客户端自行调用才能完成注册行为。因此，注册行为的时机就非常重要。

那么从产品层面，怎样设计注册推送的时机呢？

由于不同的产品之间，业务形态千差万别。所以很难总结一条明确的规定来指导使用者去注册推送。但每位产品经理在设计推送的使用逻辑时，一定要将这一点想到前边，了解app注册推送的时机，结合业务逻辑去决策注册推送的时机。以免为以后推送的使用埋下“神坑”。

举个简单的例子来说明一下吧：

某直播app，产品逻辑中有这样一条限制：只有登陆之后才能看到内容。即登录是强制动作。

这时候注册应该在什么时机呢？是在登录前还是登录后呢？

其实这个问题没有标准答案，要通过业务逻辑来进行设计。如果推送体系是基于账号设计的，只有登录完成之后，才能有账号，那么在登陆后注册推送听上去比较合理，没有登录的用户不作为自己的推送目标；如果推送不基于账号，而是基于设备，及时未登录的设备，也希望能够接受推送消息。那么注册时机应该在用户登录之前。即app被用户打开即可唤起推送。

一般的推送服务都会提供注册（registerPush）和注销（unregisterPush）两种接口，这两种接口都是客户端能力。用于开启和关闭推送功能。需要注意的是：调用注销接口后，之前注册的设备ID（regID）就失效了，无法继续使用。即使重新注册，也会生成新的设备ID。

所以注册行为是一种不可逆的行为，仅适用于需要完全终止推送服务的场景。

如果一直频繁的调用注册和注销接口，会有什么风险呢？

我们再举一个栗子：

还是拿刚才的直播app举例，需求是如果用户登出，则不再向该设备推送消息。客户端逻辑为：用户登陆后，调用register Push接口；用户注销后，调用unregister Push接口。按照以上行为，每次用户进行登录和登出操作，均会生成新的regID。这种行为直接导致无效的regID会越来越多。推送ID体系变得臃肿复杂。

因此，如果只是希望暂时停止推送或关闭推送能力。应当使用别的方式，而不是直接注销推送。各家基本都提供了暂停推送的接口。