Front-end resource processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a front-end resource processing method and device, electronic equipment and a storage medium, which are used for solving the technical problems that an existing front-end resource compression and decompression method cannot adapt to real-time processing requirements of dynamically generated contents or user-defined data and is low in processing efficiency. The method comprises the following steps: when a compression request for front-end resources is received, obtaining network information, an equipment memory, a resource type of the front-end resources, context parameters and resource metadata; selecting a compression algorithm according to the resource type, the context parameter and the resource metadata; calculating a compression level of a compression algorithm according to the network information and the equipment memory; determining a compression strategy according to the compression level; compressing the front-end resources according to the compression strategy to obtain a compressed data stream; when a decompression request for the compressed data stream is received, decompressing the compressed data stream to obtain a decompressed data stream; performing integrity verification on the decompressed data stream; and when the verification is passed, outputting the decompressed data stream.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of resource processing, and in particular to a front-end resource processing method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the increasing complexity of web application functions and the improvement of user experience requirements, the size of front-end resources continues to grow, and large JavaScript packages, high-resolution images and dynamic data streams have become performance bottlenecks. Traditional resource compression schemes mainly rely on server-side preprocessing (such as Gzip, Brotli) and HTTP content encoding, which can reduce the transmission size, but have significant limitations: first, server-side compression cannot adapt to the real-time processing needs of dynamically generated content or user-defined data; second, complete resource decompression requires waiting for all data to arrive at the browser, resulting in first-screen rendering delay and memory peak pressure; in addition, existing browser decompression mechanisms are mostly based on overall data processing, lack fine-grained streaming control, and are difficult to support progressive loading and interactive scenarios. Although modern browsers support Compression Streams API, its native interface is relatively low-level, and developers need to manually manage the stream lifecycle, error handling and resource recycling, and lack optimization strategies for front-end resource characteristics (such as code splitting dependencies, cache consistency, priority scheduling). SUMMARY

[0003] The present application provides a front-end resource processing method, device, electronic equipment and storage medium, which solves the technical problems that the existing front-end resource compression and decompression method cannot adapt to the real-time processing needs of dynamically generated content or user-defined data, and has low processing efficiency.

[0004] The present application provides a front-end resource processing method, comprising:

[0005] When a compression request for a front-end resource is received, network information, device memory, resource type of the front-end resource, context parameters and resource metadata are obtained;

[0006] According to the resource type, the context parameters and the resource metadata, a compression algorithm is selected;

[0007] According to the network information and the device memory, the compression level of the compression algorithm is calculated;

[0008] According to the compression level, a compression strategy is determined;

[0009] According to the compression strategy, the front-end resource is compressed to obtain a compressed data stream;

[0010] When a decompression request for the compressed data stream is received, the compressed data stream is decompressed to obtain a decompressed data stream;

[0011] checking the decompressed data stream for integrity;

[0012] outputting the decompressed data stream when the checking passes.

[0013] Optionally, the step of calculating the compression level of the compression algorithm according to the network information and the device memory comprises:

[0014] determining a base compression level according to the compression algorithm;

[0015] calculating a network coefficient according to the network information;

[0016] calculating a memory coefficient according to the device memory;

[0017] adding the base compression level, the network coefficient and the memory coefficient to generate a compression level.

[0018] Optionally, the step of compressing the front-end resource according to the compression strategy to obtain a compressed data stream comprises:

[0019] dividing the front-end resource into a plurality of data blocks;

[0020] compressing each of the data blocks according to the compression strategy to obtain a plurality of compressed blocks;

[0021] splicing the compressed blocks to obtain a compressed data stream.

[0022] Optionally, the step of decompressing the compressed data stream to obtain a decompressed data stream when a decompression request for the compressed data stream is received comprises:

[0023] decompressing each of the compressed blocks in sequence through a preset instance to obtain decompressed block data when a decompression request for the compressed data stream is received;

[0024] checking each of the decompressed block data;

[0025] splicing all of the decompressed block data to obtain a decompressed data stream when all of the decompressed block data pass the checking.

