欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

欢迎在 PC 社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

适配开源地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_CnPack

一、为什么要适配 CnPack

CnPack IDE Wizards 是面向 Delphi、C++Builder、BDS 和 RAD Studio 的开源 IDE 专家包。它长期积累了源码浏览、代码格式化、Uses 单元整理、DFM 窗体检查、源码模块关系、ASCII 字符查询以及调试辅助等能力。对于维护 Delphi 老工程的团队而言，这些工具并不是简单的界面插件，而是一套围绕工程结构和源码关系形成的开发工作流。

选择 CnPack 进行 HarmonyOS PC 适配，首先是因为 PC 生态需要真正面向开发者的本地工具。现有源码中同时包含 Pascal、DFM、DPR、DPK、DPROJ、C/C++ 和多种构建资源，适合用来验证鸿蒙 PC 对复杂源码目录的扫描、读取、分析和报告导出能力。其次，CnPack 的原始形态与 Windows IDE 进程深度绑定，迁移过程中必须回答一个更有普遍意义的问题：当宿主 IDE 和 VCL 窗口不能原样带到新平台时，哪些能力值得保留，哪些边界需要重写，怎样才能先形成可安装、可操作、结果可核对的独立应用。

当前鸿蒙版本采用 Stage 模型与 ArkUI/ArkTS 实现，应用包名为 com.cnpack.developertoolkit，版本为 0.2.0，支持 2in1、tablet 和 phone。它不是把原 Delphi 插件伪装成一个 HAP，而是将可独立验证的源码分析能力重新组织为 CnPack Developer Toolkit。

二、适配边界：从 IDE 内插件转为独立工作区

原版 CnWizards 通过 ToolsAPI、IWizard、InitWizard、VCL/DFM 窗体以及大量 IDE 命令入口工作。HarmonyOS PC 没有对应的 Delphi IDE 宿主，也无法直接复用 Windows 窗口句柄和菜单扩展机制。因此，本次适配没有尝试在鸿蒙侧模拟一套 RAD Studio，而是把工作流拆成“工程输入—源码分析—结果预览—报告输出”四个阶段。

能力层次	原项目形态	鸿蒙侧实现
应用入口	IDE 加载专家包	Stage 模型 EntryAbility
用户界面	VCL 窗体、IDE 菜单与工具栏	ArkUI 自适应工作区与侧边导航
工程输入	IDE 当前工程、模块和编辑器上下文	系统目录选择器或应用可访问的绝对路径
源码索引	IDE 工程服务与文件接口	fileIo 递归扫描并建立 ProjectSnapshot
结构识别	ToolsAPI 与工程对象	根据工程文件、DFM、ToolsAPI 和插件入口特征识别
源码工具	各独立 Wizard	Diff、DFM、Uses、Outline、Formatter、Relations 等独立面板
AI 接口	CnPack AI Coder 多引擎体系	AiEngine 抽象与可离线验证的本地规则 Provider
结果输出	IDE 内查看或工具窗口	HAP 内预览，并通过系统文件服务导出 Markdown 报告

这种划分保留了 CnPack 最有价值的“理解源码”能力，同时明确放弃当前阶段无法成立的 IDE 进程注入。应用可以在没有 Delphi 和 RAD Studio 的鸿蒙 PC 上独立安装运行，用户选择工程后即可完成分析。

三、鸿蒙版工程结构

适配工程位于仓库的 CnPack-ohos-migration/ 目录，当前为纯 ArkTS 应用，没有引入 Qt 或 Electron 运行时。

CnPack-ohos-migration/
├── AppScope/app.json5                  # 包名、版本、图标和应用名称
├── build-profile.json5                 # SDK、产品与签名配置
├── entry/src/main/
│   ├── ets/entryability/
│   │   └── EntryAbility.ets            # Stage 模型生命周期入口
│   ├── ets/pages/
│   │   └── Index.ets                   # PC 工作区及各功能面板
│   ├── ets/model/
│   │   └── ProjectModels.ets           # 工程快照、源码文件与分析结果模型
│   ├── ets/service/
│   │   ├── ProjectScanner.ets          # 目录遍历、文本读取与架构指纹
│   │   ├── CodeAnalyzer.ets            # DFM、Uses、Diff、Outline 等确定性分析
│   │   ├── ProjectRelationService.ets  # Pascal 工程内依赖关系
│   │   ├── ProjectReportService.ets    # Markdown 报告生成与写入
│   │   └── AiEngine.ets                # AI Provider 接口与本地规则实现
│   └── resources/                      # CnPack 图标、Logo 与字符串资源
└── reports/                            # 迁移策略、能力对照和构建验证记录

