AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载本指南聚焦 OperitAndroid 上的 AI Agent 与 AI 聊天应用在fix/chat-large-message-io分支中完成的超大聊天消息读取修复当单条消息内容超过 AndroidCursorWindow单行容量导致SQLiteBlobTooBigException、聊天导出中断、切换对话后内容空白时如何在不截断消息、不调整设备相关窗口容量的前提下通过固定大小的首段读取 完整字符数 同一 Room 事务内分段重组实现超大消息的安全读取。读完本文你将掌握该问题的完整成因、ChatContentDao的源码级实现原理、六大消费方的接入方式以及导出失败时清理不完整文件的配套机制。一、问题背景CursorWindow 单行容量与SQLiteBlobTooBigExceptionAndroid 的 SQLite 查询结果并非一次性全部进入 Java 层而是通过 Binder 传输到一个共享内存窗口CursorWindow中。CursorWindow对单行数据有严格的容量限制当某一行尤其是content这类大文本列超过窗口剩余容量时SQLite 会抛出SQLiteBlobTooBigException。修复前的原状见 chat_large_message_io_20260806/index.md聊天消息与消息变体通过SELECT *直接装入CursorWindow单条content超过窗口容量时抛出SQLiteBlobTooBigException聊天导出因此中断对话窗口查询把该异常转换为空列表最终表现为切换对话后内容空白。也就是说一个非常长的 AI 回复既会破坏导出功能还会让整个会话在 UI 上消失——异常被吞掉变成空数据用户看到的是空白对话。二、修复设计不截断、不调窗口、分块重组修复的总体意图非常克制明确列出三条不变量完整保留现有数据库内容与导出格式不截断消息、不丢变体不调整设备相关的CursorWindow容量不试图修改系统窗口大小读取查询只返回固定大小的首段文本和完整字符数超出部分在同一 Room 事务内继续分段读取并重组。核心思路是把一次取出完整大文本改成先取首段 长度再按需分段补齐从根上避免任何单行数据触碰CursorWindow容量上限。三、ChatContentDao源码剖析分块读取的核心实现新增的 DAO 位于 ChatContentDao.kt并在 AppDatabase.kt 中注册abstract fun chatContentDao(): ChatContentDao。3.1 分块大小常量// SQLite LENGTH/SUBSTR count characters, and this bound keeps every returned text row well below CursorWindow size. private const val CONTENT_CHUNK_CHARACTER_COUNT 65_536每块 65,536 个字符。注释点明两个关键事实SQLite 的LENGTH/SUBSTR按字符计数而非字节这个上界能保证每个返回行远低于CursorWindow大小从而规避SQLiteBlobTooBigException。3.2 首段查询SUBSTR LENGTH 双列结构消息行查询MESSAGE_CONTENT_ROW_QUERYSELECT messageId, chatId, sender, SUBSTR(content, 1, 65536) AS content, timestamp, orderIndex, roleName, selectedVariantIndex, provider, modelName, inputTokens, outputTokens, cachedInputTokens, sentAt, outputDurationMs, waitDurationMs, completedAt, displayMode, isFavorite, LENGTH(content) AS contentCharacterCount FROM messages消息变体行查询MESSAGE_VARIANT_CONTENT_ROW_QUERY结构完全一致只是表换为message_variants、主键换为variantId并追加variantIndex等变体字段。这里有两处关键设计SUBSTR(content, 1, 65536)只带回首段文本保证任何单行都远小于窗口容量LENGTH(content) AS contentCharacterCount带回完整字符数用于判断是否需要继续分段读取以及确定后续SUBSTR的起始位置。查询通过Embedded结构MessageContentRow/MessageVariantContentRow把实体列与字符数一起返回Room 会自动把查询列映射回MessageEntity/MessageVariantEntity。3.3 分段重组materializeMessage / materializeVariant公开的读取方法getMessagesForChat、getVariantsForChat等都标有Transaction内部先执行首段查询再调用materializeMessage/materializeVariant重组private suspend fun materializeMessage(row: MessageContentRow): MessageEntity { if (row.contentCharacterCount CONTENT_CHUNK_CHARACTER_COUNT) { return row.message } val content StringBuilder(row.message.content) var startCharacter CONTENT_CHUNK_CHARACTER_COUNT.toLong() 1L while (startCharacter row.contentCharacterCount) { val chunk checkNotNull( queryMessageContentChunk( row.message.messageId, startCharacter, CONTENT_CHUNK_CHARACTER_COUNT, ) ) { Message disappeared while reading content: messageId${row.message.messageId} } check(chunk.isNotEmpty()) { Message content ended before its recorded length: messageId${row.message.messageId} } content.append(chunk) startCharacter CONTENT_CHUNK_CHARACTER_COUNT } return row.message.copy(content content.toString()) }分块查询本身是单列SUBSTRSELECT SUBSTR(content, :startCharacter, :characterCount) FROM messages WHERE messageId :messageId重组逻辑要点普通消息零额外开销contentCharacterCount 65536时直接返回首段结果与修复前一样一次查询完成对应验收条件普通消息继续通过一次查询完成读取超大消息循环补齐从第 65,537 个字符开始每轮SUBSTR取 65,536 个字符追加到StringBuilder直到覆盖完整长度防御性检查checkNotNull防止读取过程中消息被删除导致空指针check(chunk.isNotEmpty())防止内容实际长度短于记录长度的静默截断——两者都会抛出明确带messageId的异常便于排查。3.4 避免大批量 IN 查询的附加设计getVariantsForMessages接收一个时间戳列表若直接把大 List 交给 Room 展开成 SQLite 绑定变量会触发绑定数量上限。源码采用范围查询 集合过滤两段式val minTimestamp messageTimestamps.minOrNull() ?: return emptyList() val maxTimestamp messageTimestamps.maxOrNull() ?: return emptyList() val rows queryVariantsForMessageRange(chatId, minTimestamp, maxTimestamp) .filter { row - row.variant.messageTimestamp in requestedTimestamps } return materializeVariants(rows)先按[minTimestamp, maxTimestamp]窗口一次查出候选行再在 Kotlin 层用HashSet精确过滤既保留精确时间戳集合语义又绕开了绑定变量数量限制。3.5 字符数聚合查询getSelectedContentCharacterCountsByChat用一条聚合 SQL 统计每个会话的选中内容字符数用于导出进度与阈值判断SELECT chats.id AS chatId, COALESCE(SUM(CASE WHEN messages.selectedVariantIndex 0 THEN LENGTH(messages.content) ELSE LENGTH(selectedVariant.content) END), 0) AS contentCharacterCount FROM chats LEFT JOIN messages ON messages.chatId chats.id LEFT JOIN message_variants AS selectedVariant ON selectedVariant.chatId messages.chatId AND selectedVariant.messageTimestamp messages.timestamp AND selectedVariant.variantIndex messages.selectedVariantIndex GROUP BY chats.id注意CASE分支当消息选中索引为 0即原始消息本身时统计messages.content否则统计对应message_variants行的content保证统计口径与展示口径一致。四、六大消费方统一切换到安全读取路径按照修复作用域所有会返回完整大文本的读取路径都改为经由ChatContentDao。以 ChatHistoryManager.kt 为例构造时private val chatContentDao database.chatContentDao()消费场景使用的安全读取方法对话展示loadDisplayHistorygetMessagesForChatgetVariantsForMessages运行时上下文分页/范围读取getMessagesForChatAscRange/getMessagesForChatDescRange/getMessagesForChatInRangeAsc等 10 余种分页、时间窗查询消息变体操作切换/删除/新增getVariantForMessage/getVariantsForMessage/getVariantsForMessages长期记忆MemoryAutoSaveScheduler.ktgetMessageByTimestamp/getMessagesForChatBeforeTimestampDesc聊天导出buildOperitArchivedChatgetMessagesForChatgetVariantsForChat导出统计与阈值判断getSelectedContentCharacterCountsByChat对话展示路径的完整链路是loadDisplayHistory→loadChatMessages读取消息实体 →chatContentDao.getVariantsForMessages(chatId, visibleTimestamps)读取变体 →hydrateMessages按selectedVariantIndex合并出最终ChatMessage。整个链路因此天然具备超大消息安全性。长期记忆场景同样接入MemoryAutoSaveScheduler从AppDatabase.getDatabase(context).chatContentDao()读取消息保证自动保存上下文时也不会因单条大消息触发窗口溢出。五、配套改动DAO 查询收口与导出失败清理5.1 移除返回完整大文本行的查询原MessageDao中直接返回完整content的查询被移除剩余查询只返回预览片段或统计值。例如 MessageDao.kt 的定位预览查询CASE WHEN sender user AND displayMode HIDDEN_PLACEHOLDER THEN ELSE SUBSTR(content, 1, :previewCharCount) END AS previewContent, ... END AS contentLength以及搜索结果高亮定位围绕命中位置取片段SUBSTR( content, MAX(1, INSTR(LOWER(content), LOWER(:query)) - (:previewCharCount / 2)), :previewCharCount ) AS previewContent而 MessageVariantDao.kt 收敛为纯写操作插入、批量插入、跨会话复制不再承担读取完整文本的职责。这样完整大文本读取只有一个出口即ChatContentDao。5.2 导出失败时删除不完整文件导出流程在 ChatHistoryManager.kt 中维护pendingExportFilecatch (e: Exception)分支统一清理} catch (e: Exception) { pendingExportFile?.let { incompleteFile - if (incompleteFile.exists() !incompleteFile.delete()) { AppLogger.w(TAG, 无法删除未完成的聊天导出文件: ${incompleteFile.absolutePath}) } } AppLogger.e(TAG, 导出聊天记录失败, e) null }删除失败只记警告、不掩盖原始导出异常返回null让调用方感知失败。这保证了导出异常不会在备份目录留下截断文件验收条件之一。此外长文本导出还有流式保护ChatHistoryManager定义了TEXT_EXPORT_STREAMING_THRESHOLD_CHARACTER_COUNT 4_000_000L等阈值超过阈值走exportLongTextHistories流式写出配合ChatExportProgress上报进度JSON 导出exportOperitArchiveJsonStream与 CSV 导出exportOperitArchiveCsvStream均按会话逐条构建归档对象并流式落盘。六、兼容性与验收修复明确承诺数据库实体、表结构、版本号和归档 JSON 结构保持不变——所有改动都发生在读取层写路径、迁移脚本与导出/导入格式未变因此已发布版本导出的归档文件可以直接导入。对照文档中的验收条件逐条映射到实现包含超大消息的对话可以正常切换和显示—— 对话展示链路全部走ChatContentDao分段读取不再有整行装入CursorWindow的路径JSON 导出可完整保留消息及变体导入后内容一致——buildOperitArchivedChat基于getMessagesForChatgetVariantsForChat重组完整文本归档结构未变普通消息继续一次查询完成读取——materializeMessage/materializeVariant对contentCharacterCount 65536的短消息直接返回零额外查询导出异常不会在备份目录留下截断文件——pendingExportFile在 catch 分支统一删除。七、适用边界与注意事项按字符而非按字节分块SQLite 的SUBSTR/LENGTH对文本按字符计数65536 字符的上界对中文、Emoji 等多字节文本同样成立而CursorWindow的容量按字节计算因此只要单块字符数足够小任何编码都不会触顶。超大消息的读取成本单条超过 65536 字符的消息需要ceil(length / 65536)次额外SUBSTR查询且全部包在同一个Transaction内保证首段 各分段读取期间数据一致这是为规避窗口溢出付出的必要代价仅影响超大消息。常量是内部策略从源码结构看CONTENT_CHUNK_CHARACTER_COUNT 65_536是ChatContentDao的私有常量不属于对外配置文档明确不调整设备相关的CursorWindow容量因此不同设备、不同 ROM 的窗口差异不影响该策略的有效性。相关源码索引核心 DAOChatContentDao.kt分块查询、分段重组、防御性检查、字符数聚合DAO 注册AppDatabase.kt消费方主仓库ChatHistoryManager.kt对话展示、变体操作、导出、失败清理长期记忆消费方MemoryAutoSaveScheduler.kt预览类查询不再返回完整大文本MessageDao.kt、MessageVariantDao.kt设计文档docs/TODO/chat_large_message_io_20260806/index.md赞分享AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载相关推荐Apache Pulsar WebSocket API 实战指南基于 WebSocket 的生产、消费与读取消息Apache Pulsar WebSocket API 实战指南基于 WebSocket 的生产、消费与读取消息 Pulsar 的 WebSocket API消息队列后端流处理uBlock Origin 免费轻量浏览器广告拦截插件5 分钟装好、一步到位的终极指南uBlock Origin 免费轻量浏览器广告拦截插件5 分钟装好、一步到位的终极指南 uBlock Origin 是一款免费、轻量的浏览器广告拦截插件专为网络安全应用安全LyCORIS高级应用多算法组合与动态调整技巧LyCORIS高级应用多算法组合与动态调整技巧 LyCORISLora beYond Conventional methods, Other Rank ad上一篇告别千篇一律打造专属Omarchy通知中心体验下一篇机器学习实战从数据清洗到模型部署的完整路径创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