[0026] Optionally, the step of checking each of the decompressed block data comprises:

[0027] obtaining block header information of the decompressed block data;

[0028] parsing the block header information to obtain a compression algorithm identifier, an original data size and a checksum;

[0029] determining whether the compression algorithm identifier matches the preset instance;

[0030] If matched, it is judged whether the data original size is in a preset range;

[0031] If yes, an actual checksum of the decompressed block data is calculated;

[0032] The actual checksum is compared with the checksum, and if matched successfully, it is determined that the check is passed.

[0033] The application further provides a front-end resource processing device, comprising:

[0034] an information acquisition module, configured to acquire network information, device memory, resource type of the front-end resource, context parameter and resource metadata when receiving a compression request for the front-end resource;

[0035] a compression algorithm selection module, configured to select a compression algorithm according to the resource type, the context parameter and the resource metadata;

[0036] a compression level calculation module, configured to calculate a compression level of the compression algorithm according to the network information and the device memory;

[0037] a compression strategy determination module, configured to determine a compression strategy according to the compression level;

[0038] a compressed data stream generation module, configured to compress the front-end resource according to the compression strategy to obtain a compressed data stream;

[0039] a decompression module, configured to decompress the compressed data stream to obtain a decompressed data stream when receiving a decompression request for the compressed data stream;

[0040] an integrity check module, configured to perform integrity check on the decompressed data stream;

[0041] a decompressed data stream output module, configured to output the decompressed data stream when the check is passed.

[0042] Optionally, the compression level calculation module comprises:

[0043] a basic compression level determination submodule, configured to determine a basic compression level according to the compression algorithm;

[0044] a network coefficient calculation submodule, configured to calculate a network coefficient according to the network information;

[0045] a memory coefficient calculation submodule, configured to calculate a memory coefficient according to the device memory;

[0046] a compression level generation submodule, configured to sum the basic compression level, the network coefficient and the memory coefficient to generate a compression level.

[0047] Optionally, the compressed data stream generation module comprises:

[0048] a data block division sub-module, configured to divide the front-end resource into a plurality of data blocks;

[0049] a compression sub-module, configured to compress each of the data blocks according to the compression strategy, to obtain a plurality of compressed blocks;

[0050] a splicing sub-module, configured to splice the compressed blocks, to obtain a compressed data stream.

[0051] The application further provides an electronic device, which comprises a processor and a memory:

[0052] The memory is configured to store program code and transmit the program code to the processor;

[0053] The processor is configured to execute the front-end resource processing method according to the instructions in the program code.

[0054] The application further provides a computer readable storage medium, which is configured to store program code, and the program code is configured to execute the front-end resource processing method.

[0055] From the above technical solution, it can be seen that the application has the following advantages: when a compression request for a front-end resource is received, network information, device memory, resource type of the front-end resource, context parameters and resource metadata are acquired; a compression algorithm is selected according to the resource type and the context parameters; a compression level of the compression algorithm is calculated according to the resource metadata, the network information and the device memory; a compression strategy is determined according to the compression level; the front-end resource is compressed according to the compression strategy, to obtain a compressed data stream; when a decompression request for the compressed data stream is received, the compressed data stream is decompressed, to obtain a decompressed data stream; the decompressed data stream is subjected to integrity check; and when the check is passed, the decompressed data stream is output. Thus, the real-time processing requirement of dynamically generated content or user-defined data is met, and the data processing efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0057] Figure 1 A step flow chart of a front-end resource processing method provided by the application;

[0058] Figure 2 A structural block diagram of a front-end resource processing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0059] The embodiment of the present application provides a front-end resource processing method and device, electronic equipment and a storage medium, and aims to solve the technical problems that the existing front-end resource compression and decompression method cannot adapt to the real-time processing requirement of dynamically generated content or user-defined data, and the processing efficiency is low.

[0060] In order to make the purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the following described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0061] Please refer to Figure 1 , Figure 1 A step flowchart of a front-end resource processing method provided by an embodiment of the present application.

[0062] The front-end resource processing method provided by the present application can specifically include the following steps:

