鸿蒙 PC Markdown 编辑器内核隔离:CodeMirror EditorState 多会话切换

发布时间:2026/7/26 1:14:05

鸿蒙 PC Markdown 编辑器内核隔离:CodeMirror EditorState 多会话切换
鸿蒙 PC Markdown 编辑器内核隔离CodeMirror EditorState 多会话切换多标签编辑器最隐蔽的数据错误不是标签标题显示错而是撤销历史、保存基线或恢复计时器跨文档串联。用户在文档甲输入一段切到文档乙按撤销如果乙退回甲的内容编辑器已经失去可信度。只在原生层保存每个标签的正文字符串无法解决 CodeMirror 内部状态归属。本文基于鸿蒙 PC Markdown 编辑器 OhMarkdown说明如何为每个 session保存完整EditorState如何同时隔离撤销栈、基线、revision 与恢复版本以及切换时为什么必须清理延迟任务。完整代码位于 https://gitcode.com/VON-/codex_md_oh本文对应提交3a9146e。EditorState 才是编辑会话CodeMirror 6 将正文、选择区、扩展状态和撤销历史组织在EditorState中EditorView负责把状态渲染到 DOM。多标签可以为每个文档创建一个独立 View但多个 DOM 编辑器会增加内存和布局成本。OhMarkdown 复用单个EditorView切换其 state。如果切换时只调用setDocument(content)创建新 state正文虽然正确旧标签的光标、选择和撤销历史会丢失。切回后只能得到一份新编辑器。真正会话快照需要保留interfaceEditorSessionSnapshot{state:EditorState;baselineDocument:Text;forcedDirty:boolean;pendingDirty:boolean;documentRevision:number;lastRecoveryRevision:number;}consteditorSessionsnewMapstring,EditorSessionSnapshot();state包含 CodeMirror 文档与历史其余字段是应用建立在编辑器之上的业务状态。它们必须与 state 同时切换不能继续作为全局状态留在上一文档。Map 的键是原生层提供的稳定sessionId。不能用文件名因为两个未命名文档都叫Untitled.md不能用正文哈希因为两份文件内容可能相同不能用 URI因为新文档还没有 URI。sessionId 表达的是编辑会话身份与外部文件身份分开。为什么保存的是 EditorState 引用会话持久化函数直接保存当前 statefunctionpersistActiveSession():void{editorSessions.set(activeSessionId,{state:editor.state,baselineDocument,forcedDirty,pendingDirty,documentRevision,lastRecoveryRevision});}CodeMirror state 是不可变值。一次 transaction 不会原地修改旧 state而是产生新 state 并由 view持有。Map 中保存旧会话 state 后切到其他会话继续编辑不会修改它。切回时可以直接editor.setState(storedSession.state)。不可变结构还使用持久化文本树保存 state 引用不等于每次复制全文字符串。历史中不同版本可以共享未变化结构比手工深拷贝正文和选区更适合编辑器。不过撤销历史仍会占用内存十二标签上限是当前保护措施。长期需要通过真实文档监控每会话历史成本。Map 只在 Web 进程内有效不是跨进程恢复。系统回收 ArkWeb 后原生层可以用session.content重建正文但光标和撤销历史会丢失。跨进程会话恢复需要显式序列化可恢复字段不能把内存 Map误称为持久化。保存基线不能只用 dirty 布尔值编辑器需要判断当前正文是否等于最近保存版本。OhMarkdown 保留 CodeMirrorText基线letbaselineDocument:Text;EditorView.updateListener.of((update){if(!update.docChanged){return;}documentRevision1;pendingDirtyforcedDirty||!update.state.doc.eq(baselineDocument);// 省略预览、通知和恢复})用户输入后 dirty 为 true撤销回与保存基线完全相同的 Text 时eq返回 truedirty 自动恢复为 false。若只在第一次输入时把布尔值设成 true撤销回原文后标签仍带星号关闭还会多余询问。每个会话必须保存自己的 baseline。甲保存后基线是甲正文乙可能从未保存。切换只恢复 EditorState、不恢复 baseline乙的内容会与甲基线比较脏状态随机变化。Text.eq比把两边sliceDoc()成完整字符串后比较更符合 CodeMirror 数据结构也避免每次按键都生成两份大字符串。大文档性能尤其依赖这种结构化比较。forcedDirty 处理恢复文档崩溃恢复内容可能恰好与创建 state 时的正文相同但它并未写回用户文件必须显示为未保存。重置函数设置baselineDocumenteditor.state.doc;forcedDirtyrecovered;pendingDirtyrecovered;普通打开文档recoveredfalse创建后的正文就是磁盘基线。恢复记录recoveredtrue虽然editor.state.doc.eq(baselineDocument)为 trueforcedDirty仍让 dirty 保持 true直到显式保存。这是“内容相等”与“持久化事实”分离的例子。恢复正文与某个内存基线相等不代表外部文件已经包含它。forcedDirty 只在保存成功后清除也要随会话快照切换。否则从恢复标签切到普通标签再返回星号可能消失。revision 与恢复版本属于会话每次文档 transaction 递增documentRevisiondocumentRevision1;pendingDirtyforcedDirty||!update.state.doc.eq(baselineDocument);scheduleRecoverySnapshot();恢复快照只在 dirty、非大文档且 revision 与上次快照不同的情况下发送functionflushRecoverySnapshot():void{window.clearTimeout(recoveryTimer);recoveryTimerundefined;if(!pendingDirty||largeDocumentMode||documentRevisionlastRecoveryRevision){return;}window.ohMarkdownBridge?.onSnapshot(editor.state.sliceDoc(),documentRevision);lastRecoveryRevisiondocumentRevision;}甲可能 revision 为 15乙为 2。若切换只换正文而不恢复计数乙的下一次快照可能错误继承 15或者与甲的lastRecoveryRevision相等而被跳过。两个数字必须进入 snapshot。revision 目前是会话内单调计数不跨进程。恢复记录带 revision主要用于当前会话写入排序和保存竞争不是全局文档版本。未来多会话恢复需要把 sessionId、URI 和 revision一起作为记录身份。创建新 state 必须隔离旧历史打开一个完全不同的文档时程序使用createEditorState(content)而不是对当前 state dispatch 一个“替换全文”事务functionresetEditorDocument(content:string,recovered:boolean):void{window.clearTimeout(bridgeTimer);window.clearTimeout(recoveryTimer);recoveryTimerundefined;pendingNativeChangefalse;isApplyingNativeDocumenttrue;editor.setState(createEditorState(content));isApplyingNativeDocumentfalse;// 初始化基线和版本}若把新文件作为一次全文 replacement dispatch撤销可能恢复上一份文件。即使两个文件内容恰好相同旧重做历史也可能在新文件中生效。新建 EditorState 从结构上切断历史是文档身份变更应有的语义。自动化专门验证了两种情况加载不同内容后第一次撤销只撤销新文件内刚输入的内容第二次撤销返回 false加载相同内容的新文件后旧文档遗留的重做也必须返回 false。相同字符串不能让编辑器误以为还是同一会话。isApplyingNativeDocument抑制程序设置 state引发的业务通知。虽然setState本身不是普通用户 transaction扩展和后续演进仍可能触发监听明确来源标记可以防止切换被计入 revision 或 dirty。活动会话切换顺序切换函数首先持久化当前快照functionactivateSession(sessionId:string,content:string,recovered:booleanfalse):void{if(sessionIdactiveSessionId){return;}persistActiveSession();window.clearTimeout(bridgeTimer);window.clearTimeout(recoveryTimer);recoveryTimerundefined;pendingNativeChangefalse;activeSessionIdsessionId;conststoredSessioneditorSessions.get(sessionId);if(!storedSession){resetEditorDocument(content,recovered);return;}// 恢复快照}先保存、后改变 activeSessionId 是关键。如果先改 idpersistActiveSession会把甲 state写到乙键下两个会话立即混乱。清理bridgeTimer防止甲延迟的 onChange 在乙激活后发给原生层。清理recoveryTimer防止甲快照以乙身份写入。pendingNativeChangefalse丢弃旧会话尚未发出的状态通知甲的正文已经由原生切换前捕获并且完整 state保存在 Map不需要把过期通知发送给当前页面。如果目标没有 Web 快照说明它是原生新建、刚打开或 ArkWeb 状态已丢失使用传入 content 建立 state。已有快照则恢复isApplyingNativeDocumenttrue;editor.setState(storedSession.state);isApplyingNativeDocumentfalse;baselineDocumentstoredSession.baselineDocument;forcedDirtystoredSession.forcedDirty;pendingDirtystoredSession.pendingDirty;documentRevisionstoredSession.documentRevision;lastRecoveryRevisionstoredSession.lastRecoveryRevision;pendingSaveDocumentundefined;pendingSaveDocument不随会话恢复。它只属于当前正在进行的保存命令快照而原生层通过操作互斥防止保存期间切换。恢复一个旧 pending 保存引用可能把另一个会话基线标记错误因此明确清空。恢复后主动同步原生状态设置 state后Web 重新计算大文档模式、预览和字数并主动通知原生constwordCountlargeDocumentMode?-1:countWords(editor.state.sliceDoc());window.ohMarkdownBridge?.onState(wordCount);window.ohMarkdownBridge?.onChange(wordCount,pendingDirty);if(pendingDirty){scheduleRecoverySnapshot();}原生标签栏和状态栏不能只靠之前缓存。恢复通知让当前 wordCount、dirty 与实际 EditorState 对齐。如果目标会话为脏重新安排它自己的恢复快照干净会话不写。大文档用-1表示跳过字数统计原生状态栏显示保护模式。每个会话的内容长度不同切换后必须重新计算不能把大文档模式当全局开关。预览也根据当前模式更新。纯源码只标记 dirty分栏或预览立即渲染目标正文。若不处理标签已切换右侧还可能短暂显示上一文档。保存基线与异步输入用户请求保存时Web 先保存当前 Text引用requestCommand:(command){flushToNative();if(commandsave){flushRecoverySnapshot();pendingSaveDocumenteditor.state.doc;}constcontentcommandsave?editor.state.sliceDoc():;window.ohMarkdownBridge?.onCommand(command,content);}原生写入成功后调用markSavedmarkSaved:(){baselineDocumentpendingSaveDocument??editor.state.doc;pendingSaveDocumentundefined;forcedDirtyfalse;pendingDirty!editor.state.doc.eq(baselineDocument);window.clearTimeout(recoveryTimer);recoveryTimerundefined;persistActiveSession();}基线使用保存请求时的 Text而不是完成时的当前 state。如果磁盘写入期间用户继续输入新内容不等于 pendingSaveDocumentdirty 继续为 true。若用完成时editor.state.doc作为基线会错误认为尚未写入的新输入已保存。清除 forcedDirty 表示恢复内容已经成功写入。重新比较当前 state后决定是否仍脏再把结果持久化到会话 Map。保存与切换交错由原生互斥阻止但 Web 仍保持版本正确性。关闭会话的内存清理关闭非活动 Web 会话时删除 Map 项functioncloseSession(sessionId:string):void{if(sessionId!activeSessionId){editorSessions.delete(sessionId);}}活动会话不能在仍由 EditorView 使用时直接从逻辑上清空原生层关闭活动标签时先激活后继再调用旧 id 的 closeSession此时旧会话已不活动可以删除。如果关闭后不删除十二标签虽然限制可见会话反复打开关闭仍会让 Map无限增长历史和 Text结构无法释放。内存生命周期必须与标签生命周期一致。最后一个标签关闭后原生层创建新空会话并激活再清理旧会话。Web始终有一个活动 id不进入无 state 特例。鸿蒙 PC 模拟器中的隔离结果下图来自 MateBook Pro 2in1 模拟器。两个未命名标签拥有独立正文活动会话显示Session-B另一个标签保持自己的状态。切换和撤销测试确认两个 EditorState历史不串联。截图只能展示正文与标签撤销历史必须用行为验证。自动化在 session-a输入“修改”session-b输入“新增”切回 a后撤销预期只得到“文档甲”再切回 b必须仍为“文档乙新增”。host.OhMarkdownEditor.activateSession(session-a,文档甲);// 输入“修改”host.OhMarkdownEditor.activateSession(session-b,文档乙);// 输入“新增”host.OhMarkdownEditor.activateSession(session-a,文档甲);expect(host.OhMarkdownEditor.undo()).toBe(true);expect(host.OhMarkdownEditor.getDocument()).toBe(文档甲);还应增加选区、滚动、重做、搜索选择、保存基线和恢复 revision 的逐项隔离断言。当前 EditorState天然保留选区与历史但产品验收不能只依赖库设计推断。内存与性能边界单 View多 state避免同时渲染多个 CodeMirror DOM但所有打开会话的 Text和历史仍驻留内存。十二个十兆文档即使结构高效也可能超过桌面模拟器和真机可接受范围。当前单文档五兆以上进入最小扩展模式不代表多标签总量已有控制。后续可以统计每会话内容长度限制总打开字节后台会话可以截断撤销历史或序列化正文后释放 EditorState激活时重建最近使用的少量会话保留完整状态。冻结策略必须告知用户撤销历史是否会丢并在后台脏会话释放前完成恢复快照。切换性能也要测量editor.setState、预览渲染、字数统计和 Bridge全文捕获都会随文档变大。Map 查找是常数时间不代表完整切换是常数成本。真实指标应从点击标签到光标可输入并分别记录源码、分栏和大文档模式。当前边界会话隔离目前存在于进程内。应用重启后不会恢复全部标签、光标、选区和撤销历史崩溃恢复重点仍是活动文档内容。固定标签、标签排序、跨窗口和会话持久化需要更高层模型。CodeMirror state与原生 DocumentSession是两份互补状态也存在一致性成本。正文切换前由原生主动捕获Web切换后主动回报 dirty和字数。未来可以给 Bridge消息增加 sessionId避免所有回调隐含作用于当前活动会话进一步降低异步误归属。结语多标签编辑内核的正确单位不是字符串而是完整会话。OhMarkdown 为每个 session保存 CodeMirror EditorState、保存基线、恢复脏标记、revision和快照版本切换前保存当前状态并取消旧定时器切换后恢复目标 state并重新同步原生保存使用请求时 Text作为基线关闭删除不再使用的快照。这些细节让正文、撤销、恢复和保存都归属于正确标签。鸿蒙 PC 编辑器要承担长期写作用户不应感知 ArkUI 与 ArkWeb 的边界更不应承担跨边界状态串联的后果。EditorState 会话隔离就是把这种技术复杂度留在应用内部的基础。

