本文主要是介绍unimrcp源码窥探及task异步架构的学习(一)（Framework Agent），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
设置日志DEBUG级别，对照日志从main函数进入处理流程。必要时候用gdb工具单步执行调试。
一、task分析
了解task 的一切，从task创建开始。先来了解一下，apt_task_t这个结构体中包含了哪些数据。
- 父task链表节点(注释的说法是这样的) link
说明，环(ring)是一种双向链表，可以在不知道其头部在哪里的情况下进行操作。APR中的环的介绍，请看另外一篇文章的详解。
定义如下：
APR_RING_ENTRY(apt_task_t) link; /* entry to parent task ring */
APR_RING_ENTRY是一个宏定义，按照宏定义展开的话，以上的定义是这样的结构：
struct { \
struct apt_task_t * volatile next; \
struct apt_task_t * volatile prev; \
}link;
由此可见，link为我们记录了访问父task链表的入口节点。
- 子task的链表头(按照注释的理解) head
APR_RING_HEAD(apt_task_head_t, apt_task_t) head; /* head of child tasks ring */
我们把APR_RING_HEAD的宏定义展开，得到实际的结构：
struct apt_task_head_t { \
struct apt_task_t * volatile next; \
struct apt_task_t * volatile prev; \
}head;
- 无类型指针 obj
obj是与任务关联的外部对象
- 消息池 msg_pool
- 互斥锁 data_guard
- 虚方法表结构 vtable
虚方法表结构中有三类函数指针：
task的方法， start/ run/ terminate/destroy方法
消息处理的有关方法， 发信号消息处理（ signal_msg） 、消息处理( process_msg)、消息处理启动（ process_start）、消息处理终止( process_terminate)
事件处理的有关方法， pre_run / post_run/ on_ start_complete / on_ terminate_complete/ on_offline_complete / on_online_complete
红色标注的三个方法，在 apt_task_create函数中分别进行了赋值，由此可见他们是所有task通用的方法，没有自定义：
task->vtable. terminate= apt_task_terminate_request;
task->vtable. process_start= apt_task_start_process_internal;
task->vtable. process_terminate= apt_task_terminate_process_internal;
二、task实体
那么分析完apt_task_t以后，我们来解剖一下umc客户端，看看运行这样一个程序需要启动的task实体类型。
1. Framework Agent
配置类型？ 对应的是UmcFramework的实例
最外层这个大的Agent，定义了UmcFramework这个类来进行管理。
重点关注m_pTask(apt_consumer_task_t*)变量 、m_pMrcpClient(mrcp_client_t*)变量和m_pMrcpApplication变量(mrcp_application_t*)
下面对此进行分解。首先是拿m_pTask来讲一下。
①创建task 对应的函数是UmcFramework::CreateTask()
先调用apt_consumer_task_create去创建一个consumer_task结构，在这创建的过程中，首先就要创建apt_task_t的结构，并将apt_task_t作为成员变量(base)存放于apt_consumer_task_t结构中。
②虚方法表中的 run方法、 signal_msg方法，在此处被定义赋值，既然是使用的 consumer，自然run方法和 singal_msg方法是跟consumer强关联的：
static apt_bool_t apt_consumer_task_msg_signal(apt_task_t *task, apt_task_msg_t *msg);
static apt_bool_t apt_consumer_task_run(apt_task_t *task);
这儿两个函数指针实例化，体现的正好是生产者/消费者模型。注意，不要跟apt_consumer_task_t的概念弄混淆。
signal后缀的函数，干一个事情，就是将一个apt_task_msg_t类型的消息，压入到消息队列中（生产）。
run后缀的函数，里面是一个无线循环，从消息队列中取消息，然后进行处理(消费)。具体实现上，要区分消息类型，根据消息种类不同(TASK_MSG_CORE/ TASK_MSG_USER)，交给不同的函数去处理：
TASK_MSG_CORE类型的消息，是通过apt_task_msg_process去调用apt_core_task_msg_process函数进行处理
TASK_MSG_USER类型的消息，是通过apt_task_msg_process去调用process_msg这个函数指针，目前执行到这儿这个函数指针还没有实例化，是一个空指针。
处理完上述内容以后，回到CreateTask函数继续， 接下来拿到虚方法表结构，在这里先给 process_msg方法赋值，也就是上述生产者/消费者模型中，真正要处理TASK_MSG_USER消息的地方。
再把两个事件处理方法进行实现，就是 on_ start_complete方法和 on_ terminate_complete方法。
on_ start_complete方法会在 process_start执行的时候被调用到，
③最后一步，执行apt_task_start()函数，启动这个task！
默认是会再启一个线程执行启动操作的。线程中按照时间轴处理，流程是这样：
触发on_pre_run事件（当前该task没有定义该事件的触发）
↓
修改task状态机
↓
process_start处理
- 实际执行apt_task_start_process_internal函数
- 从子任务队列中取出任务并执行(如果有)
- 触发 on_ start_complete事件(没有子任务的情况下)
↓
执行task
- 虚方法表例的run方法，已用apt_consumer_task_run赋值
- 无线循环，从消息池中取消息并消费消息
↓
task退出运行，修改task状态机
↓
触发on_post_run事件
Done！这样Framework Agent跑起来了！
写在最后：
on_ start_complete事件中，完成了sip协议栈、mrcp协议栈的工作线程的创建和启动。详细可以见(二)中的解析。
这篇关于unimrcp源码窥探及task异步架构的学习(一)（Framework Agent）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
