File compression method and terminal equipment

Abstract

The invention discloses a file compression method and terminal equipment, and relates to the technical field of terminals. The method comprises the steps of obtaining target access features of a to-be-compressed file and compression performance data of a target file type to which the to-be-compressed file belongs; based on the target access feature and the compression performance data, a target compression algorithm is obtained from multiple compression algorithms through matching, the decompression efficiency of the target compression algorithm meets the efficiency requirement corresponding to the target access feature, and the compression performance data of the target compression algorithm meets the matching condition. And compressing the to-be-compressed file by using the target compression algorithm. In this way, the compression algorithm which can reduce space occupation to a greater extent under the condition that the requirement for access efficiency is met can be obtained through matching.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a file compression method and terminal device. Background Technology

[0002] See Figure 1 Insufficient storage space is one of the main reasons why users upgrade their devices, such as smartphones and tablets. To address this issue, in addition to supporting the cleanup of infrequently used applications or files, the operating systems of these devices now also support file compression. Compressed files occupy less actual space, leaving more available space on the system. This allows the device to install more applications or store more photos, videos, documents, and other types of files.

[0003] However, compressed files require an additional data decompression process when read, which increases time and power consumption, resulting in decreased file access efficiency. Summary of the Invention

[0004] This application provides a file compression method and terminal device to solve the problem of decreased access efficiency after file compression. For each file, a matching compression algorithm can be used to compress it to meet the requirements of access efficiency.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, a file compression method is provided. This method can be executed by a terminal device, or by a component of the terminal device, such as the terminal device's processor, chip, or chip system. It can also be implemented by a logic module or software that can implement all or part of the terminal device. The following explanation uses the execution of this method by a terminal device as an example.

[0007] Specifically, the method includes: obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs. The file to be compressed is a file in a terminal device. The target access characteristics are used to indicate the access intensity of the file to be compressed. The compression performance data includes the compression performance data of various compression algorithms for compressing the target file type (hereinafter also referred to as compression data characteristics). The compression performance data includes decompression efficiency, which can be expressed as the amount of data decompressed per unit time (e.g., per second) (as shown in Table 1 below), or as the time taken to decompress a unit of data (e.g., 128K) (hereinafter referred to as decompression time). Based on the target access characteristics and compression performance data, a target compression algorithm is matched from various compression algorithms. The decompression efficiency of the target compression algorithm meets the efficiency requirements corresponding to the target access characteristics (e.g., the maximum acceptable decompression time), and the compression performance data of the target compression algorithm meets the matching conditions. The file to be compressed is then compressed using the target compression algorithm.

[0008] In summary, terminal devices can select a target compression algorithm from various compression algorithms that meets the decompression efficiency requirements of the file to be compressed and whose compression performance data (such as compression ratio) is also suitable. Meeting the efficiency requirements of the file to be compressed means that decompression can be performed efficiently, satisfying the user's requirements for access efficiency. Furthermore, suitable compression performance data, such as a high compression ratio, can further consider space usage. Therefore, a compression algorithm can be matched to minimize space usage while meeting access efficiency requirements.

[0009] In one possible design approach of the first aspect, compression performance data also includes compression efficiency. Similar to decompression efficiency, compression efficiency can be expressed as the amount of data compressed per unit time (e.g., per second) (as shown in Table 1 below), or as the time taken to compress a unit of data (e.g., 128K) (hereinafter referred to as compression time).

[0010] Higher compression efficiency means faster compression, resulting in shorter waiting times for users in scenarios where the compression process is visible. Therefore, a target compression algorithm can be selected based on compression efficiency, ensuring that the chosen algorithm completes compression efficiently and reducing user waiting time in certain scenarios.

[0011] In one possible design approach of the first aspect, the compression performance data of the target compression algorithm satisfies matching conditions, including: the target compression algorithm has the highest compression ratio among candidate compression algorithms that meet the efficiency requirements corresponding to the target access characteristics. That is, the target compression algorithm not only meets the efficiency requirements of the file to be compressed, but also minimizes space usage.

[0012] It should be noted that satisfying the matching condition is not limited to this. For example, the compression performance data of the target compression algorithm can also satisfy the matching condition if: among the candidate compression algorithms that meet the efficiency requirements corresponding to the target access characteristics, the algorithm with the highest comprehensive score for compression ratio and decompression efficiency. As another example, the compression performance data of the target compression algorithm can also satisfy the matching condition if: among the candidate compression algorithms that meet the efficiency requirements corresponding to the target access characteristics, the algorithm with the highest comprehensive score for compression ratio, compression efficiency, and decompression efficiency.

[0013] In one possible design approach of the first aspect, the terminal device stores a correspondence between access characteristics and efficiency requirements, as shown in Table 6 below. In Table 6, the access characteristic is the access strength value, and the efficiency requirement is the maximum acceptable decompression time. The efficiency requirement corresponding to the target access characteristic includes: the efficiency requirement corresponding to the target access characteristic in the correspondence.

[0014] In one possible design approach of the first aspect, a target compression algorithm is obtained by matching from multiple compression algorithms based on the target access characteristics and compression performance data, including: when the target access characteristics are lower than the feature threshold, that is, when the access intensity is low, such as when the access intensity value is less than the intensity threshold of 15 in Table 6, the target compression algorithm is obtained by matching from multiple compression algorithms based on the target access characteristics and compression performance data.

[0015] In other words, terminal devices can match the target compression algorithm to perform file compression for files with low access intensity.

[0016] In one possible design approach of the first aspect, if the target access characteristics exceed a characteristic threshold, i.e., the access intensity is high (e.g., the access intensity value is less than the intensity threshold of 15 in Table 6), the file to be compressed is not compressed. It should be understood that higher access intensity implies higher efficiency requirements, and compression often fails to meet these requirements. In this case, the file to be compressed can be left uncompressed to avoid affecting subsequent high-intensity access to the file.

[0017] In one possible design approach of the first aspect, a target compression algorithm is obtained by matching multiple compression algorithms based on target access characteristics and compression performance data. This includes: selecting candidate compression algorithms whose compression efficiency meets the efficiency requirements corresponding to the target access characteristics from among multiple compression algorithms; and selecting the target compressed file based on the compression performance data of the candidate compression algorithms.

[0018] In other words, we can first select candidate compression algorithms that meet the efficiency requirements, and then further select target compression algorithms from them that meet the matching conditions for compression performance data. This allows us to find compression algorithms that minimize space usage while still meeting access efficiency requirements.

