STEP-119 RCRR 粒子独占 C 与 CPU 效率测试矩阵 v2

日期：2026-10-11 JST。状态：TEST SOURCE PREPARED / ANDROID NOT RUN / STEP-119 PARTIAL。本 v2 取代 v1 对“窄 C 包含 WeatherColor+Particle”的测试建议；v1 保留为历史证据，不改写当时实机事实。

一、目标与核心原则

原则：一个 Continuous 段只放 RasterParticleLayer。WeatherColorLayer 不是逐帧运动图层，正常预测/颜色不变化期间可作为 R 候选，但数据提交、forecast time、色阶、Opacity、Style、Camera、Source/Tile/Atlas 等发生实际结果变化时必须安全撤销旧缓存并 Full，再重 Build/Reuse。这些具体动态失效条件仍需真机证明，不能因为分段配置正确而提前视为 PASS。

Native 当前代码以 singleContinuousSegment(plan) 选择唯一 C；快路只在这个 C 范围执行 tweaker/upload/postRender，全部 R 需具备有效缓存、Revision 与 Symbol 结果证书；现有 24 Gate 不能放宽。因而“一个 C + 多个 R”符合技术实现边界，但不是任意 R 划分都必然适合 Fast。

二、可比 Style 与真实图层顺序

正式原 PBF Style 63 层、测试副本只排除无源 tide-spots，其余 62 层定义和次序完全保留，WeatherColor / Particle 按原插入点顺序位于 clip-outline 之后，Native 预计总 64 层。基于设备导出与原正向成功相同指纹的 Style Manifest：

R 下部 [0,32)：含基础海图 [0,31)，并在索引31绘制 rn-weather-color；WeatherColor 留在 R 中。
Particle C 唯一图层 [32,33)：rn-weather-particles。
上部 R [33,64)：各类静态海图、Symbol 和文字。按测试目的拆成 1/2/3 个 R 片段，不改实际图层顺序。

不要在 NavSea 产品中按本测试索引硬编码；生产实际 Style 上应按图层 ID 验证真实边界。

三、新一轮候选与负对照

场景	预期分段	目的
`RCRR_FULL_CONTROL_NO_TIDE`	R[0,32) C[32,33) R[33,63) R[63,64)	与主 RCRR 相同 Style/Plan/Field，但关闭 Retained 缓存，取得 Full CPU 基线
`RCRR_C_NARROW_NO_TIDE`	R[0,32) C[32,33) R[33,63) R[63,64)	主 RCRR 正向，仅粒子进入 C；3 个 R
`RCR_PARTICLE_ONLY_NO_TIDE`	R[0,32) C[32,33) R[33,64)	仅 2 个 R，测缓存片段数量收益/开销
`RCRRR_PARTICLE_ONLY_NO_TIDE`	R[0,32) C[32,33) R[33,38) R[38,63) R[63,64)	4 个 R，测额外 RenderTarget/Composite/缓存生命周期成本
`RCRR_C_WIDE_NO_TIDE`	R[0,2) C[2,38) R[38,63) R[63,64)	历史宽 C 错误配置，继续作为负对照，不作为性能候选
`RCRR_R_DYNAMIC_NO_TIDE`	R[0,33) C[33,38) R[38,63) R[63,64)	Particle 在 R 内的错误配置，必须 Fail-Closed
原 `PARTIAL_RCRR`	R[0,3) C[3,39) R[39,64) R[64,66)	已经实测：R0 缺 tide、R2/R3 各 Build1/Reuse536、FastDelta0/FullDelta596、decisionMismatch0

旧正向 STATIC_RC_NO_TIDE 用于证明原有 FastPath（FastDelta1819），但天气层位置与粒子独占 C 的四个 A/B 场景不相同，不能直接拿其 CPU 数据得出 RCRR 快慢结论。

四、CPU 指标及可比性

使用 Android /proc/<PID>/stat 同一进程的 utime+stime（含 App 主线程与原生工作线程），以设备实际 getconf CLK_TCK 转换为 CPU 秒。记录该进程在观察期内消耗的累计 CPU 核秒。设备实测此接口可访问且 CLK_TCK=100，此预检不是新 APK 实测。

每场景冷启动不同 PID，固定设备、x86_64 OpenGL APK、Style URL/PBF fingerprint、中心/zoom/rotation、1920×1200 设备条件、Weather 数据、forecast pause、1024 粒子和目标 FPS30。先 Warmup35 秒（等待载入/Placement/Cache settle），再观察至少 90 秒；每 6 秒读取一次 CPU 累计值，场景 Native summary 同样按 6 秒采样，最多允许 CPU/Native 边界时间差 9 秒，否则记测量不完整。

