Method and system for managing cache of large files automatically cached by a browser

Abstract

This application provides a method and system for managing large file caches automatically in a browser, relating to the field of cache management technology. This application intercepts resource requests and generates resource descriptors during the loading of a 3D geographic information scene. Based on browser type, resource type, network caching policy, and storage quota, it determines the automatic caching threshold and target resource data volume to identify resources exceeding the threshold. A scene dependency pool containing necessary resources for the first screen and expected resources for adjacent view areas is generated according to scene dependency identifiers. Resources exceeding the threshold are fragmented and written to the browser database to form shadow cache records. By combining address keys, version verification information, resource-level integrity bitmaps, and fragment-level integrity bitmaps, it performs hit reconstruction, missing data filling, changed fragment replacement, and pool-level eviction. This improves the caching recoverability of large file resources on the browser side, the stability of first-screen loading, version update efficiency, and capacity management accuracy.

Description

Technical Field

[0001] This application relates to the field of cache management technology, and in particular to a method and system for managing large file caches automatically cached by a browser. Background Technology

[0002] When loading a 3D scene, a 3D geographic information browser client typically requests files such as 3D tiles, terrain tiles, models, textures, point of interest (POI) aggregated data, and resource lists. These resources are characterized by large file sizes, strong hierarchical dependencies, and high sensitivity to the first screen display. Furthermore, they are susceptible to issues such as unstable caching, duplicate downloads, or missing resources required for the first screen display, due to the browser's native caching strategy, cache control fields, cross-domain readability, storage quotas, and the browser's internal eviction mechanisms.

[0003] In the prior art, Chinese patent application CN105022731A discloses a method for caching map vector tiles. This method improves map rendering flexibility and user experience by calculating the map data resolution range, linearly dividing it into tiles, removing redundant data, and packaging it into cached map vector tiles. However, this solution primarily focuses on the tile organization of map vector data at different resolutions and the generation of cached data. It does not address the issue of large file resources in browser clients that exceed the stable range of automatic caching by establishing a shadow cache record based on a scene-dependent pool, nor does it provide resource-level integrity bitmaps, tile-level integrity bitmaps, missing data filling, changed tile replacement, or pool-level eviction mechanisms.

[0004] Furthermore, conventional browser caching typically relies on response fields such as Cache-Control, ETag, and Last-Modified to determine resource reusability. While this mechanism is suitable for caching and revalidation at a single response level, in 3D geographic information scenarios, strong dependencies exist between essential resources for the first screen, expected resources in adjacent viewports, model-level resources, and texture references. If relying solely on native browser caching, the system struggles to determine if a 3D scene is recoverable and to retrieve only the missing fragments when resources are partially missing. Therefore, a cache management solution is needed that can identify resources exceeding thresholds, organize cache objects according to 3D scene dependencies, and perform fragment persistence and integrity management in the browser database. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for managing large file caches automatically cached by the browser, so as to solve the problems of unstable caching, repeated downloads, or missing essential resources on the first screen in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides a method for managing large file caches automatically cached by a browser, comprising: When loading a 3D geographic information scene on a browser client, resource requests are intercepted and a resource descriptor is generated. The resource descriptor includes a normalized address, resource type, version identifier, and scene dependency identifier. The automatic caching threshold is determined based on the browser type, the resource type, the network caching policy, and the current storage quota. The target resource data volume corresponding to the resource descriptor is determined according to the priority order of the resource data volume identifier source. When the amount of target resource data exceeds the automatic caching threshold, the resource is identified as an over-threshold resource, and a scene dependency pool containing the necessary resources for the first screen and the expected resources for adjacent view areas is generated according to the scene dependency identifier. An address key is generated based on the normalized address, the version identifier, and the scenario dependency identifier. The resources exceeding the threshold are written to the browser database in fragments to form shadow cache records. The shadow cache records include the address key, response metadata, version verification information, and resource-level and fragment-level integrity bitmaps. When a resource request is received again, the hit condition is determined based on the newly generated resource descriptor, the address key, the version verification information, and the integrity bitmap. If a hit is found, the resource data is reassembled according to the fragments and a cached response is constructed for the 3D geographic information engine to read. When a resource is not hit or the necessary resources for the first screen are incomplete, missing resource replacement is performed; when resources change, changed fragment replacement is performed; and when capacity is insufficient, pool-level elimination is performed according to the elimination score of the scenario dependency pool.

[0007] Optionally, generating the scene dependency pool and forming the shadow cache record includes: Resource dependencies are extracted from the resource organization information and visibility relationships of the 3D geographic information scene and a 3D resource dependency map is generated. The resource nodes corresponding to the current 3D geographic information scene are located according to the scene dependency identifier. The scene dependency pool is generated using the essential resources of the first screen of the current 3D geographic information scene and the expected resources of adjacent view areas as boundaries; Configure resource identifiers and cache management tags for resources within the scenario dependency pool; When the scene dependency pool contains the resource exceeding the threshold, the scene dependency pool is used as a writing unit. A secondary address key is established according to the address key, the resource identifier in the pool, and the fragment sequence number. The resource fragment, fragment verification value, response metadata, and version verification information are written to the browser database, and the resource-level integrity bitmap and the fragment-level integrity bitmap are updated synchronously. When a 3D geographic information scene belonging to the scene dependency pool is loaded again, the system first determines whether the necessary resources for the first screen are complete according to the resource-level integrity bitmap and the fragment-level integrity bitmap, and then determines whether to reconstruct the cached response, replenish missing resources, or roll back the server-side loading.

