如何在不终止连接的情况下修改WebSocket参数，优化加密货币列表更新性能？

前端可见范围监听逻辑 #

• 监听列表滚动状态，滚动停止后通过系统API获取当前可见cell对应的加密货币唯一ID集合，iOS端可调用tableView.indexPathsForVisibleRows映射对应ID，安卓端可通过LayoutManager相关方法实现。
• 对ID集合的变化做150ms左右的防抖处理，避免滚动过程中频繁触发订阅调整请求，减少不必要的交互开销。
• 仅向服务端发送订阅的增量变更：即新增需要订阅的ID列表、需要取消订阅的滚出屏幕的ID列表，不需要全量重传订阅列表，也无需断开现有WebSocket连接。

服务端适配方案 #

自研WebSocket服务场景 #

在服务端为每个WebSocket连接维护独立的订阅ID集合，收到客户端的增量调整请求后，更新对应连接的订阅集合，后续仅向该连接推送集合内标的的行情数据即可，实现成本极低。

GraphQL Subscription场景 #

完全可以满足你的需求，它原生支持同一个WebSocket连接下动态发起/取消订阅：

• 当新标的滚动进入屏幕时，发起对应标的的行情订阅请求
• 当标的滚动出屏幕时，调用对应订阅实例的取消方法终止推送
• 全流程复用同一个WebSocket连接，不需要断开重连，完全匹配你的业务要求。

额外性能优化建议 #

• 前端收到行情推送后，不要直接调用全量刷新方法重绘整个列表，仅更新对应ID所在可见cell的UI即可，iOS端可通过tableView.cellForRow(at: indexPath)直接拿到可见cell赋值，避免不必要的渲染开销。
• 非可见标的的推送数据可做本地暂存，等用户滚动到对应位置时直接用缓存的最新数据渲染，无需等待新的推送，提升交互流畅度。
• 后续如果标的数量扩容到数百上千个，可配合服务端做分页加载，首次仅加载前2屏的标的列表并发起订阅，滚动到接近列表底部时再加载下一页标的并补充订阅，进一步降低初始化和运行时的资源消耗。

内容的提问来源于stack exchange，提问作者fuhr