同时必须记录：

CPU 核秒/秒 = Δ(utime+stime)/CLK_TCK/观察秒数；乘100为相对单核的进程 CPU%，多线程时可超过100%。
Native FPS = (ΔFast+ΔFull)/Native摘要实际区间秒数。
估算 CPU ms/完成帧 = (CPU核秒/秒) × 1000 / Native FPS；这是进程级近似值，不是 C++ 单次 render 函数的精确 CPU 耗时。
FastFraction、Full/Fast 增量、R Build/Reuse/Invalidate、24 Gate mismatch、源指纹、生命周期、帧率、帧率波动及进程 PID。
Full→Fast→Full（A-B-A）控制热机/网络缓存时序偏差；Full 前后的 CPU 核秒/秒漂移超过15%则需要复测，不凭一次高速帧数下性能结论。
如果 Fast FPS 比 Full 高而 CPU/秒也提高，必须同时呈报“每帧成本下降”和“整机持续负载未必下降”。CPUms/frame改善不等于省电或 GPU time 已改善。

五、顺序执行（用户手工编译一次，其余通过 RDC）

必须先将本轮 Test App 修正提交/Push，由用户手工使用当前 HEAD 进行 Android APK 构建/安装；禁止用旧 3d989a... APK 冒充新场景。完成后 RDC 检查 build-info commit、SHA-256、设备 base.apk SHA 和目标 ABI。

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

# 每条命令执行完读取状态/result.json，再进入下一条；A-B-A:
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_FULL_CONTROL_NO_TIDE --seconds 90 --warmup 35
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_C_NARROW_NO_TIDE --seconds 90 --warmup 35
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRR_FULL_CONTROL_NO_TIDE --seconds 90 --warmup 35
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCR_PARTICLE_ONLY_NO_TIDE --seconds 90 --warmup 35
python3 -B tools/particle_android_validation/benchmark_step119_cpu.py --scenario RCRRR_PARTICLE_ONLY_NO_TIDE --seconds 90 --warmup 35

每次自动写入 Git 忽略目录： artifacts/maplibre-particle/android-validation/step119-rcrr-cpu/<时间>-<场景>/result.json；同目录保存日志和启动记录。脚本全程真实读取现有 Native 摘要，不改 Gate、不执行 Gradle。验证器 Fast 场景须稳定 Fast 比例≥95%，Full 对照须 FastDelta=0、FullDelta>0。未满足时标记 MIXED_OR_NO_FAST 或 NO_EXPECTED_FRAMES，不把回退帧混入 Fast 成本声称速度提升。

在取得相应结果路径后使用：

python3 -B tools/particle_android_validation/compare_step119_cpu.py \
  --full-before '<第1次Full/result.json>' \
  --fast '<RCRR正向/result.json>' \
  --full-after '<第2次Full/result.json>' \
  --rcr '<RCR/result.json>' \
  --rcrrr '<RCRRR/result.json>'

结果自动核验同 SHA/设备/Style 指纹、Native窗口、失配、Full控制与顺序漂移，输出 CPU per frame 节省比例、CPU 核秒/秒和 FPS 对照。若主 RCRR 尚不能稳定 Fast，不执行“有性能提升”的结论，只报告准确的 Gate 和成本。

六、其他 STEP-119 待验

相同视角的 Full/Fast 截图与 Symbol/文字/航标图层层序人工对比；Camera pan/zoom/rotate、Source/Style/Tile/Annotation/context/forecast 变更导致的证书失效和 Full → Build → Reuse 恢复；13 项新增 C++ GTest 真实运行和 macOS Metal/iOS 独立验证，均保持 NOT VERIFIED。Mac 现存 libuv CMake 配置缺口不授权升级第三方系统工具。全任务 STEP119 仍是 PARTIAL，本批仅准备测试能力，没有 Android 编译或新数据。

七、保护

不改变 Shared Core 公开 API、24 Gate、Renderer 行为、正式远端 PBF Style、发行 Tag/SOURCE_LOCK。
原 STATIC_RC 63 层与历史 RCRR/负对照保留。
不清理两份 STEP110/111 未跟踪文档。
本阶段只把 Test App/CPU 工具/中文报告/Step/开发记录按 Git 任务范围提交到已有 particle/main，Push后回读远端 HEAD。

8.1 KiB Raw Permalink Blame History Unescape Escape