[0063] Step 101, when receiving a compression request for a front-end resource, obtaining network information, device memory, resource type of the front-end resource, context parameters and resource metadata;

[0064] Step 102, selecting a compression algorithm according to the resource type, context parameters and resource metadata;

[0065] In the embodiment of the present application, the compression algorithm selector can be used to dynamically select a plurality of compression algorithms and configurations according to the resource type and context parameters. The preset resource type and compression algorithm mapping table is as follows:

[0066] Text resources (JS / CSS / HTML) prefer to use Gzip high compression level;

[0067] Image resources (PNG / JPG) are combined with the pre-analysis result to determine whether to compress (skip the compressed format);

[0068] Binary data (such as fonts) uses Deflate to balance speed and ratio.

[0069] In the specific implementation, for the image resources, the generation process of the pre-analysis result is as follows:

[0070] File type detection: Identify resource format by reading the resource's MIME type or file header signature (e.g., PNG files start with ‰PNG, JPEG starts with FF D8 FF).

[0071] Compression state evaluation: For image-type resources (such as PNG / JPG), the system calculates the entropy value of the resource or checks the existing compression flag. If the entropy value is low (indicating that the resource has been highly compressed), or the resource has used a known compression algorithm (such as WebP), it is marked as "compressed".

[0072] Metadata analysis: Combine resource metadata (such as file size, creation time) to determine the necessity of compression. For example, small files (such as less than 1KB) may skip compression to avoid overhead.

[0073] Output pre-analysis results: Generate a structured pre-analysis report, including whether to skip compression, recommended compression algorithm (such as Gzip, Deflate), and compression parameter suggestions. Pre-analysis results are used to drive the compression algorithm selector.

[0074] Step 103, calculate the compression level of the compression algorithm according to the network information and device memory;

[0075] In the embodiment of the present application, after determining the compression algorithm, the compression level of the compression algorithm can be calculated according to the network information and device content.

[0076] In one example, step 103 can include the following sub-steps:

[0077] S31, determine the basic compression level according to the compression algorithm;

[0078] S32, calculate the network coefficient according to the network information;

[0079] S33, calculate the memory coefficient according to the device memory;

[0080] S34, add the basic compression level, network coefficient and memory coefficient to generate the compression level.

[0081] In a specific implementation, the calculation formula of the compression level is as follows:

[0082] Compression level = basic level + network coefficient + memory coefficient;

[0083] Wherein, according to different compression algorithms, different basic levels can be selected.

[0084] The calculation formula of the network system is as follows:

[0085] Network coefficient = (4-network_type) x 1.5;

[0086] network_type: slow-2g=0, 2g=1, 3g=2, 4g=3.

[0087] The calculation formula of the memory coefficient is as follows:

[0088] Memory coefficient=(device_memory-2)×0.8;

[0089] The unit of device_memory is GB.

[0090] In the low-speed network, the compression level is increased, thereby reducing the transmission amount and ensuring the transmission efficiency in the low-speed network.

[0091] In addition, in the high-memory device, large block processing can be enabled to improve the throughput.

[0092] The calculation formula of the block size is as follows:

[0093] Block size=min(256, max(16, 64 × (1 + device_memory / 4))).

[0094] The unit is KB, and device_memory can be obtained through navigator.deviceMemory API.

[0095] Step 104, determining the compression strategy according to the compression level;

[0096] In the embodiment of the application, a weighted scoring model can be used by the adaptive decision engine to comprehensively evaluate the compression speed, compression ratio, CPU overhead and other dimensions on the basis of the selected compression level, and select the compression algorithm with the highest total score from the previously determined several compression algorithms as the compression strategy.

[0097] The compression speed (MB / s)=(speed-min_speed) / (max_speed-min_speed)*100.

[0098] The compression ratio=(original size-compressed size) / original size*100.

[0099] The CPU overhead=(1-CPU occupancy rate)*100.

[0100] The comprehensive score=compression speed score*0.3+compression ratio score*0.5+CPU overhead score*0.2.

