随着移动互联网行业发展越来越成熟，各种各样的开发工具与标准化的解决方案，正在急速降低互联网产品的开发成本。推送服务俨然已成为移动开发中的标配服务。作为业务唯一能够主动touch用户的手段，推送服务对于app拉新、拉活、引流、保活都有着非比寻常的意义。
然鹅，作为一个多年奋战在“技术客服”一线的产品经理，我想说对于推送服务——多的是，你不知道的事~~
接下来我就以小米推送为例，跟各位开发者（产品/运营同学）简单讲讲在和形形色色的开发者对接过程中，我所见过的最隐蔽、最难躲的坑。
文章分别从四个方面总结了关于推送服务过程中隐蔽的坑，会通过两期的内容分别呈现给大家，希望可以给大家一些警示。
本期，我们先从注册和注销两方面来进行探讨~
1 、一切的开始：设备注册
所有的推送服务使用的第一步，都是注册设备。其实原因和目的都是显而易见的，因为推送本身是一个点对点的行为，每台设备的客户端都需要与服务端建立一个独立的长连接用于收发消息。因此，推送服务需要对每个设备进行标示。
各家推送服务的注册接口叫法都不同，但有两点是一样的：
1）这一接口均为客户端接口
2） 通过调用接口后均会生成一个per app&per 设备的唯一标示
以小米推送为例，客户端注册推送的接口叫做registerPush，注册成功后，会生成一个regID，regID在推送系统中是全局唯一的，mipush通过一套复杂的加密算法，保证每个app在每台设备上都不一样。
介绍完背景知识，我们来讲讲在注册设备这个看似最简单最基础的动作中隐藏的坑：设备注册的时机。
由于pushSDK需要有客户端工程师手动集成到app之中，registerPush的方法也需要客户端自行调用才能完成注册行为。因此，注册行为的时机就非常重要。
那么从产品层面，怎样设计注册推送的时机呢？
由于不同的产品之间，业务形态千差万别。所以很难总结一条明确的规定来指导使用者去注册推送。但每位产品经理在设计推送的使用逻辑时，一定要将这一点想到前边，了解app注册推送的时机，结合业务逻辑去决策注册推送的时机。以免为以后推送的使用埋下“神坑”。
举个简单的例子来说明一下吧：
某直播app，产品逻辑中有这样一条限制：只有登陆之后才能看到内容。即登录是强制动作。
这时候注册应该在什么时机呢？是在登录前还是登录后呢？
其实这个问题没有标准答案，要通过业务逻辑来进行设计。如果推送体系是基于账号设计的，只有登录完成之后，才能有账号，那么在登陆后注册推送听上去比较合理，没有登录的用户不作为自己的推送目标；如果推送不基于账号，而是基于设备，及时未登录的设备，也希望能够接受推送消息。那么注册时机应该在用户登录之前。即app被用户打开即可唤起推送。
.jpg)
2 、不要随便注销
一般的推送服务都会提供注册（registerPush）和注销（unregisterPush）两种接口，这两种接口都是客户端能力。用于开启和关闭推送功能。需要注意的是：调用注销接口后，之前注册的设备ID（regID）就失效了，无法继续使用。即使重新注册，也会生成新的设备ID。
所以注册行为是一种不可逆的行为，仅适用于需要完全终止推送服务的场景。
如果一直频繁的调用注册和注销接口，会有什么风险呢？
我们再举一个栗子：
还是拿刚才的直播app举例，需求是如果用户登出，则不再向该设备推送消息。客户端逻辑为：用户登陆后，调用registerPush接口；用户注销后，调用unregisterPush接口。按照以上行为，每次用户进行登录和登出操作，均会生成新的regID。这种行为直接导致无效的regID会越来越多。推送ID体系变得臃肿复杂。
因此，如果只是希望暂时停止推送或关闭推送能力。应当使用别的方式，而不是直接注销推送。各家基本都提供了暂停推送的接口。
以mipush为例：
小米推送客户端SDK中提供了两种方式可以控制推送的使用或恢复使用。
1）设置推送接受时间（setAcceptTime）：这种方式可以自由控制设备每天（00:00-23:59）允许接收推送的时间，达到停止/恢复推送的目的。
详情如截图：
举个栗子：夜间不希望用户收到推送/用户可自主选择接受推送的时间
2） 关闭/打开推送（enable/disablePush）：与上边的方式不同，设置acceptTime后，长连接并未断开。但设置disablepush之后，该设备的长连接也将断开，只保留regID的有效性。
详情如截图：
举个栗子：某些情况下处于为设备省电省流的考虑，希望长连接断开，但保留推送能力，则可使用这一方法。
（以上案例截图，来源于小米开放平台：小米推送服务Android版客户端SDK使用指南）
以上是此次【关于推送服务，那些隐蔽难躲的“坑”】的前两部分内容，后续精彩内容，我们下期见~
