跟着Code走，详解Symbian UI程序框架（2）——程序结构进阶，窗口管理及事件分发

在  跟着Code走，详解Symbian UI程序框架（1）——UI程序结构   一文中，我们介绍了UI程序框架的组成及初始创建过程，我们已经清楚了程序的静态结构以及这个静态结构是怎样创建出来的。下面我们讨论，这个静态程序结构在动态执行过程中，是怎样运作的。首先我们更进一步的来了解下程序的静态结构，主要是程序关键组成部分CAknApplication、CAknDocument、CAknApplicationUi及CEikonEnv的派生关系，因为非常多的功能代码是在基类中实现的。下图是UI程序组成部分的继承关系及引用关系。看似比较复杂，等我们下面分析下之后，你也许不会觉得它多么复杂。如果你了解诸如Windows下MFC中的MVC架构，或者其他的MVC架构，你对上面的组件关系或许会有几分熟悉。

CXXXEnv类是整个程序的执行环境，程序执行过程是由它驱动的。CXXXApplication类实际并未起太大作用，它与CXXXDocument类共同完成文档管理的功能。CXXXDocument代表一个具体的文档对象，如果你的程序支持多文档，可能会创建其多个实例，如果你的程序支持多种类型的文档，可能会存在多个CEikDocument的派生类及实例。CEikProcess（CApaProcess的派生类，CEikonEnv的成员变量）是文档管理的关键，它负责实例化和管理CXXXApplication和CXXXDocument对象。CXXXUi类负责管理View及控件，事件分发过程主要在其中实现，其祖父类的成员变量CCoeViewManager和CCoeControlStack是窗口管理和事件分发组织的关键。

上一篇文章中，已经给出了初始化的具体过程，下面我们只是把各部分初始化的顺序列出来：

E32Main->EikStart::RunApplication->CEikonEnv->CEikProcess(CApaProcess的派生类)->CAknApplication->CAknDocument->CAknAppUi->CAknView

 

【控件管理及普通事件分发】

所有可显示的窗口都是CCoeControl的派生类。所有UI程序在创建后，如果要受程序框架管理（例如，接受系统的按键事件），都需要调用CAknAppUi::AddToStackL，把自己加入到CCoeControlStack中。事件处理完成后关闭，或者切换到其他控件之前，调用CAknAppUi::RemoveFromStack把自己从控件栈删除。

在上一篇文章中，我们已经提到，UI程序事件分发的起始点是CCoeEnv::RunL。该函数会从窗口服务器获得事件，然后调用CAknAppUi::HandleWsEventL分发事件，真正的分发动作在CCoeAppUi::HandleWsEventL中，下面是其一段代码。

228 EXPORT_C void CCoeAppUi::HandleWsEventL(const TWsEvent& aEvent,CCoeControl* aDestination)

