回到今天模型-视图-事件的话题，Data和View分离后必然需要有Event事件的监听和派发机制来建立起数据绑定，我控制欲比较强不是很喜欢AngularJS那种dirty checking的机制，有事件变化我希望马上被通知到，做我该做的处理，至于有人担心性能问题那是多虑了，图形组件发展这么多年已积累无数成熟技巧来规避事件的性能问题。

性能问题倒不用担心，毕竟这方面任务大部分情况都是交由框架实现者去考虑，但不需要用户深入了解框架的实现细节，并不意味着用户可以完全不关系基本架构脉络，框架应用者还是有必要了解模型-视图-事件之间的引用关联关系，否则容易出现内存泄露的问题，以前经历过一个客户团队设计的客户端框架，可管理所有界面的窗口，结果出现总是OOM的内存溢出，帮他们检查后发现，他们有个全局的WindowManager对象，在每个窗口创建时都会添加对窗口的引用，这样固然貌似很强大，全局都可以控制所有界面窗口，但因为绝大多数开发人员，不会在窗口关闭要销毁时主动去删除全局WindowManager对象的引用，进而导致了所有窗口都能被全局对象引用到而无法垃圾回收，因此框架的使用者还是有必要多框架的机制有所了解才能避免这类的内存泄露问题。

很多情况下内存泄露不是长期的运行也很难发觉，但对于HT的Graph3dView这种基于WebGL的3D组件问题尤为明显，因为大部分浏览器对单个页面能运行的WebGL上下文是有限制的，例如PC上的chrome或firefox也就运行十五六个，手机平板等移动终端会更受限，因此如果出现内存泄露老的上下文没关闭，超越上限时就会出现类型”Too many active WebGL contexts. Oldest context will be lost.”的异常。