创意小游戏《动物餐厅》技术总结以及现存问题反馈

Creator 2.x
#14

问一下，动物餐厅总的开发时间有多长？

#15

image.png902×283 50.6 KB

我这几天也碰到了这个问题

#16

所以会有2.0.11来修复这个严重的问题吗

#17

会的 213455

#18

感谢楼主分享，还带来这么多的解决方案，很赞。

对于微信小游戏端的文本问题说明：

  1. 文本是通过canvas绘制然后作为字体纹理提交进行文本的渲染，卡顿的根本原因是在微信端同帧调用texImage2D次数较多时的性能消耗巨大。

  2. Shrink模式会根据文本内容不断调整文本的Size进行重排并重新进行绘制以及纹理的提交，造成卡顿的原因一是跟问题1中同样的texImage2D调用次数的增加，另外就是Shrink模式本身存在一定的计算量。

如何解决：

  1. 对于单个界面创建时，如果存在大量的文本内容，但是文本内容的字符重复较多时（字符数量 < 文本数量）可以采用CHAR模式进行字符缓存，减少字符纹理的创建。如果系统文本数量太多，部分采用BMFont或者第三方字体解决方案的同时，其他系统文本可以分帧延迟创建，尽量避免同一事件创建大量的文本数量。

  2. SHRINK模式主要是文本持续变化导致的文本重绘，这个我们后续会对SHRINK的计算进行优化，对于重绘导致的texImage2D次数增加，可以尽量控制节点的Size，减少文字大小变化带来的重排消耗。

1赞
#19

请问有没有比较详细的重现步骤或者是demo？

#20

这个 2.0.10 应该修复了呀

#21

1.build ios
2.build oppo，build结束之前，观察git，就会必现，目前看来build结束后好像就对了

#22

可能修复的是其他姿势？我发现的姿势是
1.build ios
2.build oppo，build结束之前，观察git，就会必现，目前看来build结束后好像就对了

另外build oppo 也有一个必现bug，打出来的rpk会越来越大，因为没有清理logo和配置文件

123.png416×530 92.7 KB

#23

第一个版本大概2个月不到 但是一直持续维护更新到了现在

#24

谢谢反馈，“每次build oppo版本，包体会越来越大”问题，是勾选了md5 导致。目前 提供 rpk审核时，先删掉构建目录 quickgame 重新构建。后续版本会修复

#25

mark.

#26

为什么我还是卡在引导页了？？全屏都是透明黑的，没法操作了。。。

iphone 7

#27

抱歉 修复版本还没全量发布

#28

非常抱歉，这里是我们考虑用户的使用场景不够全面，我们确实有注意到同时写文件时会导致资源锁住，导致报错，但我们设想用户使用API清理缓存资源会是在场景启动之前，不会和writeCacheFile冲突，所以在清理缓存资源的地方，都直接使用了同步写文件的方式来提高效率，确实是存在这个问题，后续会进行完善。

另外，拜读你的修改之后发现：
1.

简单的修改这里会导致另一个问题，因为writeCacheFile是延迟一段时间写回文件中，所以有可能缓存已经被删除了，但文件还没写进去，如果这时小游戏因某种原因意外关闭，会导致缓存列表中存在，但实际缓存已经被删除的情况，请知悉
2.

这个地方使用exists又查询了一次，实际上这个做法也是2.0.9之前的做法，2.0.10之所以使用一个文件来保存缓存列表，目的就是为了减少微信API access的使用，提升效率，所以这里不建议再用exists检查一次哦。

这个地方之所以没有做等待，是因为写文件是以1s一次的速度写入的，而之前做过相关测试，即使在很慢很慢的Android机型（价值￥500）上，write一次的时间也不到40ms，所以没有做更多的检查，当然这里为保险起见，之后也会做互斥的检查

查找之后发现，相同请求的处理是在cc.loader.load中做的检查

如果有发现相同url的请求已经存在则复用，所以理论上应该没有这个情况发生，请问你那边能复现资源重复下载的情况么

3赞
#29

mark

#30

感谢细心回复

cleanCache是在内部某些情况下会调用到，例如registerFailHandler

确实，这里会导致问题，所以我才会去再次判断缓存资源是否实际存在 [quote=“EndEvil, post:28, topic:79251”]
这个地方使用exists又查询了一次，实际上这个做法也是2.0.9之前的做法，2.0.10之所以使用一个文件来保存缓存列表，目的就是为了减少微信API access的使用，提升效率，所以这里不建议再用exists检查一次哦。
[/quote]

而且这个写法也是为了保证那些已经出现问题的玩家 可以顺利的加载资源，包括其他开发者，可能也有部分用户的cacheFile文件已经出现了问题，我暂时没想到既保证效率又保证兼容的做法

这个是确实存在的，因为我实际测试中，发现了同一个url走到了download里面，原因我其实之前也说了，下载完成之前，再次请求，这个this._cache是不会存有这个url的，对于大一点资源，更容易复现

#31

如果想最大化程度减少微信API access的次数，同时保证最强壮的稳定性，我建议可以参考看一下我附件里最新的代码【也merge了2.1.12的几行改动】，我直接在handle里先判断一次缓存是否存在，只有在极个别异常情况才会多走一次本地文件判断

因为安装2.0.10版本的代码，读取缓存资源之前，还是去读取了一次本地路径，确定本地路径没有后，如果发现缓存文件列表有这个文件，那么读取文件。

那么我新版本的代码，保持了一致的API access的次数，并且保证了使用cache文件的安全性，并且可以兼容已经出现问题的玩家

wx-downloader.js.zip (5.1 KB)

1赞
#32

在下载完成之前，cache里面已经会有了的，在flowIn请求的时候，item就会被缓存着用来复用，这个问题可能是其他地方导致的，我尝试复现一下

嗯，看你的最新改动里面，access保持了一致，你可以这么改，等之后看机会再提升一下效率吧

这个是我的疏漏了，十分抱歉

#33

更新2.0.10后，我们也有很多玩家反馈加载卡住的情况，辛苦各位大佬给出完整解决方案:relaxed: