游戏引擎架构：对象与资源管理核心设计与实战优化

1. 从一次内存泄漏事故说起：为什么游戏对象管理值得单独拎出来讲

三年前我接手过一个上线不到两周就频繁闪退的项目。排查了整整三天，最后定位到的原因让人哭笑不得：场景切换时，一批敌人对象被从场景树上摘下来了，但它们的引用还挂在某个全局事件监听器里，GC 根本回收不掉。每切一次场景，内存就涨一截，玩家玩到第五关左右，内存直接爆掉。

这个坑让我彻底意识到一件事：游戏对象与资源管理，是引擎架构里最不起眼、但最容易出人命的模块。渲染管线崩了你能立刻看到黑屏，物理穿模了你能立刻看到角色掉进地板，但对象和资源管理出了问题，它往往潜伏几十分钟才爆发，而且爆发的时候你连凶手是谁都不知道。

这篇内容就是围绕这个模块展开的。我会从整体设计思路讲到具体实现细节，包括对象生命周期怎么管、资源怎么加载和释放、引用计数和垃圾回收怎么选、对象池怎么设计、异步加载怎么做。适合已经有一定引擎使用经验、想往引擎架构方向深入的同学，也适合正在自己写小引擎、被内存问题折磨的独立开发者。读完之后，你至少能做到两件事：第一，看懂主流引擎在对象和资源管理上的设计取舍；第二，在自己的项目里搭出一套不会半夜炸掉的管理系统。

2. 整体设计思路：对象和资源为什么要分开管

2.1 游戏对象和资源本质上是两种东西

很多人刚开始写引擎的时候，会把游戏对象和资源混在一起管理。比如一个角色对象，里面直接塞了模型数据、贴图数据、动画数据。看起来很方便，实际上是个定时炸弹。

游戏对象和资源在生命周期上有本质区别。游戏对象是场景层面的概念，它存在于某一关、某一帧里，关卡结束它就该消失。资源是资产层面的概念，一张贴图可能被十个不同的对象引用，一个模型可能在这个关卡用、下个关卡还用。如果你把两者绑死，就会出现两种情况：要么资源被对象拖着不能释放，要么对象被资源拖着不能销毁。

所以成熟引擎的做法都是对象和资源分离。对象只持有资源的句柄（Handle），不持有资源本体。资源由专门的资源管理器统一加载、缓存、释放。对象销毁的时候，只是把句柄还回去，资源该不该释放由资源管理器根据引用情况决定。

这个设计的好处很直接：同一份资源在内存里只有一份，十个对象引用它也只占一份内存；对象销毁不影响资源，资源释放也不影响还活着的对象。代价是多了一层间接寻址，每次访问资源都要通过句柄查表，但这个开销在现代 CPU 上基本可以忽略。

2.2 句柄设计的三种常见方案

句柄这个东西听起来简单，但设计得好不好直接决定了系统的健壮性。我见过三种主流方案，各有各的适用场景。

第一种是裸指针。最直接，性能最好，但最危险。对象销毁后指针变成野指针，你再用就是未定义行为。新手项目里最常见，也最容易出事。

第二种是索引 + 版本号。句柄里存一个数组索引和一个版本号，资源管理器维护一个槽位数组，每个槽位记录当前版本。访问的时候先查索引，再比对版本号，对不上就说明资源已经释放了。这个方案能有效防止悬空引用，代价是多一次比对。很多自研引擎用这个方案，平衡了安全性和性能。

第三种是智能指针。直接用引用计数，对象销毁时自动释放。写起来最省心，但有两个问题：一是循环引用会导致内存泄漏，二是引用计数的原子操作在多线程下开销不小。适合工具链和编辑器，不太适合运行时核心路径。

我个人的建议是：运行时用索引加版本号，编辑器用智能指针。运行时追求性能和可控性，编辑器追求开发效率。两者分开，各取所需。

2.3 资源加载策略：同步、异步、流式

