2.4的
比如小游戏的包很大啊 超过200M了，资源远程管理了，然后资源边使用边加载，那缓存区肯定是在一直增加的，当小于200M前 不会有问题，
那么这里卡个极限的问题来说 比如缓存区现在已经是200M了 满了，但到目前为止 还是一切正常的啊，然后 你又加载了一个新图片，那么总数量要超200M，那么加载这个图片资源 是会成功呢？还是会失败呢？
我看到说法是先下载到临时缓存区 这个区因为不限大小 ，所以下载成功了 但是无法拷贝到用户缓存区 因为超200M了 所以拷贝失败，那么本次加载图片的操作 是否是成功的？能正常使用这个图片吗还？还是说本次加载图片 也都失败了？不能继续使用了？
这里是什么规则 谁知道给说说？
微信有2层缓存，一层是temp file，就是临时文件，一般给到1G，一层是用户数据，就是我们的cache，一般给到200M（申请可提升，但是建议不申请）。
cocos 做了这2层的处理，下载的内容会放到这两个地方。
在缓存满了200M的时候，你要下载一个新图片，它会放进temp file，然后当从temp file 拷贝到cache 的时候，失败，会报出 out of storage 错误。
注意这个时候，实际上这个图片还在temp file里面，然后也能正常读取，当前看起来是正常工作的。
但是缓存满了以后会出现问题，一个是你后续下载的东西存不进去，导致下次游戏还要下载，另外一个是缓存不仅仅是存下载文件，还负担很多其他功能，包括一些文件的存储，以及zip包的解压。
如果保持在满的状态，那么你的游戏时不时就会报错，或者直接卡住进不去（如果你配置表用zip压缩的话）。
然后还有一种情况，temp file 也满了，那这个图片下载就会直接失败了。
2赞
那么结论基本是说，用户缓存满了 是个很不稳定的因素 对吧，就算完全不用ZIP格式，也很难说会有什么其他问题的，
目前不会选择小游戏用ZIP的 但如果本次加载成功 ，只是拷贝用户缓存出错 只能说还算是个可接受的情况 最多下载进入游戏，再下载一次吧
不过这里插个话题，我一直不理解为什么ZIP的解压 不在临时缓存区里进行？解压完了 再拷贝到用户区？不知道是什么设计初衷
下载的文件是会存到临时区，对开发者来说，这个区只读，不可写，这是根本原因。
所以解压才需要拷贝到用户区（可写）
temp file区有api的限制（类似前面说的只读），只能通过download下载并读取，以及用copy操作转换为cache区文件。没法用于zip包的解压。
你是说 原始ZIP文件 先拷贝到用户区，然后再开始在用户区解压成零散文件？等于是用户区里多了一个原始ZIP文件？ 所以容易超限？
这里的拷贝，用词不太准确
更准确的说
默认情况下
- zip 还是下载到临时目录下（只读）
- zip解压的时候，只能解压到用户目录下（可写）
- zip解压失败，并且是不够空间的时候，那么cocos内部的 cacheManager 会触发一次缓存清理，但是会先立即回调一次失败，当然如果你有重试机制，一般3次，第二次可能就会成功了，但是只是可能。为什么呢？因为 cacheManager 触发了缓存清理，并不一定清理出足够空间给你二次重试解压。比如你的zip很大，即便 cacheManger 已经清理了一次，空出10MB，但是如果你zip超出 10MB，还是会有类似问题
clearLRU 还有一个设计缺陷
-
在说缺陷之前，首先 clearLRU 不是立即就清空所有缓存文件，而是会取出来最旧的文件，加入到一个队列，定时清理，避免短时间大量IO操作导致卡顿
-
缺陷，你可以发现下图，最旧的文件会直接取出来并加入到队列，但是实际缓存在这一瞬间就会移除这个缓存标记了
-
这会导致一个极端情况，假设你有30个文件需要清理，因为是定时队列，假设耗时30s清理完毕。那么如果用户20s后离开APP，那么剩下文件在本次应用生命周期就没法清理了
-
问题在于，下一次再次触发 clearLRU ，也不会记得上次这些未清理的文件，因为在加入队列的事后，实际缓存就清空了这些文件的记录。如下图红框所示。
-
一种正确的做法是，实际删除了缓存文件，才
cc.assetManager.files.remove(cacheKey);
this.cachedFiles.remove(caches[i].originUrl);
那么按这种规则，其实如果解压后的散文件总大小 不超限的话，ZIP方式也没有在用户区产生额外的空间占用？因为原始ZIP包一直还是在临时区里
- 引擎默认是将zip下载到临时目录，临时目录是小游戏平台自己维护缓存的，对开发者，对引擎都是黑盒，所以如果你特别在意 zip 文件本身，那么其实不用管，这个区，你也管不到，盲猜小游戏平台自己会维护这个临时目录的，放心吧
原则是如此，最近我们遇到不少unzip失败的情况。缓存文件是有清理的，还是会报the maximum size of the file storage limit is exceeded
但问题是 你没法保证清理后的剩余空间 是最够的吧？你怎么能知道当时用户区还剩下多少能用的是？
我们的是魔改引擎，每次下载文件之后，都是有数据大小（ FileSystemManager.getFileInfo）的，是被记录的。也会更具一套规则来删除最不需要的资源文件。保证缓存目录下的资源是在限制大小内
所以我是改了cache，让删除不要再定时，而是立即的同步的删除。以前我回帖里面有具体的内容。
（帖子被作者删除，如无标记将在 24 小时后自动删除）
缓存里面有垃圾文件吧，以为不存在，但实际占了空间 而且没被统计进去
