unity中如何unity获取list下一条数据共享内存数据

来源：蜘蛛抓取(WebSpider) 时间：2018-08-29 03:01 标签： unity获取list下一条数据

至于ECS的定义咱们先跳过，也可以看看我之前的一篇文章：

先说说和它一同推出的，和ECS没直接关系的新特性：

NativeArray内部只能容纳值对象。而且在创建的时候除了指定length外，还需要指定allocator模式：

按文档的说法，这种Native的数组更加有助于数据的连续性，对cache友好。但仅仅如此的话，一个普通的只包含struct的Array也可以达到同样的效果。

我个人是相当怀疑这玩意儿其实是在非托管堆上申请的内存，也就是和Mono的内存管理没啥关系，毕竟这东西是Jobs系统必须的东西，而Jobs看上去和C++部分走的很近。从名字上，也比较像。

先不管这个。至少从表面上看，它就是个普通的struct数组。

使用struct数组其实并不是为了减少GC（虽然实际上也大幅减少了），目的是为了更快的内存访问速度，在访问速度上通常能提高>100%的效率。这个和GPU里对纹理的cache是一样的道理，数据会先从内存到达二级缓存，在二级缓存内的读取速度远大于内存，而连续的内存会很大概率被提前放进二级缓存中。

在CPU的工作过程中，数据的读取成为瓶颈的情况其实并不罕见，只是我们平时使用的情况下，很多数据本来就是连续的，所以连续性相当不友好的“链表”才较少被使用。这种整块的内存结构也能减轻内存管理器整理内存的成本。

即使，数据读取确确实实没有成为瓶颈，但CPU内的晶体管可不是光用来计算的，也有很大一部分用于数据存取，减少它们的工作量会很明显的降低功耗和发热。

这点在GPU上提得比较多。但其实，只要是芯片，都是一样的。

另一个就是提供了SIMD的可能性……只是可能性而已。

不过C#里struct的使用有一个“复制”的大坑。因为C#不提倡使用指针，在存取数组里struct数据的时候只能多次复制，语言特性注定这个问题现在没法解决，所以虽然struct大家都知道好处，真去用它却是不现实的。

而最新版的C#7则适时提供了进行了支持。

但目前的Unity最多支持到C#6。


你们也知道这事儿啊……

所以这个框架的存在确实有可能会督促Unity将Mono编译环境升级到C#7，那样struct就能真正开始用了。没这玩意儿struct很容易搞成负优化的。

ECS的一个重要特性就是并发优势，甚至可以说，不支持多并发的ECS几乎没有价值。

（多线程可以支持多核执行，在单核天花板已经到达的现在，多核逻辑的时代也差不多该到了。而ECS是少数有可能自动实现多核的逻辑架构，因为提供了数据隔离的依据。）

Jobs是Unity自己的多线程框架，在这里就对ECS提供了支持。

ps.其实个人认为ECS框架以后会慢慢和传统的MVC架构等这种注重继承的游戏框架结合并且这种可能性是很大的。一个是随着网络数据交互量的增加（主要由于网速加快，网络资费便宜），二呢是因为随着游戏的创新发展更多的玩法功能将被实现出来，所以游戏设计不在是传统的功能设计，对功能的要求更多的是想搭乐高一样的实现。三呢现在游戏中具体的业务逻辑实现确实需要一套框架来进行规范。 

//循环向a函数每次发送200个字节长度（这个是固定的）的buffer,

//a函数中需要将循环传进来的buffer，组成240字节（也是固定的）的新buffer进行处理，

//在处理的时候每次从新buffer中取两个字节打印

我要回帖

更多关于 unity获取list下一条数据 的文章

 

随机推荐