[0019] In one possible design approach of the first aspect, selecting a target compression algorithm based on the compression performance data of candidate compression algorithms includes: selecting a target compression algorithm based on the compression performance data of at least two compression algorithms when the compression ratio of at least two candidate compression algorithms is higher than a compression ratio threshold. In other words, if at least two compression algorithms remain after screening, further selection can be made based on compression performance parameters.

[0020] In one possible design approach of the first aspect, if the compression ratio of one of the candidate compression algorithms is higher than a compression ratio threshold, the file to be compressed is compressed based on that compression algorithm. In other words, if only one compression algorithm remains after filtering, the file can be directly compressed using that algorithm.

[0021] In one possible design approach of the first aspect, if the compression ratio of each compression algorithm among the candidate compression algorithms is lower than the compression ratio threshold, that is, if the effect of all candidate compression algorithms on reducing space occupation is not significant, then the file to be compressed is not compressed to avoid the waste of resources caused by compression and decompression.

[0022] In one possible design approach of the first aspect, the same compression algorithm includes one or more sets of compression parameters (such as different versions, different compression standards, etc.). Taking zstd in Table 1 below as an example, 1.5.6-1 and 1.5.6 are two different versions of zstd, and fast=1 and fast=3 are versions 1.5.6 and two different compression standards. Compression performance data includes compression performance data of various compression algorithms and parameters for compressing the target file type. For example, zstd 1.5.6-1, zstd1.5.6--fast=1, and zstd1.5.6--fast=3 each have compression performance parameters after compressing the target file type, such as compression ratio, decompression time, etc.

[0023] The process of matching a target compression algorithm from multiple compression algorithms and then compressing the file using that target algorithm includes: matching a target compression algorithm and its parameters from multiple compression algorithms and their parameters, and then compressing the file using the target compression algorithm and its parameters. This allows for the selection of a suitable compression algorithm and its parameters, rather than simply choosing a generic compression algorithm.

[0024] In one possible design approach of the first aspect, obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs includes: when the file to be compressed is a file of a preset type (a file whose file type can be accurately identified, such as a file with an extension), obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs.

[0025] In other words, target access characteristics and compression performance data are only obtained for identifiable file types to match target compressed files.

[0026] In one possible design approach of the first aspect, the method further includes: compressing the file to be compressed using a preset compression algorithm when the file to be compressed is not a preset type file. In the following text, the unrecognized file type is referred to as the default type.

[0027] In other words, for unidentified file types, since it's difficult to determine the file type and therefore difficult to obtain compression performance data, the default compression algorithm can be used directly. This default compression algorithm can be a high-compression algorithm, such as LZ4.

[0028] In one possible design approach of the first aspect, before obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs, the method further includes: collecting access information of the file to be compressed, the access information including at least one of the following: number of reads, number of writes, amount of data read, and amount of data written. Access characteristics are obtained based on the access information analysis. Thus, access characteristics can be obtained based on user behavior.

[0029] In one possible design approach of the first aspect, access characteristics include access intensity values. Access characteristics are obtained based on access information analysis, including: calculating the write frequency, read frequency, and read mode coefficient of the file to be compressed based on the access information. Write frequency reflects the frequency of writing data to the file to be compressed; read frequency reflects the relationship between the frequency of data being read from the file to be compressed and the file size of the file to be compressed; and the read mode coefficient reflects the utilization rate of data after decompression when reading data from the file to be compressed. The access intensity value of the file to be compressed is calculated based on write frequency, read frequency, and read mode coefficient.

[0030] In one possible design approach of the first aspect, before obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs, the method further includes: testing the compression performance data of various compression algorithms on the target file type in the terminal device. That is, the compression performance data is obtained within the current hardware and software configuration of the terminal device, so that the target compression algorithm subsequently matched based on this compression performance data can be accurately applied to the current terminal device.

[0031] Secondly, this application also provides a terminal device, which includes a display screen, a memory, and one or more processors. The display screen, memory, and processors are coupled. The memory stores computer program code, which includes computer instructions. When the computer instructions are executed by the processor, the terminal device performs the methods described in the first aspect and any of its possible designs.

[0032] Thirdly, this application provides a chip system applied to a terminal device including a display screen and a memory; the chip system includes one or more interface circuits and one or more processors; the interface circuits and processors are interconnected via lines; the interface circuits are used to receive signals from the memory of the terminal device and send signals to the processor, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the terminal device performs the method as described in the first aspect and any of its possible design embodiments.

[0033] Fourthly, this application provides a computer storage medium including computer instructions that, when executed on a terminal device, cause the terminal device to perform a method as described in the first aspect and any of its possible design embodiments.

[0034] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method as described in the first aspect and any of its possible design methods.

[0035] Understandably, the beneficial effects that the terminal device of the second aspect, the chip system of the third aspect, the computer storage medium of the fourth aspect, and the computer program product of the fifth aspect can achieve can be referred to the beneficial effects of the first aspect and any of its possible design embodiments, and will not be repeated here. Attached Figure Description

[0036] Figure 1 This is a diagram illustrating one reason for upgrading a device.

[0037] Figure 2 An interface diagram illustrating a file compression process provided in this application embodiment;

[0038] Figure 3 This application provides a low-level interaction diagram for file compression and decompression in an embodiment.

[0039] Figure 4 A hardware structure diagram of a terminal device provided in an embodiment of this application;

[0040] Figure 5 A software architecture diagram of a terminal device provided in an embodiment of this application;

[0041] Figure 6 A flowchart illustrating the analysis of file access characteristics is provided as an embodiment of this application;

[0042] Figure 7 A flowchart illustrating a target compression algorithm and parameters for compression, provided in this application embodiment;

[0043] Figure 8 An example diagram illustrating file compression provided in an embodiment of this application;

[0044] Figure 9 This is a schematic diagram of the architecture of a chip system provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0046] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0047] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0048] The file compression method provided in this application can be applied to scenarios where files on a terminal device are compressed to reduce their space usage. For example, settings applications and system management applications on the terminal device can provide file compression functionality. In response to a user triggering the operation of this function, the terminal device can perform compression operations on the files on the terminal device.

[0049] Taking a mobile phone as an example, see Figure 2 The phone can display interface 201, which is the application interface of the system manager app. Interface 201 includes "Clean Up & Speed ​​Up" 2011. In response to the user's triggering of "Clean Up & Speed ​​Up" 2011, the phone can display interface 202. Interface 202 includes option 2021, used to trigger compression settings. In response to the user's triggering of option 2021, the phone can display interface 203, which includes compression options for files such as pictures and videos, and also includes "Compress" 2031, used to trigger compression. In response to the user's triggering of "Compress" 2031, the phone can begin file compression. During file compression, the phone can display a compression waiting interface as shown in interface 204. Interface 204 includes the compression progress, which can continuously change. After compression is complete, the phone can display interface 205. Interface 205 indicates that compression is complete, such as "Released 5.91GB of storage space," indicating the compression effect.