[0101] Step 105, compressing the front-end resource according to the compression strategy to obtain a compressed data stream;

[0102] In the embodiments of the present application, in order to avoid the memory pressure caused by the overall loading, the compressed data stream can be divided and compressed by the streaming compression pipeline and the block processor.

[0103] In one example, step 105 can include the following sub-steps:

[0104] S51, dividing the front-end resource into a plurality of data blocks;

[0105] S52, respectively compressing each data block according to a compression strategy to obtain a plurality of compressed blocks;

[0106] S53, splicing the compressed blocks to obtain a compressed data stream.

[0107] In a specific implementation, the front-end resource (such as Fetch response body, Blob data, custom generator) can be divided into fixed or dynamic size data blocks (typically 64KB), and each block is compressed asynchronously through a CompressionStream instance. The streaming compression pipeline adopts a multi-stage TransformStream series architecture:

[0108] The first-stage block divider decomposes the original stream into serialized blocks;

[0109] The second-stage compressor calls CompressionStream to independently compress each block and attaches block header information (such as compression algorithm, original size, checksum);

[0110] The third-stage reorganizer splices the compressed blocks into a compressed data stream in sequence.

[0111] Among them, the data blocks can be compressed in parallel by the block processor, and the Web Worker or task scheduler is used to offload the computationally intensive tasks to the background thread to prevent the main thread from blocking. To handle the flow back pressure, the pipeline integrates adaptive flow rate control, dynamically adjusts the block size and compression concurrency according to the downstream consumption capacity, and ensures the system stability. The compressed data stream can be directly pipelined to the transmission layer (such as Fetch upload, WebSocket sending) or the storage layer (IndexedDB).

[0112] Among them, the process of dynamically adjusting the block size and compression concurrency according to the downstream consumption capacity is as follows:

[0113] The remaining capacity of the downstream buffer is obtained through the desiredSize attribute of TransformStream. The downstream processing delay is calculated: the time from sending a data block to confirming it is recorded.

[0114] Block size adjustment:

[0115] If desiredSize < threshold_low (e.g. 0), decrease chunk size (current size * 0.5, min 16KB).

[0116] If desiredSize > threshold_high (e.g. 100), increase chunk size (current size * 1.5, max 256KB).

[0117] Compression concurrency adjustment:

[0118] Concurrency is based on the number of Web Workers.

[0119] If downstream latency is high, decrease concurrency (e.g. from 4 to 2).

[0120] If downstream latency is low and memory is sufficient, increase concurrency (e.g. by 1, max not exceeding navigator.hardwareConcurrency).

[0121] Further, a unique identifier can be created for each compression session, and metadata such as compression algorithm, chunk parameters, source resource version hash, etc. are recorded. The metadata is stored in a separate file or response header in JSON format for verification and reconstruction when decompressing. The cache mapper maintains the correspondence between compressed resources and source resources, and ensures consistency through double-checking of content hashes. When the source resource is updated, the mapper automatically invalidates the old compressed resource and triggers the re-compression process. The system supports incremental compression, which only re-compresses the changed part, reducing computational overhead.

[0122] Step 106, when receiving a decompression request for the compressed data stream, decompressing the compressed data stream to obtain a decompressed data stream;

[0123] In an embodiment of the present application, when receiving a decompression request for the compressed data stream, the decompression pipeline receives the compressed data stream (e.g. Fetch response body) and decompresses each chunk through a DecompressionStream instance.

[0124] In one example, step 106 can include the following sub-steps:

[0125] S61, when receiving a decompression request for the compressed data stream, sequentially decompressing each compressed chunk through a preset instance to obtain decompressed chunk data;

[0126] S62, verifying each decompressed chunk data;

[0127] S63, when all decompressed chunk data passes the verification, splicing all decompressed chunk data to obtain a decompressed data stream.

[0128] In a specific implementation, the decompression can be performed block by block through a DecompressionStream instance. The pipeline is designed as a recoverable architecture: when the data stream is interrupted (such as network jitter), the system caches the decompressed part, and only processes the newly added block when the stream is recovered, avoiding repeated work. The progressive renderer delivers the decompressed data to the consumer (HTML parser, CSSOM builder and JavaScript execution engine) in real time.

