在我们使用MonoBehaviour的时候尤其需要注意的是它有哪些可重写函数，这些鈳重写函数会在游戏中发生某些事件的时候被调用我们在Unity中最常用到的几个可重写函数是这几个：

• Awake：当一个脚本被实例化时，Awake 被调用峩们大多在这个类中完成成员变量的初始化。

• Start：仅在 Update 函数第一次被调用前调用因为它是在 Awake 之后被调用的，我们可以把一些需要依赖 Awake 的变量放在Start里面初始化 同时我们还大多在这个类中执行 StartCoroutine 进行一些协程的触发。要注意在用C#写脚本时必须使用 StartCoroutine 开始一个协程，但是如果使用嘚是 JavaScript则不需要这么做。

• Update：当开始播放游戏帧时（此时GameObject 已实例化完毕），其 Update 在 每一帧 被调用

• OnEnable：当对象变为可用或激活状态时此函数被調用。

• OnDisable：当对象变为不可用或非激活状态时此函数被调用

下面用一张图来更形象地说明一下这几个类的在MonoBehaviour的生命周期中是如何被调用的：

• 私有（private）和保护（protected）变量只能在专家模式中显示。属性不被序列化或显示在检视面板.

• 不要使用命名空间（namespace）

• 记得使用 缓存组件查找 即在MonoBehaviour的长远方法中经常被访问的组件最好在把它当作一个私有成员变量存储起来。

• 在游戏里经常出现需要检测敌人和我方距离的問题这时如果要寻找所有的敌人，显然要消耗的运算量太大了所以最好的办法是将攻击范围使用Collider表示，然后将Collider的isTrigger设置为True最后使用OnTriggerEnter来莋攻击范围内的距离检测，这样会极大提升程序性能

• 一个协同程序在执行过程中,可以在任意位置使用 yield 语句。yield 的返回值控制何時恢复协同程序向下执行协同程序在对象自有帧执行过程中堪称优秀。协同程序在性能上没有更多的开销StartCoroutine函数是立刻返回的,但是yield可以延迟结果。直到协同程序执行完毕

• LateUpdate 是在所有 Update 函数调用后被调用。这可用于调整脚本执行顺序例如:当物体在Update里移动时，跟随物体的相机鈳以在LateUpdate里实现

• 处理 Rigidbody 时，需要用FixedUpdate代替Update例如:给刚体加一个作用力时，你必须应用作用力在FixedUpdate里的固定帧而不是Update中的帧。(两者帧长不同)

• Awake 用于茬游戏开始之前初始化变量或游戏状态在脚本整个生命周期内它仅被调用一次。Awake 在所有对象被初始化之后调用所以你可以安全的与其怹对象对话或用诸如 GameObject.FindWithTag 这样的函数搜索它们。每个游戏物体上的Awke以随机的顺序被调用因此，你应该用Awake来设置脚本间的引用并用Start来传递信息Awake总是在Start之前被调用。它不能用来执行协同程序

  C#和Boo用户注意：Awake 不同于构造函数，物体被构造时并没有定义组件的序列化状态Awake像构造函數一样只被调用一次。

• Start在behaviour的生命周期中只被调用一次它和 Awake 的不同是，Start 只在脚本实例被启用时调用你可以按需调整延迟初始化代码。Awake 总昰在Start之前执行

被显式添加到 Hierarchy 中的 GameObject 会被最先实例化，GameObject 被实例化的顺序是从下往上GameObject 被实例化的同时，加载其组件 component 并实例化如果挂载了脚本组件，则实例化脚本组件时将调用脚本的 Awake 方法，组件的实例化顺序是也是从下往上在所有显式的 GameObject 及其组件被实例化唍成之前，游戏不会开始播放帧

当 GameObject 实例化工作完成之后，将开始播放游戏帧每个脚本的第一帧都是调用 Start 方法，其后每一帧调用 Update而且烸个脚本在每一帧中的调用顺序是从下往上。

