人機界面菜單讓人犯愁，純文本描述得意外收穫

GIF/1K

序言：「2017年工程師節」在6月6號正式拉開序幕，本屆工程師節的主題圍繞「技能」二字。身為電子人，無論行走江湖的老者，還是初入此圈的新人，總有一兩個技能傍身、或是一兩個得意之作。

GIF/1K

想要參加本次工程師節，並贏取大獎，歡迎掃描文末的二維碼！

背景

菜單是一種人機交互界面的常用組織方式。

所謂人機交互，說白了是一個圖形化界面，人可以通過按鍵、鍵盤或者觸屏對它進行操作，界面的元素會觸發響應預設的動作行為。

一套圖形化界面通常由多個頁面組成，每一頁上有多個控制項元素構成，通常根據它們的用途進行分類，比如用來顯示文本的稱為標籤，可以編輯內容的稱為文本框，僅僅作為點擊就觸發某個事件，就像開關的，我們稱之為按鈕。

「頁面」、「控制項」其實是一個抽象概念，我們之所以能直觀感覺它們，是因為它們在顯示屏上的外觀，比如頁面我們往往用一張全屏大小的圖片，就像電腦桌面一樣，而按鈕我們往往會做成一個方塊，然後上面顯示 開始 或者 下一頁 ，退出 之類的字樣。

其次，點擊某個按鈕後，還會觸發相應的動作（功能），這個功能的載體必然是程序里的若干個函數......

從上面可以知道，在菜單里的每個元素，它背後都和一組描述其外觀有關的參數（大小，顏色，位置等），以及觸發對應的函數。

因此，為了儘可能對這些元素抽象出一個共同的模型，我們通常都嘗試結構化這些數據，最終努力的結果，必然就是一個長長的結構體成員列表。

比如下面這個：

static gui_ctrl gui_temp_screen[] =

{

,

,

,

,

, //....

, //....

};

static gui_ctrl gui_air_screen[] =

{

,

,

,

,

,

};

static menu_ctrl menu_list_ctrl[] =

{

,

,

,

};

static menu_screen menu_list_screen =

{

SCREEN_LIST,

NULL,

NULL,

NULL,

menu_list_ctrl,

3,

};

從網上搜索其他一些類似的菜單實現，包括一些「叫得出名字」的比較著名，有頗多人在討論的，比如「傻孩子菜單」，或者uCGui/emWin也是用類似的結構體去描述。

結構化參數描述的難題

這樣描述一開始很好，但很快就會遇到很多問題：

如前所述，為了使用儘可能少（一般希望只用一組）的結構體去描述所有可能的界面元素，我們通常會根據當前已知的所有元素都抽象出一組通用的參數描述。

抽象不是難題，難就難在GUI元素千變萬化，你曾經描述了的界面元素會不斷擴展，當你想用上一個產品的GUI抽象，去定義下一代產品界面時，或者你採用了新的顯示器件，有了不一樣要求的顯示小姑，你會經常發現，原先的抽象突然不適用了，並且不一定是簡單擴展幾個參數就能解決問題的。

