4年前，我们就Unity主流模块的性能优化知识点逐一进行了说明。 俗称“dmdhn版”。 近几年，随着发动机本身、硬件设备、制作标准等的升级，甜蜜的未来也不断更新优化规则和方法，不断出口到广大开发者。 作为《升级版》的性能优化手册，【Unity性能优化系列】以浅显易懂的表达方式，试图让更多的开发者使用。 这次来分享一下Lua相关的知识点吧。
Lua可以说是现在商业游戏的标配，但随着Lua越来越被重度使用，一些性能问题也开始浮现出来。 在GPM、GOT Online、真人真机测试报告的任何一个中，在几个逻辑码的Top20的开销列表中都能看到关于Lua开销的函数，这一点很受重视。
如何快速抓住Lua的瓶颈呢？ 打开GOT Online上的Lua报告，看看有什么精彩的feature :
这里分别说明了报告页的几个选项卡。 如下所示，按顺序看。
1、代码效率解决Lua CPU耗时问题在代码效率-CPU时间占用页面中，可以看到Lua端的耗时。
打开这些函数后，可以通过查看这些函数的整体耗时堆栈、指定场景堆栈或显示任何帧的特定耗时堆栈来快速确定瓶颈函数。
说明：根据此处提供的Lua文件名/行号/函数名，能够确定花费CPU时间的瓶颈函数和CPU时间峰值的具体原因。
Lua函数的命名格式为X@Y:Z。 其中x是函数的名称，如果无法获取，则x为默认unknown； y是函数中定义的文件的位置。 z是定义函数的行号。 请注意，如果Lua脚本以字节码执行，则此值始终为0。 因此，建议在测试时尽可能使用Lua源代码运行。
特别地，堆栈的分析支持倒序查看，很多时候我们需要展开堆栈点个几十层，看得头晕眼花，但如果我们切换成倒序分析，即将原始的CPU耗时堆栈进行倒序排列，从而将真正开销最大的深层子函数直接突显，研发团队就能很快定位开销的瓶颈。
以项目为例，下图是按正序排序的耗时函数列表。
点击几个堆栈，发现这里有一个很大的头函数“update @ logic/factory/player _ builder/hall _ player 3360209”，但直接相反
这个头函数直接名列前茅，我们直接拿这个函数开刀就行了~
2、堆内存分配解决Lua堆内存分配较多的问题Lua的堆内存分配同样需要关注，减少Lua GC的触发频率和触发开销。 报告通过堆内存累计分配曲线函数堆栈来确定导致堆内存分配的函数。
分析的想法如下
1、关注堆内存分配的峰值
2、关注持续性的分配
如果每帧都有持续开销，则需要特别关注。 持续分配容易触发GC。
3、堆内存分配倒序分析
在总体堆栈信息中关注倒序堆栈分配占比较高的父节点进行针对性优化：
如上图，在Lua的堆内存中我们同样可以这样切换成“倒序”：只需要切换查看方式，我们就可以直观地定位到底哪一个Lua脚本中的哪一行代码在分配大量堆内存。这样，研发团队就能直接打开对应的Lua脚本，找到那一行和函数直接修改。
3、Mono对象引用>> 解决让你秃头的泄露问题在任意一种Lua插件中，都存在类似的机制：在C#层维护一个Cache来引用那些被Lua访问过的C#层对象，防止出现以下的问题：当Lua中再次访问该C#对象时，该对象可能已经被C#层的GC回收掉了，从而导致逻辑错误。所以，在Lua中始终保留某个C#层对象的引用，将会导致其无法被释放，当这样的引用越来越多，就会导致C#层的内存泄漏。
为了便于用户排查这种情况，我们在Mono对象引用的报告页面中对上述的Cache中C#层对象进行了汇总，统计了Cache中出现的对象类型和各个类型的对象总数。当该对象继承自UnityEngine.Object时，还将统计该类型中已经被Destroy的对象数量，如下图所示：
所以，对于判断Lua引用导致Mono泄露的一个简单的方法就是查看Destroyed总数是否为零。因为它表示的是Mono端已经被Destroy但Lua端却依然被索引的变量总数，理论上应该是趋向于0的。如果它持续很高，甚至还有不断走高的趋势，那么很大概率是泄露了，如下图所示：
对于某些数量持续上涨的对象类型，还可以在图表下通过对比两个不同采样点的对象引用，从而进一步定位Lua中不合理的引用。
补充说明：但凡是排查泄露的需求，建议长时间测试，毕竟泄露问题一旦发生，聚沙成塔就很快了。
以上就是在优化Lua性能时需要关注的一些问题和对应的方法，如何操作还需要大家结合项目实际情况。当然我们甜美的未来已经开发的GOT Online和本地资源检测都已经提供了很丰富的检测功能，希望能成为大家优化Lua的神助攻。