关于Unity2018最新杏彩合买源码新增腾讯分分彩完整版带手机端新版ECS框架
杏彩源码下载Q212303635 论坛：aqiulian.com先说说和它一同推出的，和ECS没直接关系的新特性：
NativeArray<T>
按照官方的说法，以后还会有NativeList，NativeHashMap，NativeQueue之类（这些在C#端就能实现）。
NativeArray内部只能容纳值对象。而且在创建的时候除了指定length外，还需要指定allocator模式：
Temp（临时）
TempJob（Job内临时）
Persistent（持久）
按文档的说法，这种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则适时提供了local/return ref进行了支持。
但目前的Unity最多支持到C#6。
你们也知道这事儿啊……
所以这个框架的存在确实有可能会督促Unity将Mono编译环境升级到C#7，那样struct就能真正开始用了。没这玩意儿struct很容易搞成负优化的。
Jobs System
ECS的一个重要特性就是并发优势，甚至可以说，不支持多并发的ECS几乎没有价值。
（多线程可以支持多核执行，在单核天花板已经到达的现在，多核逻辑的时代也差不多该到了。而ECS是少数有可能自动实现多核的逻辑架构，因为提供了数据隔离的依据。）
Jobs是Unity自己的多线程框架，在这里就对ECS提供了支持。
public class RotationSpeedSystem : JobComponentSystem
{
[ComputeJobOptimization]
struct RotationSpeedRotation : IJobProcessComponentData<Rotation, RotationSpeed>
{
public float dt;
public void Execute(ref Rotation rotation, [ReadOnly]ref RotationSpeed speed)
{
rotation.Value = math.mul(math.normalize(rotation.Value), math.axisAngle(math.up(), speed.Value * dt));
}
}
protected override JobHandle OnUpdate(JobHandle inputDeps)
{
var job = new RotationSpeedRotation() { dt = Time.deltaTime };
return job.Schedule(this, 64, inputDeps); //64指单个时间片内至少循环64次
}
}
整套东西使用起来还是很简单的，用实现IJobProcessComponentData<T1, T2...>的类标记要读写的ComponentData，Execute是逻辑，然后用Schedule推入Jobs系统。按这个模板书写就行了。
[ReadOnly][WriteOnly]元标签可以指定Component的读写模式，将数据进一步分离。
剩下就是归系统内部调配了，会在不产生线程冲突的情况下分配逻辑线程的时间片，实现高效率的并发。
上面这个IJobProcessComponentData是ECS框架实现的一个比较简便的用法（不需要写循环，只写其中一个循环节就可以了），本身是IJob的一个扩展，可以点进去看看稍微原始一点的写法。如果在循环前后还有处理，或者需要对数组做筛选就必须用这个了。
ISharedComponentData
这个不是个底层相关特性，却是个很有趣的东西。
与普通的IComponentData不同，虽然都是struct，如果你先初始化它的值再给每个Entity用AddSharedComponent附加上它的话，并不会产生复制，只会占用一块内存（估计传过去的是地址）
只是读取很正常，但当你修改某个Entity上它的副本的时候，它会把自己立即复制一份，然后应用这个修改。
这玩意儿很类似PSS或者WindowDLL共享内存的做法，充分体现了“这是一个性能框架”的特征。
不过认真一想……
这东西不就是shareMaterial和material的关系么……
至于这个ECS框架本身……
其实还是很传统的。Entitiy实际上是一个int，ComponentData也就是普通的struct，System则是各种系统事件的接受者，类似MonoBehaviour。他们都只要实现对应的接口就能实现功能。在用EnitityManager创建Entity，添加Component之后（和原来的GameObject一样），System逻辑就会自动生效。
System的逻辑实现，是在特定的事件上（如OnUpdate）用自定义的代码拉取一些Component数组来执行自己的逻辑，主要用的就是GetEntities<Group>方法，这会按Group的内容，拉取指定的Component数组出来，然后遍历就可以了。
（注意拉取的是整个场景上同类型的所有Component，而不是一个）
拉取的时候会进行筛选，没有添加指定Component的Entitiy并不会被拉取（除此之外，还可以用ComponentGroup设置筛选条件）
总之就是每个System手动遍历一遍指定的Component执行逻辑了——但也可以不遍历，或者遍历多次，两两交叉遍历都是可以的，因为全都是自定义代码，就算是JobComponentSystem也一样。不要被上面的Job的简单例子误导，用IJob就可以在Jobs里写任意逻辑了，并不需要一定按循环走。
所以，System其实就是MonoBehaviour（删除数据后）的集合体，MonoBehaviour执行一个Entity的逻辑，而System执行全部的。
class RotatorSystem : ComponentSystem
{
struct Group
{
RotateComponentData rotation;
SpeedComponentData speed;
}
override protected OnUpdate()
{
float deltaTime = Time.deltaTime;
foreach (var e in GetEntities<Group>())
{
e.rotation *= Quaternion.AxisAngle(e.speed * deltaTime, Vector3.up);
}
}}
执行顺序
然后有心人就会意识到，MonoBehaviour执行顺序不确定的问题在这里依然存在……
虽然并发的系统本来就希望允许乱序执行嘛，系统还是给了方法确定顺序的，只要在System上加元标签就行了：
[UpdateBefore(typeof(RotationSpeedSystem))]
觉得可以乱序执行的部分不加就是了，在使用Jobs的时候不限制顺序才能增加性能。
对GameObject系统的支持
ECS和原有的GameObject+MonoBehaviour功能其实并没有完全重合。至少在现在，Transfrom，Renderer和物理组件依然必须挂接在GameObject上，并且不挂在GameObject上也无法在场景里编辑。
Entity本来是用EntityManager.CreateEntity()来创建，然后这样进行复制的（非必须）
EntityManager.Instantiate(entity, instances);
但是如果你把上面参数里的entity换成一个Prefab对象的话，它也能正常执行，并和GameObject.Instantiate一样生成一个可显示的GameObject对象，并且照常生成对应的entity。这些生成的entity就是和GameObject绑定的存在了，也就把GameObject引入了ECS系统。
对于引入ECS的GameObject，不管是GameObject还是上面的组件都可以和ComponentData一样管理。
虽然Renderer之类必须得是Behaviour组件，但是一些挂载在GameObject用来填写数据的脚本，我们显然还是希望它们进入系统用的是ComponentData，而不是旧版的MonoBehaviour。
另外，我们的ComponentData也是需要能够在编辑器环境显示以及编辑的，而ComponentData并不能挂在GameObject上。
这个框架提供了一个桥接类来处理这个问题：
[Serializable]
public struct Radius : IComponentData
{
public float radius;
}
public class RadiusComponent : ComponentDataWrapper<Radius> { } 下面那个RadiusComponent 是可以正常挂到脚本上的。而在ECS系统内，它则会被处理隐式地处理成Radius。
依赖注入
使用[Inject]标签，可以根据字段类型自动注入一些数据。
public struct Group
{
//获得某个类型的ComponentData
public ComponentDataArray<Position> Position;
//获得某个类型的Component（这里的Component指的是原本的Unity组件）
public ComponentArray<Rigidbody> Rigidbodies;
//获得Entity列表
public EntityArray Entities;
//获得GameObject列表
public GameObjectArray GameObjects;
//标识排除所有包含MeshCollider的对象
public SubtractiveComponent<MeshCollider> MeshColliders;
//数据数量
public int Length;}
[Inject]Group m_Group;
和之前GetEntities<Group>不同，这次的Group的不会返回迭代器，所以Group里的字段本身就必须是数组。但依然会进行筛选，并且按Entity顺序排列。
[Inject]OtherSystem m_SomeOtherSystem;
用这个方法可以直接和另一个System通信。这个框架并没有提供任何和解耦相关的东西，所以System间通信都是直接调用。
[Inject]ComponentDataFromEntity<LocalPosition> m_LocalPositions;
Entity myEntity = ...;
var position = m_LocalPositions[myEntity];
这个东西看上去和GetEntities<Group>差不多（除了只能获得一个Component外)，但其实功能完全不同。GetEntities会做筛选，而它不会。
但为啥不直接用EntityManager.GetComponentData<LocalPosition>(myEntity)就不了解了，可能是性能问题吧。
EntityCommandBuffer
写过物体管理系统的都会遇到“遍历中增删对象”这个麻烦的问题。虽然确实可以用倒序遍历处理，但其实这样很不稳定，而且很可能出现删除未遍历到的对象这个问题，然后产生非必现错误。
通常的做法就是将所有这些操作延后执行。
这个框架里虽然没有这个问题，但是在多线程的时候，增删对象依然会产生较大的数据变动，这容易对同时运行的其他线程产生阻塞，就依然需要进行延后处理。
可以在一个调用次数靠后的System（SystemA）调用CreateCommandBuffer()创建EntityCommandBuffer对象，然后把它的实例传给其他需要增删对象的System（SystemB），调用这个实例的函数来负责增删。
这样增删操作会延迟到SystemA时才执行。
由于系统会特地将增删操作向后延迟，所以SystemA不做任何处理就会是最后一个执行的System，像示例里那样，用一个空System当这个SystemA也是可以的。
RemoveDeadSystem.cs
对方的文档也不全，先这样吧。
其实这次除了ECS，Jobs的部分存在感也极强。你们可以看看下面这个是啥玩意儿……
NativeCounter.csgithub.com图标
另外这个玩意儿什么时候加进来的？
using System;
using System.Runtime.CompilerServices;
using UnityEngine.Collections;
namespace UnityEngine
{
internal static class UnsafeUtility
{
public unsafe static void CopyPtrToStructure<T>(IntPtr ptr, out T output) where T : struct
{
output = *ptr;
}
public unsafe static void CopyStructureToPtr<T>(ref T output, IntPtr ptr) where T : struct
{
*ptr = output;
}
public unsafe static T ReadArrayElement<T>(IntPtr source, int index)
{
return *(source + (IntPtr)index);
}
public unsafe static void WriteArrayElement<T>(IntPtr destination, int index, T value)
{
*(destination + (IntPtr)index) = value;
}
public static IntPtr AddressOf<T>(ref T output) where T : struct
{
return ref output;
}
public static int SizeOf<T>() where T : struct
{
return UnsafeUtility.SizeOfStruct(typeof(T));
}
public static int AlignOf<T>() where T : struct
{
return 4;
}
[MethodImpl(MethodImplOptions.InternalCall)]
public static extern IntPtr Malloc(int size, int alignment, Allocator label);
[MethodImpl(MethodImplOptions.InternalCall)]
public static extern void Free(IntPtr memory, Allocator label);
[MethodImpl(MethodImplOptions.InternalCall)]
public static extern void MemCpy(IntPtr destination, IntPtr source, int size);
[MethodImpl(MethodImplOptions.InternalCall)]
public static extern int SizeOfStruct(Type type);
[MethodImpl(MethodImplOptions.InternalCall)]
public static extern void LogError(string msg, string filename, int linenumber);
}}
ps.其实个人认为ECS框架以后会慢慢和传统的MVC架构等这种注重继承的游戏框架结合并且这种可能性是很大的。一个是随着网络数据交互量的增加（主要由于网速加快，网络资费便宜），二呢是因为随着游戏的创新发展更多的玩法功能将被实现出来，所以游戏设计不在是传统的功能设计，对功能的要求更多的是想搭乐高一样的实现。三呢现在游戏中具体的业务逻辑实现确实需要一套框架来进行规范。