界面层只负责状态展示和交互分发，工程扫描、代码分析、关系生成和报告写入分别放在独立服务中。这样做的直接好处是，后续替换扫描策略、接入更完整的 Pascal 解析器或远程模型时，不需要重新组织整套 UI。

四、在 HarmonyOS PC 真机上跑通核心流程

下面五张截图来自 HUAWEI MateBook Pro（HAD-W32）HarmonyOS PC 真机，系统版本为 HAD-W24 6.1.0.117(SP78C00E100R13P3)，屏幕分辨率为 3120×2080。测试前重新构建并安装了仓库生成的签名 HAP，再把当前 CnPack 仓库的 Source/ 目录传入应用调试沙箱进行实际扫描。截图中的路径、文件数、行数、DFM 结构和 Uses 关系均来自这次真机运行。

1. 工程扫描先建立可核对的全局快照

应用支持直接输入可访问的工程绝对路径，也支持从系统目录选择器取得授权目录。选择外部目录时，会先将授权内容复制到应用缓存，再交给统一扫描器处理，避免把文件选择器 URI 错当成普通目录路径。

本次扫描得到 883 个可分析文件、498826 行文本、128 个 DFM 窗体文件和 69 个工程文件。架构指纹同时识别出 Delphi/RAD Studio IDE 扩展、VCL/DFM、ToolsAPI、InitWizard/IWizard、15 处 RegisterCnWizard 以及 AI Coder 特征。这些结论来自文件内容和工程类型，不是预置在界面里的固定介绍。

扫描结果集中保存在 ProjectSnapshot 中，后续源码浏览、Uses 分析、模块关系和报告导出都基于同一份快照，避免每个面板重复遍历目录并产生不一致的数据。

2. 源码浏览把文件索引与真实内容放在一起

扫描完成后，源码浏览页面建立文件索引，可按文件名或路径过滤。选中条目后，右侧直接读取对应文件并显示行数、字符数和完整路径。图中打开的是仓库内 Source/AIAgent/CnAIAgentClient.pas，真机读取结果为 926 行、31559 个字符。

CnPack 仓库历史较长，一部分 Pascal 文件并非 UTF-8 编码。当前扫描器按 UTF-8 读取，因此文件头中的旧编码中文注释可能出现乱码，但代码关键字、标识符和 Uses 关系仍可分析。这里保留真实显示结果，是为了明确当前版本的编码边界；后续应在扫描入口增加 BOM 检测与 GB18030/ANSI 编码探测，而不是在文档中把问题隐藏掉。

3. DFM Inspector 解析真实 VCL 窗体

DFM 文件是 Delphi 桌面工程的重要组成部分。鸿蒙版不尝试执行 VCL 窗体，而是先解析文本 DFM 中的 object 声明和属性赋值，生成对象数、非窗体控件数、属性数、对象名称与常见属性列表。

截图中的 CnAICoderChatFrm.dfm 实际解析出 41 个对象、40 个非窗体控件和 211 条属性赋值。对象区能够看到 CnAICoderChatForm、spl1、pnlChat、tlbAICoder、按钮与面板等原始组件名称。这个面板的定位不是还原设计器，而是为评估窗体复杂度、识别可迁移控件和检查属性使用情况提供快速入口。

4. Uses Analyzer 区分工程内依赖与平台依赖

Pascal 的 uses 区块同时包含工程内单元和平台/第三方单元。分析器先去掉注释与 in 路径，再根据工程快照中的文件名判断本地单元。图中的 CnAIAgentClient.pas 共解析出 7 个单元，其中 4 个可在当前工程中匹配，3 个属于外部或平台单元。

点击“去重预览”后，应用生成稳定的 Uses 列表并统计重复项，但不会直接覆盖原文件。本次样本没有重复项，去重后仍为 7 个单元。只生成预览是有意设置的安全边界：在尚未接入完整 Pascal AST 与条件编译语义前，自动改写源码的风险高于节省的操作成本。

5. 从单文件 Uses 延伸到工程模块关系

模块关系服务遍历 Pascal 文件的 Uses 结果，仅保留能够在工程内匹配到目标文件的边，形成“来源单元 → 目标单元”的依赖清单。平台单元和第三方单元仍留在 Uses Analyzer 中，不会被错误地画成工程内模块。