[0129] For text resources, the system converts the binary decompressed data into a character stream through a TextDecoder stream and injects it into the parsing pipeline in segments;

[0130] For binary resources (such as images), the system asynchronously generates partial images through createImageBitmap to achieve progressive image display.

[0131] In the embodiment of the application, the progressive renderer supports priority scheduling for different compressed data streams. Each resource has an independent decompression pipeline, and the scheduler manages the execution order of these pipelines according to the priority of the resources: the decompression pipeline of a critical resource (such as the first-screen CSS) is started first. The decompression pipeline of a non-critical resource (such as a lazy-loaded script) is executed later or only when idle. The sub-blocks within the same stream are not prioritized because a single resource is treated as an atomic unit.

[0132] It should be noted that the system can verify the compressed block header information when decompressing each block of data, verify the matching of the compression algorithm and the size range, and immediately abort and trigger the error handling process upon finding an exception.

[0133] The step of verifying each decompressed block of data includes:

[0134] S621, obtaining the block header information of the decompressed block of data;

[0135] S622, parsing the block header information to obtain the compression algorithm identifier, the original size of the data and the checksum;

[0136] S623, determining whether the compression algorithm identifier matches the preset instance;

[0137] S624, if the match is successful, determining whether the original size of the data is within the preset range;

[0138] S625, if yes, calculating the actual checksum of the decompressed block of data;

[0139] S626, comparing the actual checksum with the checksum, and if the comparison is successful, determining that the verification is passed.

[0140] In a specific implementation, the process of verifying the decompressed block of data is as follows:

[0141] Read chunk header information: parse chunk header fields (compression algorithm, original size, checksum).

[0142] Algorithm matching check: compare the compression algorithm identifier in the chunk header information with the algorithm of the current instance. If they do not match, abort decompression and trigger an error.

[0143] Size range check: check whether the original size of the data is within a reasonable range (e.g. 0 < size < 10MB). If it is abnormal, mark it as damaged.

[0144] Checksum verification: calculate the actual checksum (e.g. CRC32) of the decompressed chunk data and compare it with the checksum in the chunk header information. If it fails, trigger re-decompression (up to 3 times).

[0145] In addition, the embodiments of the present application introduce an error recovery device, which uses multiple strategies to repairable errors (such as checksum mismatch) to attempt to re-decompress or request retransmission of the current block; for unrepairable errors (such as compression format damage), fall back to the uncompressed version (if there is a cache) or throw an exception to the upper layer.

[0146] Step 107, integrity check of the decompressed data stream;

[0147] Step 108, when the check passes, output the decompressed data stream.

[0148] In the embodiments of the present application, the data integrity checker can compare the decompressed data stream with the original size and hash value in the metadata after decompression to ensure accuracy. The system also integrates a timeout and retry mechanism to automatically interrupt and restart long-stalled decompression tasks, avoiding indefinite waiting.

[0149] The embodiments of the present application also provide a memory management and resource recycler for optimizing memory usage and resource release during decompression. The system avoids loading compressed data in bulk through streaming processing, significantly reducing memory peaks. The resource recycler automatically tracks the life cycle of the decompression stream and releases related CompressionStream and DecompressionStream instances immediately when the stream is closed, errors or completed, preventing memory leaks. For large resources, the system uses a generational garbage collection strategy to preferentially release consumed decompression data blocks. The memory manager also dynamically monitors memory usage and triggers aggressive recovery (such as forced cache cleaning) or degradation processing (such as skipping non-critical resource decompression) when approaching the threshold.

[0150] The embodiment of the present application also provides a declarative compression and decompression scheduler, which allows developers to enable compression and decompression functions by simply configuring objects due to providing a high-level JavaScript API. Developers can register automatic compression tasks by defining parameters such as resource URL, compression strategy, output target, etc.; similarly, a decompression process is declared by specifying parameters such as decompression source, rendering target, priority, etc. The scheduler automatically processes stream pipeline construction, error handling and life cycle management, without manually operating underlying APIs. The scheduler supports batch operations and dependency management, such as sequentially compressing a group of resources, or triggering subsequent tasks after waiting for a resource to complete decompression.

