Cocos Creator 3.0.1 体验贴

我设置过后图片直接变成了黑色 :thinking:

什么样的表现?

哦 抱歉是可以的
就是如果图片在场景里面的时候去设置 就会有问题 但是把图片先取下来 设置之后在拖上去就可以了

抱歉,这个确实也是个 bug, 需要解决的,你那边是必现的么?

嗯 是的 必须

麻烦问下微信小游戏 creator 在loadBundle的时候,是如何去比较本地缓存资源是否过期的?
我在升级2.4.4之后,陆续有用户反馈在未有资源更新情况下,首次进入游戏卡顿的问题。
今天我们测试同学刚好复现了一次。
表现方式是昨天玩了一天的情况下,今天再次打开后,游戏明显卡顿。通过反馈日志发现是loadBoundle耗时都有好几秒,但最近两周都未更新过包。

我发现creator在每次构建完成后,生成的zip包的md5都会发生变化,哪怕资源没有改变。
所以我们在构建流程中,构建完成后压图的时候,会根据本地的缓存去比较这个zip包是否有没有变动,如果没有变动,zip的名字 会采用 缓存 中的 名字,相应的也会改变config.json中的zipVersion字段。

上述操作按我的理解应该是不会有问题的。那现在陆续有玩家反馈进游戏卡顿的问题,只能推测是游戏启动的时候,发现缓存过期,重新拉取bundle导致的。

所以, creator 在loadBundle的时候,是如何去比较本地缓存资源是否过期的呢?


麻烦看下

如果没有更新包的话,是会用本地缓存的

所以, creator 在loadBundle的时候,是如何去比较本地缓存资源是否过期的呢?

是通过版本号判断的,settings.js 里面会记录每个包的版本号,loadBundle 的时候,会用这个版本号拼接成 config.json 的路径,加载时会在小游戏的缓存空间里面看看这个 config.json 的缓存是否存在,不存在就去下载。

你可以确认下你那边本地复现的时候,CDN 上有收到对应的网络请求么

image
想问下这个压缩纹理的这个PNG,后面的参数是什么作用的?
我现在不管怎么调,打包出来的结果是一样的

原图:


压缩打包后:

压缩配置:
image

是用来压缩纹理的,可以看出来纹理大小发生了变化

你看看我后面发的那个图,我从1-100随便输入,打包后,图片大小是一样的,而且还比原图大

关键就是不太好复现。 刚看了一下 settings.js 中每个包对应的版本号,看起来跟bundle里面的config.json是一致的。所以按你的说法,应该不会去加载远程资源才对,但是后台日志反馈,每个loadbundle都花了好几秒的时间,这又是为啥呢?
是不是微信或者引擎 判断资源是否可用还加了其它判断逻辑,比如时间之类的?

另外麻烦问下,preload 一个bundle,是否只是将资源下载到本地?还是也会将资源载入内存中?

然后laodbundle 下载一个bundle,bundle为zip的时候,loadbundle的completeCb是仅仅加载config.json的回调 还是 加载了整个 zip包的回调?

谢谢!

我选了一下jpg,后面的参数1-100之间填选,就很正常,图片打包后压缩率是不一样的,是不是PNG的参数读取有问题?


之前有发过这个问题,我是想看看这个纹理压缩能不能替代掉我们之前打包后再用工具来压缩

有没有人,这是咋回事,运行时这个layout不在屏幕内

是不是微信或者引擎 判断资源是否可用还加了其它判断逻辑,比如时间之类的?

目前是没有的,判断的时候非常简单,就看列表中有没有记录。需要看下服务器上有没有收到网络请求。之前有人反馈过相同问题

另外麻烦问下,preload 一个bundle,是否只是将资源下载到本地?还是也会将资源载入内存中?

内存中应该会有一部分数据,所有的图片,模型什么的都没有加载进内存

然后laodbundle 下载一个bundle,bundle为zip的时候,loadbundle的completeCb是仅仅加载config.json的回调 还是 加载了整个 zip包的回调?

如果是 zip 模式的话,会等到 zip 加载完成才回调

这个我们之后优化下,现在这个工具确实不好用

谢谢回复。

之前有人反馈相同问题,请问下你们有具体去查过这块的问题么?
我们线上资源放在cdn服务器上,听运维说如果不知道玩家的具体ip,不太好去查是否拉取了资源。

只是从目前的表现以及 日志反馈上来看,定位到bundle加载时间过长

终于找到原因了

// 节点树结构
scene
|--2d(空节点,什么组件都没有)
    |--back(canvas节点)
    |--front(canvas节点)

canvas上的widget组件会变成这样,无法修改,应该是按父节点size是(0,0)计算的
(设计分辨率:750*1334)
image

widget-manager里面是这样计算的

···
target = node.parent!;
···
const targetSize = getReadonlyNodeSize(target);//这是返回的大小是(0,0)
const useGlobal = target instanceof Scene || !target.getComponent(UITransform);// 这里是true
···
// 后面的计算会根据isRoot来判断怎么计算值
const isRoot = !EDITOR && useGlobal;
···
const targetWidth = targetSize.width;
if (isRoot) {
    localLeft = visibleRect.left.x;
    localRight = visibleRect.right.x;
} else {
    localLeft = -targetAnchor.x * targetWidth;
    localRight = localLeft + targetWidth;
}

结论是:大概的意思就是父节点没有UITransform组件,编辑器里面是按targetSize算的,运行时是按visibleRect算的

应该算是引擎的一个BUG

@EndEvil

3.0是不是不支持facebook小游戏平台了啊?