[0050] After a file is compressed, when a terminal device needs to access it—whether to read or write data—it must first decompress the file. This increases time and power consumption, reducing file access efficiency. Decreased efficiency will impact user experience to some extent. For example, users may perceive slower device response or even lag.

[0051] For example, when an application starts, the terminal device must first decompress the files required to start the application, which reduces the efficiency of accessing the files required to start the application and takes a long time to complete the application startup. As a result, users have to wait a long time before they can use the application.

[0052] It should be understood that the more data is decompressed, the longer the decompression time and the higher the power consumption will be. Consequently, the file access efficiency will decrease further, and the greater the impact on the user experience will be.

[0053] In conventional technologies, terminal devices can consistently use a compression algorithm that has minimal impact on access efficiency to compress files.

[0054] For example, common compression algorithms and their compression ratios, compression efficiencies, and decompression efficiencies are shown in Table 1 below:

[0055] Table 1

[0056]

[0057] The compression ratio is the ratio of the size of the data before compression to the size of the data after compression. For example, a compression ratio of 2.887 means that the size of the data before compression is 2.887 times the size of the data after compression.

[0058] Compression efficiency refers to the amount of data compressed per second; for example, 510MB / s means compressing 510MB of data per second. Decompression efficiency refers to the amount of data decompressed per second; for example, 1580MB / s means decompressing 1580MB of data per second.

[0059] The higher the compression ratio, the greater the reduction in space usage. Higher compression efficiency (measured by compression time below) means faster compression, shorter waiting time for the user, and a shorter time the phone remains on the 204 error screen mentioned earlier. Higher decompression efficiency (measured by decompression time below) means faster decompression, with less impact on access efficiency; for example, it allows for faster decompression to obtain the files needed to launch the application and complete the application launch.

[0060] Clearly, in Table 1 above, the lz4 compression algorithm has the highest decompression efficiency and can complete decompression the fastest, thus having the least impact on access efficiency. Based on this, in conventional technologies, terminal devices can consistently use lz4 compressed files.

[0061] However, while the aforementioned conventional techniques reduce the impact on access efficiency, they often struggle to balance access efficiency and space usage. Taking Table 1 as an example, using lz4 for compression and decompression can minimize the impact on access efficiency, but lz4's compression ratio of 2.101 is not very high and cannot minimize space usage.

[0062] See Figure 3 After compression is triggered by applications on the terminal device, such as system manager applications or settings applications, the compression service in the terminal device's native layer can compress and decompress files (such as files involved in infrequently used applications) by calling various compression algorithms provided by the flash-friendly file system (F2FS) in the kernel layer.

[0063] If all files to be compressed are compressed and decompressed using lz4, the impact on access efficiency can be minimized. For example, when accessing compressed files, the I / O performance drops by only about 10% when decompressing. However, space usage cannot be taken into account. For example, compressing infrequently used files can only save about 20% of space.

[0064] If zstd is used to compress and decompress all files to be compressed, space usage can be reduced to the greatest extent. For example, compressing infrequently used files can save about 28% of space. However, access efficiency cannot be guaranteed. When accessing compressed files, decompression can cause I / O performance to drop by more than 60%, resulting in a poor user experience.

[0065] To address the aforementioned issues, this application provides a file compression method that can match the optimal compression algorithm for each file based on the user's access characteristics to each file and the compression data characteristics (such as compression ratio, decompression efficiency, etc.) of various compression algorithms.

[0066] The access characteristics of each file reflect the intensity of user access to the file, such as access frequency and data volume. Higher access intensity requires higher access efficiency, and lower access intensity requires lower access efficiency. The compression data characteristics of various compression algorithms reflect their compression performance; for example, compression ratio reflects the reduction in space usage, and decompression efficiency reflects the impact on access efficiency. Therefore, based on the access patterns of each file and the compression data characteristics of various compression algorithms, a compression algorithm that minimizes space usage while meeting access efficiency requirements can be selected.

[0067] For example, the terminal device in this application embodiment may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, smart TV, smart refrigerator and other smart home appliances, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device and other devices that can store various types of files. This application embodiment does not impose any special restrictions on the specific form of the terminal device.

[0068] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0069] See Figure 4 This is a structural schematic diagram of a terminal device 200 provided in an embodiment of this application. Figure 4As shown, taking a mobile phone as an example, the terminal device may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, a camera 293, a display screen 294, etc.

[0070] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the terminal device. In other embodiments, the terminal device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0071] Processor 210 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0072] In some embodiments, the terminal device may execute a file compression method through the processor 210 to find a compression algorithm that minimizes space usage while meeting access efficiency requirements, and use it to compress files.

[0073] The charging management module 240 receives charging input from the charger. The power management module 241 connects to the battery 242, the charging management module 240, and the processor 210. The power management module 241 receives input from the battery 242 and / or the charging management module 240 to power the processor 210, internal memory 221, external memory, display 294, camera 293, and wireless communication module 260, etc.

[0074] The wireless communication function of the terminal device can be implemented through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor, and baseband processor.

[0075] The terminal device implements display functions through a GPU, a display screen 294, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 294 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. The processor 210 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0076] Display screen 294 is used to display images, videos, etc. Display screen 294 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0077] Terminal devices can achieve shooting functions through ISP, camera 293, video codec, GPU, display 294 and application processor.

[0078] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of the terminal device by running the instructions stored in internal memory 221.

[0079] The software architecture of the aforementioned terminal devices can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. The following uses the layered architecture of the Android system as an example to illustrate the software structure of the terminal device. A layered architecture divides the software system into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces.

[0080] Figure 5 This is a software architecture block diagram of a terminal device to which this application embodiment applies. Taking a mobile phone as an example, the layered architecture divides the software system into an application layer and an operating system (OS) layer. Furthermore, the OS can be further divided into an application framework layer, a native layer, a hardware abstraction layer (HAL), and a kernel layer, etc., which are not shown in the figure.

[0081] The application layer can include a series of application packages.

[0082] The application layer can install application packages such as calling, memo, browser, contacts, camera, calendar, map, Bluetooth, music, video, and SMS.

[0083] In some embodiments, the application layer may also include applications that provide file compression functionality, such as phone managers, photo albums, settings, etc. These applications provide an entry point for file compression, such as the "Compression" option 2031 in interface 203 above. In response to a trigger operation on this entry point, the phone can execute a file compression method to compress the file.

