關於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的網站 http://tool.oschina.net/codeformat/js/ 。將jquery.easyui.min.js格式化成了可以查看的格式，但是混淆是沒有辦法的。

　　通過Chrome自帶的Network調試發現，有一個datagrid請求的數據已經在后台生成，但是Content Download就是特別長，如圖，12.17s，着實讓人難受。

　　后來發現有多個datagrid在同時刷新數據，因為js是單線程的，其他的刷新代碼在運行的時候，這里只能進入等待。

　　下面來逐個datagrid調試，也許是共性問題呢？！

　　對着被格式化的easyui框架代碼，代碼如圖：

這樣看上去就清晰了很多，分別對function的內容最前面添加console.time('function名稱')，最后面添加console.timeEnd('function名稱')。經過調試運行后定位到運行速度較慢的，再一步一步的往下挖，最終挖到了fitColumns有關的代碼：

　　　　if (_65c) {
            _5cd(_65c);
            $(_65b).datagrid("fitColumns");
        } else {
            var _65e = false;
            var _65f = _613(_65b, true).concat(_613(_65b, false));
            for (var i = 0; i < _65f.length; i++) {
                var _65c = _65f[i];
                var col = _614(_65b, _65c);
                if (col.auto) {
                    _5cd(_65c);
                    _65e = true;
                }
            }
            if (_65e) {
                $(_65b).datagrid("fitColumns");
            }
        }

 看到了_65e=true;可是初始配置里寫了fitColumns:false呀，這是怎么回事呢，再翻開配置代碼一看，如圖：

 A列和B列是沒有設置width，導致datagrid在渲染之前要重新計算width，即使是隱藏列，這么做大概是為了讓系統顯示隱藏列的時候不用再次計算吧。

添加上width之后，datagrid運行速度立馬快了，Content Download變得很小，問題定位成功，Bug解除。