Dear John

现象

其实从UnLua1.0起就会偶尔遇到访问UObject上面的property是nil的情况，而且都是刚创建出来的UObject，就遇到了这个问题。
很显然，UnLua并没有每次都通过反射重新读UObject上面的property，而是读取了property的缓存。那就需要研究一下property的生命周期与UnLua是怎么管理并访问property的缓存的。

UnLua是目前虚幻引擎下最主流的脚本方案之一，并且最近一年多以来更新频率提高了很多，修复了很多遗留问题。而从2.2版本开始，UnLua对内部的一些实现进行了较大的改动，但目前网络上还没有介绍最新版本的改动的。所以在这里我简单分析一下UnLua2.2之后的核心改动和需要关注的生命周期等问题。

GenerateProjectFiles

UE中构建项目之前，都需要先执行GenerateProjectFiles，这样UE会通过mono执行UnrealBuildTool（UBT）收集所有模块的Build.cs，然后生成各种编译所需要的文件。比如*.generated.h等等。

在不同平台、不同IDE下还需要生成不同结构的配置，因为Xcode、VS、Rider的工程配置文件是各不相同的，UBT源码中需要分类去处理。

以VS为例，UBT会为VS生成.sln以及各种模块的.vcxproj文件，里面包含了各个模块的宏定义以及include path，都是由Build.cs生成出来的。这样IDE在打开工程时才知道模块的宏是什么，引用的路径有哪些，也就是常说的IntelliSense功能。当然，更重要的是能让编译器在编译时找到。

互联网的产生带来了机器间通讯的需求，而互联通讯的双方需要采用约定的协议，序列化和反序列化属于通讯协议的一部分。

• 序列化： 将数据结构或对象转换成二进制串的过程
• 反序列化：将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程

Lua 中的 os.time() 获取的时间是当前设备的时间，但是当前设备是可以修改时间的，所以这个接口并不可靠。另外如果设备修改了时区，这个接口也没有提供获取指定时区当前时间的功能。

这样在各种需要显示时间以及根据时间判断是否开放系统的地方很可能因此出现问题。所以需要自己封装一些接口来获取服务器时区对应的时间。因为游戏时间肯定是以服务器所在时区显示为准。

LuaJIT 可以将 lua 代码编译为字节码然后解释执行，增加反编译的难度。

通过对 LuaJIT 引擎的源码进行定制，将其生成的 LuaJIT 字节码的 opcode 随机化地打乱、增加干扰的opcode、文件格式变换。这样反编译的难度会进一步提高。下面记录一下编译 LuaJIT 的过程。

踩了很多坑，因为网上几年前基本上都是用第三方 protobuf-net 库来作为 C# 的 Protobuf 工具使用的，尤其是 Unity 。所以关于 Google 官方的 C# 集成到 Unity 基本没人使用，C# 非 Unity 的开发（比如 .net ）可以通过VS的 Nuget 快速集成 Protobuf，在 Unity 上这样做只能够在 VS 编辑器下检测到这个库，而 Unity 编辑器是不知道的，所以不能用这种方式。

而直接接入源码也会因为缺少依赖报错无法解决，最终还是采用自己编译出DLL集成的方式来接入。

另外前提是 Unity 切换成 .net4.x，因为 Google Protobuf 需要 4.5+。

在 tolua 和 xlua 中，调用 print 会直接在 Unity 控制台输出日志。而实际上 Lua 的源码中 print 只是输出日志，想要传递到 C# 需要额外做一些操作。

一、前言

tolua_runtime 是 tolua 的C源码，编译之后会输出tolua.dll。这个可以自己修改编译，为了给tolua集成lua-protobuf，需要自己编译tolua在各个平台的库。

前言

常见的Lua热更新都是在客户端下载所有Lua代码之后重启游戏，以实现重载所有数据和函数的目的。但在实际开发过程中，如果每次都要改完Lua代码重启游戏，正常人都不能接受。

除这种热更方式之外，其实还可以实现运行时热更，或者叫无感知热更。可以做到在玩家运行游戏的时候偷偷更新一部分代码。