本次真机结果达到当前 600 条关系边的显示上限，涉及 234 个单元。前几条关系可以直接核对到 CnAIAgentClient.pas 对 CnAIAgentTypes.pas、CnAIAgentJsonRpc.pas、CnAIAgentStdioTransport.pas 和 CnAIAgentTools.pas 的依赖。关系清单已经能帮助定位耦合点，但当前版本尚未进行环检测、拓扑分层和可视化布局。

五、几个关键实现点

1. 文件选择与目录扫描使用同一条入口

系统目录选择器返回的是带授权语义的 URI，fileIo.listFileSync 则更适合应用沙箱中的本地路径。适配版在用户选择目录后，先创建缓存目录，再通过 fileIo.copy 复制已授权的目录树，最后调用与绝对路径输入相同的 ProjectScanner.scan()。这样既保留系统文件服务的权限边界，也避免为两种入口维护两套分析逻辑。

扫描器识别 Pascal、DFM、FMX、Delphi/Lazarus 工程、C/C++、JSON、XML、Markdown 和常见构建资源，并跳过 .git、node_modules、build、dist、out、oh_modules 等目录。当前设置的文件列表上限为 2000 个，单文件完整读取上限为 240000 字节，超出上限的文件仍可进入清单，但不会在初次扫描时把全部内容放进内存。

2. 架构指纹使用源码事实而非项目名称

扫描器并不因为目录叫 CnPack 就直接认定它是 IDE 插件。工程类型由 DPROJ/DPK/BPR 等工程文件、ToolsAPI 引用、IWizard/InitWizard 入口、DFM/TForm 特征、RegisterCnWizard 调用次数和 AI Coder 相关标识共同决定。相同机制也可以用于其他 Delphi 或 Lazarus 工程的初步迁移评估。

3. 分析器优先保证确定性和可复核

当前 DFM、Uses、Outline、Formatter 和 Diff 都是本地确定性算法。DFM 按行识别对象与属性，Uses 解析逗号分隔单元，Outline 提取类、过程、函数、构造与析构声明，Formatter 只生成基于关键字缩进的预览。Diff 采用逐行位置比较，而不是 LCS 或 Myers 算法，因此适合快速查看小改动，不应被描述为完整的版本控制差异引擎。

确定性分析的优势是离线、可重复、容易通过小样本核对；局限是无法完整理解条件编译、宏、字符串和语言语义。后续若接入 Pascal AST，可以保持当前服务接口不变，逐步替换内部实现。

4. AI Coder 保留 Provider 边界，但不虚构远程能力

项目中的 AiEngine 定义了统一的请求与响应接口，当前默认 Provider 是 LocalAiEngine。它根据当前文件类型、用户问题和工程快照给出 DFM、Uses、格式化或 Diff 等可执行建议。网络权限已为后续 HTTP Provider 预留，但当前截图和验收没有把本地规则响应写成云端大模型结果。

5. 报告导出遵循系统文件服务

工程扫描完成后，可以通过系统保存选择器导出 cnpack-project-report.md。报告包含扫描目录、时间、文件数、行数、DFM/工程文件统计、架构指纹、文件清单和扫描提示。写入使用系统返回的 URI 和文件描述符，避免绕过用户选择直接写入公共目录。

六、适配过程中遇到的困难

难点一：原项目的价值与原项目的宿主耦合在一起

CnWizards 的大量功能依赖 RAD Studio 当前工程、编辑器缓冲区、菜单命令和窗口服务。直接交叉编译 Pascal 源码既无法获得 ToolsAPI 宿主，也无法运行 VCL 窗体。适配时必须先把“用户真正需要的分析结果”从“结果原来出现在哪里”中拆开。工程扫描、DFM、Uses 和模块关系因此先成为独立 App 能力，IDE 级编辑器联动则明确留到后续阶段。

难点二：鸿蒙文件授权不是普通桌面路径输入

桌面软件常假设用户输入路径后进程就能递归读取，但 HarmonyOS PC 的文件访问需要经过系统选择与授权。外部文件 URI 可以读取单个文件，却不一定能直接用于同步目录枚举。当前使用“选择—复制到缓存—统一扫描”的方式解决首版可用性，同时保留直接输入应用可访问路径的调试入口。

难点三：老工程编码会影响读取和分析

Pascal 老项目中常见 ANSI、GBK/GB18030 与不同 BOM 组合。若统一按 UTF-8 读取，中文注释和字符串会损坏；若简单按系统默认编码读取，又可能破坏 UTF-8 新文件。当前版本尚未完成多编码检测，这也是源码浏览截图中部分注释乱码的原因。后续应在文件模型中持久化编码与 BOM，并在重读、分析和导出时保持一致。

