由于手游业界各大公司对该引擎的认可和追逐，自2013年开始，Unity大会成为了行业内最火爆的大会之一。在信息丰富的网络上，我们可以看到满屏的Unity教程和优点的介绍，但这款引擎是否存在着弊病呢?

带着这个问题，我们采访到了广州一家游戏研发公司的程序人员，从他们的角度来看待Unity3D引擎的现存问题。
 

引擎运行效率问题制约2D产品应用

Unity3D引擎的效率问题，这个效率是指运行效率，不是说开发效率，也就是说游戏运行时的开销。unity的跨平台的是因为它基于Mono的运行环境，导致引擎的开销很大，如果手机的硬件够强大还好，如果是中低端的手机还是有点吃力，也导致耗电量比较大。
 

这种情况下制作3d游戏还好，如果制作2d游戏的话，就变得有点让人难以接受了。

mono是由Nowel公司发起的基于.net的一个开源工程，由一个C#的编译器和一个CLR运行时和一组类库组成。C#是微软的编程语言，跟java不一样， C#只能用于windows操作系统。mono实现了能够用C#语言进行程序设计，并能够编译成在多个平台运行的程序，比如能够在linux上和macos上运行。

而像cocos2d这个引擎是用c++语言编写的，编译出来的代码通过直接调用系统底层的c语言编写的lib库来运行，编译出来的代码相当于binary代码，也就是二进制代码。但是unity的代码和java的代码类似，java编译出来的代码需要通过java虚拟机运行，在android平台上通过dalvik虚拟机运行;unity的代码则需要通过mono的CLR来执行，所以开销肯定是要大一些的。

另一个不能制作2D产品的原因是unity虽然支持2d，但是是通过二手游戏购买设定摄像机为正交摄像机并固定摄像机的位置来实现的，然后使用了box2d物理和2d碰撞等效果，实际上的开销虽然比3d游戏要小，但是整个GameObject底层还是3d环境的，所以对于一个2d游戏来说还是过大。

目前国内很多小2d游戏的推广渠道都对游戏包的大小有要求，要求包越小越好。但是unity一个空工程生成apk文件就有7-8M，如果是大型的3d游戏可能不是很大，可是对于小单机游戏制作来说真的很头痛。该公司之前用unity开发2D游戏，多次被渠道评价为安装包过大，而且很难想办法减小包的体积。

代码调试环节“所见即所得”优缺点并存

Unity的调试和编辑器是绑在一起的，通过附加到编辑器的进程上进行代码调试，编辑器没有和调试运行环境分离。这种情况下在调试的时候容易导致编辑器崩溃，要是保存了工程还好，要是没有时不时的保存工程，很可能会造成工程丢失。

因为Unity的所见即所得，这种方式有他的好处，开发者可以很方便的在编辑器中看到游戏场景的整个情况，所以unity就在编辑器里面整合了运行环境。

该程序员表示：“其实我觉得编辑器里可以有一套，但是调试的时候最好还是跟编辑器分离开来。既然是调试，谁都没有办法预测到代码到底有哪些问题，哪些问题会导致运行环境崩溃，或者死循环。这个地方我觉得挺关键的，ctrl+s可以有保障一点，但是有时一会儿没有发现代码问题在哪里的时候挺烦人的。应该用过unity的人都碰到过吧，我看我们公司的员工我看至少都碰到过这个问题。”

相比之下，cocos2d的场景编辑器是cocos studio，代码编辑windows下一般用vs，mac下用xcode。调试运行在windows下编译成exe文件调试，在mac下一般使用iphone或者ipad模拟器。

这个性能是优点也是缺点，也是Unity比较引以为傲的一个方面。在程序编辑过程中，可以很直观的看到游戏场景和游戏中的物体的位置。在调试的时候也可以暂停游戏，然后看看物体是否按照自己想象在运动。但问题恰恰就在于，不是每一个程序员的代码都是一次成型的产品，也不是每一个程序员都有不断保存的好习惯。人非程序，但程序应该可以更加人性化。

代码挂载并不是每一个程序员的最爱

代码挂载就是指将代码挂在一个物体之上，这对于初学者来说是极其便利的操作，但对于成熟的程序员来说却存在问题。

这实际上是代码驱动的开发模式，对于小型的简单的游戏这确实方便，但是当项目变大的时候弊病就显现出来。
 

 

如果项目很大，比如说网络游戏，还得用经典的数据驱动模式。否则代码驱动的结果就是bug频繁，解决起来错综复杂。总的来说代码驱动设计模式有点类似于写日记，数据驱动设计模式则是以数据为导向，增加代码的健壮性和可维护性，可重用性。

这种模式很容易让开发人员把游戏逻辑和其他行为代码混到一起。尤其是新手程序员经常是在频繁挂代码之后造成各种bug。严格来说这个方面不能说是它的缺点，跟程序员也有很大的关系。一个成熟的程序员会用各种经验规避这些问题，但一个不够熟练的程序员却无法做到。

简而言之，挂代码的方式对于刚刚开始用Unity开发的程序员来说便于入手制作独立小产品，但难于精通并融入复杂的大工程。在此类方向上，需要有经验的大型工程师指导。