[0084] The OS includes a file access feature analysis module, a file data feature analysis module, a file compression algorithm and parameter management module, and F2FS, etc. It should be noted that the file access feature analysis module, the file data feature analysis module, and the file compression algorithm and parameter management module can be distributed in one or more layers among the application framework layer, the local layer, the hardware abstraction layer, and the kernel layer; this application does not specifically limit this.

[0085] The file access feature analysis module is used to statistically analyze the access characteristics of various files on the mobile phone. For example, the file access feature analysis module can be used to count the number of times a file is read and written, the amount of data read and written, and analyze the access characteristics based on the statistical results.

[0086] For example, the file access feature analysis module includes the following functional modules: statistical period control, access information collection, and read / write feature analysis.

[0087] Statistical period control can be used to control the statistical period and duration. For example, a statistical period of one month and a statistical duration of five days can control the statistical analysis to be performed once a month, with five days of data collected each time. Furthermore, the statistical period can be fixed, such as one month or one week. Alternatively, the statistical period can also be dynamically changed based on user habits, such as a shorter period for more newly added files.

[0088] Access information collection can be used to collect access information such as the number of read / write operations and the amount of data read / written within the statistical period after the statistical period has ended.

[0089] Read / write feature analysis can be used to analyze the collected access information and obtain access features. For example, read / write feature analysis can analyze the file access strength value of each file based on the number of read / write operations and the amount of data read / written. For details of this process, please refer to the description of the relevant steps in the method embodiment below, which will not be described in detail here.

[0090] The file data feature analysis module can be used to analyze the compressed data characteristics of various compression algorithms, such as compression ratio, compression time, and decompression time. It should be understood that compression time refers to the time taken to compress a unit of data. Similarly, decompression time refers to the time taken to decompress a unit of data. For example, the unit of data might be 128KB or 64KB.

[0091] Furthermore, the compressed data characteristics of various compression algorithms can include the compressed data characteristics of various types of files compressed using different compression algorithms on the current mobile phone. The following text will primarily use this compressed data characteristic as an example for explanation.

[0092] For example, the file data feature analysis module includes the following functional modules: file type management, compression ratio analysis, and decompression performance analysis.

[0093] File type management is used to manage the file types on your phone. File types include documents, images, videos, audio files, installation packages, executable files, etc. For example, file types can be .apk, .jpg, .txt, .so, .TTF, .odex, .vdex, .png, .zip, .js, .map, .mp3, .mp4, .css, .xml, .jar, .log, etc.

[0094] It should be noted that for some unrecognized file types, such as files without an extension, they can be treated as the default type.

[0095] Compression ratio analysis and decompression performance analysis can be used to test and obtain the compression data characteristics of various types of files using different compression algorithms. For example, it can test and obtain the compression ratio, compression time, and decompression time of .so files using compression algorithms such as zstd, lz4, and zlib.

[0096] The file compression algorithm and parameter management module can be used to match the optimal compression algorithm for each file based on the user's access characteristics to each file and the compression data characteristics of various compression algorithms.

[0097] Here's a brief explanation of the parameters in parameter management: The same compression algorithm may have different versions, and within the same version, there can be different compression standards. Different versions and different compression standards are equivalent to different compression parameters. In other words, the parameters in parameter management can include version and / or compression standard.

[0098] Taking zstd in Table 1 above as an example, 1.5.6-1 and 1.5.6 are two different versions of zstd, fast=1 and fast=3 are versions, and 1.5.6 is two different compression standards.

[0099] Furthermore, compression ratio analysis and decompression performance analysis can test the compression data characteristics of various file types using different compression algorithms and parameters. Taking zstd as an example, the compression ratio, compression time, and decompression time of zstd 1.5.6-1, zstd 1.5.6--fast=1, and zstd 1.5.6--fast=3 for the same type of file were tested.

[0100] F2FS is an append-logged file system specifically designed for flash memory devices. Utilizing F2FS's compression capabilities, it can be used for most types of file compression, as well as volume (partition) compression. For example, F2FS can be used to compress document files (such as .txt, .doc, .ppt, etc.), system configuration files, application files, and other similar files.

[0101] The file compression method provided in this application embodiment can be executed in a terminal device with the above-described hardware and software structure.

[0102] File compression methods can include the following two stages: Stage 1, data preparation stage; Stage 2, compression stage.

[0103] Phase 1 mainly includes the following two processes: Process 1, testing to obtain compressed data characteristics; Process 2, analyzing to obtain file access characteristics. These are explained below:

[0104] Step 1: Test to obtain compressed data characteristics

[0105] The characteristics of compressed data can include compression ratio, compression time, and decompression time.

[0106] The characteristics of compressed data are typically related to the following factors: Factor 1, the type of file being compressed; Factor 2, the compression algorithm and / or parameters.

[0107] In Factor 1, the same compression algorithm and / or parameters result in different compression ratios for different file types. Different file types have significantly different data formats, and consequently, different compression ratios. For example, .dex and .so files contain code and executable data, resulting in relatively high compression ratios; .apk files are compressed archives with low compression ratios; and .mp4, .jpg, and other media files are inherently compressed, also resulting in relatively low compression ratios.

[0108] In Factor 2, for the same file type, the compression ratio, compression time, and decompression time also differ depending on the compression algorithm and / or parameters used. For example, for the same file, zstd compression results in a higher compression ratio but a longer decompression time, while lz4 compression results in a lower compression ratio but a shorter decompression time.

[0109] Based on factors 1 and 2 above, in some embodiments, during process 1, the terminal device (such as a file data feature analysis module) can test the compressed data characteristics of various file types after compression using various compression algorithms and / or parameters. For example, the terminal device can combine compression algorithms and / or parameters with file types and perform compression tests. For instance, if there are x compression algorithms and / or parameters and y file types, resulting in x*y possible combinations, the terminal device can test the compressed data characteristics of these x*y combinations.

[0110] In one specific implementation, at least one file of each file type can be selected, and compressed and then decompressed using different compression algorithms and / or parameters to obtain the compressed data characteristics corresponding to that type of file.

[0111] For example, the characteristics of the obtained compressed data are shown in Table 2 below:

[0112] Table 2

[0113]

[0114] Of course, process 1 can also be executed by other devices besides the terminal device itself, and this application does not specifically limit this.

[0115] Furthermore, the characteristics of compressed data may also be related to the performance of the terminal device (denoted as factor 3).

