性能优化
[🕒 预计 20 分钟] | 难度：进阶
1. 界面卡顿优化
1.1 大批量列表更新
向列表控件批量插入大量条目时，不要在事件或线程循环中逐条刷新界面——每秒数千次 UI 更新会让界面彻底卡死。正确做法：
- 用
线程_提交进度(&工作处理器, &进度处理器, &完成处理器, 参数)提交任务。进度通知由运行时合并后再派发，界面更新只发生在进度与完成处理器里。 - 工作处理器里只算不画：用
线程_报告进度(百分比, 说明)汇报进度，禁止直接操作 Win32 控件。 - 列表确实需要大量条目时，先在完成处理器里一次性写入；批量插入前应关闭控件重绘，写完再恢复。
WARNING
多线程模块 1.x 的 线程_批量启动、线程_启动延时设置文本、线程_启动延时添加行、线程_启动延时添加项目、线程_休眠、线程_等待全部、线程_活动数量、线程_硬件并发数 在 2.0 中已列为旧版命令，不再贡献命令实现，调用会被诊断阻断。旧项目请改用 线程_提交进度 + 线程_协作等待 + 线程_等待。
lcpp
// 大规模任务：一次提交，进度合并，界面只在处理器里更新
线程任务 任务 = 线程_提交进度(&导入数据, &导入进度, &导入完成, 文件列表)1.2 不要阻塞界面线程
- 在界面事件中调用
线程_等待、线程池_等待空闲等同步等待命令会直接卡住界面；确需等待时必须给有限超时，并优先把后续逻辑放进完成处理器。 - 后台任务里的短暂让出用
线程_协作等待(毫秒)，它同时是协作取消的响应点；配合线程_请求取消(任务)与线程_是否请求取消(0)实现可中断的长任务。 - 网络请求使用
HTTP客户端_GET异步等异步入口，完成后再通过处理器回调更新界面。 - 完成的任务用
线程_释放任务单独回收，或用线程_清理已完成批量清理，避免任务对象堆积。
2. 内存与资源
- JSON 值等由模块创建的对象，用完后调用对应释放命令（如
JSON_释放）。 - 图片资源尽量压缩尺寸后再加载。
- 列表数据频繁增长时注意清理过期条目。
3. 构建产物
| 手段 | 说明 |
|---|---|
| 按需 SDK | 模块的 C++ 依赖按需物化到构建目录，未启用模块不参与编译 |
| 发布运行库 | 交付前确认目标机器已安装 Visual C++ Redistributable |
| 精简发布 | 参考 打包发布 的离线精简发布流程 |
4. 定位性能问题
- 用
调试输出在关键路径输出时间点，结合底部 输出面板 观察耗时分布。 - 界面卡顿时优先检查：是否在事件中同步执行了耗时操作、是否高频逐条刷新列表控件。