CMMB標準緊急廣播m務的研究與應用
加入技術交流群
④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分鐘再次進入步驟②。本文引用地址：http://cqxgywz.com/article/152281.htm
(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標準的緊急廣播應用必然會在我國災害預警中起到重要作用。
評論