FireEngine
最早在冰火的时候就开始用Unity3d，然后当时的项目组封装了一套Unity3d的资源管理机制，后来需求和改动越来越多，重构的也不及时，而且我个人觉得当时的架构太过于庞大，用了大量的类继承以及虚函数，这样导致了大量的重复代码，并且因为虚函数的问题导致在别人在看资源相关的代码的时候可读性非常之差，而我觉得这是没有必要的，相对于类继承和虚函数来说，在允许的情况下我更愿意使用类的组合、单例、甚至于静态函数，这样也能起到同样的松耦合的作用，而且层次依然很分明。
于是在后来项目后期，自己重新写了一套，写了好久了，一直都没有用，主要是成熟项目不想改动太多，因为难免会有一些测试不到的地方。我自己接上过项目测试，是可以跑起来的，而且是对以前架构里查找表那一套是兼容的。本来Unity5之后有依赖资源打包，这样AssetMap等查找表可以更简化一点。
新框架
以前的框架除了代码庞大之外，还有一个非常大的缺点，就是引用调用太过于混乱，甚至是网状结构，就比如Object层能直接访问到Bundle层，Asset层直接调用ResMgr层，这样是很容易乱的，并且代码可读性简直无力。于是一定要分层清晰，绝对不能跨权限调用，只能隔层调用。
画了一个分层的流程图。虚线的箭头表示回调。蓝色箭头是管理类的Update，因为管理类需要Update来支持异步操作。
虽然这是Unity3d的架构，但我觉得其他引擎或者其他游戏架构基本也就是这样，无非就是缓冲池、同步异步、查找表。
源码
源码请查看我的Git。