API调用海关技术
作用：将所有screep操作预定义，在每个tick末尾全部执行。
意义：运算-调用分离，可以更直观的统计api的调用情况和运算的执行情况
这有点像海关一样，所有的货物都集中到一艘船上之后，这艘船才会发出。这个技术的源本是跨Tick执行任务衍生出来的，为了让跨Tick执行任务的框架具有低耦合性、高拓展性，将这个板块分离了出来。
实现效果
//MODEL就是你定义的海关，这里暂时用MODEL命名，你可以将它挂到global上以便于上下文的调用
//MODEL.intent(tick,gameObjectId,intentData);
intent(1098888,'c49nsb54snw616',{
handler:'harvest',
targetId:'46whwjj464sjwns'
});
那么，海关可在任意一刻收到该intent并记录，然后在游戏时间为tick时使用data中的数据对gameObjectId指定的对象调用data中定义的方法。
有同学常问，这样的intent的操作，怎么判断返回值呢？
这里有两个方案
- 回调式返回
- 状态模拟技术
回调式返回，顾名思义，就是在调用intent的入参末尾添加一个回调方法，到了执行该方法的时候，将返回值传递给回调方法，再去处理相关操作。
但这样做有个致命缺陷，它让跨tick执行任务的容错率大大降低，并且可能存在不停的内嵌调用。
在我认真分析了跨Tick执行任务框架的真正意义后，我发现这样做并不完善。但状态模拟技术在这上面的发挥就能相得益彰了。
既然是跨Tick执行任务，那么我们的API就不能变得只对一个Tick有效，于是我们抛弃了原来所有的原生API，将其重写，把API也直接提升到跨Tick的层次上。例如
原来的harvest方法变成某1Tick调用一次，剩下的Tick就会自动完成寻路和Harvest操作。
在最新的TickStream我们是这么做的
我们聚焦在Register上（目前最新版本将其更名为Registry），在TickStream我们不再需要调用API，更多的是去定义，定义一个房间，在房间里面定义一个Creep，在Creep上定义一个控制器，在控制器上定义和命名状态机和实现功能。例如定义一个为Harvest的状态，并用代码实现Creep如何进行Harvest。具体如何实现请看下面
Registry.event([{
name:'CreepNotFree',
event:EVENT_CREEP_NOT_FREE,
attach:ATTACH_CREEP,
call:function(creep){
creep.state.now.cancel();
},{
name:'UnexpectedCancel',
event:EVENT_CREEP_UNEXPECTED_CANCEL,
attach:ATTACH_CREEP,
call:function(creep){
let before = creep.state.get.before();
creep.state.now.set(before);
}
}]);
Registry.handler([{
name:'harvest',
behavior:function(creep,target){
//判断自己是否正在另一个进程中
if(creep.state.get.now()!='harvest'){
//如果creep之前已经有一个其他进程了，则发送事件到Event处理器
return Event.creep(EVENT_CREEP_NOT_FREE,creep);
}
//寻找路线
creep.state.now.set('moveTo',target);
//由于是跨Tick执行，你可以认为上面这一行代码执行完成后Creep一定在target旁边了
//harvest，这个harvest不是用户定义的，而是通过intent去调用了真实的api
creep.intent(Game.time,'harvest',target)
creep.state.now.done();
}
}]);
我们来分析一下这些代码是怎么运行的，首先我们要了解creep的状态栈。
状态栈
状态栈，表示了一个creep当前的状态调用链，这在跨Tick执行任务中至关重要。
如上文所述，我们给creep定义了一个harvest方法，harveat方法里面又通过
creep.state.now.set('moveTo',target)调用了moveTo方法(这个方法并没有写出来，因为比较复杂）。
那么实际上TickStream在执行过程中，这个Creep的状态栈是这样变化的
- at harvest
- at harvest at moveTo
- at harvest at moveTo at move
- at harveat at intent
你可以发现，moveTo这个方法在Harvest下面，表示moveTo这个行为是因为harvest引起的。
注意:harvest的behavior并不是每个tick都去执行，而是由TickStream框架驱动并缓存执行。只有当global清空后，或creep状态被重新定向后才会重新执行。
我们主要看harvest方法中的内容
这是第一部分
//判断自己是否正在另一个进程中
if(creep.state.get.now()!='harvest'){
//如果creep之前已经有一个其他进程了，则发送事件到Event处理器
return Event.creep(EVENT_CREEP_NOT_FREE,creep);
}
creep.state.get.now返回的是状态栈的栈底，因此只有creep的底栈处于harvest状态，这个behavior都能正常执行。
再看代码中的
//如果creep之前已经有一个其他进程了，则发送事件到Event处理器
return Event.creep(EVENT_CREEP_NOT_FREE,creep);
你可以在上面的Regiatry中找到对应的方法
function(creep){
creep.state.now.cancel();
}
这表示，如果creep当前的状态不是harvest，那么就取消当前的状态
在TickStream框架下，一个creep如果被其他Handler Cancel了，那么会状态会自动变成发起cancel的Handler对应的状态。
所以此时creep的状态变成了harvest
此时的状态栈
at harvest
继续往下
creep.state.now.set('moveTo',...);
此时creep的状态栈
at harvest at moveTo
在moveTo方法中，由tickstream，调用海关以及状态模拟技术，将未来几个tick的寻路
已经intent完成，并在每个tick结束后自动调用，并对状态栈进行压栈
此时状态栈
at harvest at moveTo at move
这个时候因为intent的存在，其他handler直到move的handler的执行结束后，对 at move进行出栈才能继续执行。所以这个时候其实所有handler方法都没有执行。
即使你删除代码creep也能继续跑。
直到move完成后，此时creep已经来到target旁边
此时的状态栈
at harvest at moveTo
moveTo随即也结束出栈
at harvest
这个时候可以执行harvest下面的intent调用api来真实的进行harvest了
执行完intent后使用
creep.state.now.doen()对harvest出栈
这个时候其他的handler才能对其进行操作，当然也可以被其他handler在中途取消。
由于我们在event当中添加了取消事件，即使被取消，也会被重新压栈执行。
好了。
讲原理可能会有点复杂，我表达能力可能不强，请各位敬请谅解。下次我会成体系的讲述TickStream的工作细节，当然你也可以借鉴完成自己的跨Tick框架