[0008] Optionally, determining the automatic caching threshold and the target resource data volume includes: Read the threshold benchmark corresponding to the browser type, the resource type, and the network caching policy; The automatic cache threshold is obtained by correcting the threshold benchmark based on the cache correction information; Prioritize parsing the trusted data volume identifier in the resource identifier information. The trusted data volume identifier is a data volume identifier that is consistent with the response header content length, resource list summary, or the version verification information. If the trusted data volume identifier is not parsed, the length of the content in the response header is read through the header information request; if the header information request is unavailable, the target resource data volume is recorded from the response header during the first download process, and the cache failure result is fed back to the historical cache failure record.

[0009] Optionally, writing the resources exceeding the threshold into the browser database in fragments includes: Determine the fragmentation boundaries based on the target resource data volume and resource fragmentation constraints; Configure fragment attribute information and write transaction number for each fragment; After the write operation is completed, the resource-level integrity bitmap is updated according to the resource identifier in the pool, and the fragment-level integrity bitmap is updated according to the fragment sequence number. If a write transaction is interrupted, the fragments that have passed the verification are retained and the fragments that have not been written are marked as missing fragments so that subsequent hit checks can trigger missing data filling.

[0010] Optionally, the two-level integrity bitmap includes the resource-level integrity bitmap and the fragment-level integrity bitmap; The resource-level integrity bitmap is used to indicate whether each resource in the scene dependency pool is complete, and the fragment-level integrity bitmap is used to indicate whether each fragment of a single resource is complete. When all resources corresponding to the required resource markers are in a complete state and the resources corresponding to the optional resource markers reach a preset proportion of complete optional resources, the scene dependency pool is marked as a recoverable pool. When the resource corresponding to the required resource tag is missing, the scenario dependency pool is marked as a replenishment pool, and a replenishment queue is generated based on the resource-level integrity bitmap, the fragment-level integrity bitmap, and the missing fragment.

[0011] Optionally, constructing the cached response includes: The resource request is received through the request takeover interface of the browser client or the resource provider of the 3D geographic information engine. When the normalized address, version identifier, and scene dependency identifier in the newly generated resource descriptor match the address key, and the scene dependency pool is the recoverable pool, the resource data is read and reassembled according to the fragment sequence number, and the reassembled resource data is combined with the response metadata to generate a cached response object for the 3D geographic information engine to read. The response metadata should retain at least the response base field and the version field.

[0012] Optionally, the version verification information includes server-side verification information, resource version information, and content summary information; When the shadow cache record expires, the version identifier is inconsistent with the version verification information, the resource list version number changes, or the scene dependency pool is changed from the recoverable pool to the pending pool, a verification request is sent to the server based on the version verification information. If the server-side resources remain unchanged, the validity period of the shadow cache record is extended. If server-side resources change, only the shards corresponding to the changed resources, the shard checksums, and the response metadata are replaced, and the resource-level integrity bitmap and the shard-level integrity bitmap are recalculated.

[0013] Optionally, the elimination score is jointly determined by access status information, view domain association information, pool integrity information, resource cost information, and user retention information; When performing the pool-level elimination, priority is given to eliminating scene dependency pools that are incomplete and do not contain the necessary resources for the first screen. Elimination of recoverable pools corresponding to the current view or adjacent view is delayed. When capacity needs to be released, optional resources or low-redownload-cost resources in the same scene dependency pool are deleted in groups.

[0014] Optionally, when a cache execution exception occurs, the corresponding resource is switched to server-side direct retrieval or browser native cache processing, and the resource descriptor, the scenario dependency identifier, the exception type, and the failure reason are retained; After the current storage quota is restored, the persistence authorization is successful, or the version verification conflict is resolved, the automatic cache threshold, the replenishment queue, or the eviction score is corrected according to the reason for the failure, and the shadow cache record is re-established or repaired.

[0015] Secondly, this application provides a browser-automatic caching large file cache management system, including: The request module is used to intercept resource requests and generate resource descriptors when the browser client loads a 3D geographic information scene; The identification module is used to determine the automatic caching threshold and the target resource data volume, and to identify resources that exceed the threshold; The pooling and archiving module is used to generate a scene dependency pool containing the necessary resources for the first screen based on the scene dependency identifier, and to configure the resource identifier and cache management flag in the scene dependency pool. The storage module is used to generate an address key based on the normalized address, version identifier and the scenario dependency identifier, and write the over-threshold resource into the browser database in segments to form shadow cache records; The management module is used to maintain resource-level integrity bitmaps and fragment-level integrity bitmaps, and generate a replenishment queue based on the resource-level integrity bitmaps and fragment-level integrity bitmaps; The response reconstruction module is used to determine the hit conditions based on the address key, version verification information and two-level integrity bitmap, and construct a cached response for the three-dimensional geographic information engine to read. The update module is used to perform missing data retrieval when a resource is missed or the required resources for the first screen are incomplete, to perform changed fragment replacement when resources change, and to perform pool-level eviction when capacity is insufficient.

[0016] The browser-automatic caching method for managing large files provided in this application intercepts resource requests and generates resource descriptors when the browser client loads a 3D geographic information scene. This unifies resource requests from different sources and with different formats under a standardized address, resource type, version identifier, and scene dependency identifier, preventing the same resource from being repeatedly identified due to different address parameters, version fields, or loading entry points. By determining the automatic caching threshold based on browser type, resource type, network caching policy, and current storage quota, and combining the source of the resource data volume identifier to determine the target resource data volume corresponding to the resource descriptor, it can identify potentially unstable large file resources in the browser's native cache before the resource enters the caching process, reducing reliance on the uncontrollable behavior of the native cache. By generating a scene dependency pool containing the necessary resources for the first screen and the expected resources for adjacent view areas based on the scene dependency identifier, cache management is no longer limited to a single file dimension, but is organized according to the set of resources required for 3D scene recovery, thereby prioritizing the display capability of the first screen and the continuous browsing capability of adjacent view areas.

