docs: 补充双模式资源优化分析

docs/Rtc_AIavatar/双模式分支资源优化分析报告.md

@@ -0,0 +1,468 @@
+# 双模式分支资源优化分析报告
+
+> **分支**：`adaptation_eaf_rtc_badge_dual_mode`
+> **分析日期**：2026-06-03
+> **硬件**：ESP32-S3-N16R8（16 MB Flash / 8 MB PSRAM / 320 KB Internal SRAM）
+> **目的**：盘点当前资源使用，识别后续优化空间（硬件资源 + 存储空间角度）。本文档仅分析，不含代码改动。
+
+---
+
+## 一、当前资源使用真相
+
+### 1.1 Flash（16 MB 物理）
+
+| 分区 | 容量 | 已用 | 余量 | 利用率 |
+|---|---|---|---|---|
+| `factory` (app) | 7.00 MB | **5.75 MB** | 1.25 MB | 82% |
+| `storage` (SPIFFS) | 8.94 MB | **4.40 MB** | 4.54 MB | 49% |
+| nvs + phy_init | 20 KB | 20 KB | 0 | — |
+| **未分配** | — | — | **45 KB** | — |
+
+**固件 5.75 MB 内部分布**：
+- `.rodata`（常量 / 字体 / 资源）= **3.53 MB（61%）** ⚠️ 最大头
+- `.text`（代码）= 2.10 MB（37%）
+- `.bss / .data`（静态变量）= 56 KB
+
+### 1.2 DRAM（Internal SRAM，320 KB 物理 / 实际可用 ~341 KB DIRAM）
+
+- **已用 167 KB / 341 KB（50.89%）** — ESP32-S3 上**最稀缺**资源
+- 其中 `.text`（IRAM）119 KB + `.data` 28 KB + `.bss` 25 KB
+- **余 167 KB** 给运行时堆栈 + WiFi + BLE + 其他堆
+
+### 1.3 PSRAM（8 MB 物理）
+
+- 当前占用约 1-2 MB（hiyori-assets cache + 背景图解码 buffer + 杂项）
+- **余约 6 MB** —— **最富余**资源
+
+### 1.4 SPIFFS 实际内容（4.40 MB）
+
+| 文件 | 大小 |
+|---|---|
+| `hiyori-assets.bin`（8 张 EAF 表情 m01-m08）| 4.33 MB |
+| `Background_360x360.jpg` | 20 KB |
+| `02.jpg` / `default.jpg` | 30 KB |
+
+**EAF 表情明细**（hiyori-assets.bin 内含 9 个文件）：
+
+| 文件 | 大小 |
+|---|---|
+| index.json | 1.1 KB |
+| hiyori_m01.eaf | 834 KB |
+| hiyori_m02.eaf | 528 KB |
+| hiyori_m03.eaf | 577 KB |
+| hiyori_m04.eaf | 573 KB |
+| hiyori_m05.eaf | 620 KB |
+| hiyori_m06.eaf | 433 KB |
+| hiyori_m07.eaf | 388 KB |
+| hiyori_m08.eaf | 579 KB |
+
+---
+
+## 二、本分支已完成的优化（正面评估）
+
+| # | 优化项 | 收益估算 | 价值 |
+|---|---|---|---|
+| 1 | 取消双 OTA → factory 单 app 分区 + 扩 SPIFFS | +4 MB SPIFFS | 🟢 高 |
+| 2 | BLE 5.0 关闭 + ACL 1 连接 + cache 缩小（详见 §2.1）| ~20-30 KB DRAM | 🟢 高 |
+| 3 | SquareLine UI 与 EAF 互斥编译 | 部分 Flash | 🟢 高 |
+| 4 | 拆分 `dzbj_hw_display_init` / `dzbj_display_init` | 配网/AI 不创建 LVGL → 节省 DRAM | 🟢 高 |
+| 5 | 图传上限 10 → 100 张 | +90 张容量 | 🟡 中 |
+| 6 | 移除旧 LVGL emoji / icon C 数组 | ~50 KB Flash | 🟡 中 |
+| 7 | 配网最小 EAF 显示栈 | 节省 4.32 MB PSRAM + 30 KB DRAM | 🟢 高 |
+
+### 2.1 BLE 内存优化明细（sdkconfig.defaults 改动）
+
+| 配置 | 改前 | 改后 |
+|---|---|---|
+| `CONFIG_BT_ACL_CONNECTIONS` | 4 | 1 |
+| `CONFIG_BT_MULTI_CONNECTION_ENBALE` | y | 关闭 |
+| `CONFIG_BT_SMP_MAX_BONDS` | 15 | 2 |
+| `CONFIG_BT_CTRL_BLE_MAX_ACT` | 6 | 2 |
+| `CONFIG_BT_CTRL_ADV_DUP_FILT_MAX` | 30 | 10 |
+| `CONFIG_BT_CTRL_SCAN_DUPL_CACHE_SIZE` | 100 | 10 |
+| `CONFIG_BT_BLE_42_DTM_TEST_EN` | y | 关闭 |
+| `CONFIG_BT_CTRL_DTM_ENABLE` | y | 关闭 |
+
+**这些方向都正确**。以下是仍可优化的空间。
+
+---
+
+## 三、剩余优化空间（按 ROI 排序）
+
+### 🔴 P0 — 高 ROI（短期可做）
+
+#### P0-1. 字体裁字符集（最大单点收益）
+
+| 项 | 当前 | 优化后 |
+|---|---|---|
+| `font_puhui_20_4.c` 源码 | 8.5 MB | ~3-4 MB（裁到 3000 常用字）|
+| 编译后 .rodata 占用 | **~1.4 MB** | **~400-600 KB** |
+| 操作 | 用 LVGL Font Converter 或 [78/xiaozhi-fonts](https://github.com/78/xiaozhi-fonts) 重生成，仅保留 ASCII + 3000 常用字 + 标点 |
+| **节省 Flash** | **800 KB - 1 MB** | .rodata 从 3.5 MB 降到 ~2.7 MB |
+
+**为何 P0**：字幕主要显示 AI 中文回复，3000 常用字覆盖 99% 中文，收益最大。
+
+**2026-06-03 字库对比复核**：
+
+| 项 | 当前 Baji 字库 | 喵伴 ESP-VoCat 字库 |
+|---|---|---|
+| 字库文件 | `main/fonts/font_puhui_20_4.c` | `assets/font/font_puhui_common_20_4.bin` |
+| 字库格式 | LVGL `.c` 静态编译进 app | `cbin` 二进制字体资源 |
+| 文件大小 | 8,533,399 bytes（约 8.1 MB 源码） | 1,240,332 bytes（约 1.18 MiB / 显示 1.2 MB） |
+| Unicode 映射字符数 | 约 8055 个 | 约 6813 个 |
+| 实际字形数量 | 约 7538 个 | 约 6656 个 |
+| 固件占用 | 编译后约 1.35-1.4 MB `.rodata` | 作为资源文件约 1.2 MB，不直接进入 app `.rodata` |
+| 覆盖特点 | 覆盖更宽，含更多中文、符号、日文假名等 | 常用中文集，覆盖少于当前 Baji，但不是 3000 字级别小字库 |
+
+**结论**：
+- 当前 Baji 字库确实是 app `.rodata` 中最大的单点资源之一，编译后占用约 1.4 MB。
+- 喵伴字库大小确认为 1.2 MB，字符覆盖约 6813 个 Unicode 映射，不是 3000 字级别裁剪。
+- 如果目标是**显著减少 app 分区压力**，优先裁剪当前 `.c` 字库到 `ASCII + 常用标点 + 3000-4000 高频中文`，预计比直接照搬喵伴更省。
+- 如果目标是**参考成熟方案并把字库移出 app rodata**，可以研究喵伴 `cbin` 字库加载方式，但这属于架构调整，需要评估当前 EAF/GFX/LVGL 字体加载路径兼容性。
+
+#### P0-2. 日志级别 + assertion 降级（量产前必做）
+
+| 配置 | 当前 | 量产建议 |
+|---|---|---|
+| `BOOTLOADER_LOG_LEVEL` | NONE ✓ 已做 | — |
+| `LOG_DEFAULT_LEVEL` | INFO | ERROR / WARN |
+| `LOG_MAXIMUM_LEVEL` | INFO | ERROR |
+| `COMPILER_OPTIMIZATION_ASSERTIONS` | ENABLE | SILENT |
+
+- **节省 Flash**：50-150 KB（日志字符串去掉 + 函数变薄）
+- **节省 CPU**：日志格式化 + UART 输出延迟降低
+- **降低 DRAM**：log buffer 缩小
+
+#### P0-3. WiFi RX 缓冲扩容（音质保险，原 Phase 11 核心）
+
+| 配置 | 当前 | 建议 |
+|---|---|---|
+| `CONFIG_ESP_WIFI_STATIC_RX_BUFFER_NUM` | 10 | 16 |
+| `CONFIG_ESP_WIFI_DYNAMIC_RX_BUFFER_NUM` | 32 | 48 |
+| `CONFIG_ESP_WIFI_RX_BA_WIN` | 6 | 16 |
+
+- **DRAM 增量**：~10-15 KB（余 167 KB 完全够）
+- **收益**：RTC 网络突发吸收能力 ↑，进一步保险音频流畅
+- **备注**：这是规划中的 Phase 11 主要内容，本分支尚未做
+
+---
+
+### 🟠 P1 — 中 ROI（中期考虑）
+
+#### P1-4. 吧唧 UI 图片资源外移到 SPIFFS
+
+**当前状态**：
+- 这里主要指电子吧唧 / LVGL / SquareLine 生成的 `ui/images/*.c` 图片资源。
+- 这些图片被转成 C 数组后，会跟 app 一起编译进固件，通常进入 Flash app 分区的 `.rodata`。
+- 好处是显示路径简单，运行时可以直接从 Flash XIP 映射读取，不需要文件系统打开和图片解码。
+- 代价是 app 固件体积变大，`factory` 分区压力增加。
+
+**优化方式**：
+- 不再把部分图片转成 `.c` 静态数组。
+- 将 PNG/JPG/WebP 等原始图片作为文件放到 SPIFFS / LittleFS / FATFS。
+- 运行时按需从文件系统读取，再通过 `esp_jpeg` / `esp_lcd` / LVGL image decoder 解码显示。
+
+**收益对象**：
+- 主要节省的是 **app 分区 Flash / `.rodata`**。
+- 不会减少 16 MB Flash 总资源占用，只是把资源从 app 固件挪到数据分区。
+- 对后续电子吧唧图片资源增多、UI 资源频繁替换更友好。
+
+**代价与风险**：
+- SPIFFS / LittleFS 数据分区占用会增加。
+- 首次打开和解码图片会产生延迟，需要运行时 buffer。
+- JPEG/PNG 解码会消耗 CPU，复杂大图可能影响切换流畅度。
+- 需要改资源加载路径，工作量和回归测试量都高于字体裁剪。
+
+**建议**：
+- 当前不作为第一优先级。
+- 如果后续电子吧唧 UI 资源继续变多，或 app 分区明显吃紧，再优先迁移只属于 `CONFIG_BAJI_BADGE_MODE` 的图片。
+- 对高频显示、启动首屏、关键提示图，仍可保留 `.c` 方式，减少文件系统和解码延迟。
+
+#### P1-5. PSRAM LRU 缓存（10+ 张 EAF 时启用）
+
+**当前状态**：
+- 这里的 8 张表情指 `/spiffs_image/hiyori-assets.bin` 内的 EAF 表情资源：
+  - `hiyori_m01.eaf` 到 `hiyori_m08.eaf`
+- 当前如果 AI 数字人启动时把所有 EAF 表情都预加载到 PSRAM，切换表情最快，但运行时 PSRAM 会一次性占用约 4 MB。
+- 当前模组是 8 MB PSRAM，短期 8 张表情还能承受；真正的问题出现在未来扩展到 16 张、30 张或更多表情时。
+
+**优化方式**：
+- 不再一次性加载所有 EAF 表情。
+- 固定只缓存最近使用的少量表情，例如 3 槽位：
+  - 当前正在播放的表情
+  - 上一个或常用表情
+  - 下一个预测表情 / 即将切换的表情
+- 未命中缓存时，再从 `hiyori-assets.bin` 读取对应 `.eaf` 到 PSRAM。
+
+**收益对象**：
+- 节省的是 **运行时 PSRAM**，不是 Flash。
+- 让 EAF 表情数量增长时，PSRAM 占用不再线性增长。
+- 给 RTC、音频 buffer、BLE、JPEG 解码、临时 frame buffer 留出更多外部内存余量。
+
+**卡顿风险**：
+- 如果“需要时才同步读取 EAF”，首次切换到未缓存表情时可能卡顿。
+- EAF 文件通常数百 KB，SPI Flash 读取 + 解析 + 分配 PSRAM 都可能影响动画连续性。
+
+**降低卡顿的做法**：
+- 不做纯同步懒加载，改为后台异步预加载。
+- 在 AI 回复间隙、表情不变时，提前加载高概率表情。
+- 保留常用表情常驻，例如默认/说话/开心/待机。
+- 切换表情时如果目标表情未命中缓存，先继续播放当前表情，加载完成后再平滑切换。
+
+**建议**：
+- 当前 8 张表情可以暂时不做。
+- 当表情数量超过 10-12 张，或 PSRAM 峰值接近风险线时，再做 LRU。
+- LRU 实施前必须先打点统计：EAF 加载耗时、PSRAM 峰值、表情切换耗时、动画是否掉帧。
+
+#### P1-6. SPIFFS 双分区按模式 mount
+
+**当前问题**：`hiyori-assets.bin (4.33 MB)` 在 SPIFFS 里始终占用，吧唧模式实际不需要。
+
+**优化方案**：
+```
+storage_ai,     data, spiffs, ...,  0x500000,  # 5 MB AI 用（含 hiyori EAF）
+storage_badge,  data, spiffs, ...,  0x3F0000,  # ~4 MB 吧唧用（图传图片）
+```
+- AI 模式仅 mount `storage_ai`，吧唧模式仅 mount `storage_badge`
+
+**重要纠正**：
+- 这个优化**不会让总 Flash 变大**。
+- 也不是严格意义上的“两模式各自能用更多资源”。
+- 更准确的说法是：**按模式做资源隔离，避免 AI 资源和电子吧唧图传资源互相挤占、互相误删、互相污染**。
+
+**实际意义**：
+- AI 模式只关心数字人资源，例如 `hiyori-assets.bin`、背景图、AI 模式配置。
+- 电子吧唧模式只关心 APP 图传图片、GIF、吧唧素材。
+- 双分区后，电子吧唧图传再多，也不会占掉数字人 EAF 空间。
+- 数字人 EAF 后续扩展，也不会压缩 APP 图传图片空间。
+- 文件系统挂载、格式化、清理图片时边界更清晰，降低误删数字人资源的风险。
+
+**代价与风险**：
+- 分区表需要重新设计。
+- 两个分区的容量比例需要提前规划，规划错了会造成一边不够用、一边有空余。
+- 需要确认当前 APP 图传逻辑、EAF 加载逻辑都能按当前模式选择对应 mount point。
+
+**建议**：
+- 如果电子吧唧图传图片和 AI 数字人资源后续都会持续增加，双 SPIFFS 分区值得做。
+- 如果当前只是一个验证分支，且资源规模稳定，可以暂时保持单 SPIFFS，避免引入分区迁移和烧录兼容问题。
+
+#### P1-7. BackgroundTask 栈优化
+
+**当前状态**：
+- 当前 `BackgroundTask` 栈大小为 `4096 × 8 = 32 KB`。
+- 这个栈不是“数字人背景图专用任务栈”，而是项目通用后台任务栈。
+- 它可能承接音频恢复、异步状态切换、播放收尾、RTC 相关串行操作、codec 输出恢复等后台调度。
+
+**收益对象**：
+- 节省的是 **Internal DRAM / DIRAM**，不是 8 MB PSRAM。
+- 对 ESP32-S3 来说，内部 DRAM 比 PSRAM 更宝贵，因为 WiFi、BLE、FreeRTOS 栈、驱动和部分 DMA 相关资源都会竞争内部内存。
+- 16 KB 对 8 MB PSRAM 来说很小，但对内部 DRAM 来说仍有实际价值。
+
+**实施方式**：
+- 先加 `uxTaskGetStackHighWaterMark()` 打印实际栈水位。
+- 覆盖以下场景后再判断能否缩小：
+  - BLE 配网
+  - RTC 连接 / 对话 / 软退出 / 唤醒
+  - 本地待命音播放
+  - EAF 表情切换
+  - 电子吧唧图传和模式切换
+- 如果峰值长期小于 16 KB，再考虑从 32 KB 缩到 16 KB。
+
+**建议**：
+- 不要盲目缩栈。
+- 这是一个“小而稳”的优化，适合在功能稳定后做。
+- 如果栈水位不充足，宁可保留 32 KB，避免难排查的随机崩溃。
+
+---
+
+### 🟡 P2 — 长远优化（产品化考虑）
+
+#### P2-8. OTA 重新引入（牺牲 SPIFFS 换升级能力）
+
+当前完全砍 OTA，产品化痛点：远程升级无法、现场维护必须 USB。
+
+| 方案 | factory | ota_0/1 | SPIFFS |
+|---|---|---|---|
+| 当前（无 OTA）| 7 MB | — | 8.94 MB |
+| 方案 X：单 OTA + 大 SPIFFS | — | 5×2=10 MB | 5.5 MB |
+| 方案 Y：HTTPS OTA + factory | 7 MB | 1 MB OTA | 7.94 MB |
+
+**方案理解**：
+- 双 OTA（`ota_0 + ota_1`）最安全，升级失败可回滚，但最消耗 Flash。
+- 单 OTA / factory + 小 OTA 占用相对小，但失败保护弱，断电、下载失败、校验失败时设计不当会有变砖风险。
+- 当前项目已经取消 OTA，把空间让给 app 和 SPIFFS，这是为了双模式资源和 APP 图传容量服务。
+
+**建议**：
+- 如果后续产品必须远程升级，优先考虑双 OTA 或有完整回滚保护的 OTA 方案。
+- 如果该项目主要靠 USB 烧录维护，继续保持无 OTA 更符合当前资源目标。
+- 不建议为了“预留可能性”过早恢复 OTA，否则会明显压缩电子吧唧图传和数字人资源空间。
+
+#### P2-9. PSRAM XIP（暂不推荐，需重新评估收益）
+
+```
+CONFIG_SPIRAM_XIP_FROM_PSRAM=y
+CONFIG_SPIRAM_FETCH_INSTRUCTIONS=y
+CONFIG_SPIRAM_RODATA=y
+```
+
+**重要纠正**：
+- PSRAM 是外部 DRAM，掉电丢失，不能当永久存储使用。
+- PSRAM XIP 不等于把资源永久从 16 MB Flash 搬到 8 MB PSRAM。
+- 代码和 `.rodata` 最终仍然需要存在 Flash 中，启动后再通过映射/复制等方式参与执行或读取。
+- 因此它不应被当作“直接节省 16 MB Flash 空间”的主要手段。
+
+**可能收益**：
+- 某些场景下可以调整运行时取指/读取路径。
+- 对 cache、执行位置、PSRAM 利用率可能有帮助。
+- 但对当前 app 分区体积的收益不如字体裁剪、日志裁剪、图片资源外移直接。
+
+**风险**：
+- 占用 PSRAM。
+- 引入 PSRAM 时序、cache、取指稳定性风险。
+- 当前项目同时包含 RTC、BLE、EAF、音频播放、WiFi，这些模块对时序和内存稳定性比较敏感。
+- 历史上 N16R8 + 80 MHz PSRAM 与高负载音频/RTC 场景需要充分验证。
+
+**建议**：
+- 当前不推荐作为优化项推进。
+- 文档中将其保留为“研究备选”，而不是执行建议。
+- 真正需要节省 Flash 时，优先级应为：字体裁剪 > 日志裁剪 > 移除未用组件 > 图片资源外移/压缩 > 再评估 PSRAM XIP。
+
+#### P2-10. CPU 频率调控（功耗）
+
+**适用状态**：
+- 主要指 AI 对话模式下的 idle / hibernate / 等待唤醒状态。
+- 例如 RTC 已软退出、没有音频采集播放、屏幕处于待机提示或低亮状态时，从 240 MHz 降到 80 MHz。
+- 一旦进入 RTC 对话、音频播放、BLE 图传、EAF 高负载动画，再拉回高频。
+
+**实施方式**：
+- 启用 `CONFIG_PM_ENABLE=y`。
+- 对 RTC、音频播放、EAF 动画、BLE 图传等关键阶段加 PM lock，防止运行中被降频。
+- 待机/hibernate 阶段释放 PM lock，让系统降频。
+
+**收益对象**：
+- 主要收益是功耗和发热，不是 Flash/RAM。
+- 对电池续航有价值。
+
+**风险**：
+- 可能影响任务调度精度、唤醒延迟、WiFi/RTC 时序。
+- 必须实测：待机唤醒速度、RTC 重连、首包音频延迟、BLE 配网和图传稳定性。
+
+#### P2-11. 触摸 IC 按模式禁用
+
+**当前状态**：
+- 当前 `DZBJ_ENABLE_TOUCH=1` 时，触摸 IC 可能在双模式中都被初始化。
+- 如果某个模式完全不需要触摸，理论上可以按模式跳过触摸初始化。
+
+**收益对象**：
+- 少量内部 DRAM。
+- 少量 CPU 轮询/中断处理。
+- 少量 I2C/GPIO 资源占用。
+
+**现实判断**：
+- 如果后续 AI 对话模式也要启用触摸交互，这项收益会明显降低。
+- 它不是当前资源大头，优化收益偏低。
+
+**建议**：
+- 暂不作为优先项。
+- 只有在确认某个模式长期不需要触摸时，再按模式禁用触摸 IC。
+
+#### P2-12. RTC SDK jitter buffer 扩容
+
+- 火山 RTC SDK 内部 jitter buffer 可适当调大，占用约 30-50 KB PSRAM。
+- 作用是吸收 WiFi 网络抖动、包到达不均匀、短时间突发延迟。
+- 对“接收来自火山 RTC 的音频播放卡顿、抖动、断续”有改善方向。
+
+**收益**：
+- 下行音频播放更稳。
+- 瞬时网络抖动时不容易立刻卡顿。
+
+**代价**：
+- 端到端播放延迟会略微增加。
+- PSRAM 占用增加几十 KB。
+
+**建议**：
+- 如果目标是“播放稳定优先”，可以适当调大。
+- 如果目标是“AI 回复低延迟优先”，不要调得过大。
+- 需要结合真实 WiFi 环境、RTC 日志、用户体感做 A/B 测试。
+
+---
+
+## 四、双模式架构评估
+
+### 4.1 设计已合理（无需大改）
+
+| 维度 | 当前 | 评价 |
+|---|---|---|
+| 模式存储 | NVS flag（`device_mode`）| ✅ 标准做法 |
+| 切换方式 | `esp_restart()` 冷启动 | ✅ 比热切换可靠（避免资源泄漏 + 碎片）|
+| 资源隔离 | 编译期 `#ifdef` + 运行期分支 | ✅ 最佳实践 |
+| LCD 共用 | 硬件共用 + UI 框架二选一 | ✅ 无更优方案 |
+
+### 4.2 唯一可改进点：启动速度
+
+**当前状态**：
+- 当前冷启动 → 进入对应模式约 5-8 秒（需要以后继续用日志量化）。
+- 双模式采用 `esp_restart()` 冷启动切换模式是合理的，优先保证资源干净释放和稳定性，不建议为了启动速度改成复杂热切换。
+
+**可优化方向**：
+- bootloader log 已关闭，继续保持。
+- 在 `app_main` 更早读取 NVS 模式标志，尽量在 board 初始化前完成模式分流。
+- 配网模式、AI 模式、电子吧唧模式分别只初始化必要业务，避免无关任务、UI 栈、资源加载提前启动。
+- EAF 资源加载改为异步任务，避免 `ai_chat_screen_init` 或首屏显示被完整资源加载阻塞。
+- 首屏先显示最小可用状态，例如待机提示/加载提示；表情资源后台加载完成后再进入完整数字人状态。
+
+**预期效果**：
+- 仅做日志减少、模式分流提前、跳过无关初始化：现实目标约从 5-8 秒缩短到 3-5 秒。
+- 如果 EAF 资源异步化，用户体感可做到 2-3 秒内看到响应画面，但完整数字人表情资源就绪仍可能需要更久。
+- 优化重点不是“所有资源瞬间加载完”，而是让用户更早看到设备已经启动、可交互或正在准备。
+
+**风险**：
+- 异步加载会让状态机更复杂。
+- 必须处理资源未就绪时的表情切换、字幕显示、模式切换和软退出。
+- 当前功能稳定时，不建议为了启动速度过度重构。
+
+---
+
+## 五、综合优先级建议清单
+
+| 优先级 | 项目 | 收益 | 工作量 | 风险 |
+|---|---|---|---|---|
+| 🔴 P0-1 | 字体裁字符集 | -800 KB Flash | 0.5 天 | 低 |
+| 🔴 P0-2 | 日志 / assertion 降级 | -100 KB Flash + CPU | 30 分钟 | 低（量产前）|
+| 🔴 P0-3 | WiFi RX 缓冲扩容 | 音频更稳 +10 KB DRAM | 1 小时 | 低 |
+| 🟠 P1-4 | UI 图片移 SPIFFS | -3-5 MB Flash | 2-3 天 | 中 |
+| 🟠 P1-5 | EAF PSRAM LRU cache | 限制 PSRAM 峰值 | 1-2 天 | 中（需防切换卡顿） |
+| 🟠 P1-6 | SPIFFS 双分区 | 模式间资源隔离 | 1 天 | 低 |
+| 🟠 P1-7 | BackgroundTask 栈缩小 | -16 KB 内部 DRAM | 半天 | 低（需先测水位） |
+| 🟡 P2-8 | OTA 重新引入 | 远程升级能力 | 1-2 天 | 中 |
+| ⚪ P2-9 | PSRAM XIP | 收益不明确 | 研究项 | 高（当前不推荐） |
+| 🟡 P2-10 | CPU PM | 功耗 -30% 待机 | 1-2 天 | 中 |
+| 🟡 P2-11 | 触摸按模式 init | DRAM + CPU 小幅 | 半天 | 低（若 AI 也用触摸则收益低） |
+| 🟡 P2-12 | RTC SDK jitter 扩容 | 下行音频更稳 | 半天 | 低（代价是延迟） |
+
+---
+
+## 六、最高 ROI 总结
+
+- **只做一件事** → **P0-1 字体裁字符集**：1 个改动省 800 KB Flash，当前 Flash 利用率优化的最大单点收益。
+- **只做两件事** → 再加 **P0-3 WiFi RX 缓冲扩容**：直接服务核心 KPI（RTC 音频稳定性）。
+- **时间充裕** → P0 三项 + P1-4：继续降低 app 分区压力，但 P1-4 会改图片加载路径，需要完整回归电子吧唧 UI。
+- **资源规模扩大后** → P1-5 / P1-6：一个控制 EAF 运行时 PSRAM 峰值，一个做 AI 与电子吧唧资源隔离。
+- **暂不推荐推进** → P2-9 PSRAM XIP：收益不如字体裁剪和日志裁剪直接，且对 RTC/BLE/EAF/音频稳定性风险更高。
+
+---
+
+## 七、资源瓶颈速查
+
+| 资源 | 物理 | 已用 | 余量 | 瓶颈等级 |
+|---|---|---|---|---|
+| Flash app | 7 MB | 5.75 MB | 1.25 MB | 🟠 偏紧（82%）|
+| Flash SPIFFS | 8.94 MB | 4.40 MB | 4.54 MB | 🟢 充足 |
+| Internal SRAM | 341 KB | 167 KB | 167 KB | 🟡 中等（50%，最稀缺）|
+| PSRAM | 8 MB | ~1-2 MB | ~6 MB | 🟢 最富余 |
+
+**核心认知**：
+1. **Internal SRAM 是最稀缺资源**，任何 DRAM 优化（BLE/WiFi/栈）都最有价值
+2. **Flash app 分区偏紧（82%）**，字体裁剪是最快的减压手段
+3. **PSRAM 极富余**，适合作为运行时缓存空间（jitter buffer / EAF cache / 解码 buffer），但 PSRAM XIP 不应作为当前 Flash 减压主方案
+4. **SPIFFS 充足**，是 UI 图片外移、未来扩展资源的容纳空间