AskaEth
5a9f52a069
主人 2026-10-05 定案「那肯定要多选」：图片按钮从 PickVisualMedia（单选、回一个 Uri）换成 PickMultipleVisualMedia（系统 Photo Picker 的多选形态，仍然零权限，不退回落 SAF / 存储权限）。 文件按钮那条 OpenMultipleDocuments 一个字没动。 为什么复用分享路径那一段（不另起一套发送逻辑）： 分享落地（ChatViewModel.sendShared）早就把「一条消息只能带一张图 ⇒ N 张图 = N 条消息」做完了， 那段切分本来内联在它自己的 forEach 里，不是可复用的纯函数。这次把判据抽成纯函数 imageSendPlan （ui/chat/ImageSendPlan.kt，跟 SharePayload.kt 与 SendQueue.kt 一样的写法，可单测），投递抽成 emitPlannedMessages（私有），输入栏那条路与分享落地那条路共用同一段：两处各写一份循环，迟早会在 「哪条带正文 / 哪条带附件 / 哪条清草稿 / 超过上限怎么办」上分叉。每张图各自的解码 / 缩放 / 重编码 与「内联还是上传」的取舍仍旧逐张走既有实现（deliver 与 deliverImage），一行没改。 为什么 N 张 = N 条（而不是一条带多张）： 契约里 chat.image 是单图字段，一次上行只能带一张，所以多选进来的 N 张只能落成 N 条消息： 第一条带正文 + 第一张图 + 全部附件，其余每条一张图，顺序 = 用户在多选器里选的顺序。契约与服务端 一个字没动。 上限与告知沿用分享路径的口径： 上限仍是 ShareRules.MAX_IMAGES（4）。超限那几张不静默丢，如实告知；那句文案抽成 ShareRules.truncatedImagesNotice，分享入口与选图入口共用同一句（逐字未改，ShareNoticeTest 钉住）。 系统选择器自己会把可选张数卡在 4 上，只有回落成 ACTION_OPEN_DOCUMENT 的设备（它表达不了最多几张） 以及「草稿里已有几张、再选几张」这两种情形会真超，那时由入口与投递两处说出同一句。 其余口径与今天一致： 输入栏最多攒 4 张（到顶后不再显示图片入口），每张各自可移除；取消选择什么都不做； 发送时第一条带正文并清草稿（N 条是一次发送，草稿只清一次），失败的那一条只把自己那一张还给输入栏。 一次发送切出的多条里只有第一条套用「她忙时发消息」偏好——第 2 条起声明打断就是打断自己刚起的 上一轮（与分享路径不声明同一条理由），N = 1 时与今天逐字节相同。 顺带： - ChatUiState.draftImage（String?）改为 draftImages（List<String>），rollbackPending 把失败那张补回 待发列表（不再覆盖），输入栏渲染成每张各自带移除键的一排预览； - QueueFullOutcomeTest 里断言单图的四处改成新事实（断言一条没删）； - 新增 ImageSendPlanTest，覆盖 N = 0 / 1 / 2 / 4 / 5（超限），并钉住附件只跟第一条、顺序不重排、 超限那句与分享路径同一句。