难点四：大工程扫描与 ArkUI 状态刷新要分别处理

文件扫描返回的是包含嵌套数组的普通对象。部分鸿蒙 PC 构建中，仅替换嵌套 snapshot 不一定立即触发所有 Scroll 子树刷新，因此界面把文件数、行数、DFM 数、工程数和架构字段同步为一等 @State，扫描结束后再统一更新。当前扫描仍是同步流程，依靠 2000 文件和 240000 字节读取上限控制首版风险；更大的仓库应继续改为 TaskPool/Worker 扫描并增量更新列表。

难点五：功能名称容易让人高估完成度

“Code Formatter”“Source Diff”和“AI Coder”都对应成熟领域。当前实现可以运行，也能返回真实结果，但分别属于轻量缩进预览、位置式逐行差异和本地规则建议。文档与界面必须同时说明算法边界，否则“有一个同名面板”很容易被误解为已经复刻原 CnPack 的全部能力。

七、编译、安装与启动

使用 DevEco Studio 打开 CnPack-ohos-migration/，为 com.cnpack.developertoolkit 配置与目标设备匹配的调试签名。项目的 compile、compatible 和 target SDK 均为 6.0.2(22)。macOS 命令行构建如下：

cd CnPack-ohos-migration

export JAVA_HOME=/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home
export DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk
export HOS_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk/default/hms

/Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw \
  --mode module \
  -p module=entry@default \
  -p product=default \
  assembleHap --no-daemon

签名产物位于：

CnPack-ohos-migration/entry/build/default/outputs/default/entry-default-signed.hap

连接 HarmonyOS PC 后安装并启动：

HDC=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony/toolchains/hdc

"$HDC" list targets
"$HDC" install -r \
  CnPack-ohos-migration/entry/build/default/outputs/default/entry-default-signed.hap
"$HDC" shell aa start \
  -a EntryAbility \
  -b com.cnpack.developertoolkit

本次文档整理时，命令行构建返回 BUILD SUCCESSFUL，签名 HAP 大小为 352431 字节；真机覆盖安装和 EntryAbility 启动均成功。构建阶段仍会提示目录选择 API 并非所有设备都支持，以及旧版 getContext 接口已弃用，这两项属于后续兼容性清理工作，不影响本次 2in1 真机上的核心流程。

八、当前功能边界

当前 HarmonyOS PC 版本已经完成以下能力：

• Stage 模型应用入口、可安装签名 HAP 和 PC 自适应 ArkUI 工作区；
• 系统目录选择、授权目录导入和应用可访问路径扫描；
• 多类源码与工程文件索引、行数统计和架构指纹识别；
• 源码浏览、文件名过滤和单文件内容预览；
• DFM 对象、控件和属性解析；
• Pascal Uses 分类、去重预览和工程内模块关系；
• 轻量 Source Diff、Pascal 格式化预览与代码 Outline；
• ASCII/Unicode 字符查询、本地规则 AI Provider 和 Markdown 报告导出。

尚未完成的主要能力包括：多编码自动检测、完整 Pascal AST、条件编译语义、Myers/LCS 差异算法、格式化规则配置、编辑器联动、循环依赖分析、模块关系图布局、后台增量扫描、文件监听、远程模型 Provider，以及原 CnWizards 在 RAD Studio 内的菜单、设计器和调试器集成。

此外，源码浏览默认只展示前 180 个匹配文件，扫描最多读取 2000 个文件，模块关系最多生成 600 条边。这些上限是首版为了控制 PC 真机上的渲染与内存开销而设置的明确约束，不代表仓库只有这些内容。

九、总结

CnPack 的适配难点不在于重新画一套侧边栏，而在于将一个依赖 Delphi IDE 的专家包拆成可在 HarmonyOS PC 上独立成立的开发者工作流。当前版本用 ArkUI/ArkTS 完成应用宿主和 PC 界面，用系统文件服务守住授权边界，再以统一工程快照串联源码浏览、DFM、Uses、模块关系和报告导出。

真机扫描 883 个源文件后，统计结果、架构指纹、DFM 对象数、Uses 分类和 600 条模块关系能够相互对应，说明工程输入到分析输出的主链路已经跑通。后续最值得优先投入的工作，是补齐多编码读取和异步增量扫描，再用 Pascal AST 替换正则分析器。完成这两步后，CnPack Developer Toolkit 才能从“可用的迁移基础版”继续向适合大型 Delphi 工程的专业分析工具演进。