谈谈ESIM Rapid，:-), v0.17

用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。

  (5).  便于Debug。数据处理是debug的重点，如果想在Rapid生成的代码中debug数据处理的部分，那不是一般的难受，没有一点经验，是不会看懂那些udm_set, RapidInteger_set宏的，至于Rxxx的函数，更是会头晕。所以，将数据处理通过手工填写C code实现，也是debug的需要。

2. 架构要好。

  个人认为，一个好的MMI架构应该具有以下几点特征：
  (1). 复用性。会减少开发下一款同平台手机时的effort。
  (2). 便于修改。当增删模块时，只通过相当少的修改就可以达到目的。
  (3). 层次性。有上层应用，和底层服务的概念，易学易懂。
  (4). 系统运作效率高。
  (5). 逻辑清晰。

  下面就上面几点谈一谈一些架构，都是一家之言。

  (1). 几个层次。
    一个好的MMI架构，应该有AP(应用程序，有时也叫HMI)，Service，AP Manager，MainAPP，UDI/UDM几种UDO。
    即：
                MainAP
                /   |   /
               /    |    /
              /     |     /
             /      |      /
 Service   AP层   AP Manager
                /   |   /
               /    |    /
              /     |     /
             /      |      /
 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. 模拟

        在Rapid中模拟MMI运行是MMI快速开发的关键。
        模拟代码也应以逻辑为主，在UDI函数中填入的代码可以处理一些数据，具体可以视模拟度的高低决定。
        (因为这篇文章主要是针对架构的，具体模拟的部分以后再说点吧)

    4. 几个tips

    (1). 出于RAM考虑，UDM和UDI中的message可以使用malloc生成，在激活时malloc内存，可以在生成代码中实现。

    (2). AP可以采用Holdnew方式。在Holdnew方式下，只有当该AP被holdnew起来时，可以进入该AP(不是该AP的Class)。
    
    5. 几点建议

    (1). 使用XML格式(UXO)还是BIN格式(UDO)，个人感觉XML格式操作速度不如BIN格式，但有利于浏览和修改，轻量级的Rapid中，AP的逻辑一般比较简单，权衡下，可以使用XML格式(其实开发中，更多的可能是二者都存一份)。

    (2). 关于concurrent mode，在我的开发中，concurrent mode用的很少，但我知道ESIM的MMI solution中大量使用了concurrent mode。

         concurrent mode有其方便的地方，这无可厚非，但在笔者开发过的手机中，使用的极少，170多个UDO，使用了的不到10个，在我所发现的情况中，使用concurrent mode所实现的功能，不使用时依然可以达到，而且并不复杂。
         所以，个人建议，尽量少用，原因有二，一是使用concurrent mode后，Rapid模拟的速度会降低不少，二是引入后增加逻辑的复杂，良好的架构完全可以不使用，或极少的concurrent mode而实现其功能。

    (3). 关于UDI接口定义。一般来说，开发中有两种可能，一是UDI接口对底层API完全模拟，二可能是再加简单的封装。因为Rapid不擅长数据处理，个人倾向于简单的再封装。其实，一般底层提供的API中，数据处理的仅为少数函数，所以与第一种方式大体上一致。比如，Audio播放函数，一般需要的参数，两种，直接的数据buffer，或者是文件ID。我们提供的接口可以是一个文件名的接口，然后在UDI代码中，手动添加通过文件名，读出数据到buffer中，然后调用播放函数的代码。

  6.  一点想法

  (1).  如果Rapid可以实时添加手工撰写的C code。

         这个想法是基于C语言和C++中，可以通过_asm关键字，添加内嵌的汇编代码想到的。如果在Rapid中可以添加的嵌入的C代码，在UDI定义中就可以对底层API完全的模拟，在以Full object方式code gen的UDO中对数据处理的部分通过手工添加嵌入的C代码实现。