1.首先调用starting()方法,其内部是一个对所有listener的starting()调用的for循环,然后每个listener调用另一个starting方法,其内部调用multicastEvent方法,其又调用其他multicastEvent方法,其又继续调用其他的multicastEvent方法,然后在里面进行了这样的逻辑:先根据事件类型获取到合适的监听器,然后对这些合适的监听器遍历,每一个监听器都开启一个独立的线程去执行监听(具体放在下一节)
2.其中获取到合适的监听器很重要,如何匹配?
下述方法表示先从缓存中获取,如果没有再老老实实地检索合适的监听器,然后再将检索到的监听器放进缓存,最后返回监听器,这样做的好处是下次再用到相同的监听器,可以走捷径,很快.其中有一个核心方法:检索监听器
3.如何检索监听器?retrieveApplicationListener方法
该方法表示从两条途径检索合适的监听器:一条是从现有的监听器列表中检索,一条是从现有的监听器实例列表中检索.
但不管从哪里检索,它们的核心检索方法都是一样的--->判断是否支持该事件类型的supportsEvent()方法
4.supportsEvent()方法如何运作?
该方法表示当前遍历到的监听器必须同时支持事件类型和事件源类型,才能成为合适的监听器.核心方法是supportsEventType()和supportsSourceType().
5.supportsEventType()和supportsSourceType()两个方法看上去长的差不多,没错!它们的原理也差不多,都是两个字:"比较"看是否支持.所以我们只需要看supportsEventType就明白如何运作.
该方法有个if-else判断,两个分支的核心方法名字看上去还不一样,其实if中的supportsEventType()方法本质和else中的isAssignable()目的都一样,也就是名称不一样而已,核心还是两个字:"比较"
6.说了两次"比较"了,那什么是比较呢?
就是将方法指定的事件类型与传入的事件类型比较,如果前者是后者的超类,则合适,否则不合适,如下:一个例子
补充:此处的isAssignableFrom()方法已经到底了,是native方法,作用就是比较前者是否是后者的爹.
7.上面只是ConfigFileApplicationListener监听器中supportsEventType方法的实现,其实很多监听器都有自己的实现,每种监听器都在自己的实现中规定了自己感兴趣的事件类型和事件源类型,正因此,才能与传入的事件类型做比较,从而判断自己应不应该监听它.如下面这个监听器,其感兴趣的类型与上面不同:
8.说完了如何比较事件类型,也就说完了如何比较事件源类型,因为他们的原理完全一样,都是通过判断传入的类型是不是自己内定类型的子类/实现类,从而确定要不要监听它.
但是,不同的监听器都是调用同一个方法去比较的,如何做到的?这就是本源码分析中一个比较有意思的问题,答案是这里使用了面向接口编程
所有的监听器都实现了GnericApplicationListener,当真正的实例调用supportsEventType()方法时,它们只会调用到自己所在的实现类的方法,从而达到"和而不同".
9.以上浅见,感谢指正!
