本文作者： 射手座团队 阿森
- 本文是论坛中 微信小游戏从立项到上线！谈谈《猎头专家》的开发历程 一文的一部分，因为内容比较独立，单独发出来方便查阅。
- 更好的阅读体验可以移步 我的博客 。
- 时间有限，行文难免有疏漏，欢迎吐槽拍砖！
序
游戏总杜绝不了 BUG，每当出现一个 BUG 时，程序猿们总是需要搅破脑汁去解决，这是一件很不愉快的事情。但如果 BUG 的出现暴露出了更严重的其它问题时，也算是不幸中的万幸了。我们在《猎头专家》的运营过程中就遇到过这么一个事。
《猎头专家》中有一个 无限模式 的玩法，可以用有限的复活次数不停挑战难度越来越高的电脑关卡，技术好的玩家一般能打到十多层。但某次更新版本后，我们发现有个玩家居然挑战到了 23 层，而且复活次数为 0 ，我们整个团队都震惊了…… 为了研究玩家如何做到的，我们也进入无限模式不断尝试，结果发现这种奇异的现象居然是由于一个 BUG 导致的！！！
出现 BUG 的原因是，上次版本更新导致复活次数没有正确累计，玩家可无限复活并不消耗复活次数。但当我们达到 无限模式 30 层希望更进一步的时候，游戏崩溃了！！！鉴于无限模式不停切换地图与角色的特点，我们把问题的矛头指向了内存泄露。原来那个达到 23 层的玩家之所以没有打得更高，是因为手机比我们的差啊……
我们使用的一直是 CCC 推荐的释放资源的方法，在切换地图与人物后，将“所有未用到的已加载资源”通过 cc.loader.release 方法释放掉。但在深入了解、不停地观测 cc.loader._cache 中所有加载的资源条目之后，我们发现手动释放掉的资源只是冰山一角————大量依赖资源并未被同时释放，而这些资源占用了较多的内存。我们先尝试了一个简单的解决方案：使用接口 cc.loader.getDependsRecursively 获取到资源的依赖关系并将其释放，但这个方案并不好用。因为某些资源间的互相引用，极有可能导致资源错误释放，出现更严重的问题。为此，我们设计了一个动态资源管理模块，让单个功能模块或界面或场景，能够更简单的管理自己所使用的资源，如下：
// 加载资源：
this.loader.load(path, sp.SkeletonData, (skeletonDatas) => {
// xxx
})
// 释放资源
this.loader.release()
Cocos Creator(CCC) 资源加载特性
在介绍动态资源管理模块之前，我们先需要了解一下 Cocos Creator 的资源加载机制与其特性。依据官方提供的相关文档 获取和加载资源 与简单的 DEMO 测试，我们对 Cocos Creator 的资源加载特性做一个简单的总结：
- 资源动态加载都是异步的。在处理资源加载与释放时，就需要考虑加载中的资源如何释放的问题。
- 资源是互相依赖的，指定加载资源时，也会加载其所有依赖项。在处理资源释放时，需要考虑资源的依赖关系。
- 动态加载的资源都是不会自动释放的。就算切换场景，动态加载的资源依然需要手动释放。
-
cc.loader.getDependsRecursively接口可以获取到资源的所有依赖项，包括依赖的依赖。这个接口可以让我们方便地获取到资源的依赖关系。 -
cc.loader.getDependsRecursively接口获取到的数据，是每个资源对应的唯一的 reference id ，该值可以通过cc.loader的私有方法_getReferenceKey获取。释放时使用cc.loader.release直接传入资源的 reference id 进行释放。 - 按路径加载或释放资源时，需要指定目标资源的类型（简单的配置文件除外）。释放资源时，如果该路径下有多种资源类型（比如 spine 动画相关文件有 json/png/atlas ），你将不知道它会释放什么资源，而且释放也不完全（只会释放其中一种资源）。
- 类似于上一条，在使用
cc.loader.getDependsRecursively接口获取依赖项时，不要使用文件路径作为参数获取。
《猎头专家》资源概况
在《猎头专家》小游戏中，除去开启页资源外，其它所有资源均为动态加载，即资源文件绝大部分都在 resources 文件夹中存放。全局只有一个主场景，游戏过程中没有场景的切换。这种结构既有优势也有劣势：
优势：
- 全局脚本的挂载更容易
- 小游戏初包尽量小
- 不会出现自动加载资源与动态加载资源间的互相依赖问题（这个会加大游戏过程中的资源管理难度）
劣势：
- 必须有完善的释放机制
- 在适合的时候需要释放未使用的资源来减轻内存压力
为了满足《猎头专家》资源管理的诉求，我们设计了一套资源管理模块，仅供大家参考。
资源管理模块设计及实现
资源单项加载与释放
资源加载时需要指定资源类型（配置文件不需要），于是在加载资源时，我们选择了资源分类加载。而为了方便资源释放，在资源加载完成后，需要记录所有加载到的资源，包括其依赖项。
因此，我们设计了一个专用于单个资源加载的类 LoaderItem ，有以下几个主要属性:
class LoaderItem {
isReleased: boolean = false // 是否已被释放
urls: string[] = null // 加载项列表
type: typeof cc.Asset = null // 加载资源类型
resources: Object = null // 所有使用资源的reference id
maxRetryTimes: number = 0 // 最大重试次数
}
在资源加载完成时，记录 LoaderItem 对象所有使用到的资源（包括自身），具体实现如下：
type SUCCESS_CALL = (res:any[])=>void
type FAILED_CALL = (err:Error)=>void
type ERROR_CALL = (error:string)=>void
type PROGRESS_CALL = (completedCount: number, totalCount: number, item: any) => void
/**
* 缓存已使用资源
* @param resource 缓存单个资源的所有使用资源
*/
private _cacheRes (resource: any) {
let loader: any = cc.loader
this.resources[loader._getReferenceKey(resource)] = true
for (let key of loader.getDependsRecursively(resource)) {
this.resources[key] = true
}
}
/**
* 开始加载资源
* @param successCall 加载成功回调
* @param failedCall 加载失败回调
* @param progressCall 加载进度回调
*/
load (successCall: SUCCESS_CALL, failedCall:FAILED_CALL, progressCall:PROGRESS_CALL) {
let completedCallFunc = (error: Error, resources: any[])=>{
if (!error) {
for (let res of resources) {
this._cacheRes(res, errorCall)
}
successCall && successCall(resources)
} else {
if (this.maxRetryTimes === this._currentRetryTimes) {
failedCall && failedCall(error)
} else {
this._currentRetryTimes += 1
return this.load(successCall, failedCall, errorCall, progressCall)
}
}
}
let callFuncArgs: any[] = [this.urls]
this.type && callFuncArgs.push(this.type)
progressCall && callFuncArgs.push(progressCall)
callFuncArgs.push(completedCallFunc)
cc.loader.loadResArray.apply(cc.loader, callFuncArgs)
}
由于在加载完成后我们记录了全部资源，释放时的资源处理就会非常简单直接：
/**
* 释放资源
*/
release () {
this.isReleased = true
let resources: string[] = Object.keys(this.resources)
cc.loader.release(resources)
this.resources = {}
}
/**
* 释放资源
* @param otherDepends 其它依赖项，释放资源会跳过这些资源
*/
releaseWithout (otherDepends: Object) {
for (let reference in this.resources) {
if (otherDepends[reference]) {
delete this.resources[reference]
}
}
this.release()
}
模块的资源管理类
功能模块使用的资源不可能全都是单一类型，而且模块与模块之间，资源加载对象之间也有着可能的重合的使用资源。当某个模块资源需要释放时，其它模块引用的资源需要确保不被释放。因此，需要一个资源加载与释放的管理者，来告知 LoadItem 在释放时需要过滤的资源。
鉴于模块或界面之间的树状关系结构，管理者也需要设计成树状结构，即有一个根管理者及其派生管理者，而每一个节点上的资源在被释放时，都需要考虑其它所有节点所使用到的资源。管理者对象结构如下：
class Loader {
private _parentLoader: Loader = null
private _subLoaders: Loader[] = null
private _loadItems: LoaderItem[] = null
private _released: boolean = false
}
我们需要一个根管理器来加载通用资源，这些资源将不会被其它管理器释放。同时，所有其它管理器应当是根管理器的子节点，这样才契合 Cocos 节点的树状关系，在释放时可以方便的获得到其它模块使用到的所有资源。
/**
* 获取到根管理器
*/
get rootLoader (): Loader {
let root: Loader = this
while (root._parentLoader) {
root = root._parentLoader
}
return root
}
/**
* 创建子管理器
*/
createSubLoader (): Loader {
let loader = new Loader()
loader._parentLoader = this
this._subLoaders.push(loader)
return loader
}
/**
* 移除子管理器
* @param loader 需移除的子管理器
*/
private _removeSubLoader (loader:Loader) {
let index: number = this._subLoaders.indexOf(loader)
if (index >= 0) {
this._subLoaders.splice(index, 1)
}
}
加载时，管理器需将所有的加载项记录下来；释放时，直接释放这些加载项。需要注意的是：
- 由于资源加载是异步的，资源加载完成时可能该加载项已被释放，此时需要单独处理释放逻辑。
- 释放需要在下一个 Tick 进行。因为同一时刻，同一个文件可能有多个加载项在加载，
LoaderItem对象中还未对已引用的资源作记录，直接释放可能会错误释放掉其它资源的依赖项。
/**
*
* @param urls 加载资源项
* @param type 加载资源类型
* @param succCall 加载成功回调
* @param failCall 加载失败回调
* @param retryTimes 重试次数
* @param progressCall 加载进度回调
*/
load (urls: string[]|string, type:typeof cc.Asset, succCall: SUCCESS_CALL = null, failCall: FAILED_CALL = null, retryTimes:number = 0, progressCall:PROGRESS_CALL = null) {
let item: LoaderItem = new LoaderItem(urls, type, retryTimes)
item.load((res:any[])=>{
if (this._released|| item.isReleased) {
// 释放刚加载的资源，需在下一Tick释放，保证其它加载成功
return callInNextTick (()=>{
item.releaseWithout(this.rootLoader.getAllResources())
})
}
return succCall && succCall(res)
}, (error:Error)=>{
if (this._released) return
failCall && failCall(error)
}, progressCall)
this._loadItems.push(item)
}
/**
* 释放管理器
*/
release () {
this._released = true
this._parentLoader._removeSubLoader(this)
// 释放当前加载的所有资源，需在当前Tick释放，以让后续的加载请求生效
let allResouces: Object = this.rootLoader.getAllResources()
this._releaseWithout(allResouces)
}
/**
* 选择性释放资源
* @param allResouces 不能被释放的资源
*/
private _releaseWithout (allResouces: Object = null) {
for (let item of this._loadItems) {
item.releaseWithout(allResouces)
}
this._loadItems.length = 0
for (let loader of this._subLoaders) {
loader._releaseWithout(allResouces)
}
}
如何使用资源管理类
在使用资源管理类 Loader 时，我们需要一个根管理器来加载所有无需动态释放的公共资源。根管理器可以直接使用 new Loader 来创建，全局或场景唯一。其它子模块的资源管理器，需要通过根管理器的 createSubLoader 来创建。这样就建立了一个全局唯一的资源管理树。我们可以很方便的获取到当前正在使用的所有资源，也可以针对某个节点的资源进行定点释放。
例如，我们需要对某个界面中所有加载的 Spine 骨骼动画资源进行管理，在显示动画时加载资源，在界面销毁时移除资源，只需要按如下方式进行加载和释放：
onLoad () {
// app.mainLoader为根管理器
this._actorLoader = app.mainLoader.createSubLoader()
}
showSpine (path) {
this._actorLoader.load(path, sp.SkeletonData, (skeletonDatas) => {
let skeletonData = skeletonDatas[0]
if (this && this.node && cc.isValid(this.node) && skeletonData) {
this.spine.skeletonData = skeletonData
this.spine.setAnimation(0, 'idle', true)
}
}, null, -1)
}
onDestroy () {
this._actorLoader.release()
}
需要注意的是，资源加载在节点创建之前。在需要对该节点资源（包括节点自身）进行管理时， Loader 需要提前创建并用来加载节点预制件。为了方便节点在销毁时自动释放相关资源，我们增加了 LoaderKeeper 组件，动态加到节点上并将其 Loader 记录下来，在销毁时释放资源：
@ccclass
export default class LoaderKeeper extends cc.Component {
private _loader: Loader = null
get loader ():Loader {
return this._loader
}
init (loader: Loader) {
this._loader = loader
return this
}
onDestroy () {
if (this._loader) {
this._loader.release()
this._loader = null
}
}
}
完整的使用方式如下：
let loader: Loader = app.mainLoader.createSubLoader()
loader.load(prefabPath, cc.Prefab, (prefabs) => {
let prefab: cc.Prefab = prefabs[0]
let node = cc.instantiate(prefab)
app.canvas.addChild(node)
node.addComponent(LoaderKeeper).init(loader)
}, (err:Error)=>{
loader.release()
})
这套资源加载机制可以依据项目的需求进行灵活调整，Loader/LoaderKeeper/LoaderItem 联合使用能有效地按需 加载/释放 游戏中所使用到的所有动态资源。
结语
由于《猎头专家》的资源结构特点，资源管理在设计时并未考虑自动加载资源与动态加载资源之间互相依赖时，资源释放的过程与特性。在此特别提醒，如果项目中有这种使用方式时，请自行研究以免出现资源错误释放的问题。此文主要是通过提供一种管理器的设计思路来介绍 Cocos Creator 的资源加载与释放机制，与各位交流学习。