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

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

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

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

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

 

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

比如：通过9宫格、部分缩小后Unity里在拉大等方式。

比如：（主要调整了两个小元素）就省了一半的内存。

    

优化前

 

 

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

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

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

 

       未使用ETC1压缩前的内存占用大小1024*1024的png图占用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。

很多UI其实使用的色彩很少，用不到256色。这类图片就可以进行减色压缩。

 

 

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

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

Android平台：在客户端最低配置以上，均需满足以下内存消耗指标（PSS）：

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

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

iOS平台：在iPhone4S下运行，消耗内存（real mem）不大于150MB

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

 

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

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

1)经常打开 Cache_10；

2)偶尔打开 Cache_5；

3)只打开一次 Cache_0。

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