229 {
230 TInt type=aEvent.Type();
231 switch (type)
232 {
233 case EEventKey:
234 case EEventKeyUp:
235 case EEventKeyDown:
236 if (iStack->OfferKeyL(*aEvent.Key(),(TEventCode)type)==EKeyWasNotConsumed)
237 HandleKeyEventL(*aEvent.Key(),(TEventCode)type);
238 break ;
239 case EEventPointer:
240 aDestination->ProcessPointerEventL(*aEvent.Pointer());

当收到按键事件时，会优先让iStack中最顶层的控件处理（在最顶层，就是最后加到iStack的，当然是当前显示在最前面的窗口）。因此对于按键事件，只有两个点可以处理事件：控件中对应的事件处理函数和CAknAppUi::HandleKeyEventL。（如果你熟悉Windows下MFC的程序框架，你会发现这里的按键事件分发要简单很多，没有那么多的事件处理点，没有那么长的事件处理路径）

当收到指针事件（触摸点击）时，调用aDestination的事件处理函数（aDestination是从窗口服务器获取Event时，同时拿到的控件指针，是指针事件所对应的控件窗口）。因此对于指针事件，只有指针位置对应的顶端显示控件才能处理。

 

【Command的产生及分发】

Command由菜单项产生，分发给一般是CAknAppUi类处理。Command分发过程的实现采用了Observer模式，即CAknAppUi类实现Command处理接口，并注册到菜单类作为Observer。菜单类收到系统的按键或触摸事件，生成对应菜单项的Command后，调用Observer的处理函数。以下是Command处理接口的定义代码。

class MEikCommandObserver 
    { 
public: 
    /** Processes user commands. 
    Derived classes must provide an implementation of this function which responds 
    to user commands appropriately based on a user-defined ID for the command. 
    @param aCommandId ID of the command to respond to. */ 
    virtual void ProcessCommandL(TInt aCommandId)=0;

关于CEikButtonGroupContainer创建时传入CAknAppUi作为Observer， 以及检测到事件产生Command并调用Observer.ProcessCommandL的过程，可以查看CEikButtonGroupContainer的实现文件，在/FCL/sf/mw/classicui/uifw/eikstd/coctlsrc/EIKBTGPC.CPP中。

 

【View管理】

Symbian下其实没有真正的可显示的View，View只是受View管理器管理的基本组件，它一般会包含一些可显示的控件。例如，CAknView其实并不是真正可显示的View，它只是用以实现View管理，是View对应控件的中间类，定义了一组支持View管理的接口。一般来说CAknView的派生类中会包含很多可显示的，派生自CCoeControl的控件。如果你需要使用系统的View管理功能，你可以基于CAknView来实现View。如果你使用Carbide C++向导生成程序，默认是使用这套View管理机制的。你可以完全不使用系统的View管理机制，自己通过代码通知控件的显示和隐藏（调用MakeVisiable）。

前面的结构图显示，CCoeAppUi有一个成员变量CCoeViewManager，它是实现View管理的类。成员变量CArrayPtrFlat iViewArray;用以保存所有注册过的View，每个View注册时需提供TVwsViewId（实际是AppId+ViewId），当需要对某个View进行操作，根据传入的ViewId可以找到对应的View，然后进行操作。至于对View的具体操作，例如ActiveView，最终会调用到View实现类的成员函数，成员函数调用MakeVisiable之类的函数让View显示出来。

稍微提一下，对于View的管理，UI程序框架还提供了一个View Server。它是一个进程内的Server，注册Server时，View的信息除了在CCoeViewManager中保存，还会通过Client/Server通信机制，注册到View Server。其他程序可以通过向View Server发送命令（传入目标View的AppId+ViewId），让某个程序显示某个View。View Server虽然是执行在进程内的Server，但是也是一个完整的Server，会在内核生成对应名字的Server对象，如果发现该Server已经存在就不会创建新的Server。程序向View Server注册View前，还需要实现CCoeViewObserver来处理View的操作，因为View Server并不能直接控制View的操作。View Server只是起到了操作中转的作用，其他程序请求Activate另外一个程序的View时，View Server只是通知对应目标程序的CCoeViewObserver，让其完成操作，View Server自己不能直接操作View（因为View Server在Server端，而View的实现代码在Client端）。

如果你仅仅需要实现程序内部View的管理（例如View切换操作），你完全可以不用到View Server。不过如果你使用默认的UI程序框架实现程序，就默认用到了View Server，因为CCoeAppUi中的CCoeViewManager默认完成了这些动作。

 

【总结UI程序框架的结构】

前面对于程序结构的描述，可能过于细节，下面是一个比较粗的框图。大体是用户代码一般通过调用Akn库实现代码，Akn库基于Eik库，Eik库基于cone库。这三个库的实现用到AppArc库和View Server。事实上，AppArc库和View Server不是必须的。AppArc提供了管理document的基础代码，另外实现了一个AppServer，你可以在这个Server上注册通知，检测程序的运行状态（例如退出事件），也可以列出系统中当前运行的程序列表等。View Server允许用户把自己的View注册到Server上，本程序或其他程序可以通过向View Server发送请求，对程序View进行操作。