我有一个关于滚动的问题：在 Android 上有一个叫做 RecyclerView 的东西 使用 RecyclerView 创建动态列表 | Android 开发者 它会重用组件，而不是在滚动时添加越来越多的组件。看起来 Discourse 没有这样做？为什么呢？是使用了不同的策略吗？我隐约觉得自定义 VDOM 部件系统是为了解决这个问题（即不断增长的 DOM 元素列表），但说实话，我还是不明白这如何能解决这个问题。
也许有人能对此有所阐明 
3 个赞
我们一次只加载 20 篇帖子，使用所谓的“虚拟滚动”。
4 个赞
旧的 DOM 元素会怎么样？如果我继续滚动，我想会有越来越多的元素被添加到 DOM 树中。它们会在某个时候被移除吗？
1 个赞
我们将其保留在周围，我们有一个“隐藏”的逻辑组件，一旦您离视口很远，它就会用占位符替换元素，然后当您靠近元素时，我们会通过重新渲染来取消隐藏。这个魔法的阈值相当高。
4 个赞
@sam 你能给我一个链接，比较这项技术和回收组件的文章吗？我很想了解更多。你是如何做出这个决定的？我想 A tour of how the Widget (Virtual DOM) code in Discourse works 也与此相关。
1 个赞
我不认为我们有文章，但我可能记错了。也许 @eviltrout 还记得我们是否记录了关于“post cloaking”的一些决定。不确定。
2 个赞
抱歉，时间太久了我记不清了。
我不认为我们曾经完全分析过回收组件。隐形技术是一项重大突破，解决了我们当时的问题。
4 个赞
@eviltrout 我看到了这篇帖子 Evil Trout Inc.
经过多年等待 Android 或 Ember 性能的突破，我们决定是时候采取终极方案了：我们用自定义的虚拟 DOM 渲染器替换了我们最常用视图的 Ember 渲染引擎。
所以看起来 discourse 中的 vdom/widget 系统是为了应对 Android 性能问题而构建的。
引入 cloaking 的这个 commit 似乎发生在 vdom/widget 系统之后：
cloaking 和 vdom/widget 系统在某种程度上有关联吗？它们似乎都解决了性能问题。组件的回收利用会大大减少 DOM 元素的数量，所以类似 vdom/widget 这样的系统就不需要了，对吧？
2 个赞
我们之前有 vdom，但后来又重新实现了它，因为我们发现我们也需要它。\n\n回收组件应该可以减少内存并改善大型主题上的性能，但它不会像小部件那样显着加快渲染时间。
3 个赞
无法低估所有性能问题都与权衡有关。我认为 Ember 在这方面做得很好，它专注于那些有条理并且随着您添加更多功能而扩展的应用程序。对于您应用程序中的绝大多数视图，框架开销不会让您担心。但是，如果您正在渲染许多带有许多绑定的嵌套组件，情况可能会变得很糟糕。
虽然 Discourse 在表面上看起来很简单，但每个帖子都渲染了相当多的组件。我们有许多动态按钮、链接和效果，每次渲染帖子时都会应用，涉及超过 150 个属性。
我在 @eviltrout 写的博文中看到了这个。看起来 Ember 的性能通常不是问题，只是在 discourse 主题的特定情况下，对吧？Discourse 主题是组件（帖子）的长列表，其中包含许多组件（回复按钮、点赞按钮等）。这就是导致渲染性能下降的原因。
vdom/widgets 在一定程度上缓解了这个问题，因为它降低了渲染过程的成本。但到某个点，DOM 元素的数量会变得如此之大，以至于需要通过隐藏它们来减少。
组件回收意味着完全避免这个问题，只在屏幕上保留固定数量的 DOM 元素，当用户滚动内容时，这些元素会被重新利用。
如果我有什么误述，请纠正我。
谢谢，
Spirobel 
2 个赞