工作中需要頁面資料的實時重新整理，採用了jquery的ajax實現，前後臺使用json格式資料通訊。有兩個定時器，每3s重新整理一次，執行一段時間後發現頁面記憶體占用了900+m，太恐怖了。除錯步驟如下：
1、ajax回傳資料後不做任何操作，在success中直接return，發現記憶體持續增長，沒有緩解，初步斷定是jquery的問題，jquery採用了1.5.2版本，查詢各方帖子，都說是xmlhttprequest物件的問題，需要清空該物件，jquery唯一能做的就是使用：complete: function (xhr, ts) 。推斷xmlhttprequest依然沒有釋放。
2、更新jquery版本，將版本更換到比較穩定的jquery1.2.6版本，發現記憶體不再瘋狂增長，開始了有增有落，這是個好現象。
3、去掉步驟1中增加的return; 放開後便的js繼續執行。發現了記憶體依然緩慢增長，雖然增幅不大，但是還在增長，頁面長期停留肯定依然會出現問題。繼續跟蹤js**，發現頁面元素的click事件每次重新整理時都重新註冊了一次，懷疑是他的問題，遂關閉click時間註冊，頁面重新整理後發現記憶體不再持續增長，賓果！ 原來是click多次註冊的問題。後來將click事件註冊放到了init方法中，頁面初始化函式僅執行一次，初始化頁面結構，註冊各種事件，重新整理函式定時重新整理頁面資料。在多次測試後均沒有重現問題。本著預防為主防止結合的方針，最後在頁面中也增加了定時重新整理整體頁面的定時器，不過設定了乙個小時的時間。大可不必擔心頁面整體重新整理降低了使用者體驗。
5、頁面中還需要注意到的一點是適用jquery的 html()函式，該函式不是基於innerhtml實現的，大量使用同樣也會導致系統效能下降，可以自己重寫一下：
/**
jquery html方法導致記憶體增長問題優化 請呼叫html2方法
$("#id").html2()
**/$(function())();
jquery.fn.extend(
var rel = jel.get(0);
if (rel && window.recycler)
delete rel; rel = null;
delete len; len = null;
delete cld; cld = null;
delete jel; jel = null;
},html2: function(value, raw) } }
});
});
頁面中如果元素過多，且需要為每個元素註冊相同的click事件，這個時候我們優先考慮到使用委託機制，將需要註冊的click事件註冊到元素的上層元素或者頂層元素，這樣我們就節省了大量的click註冊事件。
總結：頁面定時重新整理導致頁面占用系統記憶體會持續攀公升。
1、更換更穩定的jquery版本，版本不是越高越好啊
2、防止出現事件重複註冊情況（少量的重複註冊不會影響效能，如果把註冊事件放到了定時器中註冊，就得小心了）。
3、不要頻繁的新建、刪除介面元素，可以初始化元素然後在復不同的值。
4、大量使用jquery.html()函式。
5、使用委託替代直接的元素事件註冊。
實時重新整理MFC的EDIT控制項
今天有個同事談到了實時顯示mfc的edit控制項，我想了下，只能新增執行緒才能完成這個目標。但執行緒中不能使用updatedata函式。想到兩個解決方案，1.傳送訊息，把執行緒中的資料傳送到主線程進行實時顯示 我沒試，但肯定可以實現 2.使用getdlgitem通過id來顯示資料。unsigned ...
記憶體引發的風波故事
昨天，記憶體引發的風波故事 2012.02.25 本來機子就2g記憶體，於是就買了一條2g的爾必達，沒想到裝進去居然沒有識別3g多，反而只有2.43g，當時我就暈了，這不是虧大了嗎。網上找了解決方法，卻得到的結果是自己的機子說什麼bios識別不夠，最多只能識別2.43g，要想破解可以，但是會影響系統...
不同Jquery版本引發的危機
這是最近三個月寫得最完美的作品了，用js實現了乙個拖拽排序，效果圖如下 就在我實現的同時，師姐幫另乙個夥伴寫了乙個傳統方案的demo,他進行的是修改的排序。在她機器上演示的時候，當時就覺得很震撼，在她的滑鼠滑動下，走馬觀花了一遍 看著長長的鏈式js，頓生仰慕。當時就想，等專案結了，好好研究她這個。2...