Unity项目开发过程经验摘要.docxVIP

网络层：短链接+长连接两者的数据同步可以考虑通过数据库层来处理，短连接处理业务逻辑，长连接处理数据同步以及一些后台逻辑。当然只使用短连接的情况下，可以制定一种动态数据的携带机制，满足随时在任何协议中携带常用的各类数据，保证数据的一致，再者建议前端尽可能少的修改自己来源于服务器的缓存数据，宁愿多定义一些中间变量，多做一些逻辑。服务器和客户端统一数据结构：通过策划定义的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的校验方式。另外现在可以不用再考虑使用http://WWW.DisposeWWW.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的时候执行正反动画，觉得我们项目对动画部分的设