④EBP客户端核心层给用户UI层发送EBP_RECEIVE_OK(如前三步失败发送：EBP_RECEIVE_TIMEOUT)消息。
    ⑤用户UI层根据步骤4发送的消息来做相应的处理。a．如果是EBP_RECEIVE_OK消息，则使用关键接口中的4、5、6接口便可以获取各个紧急广播消息，并在界面上做响应展现。接口4内部会去判断并删除过期的紧急广播消息。
    当新接收的紧急广播消息中有紧急程度为1级或者2级的紧急广播时，直接弹出图4所示的界面。新接收的紧急广播消息紧急程度都是3级或者4级时，仅需要给用户1个闪烁提示，由用户选择是否观看紧急程度不太高的广播消息。b．如果是EBP_RECEIVE_TIMEOUT消息，本客户端采用的策略是首先调用ebp_cancel_receive接口，对此次接收失败的环境进行清理，然后过10分钟再次进入步骤②。

    (5)减少客户端移植工作量的探讨
    嵌入式软件开发与PC软件开发很大的区别是，嵌入式软件设计中必须考虑目标机的差异性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系统，甚至不同操作系统。如果本EBP客户端软件的设计中没有考虑便于移植的因素，那么适配这些适用于CMMB技术的手机、游戏机、PDA、车载GPS、MP4，所需工作量将是非常大的。正是考虑到这个因素，所以本客户端做了以下2方面工作来简化移植工作。
    ①逻辑与GUI的解耦，也就是图3所展现的核心层与UI层的分离。核心层的职责是管理紧急广播消息的接收、解析、本地管理。UI层的职责是监听核心层发送的EBP_RECEIVE_OK消息，收到该消息就利用接口层提供的3个接口ebp_create_cursor、ebp_get_nextcur、ebp_getebp，像使用迭代器那样访问接收到的紧急广播数据。这样的好处之一是，在支持相同GUI系统的终端间移植该客户端时，在用户UI层不需要任何的移植工作。好处二是，该层使用EBP_CURSOR(当前版本定义是typedefvoid_t*CMMB_EBP_CURSOR；)访问顶层数据，如果以后核心层使用的数据结构改变，如“typedef int CMMB_EBP_CURSOR；”，也就是说存储紧急广播消息由链表改为数组，该层也不需要作任何改变。
    ②核心层中的分层。核心层之所以分为3层的原因是，接口抽象层和EBP解析层在移植的过程中可以保持不变，而本地管理层在移植的过程中可能因为文件系统不同而必须修改具体操作。所以在核心层中将该层抽取出来，在移植客户端核心层时只需要关注该层即可。将EBP解析层与接口层分离的目的是，给用户UI层仅暴露出接口层的接口以及数据结构，使其关心的内容局限于自己所需要的数据结构，不需要去关心不会直接使用且可能会因为架构上的调整而发生变化的问题。这样如果由第三方来实现用户UI层，可以简化其开发。
    在最初的原型设计中，并没有采取这种分层的结构，而是将逻辑与GUI混合在一起，在移植到不同的平台时发现增加的工作量十分大且极易出错。所以决定在移植前采取重构，重构后的结构就是本文所描述的设计架构，后来的移植工作量就很少，也很简单了。本次设计令笔者切身感受到这种逻辑与UI分离的思想带来的好处。
2．3 运行效果截图
    本客户端接收过程是后台接收，运行效果如图4所示，该图是在支持CMMB的Windows Mobile5手机上运行，用SuperSnap工具截屏得到的。左边的标签表示接收紧急广播消息的时间，通过标签可以切换右侧内容，观看具体的紧急广播消息。所使用的测试数据为中国数字电视论坛上的CMMBMFS测试样本码流。

结 语
    以上的设计和实现充分考虑了空间和效率这两大要素，通过和市面上其他产品进行比较，该系统能够在存储空间更小、处理速度更慢的移动设备上流畅地运行，取得了令人满意的效果。
    本设计中的EBP客户端程序能够成功接收CMMB网络中多个频点发送的紧急广播消息，并且客户端具有一定的键壮性，可以通过较少的移植工作量使其工作在适用于CMMB技术的手机、游戏机、PDA、车载GPS、MP4，达到了预期目的。相信随着CMMB网络的日渐成熟，CMMB标准的紧急广播应用必然会在我国灾害预警中起到重要作用。