技術標籤：C#c#xaml

在開發 XAML(WPF/UWP) 應用程式中，有時候，我們需要建立自定義控制元件 (Custom Control) 來滿足實際需求。而在自定義控制元件中，我們一般會用到一些原生的控制元件（如 Button、TextBox 等）來輔助以完成自定義控制元件的功能。

自定義控制元件並不像使用者控制元件 (User Control) 一樣，使用 Code-Behind（UI 與邏輯在一起）技術。相反，它通過把 UI 與邏輯分離而將兩者解耦。因此，建立一個自定義控制元件會產生兩個檔案，一個是 Generic.xaml，在它裡面定義其模板與樣式；另一個是 <ControlName>.cs，這裡面存放其邏輯，如下圖：

在這種情況下，要想在程式碼中獲取到模板裡定義的控制元件，就不像 Code-Behind 中那麼容易，而要藉助於 OnApplyTemplate 和 GetTemplateChild 這兩個方法。它們的意義分別如下：

• OnApplyTemplate: 在自定義控制元件中，通常要重寫這個方法，當基類呼叫 ApplyTemplate() 方法以構造視覺化樹時，會呼叫它；
• GetTemplateChild: 獲取 ControlTemplate 中所定義的視覺化樹上指定名稱的元素；

所以，如果我們在模板中定義了一個名為 PART_ViewButton 的按鈕，那麼，我們可以這樣獲取它，併為它註冊響應事件：

        public override void OnApplyTemplate()
        {
            base.OnApplyTemplate();

            Button btnView = GetTemplateChild("PART_ViewButton") as Button;
            if (btnView != null)
            {
                btnView.Click += BtnView_Click;
            }
        }

        private void BtnView_Click(object sender, RoutedEventArgs e)
        {
            // 這裡寫響應邏輯
        }
 

當我們（或者其他人）要用這個控制元件時，通過給它設定了模板（一般都是預設模板）後， OnApplyTemplate 方法就會被執行。這樣做看起來沒什麼問題。不過，其實這裡有可能會引起一個聽起來很嚴重的問題：記憶體洩露 (Memory Leak)。

何為記憶體洩露

記憶體洩露有多種型別，一般來說，它是指某種型別的資源不再使用，但卻仍然佔用記憶體。換句話說，它從受管理的記憶體區域中“洩漏”出去了，無法被 GC 回收。如果在程式中有多處記憶體洩露，將會佔有很多記憶體，並最終導到記憶體被耗盡。

在 C# 中，常見的記憶體洩露有：

• 沒有移除事件監聽；
• 沒有銷燬非託管資源（如資料庫、檔案流等）；

對於上面兩種情況，它們的解決辦法也非常簡單，分別是：要反註冊事件（即移除事件監聽）與呼叫 Dispose 方法（如果沒有，則要實現 IDisposable 介面，並在其中銷燬非託管資源）。

對於第二種情況，比較好理解；而對於第一種情況，問題是，為什麼沒有移除事件監聽，會導致記憶體洩露呢？這是因為事件源比事件監聽者的生命週期更長。來看程式碼：

        ObjectA objA = new ObjectA();
        ObjectB objB = new ObjectB();
        objA.Event += objB.EventHanlder;

ObjectA 中定義了 Event 事件，我們為它註冊了一個事件處理器（物件 objB 中的 EventHanlder 方法）；因此，事件源 objA 對事件監聽物件 objB 存在一個引用。

如果 objB 不再使用，我們要銷燬它，但由於 objA 引用了它，所以它不會被銷燬、回收；它要等到 objA 銷燬時，才能被銷燬。所以本來需要被銷燬的物件，卻因有其它物件對它的引用，結果造成了記憶體洩露。

如何解決

再回到自定義控制元件的問題上，因為我們的自定義控制元件，可能會被重寫樣式或者重寫模板，這會使 OnApplyTemplate 方法在這個自定義控制元件的生命週期內被執行多次。所以，我們需要為那些通過 GetTemplateChild 方法得到並且又添加了事件處理的控制元件（如上述程式碼中的 btnView 控制元件）進行事件反註冊。因為這些都是前一個模板中的控制元件（元素），當反註冊後，原來的控制元件與事件監聽者（自定義控制元件本身）就不存在引用關係，從而避免了記憶體洩露的問題。

根據我們的解決思路，對之前的程式碼重構如下：

        private Button btnView = null;
        public override void OnApplyTemplate()
        {
            base.OnApplyTemplate();

            // 先反註冊事件
            if (btnView != null)
            {
                btnView.Click -= BtnView_Click;
            }

            btnView = GetTemplateChild("PART_ViewButton") as Button;

            if (btnView != null)
            {
                btnView.Click += BtnView_Click;
            }
        }

        private void BtnView_Click(object sender, RoutedEventArgs e)
        {
            // 這裡寫響應邏輯
        }

這樣，就解決了本文開頭所說的問題。不過，接下來，我們還需要做一點調整。

進一步重構

試想，如果我們的自定義控制元件中，有多個類似像前述 btnView 這樣的控制元件，我們就要將上面的程式碼在 OnApplyTemplate 方法中複製若干次，從而導致 OnApplyTemplate 方法的複雜度增加，以及程式碼的可讀性變差 。

為了改善這一點，我們將每個控制元件以及它的事件註冊與反註冊封裝一下。重構後，程式碼如下：

        protected const string PART_ViewButton = nameof(PART_ViewButton);

        private Button btnView = null;

        public Button ViewButton
        {
            get
            {
                return btnView;
            }
            set
            {
                // 先反註冊事件
                if (btnView != null)
                {
                    btnView.Click -= BtnView_Click;
                }

                btnView = value;

                if (btnView != null)
                {
                    btnView.Click += BtnView_Click;
                }
            }
        }

        public override void OnApplyTemplate()
        {
            base.OnApplyTemplate();

            ViewButton = GetTemplateChild(PART_ViewButton) as Button;
        }

        private void BtnView_Click(object sender, RoutedEventArgs e)
        {
            // 這裡寫響應邏輯
        }

針對最終的程式碼，這裡再提幾點：

1. 在 OnApplyTemplate 方法中，建議一開始要先呼叫 base.OnApplyTemplate();
2. 無論在為控制元件反註冊事件，還是註冊事件時，都要對控制元件是否為空進行判斷，這是因為有可能使用者重寫模板時沒有遵循 TemplatePart 屬性中所指定的控制元件名稱；
3. 將控制元件的名稱宣告為常量，可以避免字串拼寫錯誤；

總結

本文討論了在 WPF 或 UWP 中建立自定義控制元件時，可能會遇到記憶體洩露的問題；這主要是由於模板中的控制元件事件沒有反註冊導致的。我們不僅分析了其中的原因，也給出了針對這種情況的最佳實踐。

雖然在一般情況下，這一問題並不會造成較大的影響，但是，如果我們能夠在這些細節上注意，這樣不僅能夠提高我們的程式碼質量與程式的效能，也能夠給我們在設計或處理類似的問題時，提供必要的思路與經驗。