真实游戏实测

本页记录 RenMori 1.2.0 在一款真实 GalGame 发行版构建上的实测结果：以同一份构建的原版与 RenMori 完整保护版为对照，在同一台设备上测量顺序读取吞吐、随机读取延迟与冷启动延迟；受保护版通过原生 launcher 启动，与玩家实际运行的方式一致。

与性能基准使用的合成资源不同，本页的样本是一款真实作品的发行版构建，资源规模约 3.5 GB，包含 CG、立绘、UI 素材、BGM、语音与视频；本页不公开该作品的名称。

结论摘要

对玩家而言，加密几乎无感。

随机读取的额外延迟最大约 0.15 ms，不足 60 FPS 下单帧时间（16.7 ms）的 1%
冷缓存下全部资源的顺序读取吞吐为 584 MB/s，是实时音视频解码所需带宽的百倍以上
平均大小约 1.9 MB 的单张图像，冷缓存下读取耗时增加约 1.8 ms，且 Ren'Py 通常在后台预加载图像
冷启动至首帧的耗时由 7.16 s 增加到 8.44 s，额外的 1.3 s 只在启动时发生一次，进入游戏后不再出现
受保护版 game/ 目录体积仅增加 0.09%，其中包含三个平台的原生运行时

测试环境

项目	取值
测试日期	2026-10-31
设备	Apple M1，8 GB 内存，内置 SSD
操作系统	macOS 26.5.1（arm64）
Ren'Py	8.5.2.26010301
RenMori	1.2.0，完整保护（poly），启用 lockdown，通过原生 launcher 启动

测试样本

原版为作品的发行版构建，game/ 目录共 3.51 GiB，资源存放于一个 2.05 GiB 的 RPA 封包与两个独立的视频文件中；受保护版由同一份构建经 renmori protect 生成，全部资源位于加密容器 renmori.rmc 中。

测试只比较两个构建中均存在且大小一致的条目，共 1407 个，合计 3593 MB；22 个已编译脚本（.rpyc 与 .rpymc）在受保护版中经过脚本层变换，大小与原版不同，不计入读取测试。

类别	文件数	合计
图像	774	1477 MB
音频	599	540 MB
视频	2	1497 MB
脚本	21	0.3 MB
其他	11	79 MB
合计	1407	3593 MB

本页中的 MB 均指 2²⁰ 字节。

测试方法

全部测量均在引擎进程内进行，并通过引擎自身的资源加载路径 renpy.loader.load 读取，因此受保护版的数据包含解密、认证与容器索引查找的全部开销；两个构建均直接运行 .app 中的可执行文件，受保护版因此经过 launcher 的启动流程。

冷缓存与热缓存

每次冷缓存测量前，先以 APFS 克隆（cp -c）复制一份全新的构建；克隆与原文件共享磁盘数据，但在操作系统看来是新的文件，页缓存中不存在其任何内容，因此首次读取必然访问磁盘。预先验证显示，克隆后首轮随机 4 KB 读取的中位延迟为 104 µs，第二轮为 1.4 µs，证实首轮确为冷缓存。

热缓存测量在同一份克隆上重复读取，此时数据已位于页缓存中，结果只反映 CPU 开销。

测量项目

项目	方法
顺序读取	以 1 MB 为单位完整读取全部 1407 个条目；第 1 轮为冷缓存，第 2 至 4 轮为热缓存，取中位数；共进行 3 次，每次使用全新克隆
随机 4 KB / 64 KB	在最大的 64 个文件（均不小于 4 MB，合计 2214 MB）中随机选择文件与偏移，seek 后读取 4 KB 或 64 KB，各采样 2000 次
随机打开小文件	在 822 个不大于 256 KB 的文件中随机选择，打开并完整读取，采样 1000 次
冷启动	从运行可执行文件开始，到引擎绘制第一帧为止；冷启动每次使用全新克隆，共 5 次；热启动在同一份克隆上预热 1 次后测量 5 次

随机读取的冷、热两轮使用相同的随机序列，3 次测量的全部样本合并后计算中位数与 p95。

结果

顺序读取

单位为 MB/s，数值越大越好。

