Unity客户端Lua基础：热更新原理与C#交互实战

1. 项目概述：Unity客户端为什么绕不开Lua

先说结论：在Unity游戏开发里，Lua几乎成了客户端热更新方案的默认选项，特别是做手游、微信小游戏、数字孪生这类需要频繁发版迭代的项目。你去看招聘需求，十个客户端岗有七八个都写着“熟悉Lua、熟悉xLua或tolua”。这个项目标题里的“Unity游戏开发客户端Lua基础”，看着简单，但背后其实牵出一整条技术链：Lua语言本身、C#与Lua的交互机制、热更新框架选型、调试工具链、内存与性能优化。要真正能在项目里落地，不是会写几句print("hello")就够的。

这个内容适合谁？刚入行的Unity客户端开发、准备做微信小游戏或独立游戏想引入热更的开发者、以及从纯C#工程转向Lua业务层的朋友。它能帮你快速搞明白：为什么项目要引入Lua、C#和Lua到底怎么互相调用、一个真实业务界面从C#层到Lua层的完整打通流程、以及最常见的坑都踩在哪里。

我自己最早接触Lua也是一脸懵，总觉得“好好的C#不用，非要套一层脚本”，后来做了热更新需求才明白，没有Lua，线上Bug就得走渠道审核，等审核通过黄花菜都凉了。这篇文章就把我从零到能用Lua写业务、再到排查线上问题这一路的经验整理出来，尽量用大白话讲清楚，你跟着走一遍，至少能独立搞定一个完整的Lua业务模块。

2. 内容整体设计与思路拆解：热更新需求与方案选型

先解决一个最根本的问题：Unity客户端为什么非要引入Lua？很多人第一反应是“为了热更新”，但热更新只是表象，本质是动态执行代码的需求。C#代码在iOS平台是被编译成AOT（Ahead Of Time）机器码的，系统不允许运行时动态生成并执行新的IL代码，这就是苹果的审核限制。而Lua是解释执行的语言，把Lua脚本打成AssetBundle或者直接放在服务器上，客户端运行时下载、加载、执行，相当于绕开了“代码必须随包体过审”的限制。

当然也有别的方案，比如ILRuntime、HybridCLR（原huatuo），它们也能做热更新，且性能和C#更接近。那为什么很多人还是选Lua？核心原因有几点：一是Lua方案成熟稳定，xLua、tolua在大量上线项目里跑了好几年，踩坑资料多、社区答案多；二是Lua和C#的交互性能只要规范使用，是能接受的；三是策划和服务器同学很多本来就会Lua，改客户端逻辑的门槛低。当然这不是说Lua完美，而是对一个“追求稳定、快速上线、团队协作”的商业项目来说，Lua是风险和收益最平衡的选择。

2.1 主流Lua框架选型：xLua、tolua、SLua

Unity工程接入Lua，基本是选一个C#与Lua的桥接框架。市面上主流有三家：

个人建议新项目优先考虑xLua。它有几个实打实的优势：生成代码机制成熟，泛型支持好，还提供了一套ulua/xlua通用的底层加载方式。更关键的是xLua的“热补丁”能力，线上出了小逻辑问题，不用整包替换，写个补丁脚本就能临时修复，这在大DAU项目里简直是救命的。tolua也不是不能用，只是它手动处理wrap类的工作量更大，新手上手成本更高。

2.2 为什么要“Lua写业务、C#写框架”

想明白架构分层，后面写代码才不会乱。我在项目里推的是这样一条分层原则：

• 引擎层不动：Unity引擎、第三方SDK、网络底层这些必须用C#，它们要保证稳定和性能。
• 框架层用C#：UI框架、资源管理、事件系统、配置表加载、热更流程管理，这套基础能力用C#写，因为更接近引擎API，调试和性能都可控。
• 业务逻辑层用Lua：界面展示逻辑、按钮流程、任务系统、商店、背包，凡是会频繁改的、跟着版本策划走的，全部放Lua。

这样划分之后，一次发版改动Lua脚本就可以实现大部分线上逻辑调整，不需要用户下载新包，业务研发效率也能大幅提升。需要注意一点：不是所有功能都适合放Lua。对性能要求极高的循环计算、美术骨骼动画的复杂逻辑、或者底层频繁调用的工具函数，放纯Lua反而拖后腿，这类代码还是留在C#层。

