Firemonkey和大量数据
我刚刚看了一下 Firemonkey 的网格实现，结果发现这是一个非常简单的实现（只有 1800 行，对于网格实现来说似乎不多）。它几乎不进行自定义绘制，而是聚合了许多其他控件 - 这似乎是 Firemonkey 的做事风格。
例如，每一列都保留一组控件 - 每个单元格一个。对于具有 1,000,000 行的普通文本列，网格将在内存中保留 1,000,000 个编辑控件 - 这对我来说似乎有点疯狂。 （编辑：现在不太确定这个假设是否正确。它似乎考虑了单元格的可见性，这可能意味着它确实提供了类似虚拟模式的东西，但我不太确定......< /strong>)
我的问题：毫无疑问，Firemonkey 的这种组件聚合设计看起来简单而优雅，但它真的能够很好地适应网格中必须显示的数据量吗？我无法想象它在处理大量行时确实表现良好。 Firemonkey 处理大量数据的方式是什么？
感谢您的任何意见。
I just had a look at Firemonkey's grid implementation and it turns out that it is a very simple implementation (only 1800 lines which seems not much for a grid implementation). It does almost no custom painting but does instead aggregate a lot of other controls - which seems to be the Firemonkey style of doing things.
For example, each column keeps an array of controls - one for each cell. For a normal text column with 1,000,000 rows, the grid would keep 1,000,000 edit controls in memory - which seems a little crazy to me. (EDIT: not so sure now if that assumption is right. It seems to take the visibility of cells into account, which could mean it does provide something like a virtual mode, but I'm not quite sure...)
My question: Without any doubt, this component-aggregating design of Firemonkey seems simple and elegant but does it really scale well with the amount of data that has to be displayed in the grid? I cannot imagine that it does perform well with a large number of rows. What is the Firemonkey way of handling large amounts of data?
Thanks for any input.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
FireMonkey 网格仅控制可见行数。
因此，如果您有一个包含 10 行和 3 列的网格，它将创建 30 个单元格控件。
用 10.000 条记录填充网格没有问题：当您滚动时，30 个单元格控件将被重用并映射到新的可见行。
是的：我对此做了一些测试，因为我们有包含 100.000 条记录的 TMS 网格:-)。
如果您使用OnGetCellText（所以不是TStringgrid，它对于大量记录非常慢，尤其是TMS网格（基于VCL stringgrid））它非常快（OnGetCellText仅检索可见单元格的数据）。我们将此技术与我们的数据对象结合使用（这些对象已经加载，因此无需再次用字符串值填充网格的每个单元格...）并且 TMS 和 FMX 网格都非常快，可以处理 100.000 条记录或更多！
The FireMonkey grid only has controls for the number of visible lines.
So if you have a grid with 10 visible rows and 3 columns, it will create 30 cell controls.
Filling the grid with 10.000 records is no problem: when you scroll the 30 cell controls are reused and mapped to the new visible rows.
And yes: I did some tests with this because we have TMS grids with 100.000 records :-).
If you use OnGetCellText (so not TStringgrid, which is very slow with lots of records, especially TMS grid (based in VCL stringgrid)) it is very fast (OnGetCellText only retrieves data of visible cells). We use this technique in combination with our data objects (these are already loaded, so no need to fill each cell of the grid with the string value again...) and both TMS and FMX grids are very fast with 100.000 records or more!