如何为 Flex 数据/项目渲染器实现对象池
您可以轻松地创建 Flex 4 项目渲染器（通过 itemRenderer 或 itemRendererFunction），从而允许您从自定义对象池中提取渲染器，但是如何将这些渲染器放回池中呢？
我知道布局虚拟化做了某种形式的对象池，但我想要一种方法来连接它。例如，当 itemRendererFunction 已分配给具有虚拟化布局的数据组时，项目渲染器构造确实被推迟，但实例不会被重新使用 - 如果可能的话，我希望能够在那里进行干预。
但即使在正常的虚拟化渲染器（实例被重新循环）的情况下，能够手动管理池仍然很有用。例如，可以在数据组之间共享池，以减少填充每个组所需的初始缓冲区。
有什么方法可以知道 Flex 何时丢弃项目渲染器实例？我有一种沉重的感觉，就是没有可靠的方法来判断——尽管也许应该有。
或者，是否有一个疯狂的黑客可以工作（例如将所有渲染器保留在池中并测试其舞台属性以确定可用性）？
You can hook into the creation of Flex 4 item renderers easily enough (through itemRenderer, or itemRendererFunction) allowing you to pull renderers from a custom object pool, but how would you put those renderers back into the pool?
I understand that layout virtualization does a form of object pooling, but I'd like a way to hook in to that. For example, when an itemRendererFunction has been assigned to a data group with a virtualized layout, item renderer construction is indeed deferred, but the instances are not re-used - I'd like to be able to intervene there, if possible.
But even in the case of normal virtualized renderers (where the instances are re-cycled) it would still be useful to be able to manage the pool manually. Pools could be shared between data groups, for example, to reduce the initial buffer required to populate each group.
Is there any way to know when Flex discards an item renderer instance? I have a sinking feeling that there is just no reliable way to tell - even though perhaps there should be.
Or, is there a crazy hack that could work (like keeping all renderers in the pool and testing their stage properties to determine availability)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来 SkinnableDataContainer 是开始的地方。文档建议 updateRenderer< /a> 是值得一看的地方，但它的代码没有太多作用。
它还调度 RendererExistenceEvent.RENDERER_ADD 和 RendererExistenceEvent.RENDERER_REMOVE 事件，如果您想捕获正在发生的情况，这些事件可能值得监听。
Looks like SkinnableDataContainer is the place to start. Documentation suggests updateRenderer is the place to look at, but the code for it doesn't do much.
It also dispatches RendererExistenceEvent.RENDERER_ADD and RendererExistenceEvent.RENDERER_REMOVE events, which might be worth listening for if you are wanting to capture what's going on.
这是一个非常有趣的问题，RENDERER_REMOVE 看起来是在使用后将实例存储在池中的好方法。但我不明白如何使用 itemRenderer 或 itemRendererFunction 向数据组提供实例（而不是类）...
It's a very interesting question and RENDERER_REMOVE looks like a good way to store instances in the pool after usage. But I don't see how itemRenderer or itemRendererFunction could be used to provide INSTANCES (instead of classes) to a data group...