AskaEth
d716d26864
W49 那条「非激活会话落了新消息 ⇒ 整表重拉 GET /sessions」换掉：整表一次要回**所有** 会话（每条一行预览 + 未读计数），而真正变了的只有一个会话。改问那条会话的消息增量 `GET /messages?after=<本端已见最大 createdAt>`，只回那几条新消息。 - MessageRepository.loadIncrement：after 方向的翻页版，翻到尾巴或 maxPages 为止； 同毫秒并列推不动游标 / 翻满页数 ⇒ complete = false，不猜、也不悄悄少给几条。 byId 去重后按 MessageOrder 升序交出去。 - InactiveSessionPull 三个纯函数：incrementCursorFor（游标 = SessionItem.lastMessageAt， 不另立账本）、incrementCursors（任一 id 问不了 ⇒ 整批回落，不混着来）、 applyIncrement（只动那一行；未读 = 越过本地已读游标的条数，与服务端 unreadCountQuery 的 count(created_at > read_at) 同源；lastMessageAt 已被别人推进过 ⇒ 整行不动，防重复计数；没改动就返回同一实例）。 - SessionsViewModel.requestSilentRefresh 带 sessionId，窗口里攒 pendingIncrements （集合，不是单个 id —— 一次窗口可能合并几个不同会话）；flushPendingIncrements 逐个问增量，三档回落整表：游标拿不到 / complete = false / 请求失败（含会话已在别处 删掉的 404）。一次批次最多回落一次。登出时清空 pendingIncrements。 - 节流与 trailing 语义一个字没动（silentRefreshStep / throttleAfterPull 签名未改）； init / 抽屉打开 / 新建 / 删除 / ContextChanged 仍走整表。增量路径不写 prefs.saveSnapshot（增量凑不出合格的 SessionSummaryDto，那会用更差的东西覆盖好快照）， 也不捎带 loadPersonas()（此前它只是跟着整表搭便车）。 量级（同 JSON 形状实测）：一次静默刷新原本 = GET /sessions 全表 + loadPersonas， 10 个会话时 4100 B、2 个请求；现在 = 1 条增量 126 B、1 个请求。 测试：新增 MessageIncrementRepositoryTest（6，真 OkHttp + 真 Retrofit + JDK com.sun.net.httpserver，验 URI 参数、满页后再问一次得空页、同毫秒并列、maxPages 用尽、404 映射、字节量对比）与 SessionIncrementTest（13，三个纯函数穷举）。 testDebugUnitTest 全绿 135 suites / 1689 tests / 0 failures / 0 errors / 0 skipped； assembleDebug 通过。