第7章 加载和使用模型

截止到现在的所有例子使用的几何顶点属性都是编译到应用中的。第一个例子，OpenGLES_Ch2_1,硬编码了三个顶点的位置来定义一个三角形。第5章生成的C语言头文件也包含更复杂的几何定义。把顶点数据直接编译到应用中有利于快速加载，但是也有局限。

在运行时加载顶点属性和其他数据要比把数据直接编译到应用中更加灵活和动态。本章会介绍运行时数据加载。存在许多用于创建数据的工具，也存在许多互不兼容的存储数据的格式。因此想要解析文件中的数据并把加载的数据最终转换为顶点属性、纹理，以及OpenGLES需要的效果的话，就可能需要使用多个技术。

在开始编码之前，有必要了解一下在运行时加载数据的原因。专注于最终目标有助于从无数的可用选项中选择一个技术方法。下面是假设的目标:

• 有一个可以接受的加载和运行性能。
• 减少运行时对稀缺内存的消耗量。
• 不必编译就可以向应用更新或者添加数据。
• 利用多个团队成员来简化应用的开发。

在应用加载时从iOS文件系统中读取数据永远不如把数据编译到应用中速度快。不过，如果小心使用的话，从文件系统读取数据也可以获得一个可接受的性能。关键是要以需要最少处理的方式来保存数据，以利于加载。另一种方法是延时加载数据，尽可能在最后一刻加载数据，或者在一个独立于主应用用户界面的线程中异步加载数据。最主要的目的是让应用尽可能快地响应用户。

编译到应用中的数据会在应用整个运行过程中一直寄存于CPU控制的内存中。为了渲染，数据(至少其中一些)的第二份副本必须要保存在GPU控制的内存中。在使用小的数据集时，保持相同数据的多个副本可能不是问题,但是嵌人式系统的内存是稀缺的。当有多个复杂场景时，保存两个副本所要耗费的额外存储空间应该是不可接受的。更糟糕的是，当同一时间不管怎样都只能看到一个场景时，在CPU控制的内存中同时保存多个场景就是浪费。只加载当前需要的数据，把它传递给GPU控制的内存，然后释放CPU控制的内存，这样可以极大地减少总内存需求。

打算与用户创建的数据交互的应用显然不能把数据编译到应用自身中。一些应用在运行时通过互联网接口下载数据。一个游戏可能会首先发布限制版，然后通过因特网捐助或者通过应用内购买来获得额外的关卡。理论上，运行时加载可以让所有这些情景成为可能。

最后，运行时加载通常可以简化应用的开发。在大型开发团队中，当数据生产与软件开发的进度不同时，运行时加载尤其重要。设计师希望在应用中能够及时地看到他们的创作，并做一些处理来实现快速迭代改进。加载设计师新数据的理想方式是不用重启应用就可以加载，更别说重新编译了。