zoukankan      html  css  js  c++  java
  • cocos2dx 中触摸事件分发一些解读

    触摸事件分发中几个代码解读:

          怎么说呢,感觉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属性,可能会导致重叠精灵会被一起拖动--已证明

  • 相关阅读:
    VC++使用socket进行TCP、UDP通信实例总结
    [Android Pro] 调用系统相机和图库,裁剪图片
    [Android Pro] 查看 keystore文件的签名信息 和 检查apk文件中的签名信息
    [Android 新特性] 谷歌发布Android Studio开发工具1.0正式版(组图) 2014-12-09 09:35:40
    [Android 新特性] 有史来最大改变 Android 5.0十大新特性
    [Android Pro] service中显示一个dialog 或者通过windowmanage显示view
    [Android Pro] 通过Android trace文件分析死锁ANR
    [Android Memory] Android 的 StrictMode
    [Android Memory] Android性能测试小工具Emmagee
    [Android Memory] Android内存管理、监测剖析
  • 原文地址:https://www.cnblogs.com/boliu/p/3402172.html
Copyright © 2011-2022 走看看