如何设置iOS缓存和磁盘存储大小，以及在应用终止后如何从磁盘存储中还原缓存? [英] How to set iOS cache and disk storage size and how does cache get restored from disk storage after app termination?

问题描述

我已经问过何时准确会从urlcache的内存和磁盘中删除内容吗?

现在我还有其他后续问题:

Now I have some more follow up questions:

1. 内存缓存受iPhone的ram(通常为2Gb)限制.但是磁盘的持久性受到64Gb或128Gb的限制.正确吗?

1. The memory cache is restricted by the iPhone's ram (usually 2Gb). But the disk Persistence is limited by 64Gb or 128Gb. Is that correct?

拥有持久性比存储存储有意义吗?如果您不想占用大量内存(并且不想让应用从挂起状态终止)，即允许从磁盘存储中还原缓存，然后返回持久结果，是否有用?

Does it ever make sense to have a persistence more than your memory storage. Can it be useful if you don't want to have a high memory footprint (and don't want app to get terminated from its suspended state) ie allow the cache to be restored from disk storage and then return persisted results?

在控件上单击URLCache.shared后，我看到以下注释:

After control clicking on URLCache.shared I see the following comments:

• 内存容量:4 MB(4 * 1024 * 1024字节)
• 磁盘容量:20兆字节(20 * 1024 * 1024字节)
• 磁盘路径:(user home directory)/Library/Caches/(application bundle id)

• Memory capacity: 4 megabytes (4 * 1024 * 1024 bytes)
• Disk capacity: 20 megabytes (20 * 1024 * 1024 bytes)
• Disk path:(user home directory)/Library/Caches/(application bundle id)

没有特殊缓存要求或约束的用户 应该找到可接受的默认共享缓存实例.如果这 默认共享缓存实例不可接受，+setSharedURLCache: 可以调用以设置要返回的其他NSURLCache实例 从这种方法.呼叫者应注意确保设置者 在没有其他调用者引用该调用者的时间被调用 先前设置的共享URL缓存.这是为了防止存储缓存数据 避免变得无法挽回.

Users who do not have special caching requirements or constraints should find the default shared cache instance acceptable. If this default shared cache instance is not acceptable, +setSharedURLCache: can be called to set a different NSURLCache instance to be returned from this method. Callers should take care to ensure that the setter is called at a time when no other caller has a reference to the previously-set shared URL cache. This is to prevent storing cache data from becoming unexpectedly unretrievable.

或文档

响应大小足够小，可以合理地放入缓存中. (例如，如果您提供磁盘缓存，则响应[数据]不得大于磁盘缓存大小的 5％.)

_{我自己包括了数据}

所以我认为我的理由是正确的.

So I'm thinking my rationale is right.

读取/写入/还原缓存的整个过程如何工作?

How does the overall process work of reading/writing/restoring of cache work?

1. 我的意思是，当我第一次发出网络请求时，是不是整个响应/错误/数据都被写入/存储在缓存中，然后持久化?

1. I mean when I make a network request for the first time then is it that the entire response/error/data gets written/stored in cache and then into persistence?

下次，如果我想阅读，那么它首先从缓存开始，然后，如果响应不是陈旧/过期，它将返回它.磁盘存储没有任何变化.

Next time if I want read then it first starts from the cache then if the response was not stale/expired then it will return it. Nothing would change for disk storage.

如果它已过期，它将仅在以下情况下发出新请求 获得成功的响应后，它将清除内存和磁盘中的响应，并将新的响应写入缓存和磁盘中.如果是新的 请求失败，则不会清除，而只会保留 陈旧/过期的数据，因此如果我们想要(加载过期的响应) 会从那里加载吗?

If it was expired then it would make a new request and only upon getting a successful response, it would purge the response from memory and disk and write the new response into cache and disk. If the new request failed then it won't purge, rather it would just keep stale/expired data so if we wanted (to load expired response) it would load from there?

当应用终止时，内存将被清空.除非设备内存不足或达到大小限制，否则磁盘存储将保持不变.下次启动应用程序时，内存会将磁盘存储中的所有内容重新加载到缓存中.

And when app is terminated the memory is flushed out. Disk storage is left intact unless device was low on memory or you've reached size limit. Upon next launch of app, the memory reloads whatever's in the disk storage into the cache.

此缓存还原将开始加载最新的数据 存储，然后移动到较旧的数据，直到它 达到其大小限制或仅达到存储在其中的项目的末尾 磁盘.对吧?

This cache restoration will start loading the latest data is has stored then move onto the data that was older until it either reaches its size limit or just reach the end of the items stored on the disk. Right?

我之所以问所有这些问题，是因为我想改善应用程序的缓存体验并提高我的整体了解，因此我不会过多增加应用程序的内存使用率*，以免将其从应用程序中清除掉.由于我的应用程序内存使用率过高或需要其他应用程序，因此内存从挂起状态开始运行.

I'm asking all this because I want to improve the caching experience in an app and improve my overall understanding so I won't increase the memory usage* of the app too much so it won't get flushed out of the memory from its suspended state due my apps high memory usage or other apps being in need.

*:我们的某些网络请求将下载缩略图，因此在增加缓存大小限制时需要体谅.

*: some of our network requests will be downloading thumbnails, so I need to be considerate when I'm increasing my caching size limit.

