[xiaoyumuxi]

关联

状态栏内存详情原来只显示“内存中”一个数（macOS 物理占用、Windows 专用工作集），用户在 Windows 上看到 Lithe 只占 108 MB，怀疑漏算。实际没有漏算，只是被系统压缩或换出的部分、Windows 的专用显存都不在这个数里，也看不到 CPU 和 GPU 占用。这个 PR 让 processMemory.summarize 同时汇总三端统一口径的“内存中”和“压缩/换出”、显存，以及两次读取之间的 CPU、GPU 占用百分比；百分比的计算放在 Core，宿主只提供累计计数器。桌面端改动在配套 PR 1lck/Lithe-IDEA#1933，固定在本 PR 的 commit c7213c2，本 PR 合入后改为 main 上的 commit。

也是 1lck/Lithe-IDEA#1925 建议方案的第 1、2 步：进程表带累计 CPU 时间、两次采样之间的 CPU 占比在 Core 计算。运行窗口曲线的迁移不在本 PR。

改动

• 进程行新增四个可选字段：
  • compressedBytes：系统压缩或写到磁盘的部分，bytes 不包含它。
  • gpuMemoryBytes：bytes 不包含的显存，例如 Windows 的专用显存。
  • cpuTime：进程启动以来的用户态加内核态 CPU 时间，单位微秒。
  • gpuEngines：{ engine, busyTime }，各 GPU 引擎为该进程忙碌的微秒数。
• 请求新增三个可选字段：
  • sampledAt：读表时刻，取只增不减的时钟，单位微秒。
  • previous：上一次响应返回的 baseline，宿主原样带回。
  • logicalProcessors：给出时 CPU 按全部处理器折算，和任务管理器一致；不给时 100 表示一个处理器忙满，和活动监视器、top 一致。
• 响应新增：
  • 汇总、各类别、各条目都带可选的 compressedBytes、gpuMemoryBytes、cpuPercent、gpuPercent。同一个数要么三处都有，要么都没有。
  • baseline: { sampledAt, processes }：实例内带计数器的进程，每个进程每个引擎一行。
• 百分比规则（写在契约里）：
  • 按进程号加启动时间对上一次的行；启动时间不同说明进程号被复用，不对比。
  • 新出现的进程到下一次读取才计入；计数器比上一次小时不计入。
  • GPU 先把组内各进程同一引擎的忙碌时间相加，再取最忙引擎占间隔的比例，上限 100。
  • 百分比保留一位小数。没有 sampledAt、没有 previous，或 sampledAt 不晚于基线时，不返回百分比。
  • logicalProcessors 为 0 时返回 invalid_request。
• bytes 的含义写成三端统一：在内存中的部分。排序仍只按 bytes。
• 实现在 rust/crates/process/src/memory.rs，新增对应单元测试。
• 契约 rust/contracts/rust-core-api.md：命令表的说明和 “processMemory.summarize” 一节同步更新。
• 共享样例 rust/fixtures/process-lifecycle/memory-summary-v1.json 新增 6 个用例：
  • 压缩内存与显存和内存中分开求和
  • 两次读取之间的 CPU、GPU 占用
  • 按全部逻辑处理器折算且不超过 100
  • 第一次读取只建立基线，不返回百分比
  • 两次读取都有引擎时才返回 GPU 占用
  • logicalProcessors 为 0 时返回无效请求

验证

• cargo test --manifest-path rust/Cargo.toml -p lithe-process -p lithe-core：837 个测试全部通过，包括共享样例的回放。
• cargo fmt --all -- --check、cargo clippy -p lithe-process -p lithe-core --all-targets -- -D warnings、scripts/rust-core/verify-rust-core-comments.sh：都通过。
• 桌面端以 LITHE_CORE_RUST_DIR 指向本分支，跑了 scripts/desktop/desktop-go.sh test 覆盖 core、sysinfo、workbench 三个包，都通过；它们读同一份共享样例。

不涉及插件契约、能力版本或插件函数协议，所以不需要更新协议记录。