首先附上原文地址：https://unity3d.com/cn/learn/tutorials/topics/best-practices/optimizing-ui-controls

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?優化UI控件

? ? ? ? UGUI優化指南的這一部分關注于一些特殊類型UI的問題。雖然說大多數UI控件在性能方面都比較類似，但有兩個組件會使游戲在接近發布狀態時造成許多性能問題。

UI Text

? ? ? ? Unity內置的Text組件是在UI內顯示柵格化字形的一種很便捷的方式。然而有一些并不被廣泛了解的特性，作為性能熱點高頻率的出現。每當給UI增加text的時候，要知道字形事實上是作為獨立的四邊形渲染的，每個字符一個。這些四邊形周圍通常有大量的多余閑置空間，這取決于它們的形狀，text這種位置的特點造成了一不小心就會打斷其他UI元素的batch。

Text的網格rebuild

? ? ? ? ?一個主要的問題是重建UI text網格，每當text組件被改變時，文本組件都必須重新計算多邊形來顯示實際的text。這個重新計算也發生在這個text組件或是它的父游戲物體被禁用或者啟用時，雖然這個text沒有改變。

? ? ? ? 這個行為對于任何要顯示大量文本標簽的UI都是一個問題，比如說大部分的排行榜或是統計界面。由于隱藏和顯示UGUI最簡單的方式是啟用和禁用包含UI的游戲物體，當擁有大量text組件的UI顯示時將經常會出現不期望的幀率卡頓。

? ? ? ? 有關這個問題的潛在解決方案，請看下一章的Disabling Canvas Renderers部分。（鏈接見原文）

動態字體和字體圖集

? ? ? ? 當要顯示的字符集合非常大或者在運行前并不知道有多少時，動態字體是一個非常方便的方式來顯示文本。Unity實現時，這些字體基于UI Text組件中遇到的字符，在運行是構建一個字符圖集。

? ? ? ? 加載每個字體對象將會保持自己紋理圖集，即使它與另一個字體在相同的字體體系中。例如，使用Arial字體的加粗的文本在一個控件上，同時使用Arial Bold字體在另外一個控件上將會產生一樣的顯示輸出。但是Unity將會保存兩份獨立的紋理圖集，一個是Arial字體另一個是Arial Bold字體。

? ? ? ? ?從一個優化的角度來講，要理解的最重要的事情是UGUI的動態字體圖集保存了每個單獨的由尺寸、風格、字符排列組合而成的字形。也就是說，如果一個UI包含兩個text組件，都顯示字母“A”，則：

? ? ? ? 1.如果兩個Text組件擁有相同的大小，則字體圖集中將包含一個字形。

? ? ? ? ?2.如果兩個text組件不擁有相同的大小（例如，一個是16號，另一個是24號），則字體圖集將包含兩個不同大小的字母“A”的副本。

? ? ? ? ?3.如果一個text組件是粗體而另一個不是，則字體圖集將同時包含粗體的“A”和常規的“A”。

? ? ? ? 無論何時一個擁有動態字體的UI text對象遇到了一個沒有被柵格化到字體紋理圖集的字形時，字體紋理圖集就必須被重建。如果新的字形可以適配進當前的圖集，它將被添加進去，并且圖形設備會重新加載這個圖集。然而，如果目前的圖集太小了，系統將會嘗試重建圖集，分為兩階段。

? ? ? ? ?首先，圖集會以相同的大小重建，只會用到當前激活的UI text組件（包括其父級Canvas啟用，但是禁用了Canvas Renderer組件的的UI Text組件）中要顯示的字形，如果系統成功的將所有現在要用到的字形適配進新圖集中，圖集的柵格化不會繼續進入第二步。

? ? ? ? 其次，如果這些現在使用到的字形不行被適配進當前大小的圖集，一個更大的圖集將會被創建出來，將這個圖集較短的尺寸放大二倍。比如，512x512的圖集將會被擴大到512x1024。

? ? ? ? 由于上述算法，一個動態字體圖集只會在被創建后增長尺寸。考慮到重建紋理圖集的性能消耗，使重建最小化是非常必要的。有兩種方式。