推荐答案

如果您想深入了解内存管理，则应该深入研究较低级别的API. URLSession，URLCache等是非常高级的API.关于存储帧，图像缓存，网络缓存等，有很多WWDC会话.每个部分都有很多说明.我建议您观看所有WWDC视频(如果尚未观看)以进行启动和热身.一些主题对这样的核心概念有很好的解释.

If you want to get to know deep about memory management, you should dive into lower level APIs. URLSession, URLCache and etc. are very high level APIs. There are plenty of WWDC sessions out there about memory frames, Image caching, network caching and etc. Each part has a lot of explanation. I'm suggesting you to watch all WWDC videos (if you hadn't) for start and warm up. Some of theme has great explanation about the core concepts like this.

从今年的WWDC中查看以下两项:

check out these two from this year WWDC:

图像和图形最佳做法

iOS内存深入研究

我们可以坐在这里讨论您的问题几个星期！但为了快速回答:

We can sit here and discuss about your questions for weeks! But for quick answer:

1. 是的.由于内存大小限制了内存，由于存储大小限制了磁盘.设备和iOS可以根据需要最大限度地发挥作用.
确实，这是使用磁盘的主要目标之一.有一个名为交换内存的概念(如果需要，可以进行更多调查和研发)

1. Yes. Memory limited due the ram size and disk limited due the storage size. The device and iOS can play with the maximum limit a bit due their needs.
2. Exactly and this is one of the main goals of using disk. There is a concept named Swap Memory (for more investigate and R&D if you want)

压缩数据临时移至磁盘，以在内存中为最近使用的数据腾出空间

Compressed data temporarily moved to disk to make room in memory for more recently used data

但是内存在其帧中拥有自己的缓存.有时缓存会降低性能，而不是提高性能.因为它是框架.

But memory has it own cache in its frames. Sometimes caching reduce performance instead of improving it. Because of it's frames.

1. 并非总是如此.默认情况下，仅成功请求将被缓存(如果服务器未请求客户端在标头中不对其进行缓存").但是，您可能知道，URLSession具有大量配置，可以在非常高级的API中对磁盘，内存等进行缓存.请参阅URLSession文档.

1. Not always. By default, only success requests will cache (If server not requested the client to "don't cache it" in the header). But as you may know, URLSession has plenty of configuration for caching on disk, memory and etc. in a very high level API. See URLSession Documentation.

请参阅 NSURLRequestCachePolicy 文档.而根据您选择的策略，它的行为有所不同，可以清除先前的缓存或将其保留到下一次成功.

See NSURLRequestCachePolicy documentation. And Based on the policy you chose, it behaves different and can purge the previous cache or keep it until next success.

HomeDirectory 包含一些主目录. iOS的行为各不相同. iOS只会清理 tmp 目录(磁盘缓存所在的目录).您可以将缓存存储在其他目录(例如 Documents )中，以防止iOS将其删除.但是重点是 cache 单词本身的含义.

The HomeDirectory contains some main directories. iOS behaves differently with each one. iOS will only clean the the tmp directory (where the disk cache lives). You can store cache in a different directory like Documents to prevent iOS from removing it. But the point is the meaning of the cache word itself.

根据实际需要分配更少的空间甚至更多的空间都是至关重要的.它可能破坏进程或浪费内存/磁盘.还记得链接列表发明的原因吗?您可以为不同的目的使用不同的缓存，例如图像和JSON.但是关于图像的重点是:

Any less space or even more space from the actual need is critical. It can corrupt the process or waste the memory/disk. Remember the reason of link lists invention? You can have different caches for different purposes like images and JSONs. But the point about images is:

这些都是Foundation框架的核心，所有已知的第三方都只是它们的包装.因此，它们唯一的好处是:基于数千位贡献者的知识和更高级别的API的预定义默认值.

These are all at the heart of the Foundation framework and all known third parties are just wrappers around them. So the only benefits they have are: Predefined defaults based on the thousands of contributors knowledge and higher level APIs.

Alamofire 和 结论

正确的缓存大小取决于用例.取决于数据变量的数量，图像数量，每个图像的大小，访问同一图像的频率等，例如，如果您不断更改缓存中的图像，则实际上可能会对电池寿命产生不利影响！决定合适的缓存大小的最佳方法是进行测试.在仪器"下运行该应用程序以测量性能和电池使用情况.继续增加缓存大小，直到无法分辨出性能差异.至少在测试条件下，这是您所需的最大尺寸.然后减小尺寸，直到性能勉强可以接受为止，以确定最小的可接受尺寸.正确的大小介于这两个大小之间，具体取决于您认为重要的内容.

The right cache size depends on the use case. Depends on number of data variants, images count, size of each image, how often is the same image accessed and etc. for example if you are constantly changing the image in the cache, it could actually have an adverse effect on the battery life! The best way to decide on an appropriate cache size is to test. Run the app under Instruments to measure both performance and battery usage. Keep increasing the cache size until you can't discern a difference in performance. That's the largest size you'd need, at least under the test conditions. Then reduce the size until performance is just barely acceptable to determine the smallest acceptable size. The right size is somewhere between those two sizes, depending on what you think is important.

这篇关于如何设置iOS缓存和磁盘存储大小，以及在应用终止后如何从磁盘存储中还原缓存?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！