其实可以自己做，这俩天折腾了一下，就是不要用他的自动图集，构建的时候，自己处理一下依赖关系。然后config里头加一下，按照引擎加载的逻辑，生成一个图集的json,打包后的图片png,碎图的json加入依赖，具体还没操作，不过逻辑应该是能走通的。
这句话我彻底没脾气了。老多项目一立项就是俩三年。2.x同学们很多东西就只能靠自己了。
不是因为不想买，是买不起VIP。我想表达的是，已经了解了引擎对2.x的态度。项目升引擎需要时机，不是想升就升。目前用着2.x这些问题客观存在。项目跟不上引擎版本迭代的进度也是没办法的事情。之所以选用CocosCreator也是比较符合当初立项的状态。另外我们这个项目是从2.0一步一步升级上来的，代码中还有很多1.8.x版本的时候的内容，现在正在升2.4.11。
新立项还好说
老项目本身稳定运营，
要从2.4.x到3.x真不放心
3.x目前也没有一个LTS版本，
3.8问题也不少
就跟你说的一样，既然都谈钱了，那啥问题都能解决了我干啥还要在论坛里问呢，招几个人天天守着美术打图集都行。
官方这个态度，2.0的下场，早晚也是3.0的下场。
构建后改config感觉有不少问题，1是不如一开始就用tp，2是还得处理旋转和空白像素啥的，也不是一个通用的方案，而且我们还有很多复杂的子bundle逻辑。
不过我试了下2.4.10，发现自动图集缓存的话应该是有用的，缓存位置在temp/TexturePacker目录。第一次构建速度很慢，第二次速度很快，第三次删除缓存目录构建时间又和第一次一样了。没有开纹理压缩
1赞
再补充下，在default中开了webp，quality80，打包web mobile缓存依然有效。用了724张128x128的小图，图集尺寸设置为4096x4096，实际生成图片尺寸为2948x4095。 
所以我看jare原则上没记错
1赞
你是不是没有仔细看代码, 这个不兜底好像不行.
或者在onDestroy时clearTimeout,
或者是不是setTimeout应该改成this.scheduleOnce.
否则完全没办法防御啊.
3.8不就是lts版本
抱歉我没仔细看，这里应该 clearTimeout 才对。确实引擎内不应该写满 isValid，但是这里取消这个计时器是必须的。
这里确实可以这么判断，不过因为 2.x 不会再做这种修复性的改动了，所以抱歉不能合并。这个问题在 3.x 也已经不存在了。
bug 修复都不合了吗。。。如果 2.4.12 还没发是不是考虑放到 2.4.12。。。
看到 github 回复了，确实更应该用别的方式修复
抱歉合了也没用了，哈哈哈。而且现在不会引入这些改动，无法做到因地制宜，只能用原则来解决。毕竟鬼知道改了一个小地方会不会有连锁反应或者改出新问题。
啥时候 3.x 2d 的内存、cpu、gpu 开销和 2.4.x 差不多了我立马就升
你升了，3.x的性能立马和2.x差不多。（你们都不入坑，官方咋有动力更新）
我们也是用2.4.11，项目太大升不了3。之前打包每次合图就要2小时，合图缓存可能是有bug基本没生效。后来自己用Golang写了个小工具，打包前用工具生成所有自动图集再用Creator打包，不用任何缓存，合图时间从2小时减到45秒 。
我都是用tp，一切在自己掌控的感觉~嘎嘎香~~
早就差不多了
3.8是稳定版本了吗，我看4.0版本好像也在进行中，到时候新版本改动会很大吗
是稳定版了，现在没有 4.0 啊