资源怎么加载进内存，是另一个核心决策点。这里有三条路。

同步加载最简单，调用加载函数，等它返回，资源就在内存里了。适合小资源、启动阶段、或者对加载时间不敏感的场景。缺点是会卡主线程，加载一个大模型可能卡几百毫秒，玩家能明显感觉到顿挫。

异步加载是把加载任务丢到后台线程，主线程继续跑，加载完了再通知主线程。适合大资源、运行时动态加载。缺点是复杂度高，要处理线程安全、加载顺序、回调时机等问题。而且异步加载有个经典陷阱：你请求加载一个资源，回调还没回来，对象已经被销毁了，回调里再去访问对象就是崩溃。解决办法是回调里先检查对象是否还有效，或者用弱引用。

流式加载是异步加载的进阶版，专门针对开放世界。它根据玩家位置动态加载和卸载资源，玩家走到哪加载到哪。这个方案对资源管理器的要求最高，需要处理优先级、预加载、卸载时机等问题。做开放世界的团队基本都绕不开这套东西。

实操心得：异步加载的回调里，永远不要假设请求发起时的对象还活着。我踩过这个坑，请求加载贴图的时候对象还在，回调回来的时候对象已经被销毁了，结果访问空指针直接崩。后来统一改成回调里先查对象有效性，再决定要不要应用资源。

3. 核心细节解析：对象生命周期与资源引用计数

3.1 游戏对象的生命周期管理

一个游戏对象从创建到销毁，大致经历这几个阶段：创建、初始化、激活、更新、停用、销毁。每个阶段都有讲究。

创建阶段只是分配内存，对象还没有任何有效数据。初始化阶段才真正设置对象的属性、挂载组件、绑定资源。这两个阶段分开是有原因的：创建可以批量做，初始化往往需要根据具体配置来，分开之后对象池才能高效工作。

激活和停用是对象池的核心。对象不用的时候不销毁，只是停用，从更新列表里摘出来，资源句柄保留着。下次需要同类对象的时候，直接从池子里拿一个停用的，重新初始化一下就能用。这样避免了频繁的内存分配和释放，对性能提升非常明显。我实测过一个弹幕游戏，用对象池之后子弹的创建开销从每颗 0.02 毫秒降到了 0.003 毫秒，同屏一千颗子弹的情况下，光这一项就省了 17 毫秒每帧。

销毁阶段要特别小心。销毁一个对象的时候，必须确保所有引用它的地方都得到了通知。事件监听器要注销，父子关系要解除，资源句柄要归还。漏掉任何一项，都可能造成悬空引用或者内存泄漏。我的做法是给对象加一个IsValid标志，销毁时先置为 false，所有外部访问前都检查这个标志，这样即使有漏网的引用，也不会直接崩溃，而是安全地跳过。

3.2 引用计数的实现细节与陷阱

资源管理最核心的机制就是引用计数。每份资源维护一个计数器，有对象引用它就加一，对象不再引用就减一，减到零就释放。逻辑简单，但实现起来坑不少。

第一个坑是循环引用。A 引用 B，B 引用 A，两个的计数都永远大于零，谁也释放不了。解决办法有两种：一是打破循环，让其中一方用弱引用；二是引入垃圾回收来兜底。我倾向于在设计阶段就避免循环引用，资源之间的依赖尽量做成单向的。

第二个坑是计数操作的原子性。如果多个线程同时加减计数，不加锁就会出错。但加锁又影响性能。常见的做法是用原子操作，比锁轻量，但比普通加减还是慢。优化手段是减少计数操作的频率，比如批量引用、延迟释放。

第三个坑是释放时机。计数减到零的时候，是立刻释放还是延迟释放？立刻释放简单，但可能在渲染线程正在用这个资源的时候把它释放了，导致崩溃。延迟释放是先把资源标记为待释放，等到一个安全点（比如帧末）再统一释放。这个方案更安全，但需要额外的待释放队列。

