# STEP-119 RCRR 多场景局限性阶段验收报告 v1

日期：2026-10-11 JST

## 一、目标与结论

**结论：部分可行／阶段 PARTIAL。** Android 真机已证明一个原始四段 RCRR 场景能让后两段 R 分别 Build=1、Reuse=536；但最前 R 缺失 `tide`，同时宽 C 不满足当前 Fast 场景约束，整帧持续 Full。已新增三种区分 C 宽度及错误动态 R 的 Test App 对照入口，并据设备真实 Style 63 层清单完成静态区间核对。新增入口仍需用户手工编译 APK 后实测，不能宣称三种 GPU 场景 PASS；STEP-119 不 CLOSED。

## 二、实际基线和执行链

- RDC 设备：Mac.lan；Mac 仓库 `/Users/tei/dev/MapLibreParticleLab`，当前分支 `particle/main`，本轮起点 HEAD `46c88b0209474376225b54ae0ad701881673743d`。
- Integration `main` 已通过 RDC `git fetch` + `git merge --ff-only`，本地/远端一致 `80667d6c343411d03a760425438e3d292f452118`；已读取 `PARTICLE_PROJECT_INSTRUCTIONS.md`、README、WORKFLOW、TEAM_MODEL、contracts/rfc/adr/status/compatibility、项目 AGENTS/规范/总则。
- APK 源码锁：`3d989a00a822989339a6d7cb4d23acc04396670e`，SHA-256：`57d68800770d431a2ce9247406f636e7a01cc19fccaf4c59f5eb3a7c99128135`，ADB：`192.168.200.139:5555`。此次没有重复 Android 编译/安装。源 HEAD 与已安装 APK 的差异由先前文档提交构成；新测试源码改动后，后续新场景须重新进行用户手工 APK 构建、SHA 锁定。
- 既有 `STATIC_RC_NO_TIDE` 正向 FastDelta=1819、FullDelta=0、Build=1、Reuse=3276 和原 `STATIC_RC` 63 层缺源负向 Fast=0/Full=305，均为已验收历史证据，没有重复执行。

## 三、已执行真机 RCRR 和证据

`PARTIAL_RCRR` 原场景运行 80.007 秒、PID=28169，3 个完整 Native 摘要，设备 SHA 一致。Native 总数 66；R[0,3) / C[3,39) / R[39,64) / R[64,66)。

| 指标 | 实际结果 |
|---|---|
| R0 | Build=0 / Reuse=0 / missingSourceIds=[tide] |
| R2 | Build=1 / Reuse=536 |
| R3 | Build=1 / Reuse=536 |
| 80 秒增量 | Fast=0 / Full=596 |
| 最近 120 帧 | Fast=0 / Full=119 |
| decisionMismatch | 0 |
| 24 Gate 累计 | unsupported-continuous-layer=599、unsupported-scene=599、cache-invalid=595 |

执行进程退出码 0，表示**原生观测及取证成功**，不表示 RCRR Fast 成功。证据路径：
`artifacts/maplibre-particle/android-validation/step119-rcrr-observe-20261011_172720/partial_rcrr/result.json`、`logcat.txt`、`screen.png`。

### 关键事实校正

从设备 Debug App 的 `step113-STATIC_RC-324220201.json` 只读提取 `styleParity.baseLayerManifest`，正式 63 层索引：`tide-spots=2`、`sea-area-fill=3`、`clip-outline=31`、`special-pattern-line-754=37`。其生产 Style 指纹与当日 Fast 成功场景一致。原 R0 只有 background / base-raster / tide-spots；**天气在 C 内而不是 R0**。原 C 范围很宽，混合了普通海图图层和天气动态层。此前对 R0 图层组成的初步猜测已经被真实 Manifest 修正，未写入最终推荐结论。

## 四、新增三种 RCRR Test App 入口（未上机）

