小红点（应用角标消息设计）

需求分析：

什么叫小红点？

所谓的小红点，我们用最简单的场景来看的话就是我们手机app外的小红点数量。

如果需要进行小红点数量控制，那么就会涉及到几个点。

首先，需要确定：哪些消息是属于小红点需要管理的消息。

其次，还需要确认：消息已读的机制。

确定这两个点，那么基本上小红点的需求就基本明确了。

那么，现在我们来看下tophy的小红点机制。

注意：这里不对应用内的消息角标数量进行处理。

目前Tophy只对Ios端应用角标消息的控制，安卓由于系统多样且难以控制暂时不考虑。

Ios 端打开App后会使用应用内的消息数量覆写应用角标数量。

哪些消息是属于小红点需要管理的消息？

• 私聊消息

• 系统通知  （不管）

• 官方助手  （不管）

因为这里不处理系统通知和官方助手，所以会出现应用角标数量和app内的消息数量不一致的情况

消息的已读机制？

目前由于只有私聊消息会进行应用外角标数量的处理，所以目前的已读机制也是特例化的，依托于会话的已读。

基本逻辑：对已读会话的未读数量进行已读操作，那么 新的应用角标数量 = 当前应用角标的数量 - 已读的消息数量

同时，客户端会覆写应用角标数量

功能设计：

后端服务架构

在功能设计方面，主要的逻辑操作放在数据层（dpg-data），对外以RPC接口暴露操作。

由于并不需要保证小红点数量的同步性以及准确性（不需要特别精准），意味着不需要过多的异常补充措施。

目前，我们需求只需要小红点的数量，但是也需要预留接口进行具体【小红点对应的消息】的存储。

架构如下图：

发送消息流程图

用户已读会话流程图

客户端上报消息未读数：TODO

代码设计：

统一接口RPC

RedDotService.redDotDataSupport(String userId,RedOperEnum redOperEnum)

1. 新增用户红点数量并获取当前红点数量

2. 已读私聊消息操作，用户红点数量的处理。

会话未读数

1. 会话列表新增未读数信息，新增逻辑：消息的发送事件中需要异步修改 该字段值 + 1

2. 已有会话已读接口，新增逻辑：需要对会话列表 未读数信息字段 置为0 ，同时修改应用角标小红点的数量 (新的应用角标数量 = 当前应用角标的数量 - 已读的消息数量)。

私聊消息

1. 新增逻辑：调用统一接口RPC 获取最新的小红点数量（110 类型消息 忽略） 并 构建 firebase 消息体，发送firebase

可能出现的问题：