相关新闻

鸿蒙 PC Markdown 编辑器 Bridge 协议:原生外壳与 Web 内核的状态同步

鸿蒙 PC Markdown 编辑器 Bridge 协议:原生外壳与 Web 内核的状态同步

2026/7/26 1:14:05

鸿蒙 PC Markdown 编辑器 Bridge 协议:原生外壳与 Web 内核的状态同步 OhMarkdown把系统文件、标签和窗口放在 ArkUI,把 CodeMirror和 Markdown渲染放在 ArkWeb。两端不能共享内存,只能通过协议传递状态。若协议没有明确方向、类型、频率和身…

springboot商城系统

springboot商城系统

2026/7/26 1:14:05

SpringBoot商城系统选题背景电子商务的快速发展使得线上购物成为现代消费的主流方式之一,传统的单机或单体架构系统已难以应对高并发、高可用、高性能的业务需求。SpringBoot作为轻量级的Java开发框架,凭借其快速构建、简化配置、内嵌服务器等特性&#…

[Dify实战] 条件分支总是走错?先稳住上游字段,分类流程才不会乱跳

[Dify实战] 条件分支总是走错?先稳住上游字段,分类流程才不会乱跳

2026/7/26 1:04:05

很多人第一次在 Dify Workflow 里用条件分支,容易把它当成“让 AI 再判断一次”的节点。实际做下来,条件分支最适合做的不是理解业务,而是接住上游已经整理好的字段,然后按照稳定规则把流程分到不同路径。前面节点如果输出忽左忽右,条件节点就会跟着乱;前面节点如果已经把…

