内存优化：
1、如果是开发2D游戏，尽可能的把图集做得不超过1024，最好是512，如果不断的把图集做成2048的话，会一直把内存撑爆，因为凡是加载其中一个图片，便会把整个2048的图集都加载进去了，除非这个是公共的图集，在哪个场景都会频繁用到，否则不应该把图集弄太太大。
2、尽量不要一下子把所有的场景元素加载到场景中，凡是分开出现的应该从Resource.Load来进行加载，然后在不用的时候通过unLoad来进行清除资源。也就是说像太多对话框之类的不要一开始隐藏在场景中，而是要把它在固定的时候去加载它。
减少运算压力而不减少内存大小：
关于gameObject上挂载的脚本的激活状态区别，无论是激活状态还是未激活的状态，此gameObject上始终会消耗内存来保有当前的状态，但非激活状态可以减少运算压力，使得u3d再也不会对此物件再发送Update, Start等u3d的特有事件，但是，如果此类有静态方法的存在，依旧还是能够正常执行。
减少运算压力：
1、把尽可能多的静态物体勾上静态的属性，从而减少CPU运算压力，
2、减少固定更新的时候，FixUpdate，还有一些不需要那么实时计算的检查可以用个条件判断，满i > 5 才检查一次，这也是比较简单的降低消耗的措施。
3、以非压缩格式代替压缩格式，图片上，png一般来说都是比jpg好的在ios平台，但是png相对比较大一点，所以jpg可以做成背景图，动态图片最好用png，声音也是wav这种非压缩格式处理起来比mp3处理起来是快些，但是wav会增加容量，事实上迩总会在容量和性能之间找个平衡点。
4、减少Draw Call，这基本上是个迩随便google一下就能发现的性能问题，但事实上华丽复杂的画面往往是要求更多的draw call的，迩可以用个预先做好的效果图直接扔上去渲染，但这样又缺乏了灵活性，造成了容量的增加，总之性能，效果，容量总是在互相制约着，迩还是得需要按实际情况决定到底是优先处理哪个好，但在苛刻的情况下，容量和效果不能增加的情况下提升代码质量来提升性能也是可以的，不过提升代码质量要更高的技术和时间，这又是另外一个实时的问题了，效率！所以倒回头，又是个领导的策略性问题了，到底是慢工做细活还是要抢先市场，这又是实际情况所决定了，解决办法是有N种的，到头来，还是得看迩自己来把握。
5、SendMessage是狠方便，但动态意味着更多的负担，而且由于发送消息无视类，所以可能会产生发多了去其它类的情况造成难以察觉的BUG，但其实发送消息又是个非常方便的工具，所以看迩怎么来取舍了。
如果把一个MonoBehavir的类的某些方法定义成了一个静态类，记得静态方法不要引用gameObject和transform等属性，因为这些属性仅仅存在于当前的场景中，假若上一个场景已经运用了这些类，那么到下一个场景后，这些变量便会随着gameObject的摧毁而消失。
剩下的基本上是老生常谈了，减少过多材质的运用，shader的运用，过多了模型顶点，动态灯光的运用，改成烘焙的。其实这里性能的优化多数下是与游戏容量成正比的，也就是说光迩的游戏容量可以越大的时候，性能就要求越低，这就是说预计算代替了即时演算，当然现实是游戏容量最好狠少，配置最好越低，开发难点总是与需求相背离的。
结语：性能优化不建议开始就弄，特别对于手游业的高动态性，需求经常变，可能迩这个功能下个月就不需要了，所以不要浪费时间去做些无意义的事情，所以我们总要记得一件事，游戏是要来盈利的，我们应该要让玩家能容忍的情况下用最省时省力的方式做出真正盈利性的游戏，这才是性能优化的主旨。
这里有更多关于u3d内存管理的文章：http://www.unity manual.com/thread-906-1-1.html
U3D官网关于性能优化的说明：http://docs.unity3d.com/Documentation/Manual/OptimizingGraphicsPerformance.html
U3D WIKI关于性能优化的说明：http://wiki.unity3d.com/index.php?title=General_Performance_Tips