用ESIM Rapid开发MMI的几点心得，呵呵。
ESIM公司的Rapid用来开发手机的MMI很好，但如果不好好用，也会成为一场噩梦。
1. 撰写轻量级的Rapid应用。
这一点建议是指尽量把实现代码移到UDI中，让Rapid只处理逻辑。先声明一点，轻量级的Rapid应用决不是说较少的feature，而是针对所有使用Rapid开发MMI的手机的。
个人认为这样做有以下几个优点：
(1). 把Rapid的作用降到最小，充分发挥Rapid处理逻辑的长处。Rapid的优势在于逻辑控制 ，而非数据处理，我们可以很方便的试用Rapid的状态机和事件机制来控制逻辑。个人看来，Rapid的GDO也可以不用code generate出来。
(2). 提升系统的performence。用过的Rapid应该知道，使用Rapid生成的代码，效率并不高，远不如手工编写的C代码，而使用Rapid开发的手机，就现阶段而言，是针对中端为主，处理器使用ARM7居多，Ram有限，对更多的实现使用UDI代码，可以更好的实现对系统资源的控制，而不是通过Rapid控制。
(3). 提高开发效率。Rapid对系统资源占用量极大，一个重量级的Rapid MMI，绝对是开发者的噩梦。打开一个MMI就须2分钟，一个底层服务的存盘就会耗上6，7mins(1.6G P4, 512M)，打开一个debug模式有时也要3，4分钟，偶尔发作的Rapid internal error又会让你的辛苦劳动付之东流(还有终极BOSS code generate就不提了)。
(4). 降低code size，嵌入式开发，ROM和RAM有限，而Rapid生成的代码size偏大，通过在UDI中手动填写代码，可以降低code size。
2. 架构要好。
个人认为，一个好的MMI架构应该具有以下几点特征：
(1). 复用性。会减少开发下一款同平台手机时的effort。
(2). 便于修改。当增删模块时，只通过相当少的修改就可以达到目的。
(3). 层次性。有上层应用，和底层服务的概念，易学易懂。
(4). 系统运作效率高。
(5). 逻辑清晰。
下面就上面几点谈一谈一些架构，都是一家之言。
(1). 几个层次。
一个好的MMI架构，应该有AP(应用程序，有时也叫HMI)，Service，AP Manager，MainAPP，UDI/UDM几种UDO。
即：
MainAP
|
|
AP层
/ | / | Service UDI/UDM AP Manager
/
/
UDI/UDM
MainAPP: MainAPP是Rapid程序中处于最顶层的，不是UDO或者UXO。MainAP一般处理开机过程与关机过程中的事件。
AP: AP是最上层的应用，如短消息，CC等。
a. 一个AP应该只被MainAPP添加进来，或者hold进来。
b. AP之间相对独立，AP间的交互主要通过AP Manager，或者较少的通过MainAP，Service或共同hold的UDI进行。
c. 各自AP有自己的UDI以及UDM,或者Service。
d. 一般来说，一个Ap会有Init, Idle, Run, Interrupt, Suspend等几个mode。
e. code gen方式为Full object。
Service：Service处于AP以下，手机开机即处于运行状态，负责提供底层服务。
a. Service是被动的，即对底层服务函数的再封装，如Display，Keypad，Audio等等。
b. Service是可以无穷重入(re-entry)的。
c. code gen方式为Full object。
AppManager: AppManager是一个好的MMI架构中不可缺少的模块之一，负责ap的调度。AppManager会提供Create，Stop，Interrupt，Suspend，resume，restore以及一些状态query函数。
a. AppManager几乎处于最底层，所有的Ap都会hold他。
b. AppManager用于实现对Ap的控制，协调。
UDI/UDM: 用于对MMI下层，如设备驱动层的API函数的封装。
2. 实现
(1). MainAPP主要负责开机和关机的流程，当手机跑入Idle后，MainAPP停留在Run的mode。
(2). 设一个Idle_APP类似的AP，负责处理Idle下的各种操作。
(3). 以AppManager为主导，统筹AP之间的交互，创建，以及释放。
(4). 如需要，可在AP下设Service。一般来说，AP意味着主动，Service意味着被动。如IrDA，IrDA_Srv可用于别的AP中，如Media，有文件需通过IrDA发送时，将IrDA_Srv start起来，而IrDA_APP，当收到文件时，IrDA_APP会主动Pop出来.
3. 几点tips
(1). 出于RAM考虑，UDM和UDI中的message可以使用malloc生成，在激活时malloc内存，可以在生成代码中实现。
(2). AP可以采用Holdnew方式，但并不推荐，因为这样不利于在Rapid下debug，一般情况下，轻量级的Rapid中，建议不采用holdnew方式处理AP。
(3). 使用XML格式(UXO)还是BIN格式(UDO)，个人感觉XML格式操作速度不如BIN格式，但有利于浏览和修改，轻量级的Rapid中，AP的逻辑一般比较简单，权衡下，可以使用XML格式。
