Unity内存分析
2015-12-25 12:22
543 查看
转载自:http://forum.china.unity3d.com/thread-1091-1-1.html
Used Total和Reserved 均是物理内存,其中Reserved是unity向系统申请的总内存,Unity底层为了不经常向系统申请开辟内存,开启了较大一块内存作为缓存,即所谓的Reserved内存,而运行时,unity所使用的内存首先是向Reserved中来申请内存,当不使用时也是先向Reserved中释放内存,从而来保证游戏运行的流畅性。
一般来说,我们均建议尽可能地控制Used Total的大小,Used Total越大,则Reserved Total越大,而当Used Total降下去后,Reserved Total也是会随之下降的(但并不一定与Used Total同步)。
通过PSS来查看移动端的内存是相当不准确的。Profiler记录的是通过引擎分配的真实物理内存,而PSS中多出的内存大致分为两部分,一部分是App在运行会调用底层的一些核心库,这些库都会占用一定的内存;第二部分则是移动系统决定的,即虽然游戏中已经将资源卸载掉,但在系统层面上,系统并不会及时将其清除,而是将其缓存住,这样做的处理是为了便于以后该资源的复用效率,同时,当系统的内存分配达到上限时,系统本身会调用内存清理机制来轮询这些缓存区域,进而释放内存。
ManagedHeap的内存值是由所写的C#代码来引起并造成的,建议时刻关注CPU Profiler中的GC Collcet值,查看由哪些选项分配较大或不断分配GC Allocation。这个是造成ManagedHeap不断增大的原因。
GfxDriver可以理解为GPU显存开销,主要由Texture,Vertex buffer以及index buffer组成。所以尽可能地减少或释放Texture和mesh等资源,即可降低GfxDriver内存。
ManagedHeap的大小与你的GameObject数量、资源量无关,仅是你的代码造成的。
如果是在Editor中运行时,那么该数值是会比较大,因为编辑器运行游戏时,底层会做很多额外的事情,比如更多的log输出等,从而占据较多的堆内存。
而如果在真机运行时看到该数值时,那么80M是比较大的,这个需要你对你的代码来进行优化,避免一些不必要的堆内存分配。比如,不要总是new一个class、array、container等等。你可以在CPU Profiler中的GC Alloc处查看游戏每帧的堆内存分配。
同时,Managedheap的大小完全是有Mono来决定的,用户所写的任何脚本均是由Mono来负责解析。同时,Mono的堆内存是只升不降的,这是Mono的一个问题,Unity暂时也无法对其进行修改。因此,只能建议开发者在编写代码时尽可能地优化嗲吗,避免不要的堆内存分配。
Used Total和Reserved 均是物理内存,其中Reserved是unity向系统申请的总内存,Unity底层为了不经常向系统申请开辟内存,开启了较大一块内存作为缓存,即所谓的Reserved内存,而运行时,unity所使用的内存首先是向Reserved中来申请内存,当不使用时也是先向Reserved中释放内存,从而来保证游戏运行的流畅性。
一般来说,我们均建议尽可能地控制Used Total的大小,Used Total越大,则Reserved Total越大,而当Used Total降下去后,Reserved Total也是会随之下降的(但并不一定与Used Total同步)。
通过PSS来查看移动端的内存是相当不准确的。Profiler记录的是通过引擎分配的真实物理内存,而PSS中多出的内存大致分为两部分,一部分是App在运行会调用底层的一些核心库,这些库都会占用一定的内存;第二部分则是移动系统决定的,即虽然游戏中已经将资源卸载掉,但在系统层面上,系统并不会及时将其清除,而是将其缓存住,这样做的处理是为了便于以后该资源的复用效率,同时,当系统的内存分配达到上限时,系统本身会调用内存清理机制来轮询这些缓存区域,进而释放内存。
ManagedHeap的内存值是由所写的C#代码来引起并造成的,建议时刻关注CPU Profiler中的GC Collcet值,查看由哪些选项分配较大或不断分配GC Allocation。这个是造成ManagedHeap不断增大的原因。
GfxDriver可以理解为GPU显存开销,主要由Texture,Vertex buffer以及index buffer组成。所以尽可能地减少或释放Texture和mesh等资源,即可降低GfxDriver内存。
ManagedHeap的大小与你的GameObject数量、资源量无关,仅是你的代码造成的。
如果是在Editor中运行时,那么该数值是会比较大,因为编辑器运行游戏时,底层会做很多额外的事情,比如更多的log输出等,从而占据较多的堆内存。
而如果在真机运行时看到该数值时,那么80M是比较大的,这个需要你对你的代码来进行优化,避免一些不必要的堆内存分配。比如,不要总是new一个class、array、container等等。你可以在CPU Profiler中的GC Alloc处查看游戏每帧的堆内存分配。
同时,Managedheap的大小完全是有Mono来决定的,用户所写的任何脚本均是由Mono来负责解析。同时,Mono的堆内存是只升不降的,这是Mono的一个问题,Unity暂时也无法对其进行修改。因此,只能建议开发者在编写代码时尽可能地优化嗲吗,避免不要的堆内存分配。
相关文章推荐
- IE7降低内存和降低CPU的几个技巧
- 如何高效的使用内存
- DOS下内存的配置
- XP/win2003下发现1G的内存比512M还慢的解决方法
- PowerShell实现动态获取当前脚本运行时消耗的内存
- C#实现把dgv里的数据完整的复制到一张内存表的方法
- SQL语句实现查询SQL Server内存使用状况
- C语言内存对齐实例详解
- 深入学习C语言中memset()函数的用法
- 全局变量与局部变量在内存中的区别详细解析
- VB读取线程、句柄及写入内存的API代码实例
- php运行提示:Fatal error Allowed memory size内存不足的解决方法
- IE浏览器IFrame对象内存不释放问题解决方法
- C#之CLR内存深入分析
- JavaScript 变量、作用域及内存
- JavaScript避免内存泄露及内存管理技巧
- J2ME编程中的几个重要概念介绍
- c++实现逐行读取配置文件写入内存的示例
- Shell脚本查看进程内存真实占用情况
- w3wp.exe占用cpu过高的解决方法第1/2页