unity3d移动平台性能优化专题16：性能优化实战之20个复杂单位战斗(unity移动端教程)

编辑：rootadmin

推荐整理分享unity3d移动平台性能优化专题16：性能优化实战之20个复杂单位战斗(unity移动端教程)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:unity移动游戏开发,unity3dwasd移动,unity 移动应用开发,unity3d物体移动代码,unity移动ui,unity3dwasd移动,unity 移动应用开发,unity移动ui,内容如对您有帮助，希望把文章链接给更多的朋友！

一直秉持着性能最优的原则，目前我们的3d游戏即使在红米上也能够到达平均帧，最低帧的水平。但这次有一个功能是一个大问题，我们平时战斗都是5v5，但这次需要做一个v，理论上复杂度*2,时间也应该*2.

帧，那么*2后应该是帧左右。但遗憾的是性能这东西并不是简单的乘法，而是超越一定瓶颈后会指数下降。果然，在红米上只有帧，而且体验会有问题。那么根据前面的全部性能优化的专题，我们来看下如何针对性的去解决。

1.分析性能下降的最重要原因，发现监视器中显示的是渲染部分，以前个单位，现在个单位，大概多了几万个面，导致突破了瓶颈。那么这个是硬性指标，我浏览了我们所有的场景，发现大部分场景都在k个三角形左右，但是我也找到了一个不错的场景，只有k，我首先的策略就是更换场景，将场景换成这个k的。和策划商量后，策划同意了。ok，马上修改进行测试。

ok，结果出乎意料，最后确实发现可以维持在帧，但战斗过程中还是只有帧。看来这还远远不够，我不得不继续研究。

unity3d移动平台性能优化专题16：性能优化实战之20个复杂单位战斗(unity移动端教程)

2.仔细看了下，&#;乎渲染上已经不是太大问题，那么毫无疑问，就是单位过多引起的，有两种可能，一个是脚本AI执行*2，一种是特效数量*2.不管是哪一种，&#;乎都是只能通过逻辑优化了，本来走路Ai是很复杂，但现在鉴于人过多，只能简化走路ai，直接直走，然后减少ui上的drawcall，进行新一轮的测试。

这样之后，战斗过程大概也是在帧-帧之间，&#;乎还可以接受，但体验有问题，由于我采用AI排队策略，现在人数太多，导致AI执行变慢，比如你应该碰到人要攻击了，但由于你的AI在排队，你没办法马上攻击，只能等待甚至继续跑，但这是无法接受的，而且我发现只有一开始会这样，那么我大致推论，只有一开始的时候由于JIT等原因导致比较卡，所以帧率很低，大概只有帧，这个时候能过被执行的AI数量并不多，个人，人人都是非常着急要攻击的。但是我的队列清除速度是5，我认为这是一个比较合适的&#;，如果增加到，当然每一个人都会攻击，但是这样排队的意义就没有了。

而且测试了一下，发现增加排队的效果微乎其微，这样就很奇怪了，我假设AI执行区间是0.2s，速度是1.2m，两人相向而行，就是0.5m，而两人的攻击距离是1m，那么理论上如果是实时执行，是不会有这个问题的。那么说明就不是实时执行的了。仔细一想，是这样，我的AI执行顺序是，首先每隔0.2s发送一个AI请求，假设运气不好，那么已经经过0.2s了，然后我发送了一个AI请求成功，然后队列中已经有个单位，我不得不等待4帧，现在一帧ms，也就是0.s左右，那么就是等待了0.s，接下来，执行AI，发现要切换到攻击状态了，然后再次发送一个请求，同时重复上一个过程，这样就会经过整整0.7s的时间，这样的话就是夸张的1.m，远远超出了攻击距离范围。然后通过修改队列，将0.2修改成0.1，适当增加距离，ok，感觉还可以。

最后还是适当接受几个卡主的情况，毕竟体验上还是要好一些。

Unity3d_NGUI和UGUI的学习由于之前刚入门的时候，应Unity3d整体发展的要求我们自学了UGUI(相对来说UGUI比NGUI做得更好一些，后面会有2者对比)，但是后来公司要求使用NGUI，所以我

Unity3D读取XML文档信息 C#中可以用XmlDocument类操作Xml文件例如要读取如下Xml文件1root2personname=WangYao3age/age4/person5personname=Jobs6age/age7/person8/root程式如下1XmlDocumentdoc=newXmlDocument();

UnityC# MD5验证孙广东.6.数据经网络传输后会变得非常不安全，最简单有效的解决方案是给数据加一个密钥，使用MD5算法算出校验码，服务器收到数据和校验码后