Eden on Time Friend

骁龙 8 Gen 2 掌机跑 Switch 模拟器: 内存布局越大越不稳, 以及显存优化实测

Thu, 24 Sep 2026 14:00:00 +0000

我的 AYN Thor 掌机用的是骁龙 8 Gen 2, 平时靠 Eden 玩 Switch。有一段时间《王国之泪》总是"退后台"或者干脆闪退, 稳定版和 nightly 两个构建都一样。我第一反应是内存不够——掌机有 15GB 内存, 那 Eden 的内存布局就该往大了给, 于是我把它从默认调到最高的 8GB。结果问题变得更频繁了。

这篇就是从这个反直觉的结果往回查的过程。

退后台和闪退, 是两个独立的问题

一开始我把两个现象当成一件事, 后来看日志才发现根因完全不同。判断办法很简单: 看 Eden 进程还在不在。退后台的时候进程活着, 只是它的 EmulationActivity 被停掉了; 闪退的时候进程直接没了, 留下 tombstone。

flowchart TB
 A["游戏退后台或闪退"] --> B{"Eden 进程还在吗"}
 B -->|"进程在, 被顶到后台"| C["lmkd 内存压力<br/>杀掉 iiSU 桌面<br/>桌面重启抢占前台"]
 B -->|"进程消失"| D["GPU 管线崩溃<br/>着色器缓存与当前驱动不匹配"]
 C --> E["内存布局 8GB → 6GB → 4GB"]
 D --> F["删除驱动专属的着色器缓存<br/>确认加载的是 Turnip"]

分开之后, 每个问题都有了明确的证据链。

Eden 稳定版和 nightly 的存档为什么对不上: 用户档案 ID 与 UID 字节逆序

Sun, 20 Sep 2026 10:00:00 +0000

我把 Eden 的主力版本从稳定版换成了 nightly。它和稳定版包名不同, 可以直接共存, 游戏也都能正常打开。但进去之后, 之前所有的存档一个都读不到, 每个游戏都像第一次玩。我第一反应是 nightly 把数据目录清了, 或者存档被覆盖了, 赶紧去翻文件。

文件都在。少的不是存档, 是 nightly 去错了地方找。

两个构建共用游戏, 但不共用用户档案

Eden 把 Switch 的存档放在数据目录的 nand/user/save/ 下。这条路径不是只有一层, 它的结构大致是 nand/user/save/0000000000000000/<用户档案ID>/<TitleID>/, 中间那层是用户档案。稳定版和 nightly 是两个独立安装的应用, 各自的数据目录分开, 更关键的是: nightly 首次启动时会自己生成一个新的用户档案 ID, 和稳定版那个没有任何关系。

我这边稳定版的活动档案是 D2AE7D815565D5C93F432C7C74A7DD6A, nightly 自动生成的是 173CB8FB1F16348366B4CABB88A445D9。存档文件都在 nightly 的数据目录里(从稳定版拷过来之后), 但 nightly 只会去它自己那个活动档案目录里找游戏存档, 于是看不到。

存档目录名从哪来

那个看起来像随机十六进制串的档案目录名, 其实不是随机的。日志里能观察到, 它来自用户档案的 UID, 并且是 UID 的字节逆序排列——同一段身份数据, 换个字节序就成了目录名。两个构建只要各自生成了新 UID, 目录名就必然不同, 这也是为什么换构建、甚至 nightly 自己重新初始化之后, 存档会"对不上"。理解了这一点, 就不会再把它当成文件损坏。

为什么直接拷存档会失效

最容易踩的坑是: 把稳定版的 save/ 整个拷到 nightly 的 save/, 以为就完事了。结果 nightly 里依然读不到。原因是稳定版拷贝过去的目录名是 D2AE7D..., 而 nightly 的活动档案是 173CB8FB..., 内容进了库, 但没进 nightly 真正会查的那个抽屉。所以迁移必须做两段覆盖: 先把稳定版的存档根整体带过来, 再把稳定版活动档案里的内容, 再拷进 nightly 的活动档案目录。

Eden 模拟器配置每次崩溃就被重置: 从 C++ 源码的非原子写入讲起

Sat, 05 Sep 2026 10:00:00 +0000

Eden 里的设置总是莫名其妙回到默认, 尤其在我把模拟器强杀、或者它自己崩溃之后。图形驱动、内存布局、语言区域, 全部复位。我一开始以为是 Android 什么时候把应用数据清了, 先后重装过两次, 还在手机上给它开了各种后台保活。重装能好一阵, 然后又犯。

真正的原因和 Android 没关系, 在 Eden 自己的源码里。

不是"没保存", 是"保存到一半被截断"

配置存在 files/config/config.ini。Eden 保存设置的写法, 是把整个文件重新写一遍。问题在打开文件的模式上:

void Config::WriteToIni() const {
 fp = fopen(config_loc.c_str(), "wb"); // "wb" 一打开就把文件截断为 0
 // ...
 config->Save(writer, false); // 再逐项写入；若此刻崩溃 → 文件残缺
}
void Config::Reload() {
 ReadValues(); // 读现有配置
 SaveValues(); // 立刻又写回去
}

"wb" 这个模式在 POSIX 里的语义是: 打开即把文件截断成 0 字节, 然后从零开始写。也就是说, 从打开到写完的这段时间里, 磁盘上的 config.ini 处于"已经被清空、还没写回来"的状态。如果在这段窗口里进程被强杀或崩溃, 留下的就是一个残缺或空白的文件。下一次启动去解析它, 解析失败, Eden 就回退到内置默认值——看到的现象就是"配置被重置"。

这还没完。Reload() 每次启动都会先读、再立刻写回去。也就是说每次启动都有一个这样的写入窗口, 崩溃并不需要多罕见。写配置本身不是原子的(没有先写临时文件再 rename), 这是根因。