企业级助农管理系统管理系统源码|SpringBoot+Vue+MyBatis架构+MySQL数据库【完整版】

企业级助农管理系统管理系统源码|SpringBoot+Vue+MyBatis架构+MySQL数据库【完整版】

2026/7/26 2:04:08

博主介绍:🌟 个人简介 CSDN特邀作者 | 掘金优质创作者,深耕Java生态与现代Web开发技术栈。专业领域涵盖Java企业级开发、Spring Boot微服务架构、前后端分离解决方案,以及学术项目的工程化实践。 📊 影响力数据 全平台…

Python+RAG构建智能知识库系统实战

Python+RAG构建智能知识库系统实战

2026/7/26 2:04:08

1. 项目背景与核心价值最近在帮一家中型电商企业搭建内部知识管理系统时,深刻体会到传统文档共享平台的局限性——海量的产品手册、客服话术和运营规范分散在各个文件夹中,新员工要花两周时间才能熟悉基本业务流程。这促使我尝试用PythonRAG技术栈构建一…

MCP协议开发实战:构建英国央行数据查询的Claude AI工具

MCP协议开发实战:构建英国央行数据查询的Claude AI工具

2026/7/26 2:04:08

1. 项目背景与需求场景 最近在办理房屋再抵押贷款时,发现需要频繁查询英国央行(Bank of England)的利率数据。传统的手动查询方式效率低下,正好接触到Claude Code和MCP(Model Context Protocol)技术&#x…

