从内存分配可以看出，JAVA中的对象都是在堆上进行分配，当对象没有被引用时依赖来回收内存，如果对象数目较多，则会给带来很大的压力，从而间接影响到应用的性能。为了减少在堆中分配临时物体的数量，通过逃生分析确定外部不会访问物体。如果物体无法逃脱，可以在堆栈上分配内存，使物体占用的内存空间可以与堆栈帧一起销毁，从而减轻垃圾收集的压力。
在加载完成一个的后，在scene中所有使用的asset，包括所有的材料、地图、动画、声音等材料。全部内容自动加载(这就是Unity的智慧所在)。这就是说，当一个关卡呈现在用户面前时，所有Unity编辑器所识别的本关卡资源都已预加载，因此，在此关卡中，用户将会有很好的体验，无论是更换贴图、声音或播放动画时，都不会有额外的加载，这就是内存占用会变多。Unity的最初设计目标仍然是针对桌面，实际上无限制的内存和虚拟内存使得这种占用看起来并不成问题，但是在后来移动平台的兴起和移动设备游戏的大量开发中，这种内存策略已经成为一个问题。所以，当面向移动设备游戏的开发时，要尽可能少地直接引用的资源，而使用的方法来从硬盘读取资源。
它是用尽快将其卸载，最后，这是一个用来处理时间和内存空间。怎样获得最佳结果没有标准答案，需要自己进行权衡。当关卡结束时，此关卡中使用的所有资源都将被卸载标记。
在切换关卡时，不会卸载所有相关资源。一般用来维持分数、级别等不同的等级状态，如果包含了很多资源，如大量的地图、声音等占用了大量内存的东西，这种资源在场景切换时不能卸载，而且会一直占用内存。
应尽量避免这种情况，脚本中的另一种资源引用也是需要注意的。当场景转换时，大多数脚本都会失效并被回收，但是，保留于场景之间的脚本不在这个栏，并且这些脚本可能包含对其他对象或资源的引用，因此相关资源将无法被释放，这种情况实在是不得要领，此外，单实例在场景切换时也不会失效，同样，如果这个单例包含了大量资源的引用，它将成为一个大问题。
所以，必须尽可能减少代码的耦合和对其他脚本的依赖性。在这一点上不能真正避免，那么对于这些不再使用的引用对象，应该手动调用。或将其设为空，因此，当垃圾收集时，这些内存将被认为已经没有用处了。
值得注意的是，Unity在场景开始时，基于场景构成和参考关系自动读取的资源，只有当一个新场景或reset当前场景被读取时才被清除。
这样，内存占用就不可避免了。对于小型内存环境，占用初始内存的这一部分非常重要，因为它将决定您的关卡是否可以正常加载。所以计算资源充足。
或者当你在Hierarchy中手动使用时，尽可能减少在使用引用，这将极大地降低内存占用。只有那些没有任何指向的资源会被回收，所以要确保当资源不再使用时，将所有对该资源的引用设置。
另外要注意的是，对于获取的资源，两个方法都不能回收在任何场景开始时自动加载的资源，和这类类似的方法一样，这些手动自愿加载和卸载的方法都是优化内存占用的不二法则。
以上是关于Unity3d优化的详细信息，特别是查看Unity3D的技术手册，以获得最佳效果。不同语言之间，程序中资源真正所有者的概念也不同。这意味着，通过资源，我们共同引用了堆积和堆积值的变量，或者包括打开文件描述符、数据库连接套接字、网络套接字等变量。这些内存占用从它们存在到完成程序调用及之后的时间。资源拥有者的一个重要责任是明智地释放使用的内存。这是因为，如果内存分配不能在合适的时间和地点取消，存储就会泄漏。
>>>>>>点击进入游戏开发专题