// 引用计数的简化实现 class ResourceBase { public: void AddRef() { m_refCount.fetch_add(1, std::memory_order_relaxed); } void Release() { if (m_refCount.fetch_sub(1, std::memory_order_acq_rel) == 1) { // 计数减到零，加入待释放队列 ResourceManager::GetInstance().QueueForRelease(this); } } private: std::atomic<int> m_refCount{0}; };

注意：fetch_sub返回的是减之前的值，所以等于 1 的时候说明减完就是 0，这时候才需要释放。这个细节写错的人不少，写错了要么提前释放要么永远不释放。

3.3 资源缓存与淘汰策略

资源加载进来之后，不可能永远留在内存里。内存是有限的，必须有一套淘汰策略决定哪些资源该被踢出去。

最简单的策略是LRU（最近最少使用）。每次访问资源就把它移到队列头部，内存不够的时候从尾部开始淘汰。实现简单，效果也不错，适合大多数场景。

进阶一点的是LFU（最不经常使用），统计每个资源的访问频率，淘汰频率最低的。适合访问模式比较稳定的场景，但有个问题：曾经很热但现在不用的资源，频率还是很高，不容易被淘汰。

实际项目中，我一般用LRU 加优先级的混合策略。每个资源有个优先级，比如场景必需的资源优先级高，装饰性的资源优先级低。淘汰的时候先看优先级，同优先级再看 LRU。这样能保证关键资源不会被误杀。

还有一个细节是淘汰的粒度。是按单个资源淘汰，还是按资源组淘汰？比如一个角色的模型、贴图、动画是一组，要淘汰就一起淘汰，不然会出现模型还在但贴图没了的情况。我倾向于按组淘汰，虽然实现复杂一点，但逻辑上更干净。

4. 实操过程：从零搭一套对象与资源管理系统

4.1 对象系统的搭建步骤

假设你现在要从零搭一套对象系统，我建议按这个顺序来。

第一步，定义对象基类。对象基类里放最通用的东西：唯一 ID、有效性标志、组件列表、父子关系。不要放具体逻辑，具体逻辑都放到组件里。

class GameObject { public: uint32_t GetID() const { return m_id; } bool IsValid() const { return m_valid; } template<typename T> T* GetComponent(); void AddComponent(Component* comp); void RemoveComponent(Component* comp); private: uint32_t m_id; bool m_valid = true; std::vector<Component*> m_components; GameObject* m_parent = nullptr; std::vector<GameObject*> m_children; };

第二步，实现对象管理器。对象管理器负责创建、销毁、查找对象。内部用一个数组存所有对象，用 ID 做索引。销毁对象的时候不立刻删，而是标记为无效，等帧末统一清理。这样能避免在遍历过程中删除对象导致的迭代器失效。

第三步，接入对象池。对于频繁创建销毁的对象类型，比如子弹、粒子、特效，用对象池管理。对象池内部维护一个空闲列表，创建的时候从空闲列表拿，销毁的时候还回去。池子的大小可以动态调整，但要有上限，防止无限增长。

第四步，处理父子关系。父子关系是场景树的基础。父对象销毁的时候，子对象要么一起销毁，要么解除关系。我一般选择一起销毁，因为子对象脱离父对象之后往往没有意义。解除关系的时候要注意从父对象的子列表里移除，同时清空子对象的父指针。

4.2 资源系统的搭建步骤

资源系统的搭建比对象系统复杂，因为涉及 IO、线程、缓存等多个方面。

第一步，定义资源基类。资源基类里放引用计数、资源路径、加载状态。所有具体资源类型都继承它。

第二步，实现资源加载器。每种资源类型对应一个加载器，比如贴图加载器、模型加载器、音频加载器。加载器负责把磁盘上的文件解析成内存中的资源对象。加载器要注册到资源管理器里，资源管理器根据文件扩展名选择合适的加载器。

