0A屏幕管理机制.doc

MTK History机制深入分析1．10A的屏幕架构10A中的屏幕管理，不再像以前那样简单的管理一个数组，出栈入栈，而是维护一个树，如下图：这个是总的屏幕集合的一部分，基本上是主菜单一个应用有自己的一个总的group（也不排除特殊情况，比如设置菜单），在这个group下有许多子group（就好像一个菜单中有很多子菜单），子group中又会有用来显示的screen以及其它的group，依次类推，不过最底部（叶子节点）一定会是个screen，用作显示。以前的EntryNewScreen是一个入栈的过程，现在的进入新屏，就需要创建新的group连接到已有的父group的子group中的尾部，然后再以新建的group为父节点创建screen用作显示，当然这其中也会处理前一个group，也就是保存历史的操作。进屏之后返屏，可以想象返屏就会移除父group的子group中的tail的group并释放在其申请的内存，接着激活其前一个节点（可能是group，可能是screen），tail的group就会是激活的节点。具体的进\出屏幕会在下文详细介绍。2．进屏流程由于10A中也会用到原来的EntryNewScreen进屏，也会有直接创建screen进屏等多种方式进屏，我在这就只列出一个比较具有象征性的进屏方式。因为现在进屏比较复杂我就大体例举其调用的主要的几个函数以及他的作用。mmi_frm_group_create (MMI_ID parent_id, MMI_ID group_id, mmi_proc_func proc, void *user_data)，看到这个我想都会知道是创建一个group，它的父ID，ID等系列属性也会根据参数来赋值，值得一提的是group是动态申请内存的方式创建，还有在创建的时候，不会把新节点加到父节点的子节点的尾部。而是先加到shell.scenario_dangle这个节点下。创建好group后，就会进入group，mmi_frm_group_enter (MMI_ID group_id, mmi_group_enter_flag flag)进入新的group，注意在这里他又会调用add_node这个函数把group加入到他的父级group下，加到尾部，同时会用remove_node()这个函数来remove掉shell.scenario_dangle下对应节点，（有点没懂为什么在新建的时候会add到shell.scenario_dangle这个节点后，又在紧跟着的entry group中remove掉这个节点，是为了防止在第一次creategroup之后没有调用entry gourp么？期待高手解答）这步就是加链表的操作了。接着就是用这个函数group_active(group_node_struct *node, mmi_scenario_evt_struct* evt)，这个函数会对该node的父级group做判断：只有在父级group为shell.scenario_root，才会调用mmi_frm_entry_new_screen()，这个又是我们熟知的进屏函数了，我不再这一一介绍，只说一些不同的操作，他不单利用historyData这个结构体来保存上一个屏幕的信息，也会记录新进的屏幕的信息，还有在记录上一个屏幕信息的时候不再用mmi_frm_add_history这个函数来申请内存保存上一个屏幕控件的历史信息。接着会inactive其前一个节点。调用group_inactive或者scrn_inactive。group_inactive会调用scrn_inactive来inactive其节点下的（包括本身节点）节点。那么得分析下scrn_inactive，这里会调用该node所记录的退出函数，根据进入函数来调用scrn_add_history(scrn_node_struct *node)来保存历史，这个改良了53的保存控件历史的函数，它统一了各个所有控件的保存方式，不再是像以前那样对特殊模板独立保存方式。这里同样会申请内存来保存控件信息，不过它会根据控件的size大小来申请内存，而且都是保存在node这个结构体中，同样也可以在退出函数中作保存历史的操作。以上几步是把上个屏幕的信息保存下来了，现在要做的是对新的group的操作了。现在要做的就是对新group的操作。这个就要关注下post_scenario_evt(MMI_ID group_id, U32 scrn_id, post_scenario_act_enum act, mmi_scenario_evt_struct *evt, U32 type)这个函数会把参数中的写到post_queue这个结构体队列中，然后调用scenario_pro