很有意思的問題.

來看看網(wǎng)絡(luò)大拿們所做的總結(jié).

當(dāng)然結(jié)果需要您自行考慮.

首先,下文摘錄自InfoQ<JS OR C# 不存在的腳本之爭>

到底C#和Unity3D里的JS誰好呢？

最常見的問題無非是： 用js寫的u3d游戲和用c#寫的u3d游戲，到底誰的運(yùn)行效率高?。?/p>

最常見的回答為非是： 肯定是C#啊，因?yàn)閖s是動態(tài)的?？隙ú蝗缇幾g的語言好。

第二常見的問題無非是： 用js開發(fā)和用c#開發(fā)，哪個(gè)更快更適合我??？

第二常見的回答無非是： js適合個(gè)人開發(fā)，敏捷快速。c#適合公司開發(fā)，規(guī)范嚴(yán)謹(jǐn)。

咱們還是用和剛才討論與javascript的區(qū)別時(shí)一樣的思路來整理C#和UnityScript的不同，也就是按照先本質(zhì)，再表現(xiàn)的順序。同時(shí)兼顧回答一下上面的兩個(gè)問題。

本質(zhì)求同存異

開篇就說了，UnityScript是和C#同一個(gè)層面的語言，也需要經(jīng)歷從源代碼到CIL中間語言過渡，最終到編譯成原生語言的過程。所以本質(zhì)上，最終運(yùn)行的都是從CIL編譯而來的原生機(jī)器語言。但的確會有C#比較快的現(xiàn)象，那么問題出在哪呢？

一個(gè)可能但不是唯一的答案就是 UnityScript和C#生成CIL中間語言不同。

這一點(diǎn)想想也很簡單，就像上文提到的var的問題，如果使用Object來處理var的問題，則不可避免的是頻繁的裝箱拆箱的操作，這對效率的影響是很大的。

所以的確，C#的速度更快，但原因是UnityScript會涉及到頻繁的裝箱拆箱操作，進(jìn)而生成的CIL代碼與C#有差異，而并非UnityScript是動態(tài)語言且沒有經(jīng)過編譯。

現(xiàn)實(shí)很單純

開發(fā)到底是使用C#還是UnityScript呢？如果不考慮運(yùn)行的效率，僅僅考慮開發(fā)時(shí)候的感受，小匹夫就談?wù)勛约旱目捶ê美病蔷褪钦湎r(shí)間，遠(yuǎn)離UnityScript。

首先有幾個(gè)事實(shí)我們要清楚：

UnityScript是脫胎于.NET平臺的第三方語言Boo的。所謂的第三方語言和C#的區(qū)別，就跟自己到底是不是親生的，爹到底是不是隔壁老王是一樣的。差距可能是全方位，立體式的。社區(qū)支持，代碼維護(hù)，甚至是編譯出來的CIL代碼質(zhì)量都可能有很大的差距。選擇UnityScript之前，問問自己之前聽說過Boo嗎？別忘了UnityScript和Boo的淵源。

UnityScript和JavaScript除了長得像之外，根本就沒有什么關(guān)系。你在JavaScript里如魚得水，在UnityScript中如果不小心就可能埋下隱患，而一些隱患可能藏得很深。而且UnityScript也是靜態(tài)語言，也需要編譯，所以看不出來選擇它作為開發(fā)語言為什么會有人覺得快。

插件的支持。貌似大多數(shù)都是C#寫的吧。

好吧，如果上面的3點(diǎn)都不能說動你，那就看看官方的態(tài)度好了。

U3D官方團(tuán)隊(duì)基于數(shù)據(jù)分析做出的一個(gè)語言被使用的百分比圖。

由于Boo語言的使用量基本可以忽略，所以從Unity5.0版本開始就會停止對Boo的文檔支持。同時(shí)消失的還有從菜單創(chuàng)建Boo腳本的選項(xiàng)“Create Boo Script”。從U3D團(tuán)隊(duì)對Boo的態(tài)度，也可以窺見和Boo聯(lián)系密切的UnityScript未來的走勢。

同時(shí)U3D團(tuán)隊(duì)也會把支持的重心轉(zhuǎn)移到C#，也就是說文檔和示例以及社區(qū)支持的重心都在C#，C#的文檔會是最完善的，C#的代碼實(shí)例會是最詳細(xì)的，社區(qū)內(nèi)用C#討論的人數(shù)會是最多的。

感謝INFOQ提供的原文支持.