internal(kernel)->uitask->brew internal->active dialog->dialog ctrl->brew apps.
for clr: if app not process it, then brew will close the current running app.
for end: brew will close all apps, not passed this event to all apps, unless hook.
BREW key process:
hitask->uitask->handlekey------>state machine->process directly
|-->brew->key map->process brew environment
About HOOK(PL_SYSTEM & AFLAG_Phone):改机制看起来神通广大,不过一山还比一山高.
judgement(private option):
1. BREW内核事件作用于Dialog--top visible app--internal
2. BREW用户自定义事件作用于Dialog--all apps--internal (eg.sendevent postevent)
BREW各种机制:
大致分为两大类:一.callback机制 二.事件驱动机制
一. callback机制
1.AEECallback机制
这是BREW标准callback机制,相关操作函数为Callback_init(),Ishell_resume();Callback_cancel().
与AEECallback对应的还有native callback,它不像AEECallback那样只能运行在BREW环境中,它能在uitask和other task之间相互调用.
2.Timer机制
这应该是操作系统相关都应该提供的机制,虽然BREW不是操作系统.相关操作函数有两组
Ishell_Settimer() Ishell_Canceltimer()
Ishell_SettimerEx() Callback_Cancel()
上面那组是标准的,不过据介绍都普遍转向下面那组了.哎,这是什么世道,标准的都被人摒弃,以后怎么混啊(小发牢骚下).
其实他们也是为了我们能用得简单,下面那组用的是标准的AEECallback(看来标准也是有一片天地的).
与AEECallback机制的比较:
他们都是异步实现通知的一种方法,只不过AEECallback是下一个BREW环境被执行到执行,Timer机制是在timer过期之后的下一个loop执行.
3.sleep机制(应该是事件驱动机制,不过那个超时时间应该是用timer做的,而且有一定的可比性就先放这了)
这个机制好像是专为screen saver设计的,通过AEE_Dispatch()的返回值确定是否进入sleep模式.
在超过默认的时间过了以后,用户还没有进行按键操作,BREW internal会发送EVT_APP_NO_SLEEP,返回true,重置30秒,返回false,每个loop都询问.个人认为这种
设计有问题,因为返回false的话系统进入睡眠模式,没有必要重复地进行询问.
二. 事件驱动机制
1.alarm机制
首先介绍它的原因是它也跟timer有一定的可比性:虽然都是在时间到期后做一定的事情,不过还是有本质区别的:
.驱动机制不一样,timer是基于callback的,对进程的依赖性比较大.alarm机制是基于事件的,就算实例不存在也不打紧.
.存储介质不一样,timer应该是存在在进程的栈中,alarm是存储在文件系统之类的非易失性的存储器中.
.时长不一样,timer应该是比较短期的,甚至是毫秒级的,alarm可能是几天到几年不等,比如闹钟等.那么中间地带应该怎么选择呢,我个人认为有个标准,如果频率 太高那么就用timer,不用来回创建和销毁实体,带来不必要的损耗,如果需要有记忆性,那么就用alarm,就算关机了也能有效.
2.hook机制
它是先于top visible得到事件的一种机制.它是在某一应用中用来对同一按键进行不同处理的必要机制,只要它返回true,其他任何app或internal默认处理函数 都无法得到响应.
3.notify机制
hook机制看起来听牛的,不过notify更有特权,只要它被注册过,就算你是hook,就算你还返回了true,都无法阻止我的执行.而且目的性很强,只对自己感兴趣的消 息进行处理.我的人生有一个notify,并不是在出生的时候就注册,但是确实是一个不错的notify,在做任何决定之前,它都会跳出来,查看一下我的头脑,如果脑子 过热,它就会对我说"嘿,小子,现在还不是做决定的时候,等冷静下来再说".我希望这个机制不会失效.
好了,上面只是学习的一点归纳而已.
不过,我想谈谈高通对于brew的成功.资料上说,brew的执行源于brew signal的设置.那么我要说,brew的生存源于手机市场的存在.确实,brew就是对应手机的开发平台.它
的局限性其实很大,如果有其他的应用,可能还会被要求写一个类似brew的平台出来.在现在的情况下好像没有这种可能,因为我们生产一样东西,我们会评估它的市场和前景.如果没有市场根本就不可能做了.就算有市场,还要评估一下必要性,就是远景.这一点,高通是有前瞻性的(必须承认),因为直到现在手机还是人们通讯的最基本的工具.从这一点来说,你要我评论brew现象的出现是否偶然,你说呢.我可能给出这样的结论,brew的产生具有偶然性,而brew出现以后它的成功确是必然的.因为在前几年所有面临的机遇和挑战也太多了,如果我是决策者,我想我可能不会冒这个显,因为电子行业的产品推陈出新的速度太快了.然而高通做到了,那么恭喜他们.然而我们要问,这个现象太特殊了,而且高通不可能只把brew和它的操作系统绑定起来,一定还会有一个类似brew的东西出现,不过在那方面我跟盲人没多大区别---我找不到(或许高通已经找到并精心部署它的下一步计划了).
