做好Unity4.x开发项目规划

1. 是否要用lua

　　2. （对于需操作的游戏）客户端游戏如何做战斗验证

　　下面列举小坑吧。不建议都绕开，毕竟没有那么多时间做前期调研的。

　　对应版本Unity4.x

　　1. 客户端程序层面

　　总的来说C#超级给力的，不过别玩脱了

　　1) mono虚拟机gc

　　Unity的mono虚拟机使用不分代的gc算法，临时对象积攒起来，导致重量级GC游戏频繁卡顿。

　　Unity官方：认真review每帧20B以上，以及一次2K以上的GC Alloc的行为。传闻：Unity5会改进。

　　推荐阅读：Gamasutra: Wendelin Reich's Blog

　　评价：请像C++一样精确了解各种行为的gc，foreach 都不要随便用。严重，但游戏是可以卡巴卡巴上线的。后期一位核心开发人员修2~3周。

　　2) 苹果aot编译问题：模板问题

　　mono在苹果上采用aot将C#编译为静态代码。首先，依赖于动态代码生成的复杂模板容易运行时崩溃；其次，mono会将客户端生成一个库。模板代码实例化容易膨胀导致该库超过40M而无法链接。

　　实战：碰到了改写法吧。不过我本人是静态类型检查派的。

　　3) 少用coroutine

　　yield只支持try--finally，与异常体系兼容性极差；难以提供返回值；异步本身是非线性的，很难保证逻辑完备。

　　实战：复杂异步逻辑用状态机。不致命，多修bug也能抗过。

　　4) 自行处理配置数据序列化

　　严重影响配置读取速度。C#自带的xml序列化很慢，自带的二进制序列化也不够快。

　　实战：打包配置考虑protobuf或者代码生成器。中后期一周左右。

　　5) 反射

　　手机上jit情况下，第一次反射一个类很慢。乱用足够影响启动速度。

　　6) 本地化

　　如果公司习惯于做海外市场，一开始就可以考虑全套本地化方案。后期改需要一个人1~2个月工作量。

　　2、资源优化

　　Unity资源优化，一个靠谱的TA很重要。

　　1) 资源内存占用

　　512内存机器能用的资源大概只有50~60M。

　　需透彻研究贴图。考虑换皮怪资源复用、UI的图集合理化。

　　没有UI优化经验的话，强烈建议一个核心开发死跟，像抠代码优化一样优化图集总结经验。这个后期很难收场。

　　每个粒子发射器占用10K内存；有些项目在动画上会有内存问题。

　　2) 关注资源包大小

　　最大的是贴图和骨骼动画。贴图关注内存即可。骨骼动画可以占到模型的一半大小，重做的话有各种优化方案。但超标后期也很难收场。

　　3) 依赖打包

　　Unity4.x和Unity5完全不同。其中Unity4.x机制庞大繁杂容易错，要有心理准备。扯一些要点：

　　* 一定要搞清其内存占用和生存周期。要实测，特别容易跌眼镜。

　　* 每个API都有坑。我个人目前推荐压缩模式、LoadFromCache，此时不能拆太碎。战斗前预加载。

　　* shader加载慢，应当放入依赖包

　　* bundle不能重名

　　4) 场景、drawcall、camera

　　场景面多了考虑动态batching

　　不同材质透明物体（例如粒子）穿插可能引起drawcall暴增。

　　camera是重型对象，越少越好

　　5) svn

　　资源选Text模式、显式保存.meta，便于版本管理。资源分人或者锁了改，规避冲突。

　　3、Unity

　　和Flash一样容易学的3D编辑器

　　1) 事件机制

　　Unity事件机制很不好用。单个对象，Awake，Start，Enable调用时机相当复杂。Unity完全不保证多个对象的事件执行顺序，导致很多人绕开Start。不恰当的使用事件，很容易导致父子对象不在同一帧出现，画面不干净。

　　Destroy操作是延迟的，对象会活到帧的结尾，然后必定销毁。库级设计时，必须考虑到这一点(例如对象池/动画库)。

　　2) 资源管理

　　只说Unity4.x。合理做法是依赖很卡的UnloadUnusedAssets、LoadScene清理无引用资源（另注意前者是异步的），或者Bundle.Unload(true)，这些方案各有限制。试图更细粒度手工清理的困难在于，并不存在系统性文档解释Unity资源的分类和生存周期，且Destroy操作很保守。例如，销毁mesh时，并不会销毁material、texture，更不会清理脚本资源。

　　此外，特定的普通操作会造成资源克隆。例如访问Renderer.meterial，Animation.AddClip。

　　4、NGUI

　　久经验证的掉链子王。新项目也可以尝尝uGUI

　　1) panel重绘

　　widget改变后，所在panel需要生成多边形，很慢，坑新人没商量，注意合理分panel。panel中多边形过多会爆（貌似是65535个顶点？）。

　　uGUI原理相同，就是c代码比C#快不少。

　　2) panel渲染顺序

　　搞清楚ui上放置3D物体咋办，ui如何和特效混合排序。

　　3) 策划/美术ui规范

　　潜规则很多。Anchor、动画不可作用于同一个物体。widget必须是panel的子节点，不然他就会自己造panel，经常搞出乱子。再加上上面的panel规则等，要策划美术折腾ui可费神了。

　　项目组自制UI编辑器自然是极好的，不过不一定必要。

　　4) 创建速度慢

　　由于序列化字段多，NGUI对象创建可导致卡顿。多状态对象不要靠隐藏-显示，而要动态创建。尤其是状态中包含粒子发生器/Animation，这俩还有内存问题（10K一个）。

　　5) 与Unity事件机制强耦合

　　与Unity的事件机制强耦合，不完备，容易有bug。例如，panel绘制依赖于LateUpdate。coroutine中同时关闭旧界面，创建新界面，此时当前帧 LateUpdate 已过，表现为有一帧画面为空白。