今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

1.消息推送原理

客户端PULL（拉式）：每隔一段时间去服务器获取是否有数据，方案优点是简单但是实时性较差，我们也可以通过提高查询频率来提高实时性，但这又会造成电量、流量的消耗过高

服务端push(推式)：服务器在有数据的时候主动发给客户端。基于 TCP 长连接方式实现，消息实时性好，但是由于要保持 APP 客户端和服务端的长连接心跳，也会带来额外的电量和流量消耗

2.消息推送流程

业务层——通道层——客户层

• 系统接收到业务方的推送请求后，首先进行权限的验证，这包括应用 appKey 的验证、接口参数的验证、黑名单验证等。
  验证不通过，返回错误信息；验证通过后，为此条消息分配一个唯一 id（uuid），将消息内容持久化到数据库中，此时消息的状态为待发送。
  消息进入推送队列中，将之后推送接口请求的响应返回给业务方。
  推送队列的消费者从队列中取出待发送的消息，标记该条消息的状态为发送中，然后调用第三方推送服务接口进行发送。
  如果调用成功，那么标记该消息的状态为发送成功客户端未收到。
  客户端 SDK 在收到推送后，回调服务端接口，发送收到推送的回执；服务端收到客户端回执后，标记消息状态为发送成功客户端已收到。

• • 在调用第三方推送服务接口时，可能出现调用失败的情况；此时需要标记消息的状态为发送失败，留待重发。
    在调用第三方推送服务接口成功后、第三方推送服务在下发至客户端的过程中，可能由于某种原因，造成客户端无法收到消息；此时消息的状态为发送成功客户端未收到，对于这种状态，需要重发。
    客户端在收到推送的消息后、向服务端发送 ACK 回执时，可能由于网络环境的问题，造成服务端没有收到客户端发送的回执，此时消息的状态为发送成功客户端未收到，对于这种状态，需要重发。
    消息在重发 N 次（N 次可配置）、仍然没有进入发送成功客户端已收到的状态，那么将不再进行自动重发；管理界面将提供手动重发消息的操作入口，如有需要，可以手动再进行重发。监控平台对于一直重复不成功的消息会报警通知操作人员，这样操作人员可以及时通过手动方式处理。

3.消息推送目的

提高产品活跃度DAU、MAU；提高功能模块使用率、提升用户粘性、提升用户留存率

4.消息推送问题

不稳定性，消息丢失、延迟，接入复杂性，统计缺失等问题

5.消息推送方式

客户端PULL：

服务端PUSH：

6.移动消息推送方式

轮询PULL：客户端和服务器定期的建立连接，通过消息队列等方式来查询是否有新的消息，需要控制连接和查询的频率，频率不能过慢或过快，过慢会导致部分消息更新不及时，过快会消耗更多的资源（流量、电量等），对用户体验有较大伤害

短信推送SMS push；通过短信发送推送消息，并在客户端植入短信拦截模块（主要针对 Android 平台），可以实现对短信进行拦截并提取其中的内容转发给 App 应用处理，这个方案借助于运营商的短消息，能够保证最好的实时性和到达率，但此方案对于成本要求较高，开发者需要为每一条 SMS 支付费用

长连接方式push；GCM、第三方、自定义。移动 Push 推送基于 TCP 长连接实现， 客户端主动和服务器建立 TCP 长连接之后, 客户端定期向服务器发送心跳包用于保持连接, 有消息的时候, 服务器直接通过这个已经建立好的 TCP 连接通知客户端。尽管长连接也会造成一定的开销，对于轮询和 SMS 方案的硬伤来说，目前已经是最优的方式，而且通过良好的设计，可以将损耗降至最低。不过，随着客户端数量和消息并发量的上升，对于消息服务器的性能和稳定性要求提出了非常大的考验。因此，就难度而言，此方式代价最高

7.消息推送方案

系统级：

IOS平台；iOS 在系统层面与苹果 APNs（Apple Push Notification service）服务器建立连接，应用通过观察者模式向 ioS 系统注册关注的消息，系统收到 APNs Server 消息后转发到相应的应用程序，整个过程很清晰，并且所有 APP 都共用同一个系统级的连接，减少了系统开销，虽然 APNs 能无障碍的访问，但实际使用过程中，发现延时和丢消息的情况偶有发生

Andriod平台；Android 的 C2DM（Android Cloud to Device Messaging）采取与 iOS 类似的机制，都是由系统层面来支持消息推送，但是由于 Google 的服务在国内不能稳定的访问，此方案对于中国用户来说基本是无法使用的

应用级：鉴于 Android 平台 C2DM 推送的不可用性，国内涌现出大量的第三方推送服务提供商，采用第三方推送服务的系统流程如下图

第三方推送服务；个推、极光、友盟、小米、华为、BAT

8.消息推送类型

手机通知栏；在手机的通知栏（状态栏）上会显示的一条通知信息。

应用内消息；

一种方式为运营活动批量定时投放，需提供系统功能方便运营筛选用户，然后编辑文案，经审核通过后进行发送。
另一种是需要实时触发的消息，比如支付成功通知、验证码获取、满足某种条件触发的营销活动等消息，这类时效性要求较高且每个用户发送的消息内容中涉及到差异化的参数，需要业务应用实时触发

本地通知；本地通知不依赖于网络，无网条件下依旧可以触发

9.消息推送提示类型：消息类提示、浮层类提示、弹框类提示、局部嵌入式提示、错误提示

10.弹框种类：Dialog对话框、动作栏、浮层、toast、snackbar。

11.角标种类：Iocn的数字红点、彩色小点、应用内红点、应用内数字提醒、应用内文字角标

12.反馈问题分类：引导、确认、警告、传达通知、错误提示

13.反馈形式：页面、标签、动画、点击、震动、弹框、

14.消息防骚扰：推送频率、推送渠道、屏蔽、隐私、黑名单

明天计划的事情：（一定要写非常细致的内容） 

1.任务9
遇到的问题：（遇到什么困难，怎么解决的） 

1.消息推送思路混乱，原理不清，流程不定，机制还是推送方式不统一？
收获：（通过今天的学习，学到了什么知识）

1.有点乱