? ? ? ? 如果有可能，使用非靜態字體，并預先配置好對所需字形的支持。這通常適用于對字符有非常好限制的UI，比如說只有拉丁文/ASCII字符，或者其他一個較小的范圍。

? ? ? ? ?如果必須支持一個非常大范圍的字符，比如全部的萬國碼，字體必須被設為動態字體。為避免可預見的性能問題，主要的字體字形圖集在一開始就要通過Font.RequestCharactersInTexture設置適當的字符。

? ? ? ? 請記住，字體圖集的重建是是在每個UI Text組件被改變時才會被單獨觸發。當生成極多text組件時，在text組件內容和主要的字體圖集中收集所有獨特的字符是有好處的。這將會確認字形圖集只需要被重建一次而不是每次新字形生成時都會要重建。

? ? ? ? 另外請注意，當一個字體圖集的重建被觸發時，任何目前不包含在激活的UI Text組件中的字符將不會被添加到新的圖集中，雖然他們一開始調用Font.RequestCharactersInTexture被添加到圖集中。要解決此限制，請訂閱Font.textureRebuilt這個委托并且查詢Font.characterInfo來確保所有期望的字符保持在圖集中。

? ? ? ? Font.textureRebuilt委托目前沒有公開，它是一個單參數的Unity事件，參數是紋理圖集要被重建的字體，此事件的訂閱者應當遵循以下簽名：public void TextureRebuiltCallback(Font rebuiltFont) { /* ... */ }

專門的字形渲染器

由于字形眾所周知的情況，在每個字形位置相對固定的情況下，為這些要顯示的sprite寫一個用戶自定義的組件來顯示這些字形明顯是更有益的，比分顯示就是一個例子。

對于比分，要顯示的字符就是從眾所周知的數字0-9中繪制，不會改變范圍，并且以彼此固定的距離顯示。將一個整數分解為數碼并且顯示合適的數碼sprite是相對來說無關緊要的。這種專門的數字顯示系統以一種無需配置和非常快的計算、動畫和顯示速度來構建，比Canvas的UI Text組件強很多。

后備字體和內存使用

對于必須支持大字符集的應用程序，很容易在字體導入器的“Font Names”字段中列出大量的字體。列在 “Font Names” 字段內的任何字體將會作為后備字體，在字形不能在主要字體中找到的時候。后備字體的排列順序決定于它們列在“Font Names” 字段內的順序。

然而，為了支持這種行為，Unity會將“Font Names”字段中列出的所有字體加載到內存中。如果一個字體的字符集非常大，則后備字體的內存消耗將過多。這種情況經常發生在包括象形文字的字體，比如日本漢字或者是中文字符。

Best Fit和性能

一般來說，永遠不要使用UI text組件的Best Fit設置。

Best Fit動態的適配一個字體的最大整數大小，使text組件能夠顯示在框體中不會超出框體，并限定一個可配置的最大/最小的字體尺寸。然而，由于Unity會把每個要顯示的獨立的字形的每個單獨的尺寸渲染進字體圖集，所以使用Best Fit的話字體圖集將會被迅速的被不同的尺寸的字形所填滿。

從Unity5.3開始，Best Fit使用的尺寸檢測是非最佳的。它將每一個測試的增加尺寸的字形生成到字體圖集中，這遠遠增加了生成字體圖集所要花費的時間。這也傾向于導致圖集溢出，舊字形被踢出圖集。由于Best Fit計算所需大量測試，這會經常將別的text組件使用的字形驅逐，在合適的字體大小被計算出來以后，字體圖集的重建將會被強制執行至少一次。這個特別的問題在Unity5.4中被改正，并且Best Fit不會不必要的增加字體紋理圖集，但它仍舊比靜態大小的text要慢的多。

頻繁的字體圖集重建會迅速降低運行時性能，并導致內存碎片。設置為Best Fit的text組件的數量越多，這個問題就越嚴重。

Scroll View

