这里从三个纬度来分享下内存的优化经验：代码层面、贴图层面、框架设计层面。
一.代码层面。
1.foreach。
Mono下的foreach使用需谨慎。频繁调用容易触及堆上限，导致GC过早触发，出现卡顿现象。
特别注意的是在Update中如果非必要，不要使用foreach。尽可能用for来代替foreach。会产生GC Alloc，说明foreach调用GetEnumerator()时候有堆内存上的操作，new和dispose。
2.string修改。
如果熟悉C++的话，就会了解，每次使用string的时候，都要在内存中创建一个新的字符串对象，就需要为该新对象分配新的空间。 特别是在循环中需要修改string对象，就会频繁的分配新的空间，这时候推荐使用StringBuilder.Append等操作来处理。C++中通常也是通过分配一个固定的字符内存来处理字符串的操作。
3.gameObject.tag
gameObject.tag 会在内部循环调用对象分配的标签属性以及拷贝额外的内存，推荐使用gameObject.CompareTag("XXX")来代替.tag。
4.使用ObjectPool对象池来管理对象，避免频繁的Instance，Destroy。
二.贴图层面。
代码上的内存优化，很大层面上都不及贴图上的优化。有时候改一张图就帮你省了大几兆的内存。
1.巧妙通过调整纹理资源，来调整图的大小。比如：通过9宫格、部分缩小后Unity里在拉大等方式。
比如：（主要调整了两个小元素）就省了一半的内存。
优化前
优化后
2.Ios平台使用PVRT压缩纹理。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。
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分钟后自动释放内存。每次打开模块，该模块就会重新计时。这样就可以有效合理的分配内存。