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 模式的局限性

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

6.4 KiB Raw Blame History Unescape Escape