IEあるいはIEエンジンのブラウザ(Sleipnirとか)を使っていて、どうもページの描画速度が遅い気がする―もっと正確には最初にページを開いたときより遅くなった―と感じたことはないだろうか? 特にあなたがJavaScriptを多用したページを開いているならば、もしかしたらIE特有のメモリリーク問題(IE memory leaks problemG)が原因かもしれない。
余談ですが、前回のmoblogエントリーは、自分のブログにモブログしたつもりが間違ってこちらにエントリーしてしまいました。気が向いたら移動しておきます。
で、本題ですが、この問題はより多くの利用者が(IEエンジンの)タブブラウザーを使うようになればなるほど顕在化してくると思われるのでメモしておこうと思います。ppBlogでもJavaScriptは欠かせませんし。最初に言っておきますが、この問題はIE4-6に特有のもので他のモダンなブラウザは影響を受けません。
では、早速、IE6単体で(タブブラウザではなく)このテストページ を開いて下さい。216色のカラーチャートを作成し、その各セルにマウスイベントを設定しているシンプルなデモです。ページを開いたらリロードを何回か繰り返してみましょう。生成時間がどんどん長くなっているのを確認したら、そのページを一度閉じて、新たに次のテストページ を開いて同様にリロードを繰り返してみましょう。どうでしょうか?今度は生成時間が伸びていくということはありません。
この2つのページの違いは何でしょうか?最初のテストページでは、まさにメモリーリークが起こっています。リンク先にも書いてありますが、分かる方はControl + Alt + Del キーを押して、タスクマネージャを起動、IEXPLOERE.EXEのメモリを見ながらリロードを繰り返せばメモリが肥大化していくのを見ることができます(尚、ウィンドウを閉じればメモリは開放されます)。この2つのテストページの違いは、ほんのちょっとしたことです。やや専門的になるかもしれませんが、イベントを定義する関数を定義しているのですが、その扱いの違いです。もともとは、Scott Andrew (最近は専ら音楽に夢中のようです。。)がW3CとIE特有のイベント定義関数の差を吸収するために作り出したaddEvent/removeEvent関数ですが、オリジナルのままでは、IEのthis参照に問題があったために、様々なバージョンが編み出されました。ppBlog1.5βでも似たようなやつを付けていますが、ここに挙げるのはその改訂版です。まず、メモリリークを起こすやつから。
function addEvent(obj, evType, fn){
if(!obj["_"+evType]){
obj["_"+evType] = [];
if(obj["on" + evType] != null) obj["_"+evType].push(obj["on" + evType]);
obj["on" + evType] = function(e){
var e = e || window.event;
for(var i in this["_"+e.type]) this["_"+e.type][i].apply(this,[e]);
}
} else {
for(var i in obj["_"+evType]) if(obj["_"+evType][i]===fn) return;
}
obj["_"+evType].push(fn);
};
function removeEvent(obj, evType, fn){
if(obj["_"+evType]){
for(var i in obj["_"+evType]){
if(obj["_"+evType][i]===fn) delete obj["_"+evType][i];
}
}
};
addEventの中で、匿名関数を使っています(ホナ トピンクの部分)。次にメモリリークを起こさないやつ。
function addEvent(obj, evType, fn){
if(!obj["_"+evType]){
obj["_"+evType] = [];
if(obj["on" + evType] != null) obj["_"+evType].push(obj["on" + evType]);
obj["on" + evType] = evokeEvent;
} else {
for(var i in obj["_"+evType]) if(obj["_"+evType][i]===fn) return;
}
obj["_"+evType].push(fn);
};
function removeEvent(obj, evType, fn){
if(obj["_"+evType]){
for(var i in obj["_"+evType]){
if(obj["_"+evType][i]===fn) delete obj["_"+evType][i];
}
}
};
function evokeEvent(e) {
var e = e || window.event;
for(var i in this["_"+e.type]) this["_"+e.type][i].apply(this,[e]);
};
具体的に各オブジェクトにイベントを設定していく部分をaddEvent関数の外に出していますね。おかげで関数が3つになっちゃってます。世の中の多くのJavaScriptの書き手は、「スクリプトはシンプルなのがスマートだ」という理念を持っていて、自分もその一人です。その結果として関数内の匿名関数やクロージャーを多用する傾向にあります。悲しいかな、IEにはこれが通用しないのです。もっと詳しくこの問題を理解するキーワードは、「クロージャーclosure」と「循環参照 circular reference」です。ここで詳しく解説しようとは思っていないので悪しからず。以下のサイトを参照してください。Richard Cornfordのサイト が端的にこの問題を指摘しています。
The Internet Explorer web browser (verified on versions 4 to 6 (6 is current at the time of writing)) has a fault in its garbage collection system that prevents it from garbage collecting ECMAScript and some host objects if those host objects form part of a "circular" reference. The host objects in question are any DOM Nodes (including the document object and its descendants) and ActiveX objects. If a circular reference is formed including one or more of them, then none of the objects involved will be freed until the browser is closed down, and the memory that they consume will be unavailable to the system until that happens.
- Javascript Closures by Richard Cornford
- James Mc Parlane's Blog - IE, Closures, Leaks
- Understanding and Solving Internet Explorer Leak Patterns (Windows IETechCol)
- [Mishoo] IE: where's my memory?
この問題は、Microsoftも認識しているのでIE7では解決されると良いのですが。尚、上に挙げたサイトで、最後のMihaiのページもよくまとまっているのですが、Mihaiが例示しているメモリーリークの退避例でも、やはりリークが起こるような気がします。
あと、メモリーリークを起こすページを検出するツールがあるので、これもリンクしておきます。もっとも、このツールは完璧ではなく、すべてのメモリリークを検出するわけではないですが目安にはなるかと。メモリー負荷テスト(Blow memory)は、メモリーが増大していく様を見れるので有用です(もっともタスクマネージャーでも見れますが)。
Out of Hanwell:IEメモリリーク検出ツール
タブブラウザが出てくる以前は、この問題はさほど気にすることもなかったかもしれませんが、タブブラウザでは、常に複数のページを開いているというのが当たり前ですし、AJAXの台頭で、これからもJavaScriptはwebページで多用されるでしょうから、この問題を認識しておくのも悪くはないと思います。自分みたいなプログラム配布者はなおさらです。
あ、あと、スコット・アンドリューがaddEvent/removeEventについて最初に紹介したページを見付けたのでリンクしておきますね。 →http://www.scottandrew.com/weblog/articles/cbs-events
martin 2005/12/02@18:39:22