為什麼 C# 發明 13 年之後微軟才推出編譯為本地代碼的功能？

01-21

Announcing .NET Native Preview
有哪些技術或其他方面的考慮？

因為之前沒有一份GUI代碼無痛運行在N個平台上的需求，但是現在有了。現在你可以寫一個metro程序，提交到伺服器，伺服器幫你無痛編譯成N份代碼，然後你在手機上也能購買了。

不過其實C#一直都有編譯為本地代碼的功能，區別只是現在不需要顯式安裝.net framework了。

因為一直以來沒有這個需求。

不要聽信那些什麼「.NET好是好，就是要裝個Framework費勁，要是能脫離Framework/編譯成本地的話，我就用它」這種鬼話，到今天他們還是不會用的，反正借口永遠都能找到，什麼不開源（.NET framework源代碼早就公開），不能跨平台（Mono都十年了），JIT編譯效率低（有ngen），微軟遲早會拋棄（目前已近14年了，1.0的代碼還能跑）。這些都是鬼扯。

這一次支持native只是因為移動設備的續航需要而已。

一直都有，比如官方的 ngen.exe，現在這個就是不需要安裝.net framework

最開始嘛，.NET是個平台，主打網路的平台，還是一套開發工具呢，自然不可脫離這個運行環境（模仿JAVA啦）

後來嘛，C#明顯豐富了，可以開發桌面應用了，不過很多人覺得雞肋，還是需要裝他

很多人想不通為什麼一個不跨平台的.NEY要模仿JAVA做個不能脫離的運行環境呢。其實微軟早就想好了，自己以後會開發多個系統，平台，x64也會非常流行與32並存，.NET（個人認為主要指C#和一系列庫）要跨這些個東西

於是乎一路沿著這條路走啊追啊

現在換領導了，換新思維了，認為實用才是王道（不是CEO這麼想，是幾個高管這麼想，以前就一直被無視），然後就來了一系列個厲害的東東

偷偷留一句，以前「苟且」活下來的ngen.exe，要是當時很流行，估計活不了

利益相關：專業微軟黑路過。

你們不看文章內容么？一開始就寫著：

Windows Store apps start up to 60% faster with .NET Native and have a much smaller memory footprint.

變快了，內存佔用減少了，這是所有程序員想要的。

第二段也說了：

Today"s preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications.

就我的理解而言，除了移動應用，桌面應用應該也能在未來得到支持的。

另外，就我一個用戶而言，我覺得 .Net 帶給我的體驗是很差的。

因為玩遊戲或裝某些軟體，印象中我裝了 1.0、1.1、2.0、2.5、3.0、3.5、4.0 這麼多版本，每次都要下個幾十 MB 的安裝包，還得重啟。

給我的感覺是各個版本完全不兼容，比如我裝了 3.0，還有軟體要求我裝 2.5。

我不是 .Net 開發者，我不知道是不是這些軟體寫得爛導致的。就我的體驗而言，這是個災難。

也不知道這些年得到改進沒，我已基本不用 Windows 了。

為了避免不必要的爭議，請不要在評論里就正確性來回應上面一段。

我只是提出我自己作為用戶的感受，我不在乎微軟這樣做是否合理，或者對比 Java 之類的行業作法，或者我做錯了什麼，我只是在說一個小白用戶的體驗。

這樣的用戶，可能全世界就一個，所以不用操心去反駁。

插圖：《編程語言性能對比》 無缺草製造

第一次看到.net，最震驚的就是慢！令人髮指的慢！

在當時的較先進硬體上寫一個Hello World頁面，10秒鐘之內還出不來的奇葩徹底顛覆了我對一個產品的觀念。連微軟的演示者都要說一些俏皮話，才能等到界面出來以及不讓場面過於尷尬。

現在，硬體已經進化了幾十倍，.net做一個Hello World也變成可以接受的程度，可喜可賀。

沒頭的蒼蠅

