处理大型 Backbone 集合
我们正在设计一个主干应用程序，其中每个服务器端集合都有可能包含数万条记录。作为一个类比 - 考虑进入电子邮件应用程序的“已发送邮件”视图。
在我见过的大多数 Backbone 示例中，涉及的集合最多为 100-200 条记录，因此获取整个集合并在客户端中使用它相对容易。我不相信更大的集合会出现这种情况。
有人在大型服务器端集合上使用 Backbone 做过任何工作吗？
- 您是否遇到过特定集合大小的性能问题（尤其是在移动设备上）？
- 关于从服务器获取多少数据，您做出了哪些决定？
- 您下载全部内容还是只下载一部分？
- 您将自定义机制的逻辑放在哪里（例如集合原型？）
We're designing a backbone application, in which each server-side collection has the potential to contain tens of thousands of records. As an analogy - think of going into the 'Sent Items' view of an email application.
In the majority of Backbone examples I've seen, the collections involved are at most 100-200 records, and therefore fetching the whole collection and working with it in the client is relatively easy. I don't believe this would be the case with a much larger set.
Has anyone done any work with Backbone on large server-side collections?
- Have you encountered performance issues (especially on mobile devices) at a particular collection size?
- What decision(s) did you take around how much to fetch from the server?
- Do you download everything or just a subset?
- Where do you put the logic around any custom mechanism (Collection prototype for example?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，在大约 10,000 个项目时，旧浏览器无法很好地处理显示。我们认为这是一个带宽问题，但即使在本地，高性能机器可以提供尽可能多的带宽，Javascript 也有点晕倒了。在 Firefox 2 和 IE7 上也是如此；从那以后我就没有在更大的系统上测试过它。
我们试图获取所有内容。这不适用于大型数据集。这对 Android 浏览器尤其有害。
我们的数据采用树结构，其他数据取决于树结构中数据的存在。数据可能会因其他用户或程序其他部分的操作而发生变化。最终，我们使树结构只获取当前可见的节点，系统的其他部分独立验证了它们所依赖的数据集的有效性。这是一个竞争条件，但在实际部署中我们从未发现任何问题。我本来想在这里使用
socket.io，但管理层不理解或不信任它。由于我使用 Coffeescript，所以我只是继承了 Backbone.Collection 并创建了自己的超类，它还实例化了自定义
sync()调用。调用超类方法的语法在这里非常有用：Yes, at about 10,000 items, older browsers could not handle the display well. We thought it was a bandwidth issue, but even locally, with as much bandwidth as a high-performance machine could throw at it, Javascript just kinda passed out. This was true on Firefox 2 and IE7; I haven't tested it on larger systems since.
We were trying to fetch everything. This didn't work for large datasets. It was especially pernicious with Android's browser.
Our data was in a tree structure, with other data depending upon the presence of data in the tree structure. The data could change due to actions from other users, or other parts of the program. Eventually, we made the tree structure fetch only the currently visible nodes, and the other parts of the system verified the validity of the datasets on which they dependent independently. This is a race condition, but in actual deployment we never saw any problems. I would have liked to use
socket.iohere, but management didn't understand or trust it.Since I use Coffeescript, I just inherited from Backbone.Collection and created my own superclass, which also instantiated a custom
sync()call. The syntax for invoking a superclass's method is really useful here:就像 Elf 所说，你应该真正对从服务器加载的数据进行分页。通过下载可能不需要的项目，您可以节省服务器上的大量负载。只需在 Chrome 本地创建一个包含 10k 个模型的集合就需要半秒钟。这是一个巨大的负担。
您可以使用工作线程将工作放在另一个物理 CPU 线程上，然后使用瞬态对象将其发送到主线程，以便在 DOM 上渲染它。
一旦你有了一个集合，DOM 延迟渲染中的大渲染就只能让你到目前为止。内存将缓慢增加，直到浏览器崩溃（在平板电脑上速度很快）。您应该在元素上使用对象池。它将允许您为内存设置一个较小的最大大小并将其保留在那里。
我正在为 Backbone 构建一个 PerfView，它可以渲染 1,000,000 个模型并在 Chrome 上以 120FPS 滚动。代码全部位于 Github https://github.com/puppybits/BackboneJS-PerfView 上。它已被注释，因此您需要进行许多其他优化才能显示大型数据集。
Like Elf said you should really paginate loading data from the server. You'd save a lot of load on the server from downloading items you may not need. Just creating a collection with 10k models locally in Chrome take half a second. It's a huge load.
You can put the work on another physical CPU thread by using a worker and then use transient objects to sent it to the main thread in order to render it on the DOM.
Once you have a collection that big rendering in the DOM lazy rendering will only get you so far. The memory will slowly increase until it crashes the browser (that will be quick on tablets). You should use object pooling on the elements. It will allow you to set a small max size for the memory and keep it there.
I'm building a PerfView for Backbone that can render 1,000,000 models and scroll at 120FPS on Chrome. The code is all up on Github https://github.com/puppybits/BackboneJS-PerfView. It;s commented so theres a lot of other optimizations you'd need to display large data sets.