Claude MCP协议实战:构建英国央行数据查询工具完整指南

Claude MCP协议实战:构建英国央行数据查询工具完整指南

2026/7/26 2:04:08

Claude与MCP协议实战:构建英国央行数据查询工具完整指南 在AI助手日益普及的今天,Claude作为一款强大的对话式AI,其扩展能力尤其值得开发者关注。最近在实际业务中尝试使用Claude处理房贷相关数据分析时,发现直接获取英国央行等权…

月之暗面Kimi API实战:长文本处理与OpenAI对比开发指南

月之暗面Kimi API实战:长文本处理与OpenAI对比开发指南

2026/7/26 2:04:07

最近科技圈有个很有意思的现象:马斯克在社交媒体上公开喊话中国AI公司,而月之暗面(Moonshot AI)的回应更是直接——“希望能出来‘掰掰手腕’”。这不仅仅是两家公司的隔空对话,背后反映的是全球AI竞争格局正在发生的深…

终极指南:如何用Translumo免费实现Windows游戏实时翻译

终极指南:如何用Translumo免费实现Windows游戏实时翻译

2026/7/26 1:54:07

终极指南:如何用Translumo免费实现Windows游戏实时翻译 【免费下载链接】Translumo Advanced real-time screen translator for games, hardcoded subtitles in videos, static text and etc. 项目地址: https://gitcode.com/gh_mirrors/tr/Translumo 你是否…

