MTK平台开发总结.docVIP

声明：前阶段进行了近两个月的MTK平台上层开发，由于缺乏技术支持，对于整个平台的认识都是通过简略的文档和浅薄的经验摸索出来的。其间整理了一些文档。由于联发科提供的PDF全部是英文，有些名词难以翻译准确，只能凭单方理解和嵌入式开发的词汇习惯进行意译，还请谅解。系列文章均出自原创，肤浅可笑之处，望海涵。 ??? ??? 通过观察可以发现，每个窗体模板都调用这样一个函数：dm_redraw_category_screen()。这个函数便是显示窗体的函数。它内部的实现是这样的：获得该窗体所包含的组件及它们的属性，再根据组件的类型和属性，调用不同的接口，逐一绘制各组件。详细流程如下图所示： ? ? ? 由上面的流程可见，无论是窗体所包含的组件，还是组件的属性，都是根据模板ID获取的。那么现在摆在面前的有两个问题：一、模板ID是如何传递到这个函数中的；二、模板ID和窗体组件、组件的属性，是如何关联到一起的。 我们逐一解决这两个问题。 一、模板ID是如何传递到这个函数中的 模板ID，是ShowCategory..Screen()过程中，所显示的界面的编号，千万不要与EntryNewScreen(scrID，…) 函数中传入的窗口ID相混淆。它们以“MMI_”为前缀，被定义在枚举型结构MMI_CATEGORY_ID_LIST中，又通过结构体dm_data_struct和它的全局结构体变量g_dm_data，在应用程序中被广泛使用。先看看结构体dm_data_struct的定义： typedef struct { S32 s32ScrId; S32 s32CatId; S32 s32flags; } 其中，s32ScrId是当前窗口ID，也就是我们使用EntryNewScreen（）时传入的那个参数；而s32CatId才是模板ID；最后的flag，是模板需要显示软键盘、清屏等动作时，所置的标志变量，它在上面提到的那个dm_redraw_category_screen（）函数中被判断。还是来重点看一下第2个结构体成员s32CateId的使用。 以 ShowCategory6Screen() 为例。这个显示模板的函数中，经常可以看到这样的语句： dm_data.s32ScrId = (S32)GetActiveScreenId(); dm_data.s32CatId = MMI_CATEGORY6_ID; dm_data.s32flags = 0; dm_setup_data(dm_data); 再看dm_setup_data()干了什么： void dm_setup_data(dm_data_struct *dm_data) { g_dm_data.s32CatId = dm_data-s32CatId; g_dm_data.s32ScrId = dm_data-s32ScrId; g_dm_data.s32flags = dm_data-s32flags; } 这样，MMI_CATEGORY6_ID就被很自然的赋到g_dm_data.s32ScrId中了，然后随着这个全局变量，顺利的被带到了dm_redraw_category_screen（）中。 二、模板ID和窗体组件、组件的属性，是如何关联到一起的 通过分析dm_search_control_set函数，发现窗体模板的组件和属性相关信息都隐藏在一个宏伟的结构体数组中：g_categories_controls_map。 这个结构体定义dm_category_id_control_set_map_struct定义如下： typedef struct { U16 category_id; U8 *control_set_p; S16 *default_coordinate_set_p; S16 *rotated_coordinate_set_p; }dm_category_id_control_set_map_struct; 第一个结构体成员，是窗体模板的ID； 第二个结构体成员，是组件数组的首地址； 第三个结构体成员，是默认的组件属性数组的首地址； 第四个结构体成员，是特殊的组件属性数组的首地址。 dm_search_control_set()函数dm_search_coordinate_set()函数就是通过匹配模板ID在结构体数组中分别获取的组件集合和组件属性集合的。 好，到这里，我们刚才提出的两个问题就明确了。 （二）构成窗体的组件的定义 根据上文可以知道，窗体组件的定义与窗体模板ID是通过结构体dm_category_id_control_set_map_struct关联的。现在来