隨著 Unity 4.6 發佈，新 UI 系統終於與大家見面了。
這篇文章將不會介紹如何使用按鈕、滾動條之類的UI控件，這些內容可以參考 Unity Manual；
這篇文章的重點是，如何理解 UI 系統的設計，以便更好的在實際中使用、自定義和擴展。
EventSystem 如果你使用 UI 系統，那麼 EventSystem 對像會自動創建。這個對象負責監聽用戶輸入。默認情況下，在電腦上可以使用鍵盤和鼠標輸入，在移動設備上可以使用觸摸輸入。但是如果你要為surface這樣的設備開發，你也可以同時啟用兩種輸入。當需要屏蔽用戶輸入時，將此對像關閉即可。UnityEngine.EventSystems.EventSystem.current 保存了當前活動的 EventSystem 對象。
Canvas Canvas 是其他所有 UI 對象的根。
在一個場景裡 Canvas 數量和層級都沒有限制。子 Canvas 使用與父 Canvas 相同的渲染模式。
一個 Canvas 有三種渲染模式：
Screen Space - Overlay：UI元素相對於屏幕空間，以2D方式顯示在任何相機畫面的上面。這是非常標準的 UI 風格。典型例子：大量窗口、文本和按鈕的策略遊戲。
Screen Space - Camera：UI元素相對於屏幕空間，由指定的相機負責顯示，相機的參數影響顯示的結果。你可以把 Canvas 理解為相機的子物體。典型例子：射擊遊戲屏幕上的 3D HUD。
World Space：UI元素相對於世界空間，和其他場景裡的物體一樣有世界位置、遮擋關係。通常用來做非常創新的 UI 設計。例子：遊戲內的手機屏幕、與場景綁定的遊戲指導等。
CanvasScaler 這個組件負責屏幕適配。
UI 系統使用 RectTransform 來計算 UI 的位置和大小，但這還不夠。如何讓設計的 UI 可以適配不同的分辨率、寬高比和 DPI？這個組件給出了以下3種適配方法，注意任何一種適配方法都不會改變UI的寬高比和相對定位。
Constant Pixel Size：通過調節 Canvas 像素大小來維持縮放不變。它的意思是不根據屏幕分辨率調整 Canvas 的縮放係數，而是調節 Canvas 的像素大小總是與屏幕保持一致。你可以手動或通過代碼調節 Canvas 的縮放係數。這是 UI 系統默認的適配方案。如下圖兩種分辨率下相同的UI顯示的不同之處，雖然不同屏幕下UI元素定位、大小沒有發生變化（圖中兩個白色元素定位分別為屏幕左上角和右下角），但是較小的屏幕上UI元素佔用了大部分屏幕空間，顯得更擁擠。這就是這種適配方式的缺點，小屏幕太擁擠、大屏幕太空曠，沒有考慮到屏幕的分辨率和DPI。但是這種模式的好處是UI元素可以保持設計時的細節（因為沒有縮放）。這種模式可能適用於：你希望UI在一定範圍內按原始大小顯示，這樣既可以讓UI顯示的盡可能清晰、又可以讓屏幕較大的玩家擁有更廣闊的視野，但是在太小或太大的屏幕上，你可以通過程式來調節縮放係數，不至於小屏幕被UI佔滿、大屏幕找不到UI。
Scale With Screen Size：根據屏幕分辨率縮放。這可能是大部分遊戲最方便的適配方法。在這種模式下，你需要指定一種設計分辨率，然後指定縮放的算法。無論哪種縮放算法，如果實際寬高比與設計寬高比相同，UI 都會被等比縮放。實際上，Canvas 只是保持自己的大小和設計分辨率一致。如果實際寬高比與設計寬高比不同，這時縮放算法才會影響顯示結果。縮放算法有三種：擴展、收縮 和 匹配寬高。擴展算法的邏輯是，擴大 Canvas （在寬高比上）較短的一邊，使得 Canvas 寬高比與屏幕一致。如下左圖，設計分辨率寬高比為1：1（紅色線框），實際屏幕更寬所以 Canvas 的 width 增加以匹配屏幕。這樣的算法在寬高比不同的屏幕上將始終導致UI更「開闊」。收縮算法的邏輯是，收縮 Canvas （在寬高比上）較長的一邊，使得 Canvas 寬高比與屏幕一致。如下中圖，設計分辨率寬高比為1：1（紅色線框），實際屏幕更窄所以 Canvas 的 height 減小以匹配屏幕。這樣的算法在寬高比不同的屏幕上將始終導致UI更「緊湊」。匹配寬高的算法邏輯是，根據指定的權重，同時調節 Canvas 的寬和高，使得 Canvas 寬高比與屏幕一致。如下右圖，設計分辨率為紅色線框，設定寬度和高度的權重相等（0.5），實際屏幕上 Canvas 的寬和高都被調整以匹配屏幕。這樣的算法在寬高比不同的屏幕上根據寬高權重的不同UI佈局「保真度」也不同。
Constant Physical Size：通過調節 Canvas 物理大小來維持縮放不變。它的意思是不根據屏幕物理大小調整 Canvas 的 DPI，而是調節 Canvas 的物理大小總是與屏幕保持一致。這種說法可能比 Constant Pixel Size 更難以理解，實際上他們本質是一樣的，只不過 Constant Pixel Size 通過邏輯像素大小調節來維持縮放，而 Constant Physical Size 通過物理大小調節來維持縮放。使用這種模式必須指定一個像素轉換物理大小的因數（填寫96方便在windows上進行開發）。運行時通過具體設備報告的dpi計算最終的 Canvas 像素大小和縮放比例。這種模式從設計的意圖來看，是為了適應某些超高dpi的顯示設備（比如現在的 mac 高達 5K 的顯示器），但是在我看來只不過是讓開發人員更加困惑，實際使用價值並不高。因為開發人員更關心設計分辨率，他們需要繪製明確尺寸的圖片！除非未來開發人員和玩家都使用了超高dpi的顯示器，才會開始忽略像素尺寸而僅專注於物理尺寸。
