引用:

原帖由 iffox 于 2025-4-24 11:57 发表
posted by wap, platform: Android
厉害！安卓版天马一直存在这个缓存机制的问题，大家都知道，但是不会改，作者也一直没搞定这个。你能不能解决一下？有兴趣的话是否可以加到大光圈的群里面一起出力搞搞？大光圈整合 ...

个人愚见还是直接转换咱们已有的gamelist比较方便，多弄几套模板，以后市面上出现了更好的前端框架也能快速适配，毕竟游戏资源是相同的。真的和一个断更了两年多的开源项目没啥必要。毕竟现在daijisho和es速度都快很多，对安卓的适配也更加稳定高效，就是界面没有天马炫酷。用脚本转换了现有的list配置，什么前端都可以搭配，这样我感觉比较方便。后续要是有其他转换gamelist的点子\改动，我可以继续跟贴在后边。大家随便用随便改。

TLDR odin2 真神器也
我自己用的odin2原版，经常碰到ra核心延迟偏高的问题。我这边还能分享一下我查阅了相关ra英文文档然后用gpt4.5总结的ra runahead配置降低延迟的分析+配置：
首先是成因：
1. Android 图形系统本身就有延迟
   安卓 UI 管线：App → BufferQueue → SurfaceFlinger → 显示器 vsync
   每帧约 16~33ms 延迟是常态
   安卓没有像 PC 那样直写帧缓存，即使你用 Vulkan/OpenGL，也会被系统处理 pipeline 拉慢
2. Input（触控/手柄）事件本身延迟
   安卓输入要经过 Java 层事件分发，平均有 10ms 起步延迟
   如果用蓝牙手柄，还额外有 7~30ms 的传输延迟（看手柄协议）
   如果你是触控或蓝牙模拟器键盘，那延迟可能高达 60ms+
3. RetroArch 在安卓上是 EGL 图形封装
   它的 GUI 是独立线程，图像输出要等安卓系统提交帧缓冲
   所以帧数再高，帧响应也可能“卡在图形队列中”
4. 没有 Run-Ahead 会累积所有系统延迟
   Run-Ahead 本质上是提前模拟一帧、把模拟逻辑提前执行，从而抵消输入延迟
   没有它时，输入 → 渲染 → 输出 → 感知 = 70~150ms 是普遍区间
对比：
设备 / 系统                         | RetroArch 平均延迟（无 Run-Ahead）
PC（Vulkan + 本地手柄） | 30~50ms
安卓（原生）                     | 80~130ms
安卓 + 蓝牙手柄                | 100~160ms
安卓 + Run-Ahead            | 20~60ms（可逼近 PC）
实机（SFC / FC）              | < 20ms（硬件直通）
解决办法：
1. 启用 Run-Ahead 设置
   Settings > Latency > Run-Ahead Frames 设置为 1 或 2
   打开 Use Second Instance（防止音频抖动）
   有些核心支持特别好（如 NES 的 mesen、SFC 的 snes9x2010）
2. 使用 Vulkan 或 OpenGL 驱动（而非默认的 GLES）
   在 Video > Output 里选 Vulkan，尽可能减少 GPU 提交延迟
3. 关闭帧同步选项
   如 Hard GPU Sync、VSync 尽量关闭（不适合安卓）
4. 用 60Hz 固定刷新率显示设备
   避免在 90Hz / 120Hz 的设备上不匹配核心刷新率（会拖慢帧 pacing）
5. 避免ra设置界面内的动画 UI 与高分辨率 Overlays
   核心内的 HUD、背景动画等都可能拖慢整体帧响应
