反射是相當強大的乙個機制，它允許在執行時發現並使用編譯時還補了解的型別或成員。但是，它有下面兩個缺點。
1，反射會造成編譯時無法保證型別型別安全性。由於反射要嚴重依賴字串，所以會喪失編譯時的型別安全性。
2，反射速度慢。使用反射時，型別或成員的名稱在編譯時未知；要用字串名稱標識每個型別及其成員，以便在執行時發現他們。也就是說，使用system.reflection命名空間中的型別掃瞄程式集的元資料時，反射要不斷地執行字串搜尋。通常，字串搜尋執行的是不區分大小寫的比較，這會進一步影響速度。
使用反射呼叫乙個成員時，也會對效能產生影響。用反射呼叫乙個方法時，首先必須將實參打包成乙個陣列；在內部，反射必須將這些實參包到執行緒棧上。此外在呼叫方法前，clr必須檢查實參具有正確的資料型別。最後clr必須確保呼叫者有正確的安全許可權來訪問被呼叫的成員。
基於上述所有原因，最好避免利用反射來訪問字段或者呼叫方法/屬性。如果要寫乙個應用程式來動態發現和構造型別例項，應採取以下兩種技術之一。
1，讓型別從乙個編譯時已知的基型別派生。在執行時，構造派生型別的乙個例項，將對它的引用放到基型別的乙個變數中（利用轉型），再呼叫基型別定義的虛方法。
2，讓型別實現乙個編譯時已知的介面。在執行時，構造型別的乙個例項，將對它的引用放到介面型別的乙個變數中（利用轉型），在呼叫介面定義的方法。
在這兩種技術中，我個人更喜歡使用接**術而非基類技術，因為基類技術不允許開發人員選擇在乙個特定情況下工作得最好的基類。不過，在需要版本控制的情形中，基類技術顯得更合適一些，因為隨時都能向基型別新增乙個成員，派生類會直接繼承它。相反，要向介面新增乙個成員，實現該介面的所有型別都得修改它們的**並重新編譯。
在使用這兩種技術時，強烈建議在介面或基型別自己的程式集中定義它們。這有助於緩解版本控制問題。
反射的效能
今天在mvp站點上看到有人說反射的效能很差，要避免使用，就寫了乙個簡單的例子測試了一下 測試類如下 namespace reflectiontest.test public void test1 private double a public double geta 首先我們對於物件的構造進行測試 ...
反射的效能
反射是乙個相當強大的機制，它允許我們在執行時構建並使用乙個在編譯時還不了解的型別及其成員。但它也有兩個缺點。使用反射呼叫乙個成員時，也會對效能產生影響。用反射呼叫乙個方法時，首先要將實參打包成乙個陣列，在內部，反射將這個陣列解包到執行緒棧上。此外，在呼叫方法前，clr要檢查實參的資料型別。最後，cl...
C 反射效能測試
1.反射序列化與動態編譯序列化。比較結果 test started assembly pixysoft.framework.configurations.dll begin createobjectusingreflection begin createobjectusingreflection 0...