话题环境: ActionScript 2.0, 组件开发
今天中午在QQ群里待了一会儿,开始着手解决我们项目中存在的性能瓶颈。
一下午和同事在分析和解决,搞定后,回到群上,小东等弟兄们已经不在了,就我一个了。好像还欠了一个问题没有回答,不好意思。
原归正转,经过时间差分段分析后,发现是某个重要组件---我们自己制作的有特殊用处的文本组件CTextView---的初始化耗时太长。
进一步trace分析,在生成子组件函数和视图排版函数中发现,属于生成部分的时间消耗太长。里面的逻辑是生成了一定数量的特定MovieClip作为容器。而性能的瓶颈就在这儿。
容器的生成原来都是通过DepthManager.createChildAtDepth()这个方法生成的。于是我更换生成方法,先用attach方法生成一个该类型的MovieClip, 然后其余的全部通过MovieClip.duplicateMovieClip(),来制作复本。
原本使用DepthManager 创建的初衷是有它来管理深度,我们比较省心和放心。更换成duplicate后,那么深度的管理得由我们自己来操心。后来的改动也证明确实在深度问题上,又绊了我们一小下。后来结合上下文,用了简单一个算法来管理了深度。
再一测试:
乌拉,原本生成时间是 3344 -47= 3297 毫秒, 现在则是 766 - 63 = 703毫秒,性能提高4.68倍。
有意义的一下午!!
梳理一下本节疑难要强调的几个知识点:
1. DepthManager的所有create方法,包括UIComponent所有的create方法,其实质上都是attach movieclip的。
2.如果有大量的同质Movieclip实例,都可以用duplicateMovieClip来实现,这样执行效率高出很多。
只要是继承至MovieClip的Component,根据里氏代换原则,都全部可以使用duplicateMovieClip来复制。
也包括 一部分V2的UIComponent。
attach在Flash Player实现中,比直接的duplicateMovieClip要慢很多,这是一条基本原则,切记。
3.在大型项目中,尤其是组件的开发中,对深度的管理非常重要。一般应当尽可能去使用DepthManager来管理。如果没有用,或者不能用DepthManager(如本例情况),一定要有自己的算法来管理深度。