對標蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
上世紀九十年代，互聯網的極速發展讓通訊測試設備也得到了極大的發展。那個年代，能夠實現某種測量的硬件是競爭的核心，軟件的目的僅僅是驅動硬件運行起來，再提供一個簡單的界面。所以，最初的產品的軟件結構非常簡單，類似前面的城鐵門禁系統。
用戶要求能將測量結果保存下來，并可以重新打開。數據存儲模塊和界面被獨立出來。
依然保持上面的主邏輯，但是界面部分不僅可以顯示實時的數據，也可以從ResultManager中讀取數據來顯示。
隨著功能不斷復雜，界面窗口越來越多，原來靠一個類來繪制各種界面的方式已經不能承受。于是窗口的概念被引入。每個界面都被視為一個窗口，窗口中的元素為控件。窗口的打開，關閉，隱藏則由窗口管理器負責。
隨著規模進一步擴大，最初的大循環結構終于無法滿足日益復雜的需求了。標準的MVC模式被引入，經歷了一次大的重構。
數據中心作為Model被獨立出來，保存著當前最新的數據。View被放在了獨立的任務中執行，定期從DataCenter輪詢數據。用戶的操作通過View發送給Controller，進一步調用硬件驅動執行。硬件執行的結果從驅動到Controller更新到DataCenter中。界面，數據，命令三者基本解耦。ResultManager成為DataCenter的一個組件，View不再直接與其通訊。
MVC模式的引入，第一次讓這個產品了有真正意義上職責明晰，功能獨立的架構。
到上一步，作為一個單獨的嵌入式設備，其架構基本可以滿足需求。但是隨著市場的擴展，越來越多的設備被設計出來。這些設備雖然執行的具體測量任務不同，但是他們都有著同樣的操作方式，類似的界面，更主要的是，它們面臨的問題領域是相同的。長期以來，復制和粘貼是唯一的復用方式，甚至類名變量名都來不及改。一個錯誤在一個設備上被修正，同樣一段代碼的錯誤在其他設備上卻來不及修改。而隨著團隊規模的擴大，甚至MVC的基本架構在一些新設備上都沒能遵守。
最終框架被引入了這個系列的產品。框架確定了如下內容：
客戶希望將設備固定安放在網絡的某個位置，作為“探針”使用，在辦公室通過遠程控制來訪問這個設備。這對于原本是作為純手持設備設計的系統又是一個挑戰。幸運的是，MVC架構具有相當的彈性，早期的投入獲得了回報。
TL1 Server 對外提供基于Telnet的遠程控制接口。在系統內部，它的位置相當于View，只和原有的Controller和DataCenter通訊。
由于TL1命令相當多，而TL1又往往不是客戶的第一需求，很多設備的TL1命令開始不完整。究其原因，還是手寫TL1命令的解釋器太累。后來通過引入Bison和Flex，這個問題有所改善，但還是不足。自動化代碼生成在這個階段被引入。通過以如下的格式定義TL1，工具可以自動生成TL1的編碼和解碼器代碼。
CMD_NAME{ cmd = “SET-TIME-CONFIG::<ctag>::<year>,<month>,<day>,<hour>,<minute>,[<second>]” year = 1970..2100 month = 1..12 day = 1..31 hour = 0..23 minute = 0..59 second = 0..59}經過數十年的積累，產品已經成為一個系列，幾十種設備。大部分設備進入了維護期，經常有客戶提一些小的改進，或者要求修正一下缺陷。繁重的手工回歸測試成為了噩夢。
基于TL1的自動化測試極大的解放了測試人員。通過在PC上運行的測試腳本，回歸測試變得簡單而可靠。唯一不足的是界面部分無法驗證。
基于Test Quest的自動化工具需要在設備運行的pSOS系統上開發一個類似遠程桌面的軟件，而這在pSOS上并非易事。不過好消息是，由于框架固定了界面的風格和布局算法，基于Test Quest的自動化工具會有很高的識別效率。
從這個實際的嵌入式產品重構的歷程可以看出，第三步引入MVC模式和第四步的框架化是非常關鍵的。成熟的MVC模式保證了后續一系列的可擴充性，而框架則保證了這個架構的在所有產品中的準確重用。
本文鏈接：http://www.tebozhan.com/showinfo-26-16392-0.html一個實際嵌入式系統架構的演化
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號