[0116] In factor 3, different terminal devices have different hardware and software configurations, such as different CPU, memory, and storage configurations. Consequently, their decompression capabilities also differ, meaning their decompression efficiency varies. Therefore, for files of the same size, the decompression time will differ. Based on this, in some embodiments, process 1 is executed on the terminal device itself or on a device with the same configuration as the terminal device to obtain the compressed data characteristics under the configuration of the terminal device.

[0117] The above process 1 can be executed when the terminal device is idle. For example, the terminal device can execute process 1 when the screen is off, or when the screen is off and the device is charging.

[0118] Step 2: Analyze the access characteristics of the files.

[0119] For example, the terminal device can execute process 2 through the file access feature analysis module.

[0120] Among them, access characteristics can reflect the intensity of a user's access to a file.

[0121] In some embodiments, the terminal device can use a file access strength value to reflect access intensity. A higher file access strength value indicates a higher requirement for access efficiency, and a greater performance impact of compression on file access. For example, if a file is accessed very frequently, its access strength value will be high, requiring efficient access each time. Even a slight decrease in access efficiency due to compression can significantly impact the user experience; that is, compression has a substantial performance impact on file access.

[0122] In one specific implementation, see Figure 6 The steps to obtain the file access strength value include:

[0123] S601. Determine the statistical period.

[0124] The statistical period is used to determine when to collect and analyze access characteristics. For example, if the statistical period is one month, then access characteristics will be collected and analyzed once a month.

[0125] In some embodiments, the statistical period is dynamically changed, and the terminal device can dynamically adjust the statistical period according to the user's usage habits.

[0126] For example, within a specific time period 1, such as the period from the end of the last statistical analysis to the current period, the more new files added to the terminal device, the shorter the statistical period can be configured, such as 1 week. Conversely, the fewer new files added to the terminal device, the longer the statistical period can be configured, such as 2 weeks. In this way, the terminal device can promptly analyze the access characteristics of a large number of newly added files.

[0127] For example, within a specific time period 2, if the screen-on duration (also known as screen usage time) of the terminal device reaches a preset duration from the end of the previous statistical period to the current period, the statistical period can be configured to be shorter; if the screen-on duration does not reach the preset duration, the statistical period can be configured to be longer. A longer screen-on time indicates a longer usage period for the terminal device, resulting in more files being generated. In this way, the terminal device can promptly analyze the access characteristics of newly added files within a prolonged usage period.

[0128] It should be noted that the initial value of the statistical period can be a default value, such as one month. Subsequently, the terminal device can adjust the statistical period based on user habits.

[0129] Of course, the statistical period can also be a fixed value, such as one month. In this case, S601 can be omitted.

[0130] S602. After the statistical period is reached, file access information for each file is collected within the statistical duration. The file access information includes the number of read / write operations and / or the amount of data read / written.

[0131] The term "reaching the statistical period" refers to the time interval since the last statistical analysis. For example, if the statistical period is one month, and the last statistical analysis was conducted on August 12th, then September 12th would mark the end of the statistical period.

[0132] The statistical duration refers to the duration of the statistics. For example, a statistical duration of 5 days means that file access information within 5 days will be collected.

[0133] The read / write count can be further divided into read counts and write counts. Read counts refer to the number of times the terminal device reads data from the file, while write counts refer to the number of times the terminal device writes data to the file. It can be understood that both reading and writing are forms of file access.

[0134] The read / write data volume service can be further divided into read data volume and write data volume. Read data volume refers to the amount of data that the terminal device reads from the file, while write data volume refers to the amount of data that the terminal device writes to the file.

[0135] After the statistical period ends, the terminal device can collect cumulative read counts, write counts, read data volume, and write data volume for each file within the statistical duration. After the statistical duration ends, the terminal device can terminate the statistical analysis. For example, after the statistical analysis is completed, the terminal device can obtain the file access information shown in Table 3 below:

[0136] Table 3

[0137]

[0138] The access information obtained from the above statistics can be used for subsequent analysis to obtain the access characteristics of the files.

[0139] It should be noted that S601 above tests file data characteristics according to file type, while S602 collects file access information based on individual files.

[0140] S603. Calculate the access strength value of each file based on the file access information of each file.

[0141] In some embodiments, the terminal device (such as the file compression algorithm and parameter management module) can calculate the write heat, read heat and read mode coefficient based on the file access information, and then calculate the access intensity value based on the write heat, read heat and read mode coefficient.

[0142] This application embodiment exemplarily describes write heat, read heat, and read mode coefficient, as well as the corresponding calculation process.

[0143] Write the popularity

[0144] Write popularity reflects the frequency of writing data to a file (referred to as write frequency). The higher the write frequency, the higher the write popularity.

[0145] In one specific implementation, write heat can be divided into multiple levels, each level corresponding to a range of write frequencies. Taking a write heat divided into 3 levels as an example, the relationship between write heat and write frequency (p) can be shown in Table 4 below:

[0146] Table 4

[0147] Write frequency Write the popularity p<5(T_w1) 3(w1) 5≤p<10(T_w2) 10(w2) p≥10 20(w3)

[0148] Table 4 above can be interpreted as follows: when the file's write frequency does not exceed the threshold T_w1, the write heat is w1; when the file's write frequency is greater than the threshold T_w1 but does not exceed the threshold T_w2, the write heat is w2; when the file's write frequency is greater than the threshold T_w2, the write heat is w3.

[0149] The write frequency can be obtained based on the number of writes collected above.

[0150] For example, the write frequency is equal to the number of writes within the statistical period. For instance, in Table 3 above, the write frequency of file 2 is equal to 30 writes. This article primarily uses this as an example.

[0151] For another example, the write frequency is equal to the number of writes within a unit of time (such as 1 day, 1 hour, etc.). Taking a statistical period of 5 days and a unit of time of 1 day as an example, the write frequency of file 1 in Table 3 above is equal to 30 / 5, that is, 6 times / day.

[0152] Read popularity

[0153] Read popularity reflects the relationship between the frequency of data read from a file (referred to as read frequency) and the file size. For files of the same size, a higher read frequency means a greater likelihood that all data in the file will be read, resulting in higher read popularity. For files of different sizes with the same read frequency, smaller files have a greater likelihood that all data will be read, resulting in higher read popularity.

[0154] In one specific implementation, the file size is represented by the number of compressed blocks. The number of compressed blocks refers to the number of blocks obtained after dividing the file according to the compressed block size. The compressed block size can be a fixed value, such as 128K. Alternatively, the compressed block size is related to the file size; the larger the file size, the larger the compressed block size. This application does not impose specific limitations on this.

[0155] It should be noted that the compression in the compressed block here is only a theoretical calculation and does not represent the actual compression of the file.

