复杂页面的 SVG 内存占用
我的设计需要大量小条形图（迷你图大小）。一个典型的页面可以轻松包含 60 多个图表，每个图表显示 100 多个数据点。类似的东西的浏览器内存占用会令人望而却步吗？我还可以使用输出 png 的服务器端渲染器，但 SVG 似乎可以做更多的事情。
其他考虑因素：SVG 可能会被 Rapheal.js 转换为 IE 的 VML。所以那里的内存占用也需要合理。
任何帮助或找到好的答案的方法都值得赞赏。
I have a design that calls for a large number of small bar graphs (sparkline size). A typical page could easily have 60+ graphs showing 100+ datapoints per graph. Would the in-browser memory footprint of something like that be prohibitive? I could also go with a server-side renderer that outputs pngs, but it seems much more could be done with SVG.
Other considerations: The SVG will likely be turned into VML for IE by Rapheal.js. So the memory footprint over there needs to be reasonable as well.
Any help, or methodology for finding a good answer is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您描述的 svg 元素的数量肯定会在内存消耗方面造成问题。
与 canvas 元素相反，SVG 要求浏览器为所有表示的元素维护一个对象模型。此对象模型使您可以轻松地将事件连接到特定元素的单击。你不必跟踪正方形在屏幕上的位置、它有多大、缩放比例等。然而，这是以内存要求为代价的，并且与画布标签形成鲜明对比，后者只是令人担忧关于绘制像素的颜色，并且您必须担心跟踪单击的“对象”。
因此，当试图弄清楚性能是否会成为一个问题时，通常明智的做法是从目标硬件的最低公分母开始。您的目标是移动设备吗？您的目标是笔记本电脑和台式机吗？
一旦您找到了该问题的答案，就可以构建一个针对该硬件的虚拟应用程序，该应用程序会反复使用一个虚拟图（100 个数据点）60 次。 ，以便您可以以反映用户与其交互方式的方式与显示器进行交互（如果您希望用户能够滑动图表，则应该包括在内，等等）。
构建足够多的内容 ，现在尝试使用基本交互，如果性能满足您的要求（即应用程序受众的期望）。
就这种性质的应用程序的性能增强而言，我建议使用 ajax 和 svg 的组合。我会生成图表的缩略图（使用 SVG，由于细节减少，它们的占用空间会小得多），并且当用户决定获取更多详细信息时，我会使用 ajax 来获取该特定的更详细的 SVG 表示图形。
享受构建您的应用程序的乐趣:)
The quantity of svg elements you describe could certainly pose a problem in terms of memory consumption.
As opposed to the canvas element, SVG requires the browser to maintain an object model for all of the represented elements. This object model makes it easy for you to wire an event to the clicking of a particular element. You don't have to keep track of where the square is on the screen, how big it is, scaling, etc. However, this comes at a price of memory requirements, and stands in sharp contrast to the canvas tag, which just worries about what color to paint pixels, and you have to worry about tracking what "object" was clicked.
So, when trying to figure out if performance will be an issue, it's usually wise to start with the lowest common denominator, so-to-speak, in terms of your targeted hardware. Are you targeting mobile devices? Are you targeting laptops and desktops?
Once you have an answer to that question, build out a dummy application targeted at that hardware that uses one dummy graph (100 data points) over and over again 60 times. Build just enough so you can interact with the display in a way that mirrors how your users will interact with it (if you want users to be able to slide the graphs around, that should be included, etc.)
Using that dummed-down prototype, now try using the basic interaction and if the performance meets your requirements (i.e., the expectations of your application's audience.)
In terms of performance enhancements to an app of this nature, I'd suggest using a combination of ajax and svg. I'd generate thumbnails of the graphs (using SVG, they'd be much smaller footprints thanks to reduced detail), and as a user decides to get more detail, I'd use ajax to grab a more detailed SVG representation of that particular graph.
Enjoy building your app :)
喜欢 Adam 的想法，即使用 PNG 替代 SVG 迷你图，并根据需要下拉 SVG。这些可以很容易地在服务器端呈现，使用相同的 SVG 源输入到库中，如 librsvg 或 < a href="http://www.cairgraphics.org" rel="nofollow">开罗。
如果您正在寻找使用画布的东西（带有 IE 的自动解决方法），请查看 jQuery Sparklines 库，它可能已经完成了您需要的一切。
Love Adam's idea of using a PNG stand-in for the SVG sparklines and pulling down SVG on an as-needed basis. These could easily be rendered on the server-side using the same SVG source fed into a library like librsvg or maybe Cairo.
If you're looking for something that uses canvas (with automatic workarounds for IE) take a look at the jQuery Sparklines library, it may already do everything you need.
标准化数据是关键。在大多数情况下，在 50 像素宽的迷你图中，人眼不需要也不会注意到 100 个数据点。使用数据归一化从 100 点减少到 5 点，这样更方便眼睛并且性能更高。
当您拥有大量迷你图时，服务器端迷你图图像精灵往往会优于前端 SVG/Canvas 生成的迷你图。
这是 Java 中的快速服务器端迷你图解决方案，它使用出色的 PNG 压缩：
https://github.com /AnthumChris/anthum-sparkline
Normalizing your data is key. In most instances, 100 data points are not needed nor noticeable to the human eye in a sparkline that's 50px wide. Use data normalization to reduce from 100 points to 5, which is easier on the eyes and more performant.
Server-side sparkline image sprites will tend to outperform front-end SVG/Canvas-generated sparklines when you have large numbers of them.
Here's a fast, server-side sparkline solution in Java that uses excellent PNG compression:
https://github.com/AnthumChris/anthum-sparkline