前言
之前的过开发程中，我愈发觉得面对复杂的界面要求，最好还是用UserControl将不同模块的界面设计单独封装，以应对客户频繁地需求更改。
这样做能够在面对对不同的UI要求时，动态的加载预先设计好的特定模块的UserControl，不需要用代码对界面进行复杂的控制，否则要用代码控制一个个控件的生成与显示。设计之初费力，后面维护起来比较方便。
介绍
最近开发新工具，针对不同的模块的数据展示我设计了不同的布局单独封装为UserControl，放置在PanelControl中作为数据展示。
为了能够灵活的进行数据初始化，我给每个UserControl都订阅了主程序的通知事件。
使用委托回调的方式，主程序中调用委托，子控件控件中自动执行具体的初始化方法。
//定义一个带有一个参数的无返回值的委托
delegate void DelegateUpdateUserControl(DeviceConfig item);
//声明委托对象
private DelegateUpdateUserControl UpdateUserControl;
大事件发生
在测试过程中，数据的动态加载以及UserControl的切换展示没有问题。但随着切换次数的增加，界面变得越来越卡顿。
此时的我心中顿时警铃大作——有些该被释放掉的资源没有被释放掉？！但是每次进行界面切换，我都会调用Clear方法，将PanelControl里面的对象清空（PanelControl.Clear();），这时我开始怀疑UserControl对象仍在被主程序引用，系统无法进行GC.Collect()，对象没有被回收。
测试
我在UserControl中的订阅方法里增加一行Console.WriteLine方法，进行测试。
理想情况下每切换一次UserControl，会调用一次委托，让UserControl绑定的委托方法输出一条信息。测试却发现，第一次会输出1条、第二次输出2条、第三次输出3条...
这说明了除了第一次调用委托方法，后面每次调用都有不止一个对象在响应且数量依次增加，看来确实是每次的UserControl都没有被成功回收。
结合.NET的垃圾回收机制，断定UserControl对象还在被主程序引用，导致没有被成功释放，可鞥是没有解除委托与方法的绑定造成的。
我将针对这个问题做了以下优化：
修改以下代码：
//在切换控件时，先清空原先的旧UserControl
//清空PanelControl所有控件，通常情况下只存在一个控件
PanelControlContainer.Controls.Clear();
改为：
if (PanelControlContainer.Controls.Count > 0)
{
//获取到UserControl(PanelControlContainer)对象
UControlProperty control =(UControlProperty)PanelControlContainer.Controls[0];
//取消事件挂载，解除委托绑定
UpdateUserControl -= control.UpdateControls;
//从PanelControl中移除旧UserControl
PanelControlContainer.Controls.Remove(control);
//主动释放资源
control.Dispose();
}
以上步骤主要是取消事件挂载，解除主程序与UserControl对象之间的引用关系，及时让GC回收资源。
结果
经最后测试，调用委托后，只会有当前最新的UserControl对象响应，界面切换时卡顿的现象消失。
扩展——.NET垃圾回收机制
遇到这种情况，我们必须对.NET的垃圾回收机制有一定了解，借此机会聊聊GC回收机制。
以下内容参考《CLR via C#》(第四版)（CLR：Common Language Runtime，公共语言运行时）
在C#中，当我们创建一个对象时，它的引用会被存储在栈（Stack）中，而对象的实际数据会被存储在堆（Heap）中。这是.NET运行时自动进行的内存管理，称为垃圾回收（Garbage Collection, GC）。
每个对象都有两个开销字段：类型对象指针和同步块索引，在64位应用程序中各占8个字节。
所有引用类型的变量都称为根对象，这些根对象是垃圾回收的起点，括局部变量、全局变量、静态字段等；
CLR开始回收时会暂停所有线程，，防止线程在CLR检查期间访问对象并更改其状态；
然后CLR进入GC的标记阶段，CLR遍历堆中的所有对象，将同步索引块中的一位设为0；
然后CLR检查所有活动根，任何根引用了堆上的对象，CLR都会标记那个对象，将同步索引块中的位设为1；
一个对象被标记后，CLR会检查那个对象的根，标记他们引用的对象，如果对象已经被标记，就不重新检查对象的字段，避免引起死循环；
检查结束后，已标记的对象至少有一个根在引用，我们说这种对象是可达的，不能被垃圾回收；
GC删除未被标记的对象，把被标记的对象挪到一块连续的空间，进行压缩，避免空间碎片化的问题；
作为压缩的一个步骤，CLR还要从每个根减去所引用对象在内存中的偏移字节数，保证每个根引用的是之前的对象；
最后恢复执行之前被暂停的线程；
总结
给对象事件绑定委托，释放对象前，要主动解除委托绑定，避免出现资源无法释放的问题出现；
CLR是基于代的垃圾回收机制，自动工作并不定时释放不会再被访问的资源。
如果你觉得这篇文章对你有帮助，不妨点个赞支持一下！你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助，欢迎随时留言。也可以加入微信公众号[DotNet技术匠] 社区，与其他热爱技术的同行一起交流心得，共同成长！作者：暴走的锅巴
出处：cnblogs.com/geekfrank/p/18548348声明：网络内容，仅供学习，尊重版权，侵权速删，歉意致谢！
