本地推送

零、引言

    如果你接触过推送，你肯定接触过个推这样的第三方推送服务平台。但这里我们介绍的推送方式，是由自己实现的，方法很简单，代价也很小。

    在笔者12-13年左右的项目，就是使用这种方案，如果你目前没法花费太多成本去使用一个第三方的推送平台，不妨花几分钟了解下，

---

一、流程介绍

流程图

    流程图上说明的比较清楚了，这里解释下可能会有疑问的地方

    1、推送策略

        举个例子：

        今天是 2018.1.24 日，2天后有个活动会上线，那么在登录的时候服务器下发 2018.1.26 00:00:00，开始推送消息。当然这只是规则1。

        我们希望能够在开始推送后的早晚高峰开始推送，这样能够保证推送能够被更多用户看到，那么登录的时候服务器下发时间： 11:00、19:00，客户端在活动开始后，于这两个时间进行推送，这是规则2。

        上述举例抛砖引玉，你肯定会有更多的灵感出来。

    2、设置本地推送

        这是客户端在接收到推送策略后，需要在本地处理的逻辑内容。当然除此之外，我们还需要将推送以下弹框的形式表现出来，IOS与Android的实现不一样，这个在网络上有很多资料可以查看。

---

二、日常维护与运营

    1、运营与维护考量

        你可能发现了，这种推送方式，并不是很适合用来支持突然提出的推送规则。

        假如线上的客户端的包，只支持 规则1，但是运营突然想支持 规则2，那么在客户端预埋推送2 规则，并且更新到线上之前，是没办法支持到 规则2 的运营需求的。

    2、运营内容的前瞻性

        为了解决上述我们，在立项初期我们就需要将推送策略考虑周全，为此在做版本1.0的时候，特别针对运营内容，我们需要考虑到3.0甚至更高的版本，然后在客户端预埋进去。        

---

三、总结

    优点：一般项目版本周期大概会在1个月左右，所以我们能做出2个月之内的推送规则，并且提前在客户端预埋进去，就能达到我们的目的了，在这个前提下我们的推送到达率是100%的。如果你对推送有研究，就知道任何第三方推送平台的到达率都不可能做到100%。

    缺点：临时策略是绝对满足不了的，一定是基于规则预埋。