CMMB標準緊急廣播m務(wù)的研究與應用

(5)減少客戶(hù)端移植工作量的探討
嵌入式軟件開(kāi)發(fā)與PC軟件開(kāi)發(fā)很大的區別是，嵌入式軟件設計中必須考慮目標機的差異性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系統，甚至不同操作系統。如果本EBP客戶(hù)端軟件的設計中沒(méi)有考慮便于移植的因素，那么適配這些適用于CMMB技術(shù)的手機、游戲機、PDA、車(chē)載GPS、MP4，所需工作量將是非常大的。正是考慮到這個(gè)因素，所以本客戶(hù)端做了以下2方面工作來(lái)簡(jiǎn)化移植工作。
①邏輯與GUI的解耦，也就是圖3所展現的核心層與UI層的分離。核心層的職責是管理緊急廣播消息的接收、解析、本地管理。UI層的職責是監聽(tīng)核心層發(fā)送的EBP_RECEIVE_OK消息，收到該消息就利用接口層提供的3個(gè)接口ebp_create_cursor、ebp_get_nextcur、ebp_getebp，像使用迭代器那樣訪(fǎng)問(wèn)接收到的緊急廣播數據。這樣的好處之一是，在支持相同GUI系統的終端間移植該客戶(hù)端時(shí)，在用戶(hù)UI層不需要任何的移植工作。好處二是，該層使用EBP_CURSOR(當前版本定義是typedefvoid_t*CMMB_EBP_CURSOR；)訪(fǎng)問(wèn)頂層數據，如果以后核心層使用的數據結構改變，如“typedef int CMMB_EBP_CURSOR；”，也就是說(shuō)存儲緊急廣播消息由鏈表改為數組，該層也不需要作任何改變。
②核心層中的分層。核心層之所以分為3層的原因是，接口抽象層和EBP解析層在移植的過(guò)程中可以保持不變，而本地管理層在移植的過(guò)程中可能因為文件系統不同而必須修改具體操作。所以在核心層中將該層抽取出來(lái)，在移植客戶(hù)端核心層時(shí)只需要關(guān)注該層即可。將EBP解析層與接口層分離的目的是，給用戶(hù)UI層僅暴露出接口層的接口以及數據結構，使其關(guān)心的內容局限于自己所需要的數據結構，不需要去關(guān)心不會(huì )直接使用且可能會(huì )因為架構上的調整而發(fā)生變化的問(wèn)題。這樣如果由第三方來(lái)實(shí)現用戶(hù)UI層，可以簡(jiǎn)化其開(kāi)發(fā)。
在最初的原型設計中，并沒(méi)有采取這種分層的結構，而是將邏輯與GUI混合在一起，在移植到不同的平臺時(shí)發(fā)現增加的工作量十分大且極易出錯。所以決定在移植前采取重構，重構后的結構就是本文所描述的設計架構，后來(lái)的移植工作量就很少，也很簡(jiǎn)單了。本次設計令筆者切身感受到這種邏輯與UI分離的思想帶來(lái)的好處。
2．3 運行效果截圖
本客戶(hù)端接收過(guò)程是后臺接收，運行效果如圖4所示，該圖是在支持CMMB的Windows Mobile5手機上運行，用SuperSnap工具截屏得到的。左邊的標簽表示接收緊急廣播消息的時(shí)間，通過(guò)標簽可以切換右側內容，觀(guān)看具體的緊急廣播消息。所使用的測試數據為中國數字電視論壇上的CMMBMFS測試樣本碼流。

結 語(yǔ)
以上的設計和實(shí)現充分考慮了空間和效率這兩大要素，通過(guò)和市面上其他產(chǎn)品進(jìn)行比較，該系統能夠在存儲空間更小、處理速度更慢的移動(dòng)設備上流暢地運行，取得了令人滿(mǎn)意的效果。
本設計中的EBP客戶(hù)端程序能夠成功接收CMMB網(wǎng)絡(luò )中多個(gè)頻點(diǎn)發(fā)送的緊急廣播消息，并且客戶(hù)端具有一定的鍵壯性，可以通過(guò)較少的移植工作量使其工作在適用于CMMB技術(shù)的手機、游戲機、PDA、車(chē)載GPS、MP4，達到了預期目的。相信隨著(zhù)CMMB網(wǎng)絡(luò )的日漸成熟，CMMB標準的緊急廣播應用必然會(huì )在我國災害預警中起到重要作用。