[Kuix][转]Kuix的事件处理机制

原文连接

kuix这个项目的功能非常强大，把css和xml在j2me上几乎做到了极致。同时它的事件处理也相当的复杂，好坏与否暂且不说，基于kuix在css和xml模块设计上的造诣，想来事件处理设计的这么复杂也是有些道理的，在此分析一二，方便大家理解。

先插一个图，是kuix官网上的图，图画的相当的精美，使我看了之后有很大的学习画图的冲动，暂时忍住了，过一段时间一定得好好补上，不多说了，见图：

首先kuix并没有在回调Canvas的系统主线程中处理事件，而是采取了将事件记录下来 ，使用工作线程 处理和分发事件的方法。在KuixCanvas的回调函数keyPressed(), keyReleased(),KeyRepeated()等函数中使用了如下的代码：

processKeyEvent(KuixConstants.KEY_PRESSED_EVENT_TYPE, keyCode);

processKeyEvent(KuixConstants.KEY_RELEASED_EVENT_TYPE, keyCode);

processKeyEvent(KuixConstants.KEY_REPEATED_EVENT_TYPE, keyCode);

将事件记录在了一个Vector中，pointer事件也是一样。

而处理事件的工作线程会在KuixMIDlet初始化的时候开始运行，严格来说，这个线程并非只为处理事件而存在，它是一个后台工作线程，维持了一个工作任务列表，它会处理其中每一个任务。而在KuixCanvas初始化的时候，就把事件处理任务丢进去了，并且这个任务的run()函数的返回值是false，也就是说这个任务在运行结束后并不会从任务列表中删除，换句话说，这个任务会被工作线程一次又一次的循环执行。

接下来，我们详细分析这个在程序初始化时加入工作线程的事件处理任务：

该任务每次运行时，会处理keyEvents和pointerEvents列表里面的所有事件。具体的事件处理逻辑，由Desktop的当前focusManager 代理完成，因此focusManger实际上或许叫做eventManger更合适一些。

每一个widget都可以有一个focusManager（也可以没有），在Desktop中，包含了一个当前screen对象，和若干个(也许0个)popup的widget。如果存在popup的widget，并且其中有widget设定了focusManager，那么就以最顶层的popup的widget的focusManager对象为Desktop的currentFocusManager，如果没有popup，则返回screen的focusManager对象。

这个逻辑说起来有点绕，实际上符合我们使用窗口系统的习惯，一个应用程序有一个主窗口，然后可能在其上弹出若干个对话框之类的弹出窗口，有弹出窗口的时候，窗口焦点就从主窗口改变到最后一个弹出的窗口上了，所有的用户输入和事件也都发给这个窗口，kuix的Desktop类的这个设计正是如此。

决定了focusManager这个事件处理器，我们再来仔细分析一下它是如何处理事件的：

处理KeyEvent 的时候，focusManager实际上有三个逻辑：

1. 调用当前焦点控件的keyEvent处理；
2. 快捷键处理；
3. 默认的上下左右键的处理（当然就是移动焦点了）；

其中2和3是互斥的，也就是如果这个key被某个控件绑定成了快捷键的话，就不再进行默认的移动焦点的处理了。在1中，基类Widget什么都没做，而如果当前焦点控件是一个ActionWidget的话，事情又会变得有意思一些，这个类型的控件，是一类响应fire键的keyPressed()事件和pointerReleased()事件的控件，换句话说就是响应”确定”这一用户行为的控件。

响应的机制也就是类似command机制，看这个例子：

<button action=”foo(a,b)”>foo</button>

没错，kuix的action是支持参数的，其次，kuix的action机制并没有一个全局的actionlist统一查找，而是分散在一个一个Frame中。这里出现了我们没有提到的Frame对象，熟悉MVC的话，一句话，Frame就是C，Screen是V，还有一个叫做DataProvider的对象是M。原则上一个screen对应一个frame，一般来说一个app不止一个screen，也就有多个frame对象，有一个FrameHandler对象维护了Frame对象的链表，action查找时，从表头开始，如果当前frame没有定义这个action，那么再去下一个fame对象中查找。

需要补充说明的就是左右软件的处理，左右软件当然可以通过绑定快捷键的方式将它们绑定到对应的Menu对象。但，由于这个绑定是Screen对象的一个普遍的行为，因此，kuix直接重载了默认的focusManager的processKeyEvent()，用硬编码的方式将这两个键与menu关联了起来。

处理PointerEvent 的逻辑相对简单，就是找到对应坐标下的widget，然后调用widget的事件处理。对于ActionWidget的pointerReleased()事件，我们上面提过了，就是执行action逻辑。值得一提的是Pointer事件是向父容器传递的。最后，Kuix的Pointer事件支持Drag & Drop功能，这个待以后补充吧。