自动图集 + 压缩纹理能不能有缓存啊，每次构建都需要打图集，导致打包时间变得很长，但是图集基本上都是不变的

Creator 2.x
#1

如题：
自动图集能不能有缓存啊，每次构建都需要打图集，导致打包时间变得很长，但是图集基本上都是不变的

#2

你好，自动图集是有缓存的：
2.x:
image

3.x:
image

#3

请问 如果给图集添加了纹理压缩的参数，那么会是什么情况？ 我现在图片资源很多，每个目录里的图片都给配置了图集，然后图集又配置了纹理压缩ETC2，但每次构建 我认为时间还是很长 好像没有什么缓存功能，感觉重新开始的那种 不太清楚规则了就 顺便问问了？
或者说 如果是重复构建 是不是应该很快才对 因为没改任何东西 ，那么目前看 肯定不是这样 挺慢的每次都

#4

压缩纹理和自动图集一样都是有缓存的，正常如果没有去修改图集文件夹里的内容，重复构建都会很快的；具体可以前后对比生成的图集资源的文件时间。
构建慢不一定是受纹理压缩和自动图集影响。
纹理压缩缓存一样在 temp 文件夹下：
image

#5

您的意思是我们自己把需要缓存的自动图集拷贝到temp目录吗？

#6

我看到了那个目录，但是为什么我们每次构建还是需要去跑一遍自动图集啊，是因为用了etc2的缘故吗？每次打包都需要40分钟以上

#7

我之前在小秘书上也和你反馈过这个问题，确实打包时间很长，cpu占用很高，看进程里就是在跑压缩纹理的

#8

你的资源有多少？ 比如APK有多大最后？ 40分钟 有点不能忍了 理论上不应该这么长 或者你的机器性能 有点低？

#9

我猜，获取缓存的逻辑，并不是简单根据要打包图片的哈希值来判定能否用缓存，而是加上了其他东西，所以才会出现开发时候缓存无效，而专门测试的时候缓存又有效了
我这打包微信小游戏，一旦遇到缓存失效，就要等一个多小时。查看进程，都是在跑压缩纹理的东西，如图

image
image794×150 8.85 KB

image
image

这样子，打包后测试出bug，再次打包就变成了一件特别特别痛苦的事情

#10

哎，十代i9了解下，说实话感觉很操蛋，你说有缓存吧，打包的时候log显示一直在打图集，我也很绝望，我确实看到了缓存目录，但是也确实不生效

#11

一直在跑，cpu占用很高，十代i9都得跑40分钟，也是挺服气的

#12

我也是一样的问题，但是他们说有缓存，是不是很尴尬，我现在已经不想用这个自动图集功能了

#13

如果只是图集功能 那完全可以不用其实，因为不是必须，但如果你需要图片压缩 那你就没法不用了 如果你只是图集还40分钟，估计你要是加上压缩的话 一个上午就过去了要，你可以这样试 你删除缓存先 打个包记个时间，然后重复构建 应该有缓存了 再记个时间 对比一下

#14

请问你用的引擎版本是？

#15

2.4.4

#16

我也是,恶心心

#17

自己加缓存呀!不要有什么问题就吐槽!!哈哈:hamburger:

#18

缓存没用的,大量时间是花在修改ui的json上面.出图只占了整个时间的1/10左右.

#19

3.x 是有缓存的，如果之前结合 bundle 使用的话可能会缓存失效什么的，在 3.4.1 已经都修复了。

#20

很抱歉，自动图集有缓存，压缩纹理也有，不过 2.x 在同时用了自动图集 + 压缩纹理时确实是没有缓存的。我们会计划在 2.4.9 加入这个支持。如果只是测试出现问题，需要做微调的话，可以勾选“只构建脚本”，这样就会跳过资源重新生成的步骤了。
另外，2.x 编辑器对大型项目的支持确实相对 3.x 有所欠缺，如果项目比较大，建议拆分成多个 Bundle 动态加载，这样就能减少每次构建所需的时间了。