UI架構和應用

我其實應該早就開始寫這篇文章了，因為寫它的初衷是回複wenzhezujie
的留言。可是寫文章既需要時間也需要心態，結果就拖了些日子。現在還是醞釀的不夠，但是至少應該開始了。

 

先把那段留言抄下來，方便參考 -- "基於Gtk做widgets與scheme/skin應該屬於應用層級，還算不上去研究UI架構的層次吧。比如Qt裡面，元對象系統，訊號槽實現機制，才屬於UI架構最核心的東西。
我不認為核心，系統設計的層次比設計UI的層次高。比如對Linux來說，核心有進程調度的機制，UI最底層有XWindow協議。 只不過可以看作這是一整套知識體繫結構。核心 視窗系統 網路等獨立的模組"

 

先談談軟體架構。在電腦科學的遠古時代，人們還是用紙帶卡片和電腦打交道的時候，並沒有什麼架構的概念，程式都是一次性的，電腦也只是用於重複的完成某個任務。之後人們自然而然的開始試圖提高勞動生產率，也就是希望寫過的東西能重複使用，於是諸如常式，函數的概念就加入進來，但是這些沒有從根本上解決這個問題。科學家們開始嘗試從理論上解決它，而建築作為一個成熟的，工業化程度很高的技術就被廣泛用於電腦軟體的研究，簡單的說，就是怎麼樣讓寫軟體和蓋房子一樣，堆幾個模組就差不多了，而不用總是從一塊一塊磚燒起，這也是為什麼系統構架師其實就是建築師（Architect）的意思。所以最初架構（Framework）就是和房子的基礎構架意思差不多，指的是軟體的基本結構 （詳細曆史請參考許許多多的軟體工程和物件導向的“巨著”，最好看英文版的）。姑且不論這麼做是不是非常合理，這也差不多是約定俗成的習慣了。

 

我認為軟體架構的另一個目的是解決或改進代碼複用的問題。在這一點上，軟體有自己獨特的地方，以分層結構為例，就是可以非常細的定義層次和介面，下面的一層都可以稱為上層的架構，因為理論上，上層的模組是不需要解決下層架構已經解決的問題，也就是說相應的代碼只應該出現在下層架構中，可以被不同的上層模組通過相同介面複用，這要求架構的實現應該有相應問題的抽象。因此抽象和介面是架構的核心。

 

在軟體發展的曆史上，出現的架構層出不窮，這是因為人的思想還是非常富有創造性的，但是能發展下去的就不多了，畢竟被許多技術以外的因素左右著。廣義上說，任何一種軟體的結構都可以被稱之為某某架構，而著力解決使用者介面問題自然就可以稱為UI架構了。但是事情並不是那麼簡單。

 

UI，顧名思義，是指使用者，也就是人，和電腦的介面，所以早先的時候也被稱為MMI（Man Machine Inerface）。因此UI的設計就是解決人和電腦互動的問題，可以歸結為輸入和輸出的問題，即電腦如何準確有效接受人的指令，然後按照人需要的方式輸出處理結果的問題。再看電腦曆史，從紙片輸入輸出到今天的3D的現實和觸控螢幕，電腦的確變得人性化了很多，UI所面臨的問題也由如何使用最初的非常底層和原始的硬體到了如何讓人們和電腦接觸時更像和人打交道（畢竟人與人的交流習慣是最自然地），甚至可以有更虛幻的身處未來的感覺。這些變化也影響了不同時期UI架構的重心。例如，在圖形介面出現的初期，要做的就是序列化使用者輸入和序列化的顯示（不能多進程、線程同時寫屏），訊息佇列之類的機制或者說架構就被設計出來了，而這些之所以成為架構而不是應用，更重要是它們抽象了一個特定的功能，被其它的不同模組所複用。到了今天，沒有人繼續花很多時間研究這些東西，因為技術已經成熟，而且UI的重心已經轉向使用者體驗上。當然由於新硬體諸如觸控螢幕的普及會帶來已有架構的更新，但這個時代的UI架構更多的是如何圍繞OpenGL提供前所未有的使用者體驗，而不是如何解決字型顯示或者有效、靈活的實現scheme/skin這些早已被解決的問題。

 

在物件導向UI設計已經成為主流的今天，不同的架構基本都是從單一的基類實現了應用相關的類和對象的基礎抽象，如JAVA的Object和Qt的QObject，同時在這個基類所實現的抽象也不是UI的特性了。至於訊息響應機制，例如MFC的訊息映射宏，Swing和SWT的listener，以及Qt的signal/slot，本質上都是基於訊息佇列和分發機制，對於應用而言，更多的是介面的區別（順便說一下，我是堅決站在signal/slot這一邊，不過其中的細節不是這篇文章的重點）。更重要的是，這些架構並不是只適用於UI，所以嚴格的說，它們是屬於應用程式架構的一部分。

 

再來談談什麼是UI的應用。我的理解這是指通常意義上的UI應用程式，物理上，它們通常以單一執行檔案的形式存在，而且依賴其它的軟體庫或背景服務/守護進程（Daemon）所提供的通用架構。所以，它們往往只針對一個特定的問題，例如EMail用戶端就是解決使用EMail的問題，因此通常它們的代碼是不會被其它應用或架構使用的，設計也相對簡單一點（我的另一篇文章
也有所提及）。

 

同一種應用在不同的環境中所包含的內容也不相同。舉例而言，JAVA的應用設計就要比OSGi的應用設計考慮的東西多一些，因為OSGi*架構*替它的應用設計好了生命週期的管理架構，同樣的道理，KDE的應用比Qt的應用就可以少考慮一些和案頭系統的整合問題。這直接反映到案頭系統的UI架構和手機，汽車系統的UI架構的內涵是不同的。

 

總而言之，我認為UI架構並沒有嚴格的定義，只要它能解決任何基礎UI的問題，也設計為能夠被其它模組，特別是上層模組複用，就可以是UI架構的一部分。其實實際工作中，很多曾經是UI架構的設計核心，現在已經不再是UI架構設計的重點了，因此過去看上去似乎是UI應用的事，也變成了UI架構的一部分，因為現在的UI應用已經不需要實現這些功能了，同樣在不同的裝置環境下，UI架構所包含的東西是不同的。