2.3 一套“最小可用”的Lua运行环境包含什么

提到Lua接入，很多新手容易被“框架”两个字吓到。实际上最小运行环境只包含四个部分：

1. Lua解释器核心（lua51/lua53的C源码编译产物，xLua等框架已经帮你集成好了）。
2. C#与Lua的桥接层（LuaEnv、LuaTable、LuaFunction等封装）。
3. Lua脚本加载器（从AssetBundle、Resources或服务器拉取脚本并转给LuaEnv执行）。
4. 业务入口脚本（通常是Main.lua，负责初始化框架并跳转UI）。

在xLua里，核心就是LuaEnv这个类。它相当于一个Lua虚拟机宿主，C#这头要做的事其实是三件：初始化LuaEnv、让Lua虚拟机跑起来、在合适的时机传入数据或取回结果。工程里一般会有一个唯一的LuaEnv单例，称为LuaManager，所有与Lua有关的操作都走这个管理器，不要让每个模块自己去new LuaEnv，否则内存和性能都很难受。

3. 核心细节解析与实操要点：C#与Lua怎么打交道

这一章是整个项目里最容易卡住新手的地方。很多人写Lua脚本写得顺，但一到C#调用Lua函数、Lua回调C#方法、传复杂结构体就懵。原因在于没理解C#和Lua之间是“两个独立世界”，它们之间的通信全靠在边界上做数据转换和函数映射。

3.1 LuaEnv初始化和生命周期管理

先看最基础的一段C#初始化代码，通常放在游戏启动场景里：

using LuaInterface; // 或 XLua.LuaEnv 的命名空间，取决于你用哪个框架 public class LuaManager : MonoBehaviour { public static LuaManager Instance { get; private set; } private LuaEnv _luaEnv; void Awake() { Instance = this; _luaEnv = new LuaEnv(); // 设置自定义加载器，比如从AB包或服务器读取.lua文本 _luaEnv.AddLoader(MyLoader); // 启动Lua侧入口 _luaEnv.DoString("require('Main')"); } private byte[] MyLoader(ref string filePath) { // 返回Lua脚本的字节数据，xLua会调用这个委托来加载脚本 string scriptText = LoadFromAssetBundle(filePath); return System.Text.Encoding.UTF8.GetBytes(scriptText); } void OnDestroy() { // 一定要释放 _luaEnv.Dispose(); _luaEnv = null; } }

这段代码里有几个关键动作需要解释：

• new LuaEnv()会创建独立的Lua虚拟机，一个App只有一个LuaEnv，这是基本铁律。如果某个模块自己new一个、用完不Dispose，内存会持续涨，线上内存泄漏往往就是这么来的。
• AddLoader(MyLoader)是告诉Lua虚拟机：当Lua侧require('xxx')时，去哪个资源路径加载脚本。这里可以接AssetBundle、可以接Resources、可以接服务器热更缓存目录，完全由你的资源系统决定。
• DoString("require('Main')")开始执行Lua代码，加载入口脚本，后面所有业务逻辑就都走到Lua世界了。

3.2 从C#调用Lua函数：LuaFunction的使用方式

假设Lua侧定义了一个叫OpenPanel的函数，C#要调用它，通常这样做：

LuaFunction openPanelFunc = _luaEnv.Global.Get<LuaFunction>("OpenPanel"); openPanelFunc.Call(panelName, userId); openPanelFunc.Dispose();

这里有一个很重要的细节：Get<LuaFunction>拿到的每个对象，用完后要调Dispose()。别小看这个动作，如果你在Update里反复Get，又不Dispose，Lua侧的对象就永远没法回收，内存会以肉眼可见的速度上涨。我在项目里见过同事写的循环Get不Dispose的代码，跑了半小时内存涨了两百多兆，查了半天才发现是这里。

3.3 从Lua调用C#方法：C#静态方法、实例方法、回调函数

Lua调用C#是框架的核心能力，也是新手最容易踩坑的地方。xLua生成代码后，Lua侧可以直接这样：

-- 调用C#静态方法 local go = UnityEngine.GameObject("MyObject") -- 调用C#实例方法 local transform = go.transform transform:SetParent(parentGo.transform, false) -- 调用C#事件/委托 local btn = go:GetComponent(typeof(UnityEngine.UI.Button)) btn.onClick:AddListener(function() -- 这是Lua匿名函数回调C#事件 end)