[具身智能-649]:个人电脑搭建 RTSP 服务完整方案(Windows / Ubuntu 双平台,适配 RDK X5 rtsp2display 调试)

[具身智能-649]:个人电脑搭建 RTSP 服务完整方案(Windows / Ubuntu 双平台,适配 RDK X5 rtsp2display 调试)

2026/7/26 0:04:02

目标:电脑作为RTSP 服务端,循环推送 H264/H265 视频流; RDK X5 通过 rtsp2display 拉流预览,完全不需要在开发板编译 live555。 提供两套成熟方案: ✅ 方案 A:FFmpeg(最简单,优先推…

PDF合并与动态水印的工程化方案:2026国内免费工具实测对比

PDF合并与动态水印的工程化方案:2026国内免费工具实测对比

2026/7/26 0:04:02

一、背景与测试方案 在实际项目交付中,PDF文件合并与版权保护水印的叠加是一个高频但容易被低估的技术需求。典型的处理链路涉及:多源PDF的文件流合并、页面级水印渲染(含透明度混合与图层叠加)、输出文件体积控制。看似简单的操作…

PDF拆分压完图糊了?2026国内免费实测,档案员都在用的组合方案

PDF拆分压完图糊了?2026国内免费实测,档案员都在用的组合方案

2026/7/26 0:04:02

说实话,提到PDF拆分再压缩,我真是被折腾得够呛。 上个月公司年度合同归档,一份300多页的PDF总合同,需要按年份拆分成三个独立文件,再分别压缩到10MB以内方便邮件发送各部门确认。我心想这还不简单?先找个海…

[具身智能-649]:个人电脑搭建 RTSP 服务完整方案(Windows / Ubuntu 双平台,适配 RDK X5 rtsp2display 调试)

[具身智能-649]:个人电脑搭建 RTSP 服务完整方案(Windows / Ubuntu 双平台,适配 RDK X5 rtsp2display 调试)

2026/7/26 0:04:02

目标:电脑作为RTSP 服务端,循环推送 H264/H265 视频流; RDK X5 通过 rtsp2display 拉流预览,完全不需要在开发板编译 live555。 提供两套成熟方案: ✅ 方案 A:FFmpeg(最简单,优先推…

PDF合并与动态水印的工程化方案:2026国内免费工具实测对比

PDF合并与动态水印的工程化方案:2026国内免费工具实测对比

2026/7/26 0:04:02

一、背景与测试方案 在实际项目交付中,PDF文件合并与版权保护水印的叠加是一个高频但容易被低估的技术需求。典型的处理链路涉及:多源PDF的文件流合并、页面级水印渲染(含透明度混合与图层叠加)、输出文件体积控制。看似简单的操作…

PDF拆分压完图糊了?2026国内免费实测,档案员都在用的组合方案

PDF拆分压完图糊了?2026国内免费实测,档案员都在用的组合方案

2026/7/26 0:04:02

说实话,提到PDF拆分再压缩,我真是被折腾得够呛。 上个月公司年度合同归档,一份300多页的PDF总合同,需要按年份拆分成三个独立文件,再分别压缩到10MB以内方便邮件发送各部门确认。我心想这还不简单?先找个海…