第三步，实现资源缓存。资源管理器内部维护一个哈希表，key 是资源路径，value 是资源指针。加载资源的时候先查缓存，有就直接返回，没有才走加载流程。缓存要支持引用计数，计数为零的资源进入待释放队列。

第四步，实现异步加载。异步加载需要一个线程池和一个任务队列。加载请求丢进队列，线程池里的工作线程取任务执行，加载完了把结果放到完成队列，主线程每帧检查完成队列，处理加载完成的资源。

// 异步加载的简化流程 void ResourceManager::LoadAsync(const std::string& path, std::function<void(Resource*)> callback) { // 先查缓存 if (auto* cached = FindInCache(path)) { callback(cached); return; } // 创建加载任务 auto task = [this, path, callback]() { Resource* res = LoadFromDisk(path); std::lock_guard<std::mutex> lock(m_completeMutex); m_completeQueue.push({res, callback}); }; m_threadPool.Enqueue(task); } void ResourceManager::Update() { std::lock_guard<std::mutex> lock(m_completeMutex); while (!m_completeQueue.empty()) { auto [res, callback] = m_completeQueue.front(); m_completeQueue.pop(); callback(res); } }

第五步，实现内存预算和淘汰。给资源管理器设一个内存预算，比如 512MB。每帧统计当前内存占用，超过预算就触发淘汰。淘汰按优先级和 LRU 来，淘汰到内存降到预算的 80% 为止，留 20% 的缓冲，避免频繁触发淘汰。

4.3 参数计算与选择过程

内存预算怎么定？这个不能拍脑袋。我的做法是先统计游戏运行时的峰值内存占用，然后乘以 1.5 作为预算。比如峰值是 400MB，预算就定 600MB。留 50% 的余量是为了应对突发情况，比如玩家快速移动导致大量资源同时加载。

对象池的大小怎么定？统计游戏中最坏情况下同屏同类对象的数量，乘以 1.2 作为池子初始大小。比如最坏情况同屏 500 颗子弹，池子初始就定 600。池子上限可以定初始大小的两倍，超过上限就不再回收，直接销毁，防止内存无限增长。

异步加载的线程数怎么定？一般用 CPU 核心数减一，留一个核心给主线程。比如 8 核 CPU，就用 7 个加载线程。但 IO 密集型任务可以适当增加线程数，因为线程大部分时间在等 IO，不是真的在跑计算。

实操心得：内存预算不要定得太紧。我见过一个项目为了省内存，预算定得刚好等于峰值，结果玩家一快速移动就触发淘汰，淘汰完又立刻加载，加载完又淘汰，帧率直接掉到个位数。后来把预算放宽到峰值的 1.5 倍，问题就消失了。内存这东西，宁可多留一点，也不要卡得太死。

5. 常见问题与排查技巧实录

5.1 内存泄漏的排查思路

内存泄漏是对象和资源管理最常见的问题。排查思路我总结成三步。

第一步，确认是不是真的泄漏。有时候内存涨只是缓存没满，不是泄漏。连续跑十分钟，看内存曲线是持续上升还是趋于平稳。持续上升才是泄漏，趋于平稳是正常缓存。

第二步，定位泄漏的资源类型。给每种资源加统计，记录创建数量和销毁数量。跑一段时间后对比，创建数远大于销毁数的类型就是嫌疑对象。

第三步，定位具体的泄漏点。用内存快照工具，在泄漏前后各拍一张快照，对比差异。差异里多出来的对象就是泄漏的对象。然后根据对象的引用链，找到是谁在持有它。

我遇到过的泄漏原因里，排前三的是：事件监听器没注销、循环引用、异步加载回调里持有对象引用。这三个占了八成以上。

5.2 悬空引用的预防与处理

悬空引用比内存泄漏更危险，因为它直接导致崩溃。预防手段有几个。

用句柄代替裸指针。句柄里带版本号，访问前先校验版本，对不上就返回空。这个方案能挡住绝大多数悬空引用。