[0156] The read heat is the ratio of read frequency to the number of compressed blocks. The result can be rounded up, or it can be left unrounded. This application does not specifically limit this; the following mainly uses the rounding method as an example. For example, the relationship between the ratio of read frequency to the number of compressed blocks (q) and the read heat is shown in Table 5 below:

[0157] Table 5

[0158] Read frequency / number of compressed blocks Read popularity q≤1 1 1<q≤2 2 2<q≤3 3 …… ……

[0159] Table 5 above indicates that: when the ratio of file read frequency to the number of compressed blocks is less than or equal to 1, the read frequency is 1; when the ratio is greater than 1 and less than or equal to 2, the read frequency is 2; when the ratio is greater than 2 and less than or equal to 3, the read frequency is 3...

[0160] It's important to note that after a file is compressed, data is accessed and decompressed in blocks. A single compressed block is 128KB in size. Even if only 1KB of data is read, the entire 128KB compressed block must be accessed and decompressed. In other words, 128KB of data is actually read. Therefore, using the number of compressed blocks to represent file size on the terminal device matches the actual reading unit of the compressed file, allowing for a more accurate assessment of read activity.

[0161] Similar to the write frequency mentioned above, the read frequency can also be obtained based on the number of reads collected above. For example, in Table 3 above, the read frequency of file 2 is equal to the number of reads, which is 10.

[0162] Read pattern coefficients

[0163] The read mode coefficient reflects the utilization rate of decompressed data. As explained earlier, after a file is compressed, data is accessed and decompressed block by block. If a small amount of data is read, but the entire compressed data block is actually read for decompression, the utilization rate of the decompressed data will be low. Conversely, if a large amount of data is read, the decompressed data can be fully utilized, resulting in a high utilization rate. Therefore, generally, the larger the amount of data read, the more fully the decompressed data can be utilized.

[0164] In one specific implementation, the read mode coefficient can be represented by the ratio of the compressed block size to the average data size of the read data (hereinafter referred to as the average read block size), that is, read mode coefficient (denoted as c) = compressed block size / average read block size.

[0165] If c≤1, it means the compressed block size is less than or equal to the average read block size, resulting in high utilization and no waste during decompression. Based on this, the case where c≤1 can be uniformly set to c=1.

[0166] If c > 1, it means that the compressed block size is larger than the average read block size, and the larger c is, the lower the utilization rate, resulting in more serious waste during decompression.

[0167] The average block size can be calculated from the amount of data read and the number of reads collected earlier. For example, the average block size = amount of data read / number of reads. For instance, in Table 3 above, the amount of data read for file 2 is 200K, and the number of reads is 10, so the average block size is 20K.

[0168] After calculating the write heat, read heat, and read mode coefficients for each file, the terminal device can further calculate the access intensity value of the file based on the write heat, read heat, and read mode coefficients of each file.

[0169] In one specific implementation, the access intensity value is the sum of the product of read popularity and read mode coefficient, and write popularity. That is, access intensity value = write popularity + read popularity * read mode coefficient. In practice, the terminal device can also assign weights to the product of read popularity and read mode coefficient, and write popularity separately, and then sum them. For example, the terminal device can assign weights to read and write performance requirements based on the application or business scenario to which the file belongs. For instance, in applications such as games and video players, where read data requirements are higher, a higher weight can be assigned to the product of read popularity and read mode coefficient. Similarly, in Word, where write data requirements are higher, a higher weight can be assigned to write popularity.

[0170] Of course, the calculation of access strength value is not limited to this. In another specific implementation, the terminal device can also sum or weightedly sum the read and write activity to calculate the access strength value.

[0171] Therefore, it should be noted that in actual implementation, the terminal device can also calculate other access characteristics based on the collected file access information and use them for subsequent matching of compression algorithms and parameters; this application does not specifically limit this. In other embodiments, the terminal device can also sum the number of reads and writes, and sum the amount of read data and the amount of write data, and then perform a weighted summation of the two to obtain the access characteristics. Alternatively, the terminal device can directly determine the file access characteristics as the sum of the number of reads and writes, or the sum of the amount of read data and the amount of write data.

[0172] Phase 2 mainly includes the following two processes: process 3, triggering compression; process 4, matching the target compression algorithm and parameters and compressing.

[0173] Process 3, trigger compression.

[0174] In some embodiments, the terminal device can automatically trigger compression. The terminal device can automatically trigger compression based on information such as time, the storage status of the terminal device, and the usage of files on the terminal device.

[0175] For example, the terminal device can automatically trigger compression at a timed interval, such as a preset time interval since the last compression.

[0176] As another example, a terminal device can automatically trigger compression after the number of infrequently used files on the local machine reaches a preset number.

[0177] In other embodiments, the terminal device may also passively trigger compression based on user actions. For example, the user's action may be a trigger operation for "compression" 2031 in the aforementioned interface 203. Of course, this is not a limitation in actual implementation.

[0178] Step 4: Match the target compression algorithm and parameters and compress.

[0179] For example, the terminal device can execute process 4 through the file compression algorithm and parameter management module.

[0180] In process 4, the terminal device can match the target compression algorithm and parameters for each file and compress it. It should be noted that for files of the default type mentioned earlier, the terminal device directly determines the target compression algorithm and parameters as the default compression algorithm and parameters, such as lz4. Of course, for files of the default type, the terminal device may not need to analyze access characteristics in process 2 mentioned earlier.

[0181] In some embodiments, for any file, the terminal device can determine the file's decompression efficiency requirements (such as decompression time) based on the file's access characteristics, such as access strength values. Then, the terminal device selects a target compression algorithm from candidate compression algorithms and parameters that meet the decompression efficiency requirements, based on the compression ratio. In this way, the terminal device can prioritize meeting the file's decompression efficiency requirements and further select a compression algorithm with a better compression ratio to compress the file. This allows for the matching of compression algorithms that minimize space usage while meeting the decompression efficiency requirements (which is also equivalent to meeting the access efficiency requirements).

[0182] In one specific implementation, see Figure 7 The steps for matching the target compression algorithm and compressing include:

[0183] S701, in response to compression events, acquires access characteristics of multiple files and compression data characteristics of various compression algorithms and parameters.

[0184] Compression events refer to events that trigger compression, such as the compression timeout, the number of infrequently used files reaching a preset number, or the receipt of a compression operation from a user.

[0185] Upon receiving a compression event, the terminal device can first obtain the data prepared in Phase 1, such as access characteristics and compressed data characteristics, to match the target compression algorithm.

[0186] S702. For any file, determine the maximum acceptable decompression efficiency of the file based on its access characteristics.

