Unity技术-开发规范

👉关于作者

众所周知，人生是一个漫长的流程，不断克服困难，不断反思前进的过程。在这个过程中会产生很多对于人生的质疑和思考，于是我决定将自己的思考，经验和故事全部分享出来，以此寻找共鸣！！！

专注于Android/Unity和各种游戏开发技巧，以及各种资源分享（网站、工具、素材、源码、游戏等）

👉前提

为什么要规范/规范的目的

Unity开发通常需要和三维，美术，设计等并行开发，沟通交流频繁，而且中大项目还可能多人开发，所以一个好的项目规范，能提升开发效率。优点多多：

• 1.方便代码的交流和分片维护，使代码清晰人人都读得懂，可维护强；
• 2.前期开发团队管理效率高，分工明确，有效避免写了后面搞不明白前面，防止了恶性加班；
• 3.后期更新/维护速度快，逻辑明确，项目清晰；
• 4.规范的代码虽然不一定带来高性能，但一定是优雅的，赏心悦目的，不枯燥提升心情愉悦性；
  良好的规范很重要，任谁也不想在“脏乱”的环境工作

👉实践过程

😜文件目录规范

一级目录：

【01_Scenes】：存放所有场景，方便快速找到对应场景，如果场景有先后顺序命名可以挂上编号

【02_UI】：存放2D方面的资源，比如图片精灵等，如果过多可以分二级文件夹，其命名规则和用到的地方相对应

【03_Model】：存放3D资源，模型材质等所有相关内容

【04_NetAndData】：存放网络通信和本地数据库等相关内容，比如：服务器访问，本地存储等

【05_Utils】：存放平时用到的封装工具类，比如：Screen屏幕类，Time类，Math类，文件操作类，时间类，字符串类等等

【06_Scripts】：存放脚本，偏向于存放二处及以上使用次数的脚本，像那些单独使用的脚本且跟控件/模型有关联的，把她们放到一起即可

【07_Audio】：存放声音文件

【08_Others】：存放其他文件，暂时不清楚放在哪个分类下的文件，可以以后再分类

【09_Test】：测试文件夹，平时测试功能，下个测试脚本啥的，都放到这，产品发布之前可以直接删除

【Plugins】：系统默认文件会自动识别，为插件目录，存放扩展Unity编辑器的代码工具，编译的时候不会打包进去

【Prefab】：系统默认文件会自动识别，存放经常反复利用的对象或资源，充分复用

【Resources】：系统默认文件会自动识别，默认的资源路径，发布的时候会自动打包进去，在代码中可以直接访问

有更合适的可以再增加

二级目录：

可以根据自己项目需要增加对应的文件夹，比如存放3D资源的【03_Model】文件夹和存放2D资源的【02_UI】文件夹

3D你可以按照模型分类，也可以按照资源分类

【Animators】：动画控制器 相关的资源文件。

【Materials】：材质 相关的资源文件。

【Shaders】：着色器 相关的资源文件。

【Scripts】：脚本 相关的资源文件。

【Textures】：纹理 相关的资源文件。

或者

【ModelOne】：存整个模型的所有东西，材质/模型/纹理等

【ModelTwo】：同上，存另一个模型的全部

如上，资源明确，调理清晰， 一看就知道项目层级，至于更深的三四级目录，看项目需要，灵活设置。

😜文件名规范

• 1.大驼峰命名法，每个单词首字母大写，并且能够表现出改文件的功能意义。比如有个手模型，可以起名字为：ModelHand
• 2.同级下且名称相同的文件，命名用下划线”_”加编号来区分，比如：Scene_01，Scene_02，Scene_03，Scene_04
• 3.同属于一个整体的各个资源名称尽量要一致，比如手模型包含了贴图和对应的脚本，起名：ModelHand，ScriptHand，TexturesHand或者HandModel，HandScript，HandTextures
• 4.命名尽量使用英文，如果多人协同合作英文有障碍的话，使用拼音，但一定要全拼且符合大驼峰命名。比如手电模型：起名ShouDian，可别来SD，让人误会成SD卡或者傻蛋，非常不推荐缩写。

😜资源规范

• 1.命名遵循上面的上面文件命名规范
• 2.图片资源统一尽量使用png格式
• 3.图片不要过于追求效果，在不影响视觉的前提下能小就小一些
• 4.可以提前使用TinyPng软件来进行图片压缩，我在Android中也强烈推荐过，超级神器，效果显著
• 5.多人协作坐标模式提前商定好，统一的坐标系能帮助更好的观看模型效果，否则会导致场景乱套
• 6.移动设备面数控制300-1500，PC端建议范围是1500-4000，整个屏幕建议控制在7500面以下
• 7.贴图尺寸为2的N次方，最大不超过1024*1024，特殊情况再进行特殊处理

😜代码规范

• 1.驼峰命名法，且命名要表达出符合她的意思，要么英文要么频音，强烈反对缩写
• 2.注释尽可能写详细，便于维护和后期查阅
• 3.禁止在频繁更新的函数(Update/OnGui)中使用协程，声明变量，等创建类操作，对性能造成影响
• 4.对可能造成功能失效，影响业务流程的代码添加异常捕获，便于调试
• 5.尽可能将计算量大的耗时任务放到子线程进行，避免堵塞
• 6.其他规范待补充

👉其他

📢作者：小空和小芝中的小空
📢转载说明：务必注明来源：https://zhima.blog.csdn.net/ https://juejin.cn/user/426576084
📢欢迎点赞👍收藏🌟留言📝