类别	原版（冷）	受保护版（冷）	原版（热）	受保护版（热）
图像	1154	555	1302	480
音频	1132	430	1022	480
视频	1895	658	2281	557
脚本	118	85	96	75
其他	1644	568	1621	458
全部	1303	584	1547	419

受保护版的冷缓存吞吐约为原版的 45%，热缓存约为 27%；热缓存下已不存在磁盘等待，受保护版约 420 至 560 MB/s 的吞吐即为当前解密的上限。

按冷缓存吞吐换算，读取一张平均大小的图像（约 1.9 MB），原版约需 1.6 ms，受保护版约需 3.4 ms；视频与 BGM 由引擎流式读取，其码率通常仅为每秒数 MB，与 584 MB/s 相差两个数量级以上。

随机读取

单位为 ms，数值越小越好。

测试	缓存	原版中位数	受保护版中位数	原版 p95	受保护版 p95
随机 4 KB	冷	0.216	0.181	0.443	0.399
随机 4 KB	热	0.200	0.187	0.479	0.456
随机 64 KB	冷	0.252	0.403	0.452	0.760
随机 64 KB	热	0.249	0.348	0.397	0.699
随机打开小文件	冷	0.196	0.265	0.937	0.988
随机打开小文件	热	0.100	0.143	0.438	0.675

随机 4 KB 读取两者相当，差异在测量误差范围内；随机 64 KB 读取的中位数增加 0.10 至 0.15 ms，原因是一次 64 KB 读取通常跨越两个分块，需要解密并认证两个分块；随机打开小文件的中位数增加 0.04 至 0.07 ms，来自容器索引查找与逐文件密钥派生。

冷启动

单位为 s，从运行可执行文件开始计时，取中位数，括号内为最小值与最大值。

阶段	缓存	原版	受保护版	差值
资源索引就绪	冷	3.13（2.46–3.82）	3.18（2.80–3.74）	+0.05
绘制首帧	冷	7.16（6.01–7.70）	8.44（7.99–9.04）	+1.28
资源索引就绪	热	0.97（0.72–1.07）	0.76（0.65–1.33）	−0.21
绘制首帧	热	5.05（3.82–6.50）	5.83（4.61–6.54）	+0.78

launcher 的启动流程与容器索引的建立几乎不增加耗时，冷缓存下资源索引就绪的时间仅相差 0.05 s；热启动各次之间波动较大，两者的差异以冷启动数据为准。

额外的耗时集中在脚本加载阶段：为避免在磁盘上留下明文，受保护版不写入 Ren'Py 的字节码、界面分析等运行时缓存，每次启动都需重新编译脚本中的 Python 代码；单次运行的 Ren'Py 日志中，「Loading script」阶段原版为 169 ms，受保护版为 1967 ms。

体积开销

构建	`game/` 体积
原版	3,768,321,012 字节
受保护版	3,771,724,069 字节
差值	+0.09%

受保护版的体积包含加密容器、运行时加载器与 Windows、Linux、macOS 三个平台的原生运行时；仅加密容器相对原版资源的开销为 0.08%。

结果解读

玩家能够感知的性能问题主要是卡顿与等待：卡顿取决于单次读取能否在一帧之内完成，等待取决于大块资源能否及时就绪。随机读取最多增加约 0.15 ms，不足单帧时间的 1%；顺序吞吐即使在冷缓存下也远高于音视频流式播放所需的带宽；游玩过程中加密不会引入可察觉的卡顿或等待。

唯一可以察觉的差异是启动时多出的约 1 s，它来自不写明文缓存的安全取舍，只在启动时发生一次。

局限

未测量实际游玩中的帧时间，本页数据只覆盖资源读取，不包括图像解码、音频解码与渲染
仅在一台 Apple M1 设备上测试，Windows、Linux 与 Steam Deck 上的数据尚未测量
测试设备使用内置 SSD，机械硬盘上冷缓存读取受磁盘限制更明显，受保护版与原版之间的相对差距通常会缩小
热启动数据波动较大，仅供参考
样本作品与测量代码不公开，本页数据无法由第三方直接复现；可复现的合成基准见性能基准

#真实游戏实测

#结论摘要

#测试环境

#测试样本

#测试方法

#冷缓存与热缓存

#测量项目

#结果

#顺序读取

#随机读取

#冷启动

#体积开销

#结果解读

#局限