[0187] Among these, a higher access intensity, indicating a higher frequency of file read / write operations, necessitates higher decompression efficiency—that is, faster decompression completion. Based on this, terminal devices can match the decompression efficiency requirements corresponding to the access characteristics, such as the maximum acceptable decompression efficiency.

[0188] Taking access characteristics as access strength values ​​and maximum acceptable decompression efficiency as maximum acceptable decompression time as an example, the access strength value (z) and maximum acceptable decompression time are shown in Table 6 below:

[0189] Table 6

[0190] Access strength value Maximum acceptable decompression time (ms) z<1 10 1≤x<5 7 5≤x<10 5 10≤x<15 3 x>15 Uncompressed

[0191] The terminal device can match the access strength value of the file with Table 6 above to obtain the maximum acceptable decompression time corresponding to the range of access strength values.

[0192] Furthermore, when the access intensity reflected by the access characteristics exceeds a certain threshold, it indicates that the file has high requirements for decompression efficiency and is not suitable for compression. Based on this, the terminal device can detect whether the access characteristics exceed the corresponding characteristic threshold. If so, it determines that the file should not be compressed. For example, if the file's access characteristics include the sum of the number of times data is read and written, then when the sum of the number of times data is read and written exceeds a certain threshold, the terminal device can determine that the file should not be compressed.

[0193] Taking Table 6 above as an example, if the access strength value of a file is greater than 15, it will not be compressed.

[0194] S703. Select the target compression algorithm and parameters with the highest compression ratio from the candidate compression algorithms and parameters that meet the maximum acceptable decompression efficiency.

[0195] Various compression algorithms and parameters have corresponding compressed data characteristics, including compression ratio, compression time, and decompression time. Terminal devices can filter out candidate compression algorithms and parameters from all compression algorithms and parameters that meet the maximum acceptable decompression efficiency (such as decompression time).

[0196] For example, the terminal device can filter out candidate compression algorithms and parameters whose decompression time is less than or equal to the maximum acceptable decompression time.

[0197] It should be noted that the terminal device should select candidate compression algorithms and parameters based on the compressed data characteristics of the file type to which the current file (any file in S702) is compressed using various compression algorithms and parameters.

[0198] For example, if the current file belongs to type 1, the terminal device can filter out candidate compression algorithms and parameters from the multiple compressed data features corresponding to type 1 in Table 2 above, such as the data in rows 2 to 6, to find that the decompression time is less than or equal to the maximum acceptable decompression time of the current file.

[0199] The terminal device employs different candidate compression algorithms and parameters, resulting in varying compression ratios depending on the file type of the current file. The terminal device can select the target compression algorithm and parameters with the highest compression ratio from the candidate algorithms and parameters to compress the current file. This satisfies the user's requirements for decompression efficiency while minimizing space usage.

[0200] Taking the current file as type 1 and the candidate compression algorithms and parameters as a1, a2 and a3 in Table 2 as an example, a1 has a compression ratio of 1.5 for type 1 files, a2 has a compression ratio of 2.2 for type 1 files, and a3 has a compression ratio of 3.5 for type 1 files. The terminal device can choose a3 as the target compression algorithm and parameter.

[0201] Of course, the way in which the terminal device selects the target compression algorithm and parameters from the candidate compression algorithms and parameters is not limited to the way shown in S703 above.

[0202] In other embodiments, the terminal device can also select a target compression algorithm and parameters based on a comprehensive score of decompression time and compression ratio. The shorter the decompression time, the higher the decompression time score; the higher the compression ratio, the higher the compression ratio score. The comprehensive score is the sum of the decompression time score and the compression ratio score. In this way, the terminal device can select the target compression algorithm that best balances decompression efficiency and space usage from the candidate compression algorithms and parameters.

[0203] Taking the current file type as type 1 and the candidate compression algorithms and parameters as a1, a2 and a3 in Table 2 as an example, the terminal device can give a comprehensive score to a1 based on a compression ratio of 1.5 and a decompression time of 2ms, give a comprehensive score to a2 based on a compression ratio of 2.2 and a decompression time of 2ms, and give a comprehensive score to a3 based on a compression ratio of 3.5 and a decompression time of 5ms.

[0204] In other embodiments, the terminal device may further select a target compression algorithm based on the compression ratio, or based on the compression ratio and decompression time, and further in combination with the compression time.

[0205] Understandably, the compression process can be completed in the background, making it less noticeable to the user. Alternatively, the compression process can be visible in the foreground, as shown in the previous interface 204. If the compression process is visible in the foreground, a longer compression time means lower compression efficiency and a longer waiting time for the user. Therefore, by using compression time as a reference factor when selecting target compression algorithms and parameters, terminal devices can further consider compression efficiency and achieve faster compression.

[0206] Furthermore, when the compression ratio of the compression algorithm and parameters is too low, such as below 1.5, it indicates that compression cannot significantly reduce space usage. On the contrary, using this compression algorithm and parameters for compression and subsequent decompression will lead to greater resource overhead. Based on this, in the various embodiments of S703 mentioned above, before selecting the target compression algorithm and parameters, the terminal device can also filter out candidate compression algorithms and parameters with compression ratios lower than the compression ratio threshold. This allows the target compression algorithm and parameters to be selected from candidate compression algorithms and parameters with higher compression ratios, resulting in a significant reduction in space usage after compression.

[0207] Furthermore, if the compression ratio of all candidate compression algorithms and parameters is lower than the compression ratio threshold, then no candidate compression algorithms and parameters remain after filtering, and the terminal device can choose not to compress the current file, thereby reducing unnecessary resource consumption. If the compression ratio of at least two candidate compression algorithms and parameters is higher than the compression ratio threshold, then at least two candidate compression algorithms and parameters still exist after filtering, from which the terminal device can select the target compression algorithm and parameters. If only one candidate compression algorithm and parameter has a compression ratio higher than the compression ratio threshold, then one candidate compression algorithm and parameter still exists after filtering, and the terminal device can directly use that single candidate compression algorithm and parameter as the target compression algorithm and parameters.

[0208] S704. Compress files using the target compression algorithm and parameters.

[0209] For example, for the current file, the target compression algorithm and parameters selected by the terminal device are a3, and the terminal device can use a3 to compress the current file.

[0210] In this way, for each file, the terminal device can match a target compression algorithm and parameters that meet the requirements of decompression efficiency and greatly reduce space usage, and use it to compress the file.

