A new member of the Cache family, The Cache, has been genetically reprogrammed by Google and Firefox, possibly in consideration of the birth defects of Application Cache and LocalStorage. But the two sides disagreed on how to reorganize it, so they built it separately.

Chromium Cache API designers have identified the Cache API as “a new Application caching mechanism for ServiceWorker” and they have identified the Cache API as the Application Cache (although there are significant flaws in the offline Cache design, But the code is at least innocent), it’s easy to see why Chromium’s internal Cache API implementations reuse a lot of Application Cache code, using the same Temporary storage type, Use the same storage Backend (Very Simple Backend).

The Firefox Cache API designer described his idea in a blog post, initially to reuse the HTTP Cache or implement it based on IndexedDB, but the Cache API specification has evolved and some of the specification details conflict irreconcilably with this solution. For example, in the HTTP Cache, a URL can only correspond to one Response, but the Cache API specification requires that the same URL (different headers) can correspond to multiple responses. HTTP Cache does not use a capacity management system (QuotaManager) that the Cache API does. IndexedDB is based on structured cloning and does not support streaming data, so the Response can be very large and slow coming back from the network, significantly increasing memory usage. For this reason, Firefox decided to implement a new storage mechanism for the Cache API based on SQLite.

You need to know about CacheStorage

Cache object management by CacheStorage in W3C specification, CacheStorage ServiceWorkerCacheStorage object corresponding to the kernel. It provides a number of JS interfaces for manipulating Cache objects:

  • Cachestorage.open () is used to get an instance of a Cache object.
  • Cachestorage.match () checks whether a Cache object with Request as the key exists in the CacheStorage.
  • Cachestorage.has () checks for the existence of a Cache object with the specified name.
  • Cachestorage.keys () returns the cacheName list of all Cache objects in CacheStorage.
  • Cachestorage.delete () Is used to delete the Cache object of the specified cacheName.

Pay attention to the following situations:

  • Any CacheStorage method calls, all have the opportunity to create ServiceWorkerCacheStorage object.
  • A cache_storage_map_ ServiceWorkerCacheStorageManager maintenance (STD: : map < GURL, ServiceWorkerCacheStorage * >), This map all the origin + ServiceWorkerCacheStorage management.
  • Any domain name (for example, origin: https://chaoshi.m.tmall.com/) will only create a ServiceWorkerCacheStorage object.
  • A cache_map_ ServiceWorkerCacheStorage maintenance (STD: : map < STD: : string, base: : WeakPtr < ServiceWorkerCache > >). This map manages all cacheName + ServiceWorkerCaches in the same Origin.
  • ServiceWorkerCacheStorage under the same domain names are in the same directory, directory path storage_path: / / data/data/com. UCMobile app_core_ucmobile/Service Worker/CacheStorage / 8 f9fa7c394456a3f75c7c0aca39d897179ba4003. Eight f9fa7c394456a3f75c7c0aca39d897179ba4003 is origin (chaoshi.m.tmall.com/) hash value.

What can the front end learn from these situations? The storage of resources is not handled according to the domain name of the resource, but according to the origin of the Service Worker. Therefore, Cache resources cannot be shared across domains. That is, Service workers in different domains cannot share each other’s Cache. Even cross-domain resources requested by Foreign Cache are also stored under origin. Because ServiceWorkerCache marks the cache version by cacheName, there are multiple versions of ServiceWorkerCache resources. Why do YOU need cacheName to mark the version?

Assume that all overwrite published static resources and interface data under the current domain name are stored in the same cacheName. After service deployment is updated, redundant resources cannot be identified and cannot be completely removed by the front-end. This is because the Service Worker does not know the complete static resource path table and can only make a judgment when the client initiates a request. Resources that are not currently used do not necessarily mean that they will not be used in the future. If static resources are published without coverage, there are even more redundant resources. It is important to note that the Cache does not expire and can only be explicitly deleted

If you replace the cacheName after a version update, it means that the old cacheName resources are no longer used. The business logic can remove all resources of the old cacheName without knowing the full static resource path table.

Is that only the case with cacheName? Vender, for those of you who have used WebPack, is designed to pack together the library files of the third party that are least frequently changed, so as to avoid packing with the resources that are frequently updated, so as to improve client cache utilization, and the common configuration. By packaging common components together to reduce code redundancy, cacheName can also be configured to maximize cache space and cache utilization.

As the underlying storage of the Service worker-related cache uses the File System of the System, which generally does not support multi-process access, two different Service workers under a unified domain cannot operate on the same resource at the same time.

You need to know more about Cache

In the specification, Cache corresponds to ServiceWorkerCache in the kernel and provides a storage and management mechanism for cached Request/Response objects. It provides a series of JS interfaces for managing storage:

  • Cache.put() is used to put the Request/Response object body into the specified Cache.
  • Cache.add() retrieves a Response from a Request and places the body of the Request/Response object in the specified Cache. Note: Equivalent to fetch(request) + Cache. Put (request, response)
  • Cache.addall () is used to retrieve a Response from a group of requests and place the group of Request/Response objects in the specified Cache.
  • Cache.keys() is used to retrieve all keys in the Cache.
  • Cache.match() checks whether a Cache object with Request as its key exists.
  • Cache.matchall () is used to find if there is a Cache object group with Request as the key.
  • Cache.delete() is used to delete the Cache Entry with Request as the key. Note that the Cache does not expire and can only be explicitly deleted.

ServiceWorkerCache corresponding storage directory is/data/data/com UCMobile/app_core_ucmobile/Service The Worker/CacheStorage / 8 f9fa7c394456a3f75c7c0aca39d897179ba4003/7353 b21ee437f3877043ae17a5d5ba6395fdbd31, Which is 7353 b21ee437f3877043ae17a5d5ba6395fdbd31 cacheName (tm/chaoshi – fresh / 4.2.17) hash value (using base: : SHA1HashString calculation). The same resource name will be stored separately if the cacheName is different.

As for the storage path, it must be related to the size of the storage. The ServiceWorker specification does not specify the size limit of ServiceWorkerCache, which is limited to 512 MEgabytes in the kernel version below Chromium 50. Chromium 50 and above have no restrictions (STD :: Numeric_limits <int>:: Max). Of course, this is only limited at the Service Worker level, and it is also limited by the browser QuotaManager.

QuotaManager also has a limit on the available storage space per domain name. The algorithm (Chromium57) can be simply described as follows:

Temporary Storage quota = [available system disk space (available_disk_space) + Global_limited_usage] / 3 KTemporaryQuotaRatioToAvail = 3)

Each domain name can use Temporary type storage limit = Temporary storage limit / 5 (note: QuotaManager: : kPerHostTemporaryPortion = 5)

For example, if the available space of the system disk is 570 MB and the globally used space of the browser is 30 MB, the Temporary storage quota for each domain name is (570+30) / 3/5 = 40 MB. Although ServiceWorkerCache has a very large limit of 512 MB at the ServiceWorker level, it cannot exceed the limit of 40 MB per domain name. That is, ServiceWorkerCache can only use 40 MB for the same domain name.

Generally speaking, the ServiceWorker level limits ServiceWorkerCache more than the browser limits each domain name, so it can be interpreted as: ServiceWorkerCache is only limited by the storage available for a domain name by browser QuotaManager. For the front-end development students, there must be a business logic to clear the redundant cache, and improve the utilization of cache resources.

When the Service Worker cannot get a resource from the Cache, it searches the HTTP Cache and requests the network if it cannot find it.

Currently, the use of Cache API is limited, and I will continue to supplement it after accumulating experience.