本文选自《程序员》杂志电子版 2015 年 6 月 B 刊，作者陈漠沙，如需转载请注明出处。
在选择和衡量第三方推送服务时，开发者首要考虑的因素就是消息的“送达率”，那么该如何理解“送达率”呢？ 推送服务的“送达率”可以达到多高？今天和大家一起来聊聊这个话题。
一次消息推送的完整流程
以 Android 平台为例，一次典型的消息推送过程如下图所示(模型已经简化):
大致的流程可以描述如下:
开发者首先将消息推送指令发送给第三方推送提供商（如友盟消息推送），告知推送服务商本次推送任务要发送的内容和目标对象。
- 我们假定该推送指令要推送给该 App 的所有用户(广播)，假设该 App 有 100W 安装量，那么“发送总数”就是 100W 。
- 推送服务商收到推送指令后，会对推送的设备集合做有效性检查，假设经有效性判断后，识别出有效设备 99W ，这 99W 设备就是该次推送任务的“接受数”。
- 有效性检查包括多个层面，基本的层面包括检查设备号 device-token 的合法性( device-token 根据一定的规则生成，如果设备号不符合生成规则，必然是无效设备)。
- 在步骤 2 筛选出的合法设备里面，第三方推送服务会选择当时长连通道在线的设备进行消息下发，我们称这部分设备为“在线设备”，假设有 40W ，我们称之为“下发数”。
- 这里说的“在线设备”表示的是设备已经联网，并且与服务器端建立了长连通道。“设备联网 & 长连通道建立”是消息下发的前提。上图中的“设备3”就是一个离线设备的例子。
- 第三方服务器对步骤 3 选择出来的“在线设备”进行消息投递，投递给设备。假设消息成功下发到设备的有 39.5W ，这个数字我们称之为“送达设备数”。
- 有可能因为网络原因，导致消息下发不成功，比如网络闪断(从而长连通道也会断掉)。一般来说，“送达设备数”和“下发数”非常接近，一般都在 98% 以上。
- 消息会首先送达设备，送达设备后，会根据 App 包名( Android 平台以包名作为 App 的唯一标识)路由给 App ，路由到 App 之后，终端用户就可以接收到通知消息了，由此消息推送的整个过程就算完成，上图中消息发到给“设备1”就是这样一个过程。
假设成功路由到 App 的消息数为 35W ，我们称为“送达 App 数”。 这个过程牵涉到较多的专业术语，我通过寄快递的例子来解释下这个过程: 假如你在上海要通过顺丰寄送一个快件给北京的友盟公司，那么快件首先会邮递到顺丰公司在北京的总站点，之后再根据友盟公司的地址投递/路由到友盟，这样一个寄件过程就算完成了。
在这里，你要寄送的快件就是你要发的“消息”，北京的友盟公司相当于最终“接收消息的App”，顺丰公司在北京的总站点相当于这里提到的“设备”，友盟公司的地址就相当于这个环节里面提到的“包名”。广义来讲，其实快递本质上也可以看做是一种消息推送~
- 消息送达设备，但最终没有成功路由到 App 的原因比较多，最常见的原因是 App 已经被删除，导致路由失败，或者在某些深度定制系统上(比如 MIUI )由于做了某些限制，如果 App 在消息送达设备后没有启动过，也会导致路由失败。"设备2"就是一个 App 已经卸载，消息可以下发到设备，但是最终路由不到 App 的例子。
由此来看，消息推送从开发者创建消息推送指令，到最终消息成功送达 App (只有送达 App 后，消息才可以正确展示出来)，中间会经过几个步骤，在每个步骤中，相关数字都会有损耗。
解读“送达率”背后的那些指标、术语
接下来解释下前面提及的几个数字概念，由此来引出我们要重点讨论的消息“送达率”定义。
发送总数: 该数字是从开发者的角度出发的，表示从开发者看到的或者认为的该次发送目标集合的个数。
接受数: 表示第三方推送服务提供商认定的合法的发送设备数。"接受数"是真实的发送总数，表示该次任务计划下发的总数。
一般来说，“接受数”和“发送总数”是非常相近的。
下发数: 表示当次发送任务创建时刻，长连在线设备的个数（上文提到，设备联网且设备长连在线是消息能够下发的前提），推送服务商会选定这些长连在线的设备，做消息下发。
送达设备数: 表示消息送达到设备的数字，注意这个仅表示送达到设备层面的数字。
送达 App 数: 消息送达到设备后，成功路由到 App 的数字。
概念明确之后，我们给出两个送达率的定义，“在线送达率”和“通用送达率”。
在线送达率: 针对长连在线的设备进行消息下发，成功送达到设备的比例(注意，定义提及的只是送达到设备，而非送达到 App 这个层面)。
在线送达率 = 送达设备数( 39.5W ) / 下发数( 40W ) 或者在线送达率=送达设备数/接收数*在线设备率≈ 98.75% ，上文中的步骤 4 说的就是在线送达率。
绝大部分推送服务提供商所宣传的高送达率其实说的就是“在线送达率”。
通用送达率: 针对该次接受的设备集合，成功送达到 App 的比例(定义提及的是送到到 App ，而非设备)。
通用送达率 = 送达 Ap p数( 35W ) / 接收数( 99W )。
这里还需要补充一点的是，上述假定的数字都是针对消息创建时刻对长连在线的设备进行下发得出的数字。
实际上，开发者发送的消息都会设定一定的有效期(比如新闻类 App 的消息有效期一般比较短，而一些公告类的通知有效期可能会比较长)。在消息有效期内，如果仍有设备上线，那么消息会继续下发，“送达设备数”和“送达App数”会继续增长，直至消息过了有效期，当次发送任务生命周期才算结束，从而消息不会再去下发了，这个不会影响“在线送达率”，但是“通用送达率”在消息有效期内是会不断提升，直至消息过了有效期。假设消息最终送达到设备有 55W ，送达到 App 有50W，那么最终的“通用送达率”应该是 50W/99W 。
通用送达率和 App 活跃度的关系
看过这两个送达率的定义之后，相信大家就能明白“送达率”的含义了。一般来讲，“通用送达率”和 App 自身的活跃度以及所属的垂直领域相关度很大。
相信大家也能观察到一个现象：在 App 集成了推送 SDK 刚上线的时候，在友盟推送后台看到的通用送达率会很高，之后会发现通用送达率就会随着时间的增长而逐步降低，直至最后稳定在一个数值上。
这就说明了通用送达率和 App 活跃度有很大的关系。不活跃的 App ，有可能是因为卸载导致，有可能是因为 App 没有启动过，导致和服务器的长连接建立不起来，从而导致服务器端无法下发消息(消息下发的前提是设备联网且和服务器的长连通道建立)。
下面我们给出一个线上真实 App 的某次发送任务，细分到 App 的活跃区间，来看看 App 活跃度对消息送达率的影响:
这里的“受理”就是我们定义的“接收数”，“送出”表示“下发数”，“通道送达”表示“送达设备数”，“送达”表示“送达 App 数”。
上图表明，随着活跃度的下降，会导致消息的“下发数”、“送达设备” 和“送达 App 数”所占比例均会大幅度的降低。
上述过程，我们解释了 Android 平台的消息送达率，对于 iOS 平台来说，一般来说都是走的苹果自身提供的 APNs (Apple Push Notification Service)通道，这个时候，我们只能拿到“发送总数”和“接受数”这两个数字，其中“接受数”表示 APNs 接受的发送数，我们无法进一步获取苹果自身的送达数。
因此，谈到消息的送达率，我们一般都是针对 Android 平台来说的。
相信大家对推送的重要指标“送达率”有了一定了解，想了解更多推送指标和使用技巧？访问友盟论坛-推送版块http://bbs.umeng.com/forum-push-1.html
关于作者：陈漠沙，友盟研发总监，消息推送业务线负责人，曾就职于雅虎北京软件研发中心，担任系统开发工程师。新浪微博@贝克汉姆老了