jQuery EasyUI响应式布局的实现过程

EasyUI的fluid布局

首先解释一下本篇文章标题中提到的“jQuery EasyUI响应式(fluid)布局”，这里是指页面内的组件实例能够随着浏览器窗口大小的不同或者大小的变化自动调整组件实例自身的大小，比如自动100%填充，百分比宽度。

EasyUI 1.4版本之前，只有一个fit属性(布局类和表格类组件)，用以实现组件宽度和高度同时按照100%比例自适应父容器大小。

到了1.4版本，新增了一个宽度百分比(布局类、表格类以及表单类组件)，用以实现组件宽度按照任意百分比自适应父容器。

尽管使用上分为fit和百分比，但是他们的实现其实是统一的，都是一个逐级调用子组件相关方法的过程。

什么时候需要重计算和重绘

响应式布局其实就是组件对自身元素大小位置的重新计算，然后重绘自我以及子组件(需要计算和重绘的)。有两种情况会触发这种计算和重绘：
一是浏览器窗口大小调整会触发计算和重绘，具体是通过window对象的resize事件实现的。
二是组件本身大小调整，或者显示隐藏状态的切换都会触发计算和重绘，比如layout组件region大小的调整，tabs组件标签页的切换等，具体是通过组件内部代码实现的。

嵌套组件fluid的实现机制

仅仅对某个组件实例自身计算和重绘是很简单的，但是某组件实例自身的改变，势必对其子组件造成影响，“EasyUI是如何在重绘组件自身后完成重绘所有需要重绘的子组件的？”，这是一个很有必要弄清楚的问题。

首先，对子组件的重绘一定是按照级数层次逐级来的，不可能先重绘孙子辈的组件再重绘儿子辈的组件。

再者，是一些我分析源码后得到的结论（基于1.4版本，之前的版本实现思想类似，但是包装不同）：
所有布局类组件和表格类组件的自适应计算和重绘全部使用的是panel的相关接口（表单类组件除外）；
panel实例的DOM绑定一个自定义的”_resize”事件，事件处理器内部调用panel组件的”resize”接口；
panel组件的reszie接口内部会调用panel组件的doLayout接口；
doLayout接口会寻找下一级需要重绘(包含表单类组件)的子组件；

现在来说明具体的实现机制。我们假设有以下DOM结构,class为panel的DOM代表布局类或者表单类组件的实例，不带class的DOM是普通的DIV。

<div id="a-0" class="panel">
    <div id="a-1">
        <div id="a-1-1" class="panel">
            <div id="a-1-1-1" class="panel">...</div>
        </div>
        <div id="a-1-2" class="panel">
            <div id="a-1-2-1"></div>
        </div>
    </div>
</div>

第一步：“a-0”被触发计算和重绘，具体通过其实例的resize接口实现，resize接口最后调用doLayout接口；
第二步：“a-0”的doLayout接口搜索到“a-1-1”和“a-1-2”两个组件实例需要重绘，调用他们的resize方法；
第三步：“a-1-1”和“a-1-2”各自调用自身的resize接口重绘自我后，在各自调用自身的doLayout接口；
第四步：“a-1-1”的doLayout接口搜索到:“a-1-1-1”需要重绘，“a-1-2”的doLayout没找到需要重绘的组件，搜索结束；
第五步：“a-1-1-1”调用自己的resize接口重绘自我后，在调用自身的doLayout接口；
第六步：“a-1-1-1”的doLayout接口搜索不到需要重绘的组件，到此全部结束。

通过这个例子，我想这个过程应该就很清楚了，尽管我描述成这个样子，大家可能觉得很简单，但是其内部组件的依赖继承关系还是比较复杂的。抓住中心的实现思想，一切问题才有解决的思路。

性能问题

doLayout对“下一级响应式布局组件”的搜索代码是有很大优化空间的，当页面DOM结构很复杂的时候，特别是有大数据量表格的时候，在IE下的doLayout的搜索效率惨不忍睹，可以使用“children方法+递归调用+对普通表格不搜索”的方案优化。