推送，或者叫通知，是产品非常常用的营销工具，也是产品与用户建立连接的重要手段，日常产品的推送需求，应该是产品经理非常重视的模块。这一次我们就来讨论一下，我所认为的推送的设计要点。这一次并不讨论推送的营销效果，而是单纯从推送设计需要考虑周全的点上面去梳理，但是，无论推送是什么逻辑，都和业务场景有着密不可分的关系。

在了解消息推送的设计要点之前，我们很有必要了解一下服务端与客户端在进行消息交换时的常用技术方法以及定义。

1.长连接与短链接。

所谓短链接：客户端发送请求，服务端反馈信息，如果客户端不再发送请求（可能是多个操作任务），我客户端就断开链接。

短连接一般只会在客户端与服务端间传递一次读写操作。

短连接的优点是：开发管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段，成本低。

短链接的缺点就是：服务端无法主动给客户端推送数据。

长链接：不管客户端是否要发送请求，我服务端都主动推送信息，所以客户端在整个程序运行过程中不能断开链接，而且要有维持心跳的保活机制。

2.维持长链接的方式。

（1）轮询。

客户端通过Timer或AlarmManager定期询问服务器有没有新的消息，这样服务器不用管客户端的地址是什么直接告诉它新消息即可。

轮询包括长轮询与短轮询两种。

短轮询是指：客户端向服务端请求数据，服务端立即将数据返回给客户端，客户端没有拿到想要的数据（比如返回结果告诉客户端，数据处理中），客户端继续发请求，服务端继续立即响应，周而复始。

长轮询是指：客户端在没有收到自己想要数据的情况下不断发送请求给服务端，差别在于服务端收到请求不再直接给响应，而是将请求挂起，自己去定时判断数据的变化，有变化就立马返回给客户端，没有就等到超时为止。

（2）心跳机制。

客户端和服务端建立TCP长连接之后，客户端定期向服务器发送心跳包，以保活连接，有消息的时候，服务器直接通过这个已经建立好的TCP连接通知客户端即可。

那轮询和心跳包有什么区别呢

轮询耗费性能，因为每次轮询都要经过一次TCP的连接和断开。

轮询是为了获取数据，而心跳包是为了保活TCP连接，防止NAT超时（内网和外网的映射表）

轮询设定的时间大小决定了数据获取的及时性，心跳包的发送时间间隔和数据的及时性没有太大的关系，如果心跳包发送的时间间隔大于NAT淘汰的时间会导致长连接断开。

以上信息我们先留着，待会有用。先看下我们在产品设计推送消息时需要考虑的要点。

1.落地页。

每条推送通知是否都有落地页，每个落地页面的地址是什么，落地活动过期后看到的是什么，这一点其实很容易理解，不做过多解释。

2.展示位置。

客户端有多种情况和不同位置来展示服务端推送过来的通知，可以结合业务场景以及用户是否启动app进行思考。一般常见展示位置有：定制的弹窗，顶部悬浮，站内消息列表。举个例子，比如推送消息时，用户恰好就在这个消息的落地页上，是否还给用户展示弹窗？用户如果正在启用app，只是不在这一页，是否可以考虑顶部悬浮来引导点击？

3.存在哪。

存在哪对于用户直接的影响就是，如果存在服务端，用户清除缓存或者更换设备后仍然能再次看到以往的推送。如果存在缓存，那么用户清除缓存或者更换设备后将找不到原来的消息。一般对于用户状态变更，余额变更等适合存在服务端，而营销信息可以存在缓存。要结合各自业务综合考虑。

4.存多久。

并不是所有消息都永久给用户保存，哪一类型消息保存多久，失效后如何处理，这些也是产品需要考虑到的。

5.堆积处理。

一般情况下，消息堆积发生在用户离线的时候。那么在用户上线后，积累了一大堆的消息，应该如何处理呢？此时我们注意到，如果已经考虑了消息的有效期，有些已经失效了，就不需要再推给用户，但是如果有很多消息依然处在有效期内，用户一下收到N条，其实和没收到是一个道理，完全无法达到推送目的。那么有哪些类别的消息在离线n久之后不再推送（也就是在上线前多久内的消息还给予推送），是对用户体验的一大考虑。

6.如何排序。

这里需要了解服务端和客户端在不同的推拉机制下，是如何实现消息池排序的，这时产品就更清楚结合业务场景后，应如何规定消息的排列顺序。如果用户是在线状态，那么服务端按照用户实际触发消息的时间顺序进行推送即可。但是假如用户是离线的，一般情况下，服务端按照时间顺序给全部消息排序，客户端在上线后进行正序或者倒叙的拉取。倒叙举例：比如1-16条消息在服务端依次排列，客户端按照顺序规则先请求了8-16条，此时又有一条新的第17条消息存储到服务端，客户端再次拉取消息时其实还是拉取1-7条，等1-7条拉取完了，才会再拉取最新的第17条。那么应该如何规定消息堆积时在服务端的排列顺序，是不是有些消息权重很高要优先排序优先拉取？如何规定客户端与服务端获取消息的机制也是体现产品设计能力的要点。但是我要强调的是，消息推送本来就相对复杂了，有些需求优先级不高的时候可以不做要求，比如这条排序的规则。

7.异步场景处理机制。

这里就要结合业务场景，配合刚刚我们提到的，长链接常用的轮询机制。一般情况下，如果你的客户端开发工程师具备足够的用户意识，你作为产品经理在这方面有欠缺，可能也不会有太大影响，他会很自主的知道应该怎样做。但是当开发小哥哥是那种你说到了就做，不说就不做的话，你就要想清楚了。举个常用例子，比如用户此时是支付场景，最好的体验是马上就能知道支付结果，但是从系统交互来看，客户端发起支付，服务端请求内部支付系统，内部支付系统请求三方支付，三方支付请求银联，其中参与方众多，有时一个结果秒级返回，有时几分钟到一天都有可能，如果客户端一直单纯等待服务端给的通知，用户体验变得极差。轮询机制能够非常好的解决这个问题，制定轮询的频率以及尝试几次后如果没有结果如何操作等等，在提高整个用户体验的同时，也能提醒服务端在不同状态下，如何更好的包装信息给用户展示。根据上述关于长轮询和短轮询的解释，我们在付款的异步场景下，更适合用短轮询，并且需要设定好轮询的上限，在一直拿不到结果时，客户端如何给用户展示。

以上的每一个设计要点，都需要结合各自的业务场景，综合考虑。我没有给过多的案例，也没用特别多的设计建议，就是因为不同场景下，需求完全不同。但是无论什么场景，只要是推送，一定要注意考虑到：一落二展三在哪，四存五堆七异步，六的排序再考虑。