Friend项目中的对话列表自动刷新问题分析与解决方案

问题现象

在Friend项目(一个基于硬件开发的社交应用)中，用户报告了一个关于对话列表刷新的问题：当用户在主页面不进行手动刷新操作时，新创建的对话不会自动出现在对话列表中。这种体验问题严重影响了用户的使用流畅性。

问题根源分析

经过技术团队深入调查，发现问题出在对话过滤机制的处理方式上。当前系统采用的是本地过滤策略，而非服务端过滤。具体表现为：

1. 客户端在获取对话列表时，会从服务端获取所有对话数据
2. 然后在前端应用本地逻辑对"已丢弃"的对话进行过滤
3. 这种设计导致新创建的对话需要手动刷新页面才能出现在列表中

技术解决方案

团队提出了将过滤逻辑从客户端迁移到服务端的解决方案：

1. 服务端改造：

   • 为GET /memories接口增加discard参数，控制是否包含已丢弃的对话，默认值为true(不包含)
   • 同样为GET memories/search接口增加相同的参数支持
   • 服务端直接返回经过过滤后的对话列表

2. 客户端改造：

   • 所有获取对话列表的请求都需要带上discard参数
   • 移除本地的对话过滤逻辑
   • 优化WebSocket连接稳定性，确保新对话能实时推送到客户端

实施过程中的挑战

在实施过程中，团队遇到了一些意外情况：

1. UI显示问题：初始实现导致对话列表垂直高度过大，影响用户体验
2. 自动刷新失效：在某些情况下，WebSocket连接断开导致新对话无法自动显示

针对这些问题，团队采取了以下措施：

• 回滚了导致UI问题的更改(#1718)
• 加强了WebSocket连接的稳定性监控
• 优化了前后端数据同步机制

最佳实践建议

基于此案例，可以总结出以下开发经验：

1. 过滤逻辑的位置选择：对于数据量较大的场景，应优先考虑服务端过滤
2. 实时性保障：关键数据更新应采用WebSocket等实时通信技术
3. 前后端协作：接口设计时应充分考虑各种过滤场景，提供灵活的查询参数
4. 渐进式改进：对于已有功能的优化，应采取小步快跑的方式，便于问题定位和回滚

这个案例展示了在实际开发中，一个看似简单的功能问题可能涉及前后端多个组件的协同工作，需要开发者具备系统思维和全栈视角。