DeepSeek V4.1 Flash
044b87383b
## 为什么
用户 2026-10-29 要求：按既定计划完整实现改进，但
① **不得把编译产物拆成 DLL**（项目定位是单文件轻量工具，最终只能有一个 .exe）；
② 异常处理改用**预检验**而不是 try/catch（-fno-exceptions 省体积，且 try/catch 本身开销大）；
③ 先删除 Documents 内三份 UI 重构文档再按"计划 / 当前进度 / 最终报告"重建；
④ 顺便审计代码，删除无用/过时注释，修复名实不符；
⑤ 提交到本地仓库，期间不要占用用户的鼠标/键盘/屏幕。
## 改了什么
### 1. 体积（909,824 B -> 788,992 B，-120,832 B，-13.3%）
Makefile 新增三个可覆盖开关（默认全为 1）：
- `LAYOUT_BOUNDS` 编入/剔除「显示布局边界」叠加层
- `NO_EXCEPTIONS` 追加 `-fno-exceptions`
- `LTO` 追加 `-flto`（编译 + 链接）
派生：`FUNC_SECTIONS`（LTO 下为空）、`GC_SECTIONS`（`-Wl,--gc-sections`）、
`ASM_LISTING`/`ASM_LISTING_C`（LTO 下为空，因为 lto-wrapper 会丢弃 `-Wa` 清单）。
两个实测复现的坑（已写进 Makefile 注释）：
- **切换 LTO 必须 `make clean`**：LTO 与非 LTO 目标文件混链会让 GCC 15.2.0 在
`binds_to_current_def_p (symtab.cc:2598)` 处 ICE。
- **`-flto` 与 `-ffunction-sections -fdata-sections` 同时打开也 ICE**（干净重编也必崩，
报错落点是 `DataModel.hpp:393`，但那是 COMDAT 解析落点、不是原因）⇒
LTO 下 `FUNC_SECTIONS` 置空，并加 `-flto-partition=one`：默认 11 个分区的 LTRANS
稳定复现，单分区从未复现。**这是稳定性选项，不是性能选项。**
### 2. 关异常必须成对交付：预检验 + 兜底
新增 `Utilities/Inc/MemProbe.hpp` + `Utilities/Src/MemProbe.cpp`：
- `MemAvailablePhysical()`：`GlobalMemoryStatusEx` + 200ms 缓存
- `MemCanAllocate(bytes)`：预留后仍须保有 1/8 可用内存
- `MemReserveIfRoom(container, n)`：含 `capacity()` 早退与乘法溢出保护
- `MemInstallTerminateHandler()`：OOM 时弹一次带建议的模态提示后 `_Exit`（而不是静默消失）
接入：
- `Utilities/Src/DataModel.cpp`：全仓**唯一**的 `try/catch`（`extremes.reserve` 捕
`std::bad_alloc`）改为 `MemReserveIfRoom(extremes, count / 8)`
- `Components/PlotView/Src/PlotView.cpp`：`AvailablePhysicalBytes()` 原有一份**完整重复**
的 `GlobalMemoryStatusEx` + 缓存实现 → 转发 `MemAvailablePhysical()`
- `Components/Application/Src/Application.cpp`：`Initialize()` 开头安装 terminate handler
### 3. L1 几何产物层
新增 `Components/Shared/Inc/UiBox.hpp` + `Src/UiBox.cpp`：
- `struct UiBox { rect, clip, depth, layer }` —— 纯值类型，不继承任何东西
（继承会和 PlotView 4 层位图缓存 / SignalPanel 行位图缓存的失效体系打架）
- `class UiBoxTable : public UiTextRectSink` —— 只累计几何 + 裁剪/层/遮挡，**不含绘制代码**
`UiComponent::CollectDebugBoxes` → **`virtual void BuildBoxes(UiBoxTable&)`**：
组件从"收集布局边界（调试用）"改为"上报几何产物"，不再需要知道"调试"这个概念存在。
`UiDebugBounds.hpp/.cpp` 退化为唯一的消费者（配色 + 包角描边 + 遮挡挖洞）。
除宿主 `ApplicationCommands.cpp` 外，所有组件源码现在只包含 `UiBox.hpp`。
### 4. 审计
- `MemProbe` 里"省 40~60KB"的估算 → 改为实测 27,136 B
- `MemProbe.hpp` 的 `<new>`、`MemProbe.cpp` 的 `<cstdio>`：未使用，删除
- `UiDebugPaintBounds(g, rect, depth)`：零调用者，删除（只保留带 clip 的版本）
- `TabBar`/`Toolbar`/`PlotView`/`SignalPanel` 的 `BuildBoxes` 文档"（调试用）"→"几何 box"
- `PlotView::SetForceFullRepaint` 补写"为什么保留而不优化"
### 5. 文档
`Documents/UI_Refactor_Plan.md` / `_Progress.md` / `_Report.md` 先 `git rm` 再按
「计划 / 当前进度 / 最终报告」重建；`Documents/agent_mem.md` 追加第十三轮记录。
## 怎么验证
```
make clean
make release TARGET_FILE_NAME=JustDataInspector -j16 # 零 error / 零 warning，788,992 B
make debug TARGET_FILE_NAME=JustDataInspectorD -j16 # 零 warning
uicheck 69/69 lbcheck 21/21 lbresid 5/5 lbzorder 4/4 lbcovr 7/7 lbpanel 10/10
rendercheck: 8 个场景哈希与改造前逐一相同 + FUNC 7/7 PASS, exit=0
A FAED59DF284153DB B E6443BFE4E3955F8 C 96A0AA8C402F1729 D E3D5DBD998E43720
E DA0583CB13C26A6F F FFB822159F604D1D G 19F8DE8FE3A8DF18 H DBBDDE4CB2C97C92
```
体积溯源（`objdump -h`，基线 → 最终）：
`.text` 735,600 → 657,168；`.rdata` 49,184 → 35,016；
`.xdata` 48,132 → 27,512；`.pdata` 35,424 → 28,524；`.rsrc` 20,656 不变。
## 没做什么（有意为之）
- **没有拆 DLL**（用户明确要求单文件）
- **没有改优化等级**（`-Oz` 保持）
- **L2（`UiDamage` 脏矩形 + 独立叠加层）评估后缓做**：受益方只有"调试开关打开时的帧率"，
而正确实现必须把叠加层旧矩形注入底层组件重绘范围，穿透 PlotView 四条快路径 + 两层缓存；
在用户反复报过"拖拽错位 / 贴图残留"的背景下，风险与收益不成比例。理由写在
`Documents/UI_Refactor_Plan.md` §5 与 `PlotView::SetForceFullRepaint` 的文档里。
86 lines
2.9 KiB
C++
86 lines
2.9 KiB
C++
#ifndef __MEM_PROBE_HPP__
|
||
#define __MEM_PROBE_HPP__
|
||
|
||
#include <windows.h>
|
||
|
||
#include <cstddef>
|
||
#include <limits>
|
||
|
||
namespace jdi
|
||
{
|
||
|
||
/**
|
||
* @brief 可用物理内存的估算值（字节，带 200ms 缓存）。
|
||
*
|
||
* ⚠️ **为什么需要它**：本项目用 `-fno-exceptions` 构建（`.xdata`+`.pdata` 占产物体积约 9%，
|
||
* 关闭后**实测省 27,136 B**：909,824 → 882,688）。关闭异常后，
|
||
* `std::vector::reserve` 之类的分配失败**不再抛
|
||
* `std::bad_alloc`**，而是直接 `std::terminate` —— 因此凡是"按数据规模预留大块内存"
|
||
* 的地方，都必须先**预检验**（本函数）再决定是否预留。
|
||
*
|
||
* `GlobalMemoryStatusEx` 是系统调用，结果按 200ms 缓存：内存变化远慢于该间隔，
|
||
* 而绘制路径上每帧可能请求多次。
|
||
*
|
||
* @return 可用物理内存字节数；查询失败时返回 `SIZE_MAX`（视为"内存充足"）。
|
||
*/
|
||
std::size_t MemAvailablePhysical();
|
||
|
||
/**
|
||
* @brief 判断"再分配 `bytes` 字节是否安全"。
|
||
*
|
||
* 判据是"预留后仍保有至少 `kMemHeadroomRatio` 的可用内存"，避免把系统逼到换页。
|
||
*
|
||
* @param [IN] bytes 计划分配的字节数。
|
||
* @return 安全返回 true。
|
||
*/
|
||
bool MemCanAllocate(std::size_t bytes);
|
||
|
||
/**
|
||
* @brief 按数据规模预留的**安全版**：只有确认内存够才 reserve。
|
||
*
|
||
* 预留失败在语义上只是"少了一次性优化"：不预留时 `push_back` 会按 1.5~2 倍自行增长，
|
||
* 结果依然正确（只是多几次 realloc）。因此在 `-fno-exceptions` 下这条路径
|
||
* **既不会崩、也不会改变行为**。
|
||
*
|
||
* @tparam T 元素类型。
|
||
* @param [IN,OUT] container 目标容器（需支持 `reserve` / `capacity` / `size`）。
|
||
* @param [IN] count 期望容量（元素个数）。若已足够则什么都不做。
|
||
* @return 真的执行了预留返回 true。
|
||
*/
|
||
template <typename Container>
|
||
bool MemReserveIfRoom(Container& container, std::size_t count)
|
||
{
|
||
if (count <= container.capacity())
|
||
{
|
||
return false;
|
||
}
|
||
const std::size_t elementSize = sizeof(typename Container::value_type);
|
||
// 溢出保护：count * elementSize 可能超出 size_t。
|
||
if (elementSize != 0 && count > (std::numeric_limits<std::size_t>::max() / elementSize))
|
||
{
|
||
return false;
|
||
}
|
||
if (!MemCanAllocate(count * elementSize))
|
||
{
|
||
return false;
|
||
}
|
||
container.reserve(count);
|
||
return true;
|
||
}
|
||
|
||
/**
|
||
* @brief 安装"内存不足"兜底处理（`std::set_terminate`）。
|
||
*
|
||
* 在 `-fno-exceptions` 下，任何遗漏的分配失败都会走到 terminate。
|
||
* 默认的 terminate 会静默 abort（用户只看到程序消失）；本函数改为
|
||
* **弹一次模态提示（含"请减少同时显示的网格数/信号数"的建议）后干净退出**，
|
||
* 让用户知道发生了什么。
|
||
*
|
||
* 幂等：重复调用只安装一次。
|
||
*/
|
||
void MemInstallTerminateHandler();
|
||
|
||
} // namespace jdi
|
||
|
||
#endif // __MEM_PROBE_HPP__
|