随着移动互联网行业发展越来越成熟，各种各样的开发工具与标准化的解决方案，正在急速降低互联网产品的开发成本。推送服务俨然已成为移动开发中的标配服务。作为业务唯一能够主动touch用户的手段，推送服务对于app拉新、拉活、引流、保活都有着非比寻常的意义。
然鹅，作为一个多年奋战在“技术客服”一线的产品经理，我想说对于推送服务——多的是，你不知道的事~~
接下来我就以小米推送为例，跟各位开发者(产品/运营同学)简单讲讲在和形形色色的开发者对接过程中，我所见过的最隐蔽、最难躲的坑。
文章分别从四个方面总结了关于推送服务过程中隐蔽的坑，会通过两期的内容分别呈现给大家，希望可以给大家一些警示。
本期，我们先从注册和注销两方面来进行探讨~
1 、一切的开始：设备注册
所有的推送服务使用的第一步，都是注册设备。其实原因和目的都是显而易见的，因为推送本身是一个点对点的行为，每台设备的客户端都需要与服务端建立一个独立的长连接用于收发消息。因此，推送服务需要对每个设备进行标示。
各家推送服务的注册接口叫法都不同，但有两点是一样的：
1)这一接口均为客户端接口
2) 通过调用接口后均会生成一个per app&per 设备的唯一标示
以小米推送为例，客户端注册推送的接口叫做registerPush，注册成功后，会生成一个regID，regID在推送系统中是全局唯一的，mipush通过一套复杂的加密算法，保证每个app在每台设备上都不一样。
介绍完背景知识，我们来讲讲在注册设备这个看似最简单最基础的动作中隐藏的坑：设备注册的时机。
由于pushSDK需要有客户端工程师手动集成到app之中，registerPush的方法也需要客户端自行调用才能完成注册行为。因此，注册行为的时机就非常重要。
那么从产品层面，怎样设计注册推送的时机呢?
由于不同的产品之间，业务形态千差万别。所以很难总结一条明确的规定来指导使用者去注册推送。但每位产品经理在设计推送的使用逻辑时，一定要将这一点想到前边，了解app注册推送的时机，结合业务逻辑去决策注册推送的时机。以免为以后推送的使用埋下“神坑”。
举个简单的例子来说明一下吧：
某直播app，产品逻辑中有这样一条限制：只有登陆之后才能看到内容。即登录是强制动作。
这时候注册应该在什么时机呢?是在登录前还是登录后呢?
其实这个问题没有标准答案，要通过业务逻辑来进行设计。如果推送体系是基于账号设计的，只有登录完成之后，才能有账号，那么在登陆后注册推送听上去比较合理，没有登录的用户不作为自己的推送目标;如果推送不基于账号，而是基于设备，及时未登录的设备，也希望能够接受推送消息。那么注册时机应该在用户登录之前。即app被用户打开即可唤起推送。
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的有效性。
详情如截图：
举个栗子：某些情况下处于为设备省电省流的考虑，希望长连接断开，但保留推送能力，则可使用这一方法。
3、正确认识送达率
送达率是每个使用推送的开发者最关心的数据指标之一，也是衡量一个推送服务靠不靠谱的关键指标。
然鹅，怎样才算送达率的正确打开方式?我以小米推送为例来解释一下这个问题~
首先需要说明的是推送服务送达率的计算方式：
分子比较容易理解，就是本次推送真正送达的设备数。
分母则是本次推送请求所覆盖的有效的设备数：如果目标对象的选取是所有用户，那分母就是历史上所有激活过推送服务的有效设备数;如果是按照标签选取的，那分母是历史上所有订阅过这个标签的有效设备数;如果是按照别名或者regID来选取，那么分母就是所请求的所有合法的别名或regID。其中，设备的有效性是通过如下规则来判断的：如果应用有以下几种行为：
1)调用unregisterPush，
2) 用户主动卸载，
3)超过3个月都没有和小米服务器建立过长连接，则会判定设备失效。
4)设置alias失败等
按照这种计算方式，会有如下几个影响送达率的因素：
① 应用的留存率。
已经卸载了app的设备，肯定是推送不到的，但按照目前的计算方式，不少卸载设备(尤其是)都会被计入分母(计划推送数)当中。
②应用所在设备的联网情况。
如果在消息有效期内，设备一直不联网，那消息也是不能送达的，但也会被计入分母当中。
③消息的有效期。
有效期越短，在有效期内联网的设备数势必就越少，因此送达率会随之下降。
④目标设备的选取。
如果选取的是全量用户，那其送达率肯定会比按照用户联网情况精准提取目标设备(如选取7天内有过打开应用行为的用户)要低。
4 APNs服务的“神坑”
作为一个有追求、有态度的推送服务，支持全平台是基本的专业能力。可是面对苹果这个神一样的厂商，再牛叉的平台都得俯首帖耳，遵从人家的规定。
市面上提供推送服务的公司在面对苹果时候，基本都会采取相同的做法：
集成APNs(Apple Push Notification service)
APNs是苹果官方提供的推送服务，由于苹果闭源的生态，所有开发者都只能使用这种方式来实现推送能力，强如微信也不例外。同时，无论是Android和iOS(包括WinPhone)，推送服务的服务端接口的定义和使用方法保持一致，在结合业务逻辑使用的过程当中，客户端的差异可以透明化。
今天在这里并不想展开讲APNs，只想吐槽一下伟大的苹果……
但凡搞过iOS开发的同学，基本都面对过同一个难题：无法获取设备的唯一标示。唯一用于标识设备的DeviceToken也会经常发生变化。
这一点其实也很好解释：如果开发者能唯一标示设备，对用户而言将会有很大的隐私风险。
开发者可能感触不深，然鹅对于推送服务而言，这几乎是令人抓狂的：无法拿到设备的唯一标示，该怎么做推送呢!
Mipush在这方面做了非常多的努力和尝试，包括使用iOS的key chain能力去存储设备标识……
然鹅，最近我看到了这样的一条新闻【截图来自MrPeak杂货铺】：
简而言之，获取唯一标示这件事情基本已经被苹果赶尽杀绝了……
无论怎样，路还得走，产品还要不断发展，相信我们后面会有更好的解决办法，帮助广大开发者解决这些难题~
以上就是我做推送的一点心得，希望能为你提供一点点帮助~
【本文是51CTO专栏“小米开放平台”原创文章，“小米开放平台”微信公众号xiaomideveloper】
