所以在建立推送任务之前，有向大家介绍如何标识你的用户，如何选择推送服务，如何建立带有自滤功能的用户池。这一切的一切都是希望在消息推送过程中，减少消息的丢失。那么消息在推送过程中，到底为什么会丢失呢？下面为大家详细讲解。
在推送任务建立之后，即便你按照我所说的构建带有过滤功能的用户池，同时也进行了有效用户的甄别。但是在推送的目标用户中，仍然存在无效用户，这些用户也许已经卸载了你的APP，或者已经关闭了通知权限，但你并不知道。此时，这些用户注定是无法收到推送消息了。所以这是消息丢失的第一个环节，而这个问题几乎无法避免。我们只能通过一些方式尽量减少这些无效用户。
当用户卸载APP后，我们是否能知道该用户已经是无效的呢？若用户卸载APP，那么无法再通过APP告知我们的后台，这个用户已经不存在了。所以即便我们的用户池会判断用户的token是否发生变更，在此时也无法发挥作用。同时在甄别有效用户的时候，当APP卸载的一段时间内，推送服务仍然会认为该用户的token是有效的。所以在此环节也是难以判断。我个人的建议是，如果确实想要排除掉这些无效用户，可以考虑从以下两个角度入手：
（1）APP被用户卸载后，通过其他途径告知后台
如以前Android设备出现过APP卸载后，利用系统进程的某些服务来告知服务器。或 者使用其他APP的协助传输被卸载的消息（具体没尝试过，可以询问开发人员…
（2）甄别有效用户时，实际给该用户预先推送
此方法我在上一篇有提到过，实际推送是排查的有效方式，但是！预先推送空白通知， 如在苹果设备上，可能会被展示给用户看，对用户造成困扰。同时即便是预先推送测试， 用户收不到也可能是偶发的情况，只能在多次推送收不到的情况下，标记为疑似无效用户。
若用户关闭通知权限，此时也有一个办法能解决。用户关闭通知权限后，若开启APP，则可通过APP检测到权限是被关闭的，并告诉服务端这个用户已经失效且不可再推送了。当然这个方法仍然不是万全之策，若用户关闭通知权限之后，没有再启动过APP，那么此时如何告诉服务端，又是个难题。
所以在推送过程中，像上述情况因为用户已经无效，就已经丢失了一部分推送消息了。即便我们通过一些策略减少该问题的发生，仍然会不可避免的掺杂一些无效用户。那么除此之外还有什么情况会导致消息的丢失呢？
你的用户失联了即使用户没有卸载APP，也没有关闭通知权限，此时你仍然有可能无法把消息推送给你的用户。在上一篇我有提到过，在推送任务开始的时候，需要与客户端所在的设备建立长连接，通过设备中的推送服务进程完成消息的传递。但是有可能无法建立连接导致用户‘失联’，这个原因其实我在第二篇有提到过。原因可能如下：
- 推送服务进程被系统*死
- 推送服务进程被第三方软件*死
- 设备无法建立长连接
先从第3个原因来看，这是最容易理解的，用户设备处于某种异常状态情况下，推送服务无法与用户建立长连接，或者长连接失效等情况存在，此时需要推送服务多次尝试与设备建立连接，若仍无法建立，则无法进行下一步的推送。那么我们回过来看前2个原因，都是因为Android推送服务进程被*死，导致无法正常推送消息。这种情况多发生在Android推送时，使用第三方推送服务，系统的安全管家/省电模式将会把这些进程*死（如OPPO）或第三方软件如某某管家、某某卫士等把进程*死。如何避免这个问题的发生呢？可以考虑以下方案：
（1）考虑使用系统级推送
即接入你的用户主流设备系统的推送服务，假设你的用户主要使用华为、小米、OPPO、等设备，则可以考虑把这些推送服务都接入。但是随之而来的是研发成本、技术难题、维护成本等。
（2）使用大部分APP接入的推送服务
在第二篇也曾介绍过，若你的APP与其他主流APP均使用相同的推送服务，即便用户的设备把推送服务*死后，若用户使用与你的APP同一家推送服务的其他APP，则可以实现相互唤醒。这样做的优先是接入研发成本较低，维护较为容易。但是缺点是过度依赖于用户的行为，用户若未开启这些APP，则被系统*死的问题仍然难以解决。
总结来说，你要想尽一切办法让推送服务能在用户的设备中存活下来，当然此问题在苹果系统是不存在的，APNs是苹果唯一的系统级通道。而也是由于Android品牌的定制化及开放性问题，让市场上的Android品牌有各自改造过的系统、自己的推送服务通道、自己的系统管理机制。对于推送设计者和应用开发来说确实会造成一定的困扰。其实如果你请研发工程师反编译一些大厂出品的APP，你就会发现他们也会面对这些问题。有些APP选择和Android品牌手机厂商合作，让它的APP成为系统级服务。有些APP也会接入多种Android设备品牌提供的系统级推送服务，即便接入成本比较高，也会力求消息能正常到达。
推送服务的问题即便排除了用户的有效性问题及负责长连接的进程能正常运用，天仍有不测风云。即便是苹果的APNs推送都不敢保证推送通知消息能百分百到达。推送服务作为一种服务也会存在故障、拥堵、丢失等情况，对于这种情况的存在几乎是不可避免的。当进行大批量发送时，这些情况都是偶有发生的。
对于推送服务拥堵、故障的问题，需要考虑推送服务提供商的规模及资质，部分推送服务拥有多个推送通道，可以同时容纳大批量的推送任务同时执行。这样出现拥堵的风险就能得到降低。但是对于我们作为推送系统的设计者来说，是需要正视这些偶发性的问题及服务故障问题的存在。及时这些问题存在，其实它在推送过程中所占消息丢失的比例很低。由于推送进程被*死或者用户Token失效造成消息丢失的情况才是大头。
用户设备环境复杂上面曾经讲述用户设备若无法与推送服务保持长连接，或者推送服务进程被*死，此时会造成消息的丢失。其实除此以外，用户设备所处在环境对消息能否正常到达，是否可以正常路由显示也起着非常重要的因素。
你可能遇到过这么一种情况：在火车收到一条推送消息，讲的是几个小时前的即时新闻，你会吐槽到这个新闻推送一点也不及时。其实是因为你的设备处于弱网或无网状态，例如在电梯里、地铁上等弱网环境中，推送消息即时已经发出，但是由于网络情况差，而无法及时的显示在设备上。在这个过程中，网络状态较差的时候，推送服务将会替你把消息暂时存储下来，待重新接入良好的网络环境再重新暂时。这样虽然消息无法及时到达，但已经能减少消息丢失的几率。可是在这个过程中消息丢失仍是不可避免的，仍然存在由于设备网络环境差造成的消息丢失。例如当设备较长一段时间处于关机或无网状态，当突然正常接入网络后，大量的推送消息被路由展示，在这个过程中就很有可能出现消息丢失。
点击率低，不一定是真的低也许你会觉得推送点击率一般都比较低，Android在10%左右，IOS在5%左右已经不错了。那也许是你认识的点击率不是真的点击率。下面先给大家介绍概念：
- 发送成功率：建立推送任务成功数/计划发送用户总数
- 下发成功率：推送服务实际下发数/推送服务计划发送量
- 推送到达率：推送实际达到设备数/推送服务下发量
- 推送点击率：用户点击推送数/推送实际到达设备数
看着是不是有点抽象，待我详细介绍一遍。发送成功率指的是从你的推送系统服务端发传输到推送服务平台的成功率，这个时候做了有效用户的甄别等丢出，部分无效用户将会失败。所以这个成功率反应的是从你的服务端到推送服务的丢失和损耗，这个丢失一般比较小，如果此时丢失量很大的话，问题就出在服务端了。
推送平台通过长连接把推送消息进行下发，可能会遇到什么问题，在上面已经讲过了，这个过程中由于推送进程被*死导致长连接失效，会造成大量推送消息丢失，因此在这个过程中丢失的消息相对较多，同时由于部分无效设备并未在第一阶段剔除，此时也将无法实现消息的下发。故会把问题堆积在这个过程中，往往消息下发过程可能成功率仅为80%左右。