[0151] The embodiment of the present application also provides an adaptive strategy engine and a performance monitor, which collects runtime indicators (such as compression ratio, decompression speed, CPU occupancy, network throughput) in real time, and dynamically adjusts the compression strategy based on these data.

[0152] The dynamic adjustment process of the compression strategy is as follows:

[0153] Indicator collection: collect indicators (compression ratio, decompression speed, CPU occupancy, network throughput) every 5 seconds.

[0154] Trend analysis: use a sliding window to calculate a moving average and detect anomalies (such as a 20% decrease in decompression speed).

[0155] Strategy adjustment rules:

[0156] If the compression ratio is lower than a threshold value (such as 40%), switch to a more efficient algorithm (such as Gzip→Brotli).

[0157] If the decompression speed is lower than a threshold value (such as 10 MB / s), reduce the compression level (such as 9→6).

[0158] If the CPU occupancy is higher than a threshold value (such as 80%), reduce the concurrency or block size.

[0159] If the network throughput is high (such as >10 Mbps), prioritize compression speed; if it is low (<1 Mbps), prioritize compression ratio.

[0160] Automatic learning: the strategy engine uses linear regression to predict optimal parameters (such as block size) based on historical data.

[0161] The adaptive decision engine uses linear regression to predict optimal parameters, such as identifying the best block size for a specific resource type based on historical data. The performance monitor continuously tracks key indicators and automatically switches to a degraded strategy (such as disabling compression) when performance degradation (such as a sudden increase in decompression delay) is identified. The system provides a visual configuration interface that allows developers to set performance thresholds and alarm rules.

[0162] The application acquires network information, device memory, resource type of front-end resources, context parameters and resource metadata when receiving a compression request for the front-end resources, selects a compression algorithm according to the resource type and the context parameters, calculates a compression level of the compression algorithm according to the resource metadata, the network information and the device memory, determines a compression strategy according to the compression level, compresses the front-end resources according to the compression strategy to obtain a compressed data stream, decompresses the compressed data stream to obtain a decompressed data stream when receiving a decompression request for the compressed data stream, performs integrity check on the decompressed data stream, and outputs the decompressed data stream when the check is passed. Thus, the real-time processing requirement of dynamically generated content or user-defined data is met, and the data processing efficiency is improved.

[0163] Please refer to Figure 2 , Figure 2 The structure block diagram of a front-end resource processing device provided by the embodiment of the application is shown.

[0164] The embodiment of the application provides a front-end resource processing device, which comprises:

[0165] The information acquisition module 201 is configured to acquire network information, device memory, resource type of front-end resources, context parameters and resource metadata when receiving a compression request for the front-end resources.

[0166] The compression algorithm selection module 202 is configured to select a compression algorithm according to the resource type, the context parameters and the resource metadata.

[0167] The compression level calculation module 203 is configured to calculate a compression level of the compression algorithm according to the network information and the device memory.

[0168] The compression strategy determination module 204 is configured to determine a compression strategy according to the compression level.

[0169] The compressed data stream generation module 205 is configured to compress the front-end resources according to the compression strategy to obtain a compressed data stream.

[0170] The decompression module 206 is configured to decompress the compressed data stream to obtain a decompressed data stream when receiving a decompression request for the compressed data stream.

[0171] The integrity check module 207 is configured to perform integrity check on the decompressed data stream.

[0172] The decompressed data stream output module 208 is configured to output the decompressed data stream when the check is passed.

[0173] In the embodiment of the application, the compression level calculation module 203 comprises:

[0174] The basic compression level determination submodule is configured to determine a basic compression level according to the compression algorithm.

[0175] a network coefficient calculation sub-module, configured to calculate a network coefficient according to network information;

[0176] a memory coefficient calculation sub-module, configured to calculate a memory coefficient according to device memory;

