[分享干货晒技术]Unity 手游内存优化分享

发表于2015-07-28
评论2 6.4k浏览

Unity 手游内存优化分享


这里从三个纬度来分享下内存的优化经验:代码层面、贴图层面、框架设计层面。

.代码层面。

       1.foreach

       Mono下的foreach使用需谨慎。频繁调用容易触及堆上限,导致GC过早触发,出现卡顿现象。

       特别注意的是在Update中如果非必要,不要使用foreach。尽可能用for来代替foreach。会产生GC Alloc,说明foreach调用GetEnumerator()时候有堆内存上的操作,newdispose

       2.string修改。

       如果熟悉C 的话,就会了解,每次使用string的时候,都要在内存中创建一个新的字符串对象,就需要为该新对象分配新的空间。 特别是在循环中需要修改string对象,就会频繁的分配新的空间,这时候推荐使用StringBuilder.Append等操作来处理。C 中通常也是通过分配一个固定的字符内存来处理字符串的操作。

       3.gameObject.tag

       gameObject.tag 会在内部循环调用对象分配的标签属性以及拷贝额外的内存,推荐使用gameObject.CompareTag("XXX")来代替.tag

       4.使用ObjectPool对象池来管理对象,避免频繁的InstanceDestroy

.贴图层面。

       代码上的内存优化,很大层面上都不及贴图上的优化。有时候改一张图就帮你省了大几兆的内存。

       1.巧妙通过调整纹理资源,来调整图的大小。比如:通过9宫格、部分缩小后Unity里在拉大等方式。

       比如:(主要调整了两个小元素)就省了一半的内存。

    

                     优化前                                   优化后

2.Ios平台使用PVRT压缩纹理。Adroid平台使用ETC1格式压缩。均可以减至1/4的内存大小。优化非常明显。

       目前主流的Android机型基本都支持ETC1格式压缩。但ETC1只能支持非Alpha通道的图片压缩。所以一般把Alpha通道图分离出来,绘制到GPU显存时,a值从Alpha图里获取,无Alpha通道的图就可以使用ETC1压缩。

       ETC2以上的格式压缩虽然支持含Alpha通道的图片,但是支持的机型还比较少。目前不推荐使用。

              未使用ETC1压缩前的内存占用大小1024*1024png图占用10.7M(包含了Editor中的内存占用,以及mip map内存占用

              mipMap是摄像机离得远近用不同的图片,3D游戏中用内存换性能的一种有效方式。它会将大图变成若干小图,存储内存中,当摄像机离的比较远的时候,只需使用小图。

UI、2D场景可以把Texure这个设置去掉。

这样实际游戏中未压缩纹理1024×1024的图在内存中占用是 4M。(Unity Profiler下看应该是8M) 

使用ETC1压缩后,场景图片一张大小只有1.3MB,加上通道图2.6M。几乎是用来的1/4

甚至文件的大小也小了1/4


3.通过减色的方式减少图片大小。很多UI其实使用的色彩很少,用不到256色。这类图片就可以进行减色压缩。


.框架设计层面

       一个相对中大型的游戏,系统非常的多。这时候合理的适时的释放内存有助于游戏的正常体验,甚至可以防止内存快速到达峰值,导致设备Crash


       目前主流平台机型可用内存:

       Android平台:在客户端最低配置以上,均需满足以下内存消耗指标(PSS):

       1)内存1G以下机型:最高PSS<=150MB

       2)内存2G的机型:最高PSS<=200MB

       iOS平台:在iPhone4S下运行,消耗内存(real mem)不大于150MB

1.场景切换时避开峰值。

       当前一个场景还未释放的时候,切换到新的场景。这时候由于两个内存叠加很容易达到内存峰值。解决方案是,在屏幕中间遮盖一个Loading场景。在旧的释放完,并且新的初始化结束后,隐藏Loading场景,使之有效的避开内存大量叠加超过峰值。

2.GUI模块加入生命周期管理。


       主角、强化、技能、商城、进化、背包、任务等等。通常一个游戏都少不了这些系统。但要是全部都打开,或者这个时候再点世界地图,外加一些逻辑数据内存的占用等等。你会发现,内存也很快就达到峰值。

       这时候有效的管理系统模块生命周期就非常有必要。首先将模块进行划分:


1)经常打开 Cache_10

2)偶尔打开 Cache_5

3)只打开一次 Cache_0


       创建一个ModuleMananger 类,内部Render方法每分钟轮询一次。如果是“Cache_0”这个类型,一关闭就直接Destroy释放内存;“Cache_10”这个类型为10分钟后自动释放内存;" Cache_5"这种类型为5分钟后自动释放内存。每次打开模块,该模块就会重新计时。这样就可以有效合理的分配内存。

 暂时就先写到这。Thank : )


如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引