Unity3D 优化相关
抛砖引玉:
http://www.luzexi.com/unity3d%E4%BC%98%E5%8C%96%E4%B9%8B%E8%B7%AF/
关于图片
一、Unity3D自身会把导入的图片进行压缩,这些压缩不仅体现在内存上,而且也体现在包大小。
测试如下,相同的图片,压缩后的大小:
打包的大小分别对应如下:可以看到差别很大。
2014-12-30:
这里貌似 有个 误解:
我重新做了 这个 实验,1024 * 1024 RGBA 32 png 图片 与 1024 * 1024 RGB 8 jpg 图片 分别对应 不同的 压缩格式 并且 压缩的大小也不同。但是出来的包竟然神奇的是一样的。我无语了…………上图
二、如果一堆PreFab,被多个场景静态引用,和被多个场景动态引用,导出的大小差别不大。这里做个测试
根据图片顺序分别给出对应的包:可以看到,虽然有差别,但是不是很大,估计是静态引用本身需要一些资源吧。
三、图片不引用则不会加到包里
如果你加了一堆图片进到工程中,如果你对其不引用,那么你的的图片就不会加到工程中,必须要在这里吐槽一点,Unity3D就算一个空白工程也会有一个7M的APK,表示无语。
没有任何图片资源的工程
有图片资源的工程
关于脚本
一、有时候你打开一个按钮,弹出一个界面预设,如果这个界面携带很多资源,那么在生成的时候就会有点慢,这样给用户的感觉就是按下按钮 过了一会才会弹出那个界面。
这种情况需要异步加载,使用协程,最好不要自己使用协程加载界面,因为自己使用协程的话,那么只能在最后Destroy 自己,不然自己销毁后协程就消失了。
这样一来有两个问题。
一、在最后destroy 的之前,你 需要 额外做一段动画 来 保证与用户的交互。不然用户按下之后,你开着协程生成界面,自己又不消失,交互很不好。
二、
我们看这一段代码
1 public GameObject go; 2 3 4 float curTime; 5 6 IEnumerator Test() 7 { 8 curTime = Time.realtimeSinceStartup; 9 10 GameObject newgo = Instantiate(go) as GameObject; 11 12 float delta = Time.realtimeSinceStartup - curTime; 13 Debug.Log("Instantiate Use Time : " + delta); 14 15 yield return new WaitForSeconds(0.3f); 16 17 Destroy(transform.root.gameObject); 18 } 19 20 21 void OnDestroy() 22 { 23 Debug.Log("OnDestroy" + transform.name); 24 } 25 26 27 void OnGUI() 28 { 29 if (GUI.Button(new Rect(10, 10, 150, 100), "I am a button")) StartCoroutine(Test()); 30 }
相信我们都很清楚u3d 事件调用序列顺序,我们可以看到Instantiate 的时候 会把这个 生成物体 下的 Awake OnEnable 全部 执行一遍。
并且 原物体 的Destroy 是会在下一个轮回中进行的,是在 新生成物体 的Start之后。
这样一来,如果 原物体 是UIRoot的话,UIRoot 有一个
static public List<UIRoot> list = new List<UIRoot>(); 在新物体生成时候 list保存了 原物体 与 新物体 的两个UIRoot的引用。
list 在 新物体 Start 的时候进行 会全部 进行 scale 调整。
这个scale 调整是会把 原物体 与 新物体 都调整一遍,如果你的 新物体 生成比较快 并且 调用了 yield return new waitforseconds 之后才 销毁 原物体 , 你就会发现 原物体 卡一下的情况(因为此时还没有真正Destroy)。
2015-1-13 如果 每次 OnEnable 的时候 return, list 永远是空的。这个 时候 第二个UIROOT生成 如果此时第一个UIROOt 还没有销毁的话 还是会出现卡一下的情况,看来不是list的问题。
当然也可以因为 界面生成 花费的时间长,这样一来可能新物体 uiroot start 的 时刻 已经 超过了 yield return new waitforseconds 的 时刻。 此时 原物体 已经 destroy 了。也就不会出现卡一下的 原因了。但是这个时间不好掌握,所以还是不推荐了。
当然你也可以说干嘛不干脆一个 UIRoot 算了,原物体 与 新物体 都是这个一个 UIRoot 的子物体不就没事了。没错,这样一来是可以的,但是还没有解决第一个问题。
看到上述 2个 原因,那么我们可以明白 原物体 不能在最后 destroy 自己。可是又要使用协程,那么 我们就使用一个专门的UIManager 类来进行协程管理生成UI, 这里 UIManager 负责所有的 UI 物体的 生成 与 销毁。 先 Destroy 原物体, 再 开协程 一个个生成 新UI。用户只会看到自己按下后界面消失,至于界面的产生慢0.几秒是感觉不到的,(你也可以做一个tween传入,让产生慢一点的界面快一会传入,产生快一点慢一点传入,让用户错觉是都是产生都是差不多的,只要速度接近就行了。)
当然最好 都是 UIRoot 的 子物体,这样防止 每一个 新UI 因为都携带一个 UIRoot ,start 的 时候 都会 导致 scale 重新调整一遍。
另外,我建议用缓冲机制 setActive 代替 instantiage/destroy .(第一次除外,必须要用instantiate),这样一来最好都是一个UIRoot 的子物体,不然父物体使用destroy ,而子物体使用setactive 就冲突了。如果 全局都是 一个UIRoot ,那么我们destroy 与 setactive 都是 那一个uiroot 的 子物体,不会引发冲突。
另外模块对其的调用也可以统一,其他模块只需要调用 UIManager 的 Create(UIId id) 这个接口就可以了。内部到底是缓冲机制 还是 destroy 完全由自己维护。
总结一下,就是两点,
一、最好就是一个UIRoot ,所有新的UI都是其子物体。
二、就是 大 界面的 生成,使用协程,但是 不要 自己 使用 协程,交给uimanager 管理,这样可以先销毁自己,再生成新的ui。