[0177] a compression level generation sub-module, configured to add the base compression level, the network coefficient and the memory coefficient to generate a compression level.

[0178] In the embodiment of the application, the compression data stream generation module 205 comprises:

[0179] a data block division sub-module, configured to divide the front-end resource into a plurality of data blocks;

[0180] a compression sub-module, configured to compress each data block according to a compression strategy to obtain a plurality of compressed blocks;

[0181] a splicing sub-module, configured to splice the compressed blocks to obtain a compressed data stream.

[0182] In the embodiment of the application, the decompression module 206 comprises:

[0183] a decompressed block data generation sub-module, configured to, when receiving a decompression request for the compressed data stream, decompress each compressed block in sequence through a preset instance to obtain decompressed block data;

[0184] a verification sub-module, configured to verify each decompressed block data;

[0185] a decompressed data stream generation sub-module, configured to, when all the decompressed block data are verified, splice all the decompressed block data to obtain a decompressed data stream.

[0186] In the embodiment of the application, the verification sub-module comprises:

[0187] a block header information acquisition unit, configured to acquire block header information of the decompressed block data;

[0188] a parsing unit, configured to parse the block header information to obtain a compression algorithm identifier, a data original size and a checksum;

[0189] a compression algorithm identifier judgment unit, configured to judge whether the compression algorithm identifier matches the preset instance;

[0190] a data original size judgment unit, configured to, if the compression algorithm identifier matches the preset instance, judge whether the data original size is within a preset range;

[0191] an actual checksum calculation unit, configured to, if the data original size is within the preset range, calculate an actual checksum of the decompressed block data;

[0192] a verification pass determination unit, configured to compare the actual checksum with the checksum, and if the comparison is successful, determine that the verification passes.

[0193] The embodiment of the present application also provides an electronic device, which comprises a processor and a memory:

[0194] The memory is used for storing program codes and transmitting the program codes to the processor.

[0195] The processor is used for executing the front-end resource processing method of the embodiment of the present application according to instructions in the program codes.

[0196] The embodiment of the present application also provides a computer readable storage medium, which is used for storing program codes, and the program codes are used for executing the front-end resource processing method of the embodiment of the present application.

[0197] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, the device and the unit described above can refer to the corresponding process in the foregoing method embodiments, and will not be described here.

[0198] Each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments, and the same and similar parts between each embodiment can be referred to each other.

[0199] Those skilled in the art can understand that the embodiments of the embodiment of the present application can be provided as a method, a device or a computer program product. Therefore, the embodiment of the present application can adopt a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the embodiment of the present application can adopt a computer program product in the form of one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program codes.

[0200] The embodiments of the present application are described with reference to flowcharts and / or block diagrams according to the method, terminal device (system) and computer program product of the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be realized by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to produce a machine, so that the instructions executed by the computer or other programmable data processing terminal device produce a machine for realizing the functions specified in the flowcharts and / or block diagrams. Figure 1 The device for realizing the functions specified in one flow or multiple flows and / or blocks Figure 1 The device for realizing the functions specified in one block or multiple blocks.

[0201] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the flow Figure 1 flow or flows and / or blocks Figure 1 of the flow or flows and / or blocks.

[0202] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow Figure 1 flow or flows and / or blocks Figure 1 of the flow or flows and / or blocks.

[0203] While preferred embodiments of the application have been described, those skilled in the art will recognize that additional modifications and changes can be made thereto without departing from the scope of the application. Accordingly, the appended claims are intended to cover all such modifications and changes as fall within the scope of the application.

[0204] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0205] Finally, it should also be noted that in this document, relational terms such as first and second and the like can only be used to distinguish one entity or action from another entity or action, without necessarily requiring or implying that these entities or actions are in any such actual relationship or order. Moreover, the terms "comprises", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or terminal device. Without more limitations, an element defined by the statement "comprising a" does not exclude the existence of additional identical elements in the process, method, article, or terminal device including the element.

