MTK10A 小记

最近因为要使用6276的代码，故此比较仔细的研究了一下其窗口机制。当前我看到的代码版本是10A。10A的窗口机制采用了一种比较新颖的方式，就是采用树形结构来管理窗口，同时还引入了分组概念。从整体架构看来，更接近于MVC模式了。以前09A之前的代码，都是基于单窗口的管理模式，所有的窗口都基于History 栈的管理，进入一个新窗口就把前一个窗口压入History 栈，待该窗口关闭后，又从该栈中出栈上一次存入的窗口，并显示。早期的这种机制，存在许许多多的问题，尤其是对于所谓的Application的概念比较模糊。按照目前来说，一个Application很多时候都会对应一系列的窗口，而不是一个窗口，故此再退出该Application的时候，应该是所有的窗口都退出才对。而早期的机制，因为是单窗口的管理方式，造成一个Application一个窗口的方式比较多，虽然也有一个Application对应多个窗口，但管理起来很不方便，关闭多窗口的Application就需要开发者自己记住开了多少个窗口。9A引入了新机制，10A做的稍微完善了一点，那就是分组机制。把属于一类的（其实叫做一类这样的称呼不是很合理，但暂且当成是同类吧，就是同属于一个Application的窗口吧）归属于一个组别，一个Application对应于一个大组别，大组别里面又包含多窗口或者是另外的含有多窗口的小组别。这样，当Application关闭的时候，只要关闭大组别，代码会自动的为开发者关闭所有属于此组别的窗口。而且，对于窗口的历史内容的保存，都是存储与自己的树节点上，不用History 栈了，调用起来更加方便，也引入更少的错误。采用新的机制后，目前的代码更具有MVC风格了。虽然引入了新机制，但不能不说，MTK的10A还是一个不友好的代码，因为其为了兼容早期的单窗口机制，让两套机制共存，为此还专门为新机制引入一个适配的代码来适应旧机制，强硬的把新机制的窗口也纳入History栈的管理之中来，造成开发者在阅读代码时候，非常的痛苦。

新机制中，组别成为Group，窗口成为Scrn（还有Tab的概念，因为研究暂时没有涉及，所以后续补上）。

全局有4种树，一个是Scenario，一个是Service，一个是Background，一个是Dangle。

其中，但凡直接挂在Scenario的组别，都必须自动纳入History栈管理，因为其可以看成是一个大Application的窗口组。Dangle这颗树很微妙，目前我只是看到其作为节点的临时挂靠点，具体别的作用，还需要慢慢发掘。目前Service， Background这两个在10A里还没完善，也 没看到使用实例。

一般的窗口进入方式为：

创建Group，然后Enter Group，然后Enter Scrn，后续需要在同一组别里打开其他窗口，则继续Enter Scrn，它会自动的让其上一个Scrn失效，焦点自动切换到当前Scrn上来。如果需要开启一个新组别，则重复前面的做法，就是创建Group，Enter Group，然后Enter Scrn。一个Group的结束，会首先从其最尾的孩子开始关闭Scrn或关闭Group（还记得Scrn与Group都是作为Group的一个孩子），这是一个迭代过程，最终会关闭该Group然后激活与其同一层的别的Group，并切换焦点至这个Group上，而且还是切换到其尾巴的Scrn上。

MTK10A的消息机制，对于任务来说，就只有一种，即通过OS的消息队列的投递。但对于MMI来说，却有多种。MMI的做法如下：

收到Protocol（对此，MTK对于Protocol来说，有点笼统，甚至把驱动部分都当成是Protocol，故此暂且可认为是底层消息或其他任务消息）消息后，会首先

把消息存放在一个环队列中，然后每次从队列中获取一个消息，执行相应的操作（此时则查看消息函数注册表，一般在代码初始化的时候，就会注册了）。

最后处理完毕Protocol消息后，则处理MMI自身的消息，也就是有MMI任务内发送给自身的消息，这些消息存放在一个list中，每次获取一个来处理，并删除该点。

对于MMI自身的消息，一般分为两种，一种该消息自身已经附带处理函数，另外一种则称为事件。在10A中，事件与函数对应表分为两种，一种叫做静态表，即在编译时期已经确定的对应关系，一般在头文件中有定义好。一种是动态表，即在程序运行时才临时注册的，事件的相应一般是先查询静态表，再查询动态表。

待续......