目录
一、编译报错 Type `UnityEngine.Light' does not contain a definition for `shadowRadius' and no extension method `shadowRadius' of type `UnityEngine.Light' could be found. Are you missing an assembly reference?
编译时候提示错误:
Assets/XLua/Gen/UnityEngineLightWrap.cs(723,60): error CS1061: Type `UnityEngine.Light' does not contain a definition for `shadowRadius' and no extension method `shadowRadius' of type `UnityEngine.Light' could be found. Are you missing an assembly reference?
解决方案:在Assets\XLua\Src\Editor\Generator.cs 中GetGenConfig函数中添加黑名单
public static void GetGenConfig(IEnumerable<Type> check_type)
{
...
BlackList = new List<List<string>>()
{
new List<string>(){"UnityEngine.Light", "shadowRadius"},
new List<string>(){"UnityEngine.Light", "shadowAngle"},
};
...
}
执行菜单xlua ->Clear Generator code ,再执行xlua ->Generator code
二、xLua 的一些注意事项
1、将Xlua Assets中的内容copy到目标项目的Assets内
2、将XLua内的Tools复制到项目Assets外
3、打开项目,在项目的Build Settings——Other Settings——Scripting Define Symbols填入:HOTFIX_ENABLE
4、将本地Unity目录下的\Editor\Data\Managed下的Unity.Cecil.dll、Unity.Cecil.Mdb.dll、Unity.Cecil.Pdb.dll三个文件复制到项目中的\Assets\XLua\Src\Editor文件夹下
注意:不可将XLua放在中文目录下
5、逐步运行Unity中的XLua—Generate Code、Hotfix Inject In Editor(若第一次未出现,再重复运行一次),若Console出现如下提示,则代表无问题已配置完毕
6、打包发布时,需删掉XLua中的Examples,并且重新运行:XLua—Clear Generated Code—Generate Code—Hotfix Inject In Editor
7、一个类的私有属性可以访问要在 Lua 中添加
xlua.private_accessible(CS.CSHotFix);
三、Unity xlua的一些误区
误区1:我哪里预测得到哪些地方有bug,进而打标签呢?
其实不用预测哪些地方有bug,更多时候我们是把大多数类都囊括在内,然后把一些有把握不出bug(或者出了bug也不好解决,比如还没读懂代码的第三方库)排除在外。典型的打开方式是上线前把几乎所有类型都配置上,然后随着后续迭代把一些稳定的模块排除在外。
误区2:打标签太繁琐了,操作性不强。
打标签确实繁琐,但是早在去年1月份就可以不打标签,通过配置来配了,以至后来文档明确说了直接在类上打标签是不建议。xLua支持的动态配置结合linq,批量配置大量类也就几行代码的事情。
例如我们要对某名字空间下所有类配置到Hotfix列表,可以这样:
public static class HotfixCfg { [Hotfix] public static List<Type> by_property { get { return (from type in Assembly.Load("Assembly-CSharp").GetTypes() where type.Namespace == "XXXX" select type).ToList(); } } }
如果你没规划名字空间,可以考虑全注入+排除某些类的方式。还可以考虑放到一个目录,然后正则处理后生成一个类的静态列表(xLua的另外一种配置方式)。
误区3:Hotfix列表里头的类型都加到LuaCallCSharp列表。
这样操作会大大增加代码大小。其实没必要加,业务代码是不加都能调用到的。引擎、系统、dll形式的第三方库如果你补丁代码调用了个新的api会因为代码剪裁而调用不到。你可以考虑禁止代码剪裁或者加上ReflectionUse。
误区4:希望用lua函数做callback,但对应的委托没加到CSharpCallLua。
这个有个通用的解决办法:CSharpCallLua也支持动态配置,可以反射结合linq,返回所有字段,所有函数的参数和返回值涉及到的委托类型。
误区5:lua打完补丁,lua补丁怎么维护?
额,lua补丁其实只是紧急情况下(影响面大的bug)紧急处理方案,正常情况下补丁就修当前线上版本的bug而已,后续不需要维护。
误区6:C#的object参数接口调用,有时需要指定确定类型。
c#的类型远远比lua要丰富,怎么转换,依赖于你所调用的函数的参数类型信息,比如一个lua整数,你的参数是short,xlua就转short,参数是int,就转int。如果没任何类型信息(object),xlua只能选一个不丢失精度的,lua53的整数是原生64位整数,对应C#的long。
这时你可以定义一个RawObject,可以参考下配套的例子:11_RawObject,该例子演示了怎么指明以int类型传递到object参数。
如果你有这方面的需求(StrangeIOC就用到这类object参数接口),建议加上各种基本类型的RawObject。
误区7:重载含糊的函数调用不了
用xlua.tofunction可以解决这问题,参加FAQ相应条目。
误区8:以aop称呼热补丁
首先这是不影响使用的,只是个人听起来不太习惯,想ps一下。
aop是一种编程思想,“代码注入”只是其中一种aop的实现方式,还有各种各样的其它实现方式:早期有通过java的动态代理实现aop的;而aspectj则是加入了新的语法,在编译器层面实现aop,等等等等。早在aop提出之前,“代码注入”就应用于软件的补丁方面,特别是没有源码的软件修复。