对象销毁时通知所有引用方。维护一个反向引用表，记录谁引用了这个对象。销毁时遍历反向引用表，通知每个引用方清空引用。这个方案更彻底，但维护成本高。

用弱引用。需要长期持有但不希望影响生命周期的引用，用弱引用。弱引用不增加计数，访问前先升级为强引用，升级失败说明对象已经销毁。

实际项目中，我一般组合使用：核心对象用句柄，事件监听用弱引用，临时引用用裸指针但保证作用域内有效。

5.3 常见问题速查表

5.4 几个容易被忽略的细节

路径规范化。不同平台路径分隔符不一样，大小写敏感度也不一样。加载资源前统一转成小写、统一分隔符，能避免很多缓存 miss 的问题。

资源依赖。模型依赖材质，材质依赖贴图。加载模型的时候要自动加载依赖，释放模型的时候要自动释放依赖。依赖关系要记录清楚，不然会出现模型还在但贴图没了的情况。

热重载。开发阶段经常需要改资源看效果。热重载要能检测文件变化，重新加载资源，并通知所有引用方更新句柄。这个功能对开发效率提升很大，但实现起来要注意线程安全。

序列化。对象和资源都需要序列化，存盘和读盘要能正确重建引用关系。序列化的时候用 ID 而不是指针，读盘的时候根据 ID 重建引用。

注意：热重载的时候，正在使用的资源不能直接替换，要先加载新资源，等所有引用方都切换到新资源之后，再释放旧资源。直接替换会导致正在渲染的帧访问到已释放的内存。

6. 多线程环境下的对象与资源管理

6.1 线程安全的边界划分

多线程是对象和资源管理绕不开的话题。但并不是所有操作都需要线程安全，划分清楚边界能省很多事。

我的划分原则是：创建和销毁走主线程，加载和解析走工作线程，访问走各自线程。对象创建销毁涉及场景树修改，必须在主线程做。资源加载解析是纯计算，可以丢到工作线程。资源访问是只读的，只要资源已经加载完成，多线程同时读没问题。

这个划分的关键是资源加载完成之前，不能有任何线程访问它。所以需要一个状态机：加载中、已加载、加载失败。访问前先检查状态，只有已加载的资源才能访问。

6.2 锁的粒度与性能优化

锁用不好，多线程反而比单线程慢。优化锁的核心是减小粒度和减少频率。

减小粒度：不要用一个全局锁保护所有资源，而是每个资源一个锁，或者用分段锁。这样不同资源的操作不会互相阻塞。

减少频率：批量操作代替单次操作。比如引用计数，不要每次加减都加锁，而是攒一批一起加。或者用原子操作代替锁，原子操作比锁轻量得多。

还有一个技巧是读写分离。读操作远多于写操作的场景，用读写锁代替互斥锁。多个读线程可以同时读，只有写的时候才互斥。资源管理就是典型的读多写少，用读写锁能明显提升并发性能。

6.3 无锁队列在资源加载中的应用

资源加载的完成队列是典型的生产者消费者模型，工作线程生产，主线程消费。这个场景用无锁队列很合适。

无锁队列的核心是 CAS（比较并交换）操作。入队的时候，先读取尾指针，然后 CAS 尝试更新尾指针，成功就写入数据，失败就重试。出队类似。无锁队列的好处是不阻塞，坏处是实现复杂，而且 ABA 问题需要额外处理。

实际项目中，如果对性能要求不是极致，用带锁的队列加条件变量就够了。无锁队列的收益在队列操作非常频繁的时候才明显，一般项目用不上。

// 简单的线程安全队列 template<typename T> class ThreadSafeQueue { public: void Push(T item) { std::lock_guard<std::mutex> lock(m_mutex); m_queue.push(std::move(item)); m_cond.notify_one(); } bool TryPop(T& item) { std::lock_guard<std::mutex> lock(m_mutex); if (m_queue.empty()) return false; item = std::move(m_queue.front()); m_queue.pop(); return true; } private: std::queue<T> m_queue; std::mutex m_mutex; std::condition_variable m_cond; };

