Unity脚本类为什么要尽量避免继承monobehaviour update类

来源：蜘蛛抓取(WebSpider) 时间：2016-09-10 06:04 标签： c monobehaviour
看到网上好多人这样说，可是一直都没找到原因。这样做有什么好处呢？
这种说法是错误的。
应该从MonoBehavior的机制来分析比较合适&br&如果你的类无需引擎提供的各种初始化, 更新及析构, 物理, 渲染等的回调. 最好不要继承MonoBehavior&br&继承后, 引擎会在事件触发时, 通过反射调用各种函数. 这是需要消耗性能的.&br&&br&当然, 如果你的类压根没挂上GameObject. 理论上说, 应该没啥卵用&br&&br&所以总结, 弄不继承MonoBehavior尽量不派生
应该从MonoBehavior的机制来分析比较合适 如果你的类无需引擎提供的各种初始化, 更新及析构, 物理, 渲染等的回调. 最好不要继承MonoBehavior 继承后, 引擎会在事件触发时, 通过反射调用各种函数. 这是需要消耗性能的. 当然, 如果你的类压根没挂上GameObject…
最近在思考这个问题。&br&首先我认为，不赞成继承Mono的人大概出于性能的考虑。因为继承Mono比较消耗性能。这个本人也说不出什么具体的原因，完全凭感觉猜测。也没有做过性能测试，所以不知道究竟对性能会产生多大影响。要是有人做过相关的性能测试，希望能分享一下！&br&&br&但是如果不继承Mono，会有很多不方便的地方。&br&第一、不能使用Invoke和Coroutine了。&br&第二、调试不方便了，不能在Inspector和Debug tab看到参数。同时如果A不继承Mono，那么A这个类的List也无法在Debug界面看到。&br&第三、不自动调用Update之类的方法了，这个不算是太大的坏处&br&&br&本人在开发中，觉得第二点特别难以忍受。其他的不便之处倒还能克服。
最近在思考这个问题。 首先我认为，不赞成继承Mono的人大概出于性能的考虑。因为继承Mono比较消耗性能。这个本人也说不出什么具体的原因，完全凭感觉猜测。也没有做过性能测试，所以不知道究竟对性能会产生多大影响。要是有人做过相关的性能测试，希望能分…
已有帐号？
无法登录？
社交帐号登录
Game Dev/Unity3D/Guitar3153人阅读
unity3d（23）
如果创建新的类时，使用的是在unity editor的project视图中右键，create javascript or c#方式，那么创建的类都是默认继承自MonoBehaviour, 生成后可以查看类文件，会发现c#类继承自MonoBehaviour， 虽然javascript的类前面没有这个继承自MonoBehaviour的关键字样，但是默认也是从它继承而来，这是unity的规定。这样的类和普通没有继承自MonoBehaviour的类，有什么区别呢?区别很多，我们只说一点： 继承自MonoBehaviour的类，不需要自己创建它的实例，也不能自己创建（如
new 类名），编译的时候可以编译过去，但是执行的时候会给你一个错误在unity editor的console窗口，并且你new 后得到的东西为空；其实这是unity的一个bug，既然继承自MonoBehaviour的类不能new出来，为什么在编译的时候就给个错误，而是在运行时，如果没有看到unity editor的console窗口的内容真的很难知道为什么new的东西为空。为什么不需要自己创建呢？因为所有从MonoBehaviour继承过来的类，unity都会自动创建实例，并且调用被重载的方法，如我们经常用到的Awake,
Start, Update等。而普通类，就可以用new来创建实例了。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：179884次
积分：2703
积分：2703
排名：第9614名
原创：57篇
转载：205篇
(1)(3)(3)(26)(11)(54)(21)(4)(19)(6)(36)(12)(27)(17)(24)21883人阅读
.net(C#)（17）
最近在做一个小示例，发现类继承于MonoBehaviour的类，有很多个方法，于是乎必然要问出一个问题：这么多个方法，执行先后顺序是如何的呢？内部是如何进行管理的呢？于是在网上找了许多资料，发现了Richard Fine在2012年就已经发布了一篇文章，而且讲得算是相当深入，并且很有道理的，这里加上我的一些尝试与思考，分享给大家。
先贴上图，大家有个直观认识：
接下来，做出一下讲解：最先执行的方法是Awake，这是生命周期的开始，用于进行激活时的初始化代码，一般可以在这个地方将当前脚本禁用:this.enable=false，如果这样做了，则会直接跳转到OnDisable方法执行一次，然后其它的任何方法，都将不再被执行。
如果当前脚本处于可用状态，则正常的执行顺序是继续向下执行OnEnable，当然我们可以在另外一个脚本中实现这个脚本组件的启动：this.enab=
再向下执行，会进行一个判断，如果Start方法还没有被执行，则会被执行一次，如果已经被执行了，则不会再被执行。这是个什么意思呢？我们可以在某个脚本中将组件禁用this.enable=false，再启用时会转到OnEnable处执行，这时继续向下走，发现Start执行过了，将不再被执行。比如说：第一次启用时，将怪物的初始位置定在了(0,0,0)点，然后怪物可能会发生了位置的变换，后来被禁用了，再次启用时，不会让怪物又回到初始的(0,0,0)位置。
继续向后执行，就是Update了，然后是FixUpdate，再然后是LateUpdate，如果后面写了Reset，则会又回到Update，在这4个事件间可以进行循环流动。
再向后执行，就进入了渲染模块（Rendering），非常重要的一个方法就是OnGUI，用于绘制图形界面。当然，如果你使用了NGUI，这个生命周期的事情你就不用考虑了。
再向后，就是卸载模块（TearDown），这里主要有两个方法OnDisable与OnDestroy。当被禁用(enable=false)时，会执行OnDisable方法，但是这个时候，脚本并不会被销毁，在这个状态下，可以重新回到OnEnable状态（enable=true）。当手动销毁或附属的游戏对象被销毁时，OnDestroy才会被执行，当前脚本的生命周期结束。
特别要强调的是：这里虽然可以使用C#来写代码，但是这个类构造对象的生命周期，与MonoBehaviour的生命周期，是完全不同的。
可以通过如下示例：对脚本进行验证（两个脚本添加到同一个游戏对象上）：
脚本1Monster1：
& & void OnBecameInvisible()
& & & & Debug.Log(&invisible&);
& & & & MonsterController mc1 = this.gameObject.GetComponent&MonsterController&();
& & & & mc1.enabled =
& & void OnBecameVisible()
& & & & Debug.Log(&visible&);
& & & & MonsterController mc1 = this.gameObject.GetComponent&MonsterController&();
& & & & mc1.enabled =
脚本2MonsterController：
& & void Awake()
& & & & Debug.Log(&awake&);
& & & & this.enabled =
& & void OnEnable()
& & & & Debug.Log(&enable&);
& & & & this.enabled =
& & void Start()
& & & & Debug.Log(&start&);
& & & & //this.gameObject.SetActive(false);
& & void Update()
& & & & Debug.Log(&update&);
& & void OnGUI()
& & & & Debug.Log(&gui&);
& & void OnDisable()
& & & & Debug.Log(&disable&);
& & void OnDestroy()
& & & & Debug.Log(&destroy&);
如果您觉得有不对之处，欢迎指正，为了技术进步，我们一起努力。
Richard Fine的文章地址：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：74292次
积分：1126
积分：1126
排名：千里之外
原创：43篇
评论：25条
(1)(1)(2)(2)(2)(1)(2)(1)(2)(2)(4)(6)(2)(4)(2)(2)(13)(2)Unity脚本类为什么要尽量避免继承MonoBehaviour类_百度知道

我要回帖

更多关于 c monobehaviour 的文章

 

随机推荐