be1f5722ab
- 实现 AI 起名功能（Kimi API 接入） - 添加用户收藏功能（MySQL 数据库） - 实现海报生成与分享 - 添加音效和触觉反馈 - 配置生产环境部署（WAR 包 + Nginx） - 支持多种起名模式（经典、诗词、自然、现代） - 实现分批加载优化体验
69 lines
3.5 KiB
Markdown
69 lines
3.5 KiB
Markdown
---
|
||
|
||
见素起名：异步并行生成与体验优化手册
|
||
|
||
本手册涵盖 阶段 4：后端异步架构重构 与 前端“分批渲染”感知优化 的核心实现步骤。
|
||
|
||
---
|
||
|
||
🚀 核心逻辑：从“排队”到“赛跑”
|
||
- 优化前：请求一次 AI $\rightarrow$ 等待 AI 吐出 5 个名字 $\rightarrow$ 后端处理 $\rightarrow$ 返回（耗时 $T
|
||
\times 5$）。
|
||
- 优化后：后端同时发起 5 个 AI 请求 $\rightarrow$ 谁先跑完谁先返回 $\rightarrow$ 前端分批展示（体感耗时 $\approx
|
||
T$）。
|
||
|
||
---
|
||
|
||
第一部分：后端 - 高并发异步生成重构 (Java)
|
||
|
||
第一步：配置专用线程池 (Safety)
|
||
在 backend/src/main/java/com/jiansu/naming/config/AsyncConfig.java (需新建) 中配置。
|
||
- [ ] 定义 ThreadPoolTaskExecutor，设置核心线程数（建议 10-20）和最大线程数。
|
||
- [ ] 为线程设置清晰的前缀 jiansu-ai-，便于监控和排查。
|
||
|
||
第二步：重构 MiniMaxService (Service)
|
||
- [ ] 剥离单次逻辑：将原有的 AI 调用代码封装为私有方法 callAiToGenerateSingleName，确保其只负责生成 1 个 名字。
|
||
- [ ] 实现并发调度：
|
||
- 使用 CompletableFuture.supplyAsync(..., executor) 发起 5 个并行任务。
|
||
- 使用 CompletableFuture.allOf(...) 或 join() 合并结果集。
|
||
- [ ] 异常容错：为单个任务添加 .exceptionally() 处理，确保即便某个 AI 请求失败，也不会导致整批请求崩溃。
|
||
|
||
---
|
||
|
||
第二部分：前端 - “分批加载”感知优化 (MiniProgram)
|
||
|
||
第三步：打造“意境感”加载页 (UI/UX)
|
||
在 pages/index/index.wxml 中实现。
|
||
- [ ] 增加 .loading-container 遮罩，背景采用极简白或微弱水墨色。
|
||
- [ ] 实现动态文案区 .loading-text，用于展示加载语。
|
||
- [ ] 视觉补偿：在 index.js 中设置 loadingQuote 定时器，每 2s 随机轮换文案（如：“正在翻阅《古今集成》...”）。
|
||
|
||
第四步：实现分批渲染逻辑 (Logic)
|
||
在 pages/index/index.js 中修改 fetchNames。
|
||
- [ ] 第一波（极速）：请求后端获取前 2 个名字。
|
||
- [ ] 渲染首屏：拿到 2 个结果后立即关闭 Loading，让用户可以开始翻阅卡片。
|
||
- [ ] 第二波（静默）：在首屏展示后，静默请求剩余的 3 个名字。
|
||
- [ ] 数组合并：使用 [...this.data.nameList, ...secondBatch] 将新老数据平滑合并。
|
||
|
||
---
|
||
|
||
第三部分：性能深度优化 (Advanced)
|
||
|
||
第五步：音律分析延迟计算 (Optional)
|
||
- [ ] 如果平仄音律分析 (ToneAnalysisService) 依然耗时较长，修改接口返回结构：
|
||
- 先返回名字、出处和解析。
|
||
- 音律分数字段初始返回 null 或 "计算中"。
|
||
- 前端在用户翻转卡片到背面时，再根据名字发起一个微小的音律请求（或后端在并行任务中异步填充）。
|
||
|
||
---
|
||
|
||
✅ 验收与调试清单
|
||
1. 耗时监控：在后端日志中打印 generateNamesAsync 的执行时间，确认是否在 3s 以内。
|
||
2. 并发压力：同时开启 5 个并发请求时，观察 MiniMax API 是否触发频率限制（Rate Limit），必要时在自定义 Executor
|
||
中限制最大并发。
|
||
3. 用户体感：
|
||
- 是否在 1.5s 左右就看到了第一张名字卡片？
|
||
- 翻阅前两张卡片后，后续的卡片是否已经静默加载完成？
|
||
4. 稳定性：断网或 AI 接口报错时，前端是否能友好地显示“灵感中断”并允许重试。
|
||
|
||
--- |