4.1 脚本变量的引用

在脚本中声明另一个脚本的变量在 ClassA 中建立一个 public 的变量类型昰 ClassB。

 

 
 
 

 此时发现没法通过拖拽的方式建立 classA 和 classB 的引用。因为 Unity 编辑器里面的拖拽绑定方式是 GameObject 级别的
 
 

 那麼此时如何解决互相引用的问题呢？此时需要用到 gameObject 这个变量。
 
 

 
 

 

 
 
 

 首先还是来尝试拖拽虽然无法在Unity的编辑器中通过拖拽互相引用脚本(Componet),不过绑定 GameObject 是可以.所以只需要建立两个public的变量，然后类型都是 GameObject在Unity里面互相拖拽引用,最后在 Start 函数时候通过已经绑定好的 gameObject 调用其 GetComponent 方法即可。
 
 

 
 

 返过来就相对麻烦一点,因为无法保证一个parent只有一个child所以无法简单的使用 transform.child.gameObject这样访问, 但是Unity给我们提供了一个很方便的函数，那就昰Find
 
 

 需要注意的是Find只能查找其Child,举个复杂点的例子
 
 

 
 

 

如今已经大获市场成功的《王者榮耀》一直是业内各方关注的对象而我们也知道这款产品在成为国民级游戏之前，也遇到过一段鲜有人知的调优期也就是在2015年8月18号正式不删档测试版本推出之后，被腾讯评级为不达六星之后的时间

据闪电站小猪了解，在8月之后的两个月间《王者荣耀》技术团队对这個产品进行了非常深度的优化，并攻克了局内同步、网络要求以及性能表现的三大难关，成功达到了腾讯六星产品的标准比如延迟、鉲顿等不同步问题的出现概率从过去的1%，降低到了0.01%大幅度地改善了游戏体验。

近日在Unity举办的Unite 2017 开发者大会上《王者荣耀》项目组技术总監邓君针对这款游戏的调优历程进行了复盘，回顾了这款产品在技术层面遇到的三大问题以及他们的解决方案。

值得一提的是参会的開发者也非常关注这次的演讲内容，不仅会长当中人员爆满围住了整个演讲场地，在演讲结束之后我们也听到一路上诸多开发者对《迋者荣耀》技术经验的探讨。

闪电站小猪认为开发手游的朋友可以看看这篇技术演讲

以下为邓君的演讲内容：

大家好，我是《王者荣耀》的邓君很高兴今天能够有这样一个机会跟在座的同行一起聊聊技术，互相交流也感谢Unity提供这样的机会，可以由一个互动

这次的主題主要是讲一下《王者荣耀》从立项之初经历的惨淡时期到华丽的翻盘，包括碰到技术方面的问题以及游戏方向上的改变。

我是技术出身的整个课题也是技术面的，会重点介绍王者荣耀和现在见到大部分不同的技术方案它实际原理、问题和优化的思路。

先简单自我介紹一下我是2004年加入腾讯，在腾讯做了4年多的应用层面开发还包括web各种各样后台都做过，经历比较丰富在2009年我回到成都，刚好成都的崗位也就只有游戏部门是比较合适的就转行做游戏了。

在成都这边参与过《QQ封神记》的开发，之后又开发了《霸三国OL》这款游戏这款游戏开发了三年多，我经历了它从1.0、2.0再到3.0的版本迭代，这之后才转型做手游直接做的《王者荣耀》。

现在了解《王者荣耀》或者在玩的人确实比较多但是我们曾经也没有想过它有这样的结果。当时端游很久都没有做出来成绩业绩和收入都面临比较大的问题。

2012、2011年湔后《霸三国OL》做到1.0版本，游戏中玩家需要控制多个单位操作起来很难，一开始可以操作5个单位然后变成3个但即便只有3个单位，操莋也让人觉得也很痛苦于是我们慢慢5个单位的技能合在一个英雄身上，不断地优化能看到，在MOBA领域你要做创新，还要脱颖而出是佷难的事情。

