MTK10A帮助文档总结.docx
- 文档编号:9549352
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:16
- 大小:220.83KB
MTK10A帮助文档总结.docx
《MTK10A帮助文档总结.docx》由会员分享,可在线阅读,更多相关《MTK10A帮助文档总结.docx(16页珍藏版)》请在冰豆网上搜索。
MTK10A帮助文档总结
MTK10A帮助文档
一.10AMMI主要新特征
1.新Event机制
API:
#defineMMI_FRM_SEND_EVENT(_evt,_proc,_user_data)\
mmi_frm_send_event((mmi_event_struct*)(_evt),(mmi_proc_func)(_proc),(void*)(_user_data))
#defineMMI_FRM_POST_EVENT(_evt,_proc,_user_data)\
mmi_frm_post_event((mmi_event_struct*)(_evt),(mmi_proc_func)(_proc),(void*)(_user_data))
mmi_frm_send_event=直接函数调用
mmi_frm_post_event发消息稍后调用(据MTK说是为了防止循环调用)
mmi_frm_invoke_post_event可以处理队列里的消息,这个mtk已经做好了在一些必要的地方调用
Event处理机制在MTK10Ammiframework代码中很重要,在后续特征中会有体现
2.Callback管理机制
10A中callback其实还是用event机制实现的
在mmi_cb_mgr_cfg.h中可以看到如何注册一个event的callback,也可以通过调用mmi_retmmi_frm_cb_reg_event(U16evt_id,mmi_proc_funccall_back,void*user_data)来注册,一个event可以注册多个callback,会依次调用,如果有需要截断后面的处理,则不能返回MMI_RET_OK
MTK新版本中已有的event数量已经非常多,也可以自己添加,需要在以后熟悉代码中慢慢熟悉已有的event的意义
此时的callbackevent和上面1中的event有些区别的,使用mmi_frm_cb_emit_post_event来发送,在mmi_frm_invoke_post_event中会判断然后和1中的event区别处理
3.ScreenGroup机制
见图形化文档
跟原来的screen机制并不能完全兼容,如需移植代码需要注意,独立的功能最好添加一个groupid,否则可以使用已有的groupid
4.CUI
CommonUI
5.添加XML方式描述MmiResource
可见代码:
phonebook.resMTK会解析*.res文件生成mmi_rp_{APP_NAME}_def.h
兼容以前的添加资源方式
6.新按键处理
staticvoidprocess_key_event_routing(mmi_frm_key_evt_struct*key_evt_p)
参考PRST_FRM_NewInputHandler.pdf
7.新屏幕刷新机制
MTK为了避免屏幕闪的问题,改在特定的时间刷新屏幕,如果需要马上刷新需要设置
mmi_frm_set_curr_scr_blt_mode(MMI_FRM_SCR_BLT_IMMEDIATE);(有些需要频繁刷新屏幕的应用需要)
8.怎样添加一个新应用
见文档PRST_FRM_HOW_TO_WRITE_APP_10A.pdf
二.MTKHistory机制深入分析
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进屏等多种方式进屏,我在这就只列出一个比较具有象征性的进屏方式。
因为现在进屏比较复杂我就大体例举其调用的主要的几个函数以及他的作用。
1)mmi_frm_group_create(MMI_IDparent_id,MMI_IDgroup_id,mmi_proc_funcproc,void*user_data),看到这个我想都会知道是创建一个group,它的父ID,ID等系列属性也会根据参数来赋值,值得一提的是group是动态申请内存的方式创建,还有在创建的时候,不会把新节点加到父节点的子节点的尾部。
而是先加到shell.scenario_dangle这个节点下。
2)创建好group后,就会进入group,mmi_frm_group_enter(MMI_IDgroup_id,mmi_group_enter_flagflag)进入新的group,注意在这里他又会调用add_node这个函数把group加入到他的父级group下,加到尾部,同时会用remove_node()这个函数来remove掉shell.scenario_dangle下对应节点,(有点没懂为什么在新建的时候会add到shell.scenario_dangle这个节点后,又在紧跟着的entrygroup中remove掉这个节点,是为了防止在第一次creategroup之后没有调用entrygourp么?
期待高手解答)这步就是加链表的操作了。
3)接着就是用这个函数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。
4)group_inactive会调用scrn_inactive来inactive其节点下的(包括本身节点)节点。
那么得分析下scrn_inactive,这里会调用该node所记录的退出函数,根据进入函数来调用scrn_add_history(scrn_node_struct*node)来保存历史,这个改良了53的保存控件历史的函数,它统一了各个所有控件的保存方式,不再是像以前那样对特殊模板独立保存方式。
这里同样会申请内存来保存控件信息,不过它会根据控件的size大小来申请内存,而且都是保存在node这个结构体中,同样也可以在退出函数中作保存历史的操作。
5)以上几步是把上个屏幕的信息保存下来了,现在要做的是对新的group的操作了。
现在要做的就是对新group的操作。
这个就要关注下post_scenario_evt(MMI_IDgroup_id,U32scrn_id,post_scenario_act_enumact,mmi_scenario_evt_struct*evt,U32type)这个函数会把参数中的写到post_queue这个结构体队列中,然后调用scenario_process_post_evt_ex(U32type)来读取队列执行相应写入的操作,比如激活新group就会调用group_post_active(group_node_struct*node,mmi_scenario_evt_struct*evt)这个函数用shell.active_group来记录进入的新node。
shell.active_scrn为NULL。
6)仅仅只有好像只是group的操作,那么screen的操作去哪了呢?
现在就是开始screen的步骤了,和group一样也会新建screen,同样也是申请内存,把screen加到新的group下,调用scrn_active激活screen,用shell.active_scrn记录新的screen。
这里主要还是介绍下两种进屏幕的方式mmi_frm_scrn_first_enter和mmi_frm_scrn_enter,这两者的区别就在于前者可以应用显示函数中应用参数(一般都是节点结构体中记录的数据)还有tab页的进入调用mmi_frm_scrn_tab_enter,和scrn一样最终页调用scrn_node_enter,具体流程类似。
(可以看一下mmi_phb_entry_op_option)
具体流程入下图所示(这只是一个比较标准的进屏,10A中也有直接申请Sreen进的,还有用原始的进屏方式等等)
3.返回屏幕
1)mmi_frm_group_close_ex(MMI_IDgroup_id,U32type)中会调用group_close,而该函数会先关闭该节点的孩子节点,也就是screen节点,而scrn_close()会scrn_inactive()screen节点后,在调用execute_node_deinit(base_node_struct*node,mmi_scenario_evt_struct*evt)把POST_EXECUTE_DEINIT的操作写进队列中,接着调用scenario_process_post_evt_ex读取队列中的操作执行execute_node_post_deinit来释放screen申请的内存。
这么一来原有的screen就不在了,对于group来说也会做类似的操作,同样是先inactive,再exit,最后deinit都会把操作写进队列,这样一来就结束了显示着的界面。
2)现在就是要看怎么实现返回的了,其实简单来说就是激活了被释放节点的前一个节点,如果该节点是group会激活该group下的screen,如果是screen就直接激活screen,调用screen节点所记录下的entry函数,实现了返回的效果。
注意,在被释放节点的父节点为shell.scenario_root时,在返回时会调用GobackHistory,来返回历史。
这个是我们熟知的方法,也就不在这一一介绍了。
具体流程如下图所示:
4.删除屏幕
其实删屏在返回屏幕中已经介绍了他的具体流程,这里就简单介绍些常用的几个删屏函数吧:
1)mmi_frm_group_close(MMI_IDgroup_id):
删除相应ID的group,删除group会连带删除该group下的所有子节点。
2)mmi_frm_scrn_close_active_id()顾名思义会删除激活状态下的screen
3)mmi_frm_scrn_close_ex(MMI_IDparent_id,MMI_IDscrn_id,scrn_close_type_enumflag)删除指定ID的screen。
4)mmi_frm_scrn_multiple_close(MMI_IDparent_id,MMI_IDstart_scrn_id,U8b_inc_start,U16count,MMI_IDend_scrn_id,U8b_inc_end)这个类似53平台上的DeleteHistoryInt(),用来删除多个屏幕。
注意:
如果被删的节点的父节点,只有一个子节点(也就是被删的节点),那么同样会删除该节点的父节点。
5.插入节点
1)mmi_frm_group_insert(MMI_IDparent_id,MMI_IDbase_id,mmi_frm_node_struct*new_node_info,mmi_scenario_node_flagflag)
2)mmi_frm_scrn_insert(MMI_IDparent_id,MMI_IDbase_id,mmi_frm_node_struct*new_node_info,mmi_scenario_node_flagflag)
两者都会根据传入的flag参数确定加入的位置,加节点的流程与进屏加节点类似,只是位置不同,不再分析流程。
6.一些函数介绍
1.mmi_frm_get_active_scrn_id(MMI_ID*group_id,MMI_ID*scrn_id)获取激活的group和screen的ID
2.mmi_frm_group_get_active_id(void)
3.mmi_frm_scrn_get_active_id(void)和以前类似,对tab页也是获取主屏ID
4.mmi_frm_scrn_tab_get_active_id(void)这个函数是获取tab页主屏的ID
5.mmi_frm_scrn_tab_page_get_active_id(void)获取激活的page页ID(也就是子屏ID)
6.mmi_frm_scrn_get_active_gui_buf(void)这个函数封装了所有screen的历史获取,包括tab页。
7.mmi_frm_scrn_set_leave_proc(MMI_IDparent_id,MMI_IDscrn_id,mmi_proc_funcproc)设置删屏响应函数
7.总结
由上可知10A的屏幕管理要比以前的复杂的多,上面所分析的也是一种常见的屏幕架构,也会有比较特殊的,会直接用以前的EntryNewScreen,也会有一个group下游很多screen子节点,可是万变不离其中,都是根据节点的增删,维护一个树,来实现屏幕的切换。
还有些tab页的进屏没有详细分析,不过也是类似节点的管理,不再一一介绍,可以根据代码了解过程。
主要是进一个主屏,这个主屏链接着树,管理其顺序,然后主屏下有相应的page页,激活着的page页在这个主屏的尾部,在返回时只对主屏进行操作,不过在操作中会操作它的子节点。
注意:
在10A中也可以用EntryNewScreen,不过有几点限制:
1.如果前后都是EntryNewScreen,可以。
2.如果前面是节点,那么该节点的父节点必须为shell.scenario_root
3.如果后面是节点,那么该节点的父节点必须为shell.scenario_root
终上所述,也就是说EntryNewScreen进的screen可以理解为shell.scenario_root这个节点的子节点。
以上就是我的收获了,希望有帮助,谢谢。
三.资源添加
1、文件结构
目录一:
plutommi\MMI\FirstApp
目录二:
plutommi\MMI\FirstApp\FirstAppInc(该结构未改变)
文件列表:
FirstAppDefs.h:
用于存放本程序所需要的类型,结构,常量的定义
FirstAppProt.h:
用于存放本程序中的所有函数声明,但此文件只被本文件的源程序所加载
FirstAppGprot.h:
也是用于存放函数声明,但是此文件是用于别的程序加载,即此文件中的函数声明的都是对外的接口
FirstAppResDef.h:
用于存放本资源ID的定义接口
目录三:
plutommi\MMI\FirstApp\FirstAppSrc(该结构未改变)
FirstAppSrc.c程序的主源文件
目录四:
plutommi\MMI\FirstApp\FirstAppRes(新的目录)
FirstApp.res:
资源文件定义,包含字串、图片、菜单、屏幕等的定义,该文件实际为一个标准xml文件
ref_list_FirstApp.txt:
该模块多国语言字串定义(目前发现该文件并未生效,不知道是否是设置问题)
2、将文件加入项目
修改make\plutommi\mmi_app\下的三个文件:
1)mmi_app.lis:
此文件用来申明MMI所要编译的所有源文件,添加如下一行:
plutommi\MMI\FirstApp\FirstAppSrc\FirstAppSrc.c
2)mmi_app.inc:
此文件用来指明MMI所有头文件所在目录,同样添加:
plutommi\MMI\FirstApp\FirstAppInc
3)mmi_app.pth:
此文件用来指明MMI所有源文件所在目录,添加:
plutommi\MMI\FirstApp\FirstAppSrc
4)在plutommi\Customer\ResGenerator\MakeFile文件中添加如下一行:
-I"../../MMI/FirstApp/FirstAppInc"\
3、应用程序ID定义
1)在基础ID统一定义文件plutommi\MMI\Inc\mmi_res_range_def.h(原来为MMIDataType.h)中找到如下定义块:
RESOURCE_BASE_ENUM_BEGIN()
/**************************************************************************************
*DeclareresourceIDrangebelow
**************************************************************************************/
……
/**************************************************************************************
*DeclareresourceIDrangeabove
**************************************************************************************/
RESOURCE_BASE_ENUM_END()
在其中添加:
#ifdef__MMI_FIRSTAPP__
RESOURCE_BASE_RANGE(FIRSTAPP,50),
#endif
2)找到如下定义块:
/*Beginningofresourcetable*/
RESOURCE_BASE_TABLE_BEGIN()
……
/*Endofresourcetable*/
RESOURCE_BASE_TABLE_END()
在块中间末尾位置添加:
/****************************************************************************
*FirstApp
*****************************************************************************/
#ifdef__MMI_FIRSTAPP__
#defineFIRSTAPP_BASE((U16)GET_RESOURCE_BASE(APP_FIRSTAPP))
#defineFIRSTAPP_BASE_MAX((U16)GET_RESOURCE_MAX(APP_FIRSTAPP))
RESOURCE_BASE_TABLE_ITEM_PATH(APP_FIRSTAPP,".\\MMI\\FirstApp\\FirstAppRes\\")//这里较之前有所变化
#endif
4、字串、图片、屏幕资源的添加
先来说字串、图片、屏幕资源ID的添加。
10A版本中对资源定义的改动比较大,稍微对比一下新老版本,你会发现很多原来很大的文件变小了,而多出来了很多.res后缀的文件,这就是新版本的资源定义文件。
10A版本仍部分保持了老版本的定义方式,不过笔者建议采用新版本的方式来定义资源,而且与之前相比新版本的资源定义要方便不少。
读者可以随便找一个res文件,会看到如下定义格式:
/*NeededheaderfilesofthecompileoptioninXMLfiles,ifyouneedothersneedtoaddhere*/
#include"mmi_features.h"
#include"custresdef.h"
/*NeedthislinetotellparserthatXMLstart,mustafterall#include.*/
xmlversion="1.0"encoding="UTF-8"?
>
/*APPtag,includeyourappnamedefinedinMMIDataType.h*/
/*WhenyouuseanyIDofothermodule,youneedtoadd
thatheaderfilehere,sothatResgencanfindtheID*/
--IncludeArea-->
-----------------------------------------------------StringResourceArea----------------------------------------------------->
/*StringIDofyouApplication,wewillgetstringfromref_list.txtforalllanguages*/
/*这里说下,字串的内容定义和之前的版本一样放在YourProjectPath\plutommi\Customer\CustResource\PLUTO_MMI\ref_list.txt下,为了更好的兼容,最好将你自己定义的字串重新规整到YourProjectPath\plutommi\MMI\FirstApp\FirstAppRes\ref_list_FirstApp.txt下,具体定义方式和ref_list.txt类似,参考本博客文章《MTK编程起步——建立新APP和资源定义》*/
-----------------------------
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- MTK10A 帮助 文档 总结
![提示](https://static.bdocx.com/images/bang_tan.gif)