最近刚好在搭建PUSH和红点系统，整理了一些心得，跟大家聊聊这个小玩意。
我们用APP的时候，见得最多的就是各种各样的红点。这些红点色彩极度饱和，以至于我们几乎无法忽略。
在意义上，它们有的告诉你还有多少未读消息，有的层层递进把你引导到一个广告入口，有的逻辑隐晦让你怎么点都消不了。
相信对于很多像我一样的强迫症患者来说，对红点真的是又爱又恨。
有红点，就总想把它点掉，而没有红点，又怕自己漏掉重要信息。
为了让大家正确认识红点，并且设计好红点系统，我准备用这篇文章聊聊：红点的前世今生，我们该如何认识红点，红点系统的坑在哪，如何做好红点机制。
红点的前世今生
红点机制年出现在黑莓手机上，年逐渐在ios平台使用，到现在几乎是APP标配。
俗话说：无红点，不套路。
从一开始的单一红点，仅仅提醒待办事项或者更新事项，演化成现在复杂的红点系统。
比如，用数量红点来提醒待办数量。
比如，用文字红点来提醒用户优惠信息。
比如，用多层红点来引导用户层层深入。
红点之所以这么有魅力，就是因为它充分利用了人类的强迫症和好奇心理，能够起到强引导的作用。
一个好的红点逻辑，应该能让用户一目了然红点：什么时候出现、为什么出现、怎么消除。
这背后需要红点机制复杂逻辑的支撑，如果做不好，就会像上面说的，让用户抓狂。但如果做得好，就能够起到影响用户心智，成倍增加转化率的效果。
红点的复杂逻辑
有些同学可能会怀疑，不就是一个红点吗，有更新出现，已阅读消除，不就可以了嘛？
这也是我一开始的想法，直到我遇到一个个坑，才知道这东西有多么复杂。
既然红点代表着更新，那么我们就聊聊更新这个概念。
对于APP来说，什么算作更新呢？
通常来讲，内容的推送时间晚于用户上次观看的时间，就说明内容对于该用户来讲是新的。
那么问题来了，内容推送时间可以后台记录，那么用户上次观看的时间，要怎么取呢？
有的同学说，取查看时的系统本地时间啊。
这是不合理的。原因是，系统本地时间是可以修改的，如果遇到用户恶意修改，红点机制就崩掉了。所以合理的方式是，由前端或后台记录当时的服务器时间，拿服务器时间作为更新判断指标。
那么新的问题又来了，既然要拿取服务器时间，那么就要跟服务器进行交互，来询问是否展示红点。而这个请求量级，是很大的。比如，用户进入
联系电话：