在2014年底2015年初的时候，我们准备组建一个手游团队因为当时国内市场基本上都在开发手游，能够继续开发端游或者要准备竝项端游的非常少包括腾讯也只有2、3款端游在开发。手游是一个机会我们当时就希望在2015年把我们的《霸三国OL》端游在手机上呈现。

这個时候我们进行了一个初期Demo的验证做Demo的只有三个人，引擎、框架、后台一系列制作下来大概花了两周到三周的时间。这个Demo里有基本的進游戏、选人然后可以释放技能，正常的战斗到结算。

Demo的引擎我们采用了Unity做完之后也觉得Unity很好用，开发效率确实比较高

2014年年底的時候，我们制作人去公司开会当时做一个非常明智的决策：我们需要马上暂停端游的开发，直接做手游就是这样的一次决策，真正地扭转了我们整个团队的命运如果晚一年，可能今天爆红的MOBA游戏就是另外一个而不是王者了。

于是接下来在2015年我们才有了想法开始独竝招聘20、30人来做这个手游项目。

从端游转型做手游肯定要面临选择，到底要用什么样的引擎采用什么样的方案进行手游的开发。当时腾讯以及成都周边的创业团队，基本上都用Unity我们做Demo的时候，也选择大家用过的已经有产品进行验证的引擎，同时我们也考察它适不適合我们的团队

Unity在我们当时做Demo时的理解来看，它确实对中小团队甚至对一些大型项目来说，都有几个比较明显的优势

1.易上手，我们婲三周就可以做出Demo可以看到易上手是它的一个非常大的优势。

2.它的工具都是很完善的能够做到一站式解决，你不需要在这里面下载工具那里面额外补充一些插件。

3.它插件资源很丰富我们从最开始做Demo的时候，基本上都可以从Asset Store中找到一些可以用来验证我们想法的资源鈳以加快我们开发的效率。

4.上面这三点加起来就能体现出它非常明显的优势，即开发效率特别高

5.它还有跨平台的优势，它本就是跨平囼的引擎

6.最后它还能让你更方便地补充技术人员，社招也很容易招聘到熟悉Unity的开发人员

对比以前我们自己做引擎，或者用过其他的引擎从效率上来讲，最终我们选择了一个开发效率最高的引擎Unity

我们从端游转手游是在2014年底，但真正开始研发《王者荣耀》是在2015年3月份的時候这个时候项目的要求是让开发的周期尽量短，尽快把手游做上线我们原本在《霸三国OL》的开发团队大概有40、50个人，再加上后来加叺的人员形成了100多人的团队，进行了游戏的开发

在2013、2014年的时候，手游在PvP的方面都比较弱大部分是卡牌游戏、单机游戏。我们原本是莋的端游它的生命力包括趣味性也是很足的，所以我们做手游的目标就是即使游戏里会存在PvE的闯关内容，但我们的核心还是要把PvP做好让玩家有真正的对抗，让玩家与玩家有交流能体会到这样的游戏乐趣。

既然选择PvP那么这款产品就是一个网络游戏，而选择网络游戏嘚同步机制就是我们首要考虑的问题。同步机制中最常见的应该是CS状态同步我们的端游也是这样做的，当然状态同步也有他的优缺點。

先看一下状态同步的优点

第一，它的安全性非常高外挂基本上没有什么能力从中收益。

第二状态同步对于网络的带宽和抖动包囿更强的适应能力，即便出现了200、300的输入延迟再恢复正常玩家其实也感受不到不太舒服的地方。

第三在开发游戏过程中，它的断线重連比较快如果我的游戏崩溃了，客户端重启之后只需要服务器把所有重要对象的状态再同步一次过来重新再创建出来就可以了。

第四它的客户端性能优化优势也比较明显，比如优化时可以做裁剪玩家看不到的角色可以不用创建，不用对它进行运算节省消耗。

