第94章：C++项目实战：游戏引擎（资源管理）

资源管理，说白了就是游戏引擎的“后勤部”。

你想想看，一个3A游戏里有多少东西？模型、贴图、音频、动画、着色器……这些资源如果管理不好，轻则内存爆炸，重则游戏卡成幻灯片。我在做第一个小游戏引擎时，就吃过这个亏——资源加载完忘了释放，结果内存泄漏到系统直接杀进程。

嗯，今天我们就来聊聊，怎么用C++把资源管理这块硬骨头啃下来。

资源管理的核心痛点

为什么资源管理这么重要？我总结了几点：

  • 重复加载：同一个模型被多个场景引用，每次都从硬盘读？太蠢了。
  • 生命周期混乱：资源什么时候加载？什么时候卸载？谁说了算？
  • 跨线程安全：渲染线程在画，加载线程在读，搞不好就崩了。
  • 内存碎片：频繁申请释放，堆上全是洞。

说白了，资源管理就是解决“什么时候加载、什么时候卸载、怎么存、怎么取”这四个问题。

架构设计：资源管理器

我个人习惯把资源管理器设计成一个全局单例。为什么？因为资源是全局共享的，你总不希望每个子系统都自己搞一套缓存吧？

核心思路：资源管理器 = 资源工厂 + 资源缓存 + 生命周期控制器

下面这张图，是我在项目中实际使用的资源管理架构：

资源管理架构图 资源管理器 (Singleton) 资源工厂 创建/加载资源实例 资源缓存 哈希表 + LRU 生命周期控制器 引用计数 + GC 资源存储层 (内存池 / 文件系统) 外部接口：Load<T>() / Unload() / Get<T>()

资源工厂：统一创建入口

资源工厂负责“怎么造资源”。不同类型的资源，创建方式完全不同：

  • 纹理：从图片文件解码，上传到GPU
  • 模型：解析FBX/glTF，生成顶点缓冲
  • 音频：解码MP3/WAV，准备播放

我建议用工厂模式 + 注册表来实现：

class ResourceFactory {
public:
    using CreatorFunc = std::function<Resource*(const std::string& path)>;
    
    void Register(const std::string& type, CreatorFunc creator) {
        creators_[type] = creator;
    }
    
    Resource* Create(const std::string& type, const std::string& path) {
        auto it = creators_.find(type);
        if (it != creators_.end()) {
            return it->second(path);
        }
        // 我曾经在这里踩过坑——忘记注册导致返回nullptr，游戏直接黑屏
        // 后来加了个断言，调试期就能发现问题
        assert(false && "Unknown resource type!");
        return nullptr;
    }
    
private:
    std::unordered_map<std::string, CreatorFunc> creators_;
};

小技巧：注册表可以用宏来简化，比如 REGISTER_RESOURCE_TYPE(Texture, TextureCreator)。但别滥用宏，否则调试起来想哭。

资源缓存：别再重复加载了

缓存是资源管理的核心。你想想看，一个场景里可能有100个物体共用同一张贴图，难道要加载100次？

我常用的缓存结构：

template<typename T>
class ResourceCache {
public:
    std::shared_ptr<T> Get(const std::string& key) {
        std::lock_guard<std::mutex> lock(mutex_);
        
        auto it = cache_.find(key);
        if (it != cache_.end()) {
            // 命中缓存，更新LRU
            lru_.erase(it->second.lru_it);
            lru_.push_front(key);
            it->second.lru_it = lru_.begin();
            return it->second.resource;
        }
        return nullptr;
    }
    
    void Put(const std::string& key, std::shared_ptr<T> resource) {
        std::lock_guard<std::mutex> lock(mutex_);
        
        if (cache_.size() >= max_size_) {
            // 淘汰最久未使用的
            auto old_key = lru_.back();
            lru_.pop_back();
            cache_.erase(old_key);
        }
        
        lru_.push_front(key);
        cache_[key] = {resource, lru_.begin()};
    }
    
private:
    std::unordered_map<std::string, 
        Entry> cache_;
    std::list<std::string> lru_;
    std::mutex mutex_;
    size_t max_size_ = 1024; // 可配置
};

注意：LRU淘汰策略虽然好用，但有个坑——如果玩家突然切换场景，大量新资源涌入，旧资源会被瞬间淘汰。我建议在场景切换时，先主动清理不再需要的资源，而不是等缓存满了再被动淘汰。

