有了这个跨语言共享数据的方案，我们就可以大胆将主要的数据放在Lua层，而不用再为跨语言性能而过度牺牲热更代码的覆盖率。具体怎么设计代码的架构来利用这个数据共享方式呢？

以《赤潮》这样的产品为例：

• 同屏角色200+，必须高度考虑性能。
• 我们使用了帧同步，一旦线上发现不同步的bug是致命的，必须支持热更新修复。
• 每月我们会推出新兵种，每隔几个月会推出新玩法地图和节日地图，无论兵种逻辑还是地图规则，都需要一定的热更新能力，减少发布完整包更新的必要性。

• 常用的逻辑数据（比如角色属性/角色状态/buff信息等等），用数组存储放在Lua，并通过本文源码中的LuaArrAccess共享到C#内。
• 主体战斗逻辑使用C#实现，保证基本性能。
• C#逻辑直接通过LuaArrAccess读写Lua中的数据，而不是自己复制一份。这样，无论Lua还是C#，都可以自由访问这些共享的信息。
• Lua申请一个巨大的数组，共享到C#中，C#可以通过这个数组回传事件消息，Lua可以响应来自C#的事件，性能比使用C#导出delegate更优。
• Lua实现网络同步逻辑，以便支持随时的热更同步逻辑，以及热更网络协议。
• Lua处理策划数据表，以便支持随时热更策划数据结构变更。
• Lua处理整个玩法大规则，以便我们在推出新玩法的时候，可以做到热更新。一般而言，玩法大规则的运算量比较小，并非性能瓶颈，但需要更战斗逻辑有大量数据交互。
• Lua作为战斗逻辑的大入口，有权限管理所有角色/地图/组件的开关以及生命周期，为hotfix提供最大的便利。
• 对一些可以模板化的代码，比如技能逻辑/AI节点等，支持Lua/C#两种实现方式，以便做到新特性可以直接热更。

这一切之所以可行，得益于我们可以低消耗跨语言传递数据，否则，我们放在Lua的功能（网络同步/数据表/玩法规则/声明周期管理/技能AI模板节点），会因为需要频繁跟C#交互，产生巨大的性能瓶颈。 可见，高效地在两个语言之间共享数据，是非常重要的。

此外，如果你的项目本身是用Lua做的，要迁移到C#，你也可以利用这个共享机制很轻松地将局部代码转移过去。

由于在Lua和C#间传递数据的方法很多，我们对比一下通过传统C#版Lua导出传参，以及在C导出API给Lua直接读写C内存的性能，进行对比。

环境：Windows + i7 + Unity 2018.3.11f1，Lua使用5.3.5，LuaJIT使用2.1.0beta3（启用interpreter模式）

1、可以看到，新方案（操作1/2和操作3/4）比起传统直接Lua调用C#传递数据（操作6），性能优化非常大。新方案在两个语言都做到近乎原生读写的性能，读写成本基本不再是瓶颈。因此，将代码按需求分布在Lua和C#之间，将成为可能。

2、其中，C#端的操作3/4性能会较慢，主要原因在于两方面： 

• Lua和LuaJIT都区分int和double存储，C#操作需要进行判断。其中LuaJIT的判断较为复杂，耗时也会更多。
• 为了提高易用性和安全性，本文的源码增加了一些保护，这些保护并非必须。如果希望追求更高的效率，可以参考附录自行调整。
  
  

3、而Lua原生读写数组（操作1）的效率也比通过C API访问共享内存（操作5）要高一些，提升效率大概是2~3倍的水平。而C#端我们没有对比，因为我们的实现本质就是访问共享内存的方式，所以性能本质上是一样的，完全看共享内存存储方式的具体实现（比如是否像Lua一样需要判断数据类型）。另外考虑到我们访问不需要编译C代码，所以这个方案也是非常有优势的。

4、另外，由于数据是共享的，就没有必要在Lua和C#之间分配两套内存空间存数据，也就提供了节省内存的可能性。

5、事实上，了解Lua底层的朋友会知道，Lua数组（采用1~n连续整数键值的表）比Lua hashtable（即有带命名字段的表）访问起来要快，且节省内存（TValue的内存占用大概是Node+Key/Value的四分之一）。所以即使使用面向对象的方式开发，从性能最优的角度，我们也鼓励用Lua数组的方式来替代Lua hashtable的方式，如下代码所示： 

1. 如何整合插件

a) 由于代码使用了unsafe code，所以需要在Unity的player settings勾选Allow unsafe code。
b) 下载本文附件中的代码，将LuaAdapter.cs和LuaJitAdapter.cs拷贝到工程的任意目录。
c) 代码默认按照xLua的标准开发，但如果你使用的不是xLua也很容易集成。

• 将xLua相关的API替换为对应的API；
• 向Lua导出LuaArrAccessAPI/LuaArrAccess/LuaTablePin64/LuaJitTablePin共4个类；
• 由于xLua导出的C#类在Lua中都是按CS.XXX的命名调用，所以需要将LuaCSharpArr.lua.txt内的CS.LuaTableCSharpAccess替换为正确的命名，比如uLua为LuaTableCSharpAccess。