这里面的要点是：

1. 在Lua里调用C#的实例方法，要使用冒号“:”传self，这跟Lua自身语法一致。
2. typeof是xLua提供的全局函数，不是C#的typeof关键字，是框架封装好了给Lua用的。
3. 委托和事件支持匿名函数，这让Lua写UI回调非常方便，但也带来了闭包持有问题：如果你在Lua侧往一个C#事件里AddListener了一个lua function，而面板关闭时没移除监听，那么这个lua function会被C#侧一直引用，导致整个Lua脚本无法被回收。这是一个非常隐蔽的内存泄漏点。我的处理习惯是每次面板初始化时把监听函数保存成成员变量，关闭时显式RemoveListener，同时把引用置nil。

3.4 数据类型传递的边界规则

C#和Lua传参时，int、float、string、bool这些基础类型可以直接传，但有一些“坑”必须提前知道：

• Lua的number是double型的，传超过2^53的整数会丢精度，C#侧接收时如果定义的是long，也有精度问题，常见场景是“战斗伤害值、玩家ID、时间戳”，这些数据要么拆成字符串传，要么在C#侧用long，但只在Lua侧做展示不参与运算。
• 数组和List在Lua侧通常会转成table，访问方式变成arr[1]，注意是从1开始不是从0开始。这个对写惯C#的人来说，几乎每天都要提醒自己一遍。
• C#的Dictionary传过去是table，取值时用dict[key]，但key如果是枚举类型，在Lua侧需要用整数下标，或者通过框架的适配类映射，否则找不到。
• 自定义class，比如PlayerInfo，xLua会把它的字段暴露出来，但性能开销较大。如果频繁调用，比如每帧更新几千个对象，建议把数据聚合成一个纯C#层的大数组，Lua侧一次性拿到数组引用，再用索引方式访问，能省掉大量交互损耗。

3.5 常见错误：Lua侧拿不到UI组件

很多新手会写出这样的代码：

local txt = go:GetComponent("Text") -- 错误或拿不到

原因是Unity的GetComponent接受Type参数，但Lua字符串并不会自动等同于Type。xLua里你可以这样写：

local txt = go:GetComponent(typeof(UnityEngine.UI.Text))

或者先创建一个C#类型缓存：

local TextType = typeof(UnityEngine.UI.Text) local txt = go:GetComponent(TextType)

这不是Lua的问题，是桥接框架对Unity API的封装规则。理解了这一层，调试报错时就能快速定位。

4. 实操过程与核心环节实现：从零写一个Lua业务UI面板

光讲原理容易飘，真正动手写一个完整的功能就能把前面所有知识串起来。我以“登录后打开主城面板，显示玩家名字和金币，点按钮加金币”这个最简单的业务为例，演示完整打通链路。

4.1 工程准备：目录和资源放置

假设项目用的xLua。工程里Lua脚本不是直接随便放的，需要约定目录。常用组织方式：

• Assets/LuaScripts/存放所有Lua源代码
• Assets/LuaScripts/Main.lua入口
• Assets/LuaScripts/UI/MainCityPanel.lua业务UI
• Assets/AB/放置打好的AssetBundle包，Lua脚本最终打成LuaBundle

实际项目里Lua脚本有两种加载方式：第一种是编辑器阶段直接读文件，调试方便；第二种是发布阶段打进AssetBundle，从AB加载，这是上线后的主流方式。我建议调试时用“文件加载器 + 自定义Loader”，发布时切到“AB加载器 + 自定义Loader”，一套代码通过宏或配置切换，这样开发和线上都不折腾。

4.2 编写C#侧的UI启动入口

UI框架如果项目里没有现成的，可以先写一个最小的“界面管理类”。C#侧只需要负责把“面板GameObject”传递给Lua，其余逻辑全交给Lua处理：