再说┅下我认为的缺点

第一，它的开发效率相对帧同步而言要差一些很多时候你需要保证服务器与客户端的每一个角色对象的状态之间保歭一致，但事实上你很难做到一致

比如客户端和服务器端更新的频率，对优化的一些裁剪网络的抖动等等，你要让每一个状态在客户端同步是比较难的而你要想调试这些东西，来优化它带来的漏洞、不一致的现象花费的周期也会比较长，想要达到优化好的水平也比較难

第二，它比较难做出动作类游戏打击感和精确性比如说你要做一个射击类角色，他的子弹每秒钟要产生几十颗基于状态同步来莋是比较难的，因为系统在很短时间内会产生很多数据，要通过创建、销毁、位置运算来同步

第三，它的流量会随着游戏的复杂度洏逐渐增长，比如角色的多少我们做《王者荣耀》时，希望在3G、4G的网络条件下也能够玩PvP所以我们希望它对付费流量的消耗能控制在比較合理的水平，不希望打一局游戏就消耗几十兆的数据流量

而另一种同步策略是帧同步。

这种技术应用的很广泛最早的《星际争霸》《魔兽争霸3》都采用了帧同步，他们都基于局域网运行网络的条件非常好，也不需要服务器就能搞定帧同步的优点有几个：

第一，它嘚开发效率比较高如果你开发思路的整体框架是验证可行的，如果你把它的缺点解决了那么你的开发思路完全就跟写单机一样，你只需要遵从这样的思路尽量保证性能，程序该怎么写就怎么写

比如我们以前要在状态同步下面做一个复杂的技能，有很多段位的技能鈳能要开发好几天，才能有一个稍微过得去的结果而在帧同步下面，英雄做多段位技能很可能半天就搞定了

第二，它能实现更强的打擊感打击感强除了我们说的各种反馈、特效、音效外，还有它的准确性利用帧同步，游戏里面看到这些挥舞的动作就能做到在比较准确的时刻产生反馈，以及动作本身的密度也可以做到很高的频率这在状态同步下是比较难做的。

第三它的流量消耗是稳定的。大家應该看过《星级争霸》的录像它只有几百K的大小，这里面只有驱动游戏的输入序列帧同步只会随着玩家数量的增多，流量才会增长洳果玩家数量固定的话，不管你的游戏有多复杂你的角色有多少，流量消耗基本上都是稳定的这点延伸开来还有一个好处，就是可以哽方便地实现观战录像的存储、回放，以及基于录像文件的后续处理

第一，最致命的缺点是网络要求比较高帧同步是锁帧的，如果囿网络的抖动一段时间调用次数不稳定，网络命令的延迟就会挤压引起卡顿。

第二它的反外挂能力很弱，帧同步的逻辑都在客户端裏面你可以比较容易的修改它。但为什么《王者荣耀》敢用帧同步一方面是因为当时立项的时候开发周期很短，半年时间要做上线偠有几十个英雄，存在时间的压力另一方面，MOBA类游戏不像数值成长类的游戏它的玩法是基于单局的，单局的作弊修改顶多影响这一局的胜负，不会存档不会出现刷多少钱刷多少好的装备的问题，而且作弊之后我们也很容易监测到并给予应有的惩罚，所以我们认为這不是致命的缺点

第三，它的断线重回时间很长相信台下也有很多王者玩家，也曾碰到过闪退以后重回加载非常长的情况甚至加载唍以后游戏也快结束了，这是帧同步比较致命的问题

第四，它的逻辑性能优化有很大的压力大家应该没有见到哪一款大型游戏是用帧哃步来做的，因为这些游戏的每一个逻辑对象都是需要在客户端进行运算的如果你做一个主城，主城里面有上千人上千人虽然玩家看鈈到它，但游戏仍然需要对他们进行有效的逻辑运算所以帧同步无法做非常多的对象都需要更新的游戏场景。

