踩Tolua中的大坑之性能问题

在完成项目中的第一个玩法,长沙麻将之后,我们发现项目中的一个重大问题。玩家打一局游戏开始的时候没有什么问题,但是打到中途,一般在4-5局的时候就会出现卡顿的问题,并且会随着游玩时间加长,卡顿会随时间加重,以至于最后FPS到10一下,游戏如同幻灯片。
通过Unity中的性能检测器,发现游戏刚开始看不出什么问题,但是到游戏中期,会发现有在LuaLooper.cs中的LateUpdate()函数在不停的跳,也就是随着游玩时间的加长,这个函数的跳跃越密集,如下图。
踩Tolua中的大坑之性能问题_第1张图片

经过查阅资料发现,这个lualooper主要负责lua中的协程调用。而项目之前在游戏逻辑中有大量使用协程。
下面就对lua的协程做一个简单的小结:
lua协程函数有六个
coroutine.start():开启一个协程,第一个参数是要开启的协程函数
coroutine.wait():等待函数,第一个参数是等待的秒数,第二个是一个协程函数(注意这个方法只能在已经开启的协程函数中使用)
例如:
coroutine.start(this.co)
function this.co ()
coroutine.wait(1)
end
coroutine.step():挂起一个协程,第一个参数是要挂起的秒数,第二个参数是协程函数(注意这个方法也和wait一样,只能在已经开启的协程函数中使用);
coroutine.www():从www获取数据,同前两个函数
coroutine.stop():结束一个协程;参数是一个协程函数。在协程函数外使用
coroutine.isrunning():判断协程是否在运行;参数是一个协程函数。在协程函数外使用
大致了解了协程函数,发现在我们的游戏逻辑中大量使用了协程函数,但是及时大量使用,应该不会有很大的性能问题,毕竟这种递增式的性能问题肯定是哪里有性能的泄漏,框架本身出问题的概率较小。
最后,怀疑是在开启协程之后在协程运行结束之后没有关闭协程导致的问题。
通过研究作者写的coroutine.lua文件发现,作者将所有的协程都放在comap这个table中。
踩Tolua中的大坑之性能问题_第2张图片
那么我在游戏中打印这个table时发现,果然这个table在疯狂增长,几乎每运行10秒就增长一倍。然后阅读tolua作者的readme时作者也有过提醒。

所以,发现了问题所在,在游戏过程中每当一个协程完毕,就将这个协程关闭。但是由于游戏逻辑已经全部写完,修改难度较大,而且在修改之后又出现各种显示的问题,比如,当一个协程没有关闭的时候开启了另一个协程,那么没有运行完毕的协程会被强制关闭。
所以,这里设计了一种判断没有已经停止运行的协程函数,并想已经停止运行的协程函数关闭的方法。方法十分简单。使用也很方便,在Updata()中定时调用就可以了。
在这里插入图片描述
这次,这场性能问题解决完毕。这场灾难无疑是程序员的大意引起的,但这种问题难以检查。在差错的过程中也采用了很多手段,比如下载toluaruntime,加入风云大佬的性能检查函数,来帮助差错,但是编译途中困难重重,加之性能检查差错日志十分难以阅读,最后放弃了从底层差错的手段。尤其产品上线在即,如果找不出解决办法,或许只能换框架。所以,以后在编码过程中应该更加慎重。差错思路也应清晰明了。
踩Tolua中的大坑之性能问题_第3张图片

你可能感兴趣的:(踩Tolua中的大坑之性能问题)