public class UIManager : MonoBehaviour { public void OpenPanel(string panelName) { // 从AB或Resources加载面板预制体 GameObject prefab = Resources.Load<GameObject>($"UI/{panelName}"); GameObject instance = Instantiate(prefab, transform); // 通知Lua执行面板初始化 LuaManager.Instance.CallLuaFunction("MainCityPanel_Init", instance); } }

等等，MainCityPanel_Init这个命名太随意了，建议统一用“模块名_方法名”的命名规则，例如：

• MainCityPanel_Open
• MainCityPanel_Close
• MainCityPanel_Refresh

这样C#和Lua侧沟通清晰，不容易重名。以前项目里有人喜欢叫OpenMainCity、InitMainUI，五花八门，后来统一规范，排查问题效率高多了。

4.3 编写Lua侧的面板逻辑

Lua侧代码如下，注意用面向“表+函数”的方式组织，而不是用复杂class：

local MainCityPanel = {} local gameObject local coinText local coinCount = 100 function MainCityPanel.Open(go) gameObject = go local transform = gameObject.transform -- 获取子物体上的Text组件 local nameText = transform:Find("Info/NameText"):GetComponent(typeof(UnityEngine.UI.Text)) nameText.text = "玩家"..tostring(PlayerInfo.id) coinText = transform:Find("Info/CoinText"):GetComponent(typeof(UnityEngine.UI.Text)) coinText.text = "金币："..coinCount -- 为按钮绑定加金币逻辑 local addBtn = transform:Find("BtnAdd"):GetComponent(typeof(UnityEngine.UI.Button)) addBtn.onClick:AddListener(function() coinCount = coinCount + 1 coinText.text = "金币："..coinCount -- 调用C#方法保存数据 LuaManager_SaveCoin(coinCount) end) end function MainCityPanel.Close() -- 关闭时需要清理监听、置空引用 gameObject = nil coinText = nil end return MainCityPanel

然后Main.lua里加一个分发入口：

local MainCityPanel = require("UI.MainCityPanel") function MainCityPanel_Open(go) MainCityPanel.Open(go) end function MainCityPanel_Close() MainCityPanel.Close() end

这样一个简单的Lua业务面板就完成了。C#点击按钮打开面板，Lua里处理显示和交互逻辑，点击“加金币”按钮数据增加，整个流程全通。

4.4 参数传递与Overhead分析

很多项目的性能问题出在“频繁跨语言调用”上。Lua调C#不是免费的，一次调用有几微妙到几十微妙的开销，看似不大，但一帧里如果调用上千次，性能就上来了。实测经验是：

• 每帧且每对象调用的逻辑，尽量合并成一次C#调用。例如给100个NPC设置位置，不要在Lua里循环100次调transform.position，而是C#提供一个批量设置接口，传一个数组进去。
• 尽量避免在Lua侧频繁创建临时table传给C#，跨语言传table的开销比传基础类型高很多。
• 如果只是数值增减，在Lua内部用number类型自算，只在最终结果需要同步给C#时再传一次。

这里需要特别说明一下：transform.position在Lua侧设置时会分配临时Vector3对象，在大规模更新场景下会产生大量GC。常见优化是把transform.localPosition赋值改为使用transform:SetLocalPosition(x, y, z)的扩展方法，这能显著减少临时对象分配。

4.5 Lua侧制作地图/关卡流程的简化说明

搜热词里有人问“lua制作地图详细步骤”，在Unity引擎下，Lua自己并不负责地图编辑器，而是负责地图的加载和配置。典型做法是：地图数据以Json或Lua表配置形式存在，Lua读取配置后动态创建Tile或加载预制体。步骤大概是：

1. 用Unity的Tilemap或预制体制作地图块，导出成AssetBundle。
2. 策划配置地图文件，内容是“地点ID、格子坐标、资源引用、怪物ID列表”。
3. Lua侧解析地图配置，按坐标实例化地图块。
4. 玩家进入地图时，Lua只加载相机范围内的格子，实现“大地图分块加载”。

地图这块最容易出错的是坐标转换。地图像素坐标和世界坐标经常存在偏移，建议在配置里约定好“格子坐标转世界坐标”的公式，Lua和C#用同一个公式函数，避免两边各写各的导致拼接缝。

5. 常见问题与调试排查技巧

实际上手写Lua业务时，出错最多的场景往往不是语法问题，而是“C#和Lua两边类型对不上”或“加载不到脚本”。我把高频问题整理成一个速查表。

5.1 调试方式：没有断点怎么追踪逻辑

Lua写业务时最大的不便是断点调试不如C#方便。但其实是有的，只是很多人不知道。

早期项目就是用print大法，在代码里到处打日志。这种方式简单但效率低，而且日志多了会淹没关键报错。更推荐的做法是接一个Lua调试器，比如xLua官方支持的调试模式，或者使用ZeroBrane Studio，配合EmmyLua插件，可以在编辑器里打断点、单步执行、查看变量值。开发体验会好很多。

如果不想折腾IDE，至少要掌握两个基本功：

1. 写一个dump函数，可以打印table的层级结构，排查“table里到底有没有这个字段”。
2. 在C#侧做一个Lua日志转发。Lua的print默认输出到Unity的Console，但线上环境看不了，要把日志通过网络或文件上传到后台，这个功能叫“Lua日志远程收集”，上线排查必备。

转发逻辑很简单，在C#侧注册一个log函数替换Lua的print：

_luaEnv.DoString(@" local originalPrint = print function print(...) originalPrint(...) LuaBridge_Log(table.concat({...}, '\t')) end ");

这样本地和线上都能统一收集Lua日志，定位问题会轻松很多。

5.2 runtime报错时先看调用栈

Lua报错信息很多人觉得看不懂，其实它已经把关键信息给出来了，比如：

lua: Assets/LuaScripts/UI/MainCityPanel.lua:18: attempt to index a nil value (field 'coinText')

这个报错告诉你：出错文件是MainCityPanel.lua，第18行，错误原因是coinText为nil，但你尝试访问它。拿到这个信息后，第一步去Lua侧看第18行是什么操作，第二步往上追踪这个变量什么时候赋的值、什么时候被置nil。

一个非常常见的场景：面板关闭了再打开，Lua侧缓存了一个组件引用，但关闭时置了nil；重新打开时初始化逻辑只执行了一部分，另一个函数里又用了这个nil变量，就报这个错。解决办法是每次打开面板时强制清空旧缓存，重新初始化所有引用，不要在Open流程里出现“如果xx存在就复用”的逻辑分支，这样最容易出隐性bug。

5.3 线上热更失败怎么排查

热更新是Lua方案的核心价值，但线上热更失败也是最让人头疼的问题。失败通常分两种情况：

第一种是加载不到新脚本。原因是客户端本地缓存、AB包版本号、服务器配置三者不一致。排查时先看客户端本地Lua版本号，再对比服务器下发清单，确认下载路径和文件名是否匹配。

第二种是下载成功但执行报错。通常是因为新Lua脚本里有语法错误或在当前框架里引用了不存在的全局函数。线上热更比本地开发风险更高，因为一部分用户更新了、一部分没更新，两份逻辑同时在线，如果脚本里有对旧资源的强依赖，非常容易出问题。我的经验是：发热更前必须先在本地模拟“从旧版本升级到新版本”的完整流程，重点测试资源加载和缓存逻辑，不要只测全新安装。

5.4 关于“Lua写蛋仔代码出现方框框住代码”这类问题

热词里有个有意思的搜索：“lua写蛋仔代码在vs里每行都有个框框框住代码”。这个问题其实跟Lua本身无关，是代码编辑器把Lua文件识别成了其他语言，导致语法高亮和括号检查异常。解决方法是：在VS Code里确认右下角语言模式是Lua，如果不对，点击语言模式选择Lua。如果还不行，可能是装了某个插件把默认语言改掉了，卸载冲突插件或修改文件关联配置即可。这种问题很常见，但一般不卡人，别被它劝退。

6. 项目落地细节：从“写出能跑的Lua”到“写出能上线的Lua”

到这一步，你已经能写一个简单的Lua业务模块了。但要上生产环境，还有几个绕不开的工程化细节，这里一次性讲透。

6.1 全局变量污染与规范

Lua脚本最容易犯的错是把变量写成全局变量。比如：

function MainCityPanel.Open(go) currentCoin = 100 -- 忘了加local，变成全局变量 end

这行代码没有加local，currentCoin就会变成全局变量，被Lua虚拟机的全局表一直引用。如果这个变量是函数、table或者持有GameObject引用，它永远不会被GC回收。时间一长，内存占用会越来越高。

为了避免这个问题，团队里要强制开启“禁止全局变量写入”的检查。xLua提供了LuaEnv.Global访问，但更直接的做法是在Main.lua起始位置注入一个修改__newindex元方法的代码块，一旦检测到对全局表的写入就抛错或打日志。这样开发阶段就能抓到所有“不小心创建全局变量”的地方。

6.2 Lua侧的面向对象与代码复用

Lua不是面向对象语言，但业务写大了，完全靠模块化table也容易乱。最常用的方案是“简易类实现”，核心机制是用setmetatable和__index实现继承。

local BasePanel = {} BasePanel.__index = BasePanel function BasePanel.New() local self = setmetatable({}, BasePanel) return self end function BasePanel:OnOpen() -- 子类实现 end local MainCityPanel = BasePanel.New() function MainCityPanel:OnOpen() -- 覆写父类方法 BasePanel.OnOpen(self) end

这块不要搞得太复杂。我见过有人把C#的MVC、MVVM原封不动搬进Lua，结果几十个类、几百个文件，改一个功能要翻五六个文件，团队协作效率反而下降。Lua写业务更适合轻量约定，不追求大型架构范式。

6.3 定时器与Update的Lua化

Unity的MonoBehaviour.Update在Lua侧也有对应方案。简单场景可以用协程（coroutine）驱动，但更常用的是在C#侧维护一个“全局驱动脚本”，每帧调用Lua的OnUpdate(dt)：

void Update() { LuaManager.Instance.CallLuaFunction("GlobalUpdate", Time.deltaTime); }

function GlobalUpdate(deltaTime) -- 遍历所有激活的定时器 for id, timer in pairs(activeTimers) do timer.elapsed = timer.elapsed + deltaTime if timer.elapsed >= timer.interval then timer.func() if timer.repeatCount ~= -1 then timer.repeatCount = timer.repeatCount - 1 if timer.repeatCount <= 0 then activeTimers[id] = nil end end timer.elapsed = 0 end end end

写定时器时有一个容易踩的坑：如果timer回调里销毁了UI对象或暂停了战斗，而定时器列表还在继续遍历，就会发生“在遍历中修改table”的报错或者nil调用。安全做法是先收集要删除的id，遍历结束后统一清理，或者用倒序遍历。

6.4 资源释放与面板关闭规范

Lua业务里，面板关闭最容易出资源泄漏。我的规范是这样：

1. 面板打开时，所有通过GetComponent拿到的组件引用统一放到一个_refs表里。
2. 面板关闭时，遍历_refs置nil，再销毁GameObject。
3. 面板的按钮监听统一用AddListener绑定，关闭时先移除监听。
4. 与网络模块注册的回调，关闭面板时也要反注册。

这个规范听起来简单，但真正做到位，线上内存问题能减少八成。尤其是网络回调和事件回调，不少项目就是因为面板关闭后回调还指向lua函数，导致Lua脚本永远无法被回收。

6.5 热更版本管理的约定

Lua脚本最终要跟着版本走。约定一个“Lua版本号”概念：

• 每一份Lua脚本打包时生成一个MD5值。
• 服务器维护一个“当前线上Lua版本清单”的配置表。
• 客户端启动时请求版本清单，比对本地缓存的版本号，不一致则下载新脚本。
• 下载完成后先写入临时文件，全部下载成功再原子性替换，避免下载一半导致脚本不完整。

这个流程我已经在实际项目里跑了很多年，提醒一个关键点：下载Lua脚本时一定要校验MD5，不校验的话，网络抖动可能导致一个损坏的Lua文件上线，用户装了之后一直报语法错误，非常难排查。另外，本地缓存目录要放到Application.persistentDataPath里面，不要放StreamingAssets，后者是只读的。

7. 写在最后：我的一点实际体会

做Unity客户端这么多年，我最大的感受是：Lua本身不难，难的是把它用“对”的方式嵌进Unity工程。很多人一上来就追求用Lua写引擎层工具、写底层插件，结果性能和维护成本双输。正确的路径永远是“稳定的框架用C#，易变业务用Lua”，这个边界越清晰，项目越健康。

我自己踩过最大的坑就是一开始没做全局变量写保护，上线后内存悄悄涨，查了两天才发现是一个Lua脚本把一张战斗数据大表丢进了全局。后来把“开发期全局变量检查”和“面板关闭引用清理”这两条铁律定下来，团队再没出过这类线上事故。

最后再分享一个小技巧：不管项目用xLua还是tolua，一定要在开发环境里把Lua的启动耗时、跨语言调用次数、每帧Lua执行耗时这几个指标打出来。不需要多复杂的性能分析工具，就是几个Debug日志的事，但能帮你在早期就发现性能隐患。等到线上卡顿再想查，成本就完全不一样了。