生命周期管理：谁生谁死？

资源什么时候该卸载？我见过三种策略：

策略 原理 适用场景
引用计数 没人用了就卸载 大多数情况，简单可靠
定时GC 定期扫描，清理未使用资源 移动端，内存紧张
手动管理 关卡加载/卸载时批量处理 大型开放世界，精细控制

我个人习惯用引用计数 + 智能指针。C++的shared_ptr天然支持引用计数，但要注意循环引用：

class Texture : public std::enable_shared_from_this<Texture> {
    // 资源内部不要持有其他资源的 shared_ptr
    // 如果必须引用，用 weak_ptr
};

class Material {
    std::shared_ptr<Texture> diffuse_;  // 正确：Material 持有 Texture
    // std::shared_ptr<Material> self_; // 错误：循环引用！
};

避坑指南：我曾经在材质系统里，让Material持有了一个指向自己的shared_ptr，结果整个场景退出时资源全泄漏。查了两天才发现是循环引用。从那以后，我规定所有资源类内部只能用weak_ptr引用自己或兄弟资源。

异步加载：别卡主线程

游戏最忌讳什么？卡顿。如果资源加载放在主线程，玩家会看到画面一帧一帧地跳。

我建议的异步加载流程：

  1. 请求加载：返回一个future或回调
  2. 后台线程：从硬盘读取，解码，准备数据
  3. 主线程：将数据提交到GPU（因为OpenGL/DirectX操作必须在主线程）
  4. 完成回调：通知游戏逻辑资源已可用
std::future<std::shared_ptr<Texture>> LoadTextureAsync(const std::string& path) {
    return std::async(std::launch::async, [path]() {
        // 1. 从硬盘读取
        auto raw_data = ReadFile(path);
        // 2. 解码
        auto decoded = DecodeImage(raw_data);
        // 3. 创建纹理对象（但不上传GPU）
        auto tex = std::make_shared<Texture>(decoded);
        return tex;
    });
}

// 在主线程调用：
void MainThreadUpdate() {
    // 检查future是否完成
    // 如果完成，调用 tex->UploadToGPU()
}

小技巧：异步加载时，可以加一个“加载进度”回调。我在项目中用了一个简单的计数器，每完成一个资源就更新UI上的进度条。玩家看到进度在动，心里就不慌。

内存池：告别碎片

资源频繁创建销毁，内存碎片是个大问题。尤其是纹理数据，动辄几MB，分配释放几次堆就乱了。

我推荐用内存池：

  • 预分配一大块连续内存
  • 资源从池中分配，不直接调用new
  • 池内用自由链表管理空闲块
class MemoryPool {
public:
    MemoryPool(size_t block_size, size_t block_count) {
        pool_ = malloc(block_size * block_count);
        // 初始化自由链表
        for (size_t i = 0; i < block_count; ++i) {
            free_list_.push_back(
                static_cast<char*>(pool_) + i * block_size);
        }
    }
    
    void* Allocate() {
        if (free_list_.empty()) return nullptr;
        auto ptr = free_list_.back();
        free_list_.pop_back();
        return ptr;
    }
    
    void Deallocate(void* ptr) {
        free_list_.push_back(static_cast<char*>(ptr));
    }
    
private:
    void* pool_;
    std::vector<void*> free_list_;
};

注意：内存池虽然快，但有个限制——所有块大小必须相同。如果资源大小差异很大，可以考虑分多个池，或者用伙伴分配算法。我在项目中用了三个池：小对象（<64KB）、中对象（64KB~1MB）、大对象（>1MB）。

总结：资源管理的黄金法则

嗯，说了这么多，其实核心就几条：

  • 统一入口：所有资源通过管理器加载，别到处new
  • 缓存为王：相同的资源只加载一次
  • 引用计数：没人用就释放，别舍不得
  • 异步加载：别卡主线程，玩家会骂娘
  • 内存池：减少碎片，提高性能

我记得第一次把资源管理器跑通时，看着游戏里几百个模型流畅加载，心里那个爽啊。但别高兴太早——资源管理是个持续优化的过程，不同游戏、不同平台，策略都得调。你想想看，PC上内存管够，移动端却抠得要死，能一样吗？

好了，这一章就到这里。代码都在上面了，拿去用，有问题咱们群里聊。

公众号：蓝海资料掘金营，微信 deep3321

← 上一章 📖 返回目录 下一章 →