私信
2025-12-02 17:08:33 0 举报AI智能生成
私信的核心点
作者其他创作
大纲/内容
在无网情况下发消息和重试发送的动作
在无网的情况下，手动点击发送失败的消息，会换位到最下面的位置，是因为每次重试，就是向服务器重新发消息，那msgid就重新更新为最新的，但（9890版本）的图片因为在无网络的情况下去操作重新发送是会先走url转换请求，还没到向私信服务去发请求，所以图片位置就不会变
前提：在无网络的情况下，去发图片和普通消息
未读数的计算
未知内部具体的实现逻辑
预期收到几条未读数就是几
客户端每次同步请求都会上报自己本地已经收到的某会话的消息总数和已读数，服务端会把这些信息记录
【场景】不同设备间的同一个账号的未读数
设备01和设备02的同一个会话未读数相同m条，设备01消费该会话的未读数
如果设备01消费完了，同时同步给服务端，服务端就会记录该会话的消费情况
设备02 去做同步请求的时候
服务端有下发该会话的消息，那设备02的该会话的未读数为0
这种情况没有新消息但服务端会下发，是因为这个会话曾经做过删除消息或者举报的动作
服务端下发该会话（因为刚好有新消息n条），那设备02的该会话的未读数就是n，而不是n+m，因为之前的未读数已经被设备01消费了并且通知给服务端了
设备01和设备02的同一个会话未读数相同，并同时在线
设备01进入该聊天会话，设备02停留在私信列表
设备01做删除消息的动作
删除历史消息一条（不是刚那些未读的消息）
设备02的该会话的未读数不变
删除刚那些未读的消息一条
设备02的该会话的未读数-1
消息审核
文字
同步审核（私信服务等待审核结果的时间长就走同步）
异步审核（私信服务等待审核结果的时间短，没等到结果，就转向走异步）
图片
同步审核（私信服务等待审核结果的时间长就走同步）
异步审核（私信服务等待审核结果的时间短，没等到结果，就转向走异步）
审核结果
风险
文字
接收方会在文字下方显示风险提示
如果是同步审核，收到文字消息同时显示风险提示
如果是异步审核，先收到文字，再收到审核结果，文字下方才显示风险提示文案
图片
接收方会在图片消失，显示风险提示
如果是同步审核，收到消失为风险提示
如果是异步审核，先收到图片，再收到审核结果，图片消失再显示风险提示文案
审核不通过
同步
无论和图片都不会发送成功
异步
图片
先发送成功，结果下来再撤回
调节同步/异步开关可以让开发改
消息状态
32
设置账户为发消息为32状态，找审核人员设置
这样的账户发消息给任何人，对方在聊天窗口这条消息下方都会显示提示存在风险文案
其他消息状态
关注关系？？？（待确定）
进入私信列表的时候
这个是在同步请求或者全量请求的时候 就通过长链接下发了关注关系
用户websocket一直在线，只要关注关系有变更就会下发最新的关注关系？？
进入聊天窗口的时候
会通过http请求下关注关系
私信小助手
每次冷启动或者重新登录才能触发服务端下发未接收过的小助手消息；发过的消息不会再重复下发
就算走的同步消息请求动作，其实也是用户上线了，才触发服务端下发该消息，该消息走的通道和其他普通消息不一样，deliver （普通消息）= 0
数据类型
所有消息类型发送后的数据存储；
1.文字（包含表情）
2. 图片
3.vrs视频分享
4.Pugc视频分享
5. 直播中
6. 帖子图片
7. 帖子视频
8. 网页
9. 播单
10. 文字+链接 活动
11. 标题+图片+内容+链接 活动
12. 普通直播预告
13. 小课预告
14. 播单，播单区分音频与视频
15. 概率互动表情
16.普通互动表情
17.语言动态（闪记）
18.新音频直播和音频直播回放
19.H5活动页分享长图
20.剧集合集
21.作品集
1.文字（包含表情）
2. 图片
3.vrs视频分享
4.Pugc视频分享
5. 直播中
6. 帖子图片
7. 帖子视频
8. 网页
9. 播单
10. 文字+链接 活动
11. 标题+图片+内容+链接 活动
12. 普通直播预告
13. 小课预告
14. 播单，播单区分音频与视频
15. 概率互动表情
16.普通互动表情
17.语言动态（闪记）
18.新音频直播和音频直播回放
19.H5活动页分享长图
20.剧集合集
21.作品集
服务消息下发逻辑
在设备做第一次登录进行全量请求
服务端是把（近半年？）的消息一次分段下发，每段以某些数据的消息下发（该数量是以服务端读配置的条数为准）
不是第一次登录，在设备已经存在会话的情况下去做同步请求
前端会分页向服务端做请求（每页具体条数由后台配置决定）
如果每页的数据大于服务端分段请求每段的数量，则服务端会分段下发
如果每页的数据小于服务端分段请求的每段的数量，则一次都下发了
哪些情况会触发服务下发消息
会话有新消息的时候 ，而且用户在线就会下发消息(下行)
用户在聊天窗口做删除消息的请求，请求成功后，服务端也会下发消息
客户端做登录或者杀死app再重启也会向服务端同步请求消息
如果没有新的消息，就算请求了也不会有下发消息
如果存在新消息，服务端就会下发
如果没有新消息，但会话半年内做过删除消息或者举报的动作，服务收到同步请求也会下发消息
删除消息、举报消息（上行）（http请求）
场景实例
删消息（举报）
两台设备登录同一个账号，存一个会话未读数3
其中一台设备进入该会话窗口，另一台设备杀死，前面设备在聊天窗口做删除消息（消息为刚才新收到）删除成功一条后，另一个设备重启做请求，该会话的未读数是2
其中一台设备进入该会话窗口，另一台设备同时在线，前面设备在聊天窗口做删除消息（消息为刚才新收到）删除成功一条后，另一个设备该会话的未读数也立刻更新为2
删除和举报的动作，会促使服务端做广播：有删除消息或者举报的动作，服务端就会下发会话的最新数据
多台设备登录同一个账号，且这个账号下存在一个会话有未读数，设备A对这个未读数会话进行删除一条最新消息，设备B该会话的未读数-1；且刚被删除的消息也没展示了
多台设备登录同一个账号，且这个账号下存在一个会话有未读数，设备A对这个未读数会话进行删除一条历史消息，设备B该会话的未读数-1（不会-1）；但刚被删除的消息也没展示了
删除
删除具体的消息会触发服务端下发消息
账号就在一台设备登录，在聊天窗口做删除消息，服务端就会下发该会话的最新消息数据，用户就只感觉到被删除的消息没了
账号在多个设备登录，同时在线，其中一台设备对一个会话的消息进行删除消息的动作，另一台设备也能立刻看到消息消失或者未读数有变化
删除会话不会触发服务端下发消息，删除会话是以设备为维度
比如设备01的账号01做了一个删除会话的动作，设备02的账号01的该会话一直都会在，不会应该其他设备删除会话，而引发其他设备的该账号该会话被删除
除非账号01在新设备登录，这个被删除的会话不会随着全量请求而下发
关键词
同步请求：每次登录或者杀死app再唤起就会发一次同步请求
全量请求：新app或者重装app（本地没有会话）发起请求
下行：服务端自动下发消息
上行：向服务端发消息或其他请求
发消息（http方式进行发送）
发送成功
接收方
聊天窗口显示的内容
私信列表显示的信息
push
未读数计算
发送方
聊天窗口显示的内容
私信列表显示的信息
发送失败
因为触发了隐私设置而发送失败
触发了我关注的
toast提示：“发送失败，获得对方关注后可发消息”
聊天窗口文案提示
发送方未关注接收方：文案提示：“对方设置隐私权限，无法发送消息”
触发了关注我的
toast提示：“发送失败，对方仅接收粉丝消息”
聊天窗口文案提示
发送方未关注接收方：文案提示：“对方仅接收粉丝的消息，是否关注Ta”
因为对方设置了不接受或者加入黑名单而发送失败
toast提示：“发送失败，对方暂不接受消息”
文字或者图片因为审核不通过
文字审核不通过toast：“发送消息涉及敏感内容，请重新输入”
同步审核：图片审核不通过toast：“发送消息涉及敏感内容，请重新编辑”
异步审核：图片审核不通过，文案：“注意保护隐私，谨防诈骗，如若对你造成骚扰或威胁到自身安全，请长按消息进行举报”
无网络
服务器挂了
涉及到所有的消息类型
发消息方式为http方式，内容以加密后进行参数请求
特殊场景
两台设备登录同个账号，存一个会话未读数为3
其中一台设备进入该聊天会话，发一条新消息（就只发消息，不做重新登录或者重启app），另一台未消费该会话的未读数前提下，去做重启同步请求，请求成功后该会话的未读数被消费为0
多台设备登录同一个账号，且这个账号下存在一个会话有未读数，设备A对这个未读数会话进行发消息，设备B冷启动后该未读的会话更新为已读了（因为在设备A进行发消息的时候，服务端更新该会话的已读情况，所以设备B再次同步请求下就会拿到该会话的未读数已经被消息的消息了）
收消息（两种方式）
pull拉取消息（http请求）
点击任意一条站外push进入到会话页面，此场景客户端每次请求最新的10条消息
从私信会话列表点击进入聊天会话窗口，此场景客户端每次请求最新的10条消息
在聊天窗口中下拉，会发起请求，是从当前页面的某条数据的msgid（该页面消息的时间排序较前的）作为请求参数，向服务端请求历史消息
用户websocket在线，只要有最新消息就会实时下发
全量请求
新app首次登录
同步请求
旧app做登录动作
旧app做冷启动动作
表情包相关的点
安卓端
由于环境切换为测试环境前都会先访问app是处于正式环境，就会相应先加载正式环境的表情包，----所以一旦切到测试环境如果测试环境没有配表情包，但app还是可以看到表情面板有表情，这些表情为正式环境的表情包的表情
表情包请求流程
app冷启动会向总控请求，是否有符合版本要求的表情包
在请求的时候会带上该app的版本号，如果向总控请求，有符合版本号的表情包就会，总控接口会返回下载表情包路径（新app）
在请求的时候会带上该app的版本号，如果向总控请求，有符合版本号的表情包（最新包）就会，总控接口会返回下载表情包路径（老app）
原版本号上有增量表情，则下载增量表情合并到本地表情包
存在比目前app版本的最新版本的表情，则下载最新表情包替换目前表情包
0 条评论
下一页