d) 在Lua初始化后，调用LuaTableCSharpAccess.RegisterPinFunc(L);注册函数，其中参数L是lua state的IntPtr。
e) LuaCSharpArr.lua.txt中包含了LuaCSharpArr的整个定义声明，可以直接require使用，如果你的Lua代码require机制不同，将代码复制到你的Lua可以访问到的地方即可。
f) 参考示例代码LuaTestScript.lua.txt以及LuaTestBehaviour.cs使用Lua端的LuaCSharpArr和C#端的LuaArrAccess。
g) 如果想运行测试用例，在空场景中建立一个GameObject，将LuaTestBehaviour拖进去，并将里头的LuaScript字段附上LuaTestScript.lua.txt即可。

2. 理解Lua array与hashtable

a) 你需要知道，Lua table实际内部是包含一个数组（array）和hashtable来共同存储所有数据的。其中array用于存储键值为1~n的数据，且1~n必须连续。而其他的数据，会被存放在hashtable内。
b) 必须要注意，Lua数组要求key必须是连续的整数（1~n），如果中间有空洞，那么可能出现的情况是后面的数据会被放到hashtable存储，也就无法在LuaArrAccess读取，所以我们提供了预分配机制，防止自己插入的时候出现失误。

3. 安全读写与访问

a) 要大规模在工程中使用，那么代码的安全性就很重要，将lua底层数据结构暴露这个事情，本身会破坏Lua的安全性，错误的操作可能会导致严重的内存错误。因此我们提供的实现做了一些机制避免出现问题。

• LuaArrAccess（C#访问器）会正确地响应LuaCSharpArr（Lua端数组）被GC的情况。当LuaCSharpArr被GC时会触发LuaArrAccess.OnGC()，将C#对LuaCSharpArr的引用指针置空。此时LuaArrAccess处于InValid状态，读取数值会返回0，写入数值会被忽略。
• Lua分配过的内存是保证地址的可持续性的，也就是你用指针引用的数据不会突然间被转移到其他的内存位置。
• 前文提到LuaCSharpArr.New会进行预分配，防止数组空洞。
• LuaArrAccess会检查数组越界。

b) 使用注意

• 你可以在Lua中引用LuaCSharpArr，但是不要在Lua直接强引用LuaCSharpArr:GetAccess返回的LuaArrAccess。强引用LuaArrAccess会导致C#端不能正确响应Lua array被GC的情况。
• Lua array的扩展只能发生在Lua端。也就是如果Lua array长128，你不能在C#端通过LuaArrAccess设置第129项来扩展数组长度。
• LuaArrAccess:GetArrayCapacity()返回的长度是Lua底层预分配的长度，并不是你在Lua中用#运算符获取的数组长度。一般GetArrayCapacity返回的值是2的n次方，比#返回的值更大。在这个范围内读写是内存安全的。
• 你可以通过Lua的#运算符获取数组长度，确认数组是否有空洞。如果有空洞，则#返回的长度只会等于空洞前面的长度。
• LuaArrAccess使用与Lua一致的index，也就是从1开始，而不是从0开始。但注意，LuaJIT允许从0开始，这个也是LuaArrAccess支持的。
  
  

4. 进一步的性能提升

a) LuaArrAccess的代码为了易用性和安全性，牺牲了相当程度的性能，读者如果对性能有更高要求并且有意愿修改源码的话，可以尝试以下方法提高性能。

• 跳过Index检查以及null指针检查：如果代码能够保证数组非固定长度；
• 使用GetIntFast和GetDoubleFast函数：该系列函数不检查index范围，不检查double和int类型，性能极致高效，但是读者使用需要相当注意，尤其是int和double的处理要十分小心；
• 使用C语言重新实现LuaArrAccess：使用C可以获得比C#更好的性能，但是需要读者去修改和编译Lua/LuaJIT的C代码，限于篇幅关系，这里不提供详细说明，读者可以参考LuaArrAccess的代码直接翻译到C代码。
  
  

5. 其他问题

a) 目前提供的实现，只支持数组存储int/double，不支持其他类型（bool/string等）。由于Lua/LuaJIT在默认编译方式下使用double存储浮点数，所以不提供float相关的接口。
b) 代码只支持读写数组，无法读写hashtable。这里也额外提一点，Lua hashtable虽然使用便利，但是在读写效率以及内存占用上，都比lua array要差不少。所以在我们的项目实践中，会有大量的Lua class使用array来存储字段。
c) 事实上这个方法可以举一反三，推广到用于直接在C#绑定访问lua中的某个表的一个字段，或者访问完整的key-value table，不过由于table访问的复杂性，实现起来会相对复杂一些，不在本文讨论的范围内，读者可以进一步探索。
d) 本文提供的代码并非文中提到的《赤潮》所使用的版本，因为《赤潮》使用的代码基于ulua+luajit2.1.0beta2，也未实现文中所提到的安全访问特性，且需要修改LuaJIT源码，所以代码会有大量不同。
e) 本文的源码已通过以下平台测试（xLua 2.1.14 + unity2018.3.5）。

• Windows x86/x64，Lua+LuaJIT
• Android il2cpp armv7/arm64，LuaJIT
• Ios il2cpp arm64，LuaJIT

f) 另由于Lua/LuaJIT、xLua/sLua/uLua多版本差异以及Mono/il2cpp/跨平台带来的复杂性，本文代码无法确保完全覆盖所有版本和所有平台的组合情况，如果使用中遇到问题，欢迎在下方留言反馈。