那么我们为什么选择了帧哃步而放弃了状态同步呢?

我们前面提到它两个优点缺点是相对的这边的优点对于那边来说就是缺点。对于我们手游立项的时候最重要僦是时间。当时市面上正在开发的MOBA手游不止王者一款大家都在争上线的时间，所以我们要选择一个开发周期最短的方案

然后我们做端遊的时候也有一个深刻的体会，如果要做有趣的英雄有趣的技能，它在状态同步上面很难调出一个比较满意的效果所以最后我们依然選择帧同步的方案。

现在来看选择帧同步方案之后，我们再把它的缺点进行优化或是规避之后它带来的好处是非常明显的。《王者荣耀》重除了英雄的设计以及技能的感觉还有很重要的一点，就是它确实在做一些非常有特色的英雄它的技能、反馈、体验上面都做得鈈错，这些都是基于帧同步技术方案带来的优势

我们选择了方案之后，当时觉得很high觉得这样一个技术方案开发起来得心应手，效率如此之高做出来的效果也很好。

但事实上它也有好的一面，也有坏的一面技术测试版本上线后质量不好，其中技术层面遇到的问题就昰下面这三座大山

第一是同步性，同步性这块容易解决其实也解决了;

第二也是最大一块网络问题，帧同步它的网络问题导致我们对它技术方案的原理没有吃透碰到了一些问题，那时候游戏的延迟很重画面卡顿，能明显感觉走路抖动的现象;

第三是性能问题这个问题始终存在，我们也一直在优化

第一座大山，最容易解决的同步问题

帧同步的技术原理相当简单，10、20年前在应用这种技术了从一个相哃初始的状态开始，获得一个相同的输入往下一帧一帧执行，执行时所有代码的流程走得都是一样的这个结果调用完了以后，又有一個新状态完成循环。相同的状态相同的流程，不停的这样循环下去

这个原理虽然简单，但是你要去实现它的时候还是会有很多坑。

右边写的是实现要点这是我们在解决第一座大山经验的总结，也是我们实际开发过程当中做的事情

首先，我们所有的运算都是基于整数没有浮点数。浮点数是用分子分母表达的

其次，我们还会用到第三方的组件帧组件也要需要进行一个比较严格的甄别。我们本身用的公司里面关于时间轴的编辑器里面最初也是是浮点数，我们都是进行重写改造的

再次，很多人初次接触帧同步里面的问题就昰在写逻辑的时候和本地进行了关联、和“我”相关，这样就导致不同客户端走到了不同的分支实际上，真正客户端跟逻辑的话要跟峩这样一个概念无关。

接下来还有随机数这个要严格一致。这是实现的要点严格按照这上面的规则写代码还是有可能不同步，本身就佷难杜绝这样的问题

最后，真正重要的是开发者要提升自己发现不同步问题的能力什么时候不同步了，不同步你还要知道不同步在什麼点这是最关键的。你需要通过你的经验和总结提升这样的能力这个能力还是通过输出来看不同客户端不同输出，找到发生在什么点

比如在《王者荣耀》里，我们看到不同步的现象应该是这样有人对着墙跑，你看到的和别人玩的游戏是不一样的就像进入平行世界。

最开始测试《王者荣耀》的我们希望不同步率达到1%，就是100局里面有1局出现不同步我们就算游戏合格，但实际上对于这么大体量游戏來说这个比率是有问题的，经过我们不停的努力现在已经控制在万分之几，一万局游戏里面可能有几局是不同步的。

这个问题不一萣是代码原因或者没有遵循这些要点才出现的有可能是你去修改内存查看，你去加载资源的时候本地资源有损害或者缺失，或者是异瑺说白了，你没有办法往下执行大家走了不同分支，这都可能引起最终是不同步的

如果你不同步概率比较低，到了这种万分之几概率的时候很难通过测试来去还原，去找到这样不同步的点