我想微軟之所以要採用.net架構，首先是要擁抱互聯網的決心，同時感受到Java的巨大壓力。但微軟.net做成這樣絕對是像沒頭的蒼蠅一樣四處亂撞的結果，正如為了移動平台而在Windows上的胡來一樣。羨慕Java八面玲瓏，於是也做成中間語言具備了跨平台潛質；但微軟的收入幾乎都來自Windows的壟斷，於是乎從來也沒有真正跨出去。事實上，C#程序幾乎都是在x86架構下本地運行的。但為了跨平台的架構，極大犧牲了性能，並且也沒有挽留住網路用戶（都跑到移動端了）和伺服器用戶。但因為Windows在桌面系統沒有競爭對手，Borland也被打垮了，導致微軟可以在C#上長期這麼任性。C#用中間語言就像和同桌說話，還要前排的人中轉一樣可笑至極，而這樣做的原因竟然是為了具備和更前一排人說話的能力。

不只是本地代碼

C#的.net平台，代表了微軟在互聯網時代至少努力了、掙扎了。實際上，即使C#編譯成本地程序，也避免不了微軟的頹勢。只是害苦了那些C#開發者，承擔了沒有必要的低下性能。最近又測了一下C#程序的運算性能，和C++本地代碼對比其實也只有兩三倍的差距，和Java類似。但運算性能之外的消耗依然驚人，比如內存佔用和啟動速度等方面。C#的性能低下更多應該是拜過度封裝所賜，完美優雅的庫猶如層巒疊嶂消耗了大量資源。我們曾寫過一個嚴格按OO設計的產品，平均一個界面要傳送1M的對象，而實際上的數據只有幾十K。當然，這個程序可以優化的地方很多，但在某方面也體現出OO在資源佔用方面的天生劣勢。

下面這個知乎話題非常好，從CPU和內存方面解釋了OO為什麼性能那麼差。OOP相比面向過程引發了更多內存操作，而內存比CPU慢100倍，造成「內存牆」的性能瓶頸。C#這種對WindowsAPI又封裝了好幾層的架構，然後你再層次良好地封裝這些被封裝了幾層的庫，必然也是掉到「內存牆」這個坑裡了。面向對象編程的弊端是什麼？ - 計算機科學

就像早先的COM和dll之類，註冊、版本問題給用戶帶來極大困擾，實際上是沒有必要耦合那麼深的。但這符合微軟利益，通過COM將產品和Windows像一團亂麻一樣捆在一起。Borland有更好的產品但就這樣被捆死了，而.net版本翻新對Borland來說則是補刀。

如果你在大公司呆過，你就知道如果你連續10年都在維護一個.net1.X的幾乎不用更新的超級好用的產品，那你的江湖地位一定是……被路人忽略的。而過一兩年整出一個.net2.0，然後修復了3000個BUG的3.0，然後全新架構的4.0推翻3.0……你一定是萬眾矚目的傢伙，拯救公司的英雄。微軟幾千個程序員，不弄出點新東西，獎金怎麼發呢？據說蘋果早期用同類公司1%的人手整出了顛覆世界的iPhone，看來人少出精品，人多出.net（新建一個工程，選項里就能看到塞了多少令人眼花繚亂的歷史垃圾）。

最新的UWP在封裝上更上一層樓。啟動應用商店裡的小程序，又讓我依稀體驗到了第一次見到.net的感受。主界面好幾秒才彈出來，不知道在搞什麼鬼。這些官方應用早就用了本地代碼，也沒體現出性能優勢。但反過來一想，託管代碼性能要多恐怖呀，怪不得微軟要在這裡硬生生提供本地代碼功能。全面支持本地代碼兩大難點，第一總架構師自打自臉（因此進展緩慢）；第二確實有工作量，尤其是.net還在飛速進化；第三微軟自己用高速的C++，而C#提供本地代碼不會帶來大量新用戶商業價值有限（為什麼應用商店先提供，因為那塊兒可以和蘋果安卓直接搶新用戶）。

PHP和Python，運算速度比C++慢100倍以上，但整體性能、部署、資源消耗方面依然擁有相當的競爭力，甚至有時比C#用起來更爽。可見，本地代碼也不是完美的性能方案，各方面的綜合優化才是王道。

應該是有多方面原因的，其中一個最大原因是MS寄希望於.net一舉解決windows的安全問題。

隨著移動互聯時代的到來IOS，Androd的崛起，windows一統江湖的局面已經不復存在，windows安全問題似乎也不再成為那麼急迫的問題，因為大家現在用的更多的是手機，呵呵