Binder,绑定器
接触过ui的小伙伴应该都有用过有类似功能的东西。如,图标绑定器,技能绑定器,背包物品绑定器。
几乎所有 符合以下条件的物体都可以通过Binder的方式进行数据绑定然后自动生成。
- 需要重复生成。
- 数据类相同。
- ui表现类似。
虽然具体的bingder逻辑不尽相同,但与使用条件对应的也有几个点是binder一定需要去处理的:
- 一堆具体的游戏物体gameobject 如:List<gameobject>
- 某个数据类 如:IconDataClass
- SetUp ,对这堆游戏物体的共同之处进行初始化 。Bind:对不同之处进行差异化
大概长这样:
public static void Binder<Tbinder, KData>(List<GameObject> golist, List<KData> datas) where KData : class, new() where Tbinder : class
{
for (int i = 0; i < golist.Count; ++i)
{
if (golist[i].GetComponent<Tbinder>() != null) //判断go上是否有Tbinder,若有执行Bind操作
{
golist[i].Bind(datas[i]);
}
else //若没有,new出来 通过某种方式比如我这里的作为事件监听的parameter 给到go物体上 ,然后setup + bind
{
var listener = UIEventListener.Get(golist[i]);
listener.parameter = new Tbinder();
golist[i].Setup();
golist[i].Bind(datas[i]);
}
}
}
同时在Tbinder的实例中,都会定义OnDestroy,功能是清除Tbinder里面的所有数据。
然后昨天遇到的问题:: 在我执行销毁那堆go物体以后,通过调试发现OnDestroy确实调用到了,然而这个Tbinder却依然存在于内存空间,幽灵一般不知道哪里还在引用这它。于是再次执行绑定时就会报错说 xx物体已经被销毁了但你依然试图去访问。
查了半天,后来终于发现是OnDestroy的时候,传入Tbinder中的KData,居然忘了清空。
自己逻辑上觉得一切正常但真正的问题常常隐藏在自己思维的盲区。
吃一堑长一智:当这个类不再被其他对象引用且自己也不引用任何其他对象的时候才会触发Dispose回收机制。
如果再次遇到这个异常,就去检查所有相关的Destroy是否真的清楚干净了。