我现在用的还是比较简单的引用计数. 主Asset有引用计数, 依赖Asset没有引用计数. 主AB和依赖AB都有引用计数.
目前没有遇到环形依赖的问题
那你这个孤岛问题没法处理了
什么孤岛问题
引用计数的特有问题
没明白，我这个方案目前主要麻烦是 不好反向排查引用计数
设计上控制不了的 它需要每个使用的地方都去做计数
那你不是先加载依赖再加载主资源的吧
跟对象池一样 如果使用的地方取了 不回池 就没办法
是一股脑无序加载的
是啊
那环形依赖的基数你全部计数加了几
我这边 应该在打包的时候就处理了环形依赖了
我的依赖是依赖AB 没有依赖资源的
给你看一下依赖清单哈
DependsAssetBundleList里面放的是AssetBundle 而不是Asset
那你依赖的依赖呢？
这里就一级
加载是这样的, 先加载依赖AB 再加载主AB 再加载主Asset
依赖的依赖 也在我那个清单里面了
你可以这么理解: 原本它是多级的, 但我给它合并成1级了, 并且把重复的AB给剔除掉了
对 多级合并成1级 然后剔除重复的AB
这样清单也变小了
这种事情我觉得能在Editor环境做 就在Editor环境做
在Runtime环境做 性能不好
这里也不太对吧
什么不太对
环形依赖，你咋处理的
A依赖B, B依赖C, C依赖A. 这样?
嗯，这种你的计数会加载的时候asset和assetbundle分别增加几
@天亮[YOYO外包版] 假设我加载的是A吧, 那么A的Asset计数是1 B的Asset计数是0 C的Asset计数是0
A.B.C的AssetBundle计数都是1
我在打包的时候 就杜绝了环形依赖了 Unity有个API AssetDatabase.GetDependencies 参数传true 导出的资源清单就不存在环形依赖问题的
所以我这边在加载的时候 也没有什么递归去找依赖
就是一个For循环 直接加载所有依赖AB
那你AB不卸载就Asset不卸载？那你AB引用一直是1
这算哪门子引用计数
不是吗？ 那如果有环形依赖的话 这个清单就无限大了?
那个是找你依赖资源的依赖的参数
是否递归的找下去
是呀 但返回的结果就是个数组，而不是树
你这样打包不过刚好踩中Unity的资源机制，你这个并不是引用计数
可以看看GF对于引用计数的处理，你这个还显得有点稚嫩了
@天亮[YOYO外包版] 如果我卸载了资源A, 那么A的Asset计数是0 B的Asset计数是0 C的Asset计数是0
A.B.C的AssetBundle计数都是0
其实也是能释放的
那如果0是你的释放时间，AssetBundle的加载顺序你就是乱序的
因为他们的计数只加了1
是这个道理吧
如果你把0判断是asset的卸载实际，那为啥BC不是被卸载的状态
而是B，C要靠着自己所在的AssetBundle进行卸载
Asset跟AssetBundle应该不依赖对方的计数
不太理解
噢噢 我现在是依赖的, Asset计数0 才会让AssetBundle计数减1
那你这完全限制了Asset能单独卸载了
可能是只会去大小的AB包？
噢 那确实
我没有单独卸载Asset的, 卸载的最小颗粒度也是AssetBundle
@五杀时间到了 这种是很大问题的
首先AB包很小这个是很限制随机读写的性能
单个AB很大的话 内存不好释放是吗?
AB很大其实没关系，大家一般都是LZ4的支持随机读写的
只是你这个Asset的卸载时机在AssetBundle的卸载时刻，你会导致大量卡顿的帧
导致内存称为瓶颈
嗯 我明白你说的了 就是AB太小的话 限制了随机读写的性能.
AB太大的话又没办法单独卸载Asset
然后一个大的AB一次释放掉 CPU耗时太高 会卡一下
当时我写的时候 是没考虑到这种性能问题
就按自己想法撸的
你这么一说确实 性能不太友好
GF可以说是在资源管理上是无敌的，哪怕你加载到半中间突然不想要了，GF也给你处理过了，副作用就是构建资源包时Load和分析比较耗时，你可以自己改造下打包过程，尤其是接入lua或者wolong或者其他二进制的伙计，很多人问过我这个事情了
@预备 我那个就不存在循环依赖这个问题
但就像亮哥说的, 不支持单个Asset释放, 释放最小颗粒度是AB, 性能不友好