[0206] The above-described embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalent replacements; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A front-end resource processing method, characterized by, The method comprises the following steps: When a compression request for a front-end resource is received, network information, device memory, resource type of the front-end resource, context parameters and resource metadata are acquired; A compression algorithm is selected according to the resource type, the context parameters and the resource metadata; A compression level of the compression algorithm is calculated according to the network information and the device memory; A compression strategy is determined according to the compression level; The front-end resource is compressed according to the compression strategy, and a compressed data stream is obtained; When a decompression request for the compressed data stream is received, the compressed data stream is decompressed, and a decompressed data stream is obtained; The decompressed data stream is subjected to integrity check; When the check is passed, the decompressed data stream is output.

2. The method of claim 1, wherein, The step of calculating the compression level of the compression algorithm according to the network information and the device memory comprises the following steps: A basic compression level is determined according to the compression algorithm; A network coefficient is calculated according to the network information; A memory coefficient is calculated according to the device memory; The basic compression level, the network coefficient and the memory coefficient are added to generate a compression level.

3. The method of claim 1, wherein, The step of compressing the front-end resource according to the compression strategy to obtain a compressed data stream comprises the following steps: The front-end resource is divided into a plurality of data blocks; Each data block is compressed according to the compression strategy, and a plurality of compressed blocks are obtained; The compressed blocks are spliced to obtain a compressed data stream.

4. The method of claim 3, wherein, The step of decompressing the compressed data stream to obtain a decompressed data stream when a decompression request for the compressed data stream is received comprises the following steps: When a decompression request for the compressed data stream is received, each compressed block is decompressed in sequence by a preset instance to obtain decompressed block data; Each decompressed block data is checked; When all the decompressed block data are checked, all the decompressed block data are spliced to obtain a decompressed data stream.

5. The method of claim 4, wherein, The step of checking each decompressed block data comprises the following steps: The block header information of the decompressed block data is acquired; The block header information is parsed to obtain a compression algorithm identifier, a data original size and a checksum; It is judged whether the compression algorithm identifier matches the preset instance; If yes, it is judged whether the data original size is within a preset range; If yes, an actual checksum of the decompressed block data is calculated; The actual checksum and the checksum are compared, and if the comparison is successful, it is determined that the check is passed.

6. A front-end resource processing apparatus, characterized by comprising: The method comprises the following steps: An information acquisition module is configured to acquire network information, device memory, resource type of a front-end resource, context parameters and resource metadata when a compression request for the front-end resource is received; A compression algorithm selection module is configured to select a compression algorithm according to the resource type, the context parameters and the resource metadata; A compression level calculation module is configured to calculate a compression level of the compression algorithm according to the network information and the device memory; A compression strategy determination module is configured to determine a compression strategy according to the compression level; A compressed data stream generation module is configured to compress the front-end resource according to the compression strategy, and obtain a compressed data stream; A decompression module is configured to decompress the compressed data stream when a decompression request for the compressed data stream is received, and obtain a decompressed data stream. An integrity checking module is configured to perform integrity checking on the decompressed data stream. A decompressed data stream output module is configured to output the decompressed data stream when the checking is passed.

7. The apparatus of claim 6, wherein, The compression level calculation module comprises: A basic compression level determination submodule is configured to determine a basic compression level according to the compression algorithm; A network coefficient calculation submodule is configured to calculate a network coefficient according to the network information; A memory coefficient calculation submodule is configured to calculate a memory coefficient according to the device memory; A compression level generation submodule is configured to sum the basic compression level, the network coefficient and the memory coefficient to generate a compression level.

8. The apparatus of claim 6, wherein, The compressed data stream generation module comprises: A data block division submodule is configured to divide the front-end resource into a plurality of data blocks; A compression submodule is configured to compress each data block according to the compression strategy to obtain a plurality of compressed blocks; A splicing submodule is configured to splice the compressed blocks to obtain a compressed data stream.

9. An electronic device, comprising: The device comprises a processor and a memory: The memory is configured to store program code and transmit the program code to the processor; The processor is configured to execute the front-end resource processing method according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium is configured to store program code, and the program code is configured to execute the front-end resource processing method.

Images