[0017] Furthermore, by writing resources exceeding the threshold into the browser database in fragments and forming shadow cache records, large file resources can obtain an indexable, verifiable, and recoverable persistent storage structure on the browser side, reducing the waiting time and bandwidth consumption caused by re-downloading large files. By maintaining resource-level integrity bitmaps and fragment-level integrity bitmaps, it is possible to determine whether resources in the scene dependency pool are complete and whether fragments of individual resources are complete, providing a clear basis for subsequent hit judgments, missing data filling, and first-screen integrity determination. By reconstructing the cache response based on the address key, version verification information, and integrity bitmap when receiving resource requests again, cached resources can be read without the 3D geographic information engine needing to be aware of the underlying shadow cache structure, improving the compatibility of cache reuse. By performing missing data filling, changed fragment replacement, and pool-level eviction when there is a miss, resource change, or insufficient capacity, respectively, it is possible to avoid re-downloading the entire package and indiscriminate cleanup, ensuring that cache repair, version updates, and capacity release are all matched with the 3D scene dependency relationship. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a browser-automatic file cache management method provided in this application embodiment; Figure 2 A three-dimensional resource dependency graph provided for embodiments of this application; Figure 3 This is a schematic diagram of the structure of the resource-level integrity bitmap and the fragment-level integrity bitmap provided in the embodiments of this application; Figure 4 This is a schematic diagram of a browser automatic caching large file caching management system provided in an embodiment of this application. Detailed Implementation

[0020] The applicant noted that the failure of large file caching in the 3D geographic information browser client is not a matter of whether a single file is saved by the browser, but rather a result of the combined effects of the browser's native caching strategy, resource size, scene dependencies, resource version, and storage quota. If cache hits are judged solely based on a single URL, the browser may have already saved some resources, but the resources required for the first screen may still be incomplete; it is also possible that some large files are repeatedly downloaded because they exceed the browser's automatic caching stability range. Therefore, this application first converts ordinary resource requests into manageable resource objects, then determines whether they belong to resources exceeding the threshold, and establishes shadow cache records according to scene dependencies when they are resources exceeding the threshold.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] like Figure 1 As shown in the diagram, S101 to S108 represent the processing order of resource requests by the browser client. S101 corresponds to resource request interception and resource descriptor generation, S102 corresponds to the determination of the automatic cache threshold and the target resource data volume, and S103 is the judgment node for whether the target resource data volume exceeds the automatic cache threshold. When the judgment result of S103 is negative, the resource enters the browser's native cache or is loaded on the server side; when the judgment result of S103 is positive, the process proceeds to S104, where the browser client generates the scenario dependency pool. S105 represents address key generation and shard writing to the database, S106 represents hit condition judgment, S107 represents reorganizing resource data and constructing a cached response, and S108 represents performing missing data filling, changed shard replacement, or pool-level eviction when there is a miss, resource change, or insufficient capacity.

[0023] During the resource request takeover and threshold identification phase, when the browser client loads the 3D geographic information scene, it intercepts resource requests and generates resource descriptors, which include a normalized address, resource type, version identifier, and scene dependency identifier. Based on the browser type, resource type, network caching policy, and current storage quota, it determines the automatic caching threshold and determines the target resource data volume corresponding to the resource descriptor according to the priority order of the resource data volume identifier source. When the target resource data volume exceeds the automatic caching threshold, the resource is identified as an over-threshold resource.

