7.0 KiB
STEP-119 RCRR 多配置实机与验证矩阵 v1
日期：2026-10-11（JST）。执行入口：Mac.lan RDC，Particle particle/main。状态：一组真机完成；三组新配置已实现、静态核对通过但未构建/上机。非最终验收。
1. 场景与边界
本轮沿用 STEP-119 源码 APK（commit 3d989a00a822989339a6d7cb4d23acc04396670e，SHA-256 57d68800770d431a2ce9247406f636e7a01cc19fccaf4c59f5eb3a7c99128135），不重复已通过的 Android 原生完整编译。设备 192.168.200.139:5555，x86_64。当前远端 HEAD 起点为 46c88b0209474376225b54ae0ad701881673743d，其与 APK commit 的后续差异为已有报告/Step 文档，而非新 Android 源码。
不改正式 PBF/Sprite/Glyph、Source 接口、Shared Core、24 Gate、发布版本，不清理 STEP-110/111 两份未跟踪任务书。保留原 PARTIAL_RCRR、原 STATIC_RC 与 STATIC_RC_NO_TIDE，后续新场景只在测试副本中排除唯一 tide-spots→tide 孤立 Symbol 层，并恢复空 Annotation 辅助层的正常生命周期。
2. 已执行：原 PARTIAL_RCRR
- 80.007 秒实机，PID
28169，完整摘要 3 份，同源 APK/设备 SHA 一致。 - 原始 Native 图层 66，原 63 PBF + 2 天气 + 1 SDK Annotation；R[0,3)、C[3,39)、R[39,64)、R[64,66)。
- R0：Build 0、Reuse 0、Fallback 595、missingSourceIds=[tide]；R2：Build 1、Reuse 536；R3：Build 1、Reuse 536。
- 观测区间：FastDelta=0、FullDelta=596，最后 120 帧 Full=119、Fast=0，decisionMismatch=0。
- Native 24 Gate 累计
unsupported-continuous-layer=599、unsupported-scene=599、cache-invalid=595；这些是场景累计，不是对应原因的独立帧数。 - 结论：全帧 Fast 安全拒绝通过；局部 R2/R3 的 Build/Reuse 已实际观察到。这不构成 RCRR 加速性能通过。
原证据：
artifacts/maplibre-particle/android-validation/step119-rcrr-observe-20261011_172720/partial_rcrr/result.json，同目录有 logcat.txt 与 screen.png。
3. 基于真实设备 Style Manifest 校准分段
从设备 run-as 只读提取的 step113-STATIC_RC-324220201.json，包含当前实际 63 层 baseLayerManifest；其 PBF 指纹 e0f9c2d1df38ae5d5953b561c52efe2f8590336de80b988e1d2935580d30b996 与已通过 Fast 的场景一致。
原基础层：background=0、base-raster=1、tide-spots=2、sea-area-fill=3、clip-outline=31、special-pattern-line-754=37、最后的 place-labels-land-ja=62。天气插在 clip-outline 之后。因此原 R0 是前三层（包括 tide），天气并未落入 R0；原 C1 是宽 C，包含天气与普通静态 PBF 层。禁止再用此前错误的“天气在 R0”解释原负例。
新增 Test App 变体（全部保留其余 62 原图层、天气数据与顺序；移除 SDK 空 Annotation 辅助层；Native 总层数预期 64）：
| 场景 | 期望 R/C 索引 | 主要目标 |
|---|---|---|
RCRR_C_NARROW_NO_TIDE |
R[0,31)、C[31,33)、R[33,63)、R[63,64) | C 仅含 WeatherColor/Particle；检验所有 R 缓存与整帧 Fast 能否真实通过 |
RCRR_C_WIDE_NO_TIDE |
R[0,2)、C[2,38)、R[38,63)、R[63,64) | C 混入普通 PBF；验证不支持的连续图层是否安全拒绝整帧 Fast |
RCRR_R_DYNAMIC_NO_TIDE |
R[0,33)、C[33,38)、R[38,63)、R[63,64) | 故意将动态天气放入 R；检验版本/连续输入不允许错误静态复用 |
源级校准证据：
artifacts/maplibre-particle/android-validation/step119_rcrr_style_structure.json。该结果是实际设备导出数据上的静态切分核对，不是新 APK GPU 验证。Mac 通过 Python 直接 GET 正式 Style 曾收到 HTTP 403，因此优先复用了相同 Style 指纹的设备导出 Manifest；没有修改服务器资源。
4. 静态测试与当前缺口
新增 tools/particle_android_validation/test_step119_rcrr_scenarios.py，四项 Python unittest 全部 PASS：三种索引互相排斥、缺 tide/缺 Annotation 清理不得通过、范围尾部和段数不对必须拒绝、原 STATIC_RC_NO_TIDE 不回退为错误结构。验证器 scene_parity_valid 对 64 层 RCRR 三 R 段改用精确区间校验；原 63 层判断、90 秒观察、24 Gate 和 Fast 判据不放宽。git diff --check PASS。
没有对新 Kotlin 场景做 Android 编译/安装（遵守用户手工 Android 编译及本轮不重复已有完整编译限制）。新增三场景的 Kotlin 可编译性与 Native 真机结果必须记 NOT VERIFIED。新增 13 项 STEP-119 GTest 仍未运行；Mac Metal CMake 被既有 libuv 缺失阻塞，本轮不安装或升级工具链；iOS Metal/实体机亦未验证。
5. 下次同一次人工 APK 构建后的串行设备验收
源码 scoped commit/push 完成后，由用户按已有标准在 Mac 手工构建新 HEAD 的 x86_64 Android OpenGL Test APK，不得使用旧 3d989a APK冒充新场景；验证 build-info commit、APK SHA、设备 base.apk SHA 一致后，逐一运行：
cd /Users/tei/dev/MapLibreParticleLab
./tools/particle_android_validation/build_validation_apk.sh
adb -s 192.168.200.139:5555 install -r artifacts/maplibre-particle/android-validation/MapLibreAndroidTestApp-validation-opengl-debug-x86_64.apk
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --preflight-only
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_C_NARROW_NO_TIDE --seconds 90
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_C_WIDE_NO_TIDE --seconds 90
python3 -B tools/particle_android_validation/verify_step113_fast_path.py --serial 192.168.200.139:5555 --scenario RCRR_R_DYNAMIC_NO_TIDE --seconds 90
每步独立读取退出码与 result.json：完整 R/C、Source/Tile、R0/R2/R3 Build/Reuse/Invalidate、Fast/Full 差分、24 Gate、120 帧、生命周期/判定一致性。正向窄 C 必须先 Full 建立证书，再 Build 和成功 Reuse 后 Fast；若失败记录真实 gate，而不是降阈值。宽 C 和动态 R 是安全负例，NO_FAST_OBSERVED/exit2 若符合完整原因和分段预期属于负例通过，而非直接整体失败。禁止直接用这些负例宣称 Fast 不可用。
之后须补：静止视觉 Full/RCRR 同资源同视角人工航标、文字、Symbol、层序对照；Camera/Source/Style/Tile/Annotation/Context/cache toggle 的瞬时失效、Full 回退、重新稳定后的 Build/Reuse；13 GTest 真实执行和 Mac Metal/iOS 独立验证。视觉比对时动态粒子会造成像素差异，不能简单拿整屏逐像素一致作为静态 Symbol 结论。
6. 当前判定
ANDROID_RCRR_FAIL_CLOSED_OBSERVED / NEW_VARIANTS_SOURCE_READY / STEP119_PARTIAL。
主要已确认局限：多 R 缓存复用并不代表全帧 Fast；含缺源 R 会阻断、过宽 C 中非支持类型的连续层触发拒绝；未实测新窄 C 前，不能推断 RCRR 性能收益。待验证风险：多 RenderTarget/Composite 成本、全局 Symbol Placement/Atlas 证书联动、局部更新导致跨 R 全局失效、上层标记/文字的层序与图像等价、iOS/Metal 一致性。