实操心得：条件变量的 notify 要在锁外面调用，虽然标准允许在锁内调用，但在锁内调用会导致被唤醒的线程立刻又阻塞在锁上，多一次上下文切换。这个细节对性能有影响，尤其是高并发场景。

7. 对象池的进阶设计与实战优化

7.1 对象池的通用化设计

对象池写起来简单，但写好用不容易。通用化的对象池要解决几个问题：任意类型、自动扩容、线程安全、统计信息。

任意类型用模板解决。自动扩容用空闲列表加增长策略解决。线程安全用锁或者线程本地池解决。统计信息记录创建数、复用数、峰值数，方便调优。

template<typename T> class ObjectPool { public: T* Acquire() { std::lock_guard<std::mutex> lock(m_mutex); if (m_freeList.empty()) { if (m_totalCount >= m_maxSize) return nullptr; m_freeList.push_back(new T()); m_totalCount++; } T* obj = m_freeList.back(); m_freeList.pop_back(); m_activeCount++; m_peakCount = std::max(m_peakCount, m_activeCount); return obj; } void Release(T* obj) { std::lock_guard<std::mutex> lock(m_mutex); m_freeList.push_back(obj); m_activeCount--; } private: std::vector<T*> m_freeList; size_t m_totalCount = 0; size_t m_activeCount = 0; size_t m_peakCount = 0; size_t m_maxSize = 10000; std::mutex m_mutex; };

7.2 线程本地池减少竞争

多线程环境下，全局对象池的锁会成为瓶颈。优化方案是每个线程一个本地池，线程从自己的池子拿对象，不够了再从全局池批量拿一批。释放的时候也先还到本地池，本地池满了再批量还回全局池。

这个方案能大幅减少锁竞争，代价是内存占用会高一些，因为每个线程的池子都有冗余。适合对象创建频繁、线程数不多的场景。

7.3 对象池的监控与调优

对象池不是建好就完事了，要持续监控和调优。关键指标有三个：命中率、峰值使用率、扩容次数。

命中率是直接从池子拿到对象的比例。命中率低说明池子太小，频繁扩容。峰值使用率是峰值时活跃对象占池子大小的比例。比例太高说明池子快满了，该扩容了。扩容次数太多说明初始大小定小了。

我一般每帧统计这些指标，输出到调试面板。发现异常就调整池子参数。这个习惯帮我提前发现过好几次潜在的性能问题。

8. 资源热更新与版本管理

8.1 热更新的基本流程

热更新是运营阶段的核心需求。基本流程是：检测版本、下载差异、校验完整性、替换资源、重载。

检测版本靠版本号比对。客户端存一个当前版本号，服务器返回最新版本号，不一致就触发更新。下载差异靠差异算法，只下载变化的文件，不是全量下载。校验完整性靠哈希，下载完算一遍哈希，和服务器给的比对，不一致就重下。替换资源要注意原子性，不能替换到一半崩溃了，导致资源损坏。重载要通知所有引用方，更新句柄。

8.2 资源版本冲突的处理

热更新最头疼的问题是版本冲突。玩家 A 的资源版本是 1.0，玩家 B 是 1.1，两人联机的时候资源不一致，可能出现显示错误甚至崩溃。

解决办法是资源版本协商。联机的时候，客户端把资源版本发给服务器，服务器选一个大家都兼容的版本，通知所有人切换。如果找不到兼容版本，就提示玩家更新。

另一个办法是资源隔离。不同版本的资源放在不同目录，运行时根据版本号加载对应目录的资源。这个方案更彻底，但内存占用会高一些。

8.3 热更新的回滚机制

热更新出问题是常有的事，必须有回滚机制。回滚的核心是保留旧版本资源，新版本出问题的时候能切回去。

