unity unity项目开发过程经验摘要（转）

网络层：短链接+长连接

两者的数据同步可以考虑通过数据库层来处理，短连接处理业务逻辑，长连接处理数据同步以及一些后台逻辑。当然只使用短连接的情况下，可以制定一种动态数据的携带机制，满足随时在任何协议中携带常用的各类数据，保证数据的一致，再者建议前端尽可能少的修改自己来源于服务器的缓存数据，宁愿多定义一些中间变量，多做一些逻辑。

服务器和客户端统一数据结构：

通过策划定义的excel表，一键导出java c# proto文件，通过在excel表中添加标注来确定哪些参数是公用数据(传输)，哪些是客户端专用哪些是服务器专用

另外：客户端一定要尽量少的做比较重要逻辑的条件判断，尽量少的使用公式计算，如果可能的话，直接由策划提供对应公式计算后的数值，或者数据尽可能的由后端传过来。 再者不同协议尽可能使用公用的结构体，这样可以减少对缓存数据操作的地方，也就可以减少出错的地方。

还有一点，要多做异常错误码的处理，可以在这里进行一些前端与后端数据的同步工作。

尽量使用静态表的方式来获取各类数据，因为策划会在线上服进行一定程度的数值调整，千万不要写死在程序里面，当前我们进击的魔王走的是静态表，同时支持静态表的动态更新，这样可以满足策划对数据表的随时修改，可以将静态表都拆分成个体单独处理，每个表都有自己的版本号，减少下载量。由一个总的信息记录文件来控制(这个文件每次必须从服务器获取最新)，记录当前版本，下载地址等等，当然如果整体大小很小的话，那么也可以合并成一个文件，减少更新请求次数。

资源处理：打包成bundle是必须的，考虑是否将界面资源也打包，或者生成为场景资源，打包公用资源，打包单体界面资源，按照顺序下载资源，处理资源 (这一条根据需求，如果逻辑合理的话可以减少资源量，不过会加重逻辑工作量)，同时如果使用Bundle的话一定得保证文件名的唯一性，因为WWW是使用文件名来进行区分下载的。合理拆分AssetBundle。 资源分类：场景、角色、界面、静态表、动画、特效、其他

//文件名, 版本号(修改时间), 文件尺寸 md5(crc32) 下载地址(BaseURL+Platform+Resource)

使用WWW.LoadFromCacheOrDownload的方法，下载完的数据将在unity3d的本地缓存目录中进行保存。Web浏览器通常允许缓存大小达到50MB，PC和MAC的本地应用，IOS和Android应用都允许缓存达到4GB大小

在Unity4.3.3中可以使用CRC32进行文件正确性校验，CRC32为32bit的简单hash，MD5为128bit较复杂的hash算法，根据网上的资料，虽然CRC32在某些情况不是一定比MD5快，但是有Unity3D内置的接口，同时如果我们使用MD5会增加自己的工作量，那么还是建议使用CRC的校验方式。

另外现在可以不用再考虑使用WWW.Dispose来清空进程，释放资源了，一是这东西不保险，可能会造成崩溃(在下载完成之后调用没问题，在下载中频繁调用可能会出现异常)，二是Unity自己会在合适的时机清空加载进程。

保持良好的编码：

项目开发中一定要保证委托使用的一致性(Observer pattern)，一定不要某些模块使用，另外的模块又不使用，造成代码比较散乱。 其次坚持统一的本地化语言开发机制，对于界面布局的问题在代码中尽量不要使用写死的数值来调整位置，不要因为前期偷懒造成后期修改成本的增加，毕竟在前期开发中对个人负责的功能更加清晰。

优化托管的堆内存：尽可能早的时间将不需要的引用去除掉，置为null，这样回收机制才能正确地及时的把不需要的内存清理出来(理论上)

优化Unity内存：避免程序内存峰值，在加载两个大场景时，中间最好穿插一个很小的场景，这样在场景切换过程中不再使用的资源将会被适当释放一部分，二是要注意脚本中对一些资源Prefab、GameObject等引用，如果一些不会被删除的脚本包含了对大量资源的引用，那么这部分资源将不会被释放。

统一计时功能，根据需求分发到使用者，C#的话最好使用Ticks来计时，比较精确一点，不管使用Ticks或者second，一定要保证各处使用单位一致，同时保证使用Unity的Time. realtimeSinceStartup来记录程序中与真实时间挂钩的变量，而不是使用Time.deltaTime

协议码的处理：建议使用C#的反射机制来处理，抛弃switch的编写，利用C#的partial功能将文件按模块或者功能分离代码文件。

3D美术效果：比较合理的美术规范，适用于自身项目，适用于移动端的shader

界面布局：坚持九宫格的布局，界面统一动画的处理，在九宫格的几个节点挂上相应的动画脚本，在Enable和Disable的时候执行正反动画，觉得我们项目对动画部分的设计还是很不错的，效果也比较统一，使用起来也比较简单。

界面贴图的制作：NGUI的图集合并规则，按照美术风格，规定美术的图素数量，将可能的图素合并到1-2张通用大贴图上，其次按照不同的模块进行单独生成图集，这样可以方便做bundle，进行资源下载等其他功能.

自定义一些针对性的界面操作工具，图集修改，深度统计、修改

效率：尽量减少Instantiate的使用，在合理的情况下使用Cache机制，但同时要控制内存的使用

ScrollList或者ScrollView一定要实现循环利用，使用尽可能少的模板进行数据循环显示

做好界面管理功能，我们项目中没有统一的界面管理，很容易造成界面该删除的时候没有删除，再加上比较深层的委托使用，和单一事件分发，使得有的模块的逻辑看起来很复杂，很难快速定位逻辑问题。

任务系统

新手引导：建议以端游的制作方式去处理，在开发过程中注意处理好事件屏蔽的逻辑，可以通过遮挡、tag标签、collider等来进行事件屏蔽，总之一定要满足不能因为引导出现异常造成用户无法继续游戏。

Shader：因为项目中使用的shader类型也不多，但是在三星的I9260上发现角色的效果不正确，经过查看发现是shader脚本中有变量没有初始化造成，v2f o = (v2f)0; I9260使用的CPU是OMAP4470搭载了PowerVR SGX544@384MHz，有可能是驱动程序或者Unity自身优化造成，但是在iPhone4S上并没有发现这个问题，所以驱动程序的可能性比较大。结论，尽量都给变量加上初始化。

Unity自身的Shader Code不支持discard语法，我们是使用AlphaTest + Blend替换的，但是在open gles2.0上又是不支持AlphaTest的，而是通过shader的discard来实现，那么应该是Unity进行了转换，有些shader语法需要注意一下。

其他：注意与服务器时钟同步、注意监测网络，注意游戏切入后台再切回来的流逝时间处理，前后端的数据同步尽量使用直接赋值的方式，避免加减这种操作，减少逻辑出错几率。

自动打包：资源自动打包，安装包自动打包，减少人为操作，降低出错几率。

工程设置：必须采用.Net2.0 Subset，尽量剥离系统库，采用micro mscorlib，在这种模式下System.Xml System.Security.Cryptography等一些库无法使用，采取较小的第三方替代

上线：开服前一定要做一遍checkList，梳理changelog以及需要那些资源，各功能的简单测试结果单。

崩溃统计：

1. 友盟：http://www.umeng.com/analytics_errortype？ 2. Crittercism：https://www.crittercism.com/？ 3.

Crashlytics:http://blog.sina.com.cn/s/blog_8c87ba3b0101m1lf.html