浅谈推送服务的那些“坑”

浅谈推送服务的那些“坑”

随着移动互联网行业发展愈来愈成熟，各类各样的开发工具与标准化的解决方案，正在急速下降互联网产品的开发成本。推送服务俨然已成为移动开发中的标配服务。做为业务惟一可以主动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失败等

按照这种计算方式，会有以下几个影响送达率的因素：

1.    应用的留存率。

已经卸载了app的设备，确定是推送不到的，但按照目前的计算方式，很多卸载设备（尤为是）都会被计入分母（计划推送数）当中。

2.    应用所在设备的联网状况。

若是在消息有效期内，设备一直不联网，那消息也是不能送达的，但也会被计入分母当中。

3.    消息的有效期。

有效期越短，在有效期内联网的设备数势必就越少，所以送达率会随之降低。

4.    目标设备的选取。

若是选取的是全量用户，那其送达率确定会比按照用户联网状况精准提取目标设备（如选取7天内有过打开应用行为的用户）要低。

 

4 APNs服务的“神坑”

做为一个有追求、有态度的推送服务，支持全平台是基本的专业能力。但是面对苹果这个神同样的厂商，再牛叉的平台都得俯首帖耳，听从人家的规定。

市面上提供推送服务的公司在面对苹果时候，基本都会采起相同的作法：

集成APNs（Apple Push Notification service）

APNs是苹果官方提供的推送服务，因为苹果闭源的生态，全部开发者都只能使用这种方式来实现推送能力，强如微信也不例外。同时，不管是Android和iOS（包括WinPhone），推送服务的服务端接口的定义和使用方法保持一致，在结合业务逻辑使用的过程中，客户端的差别能够透明化。

今天在这里并不想展开讲APNs，只想吐槽一下伟大的苹果……

但凡搞过iOS开发的同窗，基本都面对过同一个难题：没法获取设备的惟一标示。惟一用于标识设备的DeviceToken也会常常发生变化。

这一点其实也很好解释：若是开发者能惟一标示设备，对用户而言将会有很大的隐私风险。

开发者可能感触不深，然鹅对于推送服务而言，这几乎是使人抓狂的：没法拿到设备的惟一标示，该怎么作推送呢！

Mipush在这方面作了很是多的努力和尝试，包括使用iOS的key chain能力去存储设备标识……然鹅，最近我看到了这样的一条新闻：

http://mp.weixin.qq.com/s?__biz=MzI5MjEzNzA1MA==&mid=2650264371&idx=1&sn=d23e515528e5d894a8d79558a48f73d1&chksm=f4068206c3710b1089d87c6727915488cddc94c08e4a928bac7e9809d9857fc4493ba7a36ae0&mpshare=1&scene=1&srcid=0314yXPCqwzN26Z7kuKmOVIO#rd

（此处为转载内容）

简而言之，获取惟一标示这件事情基本已经被苹果赶尽杀绝了……做为一个有操守的推送服务，我仍是很是想骂人……

不管怎样，路还得走，产品还要不断发展，相信咱们后面会有更好的解决办法，帮助广大开发者解决这些难题~

以上就是我作推送的一点心得，但愿能为你提供一点点帮助~

 

yubin