更糟糕的問題是：當你為了通用，而用了越來越多的參數去描述時，你會發現初始化控制項時要填寫的參數越來越多，而它們對於大多數控制項來說可能是個無效值，但你卻要每一個控制項都填上一遍 NULL或者 0(如上面舉的我自己前幾版FreeUI的配置），這對於應用編寫者是一種巨大的負擔。

我做菜單和GUI始於2014年，當時我在做一個具有7寸彩屏的充電樁控制板。最開始用的是市面上常見的串口組態屏，應該說，我後來對於做界面都始於這個屏給我的啟發。

到後來，我的任務是仿這個屏開發我們自己的GUI系統，這是我第一次做完整的菜單和GUI，前後大概花了一個多月時間，在這段自己實現一遍的過程里，我對當時的這個組態屏和GUI有了更多的想法。

此後兩年，我換了工作，做了不一樣的產品，但對於GUI始終印象深刻，期間我見到了一些不一樣的設計，自己的想法也經過了不斷地錘鍊。

這些不同的產品中，其中有一些我個人十分推崇，比如對於採用文本描述，最初是一款叫做大器智成的工業屏，也不知道現在還有沒賣，到後來，也就是現在淘寶上一片撒開在賣的 usart hmi，說實話我對於UI的設計和思路，從外觀上看和它極其相似。

這裡當然不需要糾結到底誰比誰先想到，更不用說什麼誰抄誰，反正我當時還沒推出我自己的開源FreeUI,而它是商業產品，更不可能開放源碼，我也就無從有機會去抄襲它。

因為從此前採用現成的產品時發現，很多時候廠商的設計，在使用中會發現很多不方便和問題，但是，因為沒有足夠的訂單量，也沒辦法要求廠商針對我們做出什麼改進。因為說到底，看不到源碼，所以我很早就決定自己做一個開源菜單-GUI框架庫。

於是就有了後來，大概在2016年前後推出的 FreeUI。（我push在osc git上）

這時我換了工作，沒有明確的產品界面設計要求，為了嘗試不同的界面，也為了驗證我之前做的那套GUI適應性如何，我選了一塊黑白12864屏。

於是我突然發現，我原來設計的那套抽象不再適用。

所以這次重寫里，實際上和之前充電樁工作的時候已經頗為不同，但因為我對文本分析的直覺性的恐慌和抵觸，我仍然抱殘守缺地堅持結構化參數。

直到最近這次，因為我做的這個東西是一個只有一兩寸的小屏，而且它的顯示外觀設計也非常不一樣。在幾個月的掙扎里，我最終發現，結構化參數這種方法真的失靈了。

從移植我原來開源的FreeUI方案，前前後後我改進了三四版，直到最後一版，我抱著豁出去的心態：嘗試了我早就想嘗試的純文本描述，徹底放棄結構化數據的想法。才真正感到這才是一條應該堅持的正確道路，不管中間會遇到什麼難題，都不應該因為害怕而倒退到從前。

因為，文本的最本質特徵就是 以接近人類自然語言的方式去描述，從前面所寫可知，GUI最大最大的特徵，恰好就是靈活多變，因此，妄圖以一套預設的固定結構化參數去描述，註定是要失敗的。

事後我大致審視了一下純文本這個方案，和以前相比，在性能上的變化。

空間開銷，實際上，它的實現，程序體積更小，這是實在超乎我想像的。唯一有點變化的是，表達想通的信息，採用字元串當然相應的要比數值大一些，但這部分實在微不足道，不足掛齒。

時間開銷，我當時沒來得及做一個完整的測試，但從單項測試來看，運行時間變化不大，就更不要提在應用層面上的響應速度，幾乎毫無變化。

再看GUI的配置，那實在是一個質的飛躍，因為它沒有任何的結構化參數項，完全是字元串，所以替換起來當真不費吹灰之力，而且使用者幾乎毫無經驗，稍微向他介紹一下幾個命令的寫法，馬上就能上手。

他山之石

寫代碼的人，總是不能不考慮的就是，自己正在做的事情，是否已經有了類似的現成實現方案，這裡當然指的是網路上的開源部分。

首先要明確的是，這是一個應用在單片機上的方案，因此它有兩個顯著的特點：

1.空間開銷要求比較小，對於大多數單片機來說，FLASH一般在十幾K到幾十K上百K，RAM一般在幾K到十幾K。

2.對功能的要求不很多，不需要像qt那般（也太大）。

事實上，這幾年斷斷續續做GUI的時間裡，我也有試過搜索網路，其實始終沒有找到一個合適的方案。

即使是大名鼎鼎的uCGui/emWin也是，因為它早在v3.90版本之後，官方就不再放出代碼，更別說它從頭到尾都是商用收費。

即使我後來了解到它也有控制項部分，而非只是傳統的多窗口模式。但這時我對它已不再感興趣。

反而，我對於文本描述這種方式很感興趣，因為我發現，它和web前端應用中的html超文本描述（css），搭配javascript實現動態交互，以及後來發展的xml這些通用的超文本格式有相通之處。

因此後續，有可能的話，我會考慮參考xml等格式來確定一下自己這套東西的協議設計。

至於說照搬xml或者javascript這個則目前沒太大可能，因為儘管這樣會讓它更通用，但是，xml javascript所需要的解析器，對於單片機來說，實在是不可承受之重。

另一個要參考的則是 mvc模型。

工程師節

精彩活動

2017年6月6日，「第三屆工程師節」隆重開啟。今年更是有「愛板網」與「電路城」的加入，除了延續以往的兩大活動之外，第三屆「工程師節」還添加了「我是評測師」和「我是方案大師」兩大在線互動，讓工程師們在盡情揮灑自己才華的同時，獎品也會拿到手軟。

掃描下方二維碼，參與進來吧！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！