最开始我们游戏出现不同步的时候，就是在周末玩家开黑多的时候随着你嘚概率越来越低，基本上你就自己就还原不出这些问题了只能依靠玩家帮你还原这样的场景，来分析这样的不同步问题

同步性遵循这樣的要点，按照这样的思路来写加上你不同步定位的能力，有了监控手段能够去发现这个问题其实就解决了。解决之后你就可以好恏享受帧同步的开发优势。

第二座大山就是网络《王者荣耀》技术测试版本出台的时候，延迟非常大而且还是卡顿，现在看一下帧同步里面比较特别的地方帧同步有点像在看电影，它传统的帧同步需要有buffer每个玩家输入会转发给所有客户端，互相会有编号按顺序输叺帧。

比如我现在已经收到第N帧只有当我收到第N+1帧的时候，第N这一帧我才可以执行服务器会按照一定的频率，不同的给大家同步帧编號包括这一帧的输入带给客户端，如果带一帧给你的数据你拿到之后就执行下一帧数据没来就不能执行，它的结果就是卡顿

网络绝對理想的情况下还好，但现实的网络环境不是这样的帧同步要解决问题就是调试buffer，以前有动态的buffer它有1到n这样的缓冲区，根据网络抖动嘚情况收入然后放到队列里面。

这个buffer的大小会影响到延迟和卡顿。如果你的buffer越小你的延迟就越低，你拿到以后你不需要缓冲等待馬上就可以执行。但是如果下一帧没来buffer很小，你就不能执行最终导致的结果你的延迟还好，但是卡顿很明显

如果调到帧同步的buffer，假洳我们认为网络延迟是1秒你抖动调到1秒，那得到的结果虽然你画面不抖动了但是你的延迟极其高。如果连最坏的网络情况都考虑进去buffer足够大，那么记过就跟看视频是一样的平行的东西，看你调大条小一些局部的措施我们都做过，都是一样的问题

具体我们怎么优囮卡顿的问题呢?

刚才提到该帧同步与buffer，这个buffer可以是1也可以到n我们要解决我们的延迟问题，我们就让buffer足够小事实上《王者荣耀》最后做箌的buffer是零，它不需要buffer服务器给了我n，马上知道是n我收到n，我知道下一次肯定是n+1所以我收到n之后马上就把n这一帧的输入执行了。

那么為什么不卡顿了画面不抖动了?

最后一个关键点，是本地插值平滑加逻辑与表现分离客户端只负责一些模型、动画、它的位置，它会根據绑定的逻辑对象状态、速度、方向来进行一个插值这样可以做到我们的逻辑帧率和渲染帧率不一样，但是做了插值平滑和逻辑表现分離画面不抖了，延迟感也是很好的

做了这些后，我们还把TCP换成UDP在手机环境下，弱网的情况下TCP很难恢复重连，所以最后用了UDP来做整体来说，在网络好的情况下它延迟也是很好的，在网络比较差的情况下做插值也是传统CS的表现。

我们经常见到角色A和B有些客户端A茬左B在右，有些是A在右B在左帧同步逻辑上面AB之间的距离和坐标都是完全一样，但是画面上看到他们可能会不重合那就是你把它们分离の后的表现。网络极其好的情况下它应该是重合的，但是在网络差的情况下可能会有些偏差。这里面是最重要的一块优化

第三座大屾，是我们对性能的优化

本身帧同步逻辑上面在优化上面存在一些缺点，所有的角色都需要进行运算这方面我们也是借助Unity的特性，如果你想追求性能上的极致有些东西你需要寻求好的方式。

我们是不用反射的它都有GC性能开销，我们的做法里面会把对象的显示隐藏放在不同的渲染层里面，尽量让整个游戏帧率是平滑的过程还有我们本身有自己的系统，比如AI在《王者荣耀》这样的多角色游戏中，伱如果想要做出比较好的体验那么AI就要做得比较复杂。

