MTK MMI event 小结

最新推荐文章于 2018-07-21 10:30:36 发布

转载最新推荐文章于 2018-07-21 10:30:36 发布 · 1k 阅读

文章标签：

#mtk #query #timer #电话 #null #优化

MTK技术专栏收录该内容

7 篇文章

订阅专栏

本文介绍了MTK MMI中常见的事件处理机制，包括按键事件、触摸屏事件等，并详细解析了普通事件和中断事件的处理流程。通过注册函数SetProtocolEventHandler，开发者可以为特定事件指定处理函数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在MTK MMI 里面有各种event，最常见的跟交互相关的按键 event，触摸屏 event。跟各种具体事件比如电话event，短信event，电量event，信号量event，timer event等等。

MTK 都有相应的处理方式，跟交互相关的按键(KeyBrd.c)和触摸屏(TouchScreen.c) 各有一套自己的机子，timer event 已经在 MTK timer 小结 3 介绍过，还有一套机制就是处理各种其他事件，它主要分为普通事件和interrupt event，interrupt event 主要用于需要弹出的对话框的event。

昨天草草的写了几句，今天自己先复习了想写的东西，一看那么晚了，哎，都怪原来没有搞透，现在复习也有些地方不是很明白。如果有错误希望指正。

今天主要看分析，常用事件机制。做过MTK开发的童鞋应该知道要接受 MTK L4 层的消息，用一个注册函数 SetProtocolEventHandler，注册一个event 的处理函数。比如短信，电话，电池电量，信号量等等都是通过这个函数来注册消息。当L4 层，处理完封装事件后，就会把这个event 发送到MMI task 里来(消息发送可以看 MTK task 小结 5 )，然后MMI task 通过这个 event 机制，找到相应的处理函数，进行处理。实现这种机制，也是考虑到零活性和扩张性。如果都在MMI task 里面，用 switch case 来处理，那就很疯狂了，长度不说，写个应用，定义个消息，都要去改MMI task，所以这个机制实现虽然比较简单，但是还是很有必要的。

昨天也说到，这个机制的 event 主要有两种，普通event 和 intrrupt event(中断事件)，这些主要是一些需要中断当前应用的事件(主要是看那些弹出框)，比如电话，有些应用需要提前处理这个消息，还要处理这个事件处理完毕后的处理。还是看代码吧

在MMI task 最后，会调用函数 ProtocolEventHandler，这个函数是就是找相应的event 的相应处理函数(平台不一样，可能实际的函数名字有些区别，但是流程基本上一样的，我这里被 #define 到 mmi_frm_execute_current_protocol_handler)。

// MsgStruct 是具体事件的消息体
void mmi_frm_execute_current_protocol_handler(U16 eventID, void *MsgStruct, int mod_src, void *peerBuf)
{
U16 count = 0;

PsExtPeerFuncPtr currFuncPtr = NULL;

    U8 interrup_result = MMI_FALSE; /* False not handle interrupt, True will handle */

     MMI_BOOL query_result = MMI_FALSE, execute_result = MMI_FALSE;
    interrupt_event_hdlr int_func = NULL, post_int_func = NULL;
    mmi_frm_int_event_type current_frm_int_event;

    {
        // 遍历 protocolEventHandler 查找是否有event 注册了回调函数
        // 虽然这个方法感觉比较笨，就一个数组,实际上对速度没有什么影响
        for (count = 0; count < maxProtocolEvent; count++)
        {
            if (protocolEventHandler[count].eventID == eventID)
            {
                //找到处理函数
                currFuncPtr = (PsExtPeerFuncPtr) protocolEventHandler[count].entryFuncPtr;
                // 这个地方时，一个优化
                // 处理的事情就是把刚才现在处理的 event id 往前移动一个单位
                // 这是考虑到程序的局部性原理，这个优化还是很有必要的
                if (count > 0)
                {
                    protocolEventHandler[count].eventID = protocolEventHandler[count - 1].eventID;
                    protocolEventHandler[count].entryFuncPtr = protocolEventHandler[count - 1].entryFuncPtr;

                    protocolEventHandler[count - 1].eventID = eventID;
                    protocolEventHandler[count - 1].entryFuncPtr = (PsFuncPtr) currFuncPtr;
                }
                break;
            }
        }
    }

    // 这个就是查找是否是中断事件
    current_frm_int_event = mmi_frm_interrupt_event_converter(eventID, MsgStruct);
    if (current_frm_int_event > 0)
    {
        // 查看改中断事件是否有注册提前处理函数
        query_result = mmi_frm_query_interrupt_event_information(current_frm_int_event, &int_func, &post_int_func);
    }
    // 如果有调用该函数
    if (query_result && int_func)
    {
        /* New interruption mechanism */
        execute_result = (*int_func)(current_frm_int_event);
    }

    //根据 event 相应的回调函数以及前面处理的结果，来觉得是否处理该事件
    // 要注意的是，如果如果 interrput 提前处理函数返回 true，那么这里就不会执行
    if ((currFuncPtr) && (!interrup_result) && (!execute_result))
    {
        (*currFuncPtr) (MsgStruct, mod_src, peerBuf);
    }
    else
    {
        MMI_TRACE(MMI_FW_TRC_G1_FRM, MMI_FRM_INFO_EVENT_EXECURPTO_NO_HDLR, eventID);
    }

    // interrupt event 最后处理函数
    if (query_result && post_int_func)
    {
        execute_result = (*post_int_func)(current_frm_int_event);
    }