游戏导入CSV数据的最优方案：如何平衡性能与内存占用？

方案1：运行时按需解析CSV #

• 适用场景：
  • 单文件条目数低于1000的小型游戏、快速验证的原型项目
  • 开发调试阶段需要频繁修改CSV、不想每次修改都走预处理流程的场景
  • 支持玩家自定义CSV Mod的游戏
• 潜在问题：
  • CSV原生解析需要做字符串拆分、字段类型转换，CPU开销极高，数据量稍大就会大幅拉长加载时间，甚至触发主线程卡顿
  • 解析过程会产生大量临时字符串，GC压力大，内存占用不稳定
  • 无前置类型校验，CSV格式错误要到运行时才会暴露，排查成本高

方案2：离线预解析生成硬编码代码文件 #

典型生成的代码结构如下：

public class ContentOfSomeCsv {
    private static EntryType[] data;
    public static void LoadData(){
        data = new EntryType[] {
            entry1,
            entry2,
            // ...
            entryn,
        };
    }
}

• 适用场景：
  • 数据量中等（单文件条目数低于10万）、上线后配置改动频率极低的游戏
  • 对加载速度要求极高、不需要动态修改配置的单机游戏
• 潜在问题：
  • 代码文件体积随数据量线性增长，数据量过大会导致项目编译速度大幅变慢，甚至触发编译器内存溢出
  • 每次修改CSV都要重新生成代码、编译项目，迭代效率低
  • 所有数据加载时会全部常驻内存，数据量大会导致内存占用过高

方案3：导入运行时数据库按需加载 #

• 适用场景：
  • 数据量极大（单文件条目数10万以上）、单次业务只会用到少量条目的游戏，比如开放世界的NPC配置、全局掉落表
  • 需要高频热更配置、不能每次更新都让玩家重新下载客户端的运营类游戏
• 潜在问题：
  • 数据库查询本身有固定开销，高频查询不加缓存会导致性能下降
  • 需要额外集成数据库依赖，安装包体积会有1~5M不等的增长
  • 小数据量场景下开销远大于收益，反而会拉高加载耗时和包体积

优先选择离线预解析为二进制序列化文件的方案：

• 离线阶段把CSV转换成FlatBuffers、MessagePack这类低/零反序列化开销的二进制格式，提前做类型校验，从根源避免运行时格式错误
• 运行时直接加载二进制文件反序列化，解析速度比原生CSV快10~100倍，解析过程GC极少，内存占用稳定
• 中等数据量可以全量加载，数据量过大的场景可以给二进制文件加偏移索引，按需读取指定条目，不需要全量加载进内存
• 支持热更，把二进制文件放到热更资源包即可更新配置，不需要修改客户端代码，比硬编码方案灵活，比数据库方案轻量化
• 高频访问的条目可以搭配LRU缓存，进一步平衡性能和内存占用

内容的提问来源于stack exchange，提问作者TinglePan