触摸事件分发中几个代码解读：
怎么说呢，感觉cocos2dx中的消息分发机制，相对于android中触摸事件分发机制要简单的多。因为android中要做区域判断，过滤器，以及父子组件分发给谁等等的逻辑..
cocos2dx 中相对就要简单多了。
如果有一个组件如果想要接收触摸事件，会通过一个继承一个CCTouchDelegate接口注册给CCTouchDispatcher
CCTouchDispatcher 中维护了一个CCTouchHandler的队列。CCTouchHandler 是CCTouchDelegate两个派生类的包装类。
在接到触摸事件之后，遍历 所维护的CCTouchHandler 队列，并按触摸事件类型，调用对应的方法，CCTouchDelegate 接到回调后，再来进行逻辑处理
而 CCTouchDispatcher 实现了一个 EGLTouchDelegate接口。CCDirector会把这个接口以CCEGLView::setTouchDelegate(CCTouchDispatcher)方式注册到CCEGLViewProtocol里，而这个类针对支持的平台都有适配，然后平台会把相应的事件分发下来。
先来看CCTouchDelegate注册事件解除注册两个方法（Standard方式和Target方式类似，只说一种）
注册回调接口
void CCTouchDispatcher::addStandardDelegate(CCTouchDelegate *pDelegate, int nPriority) { CCTouchHandler *pHandler = CCStandardTouchHandler::handlerWithDelegate(pDelegate, nPriority); if (! m_bLocked) { forceAddHandler(pHandler, m_pStandardHandlers); } else { if (ccCArrayContainsValue(m_pHandlersToRemove, pDelegate)) { ccCArrayRemoveValue(m_pHandlersToRemove, pDelegate); return; } m_pHandlersToAdd->addObject(pHandler); m_bToAdd = true; } }
移除回调接口
void CCTouchDispatcher::removeDelegate(CCTouchDelegate *pDelegate) { ... if (! m_bLocked) { forceRemoveDelegate(pDelegate); } else { CCTouchHandler *pHandler = findHandler(m_pHandlersToAdd, pDelegate); if (pHandler) { m_pHandlersToAdd->removeObject(pHandler); return; } ccCArrayAppendValue(m_pHandlersToRemove, pDelegate); m_bToRemove = true; } }
先说为什么要加入一个m_bLocked， m_pHandlersToRemove，m_pHandlersToAdd 而不是直接放入m_pStandardHandlers中。
触摸消息的分发是在CCTouchDispatcher::touches方法中实现的
touches方法中，消息的分发是通过 CCARRAY_FOREACH(m_pStandardHandlers,pObj)这样的方式来遍历m_pStandardHandlers的，来依次判断是否需要把触摸事件分发到对应的胡回调接口中。
假设没有做阻塞标识符m_blocked，如果在移除接口的方法调用的时候，恰好正在遍历这个队列，这个时候直接从m_pStandardHandlers移除对象，
很可能会破坏队列结构，很可能会导致脚标越界的异常（就是常说的队列安全）。
所以就需要一个缓存队列缓存add和remove操作，在遍历结束后，把缓存队列中的接口移除或者添加进m_pStandardHandlers中。
另外forceAddHandler（），forceRemoveDelegate 这些方法顾名思义，就是什么也不用管了，直接添加或移除。这个两个方法调用之前，都做了 !m_blocked 判断。
touches 方法解读：
首先将阻塞标识位m_bLocked设置为true，防止外部直接改变 m_pTargetedHandlers 队列
m_bLocked = true;
之后 判断了这次分发触摸事件是否是两中处理方式都要做。
unsigned int uTargetedHandlersCount = m_pTargetedHandlers->count(); unsigned int uStandardHandlersCount = m_pStandardHandlers->count(); bool bNeedsMutableSet = (uTargetedHandlersCount && uStandardHandlersCount); pMutableTouches = (bNeedsMutableSet ? pTouches->mutableCopy() : pTouches);//这里为什么要复制一个队列出来，会下边解释
然后进入Target处理方式的逻辑。这个顺序表明Target的处理优先级要比Standard要高
Target处理循环(代码又删减)
for (setIter = pTouches->begin(); setIter != pTouches->end(); ++setIter) { .... CCARRAY_FOREACH(m_pTargetedHandlers, pObj)//遍历m_pTargetedHandlers， { pHandler = (CCTargetedTouchHandler *)(pObj); bool bClaimed = false; if (uIndex == CCTOUCHBEGAN) { bClaimed = pHandler->getDelegate()->ccTouchBegan(pTouch, pEvent);// 标记1 if (bClaimed) { pHandler->getClaimedTouches()->addObject(pTouch); } } else if (pHandler->getClaimedTouches()->containsObject(pTouch))//标记2 { // moved ended canceled bClaimed = true; ..... pHandler->getClaimedTouches()->removeObject(pTouch); break; } if (bClaimed && pHandler->isSwallowsTouches())//标记3 { if (bNeedsMutableSet) { pMutableTouches->removeObject(pTouch); } break;//标记4 } } } }
对应标记解释
标记1:
如果继承的是CCTargetedTouchDelegate 接口，began回调的返回值至关重要，只有返回true的时候，会把当前CCTouch放入CCTargetedTouchDelegate对应包装类的触摸事件集合 中。
标记2：
当只有在标记1中触摸事件返回值为true 的情况，才会分发后续事件。
估计有人看到这里会疑惑，当CCTouch 是began时候放入包装类中。如果触摸事件已经是变化成了MOVE 或者 END时候已经是第二次调用touchs方法了，为什么却使用pHandler->getClaimedTouches()->containsObject(pTouch)这样的方式判断的？
事实上，经过测试发现，当一个触摸事件生成之后，从began,到end和cancle，都是同一个对象。
另外，经过测试，这些CCTouch对象是通过多个固定对象来缓存的，而不是每次有触摸就创建一个新对象。多次触摸事件测试结果显示，单点触摸情况下大约有四个左右（）的缓存对象
标记3：
这个地方的代码非常的巧妙..
如果这个CCTouch已经有一个CCTargetedTouchDelegate的对他处理，且这个CCTargetedTouchDelegate的状态又是isSwallowsTouches==true,即注册监听的时候调用方法addTargetedDelegate(CCTouchDelegate *pDelegate, int nPriority, bool bSwallowsTouches)时，第三个参数为true，则不再把这个CCTouch分发给这个组件之后的其他组件。当然，优先级比他高的就没办法屏蔽了。
其中这个“不分发给其他组件”有两个逻辑处理
1、标记4处的break ，就是当这bSwallowsTouches为true情况。会退出这个CCTouch处理逻辑中的CCARRAY_FOREACH(m_pTargetedHandlers, pObj) 循环，保证了这组件之后的CCTargetedTouchDelegate 都不会接受到这个CCTouch事件
2、如果是有CCStandardTouchDelegate要处理(bNeedsMutableSet==true)的情况，则把这个CCTouch从事件集合中移除，来保证Standard方式的组件不会接收到这个CCTouch事件。同样的原因，因为对CCTargetedTouchDelegate的处理是在对CCSet*pTouches遍历中做的，直接从pTouches中移除又会破坏队列结构，所以有了上边说到的pMutableTouches=pTouches->mutableCopy() 的copy操作
再来看这么写的原因
bool bNeedsMutableSet = (uTargetedHandlersCount && uStandardHandlersCount); pMutableTouches = (bNeedsMutableSet ? pTouches->mutableCopy() : pTouches);
bNeedsMutableSet = uTargetedHandlersCount && uStandardHandlersCount
bNeedsMutableSet = true&&true 就是标记3解释的地方说到的情况是
bNeedsMutableSet = true&&false 的情况，没有Standard 类型处理方式 需要处理，也就没必要屏蔽这个事件，所以没有copy
bNeedsMutableSet = false&&true 这种情况没有Target的处理，则也不会出现Swallows 为true需要屏蔽的情况，也就不会有移除操作，不用copy
bNeedsMutableSet = false&&false 这种情况什么处理也不做，也不需要copy
这就是为什么 bNeedsMutableSet==true 的情况需要copy操作了
standard的处理循环
CCARRAY_FOREACH(m_pStandardHandlers, pObj) { pHandler = (CCStandardTouchHandler*)(pObj); switch (sHelper.m_type) { case CCTOUCHBEGAN: pHandler->getDelegate()->ccTouchesBegan(pMutableTouches, pEvent); break; ........ } }
从代码可看出，Standard 消息处理方式更简单，什么也不管，直接遍历所有注册过的组件，然后事件集合全部发下去，让组件自己处理。
处理完Standard之后，会将阻塞标记m_blocked设置为false，然后组件开始检查add和remove队列。
并且可以发现，Target处理方式并不是不接受多点触摸，只不过是把多点触摸拆开分发下去的。而Standard是把多点触摸的消息一起发现去的。且分发过程中，是没有做区域判断的。并且，Standard处理方式ccTouchesBegan,move,end等方法的返回值是true或false都没影响
//待证明的假设
1、这边就假设一个场景，一个精灵注册的是Target的方式，并且随着触摸位置来更新精灵的位置。
如果只是拿到了CCTouch 就直接更新精灵的位置，可能会导致两个手指一起按住精灵拖动，因为CCSet *pTouches多次分发下去的，可能会导致精灵在两个手指之间跳动。但是因为这个分发过程是在一个循环中直接分发完成，两个指头触摸事件顺序是不变的，界面都没有来的及重绘，而直接到了最后那个触摸事件的位置上。
2、还是1中的设定，如果在注册监听的时候，所有精灵都没有设置m_bSwallowsTouches属性，可能会导致重叠精灵会被一起拖动--已证明