- `RCRR_C_NARROW_NO_TIDE`：R[0,31) / C[31,33) / R[33,63) / R[63,64)，C 只包含两天气层。用于验证全段缓存和最终 Fast 的可能性。
- `RCRR_C_WIDE_NO_TIDE`：R[0,2) / C[2,38) / R[38,63) / R[63,64)，C 混合天气与静态 PBF。用于验证白名单边界和宽 C 的实际代价。
- `RCRR_R_DYNAMIC_NO_TIDE`：R[0,33) / C[33,38) / R[38,63) / R[63,64)，天气被放入错误 R。用于验证失效与 Full 安全拒绝。

代码变更严格局限于 Test App `Step113PbfGateScene.kt`、`verify_step113_fast_path.py` 和新增 `test_step119_rcrr_scenarios.py`，保留原所有场景。生产 PBF63 的定义、服务器 URL、天气实际字段及图层相对顺序不变；只在明确 NO_TIDE 测试副本排除已确认的唯一孤立层。对新场景增加精确 R 范围匹配，不降低原验证器 24 Gate 或 FAST_OBSERVED 条件。

源级校验：设备实际 Manifest 分段结构 3/3 与预期一致；Python unittest 4/4 PASS；`git diff --check` PASS。没有 Android Kotlin/NDK 编译或新 APK/设备验收，**三种新增场景为 SOURCE_READY / NOT VERIFIED**。

## 五、当前 RCRR 模式的局限性

1. **全帧 Fast 是全局准入。** R2/R3 的 Cache 能各自 Build/Reuse，但 R0 缺源时整帧仍 Full；不能按各 R Reuse 求和冒充 Fast。
2. **连续 C 不是任意图层的免责通道。** 原宽 C 下 `unsupported-continuous-layer` 持续增加，说明当前 Fast 路径不支持直接把大量普通海图层划入 C 并期望跳过完整场景处理。需要以新窄 C 实测来确认适用边界。
3. **配置高度依赖真实 Style 顺序。** 同一个 layerId 相对位置设错可能造成循环 C 混入静态层或天气落入 R；实际 PBF 63 层与 NavSea 113 层现场定义不同，不能按历史索引照搬。
4. **缓存分段独立性有限。** 即使 R 分段有缓存，Source/Style/Tile/Symbol Placement/Atlas/Opacity/Annotation 的全局结果版本可能要求跨段失效；当前 13 项源级 C++ 测试尚未真正 GTest 运行，相关安全边界待进一步真机验证。
5. **性能与显存不是必然收益。** 多个 R RenderTarget/Composite 会增大缓存资源与混合成本；当前没有同场景 RC/RCRR 同相机有效帧时间和 GPU 内存对照，不能声称多段比单 R 更快。
6. **视觉与平台仍未关闭。** 尚无强制 Full/RCRR 同 Style 静态航标、Symbol、文字、层序的人工确认；Metal CMake 仍因既有 libuv 缺失未配置成功，13 GTest 与 iOS 真机没有新验证。

## 六、风险与下一步

建议以**窄 C、其余静态 R**作为 RCRR 正向候选，保留原 63 层 RCRR 和两个新负向变体。下一次由用户按既有 Mac 标准手工只进行一轮最新源码 APK 构建后，RDC 串行执行三场景各 90 秒真实诊断和同视角视觉对照；若窄 C 仍被 unsupported gate 拒绝，应保留 Full、检查准确原因和局限边界，而不是修改 Gate 放行。

状态为 `ANDROID_RCRR_FAIL_CLOSED_OBSERVED / MULTI_RCRR_SOURCE_READY / OVERALL_PARTIAL`。更详细命令、矩阵和预期证据位于 `docs/60_测试/STEP-119_RCRR多配置验收矩阵_v1.md`。本次不是 GSRL 正式发行，没有 SOURCE_LOCK、发布 Tag 或版本覆盖；未跟踪 STEP-110/111 文档禁止纳入提交。

## 七、Git 收尾

本段由 RDC 在完成 scoped commit/push 与远端回读后补写最终提交、Push 与远端 HEAD；在此之前不得声称 Git 收尾通过。