LOD(Level of Detail)
细节层次LOD，指根据物体模型的节点在显示环境中所处的位置和重要度，决定物体渲染的资源分配，降低非重要物体的面数和细节度，从而获得高效率的渲染运算。LOD是一种优化游戏效率的常用方法，缺点是占用大量内存(空间换时间)，使用这个技术一般是在解决运行时流畅度的问题，减少需要处理的模型顶点数目，降低GPU性能瓶颈的风险。
原理：当模型离摄像机（可以是人物摄像机或其他摄像机）很远时，然后根据距离的远近使用不同模型级别，远的时候就选择低级别的模型，近的时候选择高细节模型，这样就可以减少模型上面的顶点和面片数量从而提高性能。
Mipmap
Mipmap类似于LOD技术，LOD针对模型资源，Mipmap针对纹理贴图资源。
使用Mipmap后，贴图会根据摄像机距离的远近，选择使用不同精度的贴图。
优点：优化显存带宽，减少渲染，降低GPU负荷。可以根据实际情况，选择合适的贴图来渲染，距离摄像机越远，显示的贴图像素越低。
缺点：占用内存，因为Mipmap会根据摄像机远近不同而生成8张贴图。(如果不需要此效果，一定要把Generate Mipmap选项和Read/Write Enable选项取消勾选，对于一些较小的贴图，尽量不使用Mipmap)
Draw Call
unity渲染画面的过程：
1. 可见性测试
引擎首先经过简单的可见性测试，确定摄像机可以看到的物体。
可见面检测的两个基本原则：
①三角形在视锥体外的部分不可见，视锥体外的部分被裁剪，视锥体内的部分留待处理。
②像素可能会被离摄像机更近的物体遮挡。
2. 准备好物体的数据
然后把这些物体的顶点（包括本地位置、法线、UV等），索引（顶点如何组成三角形），变换（就是物体的位置、旋转、缩放、以及摄像机位置等），相关光源，纹理，渲染方式（由材质、Shader决定）等数据准备好。
3. 通知图形API开始绘制
然后通知图形API——或者就简单地看作是通知GPU——开始绘制，GPU基于这些数据，经过一系列运算，在屏幕上画出成千上万的三角形，最终构成一幅图像。
在Unity中，每次引擎准备数据并通知GPU的过程称为一次Draw Call。
这一过程是逐个物体进行的，对于每个物体，不止GPU的渲染，引擎重新设置材质、Shader也是一项非常耗时的操作。
举例：如果在画面上有一张 “木" 椅子、一张 “铁" 桌子，那理论上就会有两个 Draw Call。
有看到特別指出 “木" 与 “铁" 吗？这代表两物件是使用不同材质球或者不同的 Shader。
在 DirectX 或 OpenGL 里，对不同物件指定不同贴图或不同 Shader 的描述，就会需要呼叫两次Draw Call。
Draw Call Batching 技术
在一次Draw Call中批量处理多个物体。Draw Call Batching技术的核心就是在可见性测试之后，检查所有要绘制的物体的材质，把相同材质的分为一组（一个Batch），然后把它们组合成一个物体（统一变换），这样就可以在一个Draw Call中处理多个物体了（实际上是组合后的一个物体）。
Draw Call Batching的缺陷
但Draw Call Batching存在一个缺陷，就是它需要把一个Batch中的所有物体组合到一起，相当于创建了一个与这些物体加起来一样大的物体。
与此同时就需要分配相应大小的内存。这不仅会消耗更多内存，还需要消耗CPU时间。
特别是对于移动的物体，每一帧都得重新进行组合，
但对于静止不动的物体来说，只需要进行一次组合，之后就可以一直使用，效率要高得多。
这就需要进行一些权衡，否则得不偿失。
Dynamic Batching和Static Batching
Dynamic Batching：Dynamic Batching是完全自动进行的，不需要也无法进行任何干预。对于顶点数在300以内的可移动物体，只要使用相同的材质，就会组成Batch
Static Batching：Static Batching则需要把静止的物体标记为Static，然后无论大小，都会组成Batch。(收费)
高效利用Draw Call Batching
(1) 首先是尽量减少场景中使用的材质数量，即尽量共享材质，对于仅纹理不同的材质可以把纹理组合到一张更大的纹理中（称为Texture Atlasing）。
(2) 然后是把不会移动的物体标记为Static。此外还可以通过CombineChildren脚本（Standard Assets/Scripts/Unity Scripts/CombineChildren）手动把物体组合在一起，但这个脚本会影响可见性测试，因为组合在一起的物体始终会被看作一个物体，从而会增加GPU要处理的几何体数量，因此要小心使用。
(3) 对于复杂的静态场景，还可以考虑自行设计遮挡剔除算法，减少可见的物体数量同时也可以减少Draw Call。总之，理解Draw Call和Draw Call Batching原理，根据场景特点设计相应的方案来尽量减少Draw Call次数才是王道，其它方面亦然。
GC(Garbage Collection)
GC（垃圾回收器）是任何一个计算机设备的内存管理系统中重要的一部分。其主要目的是尝试去回收或释放系统中程序不再使用的资源。
这是一个自动化的系统，它确保了空闲的对象不再占用内存空间，这便充分优化了内存资源，提高了性能。尽管它是一个自动化的系统，但是还是可以在程序中对它进行控制。
通常的，GC在进行回收处理时，要确保该对象在程序中不再使用，方才对该对象进行回收。
GUID与fileID
GUID:Unity会为每个导入到Assets目录中的资源创建一个meta文件，文件中记录了GUID，GUID用来记录资源之间的引用关系。
fileID:用于标识资源内部的资源。
资源间的依赖关系通过GUID来确定；资源内部的依赖关系使用fileID来确定。
InstanceID(实例ID)
Unity为了在运行时，提升资源管理的效率，会在内部维护一个缓存表，负责将文件的GUID与fileID转换成为整数数值，这个数值在本次会话中是唯一的，称作实例ID(InstanceID)。
程序启动时，实例ID缓存与所有工程内建的对象(例如在场景中被引用)，以及Resource文件夹下的所有对象，都会被一起初始化。如果在运行时导入了新的资源，或从AssetBundle中载入了新的对象，缓存会被更新，并为这些对象添加相应条目。实例ID仅在失效时才会被从缓存中移除，当提供了指定文件GUID和fileID的AssetBundle被卸载时会产生移除操作。
卸载AssetBundle会使实例ID失效，实例ID与其文件GUID和fileID之间的映射会被删除以便节省内存。重新载入AssetBundle后，载入的每个对象都会获得新的实例ID。