[0211] To further deepen the understanding of the above embodiments, the following will be combined with Figure 8To briefly summarize the process of this application embodiment, the terminal device can perform compression on files involved in infrequently used applications (such as APP1, APP2, etc.). Specifically, the terminal device can obtain the compression data characteristics of the file types (such as apk, jpg, txt, etc.) to which these files belong, such as compression efficiency (expressed by compression time), decompression efficiency (expressed by decompression time), compression ratio, etc. Furthermore, the terminal device can also obtain the access characteristics of these files, including access characteristics obtained from analyzing various access methods such as random read / write and sequential read / write. Finally, for any of these files, the terminal device can perform algorithm matching based on the compression data characteristics corresponding to the file type to which the file belongs and the access characteristics of the file, and select a target compression algorithm and parameters, such as selecting a target compression algorithm and parameters from algorithms and parameters a1, a2, etc., for compressing the file.

[0212] This application also provides an electronic device, which may include a memory and one or more processors. The memory and processors are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device can perform various functions or steps performed by the mobile phone in the above method embodiments to achieve file compression.

[0213] This application also provides a chip system, such as... Figure 9 As shown, the chip system 900 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901). Exemplarily, the interface circuit 902 can read instructions stored in the memory and send those instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete components, and this application embodiment does not specifically limit this.

[0214] This embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the various functions or steps performed by the mobile phone in the above method embodiment to achieve file compression.

[0215] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps performed by the mobile phone in the above method embodiment, thereby achieving file compression.

[0216] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to enable the chip to perform the various functions or steps performed by the mobile phone in the above method embodiments, thereby achieving file compression.

[0217] In this embodiment, the electronic device, communication system, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0218] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0219] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0220] The unit described as a separate component may or may not be physically separate. The component shown as a unit can be one physical unit or multiple physical units, that is, it can be located in one place or distributed in multiple different places. Some or all of the units can be selected to achieve the purpose of the solution in this embodiment according to actual needs.

[0221] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0222] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0223] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A file compression method, characterized in that, Applied to terminal devices, including: The target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belong are obtained. The file to be compressed is a file in the terminal device. The target access characteristics are used to indicate the access intensity of the file to be compressed. The compression performance data includes the compression performance data of various compression algorithms for compressing the target file type. The compression performance data includes decompression efficiency and compression ratio. Based on the target access characteristics and compression performance data, a target compression algorithm is obtained by matching from multiple compression algorithms. The decompression efficiency of the target compression algorithm meets the efficiency requirements corresponding to the target access characteristics, and the compression performance data of the target compression algorithm meets the matching conditions. The file to be compressed is compressed using the target compression algorithm.

2. The method according to claim 1, characterized in that, The compression performance data also includes compression efficiency.

3. The method according to claim 2, characterized in that, The compression performance data of the target compression algorithm meets the matching conditions, including: The target compression algorithm is the candidate compression algorithm with the highest compression ratio that meets the efficiency requirements corresponding to the target access characteristics.

4. The method according to any one of claims 1-3, characterized in that, The terminal device stores the correspondence between access characteristics and efficiency requirements; The efficiency requirements corresponding to the target access feature include: the efficiency requirements corresponding to the target access feature in the correspondence.

5. The method according to any one of claims 1-4, characterized in that, The process of matching a target compression algorithm from multiple compression algorithms based on the target access characteristics and compression performance data includes: If the target access feature is lower than the feature threshold, a target compression algorithm is selected from multiple compression algorithms based on the target access feature and compression performance data.

6. The method according to claim 5, characterized in that, If the target access characteristics are higher than the characteristic threshold, the file to be compressed will not be compressed.

7. The method according to any one of claims 1-6, characterized in that, The process of matching a target compression algorithm from multiple compression algorithms based on the target access characteristics and compression performance data includes: Select a candidate compression algorithm from a variety of compression algorithms whose compression efficiency meets the efficiency requirements corresponding to the target access characteristics; The target compressed file is selected based on the compression performance data of the candidate compression algorithms.

8. The method according to claim 7, characterized in that, The selection of the target compression algorithm based on the compression performance data of the candidate compression algorithms includes: If at least two of the candidate compression algorithms have compression ratios higher than a compression ratio threshold, a target compression algorithm is selected based on the compression performance data of the at least two compression algorithms.

9. The method according to claim 8, characterized in that, The method further includes: If the compression ratio of one of the candidate compression algorithms is higher than the compression ratio threshold, the file to be compressed is compressed based on the selected compression algorithm.

10. The method according to claim 8 or 9, characterized in that, If the compression ratio of each of the candidate compression algorithms is lower than the compression ratio threshold, the file to be compressed will not be compressed.

11. The method according to any one of claims 1-10, characterized in that, The same compression algorithm includes one or more sets of compression parameters, and the compression performance data includes compression performance data of various compression algorithms and parameters for compressing the target file type respectively; The step of matching a target compression algorithm from multiple compression algorithms and compressing the file to be compressed using the target compression algorithm includes: The target compression algorithm and parameters are matched from a variety of compression algorithms and parameters, and the target compression algorithm and parameters are used to compress the file to be compressed.

12. The method according to any one of claims 1-11, characterized in that, The acquisition of the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs includes: If the file to be compressed is a preset type file, obtain the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs.

13. The method according to claim 12, characterized in that, The method further includes: If the file to be compressed is not a preset file type, the preset compression algorithm is used to compress the file.

14. The method according to any one of claims 1-13, characterized in that, Before obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs, the method further includes: Collect access information of the file to be compressed, the access information including at least one of the following: number of reads, number of writes, amount of data read, and amount of data written; The access characteristics are obtained based on the access information.

15. The method according to claim 14, characterized in that, The access characteristics include an access strength value; The process of analyzing the access information to obtain the access characteristics includes: Based on the access information, the write heat, read heat and read mode coefficient of the file to be compressed are calculated. The write heat reflects the frequency of writing data to the file to be compressed, the read heat reflects the relationship between the frequency of reading data from the file to be compressed and the file size of the file to be compressed, and the read mode coefficient reflects the utilization rate of the data after decompression when reading data from the file to be compressed. The access intensity value of the file to be compressed is calculated based on the write heat, read heat, and read mode coefficient.

16. The method according to any one of claims 1-15, characterized in that, Before obtaining the target access characteristics of the file to be compressed and the compression performance data of the target file type to which the file to be compressed belongs, the method further includes: In the terminal device, the compression performance data of various compression algorithms for the target file type are tested.

17. A terminal device, characterized in that, include: A display screen, one or more processors, and one or more memories; the one or more processors are coupled to the display screen and the one or more memories; the one or more memories are used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the terminal device to perform the method as described in any one of claims 1-16.

18. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed on a terminal device, the terminal device causes the terminal device to perform the method as described in any one of claims 1-16.

19. A computer program product comprising computer instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-16.

Images