[0024] In practice, resource requests can be received via browser background request interception events (Service Worker's fetch event), or via network request wrappers (fetch wrappers), asynchronous request wrappers (XHR wrappers), or the resource provider of the 3D geographic information engine. After receiving a resource request, the browser client generates a resource descriptor. The normalized address can be formed using a unified protocol, hostname, path hierarchy, and necessary query parameters, removing tracking parameters, timestamp parameters, or session parameters irrelevant to the resource entity. The resource type can be determined based on the file extension, content type in the response header, resource manifest declaration, and the 3D geographic information engine's loading context. The version identifier can be obtained from the address version number (URL version number), resource manifest version number, filename version number, entity tag (ETag), last-modified time (Last-Modified), or content digest. Scene dependency identifiers can be generated based on the scene entry address, layer identifier, 3D tile root node, terrain dataset identifier, initial viewport extent, or scene number within the project.

[0025] When determining the automatic caching threshold, the browser client first reads the threshold baseline corresponding to the browser type, resource type, and network caching policy (HTTP caching policy), and then adjusts the threshold baseline based on cache correction information. Cache correction information may include the current storage quota, historical cache failure records, the cost of re-downloading in the scenario dependency pool, and user offline retention flags. The automatic caching threshold is used to distinguish between ordinary resources that can continue to be stably handled by the browser's native cache and large file resources that need to enter the shadow caching process.

[0026] As an example, when the mobile device or current storage quota is low, the threshold benchmark can be taken in the range of 16MB to 64MB; when the desktop device or current storage quota is sufficient, the threshold benchmark can be taken in the range of 64MB to 512MB; fragmented resources such as 3D tiles and terrain tiles can take a lower range, while continuous large files such as models and textures can take a higher range. The lower the automatic caching threshold, the more resources enter the shadow caching process, improving cache recoverability but increasing write transactions and address key maintenance; the higher the automatic caching threshold, the fewer resources enter the shadow caching process, increasing the burden on the browser's native cache. If the browser's remaining available quota is low, or if historical cache failure records show that the same type of resource has not been stably saved multiple times, the automatic caching threshold can be lowered to allow such resources to enter the shadow caching process earlier.

[0027] The source of resource data volume identification can include request headers, response headers, server filenames, and resource lists. When the target resource data volume is determined, the data volume identifier in the request header is parsed first; if no usable data volume identifier is found in the request header, the content length in the response header is read; if the response header content length is missing or unreadable, the data volume identifier in the server filename is parsed; if it still cannot be obtained, the data volume identifier in the resource list is read. Resource identification information can be formed from the server filename, address parameters, or resource lists. If a reliable data volume identifier is not parsed from the resource identification information, the content length in the response header can be read through a HEAD request; if a HEAD request is unavailable, the target resource data volume can be recorded from the response header during the initial download process, and the caching failure result can be fed back to the historical caching failure record.

[0028] When the target resource data volume exceeds the automatic caching threshold, the browser client identifies the resource as an over-threshold resource. Over-threshold resources are not written directly to the browser database as orphan files. Instead, they are processed along with a resource descriptor, target resource data volume, resource type, version identifier, scenario dependency identifier, and network caching policy. This allows for subsequent resource organization according to the scenario dependency pool, writing to the browser database in fragments, and determining recoverability based on the integrity bitmap.

[0029] During the scene dependency pool generation phase, the browser client generates a scene dependency pool containing essential resources for the first screen and expected resources for adjacent viewports based on scene dependency identifiers. Specifically: resource dependencies are extracted from the resource organization information and visibility relationships of the 3D geographic information scene, and a 3D resource dependency map is generated; resource nodes corresponding to the current 3D geographic information scene are located based on scene dependency identifiers; a scene dependency pool is generated with the essential resources for the first screen and expected resources for adjacent viewports of the current 3D geographic information scene as boundaries; and resource identifiers and cache management tags are configured for the resources within the scene dependency pool.

[0030] like Figure 2 As shown, the dashed box on the left represents the source of dependencies, listing the 3D tile list, terrain tile index, model hierarchy, texture references, point of interest (POI) aggregation, bounding volume relationships, and view frustum visibility relationships. The central node represents the current scene resource node, and the dashed box on the right represents the boundary of the scene dependency pool, divided into resources required for the first screen and expected resources in adjacent view areas. The connecting lines in the figure indicate that after extracting resource relationships from the dependency source, the current scene resource node is located, and the scope of the scene dependency pool is determined by the first screen boundary and the adjacent view area boundary. Figure 2 This is used to illustrate the correspondence between resource dependencies and the boundary of the scenario dependency pool, and does not represent the steps or process.

[0031] In practice, after obtaining the resource exceeding the threshold, the browser client first determines the 3D geographic information scene in which the resource is located based on the scene dependency identifier. The scene dependency identifier can correspond to the 3D tile root node, terrain dataset, model layer, initial view range, or a scene entry point formed by multiple layers. Through this identifier, the browser client can associate the current resource exceeding the threshold with other resources in the same loading scene, avoiding the inability to restore the complete first screen by saving only a single large file.

[0032] The browser client extracts dependencies from existing resource organization information. The 3D tile list reflects parent-child tiles, hierarchical refinement, and spatial bounding volume relationships; the terrain tile index reflects the adjacency relationships of terrain data at different levels, row and column numbers, or spatial extents; the model hierarchy reflects the calling relationships between the root model, child models, and level-of-detail (LOD) models; texture reference relationships reflect the dependencies of model files on textures, material files, or texture compression files; point-of-interest (POI) aggregation relationships reflect the relationships between point-of-interest data and view extent, scale, or aggregation level; and bounding volume relationships and view frustum visibility relationships reflect whether a resource will be rendered in the current first screen or adjacent view areas.

[0033] The browser client generates a 3D resource dependency graph based on the aforementioned dependencies and locates the current scene resource nodes within the graph. Subsequently, the browser client determines the essential resources for the initial screen and the expected resources for adjacent viewports. Essential resources for the initial screen are those resources that need to be prioritized when the current 3D geographic information scene is first displayed, such as the root 3D tile, terrain tiles within the initial screen's view frustum, the main model of the initial screen, basic textures, initial screen point of interest (POI) aggregation data, and a necessary resource list. Expected resources for adjacent viewports are resources that are predicted to be requested in the short term based on the current viewpoint, camera movement direction, zoom level, scene adjacency relationships, or the user's historical browsing path.

[0034] The boundary of the scene dependency pool is jointly defined by the resources required for the first screen and the expected resources for adjacent view areas. If the boundary is too narrow, even a small amount of view movement outside the first screen may trigger a re-download; if the boundary is too wide, too many remote resources will enter the same scene dependency pool, consuming browser database capacity and increasing the cost of subsequent eviction checks. Therefore, the browser client can comprehensively determine the scope of the scene dependency pool based on the current view area, adjacent view areas, resource level, and storage quota. After the scene dependency pool is formed, the browser client configures resource identifiers and cache management tags for the resources in the pool. Cache management tags can include required resource tags, optional resource tags, re-download costs, and version tags, enabling subsequent fragment writing, integrity checks, replenishment, and eviction to be performed on a scene dependency pool basis.

[0035] During the fragment writing and shadow cache record formation phases, the browser client generates an address key based on the normalized address, version identifier, and scenario dependency identifier. When there are resources exceeding the threshold in the scenario dependency pool, the scenario dependency pool is used as the writing unit, and a secondary address key is established according to the address key, the resource identifier in the pool, and the fragment sequence number. The fragment boundaries are determined based on the target resource data volume and resource fragment constraint information. The byte range, fragment sequence number, fragment check value, and write transaction number are configured for each fragment. The resource fragment, fragment check value, response metadata, and version check information are written to the browser database, and the resource-level integrity bitmap and fragment-level integrity bitmap are updated synchronously.

[0036] Address keys are used to distinguish resources corresponding to different normalized addresses, versions, and scenario dependencies. Secondary address keys further introduce resource identifiers and fragment numbers within the pool, ensuring that each resource fragment in the browser database corresponds to a specific scenario, resource, and fragment. When determining fragment boundaries, the target resource data volume is used to determine the overall divisible range of the resource. Resource fragment constraint information can include resource type, network chunking status, 3D geographic information engine loading granularity, and required resource markers. Specifically, resource type distinguishes between 3D tiles, terrain tiles, models, textures, or resource lists; network chunking status reflects whether the server supports chunked transmission or byte-range requests; 3D geographic information engine loading granularity matches fragment boundaries with engine reading habits; and required resource markers ensure that resources required for the first screen have higher processing priority during writing and retrieval.

[0037] Once the fragment boundaries are determined, the browser client configures fragment attribute information and write transaction numbers for each fragment. The byte range determines the fragment's position in the resource data, the fragment sequence number maintains the fragment reassembly order, the fragment checksum determines whether the fragment is complete after being written or read, and the write transaction number distinguishes different write processes. Subsequently, the browser client writes the resource fragment, fragment checksum, response metadata, and version verification information to the browser database using the second-level address key, forming a shadow cache record.

[0038] If a write transaction is interrupted, the browser client retains the fragments that have passed verification and marks the fragments that have not been written as missing fragments. The fragments that have passed verification continue to be saved as part of the shadow cache record, and the fragments that have not been written are included in the scope of subsequent missing fragment checks. Through this process, a write interruption will not cause the entire completed fragments to be discarded, and subsequent hit checks can also trigger missing fragment checks based on the missing status.

[0039] During the integrity management and cache response reconstruction phases, the two-level integrity bitmap includes a resource-level integrity bitmap and a fragment-level integrity bitmap. The resource-level integrity bitmap indicates whether each resource in the scene dependency pool is complete, while the fragment-level integrity bitmap indicates whether each fragment of a single resource is complete. When all resources corresponding to the required resource markers are in a complete state, and the resources corresponding to the optional resource markers reach a preset percentage of complete optional resources, the browser client marks the scene dependency pool as a recoverable pool. The percentage of complete optional resources can be set according to scene complexity, continuous browsing requirements of adjacent view areas, and current storage quotas, and can range from 50% to 95%. The higher the percentage, the stronger the continuous browsing capability after the scene dependency pool is restored, but the higher the cost of replenishment and storage; the lower the percentage, the faster the first screen recovery speed, but the probability of re-requesting resources when loading adjacent view areas increases. When resources corresponding to the required resource markers are missing, the browser client marks the scene dependency pool as a replenishment pool and generates a replenishment queue based on the resource-level integrity bitmap, the fragment-level integrity bitmap, and the missing fragments.

[0040] like Figure 3 As shown, the table on the left represents resources in the scenario dependency pool and their required or optional resource markers, while the table at the top center represents the resource-level integrity bitmap. In the bitmap, 1 indicates completeness, and 0 indicates missing. When the corresponding bit for resource R03 is 0, it corresponds to the R03 fragment-level integrity bitmap. In the R03 fragment-level integrity bitmap, the corresponding bits for fragments P02 and P05 are 0, therefore the replenishment queue on the right records R03-P02 and R03-P05. This diagram illustrates that the resource-level integrity bitmap is first used to determine resource completeness, then the fragment-level integrity bitmap is used to locate missing fragments, and a replenishment queue is generated accordingly.

[0041] In practice, the resource-level integrity bitmap can be arranged according to the resource identifiers in the scenario dependency pool, with each bit corresponding to a resource identifier in the pool. The fragment-level integrity bitmap can be arranged according to the fragment sequence number of a single resource, with each bit corresponding to a fragment sequence number. Whenever a resource fragment is written, passes fragment verification, is filled in for missing fragments, is replaced by a changed fragment, or is evicted, the browser client synchronously updates the corresponding integrity bitmap. If all fragments of a resource are complete, the corresponding bit in the resource-level integrity bitmap is updated to complete; if any fragment is missing or fails verification, the resource remains in an incomplete state.

[0042] Upon receiving a resource request again, the browser client generates a new resource descriptor and determines the address key based on the canonical address, version identifier, and scene dependency identifier. If the canonical address, version identifier, and scene dependency identifier in the newly generated resource descriptor match the address key, and the version verification information is valid and the integrity bitmap meets the reading conditions, a hit is determined. After a hit, the browser client reads and reassembles the resource data according to the fragment sequence number, combines the reassembled resource data with the response metadata, and generates a cached response object. The cached response object can be represented as a browser response object (Response object), a binary resource address (Blob URL), a binary buffer object (ArrayBuffer object), or a resource provider readable object. The basic response fields can include content type, status code, cache control fields, and byte range fields. The version field is used to retain resource version information; the cached response object is available for the 3D geographic information engine to read.

[0043] If the address key matches but the scene dependency pool is a pending retrieval pool, the browser client does not directly use that scene dependency pool as the source of the complete cached response. Instead, it generates a retrieval queue based on the resource-level integrity bitmap, the fragment-level integrity bitmap, and the missing fragments. If the necessary resources for the first screen are incomplete and cannot be retrieved temporarily, the browser client falls back to server-side loading to ensure that the 3D geographic information scene can still continue to load.

[0044] During the version verification and change fragment replacement phase, version verification information includes server-side verification information, resource version information, and content summary information. Server-side verification information may include entity tags (ETag) and last-modified time (Last-Modified), while resource version information may include the resource manifest version number and filename version number. When a shadow cache record expires, the version identifier is inconsistent with the version verification information, the resource manifest version number changes, or the scene dependency pool changes from a recoverable pool to a pending pool, the browser client initiates a verification request to the server based on the version verification information. The validity period can be set according to the resource type and the frequency of resource changes, ranging from 5 minutes to 30 days; shorter validity periods can be used for resource manifests and indexes with high change frequencies, while longer validity periods can be used for stable resources such as models and textures. Shorter validity periods result in higher version timeliness but increase the number of verification requests; longer validity periods reduce network verification but increase the risk of using old version resources. If the server-side resources remain unchanged, the validity period of the shadow cache record is extended; if the server-side resources change, only the fragment, fragment checksum, and response metadata corresponding to the changed resources are replaced, and the resource-level integrity bitmap and fragment-level integrity bitmap are recalculated.

[0045] In practice, different resources can employ different version verification methods. The resource list can use the resource list version number; model or texture files with version numbers can use the filename version number; resources for which the server returns explicit verification fields can use entity tags (ETag) or last-modified timestamps (Last-Modified); and resources requiring precise content comparison can use content summaries. When the version identifier in the newly generated resource descriptor matches the version verification information in the shadow cache record, the browser client can continue to use that shadow cache record; when they do not match, the browser client first initiates a verification request to prevent older version fragments from being incorrectly reassembled into the current resource.

[0046] If the server-side verification result indicates that the resource has not changed, the browser client does not replace the already saved resource fragments, fragment checksums, and response metadata; instead, it extends the validity of the shadow cache record. If the server-side verification result indicates that the resource has changed, the browser client does not directly delete the entire scenario dependency pool; instead, it only replaces the fragments, fragment checksums, and response metadata corresponding to the changed resource. For resources that have not changed, the original fragments and integrity states can be retained. After the fragment replacement of the changed resource is completed, the browser client recalculates the fragment-level integrity bitmap corresponding to the resource and recalculates the resource-level integrity bitmap based on the integrity state of the resources in the pool.

[0047] When capacity is insufficient, browser clients perform pool-level eviction based on the eviction score of the scenario dependency pool. The eviction score can be determined based on principles commonly used in browser caching, database caching, and local caching, such as prioritizing recent access, prioritizing access from closer locations, and prioritizing those with higher re-download costs. Specifically, the browser client converts access status information, view domain association information, pool integrity information, resource cost information, and user retention information into sub-scores ranging from 0 to 100, with higher scores indicating greater suitability for capacity release. Access status information is determined based on the most recent access time; the longer the time since the last access, the higher the sub-score. View domain association information is determined based on view domain distance and the predicted probability of adjacent scenes; the farther from the current view domain and the lower the predicted probability of adjacent scenes, the higher the sub-score. Pool integrity information is determined based on the completeness of the scene dependency pool and whether it contains resources necessary for the first screen; incomplete scene dependency pools that do not contain resources necessary for the first screen have higher sub-scores, while recoverable pools corresponding to the current view domain or adjacent view domains have lower sub-scores. Resource cost information is determined based on re-download cost, total resource size, and resource type; the larger the total resource size and the lower the re-download cost, the higher the sub-score. User retention information is determined based on user offline retention flags; the presence of user offline retention flags lowers the corresponding sub-score. The weighted average of these sub-scores yields an elimination score, which serves as the ranking criterion for pool-level elimination.

[0048] For example, in a 3D geographic information scene, the elimination score can be calculated with the following weights: access status information 25%, view domain association information 30%, pool integrity information 20%, resource cost information 15%, and user retention information 10%. View domain association information has a higher weight because continuous browsing of a 3D geographic information scene typically relies on resources in the current view domain and adjacent view domains; access status information has a lower weight, used to prioritize releasing scene dependency pools that have not been accessed for a long time; pool integrity information is used to avoid prioritizing the deletion of scene dependency pools that can directly restore the first screen; resource cost information is used to balance releasing large capacity and avoiding high-cost re-downloading; and user retention information is used to reduce the elimination priority of user-specified offline retention resources. These weights can be adjusted according to the browser client's storage pressure, the 3D scene update frequency, and the user's offline usage needs.

[0049] During pool-level eviction, the browser client prioritizes eviction of incomplete scene dependency pools that do not contain resources essential for the initial screen. These pools cannot be directly used for initial screen recovery and do not contain resources that must be retained for the current recovery; therefore, their deletion has minimal impact on the immediate loading of the 3D geographic information scene. For recoverable pools corresponding to the current viewport or adjacent viewports, the browser client delays eviction to reduce the probability of re-downloading resources during continuous browsing. When it is necessary to release capacity but deleting the entire scene dependency pool is not advisable, the browser client can delete optional resources or low-re-download-cost resources in groups within the same scene dependency pool, and update the resource-level integrity bitmap and fragment-level integrity bitmap based on the deleted resources or fragments.

[0050] When a cache execution exception occurs, the browser client switches the corresponding resource to either direct server-side retrieval or native browser caching, retaining the resource descriptor, scenario dependency identifier, exception type, and failure reason. Browser database capacity anomalies can manifest as insufficient quota before writing, changes in capacity status during writing, or the browser database being unable to allocate further storage space. Persistence authorization failures can manifest as the browser rejecting the persistent storage request, or the user not granting the necessary storage permissions for offline retention. Unreadable cross-domain responses can manifest as the browser client being unable to read response headers, content length, or version verification fields. Missing content length can manifest as the response headers, server filename, and resource manifest failing to provide a reliable data volume identifier. Version verification conflicts can manifest as inconsistencies between the version identifier and the entity tag (ETag), last-modified time, resource manifest version number, filename version number, or content digest. Write transaction interruptions can manifest as some shards having been written while others have not.

[0051] When the above anomalies occur, the browser client does not force the continued execution of the shadow cache write or reconstruction process. Instead, it switches the corresponding resource to either server-side direct retrieval or browser native caching. Server-side direct retrieval ensures that the 3D geographic information scene can still load resources over the network; browser native caching is used to continue utilizing the browser's existing caching capabilities when shadow cache conditions are not met. After the current storage quota is restored, persistent authorization is successful, or version verification conflicts are resolved, the browser client adjusts the automatic cache threshold, replenishes the retrieval queue, or eviction score based on the cause of failure, and re-establishes or repairs the shadow cache record.

[0052] like Figure 4 As shown, the request module, identification module, pooling archiving module, storage module, browser database, management module, and response reconstruction module within the browser client are connected vertically in sequence, representing the processing relationship of resource requests from receiving, identifying, archiving, fragment writing, integrity management to constructing cached responses. The update module, located on the management module side, is used to repair shadow cache records in the browser database based on the replenishment queue, changed fragment replacement, or pool-level eviction results, and to verify or replenish records with the server when necessary. The response reconstruction module outputs the cached response to the 3D geographic information engine. Figure 4 This is a system architecture diagram. The connecting lines between the modules in the diagram represent the data or processing results transmission relationship, and do not require that each module be implemented as an independent physical component.

[0053] In one system implementation, the browser-automatic caching large file cache management system includes a request module, an identification module, a pooling and archiving module, a storage module, a management module, a response reconstruction module, and an update module. The request module intercepts resource requests and generates resource descriptors when the browser client loads a 3D geographic information scene. The identification module determines the automatic caching threshold and the target resource data volume, and identifies resources exceeding the threshold. The pooling and archiving module generates a scene dependency pool containing resources required for the first screen and expected resources in adjacent viewports based on scene dependency identifiers, and configures resource identifiers and cache management tags for resources within the pool.

[0054] The storage module generates address keys based on normalized addresses, version identifiers, and scene dependency identifiers, and writes resources exceeding the threshold to the browser database in shards to form shadow cache records. The management module maintains resource-level integrity bitmaps and shard-level integrity bitmaps, and generates a replenishment queue based on these two levels of integrity bitmaps. The response reconstruction module determines the hit conditions based on address keys, version verification information, and the two levels of integrity bitmaps, and constructs a cached response for the 3D geographic information engine to read. The update module performs missing replenishment when there is a miss or when essential resources for the first screen are incomplete, performs changed shard replacement when resources change, and performs pool-level eviction when capacity is insufficient.

[0055] The browser-automatic caching large file caching management system in this application embodiment is used to implement the browser-automatic caching large file caching management method in any of the preceding embodiments. Therefore, the execution process of each module in the system can be referred to the description of the corresponding steps in the method embodiment. Each module can be implemented by the cooperation of script programs in the browser client, browser background request interception programs (Service Workers), resource providers, browser database access logic, or extended interfaces of the 3D geographic information engine, or it can be implemented by different functional units in the same software program.

[0056] This application may also provide an electronic device, including a memory and a processor. The memory is used to store a computer program, and the processor is used to execute the computer program to implement the browser automatic caching large file cache management method in any of the preceding embodiments.

[0057] This application may also provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the browser automatic caching large file cache management method described in any of the preceding embodiments. The computer-readable storage medium may include media capable of storing computer programs, such as a USB flash drive, read-only memory, random access memory, portable hard drive, magnetic disk, or optical disk.

[0058] The above embodiments are used to illustrate the technical solutions of this application and are not intended to limit this application. For those skilled in the art, improvements or modifications can be made to this application without departing from the principles of this application, and such improvements or modifications also fall within the protection scope of this application.

Claims

1. A method for managing large file caches automatically cached by a browser, characterized in that, include: When loading a 3D geographic information scene on a browser client, resource requests are intercepted and a resource descriptor is generated. The resource descriptor includes a normalized address, resource type, version identifier, and scene dependency identifier. The automatic caching threshold is determined based on the browser type, the resource type, the network caching policy, and the current storage quota. The target resource data volume corresponding to the resource descriptor is determined according to the priority order of the resource data volume identifier source. When the amount of target resource data exceeds the automatic caching threshold, the resource is identified as an over-threshold resource, and a scene dependency pool containing the necessary resources for the first screen and the expected resources for adjacent view areas is generated according to the scene dependency identifier. An address key is generated based on the normalized address, the version identifier, and the scenario dependency identifier. The resources exceeding the threshold are written to the browser database in fragments to form shadow cache records. The shadow cache records include the address key, response metadata, version verification information, and resource-level and fragment-level integrity bitmaps. When a resource request is received again, the hit condition is determined based on the newly generated resource descriptor, the address key, the version verification information, and the integrity bitmap. If a hit is found, the resource data is reassembled according to the fragments and a cached response is constructed for the 3D geographic information engine to read. When a resource is not hit or the necessary resources for the first screen are incomplete, missing resource replacement is performed; when resources change, changed fragment replacement is performed; and when capacity is insufficient, pool-level elimination is performed according to the elimination score of the scenario dependency pool.

2. The method according to claim 1, characterized in that, Generating the scene dependency pool and forming the shadow cache record includes: Resource dependencies are extracted from the resource organization information and visibility relationships of the 3D geographic information scene and a 3D resource dependency map is generated. The resource nodes corresponding to the current 3D geographic information scene are located according to the scene dependency identifier. The scene dependency pool is generated using the essential resources of the first screen of the current 3D geographic information scene and the expected resources of adjacent view areas as boundaries; Configure resource identifiers and cache management tags for resources within the scenario dependency pool; the cache management tags include required resource tags and optional resource tags. When the scene dependency pool contains the resource exceeding the threshold, the scene dependency pool is used as a writing unit. A secondary address key is established according to the address key, the resource identifier in the pool, and the fragment sequence number. The resource fragment, fragment verification value, response metadata, and version verification information are written to the browser database, and the resource-level integrity bitmap and the fragment-level integrity bitmap are updated synchronously. When a 3D geographic information scene belonging to the scene dependency pool is loaded again, the system first determines whether the necessary resources for the first screen are complete according to the resource-level integrity bitmap and the fragment-level integrity bitmap, and then determines whether to reconstruct the cached response, replenish missing resources, or roll back the server-side loading.

3. The method according to claim 2, characterized in that, Determining the automatic caching threshold and the target resource data volume includes: Read the threshold benchmark corresponding to the browser type, the resource type, and the network caching policy; The automatic cache threshold is obtained by correcting the threshold benchmark based on the cache correction information; Prioritize parsing the trusted data volume identifier in the data volume identifier resource identifier information. The trusted data volume identifier is a data volume identifier that is consistent with the response header content length, resource list summary, or the version verification information. If the trusted data volume identifier is not parsed, the length of the content in the response header is read through the header information request; if the header information request is unavailable, the target resource data volume is recorded from the response header during the first download process, and the cache failure result is fed back to the historical cache failure record.

4. The method according to claim 2 or 3, characterized in that, Writing the resources exceeding the threshold into the browser database in fragments includes: Determine the fragmentation boundaries based on the target resource data volume and resource fragmentation constraints; Configure fragment attribute information and write transaction number for each fragment; After the write operation is completed, the resource-level integrity bitmap is updated according to the resource identifier in the pool, and the fragment-level integrity bitmap is updated according to the fragment sequence number. If a write transaction is interrupted, the fragments that have passed the verification are retained and the fragments that have not been written are marked as missing fragments so that subsequent hit checks can trigger missing data filling.

5. The method according to claim 2, characterized in that, The two-level integrity bitmap includes the resource-level integrity bitmap and the fragment-level integrity bitmap; The resource-level integrity bitmap is used to indicate whether each resource in the scene dependency pool is complete, and the fragment-level integrity bitmap is used to indicate whether each fragment of a single resource is complete. When all resources corresponding to the required resource markers are in a complete state and the resources corresponding to the optional resource markers reach a preset proportion of complete optional resources, the scene dependency pool is marked as a recoverable pool. When the resource corresponding to the required resource tag is missing, the scenario dependency pool is marked as a replenishment pool, and a replenishment queue is generated based on the resource-level integrity bitmap, the fragment-level integrity bitmap, and the missing fragment.

6. The method according to claim 5, characterized in that, Constructing the cached response includes: The resource request is received through the request takeover interface of the browser client or the resource provider of the 3D geographic information engine. When the normalized address, version identifier, and scene dependency identifier in the newly generated resource descriptor match the address key, and the scene dependency pool is the recoverable pool, the resource data is read and reassembled according to the fragment sequence number, and the reassembled resource data is combined with the response metadata to generate a cached response object for the 3D geographic information engine to read. The response metadata should retain at least the response base field and the version field.

7. The method according to claim 6, characterized in that, The version verification information includes server-side verification information, resource version information, and content summary information; When the shadow cache record expires, the version identifier is inconsistent with the version verification information, the resource list version number changes, or the scene dependency pool is changed from the recoverable pool to the pending pool, a verification request is sent to the server based on the version verification information. If the server-side resources remain unchanged, the validity period of the shadow cache record is extended. If server-side resources change, only the shards corresponding to the changed resources, the shard checksums, and the response metadata are replaced, and the resource-level integrity bitmap and the shard-level integrity bitmap are recalculated.

8. The method according to claim 7, characterized in that, The elimination score is determined by access status information, view domain association information, pool integrity information, resource cost information, and user retention information. When performing the pool-level elimination, priority is given to eliminating scene dependency pools that are incomplete and do not contain the necessary resources for the first screen. Elimination of recoverable pools corresponding to the current view or adjacent view is delayed. When capacity needs to be released, optional resources or low-redownload-cost resources in the same scene dependency pool are deleted in groups.

9. The method according to claim 8, characterized in that, When a cache execution exception occurs, the corresponding resource will be switched to server-side direct retrieval or browser native cache processing, and the resource descriptor, the scenario dependency identifier, the exception type and the reason for failure will be retained. After the current storage quota is restored, the persistence authorization is successful, or the version verification conflict is resolved, the automatic cache threshold, the replenishment queue, or the eviction score is corrected according to the reason for the failure, and the shadow cache record is re-established or repaired.

10. A browser-automatic file caching management system, characterized in that, include: The request module is used to intercept resource requests and generate resource descriptors when the browser client loads a 3D geographic information scene; The identification module is used to determine the automatic caching threshold and the target resource data volume, and to identify resources that exceed the threshold; The pooling documentation module is used to generate a scene dependency pool containing the necessary resources for the first screen based on the scene dependency identifier, and to configure the resource identifier and cache management flag in the scene dependency pool. The storage module is used to generate an address key based on the normalized address, version identifier and the scenario dependency identifier, and write the over-threshold resource into the browser database in segments to form shadow cache records; The management module is used to maintain resource-level integrity bitmaps and fragment-level integrity bitmaps, and generate a replenishment queue based on the resource-level integrity bitmaps and fragment-level integrity bitmaps; The response reconstruction module is used to determine the hit conditions based on the address key, version verification information and two-level integrity bitmap, and construct a cached response for the three-dimensional geographic information engine to read. The update module is used to perform missing data retrieval when a resource is missed or the required resources for the first screen are incomplete, to perform changed fragment replacement when resources change, and to perform pool-level eviction when capacity is insufficient.

Images