连接应用程序开发实践和游戏开发实践

Question

我以前在游戏开发中遇到过一种叫做遮挡剔除的有趣的练习。我仍然在研究它是如何工作的，因为这主要是在游戏编程/工具/IDE中讨论的，所以我正在应用于应用程序开发中的数据管理。

wiki 这里上定义的该实践的其他名称:表面确定(也称为隐藏表面去除(HSR)、遮挡剔除(OC)或可见表面确定(VSD))。

我对实践的理解是，在绘制3D图形时，使用一种算法来根据某些视图/摄像机透视图来确定应该呈现的对象以及内存中的对象。这主要用于更有效地使用图形内存，但它并不一定会提高非图形内存的使用效率，因为未呈现对象背后的数据仍在被操作。

至于应用实践，我试图使用管理在应用程序运行时加载的数据的方面，其中数据可以是行、特定值或某些对象。

从应用程序的角度来看，这似乎类似于某种形式的延迟加载或无状态调用/事件。

private Lazy<Foo> DataItem;
public void GoToNextView()
{
    DataItem = new Lazy<Foo>();
    //return data to some display
}

对于上述示例，将通过新的构造函数清除/设置以前的数据以进行垃圾收集，然后将可能加载的新数据。

下面是一个具体的例子：

对于某些分页表，只有特定于加载页的数据，然后在“下一步”上卸载上一页并加载新页。在我的脑海中，这种实践更多地是基于事件的，这主要是由于在应用程序的UI/前端方面的思考。除非从某些UI的代码背后执行数据操作，否则我看不到在数据管理中使用延迟帮助的好例子，因为UI将更快地加载数据，而不是等待特定的步骤。(如果我的理解在延迟加载和无状态之间不正确，请更正)

从框架/自定义库的角度来看，我认为这两种实践之间可能会有更多的差异，因为有可能在某些数据加载之前进行更多的数据操作和增量步骤。

private Bar DataItem;
public Bar Process()
{
   DataItem = new Bar();
   //return some processed/manipulated Bar value
}

private Lazy<Bar> OtherDataItem;
public Bar OtherProcess()
{
    OtherDataItem = new Lazy<Bar>();
    //process other items
    //at some step, get the value associated to the variable via OtherDataItem.Value
    //return some processed/manipulated Bar value in respect to the other processed items
}

在这种情况下，数据管理存在差异，第一个数据将始终保存与类型关联的完整数据(结束是方法的任何一端或处理/垃圾收集)。根据我对惰性的理解，在调用值之前，数据实际上是不会被检索的，因此数据不会从头到尾被保存(我相信后台也会检查是否为惰性类型处理未使用的数据，我不知道这是真的还是处理其他一些特定的事情)。

我正在寻找实践中的应用程序开发，以实现相同的目标，数据管理的基础上，重点，就像在游戏开发中看到的实践。我不知道这是否真的是一种工具，而不是一种实践，因为研究倾向于引导我在“统一”中使用。

对于我的问题(S)，什么应用程序开发实践实际上属于数据管理实践显示的遮挡从游戏开发实践？如果上述两个指定的应用程序开发实践等同于该游戏开发实践，那么我试图传达的理解是否准确？

再次，我仍然在研究和深入任何我能找到的信息，我的知识可能在任何一方(应用程序或游戏开发)都是不正确的。我觉得我正处在一个时刻，我需要先检查一下我的理解，然后才能坚持这一想法并取得进展。我欢迎对我的理解作出任何更正或提出任何问题。

Answer 1

你在试图概括你学到的东西。这很好。这表明你不仅仅是死记硬背。

遮挡剔除与缓存问题非常相似。你必须限制有限资源的使用。如果做得正确，就会有很大的回报。做错了，代价很高。让它与众不同的是你如何预测什么是不需要的。

在应用程序中，您拥有以不同速度工作的资源。本地的速度比远程快。内存比硬盘快。但只有这么多的东西可以保存在本地和记忆中。你必须预测使用，并准备好接下来最有可能使用的东西。如果搞错了，事情就会变慢。

即使在打开文本文件时也会看到这种情况。滚动条向您显示这里有更多的内容，而不是您所看到的。但是由于屏幕只有这么大，所以你还没有看到其他的屏幕。

有些文本文件足够大，所以您只需要使用一个特殊的文本编辑器来打开它们，因为编写典型编辑器的人知道典型的文件大小应该是什么。正因为如此，他们认为将整个文件加载到内存中总是可以的。如果你的文件比你的记忆大，那就不酷了。

Answer 2

正如在其他答案中提到的，您提到的场景之间的相同之处在于，为了提高交互的速度，您正在尝试减少您在任何给定时间必须使用的数据集。这是在许多不同的情况下完成的。

要记住的一件事是，你需要首先了解为什么速度不是你想要的。分析会告诉你时间花在哪里，或者允许你加速这个部分，或者知道你是否达到了极限，也许需要尝试另一种方法。

问题不在于内存中有多少数据，而在于它在内存中的排列方式，或者其他一些您没有想到的特性。或者显示例程是缓慢的，你的数据安排很好，你实际上可以足够快地处理它。直到你决定了你的目标是什么，然后衡量，看看你是否实现了它，你不应该太担心如何去修正它。你可以花很多时间做一个很棒的新算法，结果发现你优化了错误的部分。