网站营销平台代理商,有哪些做淘宝素材的网站,帮客户做网站的公司,wordpress手机电影这边有一个Unity项目用的tolua#xff0c; 游戏运行后手机上lua内存占用 基本要到 189M#xff0c; 之前峰值有200多。 优化点1 加快gc频度#xff1a;
用uwa抓取的lua内存#xff0c; 和unity的mono很像#xff0c;内存会先涨 然后突然gc一下#xff0c;降下来。 这样…这边有一个Unity项目用的tolua 游戏运行后手机上lua内存占用 基本要到 189M 之前峰值有200多。 优化点1 加快gc频度
用uwa抓取的lua内存 和unity的mono很像内存会先涨 然后突然gc一下降下来。 这样内存峰值就会比较高再加上游戏里其他内存占用多 3G的ios内存吃紧很不友好容易闪退。 所以一个方法 调了lua gc的参数 让其加快了gc频率 由于lua这边是增量式GC的所以gc频率高了 也没啥卡顿。 最后性能测试 发现lua 游戏里内存占用基本是 一条直线了。 参数是这么设的 另外一个项目的lua也是这么设的网上找到的一些例子也设了这个参数 collectgarbage(setpause,100) --表示当收集器在总使用内存数量达到上次垃圾收集时的(100/100)一倍时再开启新的收集周期。 (默认200)collectgarbage(setstepmul,5000) --表示垃圾收集器的运行速度是内存分配的505000/100)倍如果此值小于100可能会导致垃圾回收不能形成完整的周期。 默认200collectgarbage(restart)
之前是默认值回收频率比较低。
优化点2 去掉了因require路径 / 和 .的混用造成的重复加载 参考我另外一篇文章单独说了这个问题。 发现契机是这样的 这边点开始游戏 会初始化预处理很多数值表原因就是 require 来 require 去 引用关系嵌套 导致很多不一定用的表也加载了。 因为登录游戏后服务器发数据过来 必须把有的模块初始化好 这个也是个优化点暂时还没去处理 卡顿很久体验不好。 所以想到刚进游戏 在登录界面等待没事做时可以 分帧加载必须的数值表。 减少一次性的卡顿。 但跟踪发现 好像优化不大而且好多表都加载2次。 才发现 require data/xxxx require data.xxxx 在真机上会加载2次 用的库没改好。 简单优化方案入口lua最开头重写 require 把 传进来的路径 把/替换成的. 实际一跑发现卡顿时间表少了 内存还减少了35M左右。 优化点3 数值表lua里内存精简 一开始看了这篇文章Lua性能优化一Lua内存优化 - 知乎 里面提到了这篇文章Lua配置表存储优化方案 - UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技
这边项目的策划数值表是导出成protobuf的二进制格式然后加载到内存里。方便前后端解析因为协议都是用Protobuf。 但项目里数值后期太多 大头都是数值表所以优化数值表可以省很多内存优化方法A 就是前面有提到的 把字段名优化掉 这个项目很早之前就实现过了 把解析出来的数据 每行字段值 按[1] [2] ……[n] 索引存放 代码请求时 用了一个meta table里面记录了 表的所有字段名及对应的索引 从.pbc文件里解析 google.protobuf.FileDescriptorSet 得到的 local dataMetatable {}dataMetatable.keys {}local t_pbc protobuf.decode(google.protobuf.FileDescriptorSet, pbcBuff)local proto t_pbc.file[1]for _,v in ipairs(proto.message_type[1].field) dodataMetatable.keys[v.name] v.numberenddataMetatable.__index function(t, k)local v rawget(t, dataMetatable.keys[k])return vend
这样确实省下二三十M内存吧数值不一定准。 解析表会稍慢些。优化方案B 每行数据按需加载 这个方案思路本来挺好的 当时也是为了节省C#那边的mono内存。 把数值文件预处理一下把每行数据的各自序列化后按顺序存放成一个二进制文件 另外还要生成一个索引对照文件里面记录了某个key 在数值表的起止位置。 这样数值表很多暂时用不到的数据就不用加载进来。 省下很多内存。 getbykey时找一下发现内存里没有则用流方式去文件里读取数据然后单行反序列化下就行了。 只不过索引文件也会占一部分额外内存放在内存里面 实际项目到了后期发现内存没省多少进加载也特别卡了。 因为很多数值表 数据需要全部遍历预处理一下一些字段 造成不少表还是全部读取了反而没有优化变更卡更占内存。 也没有不用了 回收的机制。 这个可以继续规范优化比如个别表全部加载方式个别表按需加载 再实现长久不用的数据或表释放掉……优化方案C 每个数值表设一张默认值表
就是前面uwa文章里提到的一般数值表有很多字段完全一样没必要重复存放。这边项目后期确实很多字段虽然看起来用着但都默认填一样基本是废的但还占用内存 这样就可以 把一些数据很多的表统计一下每个字段的默认值 导表或者解析表数据存到内存时 发现字段和默认值一样的就不要导出或者存到内存里直接置空就行了 这边是这样实现的在 方案A的基础上做了调整, metatable里加了一个default表 __index时如果key取到数据为nil则从default表里取 local data_name proto.message_type[1].name -- 数值表名dataMetatable.default InitDataDefault.get_data_default(data_name)for _,v in ipairs(proto.message_type[1].field) dodataMetatable.keys[v.name] v.numberenddataMetatable.__index function(t, k)local v rawget(t, dataMetatable.keys[k])if nil v and dataMetatable.default thenv dataMetatable.default[k];endreturn vend default表的结构类似这样 针对几个大表处理 lua gc后内存降了有40多M 只不过加载时间可能会变长些所以目前只是在IOS小内存设备上开了这个处理。 内存优化量仅供参考。 具体还是看数值表的复杂情况和量级。 附带其他几个lua 优化的文章Lua性能优化技巧_lua 性能优化-CSDN博客
https://www.cnblogs.com/marcher/p/16866981.html
