GList创建一堆item非常耗时，请问有什么好的解决方案吗？
如题，GList是virtual的，item的component确实比较大，每次打开一个界面都可能会创建10几个出来，Unity的Deep Profile可以看出绝大多数耗时在ConstructFromResource上。有下面这几个解决方案或想法：
1. 利用GObjectPool自己扩展一个全局的对象池，在初始界面一口气创建适量的对象放到全局池。并改造GList的获取对象方式，优先从全局池拿对象，并在销毁界面的时候归还。实验效果还不错，但存在一些问题：
2. 克隆对象。只创建一个component，然后快速克隆多份，避免ConstructFromResource。这只是一个初步想法，不知道有没有实现的可能性。
3. 从根本上对component进行减肥。这是最后的无奈之举，因为这个承担了较多职责的通用component确实会给程序和策划的开发带来很多遍历。
想问一下谷主未来有没有计划做全局对象池，或者有没有其他解决方案，谢谢！
1. 利用GObjectPool自己扩展一个全局的对象池，在初始界面一口气创建适量的对象放到全局池。并改造GList的获取对象方式，优先从全局池拿对象，并在销毁界面的时候归还。实验效果还不错，但存在一些问题：
- 在销毁的时机上比较难掌控（比如经常发生归还对象池时displayObject已被销毁的情况）
- 列表滚动的时候会偶现尺寸不正确
- 对嵌套的组件无能为力。比如我们有一个公用的组件C，在很多界面会用到，又有组件A和B包含了C（在C的基础上扩展功能）。最理想的状况是全局池里只创建一堆C，A和B在construct的时候会自动取出C的副本来用
2. 克隆对象。只创建一个component，然后快速克隆多份，避免ConstructFromResource。这只是一个初步想法，不知道有没有实现的可能性。
3. 从根本上对component进行减肥。这是最后的无奈之举，因为这个承担了较多职责的通用component确实会给程序和策划的开发带来很多遍历。
想问一下谷主未来有没有计划做全局对象池，或者有没有其他解决方案，谢谢！
没有找到相关结果
已邀请:
8 个回复
谷主
赞同来自:
所以根本不需要什么全局对象池，你缓存一个个单独的对象还不如直接缓存整个UI，他们占的内存是一样的。常用的UI界面不卸载就行了，何必搞那么复杂。
谷主
赞同来自:
长路
赞同来自:
谷主
赞同来自:
长路
赞同来自:
在pc浏览器，更新房间列表用了616ms。房间列表下的结果列表用了40-100ms不等。
基本上都是additemfrompool耗时多。
一个房间列表有11ms的，一个结果item有2-5ms的。几百个结果，就要几百ms了
谷主
赞同来自:
几百ms很正常啊，可是你说的是几秒啊
长路
赞同来自:
Processor / GPU: 1.3 GHz Quad core Cortex A7 / Mali 400 MP2
Display / Resolution: 5.5 Inches / 854 x 4800 pixels
RAM: 1 GB
补两个图供参考。图是pc浏览器的。
谷主
赞同来自: