最近刚好在搭建PUSH和红点系统，整理了一些心得，跟大家聊聊这个小玩意。我们用APP的时候，见得最多的就是各种各样的红点。这些红点色彩极度饱和，以至于我们几乎无法忽略。
在意义上，它们有的告诉你还有多少未读消息，有的层层递进把你引导到一个广告入口，有的逻辑隐晦让你怎么点都消不了。
相信对于很多像我一样的强迫症患者来说，对红点真的是又爱又恨。
有红点，就总想把它点掉，而没有红点，又怕自己漏掉重要信息。
为了让大家正确认识红点，并且设计好红点系统，我准备用这篇文章聊聊：红点的前世今生，我们该如何认识红点，红点系统的坑在哪，如何做好红点机制。
红点的前世今生
红点机制2009年出现在黑莓手机上，2013年逐渐在ios平台使用，到现在几乎是APP标配。
俗话说：无红点，不套路。
从一开始的单一红点，仅仅提醒待办事项或者更新事项，演化成现在复杂的红点系统。
比如，用数量红点来提醒待办数量。
比如，用文字红点来提醒用户优惠信息。
比如，用多层红点来引导用户层层深入。
红点之所以这么有魅力，就是因为它充分利用了人类的强迫症和好奇心理，能够起到强引导的作用。
一个好的红点逻辑，应该能让用户一目了然红点：什么时候出现、为什么出现、怎么消除。
这背后需要红点机制复杂逻辑的支撑，如果做不好，就会像上面说的，让用户抓狂。但如果做得好，就能够起到影响用户心智，成倍增加转化率的效果。
红点的复杂逻辑
有些同学可能会怀疑，不就是一个红点吗，有更新出现，已阅读消除，不就可以了嘛？
这也是我一开始的想法，直到我遇到一个个坑，才知道这东西有多么复杂。
既然红点代表着更新，那么我们就聊聊更新这个概念。
对于APP来说，什么算作更新呢？
通常来讲，内容的推送时间晚于用户上次观看的时间，就说明内容对于该用户来讲是新的。
那么问题来了，内容推送时间可以后台记录，那么用户上次观看的时间，要怎么取呢？
有的同学说，取查看时的系统本地时间啊。
这是不合理的。原因是，系统本地时间是可以修改的，如果遇到用户恶意修改，红点机制就崩掉了。所以合理的方式是，由前端或后台记录当时的服务器时间，拿服务器时间作为更新判断指标。
那么新的问题又来了，既然要拿取服务器时间，那么就要跟服务器进行交互，来询问是否展示红点。而这个请求量级，是很大的。比如，用户进入微信首页时，如果有更新的朋友圈，用户需要在底部导航「发现」处看到红点，而「发现」的红点逻辑，其实是源于朋友圈有更新。也就是说，用户在进入微信首页时，已经请求到了朋友圈的更新内容逻辑。
所以，看上去简单的红点，其实是涉及到多个层级页面的一次请求，并且往往随着页面跳转和点击来触发，对服务器的压力非常大。
怎么解决呢？这块就涉及到同步和异步的逻辑。
一般来说，如果并发量大的客户端动作，我们可以通过缓存和限流来处理。比如，如果我们限定一段时间，假设是5min，在这5min内，如果请求过红点，则不再请求红点接口。这样就可以大大减少服务器的压力了。
那么，这个时间怎么定呢，是拍脑袋定5分钟吗？肯定不是的。
一般来说，这个时间要取决于后台能够承受什么频次，以及，从用户体验上讲，我们的用户能够接受多长。从用户体验上讲，如果你的用户每次操作间隔很长，并且需要红点的内容不多，那么只要设定一个略短于操作间隔的时间，就能保证用户每次操作都能触发一次红点拉取，对用户体验是影响不大的。所以，遇到类似的问题，需要通过数据分析来找到性能和体验上的平衡点。
只有这一种实现方式吗？不是的。
很多人会发现，自己还在首页，没有进行任何操作，红点却突然出现，这是怎么回事呢？
这个时候，对比于上文的前端请求，往往是后台推送的红点。
比如在进行各种运营活动的时候，在有模块更新的时候，就可以使用推送红点机制，来推一个临时红点给到客户端。日常的未读提醒红点和活动运营红点，都是APP引导，比较常用的手段。
那么解决了红点产生的问题，要如何解决多个红点的问题呢？
有的页面会出现多个红点的情况，如果这些红点的逻辑不一致，就会让用户很迷惑。比如，下面的红点表示的是有多少新增的消息你还没读，而上面的红点是一种优惠模式的提醒，这两种红点样式近似，但有区隔。如果用一样的样式，用户就会产生反射，当意义不一样的时候，用户会觉得很迷惑。
所以，如果需要有多种意义的红点，要使用不同的样式。
聊完了红点的产生、多个红点，再聊红点的消除：
通常来讲，有的信息是阅读即可，比如朋友圈。有的信息是需要点击详情查看，比如短信。那么设计他们的消失逻辑呢？有2大原则：
第一，上层页面红点逻辑跟下层页面走。如果有一个短信未读，就需要在ICON处加1，在列表页展示红点。点击进入详情后，列表页红点消失、ICON处红点减1。如果下层的红点不消失，上层的红点也不变。
第二，页面发生跳转之前，往往红点逻辑不变。如果有一个信息流页面，当你进入时，有10条红点信息，而你点击了其中1条时，再返回，其它9条是否消除？我这边的经验是，点哪个、消除哪个，哪怕其它红点消息是阅读性的，也不变。原因就是，当用户了解到自己有10个未读，而处理又必须有先后的时候，不能在用户还在处理进程中的时候，帮他把未处理的信息变成已处理。
红点消除是一个逻辑问题，大家需要根据场景来深入思考，确保把页面内、跳转、点击、曝光等情况下的消除逻辑都考虑到。
如何设计好红点？
想设计好一套好的红点机制，需要有一定的框架。
首先要明白的是，红点是一种引导用户、干预用户的机制，这种机制需要有限制，不能被滥用。
所以一般，我们都会设计红点上限。比如，同一用户，每天看到的红点数量有上限，同一个页面的红点数量有上限。相反，不加规范的话，想想我们的手机屏幕吧，被多少APP强行挂上了琳琅满目的红点。
规范过后，就是各种类型红点的机制。比如未读提醒型、个性推送型、运营型。
未读提醒型，要从里到外层层梳理，再把冲突和消除情况考虑充分。
个性推送型，要做好冲突规则的梳理，避免和未读提醒型产生冲突和歧意。
运营型，要设计多样化的红点模板样式，针对不同的意义，使用不同的推送样式和机制。
梳理完各种类型红点后，还需要进行时效性、性能的评估。
通过评估用户操作时长、频次、请求数量等数据，结合服务器性能，来选择哪些红点被限流，哪些红点需要全力保障实时刷新。
充分考虑以上情况后，才能算设计了一个合格的红点体系。
