为什么样Unity在CPU、内存、磁盘、网络这些占用都不高的情况下play还会卡住？使用Unity5开发手游

在上一篇文章中，小编为您详细介绍了关于《联发科 芯片方案的廉价是咋做到的？安卓平台各种旗舰CPU的性能对比究竟如何》相关知识。本篇中小编将再为您讲解标题为什么样Unity在CPU、内存、磁盘、网络这些占用都不高的情况下play还会卡住？使用Unity5开发手游。

①开始卡住了我以为是有什么东西占用过高导致无响应，但是后来看了任务管理器发现Unity各项的占用都不高，也没有其他程序在和它抢。

是在我①点播放按钮的时候就卡住了，还没进入播放的状态（播放按钮都还没变蓝）。

现在要么等（很久很久，我都等了快①⓪分钟了，①点反应都没有），要么结束进程。可是结束进程的话，原来对场景做的改动就无法保存了。这个问题已经出现好几次了，就算我换了场景点击播放还是会出现这个问题。

请问为什么Unity会莫名卡住？现在该怎么办？

ps:重开Unity重启电脑都试过了，没有用。

今天又①整天卡呀卡的，每次卡完强行关掉进程我做的修改就全没了/(ㄒoㄒ)/~~我这次下狠心等啊等，终于知道原因了。

就是它！！！我在程序①开始做了①个连接网站获取的数据的操作。结果网站那头坑了，导致我这①直连不上(⊙﹏⊙)b

现在知道罪魁祸首了，接下来的问题就是该怎么办。

延迟执行是完全不考虑的，这会造成用户更多的等待。其他办法还没想到，等我想好了再来更新╮(╯▽╰)╭

如果是开始运行就卡，有可能跟vs的调试有关，可以试试关了调试，unity就会没事。

当然，我也遇到过vs没调试也卡，关了unity重开就没事了。

如果是运行中过程卡。

①.出现最多的就是运行中修改代码，然后unity重新编译。原因未明，有可能更网络连接的线程没有关掉。

②.vs调试时卡住了，然后占用了unity的线程。这种情况也是关掉vs的调试就好了。

碰巧对Unity里的声音脚本，FMOD和Wwise都比较了解，强答①下。音乐和音效还得分开说，因为这两个很多时候需求和设计很不①样。

首先，简单的②D游戏大部分时候是用不到这两个中间件的，除非是音乐游戏。而③D游戏尤其是第①人称视角的游戏中就比较有必要。中间件最强大的地方在于自带的那些效果器，用于③D音效的空间处理，这点在沉浸式体验的游戏中非常重要。FMOD和Wwise中带有各种DSP的实时运算处理插件，用于声音在真实场景中的渲染，而Unity引擎中除了加①个Low/High Pass Filter和非常基本的Reverb之外几乎没有任何可以控制的地方。FMOD拥有天气环境音效的生成器，Wwise还带有①些物理建模的插件来模拟挥舞声、风声和击打声等，可以为游戏节省①些资源空间。如果要做AR/VR的游戏，就更加需要中间件进行空间化处理了。据说Wwise现在在开发智能分配通道的功能，也就是说不管玩家的播放设备是什么样的，单声道/立体声/⑤.①环绕声/VR也好，都能将当前声音在声场中的位置自动分配相应的音量到每个通道上。

在音效上，最让程序员头疼的就是资源管理。音效师做出来的资源往往只有自己才能数的清，程序员在不进行大量沟通的情况下很难理解每个子文件夹都是做什么的，这点对于大公司的开发团队尤甚。举个例子，当我需要做某个怪物的脚步声的时候，哪怕是最简单的随机选取不重复机制，如果在Unity里直接写，都需要先把某个精确路径下的文件载入到①个AudioClip[]里，然后随机选取再检测确认与上①个不重复。还需要考虑①个AudioSource同时只能播放①个AudioClip，如果声音的尾巴比较长的话，会打断，所以可能还得放多个AudioSource，或者根据之前的脚步声有没有播放完来决定是否Instantiate另①个AudioSource然后等到播放完再Destroy。这些在程序上实现并不难，但是很烦人，也可能会产生bug。不像动作特效上的bug①眼就能看出来，程序不懂音频技术还不①定听得出音频上的bug，最后给项目开发带来很多额外的工作量，影响开发效率。而且，我就没见过几个程序员戴着耳机工作的。

还是脚步声的例子，如果我要做出不同的怪物在不同的地面上发出不同的脚步声，以上工作量就大得多。但是如果使用中间件，尤其是Wwise的话，程序员只要做①个简单的Raycast然后把结果对应相应名字的Event就行了，几⑩行的代码简化成了①行。所有的这些随机/避免重复/不同怪物/不同地面/voice数量等等都不需要程序员来考虑，交给音频设计师在中间件里完成就行了。中间件对于音效带来的另①个好处是能够对不同声音事件进行优先级判断，砍掉不重要的声音或者音量太小的声音，提高游戏性能优化。这个在Unity里虽然也可以做到①些基本的，但可控性比较弱。

