javascript 關於類型判斷的不同方法 和效能的 思考.

.目前 主流的判斷方式 是
var obj='franky';
return Object.prototype.toString.call(obj)=='object String';
這種方式..不得不說 這種方式很優秀 除了代碼量比較多一些... 但是它在 非ie瀏覽器中的效能表現十分優秀...
有些朋友可能會奇怪 這個不是專門判斷是不是 Array的麼. 考慮到typeof 返回 object  以及 iframe new Window()  等其他window.Array!= 當前表單的Array 這一情況. 那麼String類型為什麼也要用這個呢? 直接typeof 不也可以麼? 答案是否定的.  typeof new String('franky') =='object' 而不是我們期望的 string..

那麼現在我們看看 另外一種判斷方式. 這個方式 是我一直使用的方式. 雖然我已經打算放棄它..原因後面說.
以前我用return obj!=null && obj.constructor==String.toString();
後來改成return obj!=null && obj.constructor.toString()==String.toString();
因為 系統自動調用constructor.valueOf() 的效能不如直接給.toString()
這種判斷方法 我以前想當然的認為 沒有 Object.prototype 沒有call 應該效能高些 .而事實上在ie中也確實是這樣的
ie6 ie7 ie8 都是這樣. 確實比 主流方法要快一些.
但是 在非ie瀏覽器  (做過測試的有 opera9 10,safari 3 4,firefox 3.1 3.5,chrome 1 2)   主流方法 要比 constructor的判斷法 塊10倍的速度.

這裡 就有個取捨的問題.  目前國內的 一些調查表明 90+% 的使用者仍然在用ie .   那麼我們是為了10%的客戶 來考慮效能 還是 為了90%的客戶來考慮效能呢?
當然這個調查 也太偏頗 . 還要考慮到 年輕人使用瀏覽器的比例... 大概用ie的 還是中老年 以及電腦知識匱乏人群 .比較多一些. 那麼 最佳化方面 就要考慮到  網站所對應的主要人群...

我之所以絕對還是選擇主流方法 是因為 非ie下 10倍的優勢  而ie下的優勢 也就是2倍甚至更低(ie版本不同)...的優勢...  有些沒必要僅僅計較.

那麼我的朋友 Nouo 提出 另外一個 判斷方式.

對於typeof 有效 先用typeof 然後再用 主流或constructor方式判斷 即
return typeof(obj)=='string' || Object.prototype.toString.call(obj)=='object String';

他的理由是. 一般我們直接判斷一個類型的時候 比如 isString(obj)  我們首先期望它是一個 string的情況比較多. 比如 我希望參數是 string而如果不是則拋出異常的情況...  但是 可能我們有時候還是要 做一些類型判斷而使用其他邏輯 . 那麼 一旦傳入的不是 string類型 或 new String()  那麼就要多一次判斷的時間...
所以這樣做 我還是不贊同的.   不過 不得不承認 直接的typeof 是效率之王.. 遺憾的是它總是有這麼多缺陷...

通過以上的 幾個方法 我們可以得出大致以下幾個結論.
1. ie瀏覽器中訪問 obj.constructor的效能還湊合 至少比找Class.prototype.method.call() 要強一點點.
2. 非ie瀏覽器中訪問obj.constructor的 速度十分可悲. 
3. 如果 一個對象和一個實值型別做比較運算 能手寫調用 toString或valueOf 方法最好直接調用 而不要期待瀏覽器 自動調用. 效能會有提升.(積少成多...)

那麼 到了這裡 似乎我們最終 只是拋出一個問題 留給大家. 即 你們的網站  是優先考慮ie還是 不值得為了那一點點 的效能提升 而大廢周章 (還要犧牲掉其他瀏覽器 的相對巨大的效能損耗).  我還是傾向於 後者.....