原归正转，经过时间差分段分析后，发现是某个重要组件---我们自己制作的有特殊用处的文本组件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(如本例情况)，一定要有自己的算法来管理深度。