我的做法是每次更新前把旧资源打包备份，更新后如果检测到异常（比如崩溃率上升、加载失败率上升），自动触发回滚。回滚就是解压备份，替换当前资源，重启游戏。

回滚机制的关键是快速检测异常。我一般监控三个指标：崩溃率、加载失败率、帧率。任何一个指标超过阈值就触发回滚。阈值不能定太松，太松了玩家已经受影响了才回滚；也不能太紧，太紧了正常波动就回滚，反而影响体验。

实操心得：热更新一定要做灰度。先放 1% 的玩家更新，观察一天没问题再放 10%，再观察再放全量。我见过太多全量更新出事故的案例，灰度能帮你把事故控制在 1% 的玩家范围内。

9. 从数据看管理系统的性能影响

9.1 关键性能指标与测量方法

对象和资源管理的性能影响，主要看几个指标：对象创建销毁耗时、资源加载耗时、内存占用、GC 频率。

对象创建销毁耗时用高精度计时器测，测一千次取平均。资源加载耗时区分同步和异步，同步测阻塞时间，异步测从发起到完成的延迟。内存占用用引擎自带的内存统计，或者操作系统的内存接口。GC 频率统计单位时间内的 GC 次数和每次的耗时。

测量的时候要注意排除干扰。关掉其他程序，固定 CPU 频率，多次测量取中位数。单次测量波动太大，没有参考价值。

9.2 优化前后的数据对比

我拿一个实际项目的数据做对比。优化前，对象创建平均 0.05 毫秒，资源加载平均 120 毫秒，峰值内存 800MB，每分钟 GC 3 次。优化后，对象创建降到 0.008 毫秒（用对象池），资源加载降到 40 毫秒（用异步加缓存），峰值内存降到 500MB（用淘汰策略），GC 降到每分钟 0.5 次。

这些数字看起来不大，但放到实际游戏里，效果很明显。对象创建快了 6 倍，同屏一千个对象的情况下，每帧省了 42 毫秒。资源加载快了 3 倍，场景切换的等待时间从 3 秒降到 1 秒。内存降了 300MB，低端机也能跑起来了。

9.3 不同策略的适用场景总结

这张表是我这些年做项目总结出来的，选型的时候对着看，基本不会选错。当然具体项目还要具体分析，没有银弹。

10. 一些踩坑之后的个人体会

写了这么多，最后分享几个我踩坑之后才明白的道理。

第一，不要过早优化，但也不要完全不优化。我见过一开始就上全套对象池、异步加载、流式加载的项目，结果复杂度爆炸，bug 修不完。也见过完全不优化，上线后卡成 PPT 的项目。我的建议是：先做对，再做快。功能跑通了，再根据性能数据针对性优化。

第二，监控比优化更重要。你不知道问题在哪，优化就是瞎猜。把对象数量、资源数量、内存占用、加载耗时这些指标监控起来，问题自然就暴露了。我现在的习惯是每个项目都先搭监控面板，再写业务逻辑。

第三，简单方案往往够用。不是所有项目都需要流式加载，不是所有资源都需要异步。很多项目用同步加载加缓存就能跑得很好。复杂度是有代价的，能简单就简单。

第四，测试要覆盖边界情况。对象池满了怎么办？资源加载失败了怎么办？热更新下载中断了怎么办？这些边界情况平时不出现，一出现就是崩溃。我现在的习惯是每个模块都写边界测试，宁可多花时间，也不要上线后半夜被叫起来修 bug。

第五，文档和注释要写清楚。对象和资源管理的代码往往很绕，过两个月自己都看不懂。关键逻辑一定要写注释，设计决策一定要写文档。我现在回头看两年前写的代码，没有注释的地方基本都要重新读一遍才能理解，有注释的地方一眼就懂。

这个模块的东西还有很多，比如序列化、网络同步、跨平台适配，每一个都能单独写一篇。今天先把核心的对象生命周期、资源引用计数、对象池、异步加载、热更新这些讲透。后面有机会再展开其他部分。