ps Run-Ahead 负载简述
Run-Ahead = N，会在每一帧 额外运行 N 帧模拟器逻辑（不含渲染）：
相当于 CPU 每帧多做 N × Emulation Step
比如原始帧率是 60fps，开启 Run-Ahead=2，相当于模拟器运行 180fps（其中渲染只渲染 60fps）
如果核心对 CPU 要求高，那么会叠加出明显瓶颈
基于odin2的8gen2 实际测试+gpt 有以下的建议
核心 | 类型 | Run-Ahead 2 帧表现（在 S8 Gen2） | 建议帧数
fbneo / fba2012 | 街机（快） | ✅ 极流畅（<20% CPU 占用） | 2~3
snes9x / snes9x2010 | SFC | ✅ 流畅 | 2
nestopia / mesen | NES | ✅ 流畅（mesen 甚至可 3） | 2~3
Genesis Plus GX | MD | ✅ 正常 | 2
mGBA / gambatte | GBA/GB | ✅ 流畅 | 2~4
PCSX ReARMed (low-res) | PS1（轻） | ✅ 勉强流畅 | 1~2
Beetle PSX HW / DuckStation | PS1（高精度） | ⚠️ 可运行，但稍吃 CPU | 1 建议
Flycast / Reicast | Dreamcast | ⚠️ 卡顿概率高 | 建议关闭
Beetle Saturn / Mednafen Saturn | Saturn | ❌ 极吃性能，慎用 Run-Ahead | 建议关闭

[ 本帖最后由 gggbdm 于 2025-4-24 15:04 编辑 ]

刚好下午得空，我还针对runahead，做了一个odin2 root执行脚本，给ra提权到root，可以增强大部分核心效率，原理和分析我放在底下。
也欢迎大家测试反馈
激进一点的功能我没有测试，暂时注释了。这里只是提供一些思路和个人见解。
ra_boost.sh

复制内容到剪贴板

代码:

使用方式（在 Odin2 上）
1. 把上面的脚本保存为 ra_boost.sh
2. 放到存储：某个文件夹/ra_boost.sh
3。打开 Odin 设置 > Root 权限脚本（或类似名称）
效果：
1. RetroArch 打开瞬间 CPU 频率全核拉满（可配合 CPU Info App 验证）
2. 高精度核心帧数更稳，开启 Run-Ahead 更不容易破音
3. Android 主线程卡顿明显减轻（低延迟提交有效）
分析：
Root 后 RetroArch 能做什么？
1. 解除 I/O 与 CPU 调度器限制
  可通过 root 调整 RetroArch 的运行优先级（nice, sched_set）
  可启用 CPU 频率保持在 Performance 模式（或禁用 powersave）
  可通过修改 /sys/devices/ 中的 调度器参数，避免频繁上下文切换
  &#128204; 结果：核心帧模拟更稳定，尤其是高精度如 Beetle PSX、DuckStation、Saturn 核心能更稳定 60fps
2. 绕过 Android 的图形渲染限制
  Android 使用 SurfaceFlinger 管理图形渲染，是强制 vsync 的合成器（通常有延迟）
  如果你 root + 解锁 bootloader，可以刷入 Magisk 模块或 kernel mod：
    替代 SurfaceFlinger（或开启 DRM直通）
    启用 low-latency graphics 模式
    使用 GameDriver 强制使用本地 Vulkan 实现或 bypass egl/jank（某些 kernel 支持）
  &#128204; 结果：图形帧提交不再等待 UI 线程，降低 1 帧以上延迟（~16ms）
3. RetroArch 运行在 SELinux relaxed / permissive 模式下
  某些核心（如 Beetle 系列）需要更多文件访问权限或内存映射权限（BIOS读写、CHD缓存等）
  默认 Android 限制这些行为，导致性能不稳定
  &#128204; 结果：运行环境更加接近 Linux 桌面，可提升兼容性和加载效率

❌ 但也有几点限制和误区：
Root 后 RetroArch 自动帧数更高？        ❌ 不一定，要配合正确的内核调度策略和图形优化
Root 能降低蓝牙手柄延迟？                ❌ 不能直接降低蓝牙协议延迟（需用 USB 有线手柄）
刷 Kernel 就一定更快？              ❌ 不对，取决于你刷的内核是否对模拟器场景优化
Run-Ahead 更容易开启？                ✅ 是的，可用 root 配置更 aggressive 的同步策略

[ 本帖最后由 gggbdm 于 2025-4-24 15:31 编辑 ]