在填充率問題之后，UGUI的Scroll View是第二個運行時的最常見性能問題的源頭。Scroll View通常需要大量的UI元素來表現其內容。Scroll View的填充有兩個基本的方法：

1.用Scroll View內容的所有要顯示的必要的元素來填充。

2.將元素存儲起來，當它們需要表現可視內容的時候重新給他們設定合適的位置。

這兩種解決方案都有問題。

第一個解決方案需要更多的時間來生成所有UI元素，而且隨著要顯示的元素的增加，Scroll View的rebuilt的所需時間也會跟著增加。如果Scroll View中只有少量的元素，比如Scroll View只需顯示一些Text組件，那么使用這個解決方案簡單易行，最為合適。

第二個解決方案需要大量的代碼來實現正確的當前要顯示的UI和layout系統。下面將進一步詳細討論兩種可行的解決方案。對于那些大量的復雜的要滾動的UI來說，通常需要使用某些對象池的方法來避免性能問題。

盡管存在這些問題，所有的方法都能夠通過給Scroll View添加RectMask2D組件來得到改進。這個組件可以確保Scroll View的viewport之外的元素不包括在要繪制的元素列表中，在列表中的元素在Canvas的rebuild的時候必須生成它們的幾何體，排列，并且進行分析。

簡單的Scroll View元素池

實現Scroll View對象池最簡單同時保留Unity內置的Scroll View組件的大多數原生便捷性的方法是使用一種混合的方法：

在UI中布局元素，這將允許布局系統來正確計算Scroll View的content大小，并且允許scrollbar正常工作，使用掛載Layout Element組件的游戲物體來作為可見UI元素的“placeholders（占位符）”。

然后，實例化足以填充Scroll View的可視區域的可視部分的可見UI元素，并且設定父物體為定位好的占位符。當Scroll View滾動時，重用UI元素來顯示滾動到視口中的內容。

這將大大減少必須要batch的UI元素的數量，因為batch的開銷增長只基于Canvas內的Canvas Renderer數量，而不是Rect Transform的數量。

解決問題的簡單方法

目前，當任何UI元素重新設置父級，或者層級排序變換的時候，該元素及其所有的子元素都將被標“Dirty”,并且會強制rebuild其Canvas。

這個問題的原因是Unity沒有分離重新設置父級和改變其層級排序的回調。這些事件都會觸發一個叫OnTransformParentChanged的回調。在UGUI源碼的Graphic類中（見源碼中的Graphic.cs腳本），這個回調實現并執行了SetAllDirty方法。通過將Graphic標Dirty,系統可以確保Graphic將在下一幀渲染前重建其布局和頂點。

可以將Canvas分配到Scroll View中每一個元素的根RectTransform上，這將會限制重建發生的范圍只在重新設置父級的元素上而不是Scroll View的整個content。但是這也會增加需要渲染Scroll View的drawcall數量。此外，如果Scroll View內獨立的元素是復雜的并且包含了十多個Graphic組件，特別是每個元素上包含了大量的Layout組件，其rebuild的開銷也經常可以會高到顯著的降低低端設備的幀率。

如果一個Scroll View的UI元素的大小是不可變的，那么完全重新計算布局和頂點就是不必要的。然而，避免這種問題的解決方案需要實現的對象池是基于位置的改變而不是重新設置父級或是更改層級順序。

基于位置改變的Scroll View池

為了避免上述問題，可以創建一個僅僅是移動其包含的UI元素的RectTransform的對象存儲池。這樣就通過移動RectTransform避免了rebuild尺寸未改變的內容，顯著的提高了Scroll View的性能。

要做到這一點，通常最好是要寫一個用戶自定義的Scroll View子類和寫一個用戶自定義的Layout Group組件。后者通常是更簡單的解決方案，可以通過實現UGUI的LayoutGroup的抽象基類來完成。

用戶自定義的LayoutGroup可以分析底層的元數據來檢查要顯示多少數據元素，并且可以重新設置Scroll View的content的RectTransform為合適的。也可以通過訂閱Scroll View change events（onValueChanged）并相應的使用來重新設置可見元素的位置。