GList创建一堆item非常耗时,请问有什么好的解决方案吗?

如题,GList是virtual的,item的component确实比较大,每次打开一个界面都可能会创建10几个出来,Unity的Deep Profile可以看出绝大多数耗时在ConstructFromResource上。有下面这几个解决方案或想法:
 
1. 利用GObjectPool自己扩展一个全局的对象池,在初始界面一口气创建适量的对象放到全局池。并改造GList的获取对象方式,优先从全局池拿对象,并在销毁界面的时候归还。实验效果还不错,但存在一些问题:
  • 在销毁的时机上比较难掌控(比如经常发生归还对象池时displayObject已被销毁的情况)
  • 列表滚动的时候会偶现尺寸不正确
  • 对嵌套的组件无能为力。比如我们有一个公用的组件C,在很多界面会用到,又有组件A和B包含了C(在C的基础上扩展功能)。最理想的状况是全局池里只创建一堆C,A和B在construct的时候会自动取出C的副本来用

2. 克隆对象。只创建一个component,然后快速克隆多份,避免ConstructFromResource。这只是一个初步想法,不知道有没有实现的可能性。
3. 从根本上对component进行减肥。这是最后的无奈之举,因为这个承担了较多职责的通用component确实会给程序和策划的开发带来很多遍历。
 
想问一下谷主未来有没有计划做全局对象池,或者有没有其他解决方案,谢谢!
已邀请:

谷主

赞同来自:

如果你一个界面比较大型,那么创建后就别卸载了,一直放在内存用,明知他创建比较耗时,那我搞不懂你反复create dispose的意义。这无关什么GList,我们是以UI界面为单位优化的,例如一个排行榜界面,整个游戏周期你可以就创建一次,如果你觉得就这一次耗时都不能接受,那还可以用CreateObjectAsync异步创建啊。
 
所以根本不需要什么全局对象池,你缓存一个个单独的对象还不如直接缓存整个UI,他们占的内存是一样的。常用的UI界面不卸载就行了,何必搞那么复杂。

谷主

赞同来自:

补充一下,你只说非常耗时,但并未给出任何具体数据。一般游戏中的UI界面,构建时间应该是几十ms内,这完全说不上非常耗时。

要回复问题请先登录注册