DynamicBufferComponent:非托管内存下可以随意调整大小的数组,默认容量为128字节,每个元素默认大小为16字节(float4类型),也就是默认容量为8个元素。其继承接口为IBufferElementData。
DynamicBuffer默认是存储在一段连续的trunk中,如果默认大小需要扩充,则会移动到另外一个trunk中,原始的会被销毁。
DynamicBuffer的使用事项:
添加,移除均可以使用AddComponent和RemoveComponent,但是检索或获得DynamicBuffer我们需要使用GetBuffer而不是GetComponent。
因为DynamicBuffer是只指向初始Trunk,当一个Entity添加或者移除Component时,它所属的Trunk就会发生改变,但是原来的DynamicBuffer指向是不变的。
ECB.AddBuffer将返回一个可写的Buffer,拷贝至ECB的Playblack中,SetBuffer同理,而AppendBuffer则是在Playblack所指的Buffer尾部添加值
==============================================================================================
Enableable Component:用来在Runing时启用或者禁用对象上的某个组件,用于处理频繁修改组件的情况。(优化了1.0之前频繁操作Add和Remove导致的Structural Change)
==============================================================================================
Shared Component:首先第一点,Shared Component一般都存储在Chunk之外,然后通过每一个chunk的句柄对应Shared值,这样设计的话,可以使得不同的Chunk,也就是不同的Entity的组件集合可以对应一个Shared Value。如果我们将Shared Value进行更改,并且跟改后Shared Value是存在于当前Shared ComponentDataArray中,那么Entity对应的Chunk会相应进行移动,如下图:
但是如果是下面的情况,也就是Value值的改变是新值,那么则是添加到新的Chunk中,同时也同样引起了Structual Change,这两种情况应该要避免。
第三点我想着重解读一下,假设有两种共享组件,那么某一个实体的chunk可以拥有共享组件1,共享组件2,共享组件1和2一共三种情况,那么至少就有三种Chunk的可能,也就导致了Archetype有三种可能,即碎片化(个人理解,可能不大对?)