Unity3D LUA开发代码规范

一:命名规范:

1、类命名:驼峰式命名:单词首字母大写,如:GetInstance

2、函数命名:同类名

3、公有变量命名:同类名

4、私有变量命名:小写,单词之间用“_”分隔,如:self.action_list

5、局部变量命名:同私有变量

6、参数名命名:同私有变量

7、任何情况下不应该由外部访问的成员,使用双下划线打头,其它同私有变量命名,如:析构函数__init,内部成员self.__callback

8、由于脚本语言没有跳转功能,最好在UI组件实例的名字末尾标识组件类型,提高可读性:

a)基础组件(UIBaseComponent):xxx_cmp

b)按钮(UIButton):xxx_btn

c)文本(UIText):xxx_txet

d)图片(UIImage):xxx_img

e)输入框(UIInput):xxx_input

f)标签组(UITabGroup):xxx_tabgroup

g)按钮组(UIButtonGroup):xxx_btngroup

h)可选中按钮(UIToggelButton):xxx_togglebtn

i)可复用组件(UIWrapGroup):xxx_wrapgroup

j)滑动条组件(UISlider):xxx_slider

k)后续...

9、所有UI脚本以UI打头,即UIxxxx

10、系统功能扩展函数:全部使用小写,不用下划线,如对table的扩展:table.walksort

11、所有协程函数体以"Co"打头,如:CoAsyncLoad,表示该函数必须运行在协程中,并且可以使用任意协程相关函数

12、所有Unity Object均使用全局函数IsNull判空===>***很重要

13、所有热修复脚本放XLua目录下 

二:类定义和使用

1、所有函数定义为local,在脚本最底部导出,导出的函数一定是公有的

2、所有公有函数第一个参数是self,函数使用调用:instance:function(...)

3、所有私有函数第一个参数是self,不导出,只能在脚本内访问,函数调用:function(self, ...)

4、所有私有函数一定要先定义,后调用

5、override的使用有点特殊:先用base = baseClassType,然后override时使用:base.function(self)调用父类方法

6、继承类时,如果不是等同于cs侧sealed的概念,那么必须把基类的参数列表填写完整,后面接上自己需要的参数

7、函数需要重载时,一般通过判断参数个数和类型来实现,此时必须把最长参数列表填齐,除了回调绑定等不定参数的特俗情况,一般情况下不要使用可变参数(...)

9、所有定义回调的地方,都需要预先声明回调和注释说明回调原型,让使用者一目了然

10、__init不需要调用base.__init,底层会自动调用基类构造函数,__delete也一样

 

三:单例类定义和使用

1、单例类从Singleton继承,不要重写GetInstance、Delete方法

2、单例类定义时内部函数书写规范同上:类定义和使用

3、单例类调用一律使用singletonClass:GetInstance():function/.var访问

4、除了局部变量,不要使用成员变量或者全局变量缓存单例类引用,如:inst = singletonClass:GetInstance(),inst:function/.var,因为单例类销毁后inst还会存在引用

5、单例类的Instace只用来查询该单例类是否已经被创建,如:if singletonClass.Instance ~= nil then singletonClass:Delete() end

 

四:数据类定义和使用

1、数据类:对普通类增加访问限制,具体为:不能对不存在的域进行读写。目的:减少因为笔误而造成的不可察Bug

2、定义格式使用:DataClass("dataClassName", dataTable)

3、dataTable是一张普通表,定义了该数据成员的域,必须初始化,不能有nil值

4、定义以后不能新增数据域,访问不存在的域会提示错误,New新的数据实例同New新的类实例

 

五:常量类定义和使用

1、常量类:对普通类增加访问限制,具体为:不能对不存在的域进行读写,数据域只读,不可写。目的:减少因为笔误而造成的不可察Bug

2、定义格式使用:ConstClass("constClassName", constTable),一般用于配置表等数据,一旦生成只能查表,不能写表

3、定义以后查询不存在的域、写不存在的域、写存在的域都会有错误提示

 