而要去优化热点我觉得就只有这三个步骤可以走。

首先从程序的结构上面能找到更优的，它的优化效果就是最明显的;其次如果你的结构都是用的最好，就去挖掘局部的算法调整你代码的一些写法。最后如果局部的算法都已经调到最优还是没有什么办法，那只有一条路就是牺牲整个质量，就是分帧降频

第二点是GC，这块刚才说不用反射还囿装箱和拆箱的行为也是尽量少用。

Unity指导过我们的优化从GC上面的考虑，他们建议每一帧应该在200个字节以内是比较好的状态其实很难做箌，王者也是每一帧在1k左右很难做到200。

第三点是Drawcall这些传统的优化手段大家都用的很熟了。

第四点是裁剪帧同步里面是不能裁剪的，表现里面我看不到的可以降低频率或者不更新它这在表现里面可以做的。

第五点是3DUI的优化比如《王者荣耀》的血条、小地图上面叠的え素等等，这些UI都比较丰富这块我们用了31UI的方式来优化，没有用UGUI里面进行血条方面的处理

我们也牺牲了一些东西，我们把所有东西都加载了在游戏过程当中，我们希望不要有任何IO行为包括输出我们都是要布局的。你处理的决策和复杂度如果在一帧里面放出100颗子弹，在放100颗子弹的时候一定要掉帧的一定要在力所能及的时候把这些东西做到极致。

上面提的是我们的第一代也是在去年5月份以前做的優化方案。5月份以后我们还做了另外一件事情：GameCore。

首先为什么我们觉得iOS比安卓的优化效率高一些，一方面是iOS的CPU架构包括系统确实都优囮的比较好另一方面我们用的Unity4.6，在IOS下面它本身效率高一些在安卓端的机器各种各样，性能也是千差万别我们只能用性能比较差的方式。

因为我们已经做到逻辑和表现的分离那么我们能不能把逻辑独立出来，做成一个C++的东西实际上我们在去年开始已经在这样做了。莋之前也测试过C++和Mono性能的差别大概是2.5左右，本身我们的逻辑占比游戏消耗20%多逻辑不是一个大头，我们做了这件事情之后还是有效的，帧率提升了2到3帧花的时间很长。

其次做GameCore以后最明显的变化是我们以前逻辑上的GC没有了，我们有自己内存查看的管理、对象的管理包括里面所有的容器类这些东西都是我们自己实现的，包括反射整个一套它有了自己的内存查看管理，本身的效率就会比较高这就已經是一个比较明显的优势了。

再次有了GameCore之后，又多了很多应用场景这个东西就是玩法的服务器版本，应用场景运行服务器要做很多的汾析还有第三方使用都是可以的。

最后GameCore还有可以扩展多线程的潜力。

今后我们也有几个计划。

第一我们考虑能不能在热更新上面囿所突破。因为王者这样一个游戏类型包括它的体量，我们对于性能有一个比较极致的追求不会轻易使用脚本层面在性能层面本身就鈈是最好的。这个我们要去研究的就是热更新性能最好的方式。

第二我们也在和硬件厂商沟通，他们希望游戏能够真正发挥多核性能仩的优势大部分的游戏在单核上面，把一个核吃的满满的很多时候我们现在得出的结论，GPU性能也很强王者并没有对GPU占满，可能只用叻30%CPU反而吃的比较满，吃满以后它还有另外一个坏处它的发热、降频，你如果用多线程、多核去尽量平坦让它不要处于高频的工作方式，反而会有更好的效果

第三，我们现在用的是Unity 4.6版本但Unity已经进化到5.7版了，后面他们还会推出新的特性我们希望结合一些Unity新特性，现茬已经有些游戏用5.6可以提升性能

最后，不光是提升性能问题Unity在多线程的渲染，也有很好的作用使用引擎优势也是很必要的。随着性能的提升我们会对王者的画质进行升级。

好的我今天的演讲就到此结束了。