关于easyui展示慢的Debug

　　同事开发的软件系统采用Easyui做的前台界面，当业务变得比较复杂之后，展示效果就变得很慢，于是我开始了原因的排查，现在已经找到了具体的原因，所以拿出来与大家一起分享调试过程。

 　　既然调试的是前端，那么我们就要将前端和后端分离，前端按格式返回数据，由于前端使用了iframe嵌套，那么我们需要在通过权限验证之后，直接打开iframe的src，带上对应的参数，再找到里面具体的执行JS代码。

　　由于后端使用了WebApi，返回的是XML格式，限制被直接查看，所以需要在Global.asax中添加一段代码：

GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();

　　可以看出这是Clear方法，它清除了系统的XML格式化支持，系统默认的格式化支持是XML、JSON，清除了第一个，那么就剩下第二个，这样我们就能顺利拿到后端返回的JSON数据了。

有了后端返回的数据，我们就可以重新起一个项目，直接从后端返回它，可以减少调试原来系统的步骤。下面就是调试前端了。

　　引用完毕js脚本，一切准备就绪。忽然发现jquery.easyui.min.js是压缩和混淆过的，这下有些犯难了，在高手的指点下，发现了一个可以格式化JS的网站  。将jquery.easyui.min.js格式化成了可以查看的格式，但是混淆是没有办法的。

　　通过Chrome自带的Network调试发现，有一个datagrid请求的数据已经在后台生成，但是Content Download就是特别长，如图，12.17s，着实让人难受。

　　后来发现有多个datagrid在同时刷新数据，因为js是单线程的，其他的刷新代码在运行的时候，这里只能进入等待。

　　下面来逐个datagrid调试，也许是共性问题呢？！

　　对着被格式化的easyui框架代码，代码如图：

这样看上去就清晰了很多，分别对function的内容最前面添加console.time('function名称')，最后面添加console.timeEnd('function名称')。经过调试运行后定位到运行速度较慢的，再一步一步的往下挖，最终挖到了fitColumns有关的代码：

 1 　　　　if (_65c) {
 2             _5cd(_65c);
 3             $(_65b).datagrid("fitColumns");
 4         } else {
 5             var _65e = false;
 6             var _65f = _613(_65b, true).concat(_613(_65b, false));
 7             for (var i = 0; i < _65f.length; i++) {
 8                 var _65c = _65f[i];
 9                 var col = _614(_65b, _65c);
10                 if (col.auto) {
11                     _5cd(_65c);
12                     _65e = true;
13                 }
14             }
15             if (_65e) {
16                 $(_65b).datagrid("fitColumns");
17             }
18         }

 看到了_65e=true;可是初始配置里写了fitColumns:false呀，这是怎么回事呢，再翻开配置代码一看，如图：

 A列和B列是没有设置width，导致datagrid在渲染之前要重新计算width，即使是隐藏列，这么做大概是为了让系统显示隐藏列的时候不用再次计算吧。

添加上width之后，datagrid运行速度立马快了，Content Download变得很小，问题定位成功，Bug解除。