性能的关键点

[xinglie]

编译

基于magix的项目背后有自己的打包工具：https://github.com/thx/magix-composer

该工具不仅做代码编译，同时也检测项目中样式：未使用的、重名的、不推荐的写法等问题。检测项目中模板：使用未声明的选择器、未声明的变量、参数传递等问题。

在编译转换的同时，保证代码质量，确保每个人都写出合规的代码。

在做模板转换时，工具会尽可能的检测出模板中哪些是动态的，哪些是静态的，哪些是一次生成可反复使用的，一个变量变化引起哪些模板变化等各种信息，用于运行时最小化的改变界面。

在我写过的文章中可以查看：局部刷新与模板
模板编译与优化

简单来讲：通过离线的编译，使用工具提前优化好相关的代码，减少运行时不必要的处理，因为性能是从点滴做起的。

运行

编译后的代码终归是要在浏览器里结合最新数据来渲染出界面供用户使用的。

模板的处理

在我以往的文章中，谈过运行时的界面更新，magix中的界面异步更新
以及在这个仓库的边界说明也聊到该项目中使用的底层技术原理及方案

底层框架及方案力求使用最少的资源来支撑更庞大的上层建筑。给定一台计算机，它的性能就是1，底层方案占用的资源和性能越少越好，这样在上层的其它应用更有发挥空间

dom事件

为了全局管理，magix在document.body上统一使用代理的方式处理dom事件。同一种类型的事件，比如click，任意view可注册n多click事件，但在magix框架层面，只会注册一次。不同类型的事件，比如click和keydown，在magix框架层面使用同一个事件回调处理函数，减少对象的创建。在这个统一的事件回调里，再根据编译工具提供的相关信息，直接定位相关联的view及调用开发者提供的事件处理程序，无须任何查找算法。

事件代理靠近document的根节点，性能不一定就下降，这取决于统一的事件回调里，如何处理事件冒泡、嵌套等方案。

得益于编译时的方案，在编译过程中，对模板中的事件属于哪个view可以提前确定，相同类型的事件在一个view中有没有嵌套，也是可以提前确定，并把信息传递给运行时。

在运行时，使用编译时提供的信息，事件发生后，无须层层向上遍历dom节点，即可知道当前事件需要哪个view处理，处理完后，向上嵌套的还有没有相同的事件，来决定中断还是继续调用。

其它关于性能的点这里不再一一描述。

做一个高性能的程序是需要从方方面面，点点滴滴积累起来的，任何一个环节都需要仔细，不漏掉任何一个可以优化的点