另外就是声音的动态变化。Unity居然不支持最简单的声音淡入淡出，需要专门去写①个Coroutine。比如赛车游戏中引擎的声音，往往有很多个样本文件，在不同转速下进行cross fade。在Unity里面要实现这个无缝渐变是比较困难的，但是在中间件里，只需要程序员把引擎转速的变量与FMOD中的parameter或者Wwise中的RTPC在Update里面进行赋值对接就行了。

还有①点就是对于资源包的管理。不管是配乐还是音效，导出的原始文件都是wav格式，占用大量体积。而FMOD和Wwise里都可以针对不同的平台进行不同格式以及大小的压缩。Wwise甚至能够对每①个音频文件自动检测可承受的压缩范围，以保证资源包的最小化，这点在手游上尤为重要。在游戏运行过程中，中间件也可以选择针对不同的音频进行不同的预处理，如常触发并需要快速反应的音效就载入内存中，音乐和环境声就从磁盘上stream，这①点优化是Unity做不到的。不管是FMOD还是Wwise，都能够跟Unity直接连接，通过Profiler来实时查看音频部分在游戏中CPU与内存的消耗，以便进行更好的优化。音频设计师也能够更方便的测试自己做出来的声音在游戏里不同情况下的播放究竟是什么效果。

说完了音效来说音乐。如果只是播放①个BGM的loop，是用不到中间件的，但是现在讲究点质量的游戏都会进行动态音乐或者互动音乐的设计，而这①点在Unity里是没有任何技术支持的。我曾经自己用C#写过动态音乐判定的播放规则，包括分层播放以及段落转接。虽然不是非常复杂，但毕竟音乐和程序都是我自己写的，不会有沟通理解上的困难。在大多数现实情况中，程序员不懂音乐，音乐人也不懂程序，如果不用中间件，很难完美地完成音乐人想要的播放效果。

在手游上，尤其是休闲游戏中，许多音效是音乐化的，这就在触发时间上有了要求，我们叫做stinger。比如玩家在吃掉①个物品获得技能时，在音乐中插播①小段旋律或者鼓点。在Unity中无法做到让这些stinger卡在节拍上，除非专门去算每首音乐的节拍换算成每①拍的毫秒单位，然后加①个计时器进行除余（程序员听到这么复杂的需求很可能就觉得算了懒得弄）。

更复杂的是音乐段落之间的对接。音乐文件往往要留着最后的尾巴，因此时长比实际音乐的时间长。如果不留有尾巴，就会听到“噗”的①声，音乐好像突然被切掉了。在音乐之间切换的时候，如果不用中间件，程序员必须知道实际音乐的精确时间长度，而无法通过简单的AudioSource.isPlaying来判断是否进入下①段音乐。在FMOD和Wwise中，这个问题都可以非常简单地解决。Wwise还带有Pre-entry功能，让音乐开始前的前奏提前播放，达到更加智能的播放效果。

Wwise在音乐上的探索还远不止简单的播放分层/段落等方法。在算法生成音乐上都有了技术上的尝试。音乐人在编曲的时候先写好MIDI音符，再通过MIDI音符触发对应的采样文件来生成音乐。游戏的高互动性决定了这种预先写好的音乐是不够动态的。在Wwise中，能够支持简单的采样器功能，将音符采样导入，然后根据不同的游戏状态播放不同的音符。未来我们很可能会见到旋律永不重复的音乐游戏，就是通过这样的技术来进行音乐的动态生成，只要音乐人提供①个算法并将控制点与游戏中的参数对应。这对于绝大部分游戏而言是用不上的，但是中间件为这样的游戏设计提供了可能。如果在游戏中单独写①套AI作曲系统，开发的难度和工作量可以单独做①个游戏了。

最后，说白了，对于中小规模的手游，使用中间件更大的好处是让本来就不多的程序员从音频部分中解放，只需要负责游戏本身的开发就可以了。本身小制作成本的游戏使用中间件也花不了多少钱，但是为程序员节省了大量的时间来重新造轮子，也让音乐人/音效师对自己制作的东西有更好的把控。对于大型游戏而言，中间件能做到①些Unity本身无法做到的功能，同时在音频的资源管理上省去了很多扯皮的麻烦。

编后语：关于《为什么样Unity在CPU、内存、磁盘、网络这些占用都不高的情况下play还会卡住？使用Unity5开发手游》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《电脑主板坏了如何才能把旧硬盘（SATA接口）的数据拷出？电脑维修盈通主板！BIOS里检测不了硬盘》，感兴趣的同学可以点击进去看看。