六:UI窗口代码规范

1、严格遵守MVC架构:Model层数据、View层窗口组件操作、Ctrl层数据操作

2、View层直接依赖Ctrl层,间接依赖Model层(只读);Ctrl层依赖Model层;Model层不依赖Ctrl和View层

3、Ctrl层没有状态,可以操作游戏逻辑和Model层数据;View层除了读取配置表,不能直接操作任何游戏逻辑

4、逻辑的运行不能依赖窗口的Ctrl层,如果需要这样的控制代码,写到游戏逻辑模块中

5、窗口Model层不存游戏数据,它的生命周期是和窗口绑定在一起的,只能缓存用户操作,比如:当前选择了那个服务器做登陆服务器

6、窗口Model层是针对窗口的数据,是游戏数据中心的一个抽取,比如数据中心UserData可能包括用户名、背包、Vip、英雄等等数据,但是用于界面可能只是从用户名、Vip提取部分数据展示

 

七:UI组件代码规范

1、所有需要调度和管理的UI组件最好使用Lua侧封装的各种UIComponent,不要直接使用Unity侧的UI原生组件,否则不受Lua侧组件系统调度管理,需自行管理

2、原则上尽量对UI组件执行封装:一是可以简化逻辑层脚本使用方式,二是可以利用缓存尽量减少lua与cs交换,提升性能

3、原则上游戏逻辑代码中(包括窗口View层代码)不对UI组件做任何假设,即不假设Unity侧使用的是NGUI还是UGUI

4、虽然目前这套框架是针对UGUI编写,但是如果要扩展(或者要替换插件),只需要另外针对NGUI写一个Lua侧的各种UIComponent

5、所有UI组件最好先封装,后使用,以尽量使用Lua侧组件管理系统来简化写View层脚本的工作量,各个使用到的组件现在还不是很完善,后续...

6、一个窗口(window.view)下的所有组件持有对窗口view脚本的引用,方便访问window.view,或者window.model层数据

7、当设计通用组件时,不能直接依赖window.view,需要数据刷新最好提供函数回调

8、UI组件代码所有函数的执行规律同Unity脚本,UI组件代码不要使用__init、__delete函数,由OnCreate、OnDestory代替

9、最好不要自己去New组件,使用AddComponent替代,否则必须自己管理生命周期---在OnDestory中调用组件的Delete方法

 

八:工具类代码规范

1、所有和UI界面相关的公共函数添加到UIUtil

2、所有和Lua语言直接相关的公共函数添加到LuaUtil

3、所有对table操作的扩展函数添加到TableUtil

4、其它待续...

 

九:框架代码规范

1、原则:保证框架代码的可迁移,如果需要迁移到新项目,可以不修改任何代码,或者修改很少的粘合代码即可使用

2、如果需要完善框架,框架内的代码理论山不要牵涉任何游戏逻辑,一般只提供管理类和基类,和业务相关的子类不要放在框架中

 

十:性能

1、性能瓶颈出现在两点:lua作为脚本语言本身的速度问题、lua与cs的频繁交互造成高频率堆栈操作和Marshall操作

2、原则1:单次调用,内部执行性能要求高的函数,比如寻路计算,考虑放CS侧,或者用C/CPP写---要求:函数执行时间要高于lua与cs调用交互时间,否则得不偿失

3、原则2:尽量避免与cs的交互,交互越少越好,如tolua作者对Vector3在lua侧的实现,就是为了避免Vector3操作调用cs接口,其它实现的数据结构类似

4、不要使用cs侧协程,lua这边我已经实现了一套,Unity支持的所有协程功能这里都支持,而且进行了很大的性能优化

5、更新频率低的函数(如UI界面倒计时)使用定时器,尽量不要用Updater

6、虽然Lua采用分步GC,不需要太关注GC造成游戏Lag的问题,但是分配、回收频率很高的table,还是要做缓存,参考定时器管理模块

你可能感兴趣的:(unity3d)