.NET中事件实现机制(下)——显式实现事件

上一篇日志提到了事件的实现方式。在浏览M$提供的Control.cs源代码时,按照设想M$应该也是采用了类似的方式去实现Control类的事件,但发现貌似不是这样。

打开Control.cs,发现M$定义了一堆object:

Capture

 

这一大堆乱七八糟的东西是干嘛的呢?

Control类作为每个Windows Forms上控件的基类,提供了各控件通用的事件。MSDN上提供的Control类的事件多达70多个,于是我们应该可以联想到M$这样做的目的。

界面上的控件都是从Control基类派生,这意味着每个控件至少都要支持这70多个事件(即使没有提供实现,Control基类也会提供实现)。假如每一个控件都存储多个委托字段,那么将会大量地占用内存。

不过还好,我们使用控件的形式相对比较固定:例如使用Button时,最常用的就是Click事件,对于其他的事件我们几乎很少会去关心。实际上,每个在界面中的控件,绝大多数都只有少数事件会被关联,而剩下的几十个在大部分时间都没有方法关联它

这是M$优化Control类内存占用的一个基本前提。那么设计自然是,只记录被关联的委托,其他的都不记录以减少内存消耗。这篇日志主要来学习下M$的相关实现方法。

还是以KeyPress事件为例,我们查看其源代码:

        [SRCategory(SR.CatKey), SRDescription(SR.ControlOnKeyPressDescr)] 
        public event KeyPressEventHandler KeyPress {
            add { 
                Events.AddHandler(EventKeyPress, value);
            }
            remove {
                Events.RemoveHandler(EventKeyPress, value); 
            }
        }

这个Events对象是在Control的基类Component中定义的,我们转到Component类的代码中查看:

        protected EventHandlerList Events {
            get { 
                if (events == null) { 
                    events = new EventHandlerList(this);
                } 
                return events;
            }
        }

再跳转到EventHandlerList的定义,M$的说明是:Provides a simple list of delegates. 这意味着Control类的所有事件委托都存储于EventHandler对象中。回到KeyPress事件的add方法(在C#中的运算符是+=,在VB中是AddHandler),它调用了这个类的AddHandler方法,这个方法实现如下:

        public void AddHandler(object key, Delegate value) {
            ListEntry e = Find(key); 
            if (e != null) {
                e.handler = Delegate.Combine(e.handler, value);
            }
            else { 
                head = new ListEntry(key, value, head);
            } 
        }

现在明白了,Control类实际上为每个对象维护了一个内部的链表,这个链表记录了对于存在的每一个事件的委托(如果某个事件没有被关联,这个链表中就不会存在相对应的委托,所以就没有内存的占用)。

所以,M$在Control类中定义的每个事件的静态对象(就是第一张图中的一堆object)实际上是这个链表中的键,在存储和触发事件时,这个对象作为主键对其对应的委托进行查找。

当添加一个不存在的委托时,会向链表中插入一个新的委托实例:head = new ListEntry(key, value, head);,否则就直接添加到现有的委托链中:e.handler = Delegate.Combine(e.handler, value);。

(备注:调用Delegate.Combine和Remove方法后,委托的引用会被更改,所以要重新设置handler使其指向新的引用。)

ListEntry是EventHandlerList的一个内部类,只是一个简单的链表而已:

        private sealed class ListEntry {
            internal ListEntry next; 
            internal object key; 
            internal Delegate handler;

            public ListEntry(object key, Delegate handler, ListEntry next) {
                this.next = next;
                this.key = key;
                this.handler = handler; 
            }
        }

进行查找时,其Find方法只是简单地遍历链表查找其相应的记录。

在触发KeyPress事件时,如果没有事件与其关联,那么在EventHandlerList中就不存在引用,什么都不做直接返回,否则调用委托回调其关联的方法即可:

        protected virtual void OnKeyPress(KeyPressEventArgs e) {
            Contract.Requires(e != null); 
            KeyPressEventHandler handler = (KeyPressEventHandler)Events[EventKeyPress];
            if (handler != null) handler(this,e); 
        }

 

至此,我们可以看到使用EventHandlerList,在每个控件只存在少量事件关联的情况下,确实可以大量减少不必要的内存开销。因此建议在实现大量事件的类时,可以参照M$的实现方式。

对于EventHandlerList,有两点需要说明:

  • EventHandlerList是一个链表而不是哈希表,因此查找速度肯定不如Dictionary。但是由于这个类存在的场景是少量事件会被关联(在Control中,平均只有少于10个事件),那么这个问题可以被忽略。特别地,在只有一两个关联事件时,使用这种链表会比Dictionary占用更少的内存。
  • EventHandlerList不是线程安全的。因此在对线程安全有要求的场景需要自己处理同步的问题。但M$提供的代码中都没有考虑线程安全,我估计是订阅、取消订阅基本都是在初始化代码中的事情,因此大多数情况都不存在这个问题。

所以,在有特殊要求的情况下(比如必须保证线程安全;或者事件实在是太多,当然不太可能事件比Control类还多),可以自己实现一个类似的东西。(注意,在定义链表的索引时必须要定义成static的,否则每个对象都会有此外,M$定义索引用的是object而不是字符串或者值类型的原因不明,但我估计是以后添加新的事件或子类添加新的事件时会很方便,子类不必关心Control类对每个事件定义了什么样的键。

对于内部使用链表而不是哈希表的问题,我个人认为应该使用链表,不赞成自己使用Dictionary替代原来的实现方式。

因为哈希表会有额外的开销(在Dictionary的实现中,会定义近10个实例字段,至少占用40个字节的额外空间;如果是线程安全的哈希表或64位系统还会更多)。而EventHandlerList对象是每个Control对象都会有的,如果有这么多额外开销反而会得不偿失。

所以我觉得在《CLR via C#》这本书中,提供的EventSet这种实现方式是不恰当的。

 

通过这个东西,我们发现M$在定义这种通用的、且到处都被用到的类时都非常小心,特别注意内存的开销。比如Control类对成员变量前的注释:Do not add anything to this list unless absolutely neccessary. Every control on a form has the overhead of all of these variables!

此外我们看到Object类没有定义任何成员变量,也是基于这一点考虑。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s