上下文 Context
Context是一种为Entity服务的的管理性数据结构。一个Entity不能自己独立创建，它必须通过context.CreateEntity（）创建。通过这种方式，Context可以管理我们创建的所有Entity的生命周期。它也是第一个在我们操作Entity时得到通知的观察者（请参阅Entity章节中的Entity观察（Entity observation ）部分）。
Entity对象池
为了避免GC，Entitas-CSharp中的Context具有内部对象池机制。当用户创建一个新的Entity时，对象池将使用先前被销毁而存储起来的Entity。这种方式堆上的内存得到回收。一个Entity只有在我们确信没有任何地方引用到的时候才会被回收。这就是Entitas-CSharp具有内部引用计数（internal reference count）机制的原因。如果您仅使用Entitas来记录，并且不存在任何自己存储的引用，则不必考虑它。内部类已经为您处理了所有引用的计数。但是，如果你想创建一个Component，如：
class Neighbour: IComponent {
public IEntity reference;
}
或者拥有一个MonoBehaviour储存了Entity的引用：
class EntityLink : MonoBehaviour {
IEntity _entity;
}
如果这样的话，你需要调用_entity.Retain（this）;来储存一个引用。当你不再需要这个Entity、或者Entity被销毁的时候，你要记得调用_entity.Release（this）;。如果你忘记调用Release，一个被销毁的Entity将被永久保留在内存中并且不会被重用。非常容易导致内存泄漏，这在Entitas Visual Debugger中很容易观察得到。如果你忘记调用Retain，你可能会得到一个Entity的转世版本（reincarnated version）。这将导致非常难以调试，并且非常奇怪的行为。
顺便说一句，我们不鼓励那些Component里面引用另一个Entity，更偏向的是使用Entity Index 的Component（参见索引（Index）章节）。而EntityLink现在是Entitas.Unity插件的一部分，所以如果你只需要引用GameObject上的Entity，不必担心，有我们呢。
多个Context类型
如果我们将一个典型的关系数据库（基于表结构的）与Entitas进行比较，我们可以得出以下联系。一个Component是一个列（column），一个Entity是一个行（row），Context（context）是一个表（table）本身。现在在关系数据库中，一个表是根据结构（scheme）来定的。在Entitas中，它基于实现IComponent的类。这意味着当我们定义更多的Component类时，我们表的表头就变得更广泛。对于不同的实现细节，对内存消耗会有不同的影响。对Entitas-CSharp来说，它对内存消耗的确有一定的影响，因为一个Entity就是一个IComponent的数组。
为了解决日益增长的表格大小问题，我们可以引入另一个表格。
这里是Entitas-Csharp Wiki的一个片段：
using Entitas;
using Entitas.CodeGenerator;
[Game, UI]
public class SceneComponent : IComponent
{
public Scene Value;
}
[Game]
public class Bullet
{
// Since it doesn't derive from 'IComponent'
// it will be generated as 'BulletComponent'
}
[Meta]
public struct EditorOnlyVisual
{
public bool ShowInMode;
public EditorOnlyVisual(bool show) {
this.ShowInMode = show;
}
}
Component类声明之上的属性告诉代码生成器我们想要拥有哪些Context类型。在这个特定的例子中，我们有一个Game，Meta和UIContext。正如你看到的SceneComponent一样，一个Component可以是多个Context的一部分。这样做的意义是，如果我们想要用关系型数据库（realtional database）的模型来解释的话，则表Game和表UI都应该要可以有Scene列。
我应该建立多少种Context类型呢？
这真的取决于你的应用场景。如果你有一个相当小/简单的游戏，你可以只使用一个Context，这种方式更简单。您需要记住的是一个Entity是由一个Icomponent数组构成的，它是一个指针数组。指针在64bit的系统结构的大小为8个bytes。所以如果你有50个Component，每个Component的大小至少为400bytes。如果您的游戏中有100个Entity，则它们占用40KB。40KB是否很多的消耗全由你自己判断，如果您有数百个Component和数千个Entity，最好开始分片管理。
有时即使是为了更好的组织，将Component分成不同的Context也是非常有好处的。您可能有些只用在游戏核心逻辑中的Component，或者只是与元游戏（meta game指monobehavior一类）相关的Component。如果确定Component间没有重叠，不存在既需要存储ComponentA和又要存储ComponentZ的Entity。那么最好将他们放在不同的表（tables）中。
Context的观察（Context Observation）
与Entity相同，Context的改变也是可以观察的。这也是我们在内部功能组（Group 本章将会介绍）和可视化调试器（visual debugger）中使用的事件。
如果您想为Entitas编写一些工具，例如自定义记录（Logging）或分析（Profilling）、您可以使用以下事件：
- OnEntityCreated
- OnEntityWillBeDestroyed
- OnEntityDestroyed
- OnGroupCreated
