项做每好unity4.x开发规划的要素.doc

做好Unity4.x开发规划的要素 　　每次做完一个项目，很多人必然有很多感慨和愤恨，希望在下个项目一定要避免，要做的更好的。但总的来说，unity没有特别的坑。只要肯研究，后期都能改进，也都不会影响到上线。 　　unity上手容易，但也有很多麻烦，基本事件机制，生存周期，场景和资源管理，mono虚拟机的gc机制都是麻烦点。 　　要说的话，真正影响到架构的是排序。 　　一、 是否要用lua 　　二、(对于需操作的游戏)客户端游戏如何做战斗验证 　　1. 客户端程序层面 　　总的来说C#是比较不错的 　　1) mono虚拟机gc 　　Unity的mono虚拟机使用不分代的gc算法，临时对象积攒起来，导致重量级GC游戏频繁卡顿。 　　Unity官方：认真review每帧20B以上，以及一次2K以上的GC Alloc的行为。传闻：Unity5会改进。 　　可以阅读：Gamasutra: Wendelin Reichs 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都有麻烦。 　　* 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、NG