我们有一个需求，我们需要在多个网格中显示大量数据，还需要提供在UI端进行排序的选项。有两种方法：
总体感觉是，采用方法1时，UI会不必要地加载大量数据（例如跨网格的10k条记录-范围为1-2 MB），并且可能会导致UI性能问题-不要忘记满足这些请求的服务器适用于接近一百万的大型用户群。使用方法2，每当用户单击排序时，都会有一个API调用，并且服务器资源被浪费在对巨大数据进行重新排序上（用户只需要看很少的10条记录即可）
答案 0 :(得分：0)
还有第三种方法：
对于每个可能的排序顺序，服务器都有不同的索引。添加新数据后，会将其插入每个索引的正确位置。每个用户的UI都向服务器询问与用户选择的排序顺序相对应的索引的“条目N * K到（N = 1）* K”。没有排序。无需将所有内容都加载到每个UI中。
注意1：您可能可以作弊-例如如果您有一个“按字母升序排序”的索引，则可以使用相同的“按字母降序排序”的索引。这样，您可能只需要8个排序顺序的4个索引即可。
注意2：您可能可以作弊更多。您可以将数据拆分为“存储桶”，而不是为每个排序顺序创建一个索引，并为每个排序顺序的每个存储桶创建一个索引。例如。可以用一个索引代替“以A开头的索引”，而不用一个索引以“以B开头的索引”，以同样的方式，而不是使用一个索引以“按时间顺序排序”您今年可以有一个索引，去年可以有一个索引... ...这有助于加快插入成本（添加新数据时），并可以改善UI（例如，一些“跳到存储桶”按钮的用户）可以使用）。
我们可以参考任何行业标准做法吗？
行业标准惯例取决于哪个行业。太多的事情正在转移到“ Web应用程序”上，在该行业中，行业标准做法是让能力不强的开发人员以低于最低工资的价格工作，并使用效率极低的框架将其浪费掉。
我们如何量化UI性能？
我会使用响应时间（应用启动和显示用户数据所需的时间，滚动/移动到其他页面后显示数据所需的时间，用户单击其他页面之间的时间“排序顺序”按钮以及显示新排序顺序中的数据的屏幕等）。