深入玩BREW---从任务角度看BREW

首先要明确一个概念， 手机软件不只是只有BREW而已。任何嵌入式软件都必须要有他的操
作系统，在高通平台上，这个操作系统就式REX。 REX管理着一些TASK－－任务（UI TASK,CM
TASK,CAMERA TASK，FILE SYSTEM TASK）等等。早前，由于WEB BROWSER由于占用资源过多也曾
被单独做成一个TASK，但是任务间通信比APP间通信麻烦的多，后来也就被揉进BREW中做一个
APP了。

UI TASK是个比较特殊的任务，顾名思义，在它上面跑的是用户接口的程序。 BREW 就是在UI
TASK里运行的，当然也可以自己做一个TASK来运行BREW，但是高通强烈推荐在UI TASK里运行
BREW。 TASK间的调度，通信是依靠signal信号来完成的。每个任务只对自己关心的signal感
兴趣，而TASK在大部分时间里做的事情就是等这些信号。下面看一下UI_TASK的核心代码：
void ui_task (dword dummy)
{
static rex_sigs_type sigs; //定义signal的类型

ui_init(); //初始化UI TASK：初始化一个定时器，用

//task_start启动，注册定时器等等

for( ;; ) {
sigs = rex_wait(
UI_RPT_TIMER_SIG | TASK_OFFLINE_SIG | TASK_STOP_SIG
| UI_IPC_SIG| AEE_APP_SIG| UI_AUTOANSWER_SIG);
HandleSignals( sigs ); //一旦收到信号就处理
}
}

大家可以在上面看到 AEE_APP_SIG这个信号，它就是BREW专属信号量，一旦收到这个信号，

UI TASK就知道BREW需要被运行了， 之后的处理过程如下：

if ( sigs & AEE_APP_SIG) {
....
{
uint32 ret_val = 0;

ret_val = AEE_Dispatch(); //调用AEE_Dispatch函数分发处理BREW事件队列，回调

//等
.....
}
}

BREW的执行和其他代码一样，采用时间片轮转机制，分给它的DISPATCH时间是有限的，默认是
250毫秒。 时间片用完之后，BREW就需要放弃CPU的控制权，返回给UI TASK。 关于
AEE_DISPATCH这个神秘的函数，东方兄有精辟的分析，我在这里偷个懒，引用一下。

{
AEE_Dispatch会检查BREW事件队列中的所有事件，一一分发（此时就会将事件发给APP　
Handleevent），同时也会检查Callback队列中的Callback，进行一一回掉．所有都处理完后，
表示本次BREW循环结束．将运行环境切换回UI　Task中的其他非BREW程序，或者切换至其他
Task．　当下次BREW再需要执行时，BREW将再次设置AEE_APP_SIG，从而导致当系统任务调度到
UI　Task时，AEE_Dispatch再次被调用，以此往复．
ISHELL_Resume将Callback放到BREW　Callback队列中，同时设置AEE_APP_SIG,这样当下次UI　
TASK被调度的时候，就会进行AEE_Dispatch，此时就会来回掉该Callback．　相当于延迟了一
个消息循环后才被回掉．即，在下一次BREW　Event　Loop时被回调，就是这个意思．
我们可以再看看，按键是怎么传到BREW中的．　当用户按一个键后，　　UI Task会首先收到该
建，将该键值转换为BREW中的虚拟键值码（AVK_XXX）后放入BREW的事件队列中，同时设置
AEE_APP_SIG．　这样下一次UI　TASK被调度时，执行AEE_Dispatch，就会将该按键事件发送给
app　handleevent了．
}