CN116701327A

CN116701327A - File processing method and electronic equipment

Info

Publication number: CN116701327A
Application number: CN202211566654.1A
Authority: CN
Inventors: 李珺珂
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-12-07
Filing date: 2022-12-07
Publication date: 2023-09-05

Abstract

A file processing method and electronic equipment relate to the technical field of data compression and can finish space cleaning of the electronic equipment under the condition that a user does not feel. The electronic equipment displays a first interface, metadata of a first file is included in the first interface, the metadata of the first file includes a file name and a file size of the first file, and the first file is any file in the electronic equipment. And under the condition that the preset condition is met, the electronic equipment automatically compresses the first file to obtain the second file. The electronic device deletes the first file and stores the second file in a storage position of the first file. The electronic device displays a second interface, wherein the second interface comprises metadata of a second file, and the metadata of the second file comprises a file name and a file size of the second file. The file name of the second file is the same as the file name of the first file, the file name comprises a main name and an extension, and the file size of the second file is smaller than that of the first file.

Description

File processing method and electronic equipment

Technical Field

The present application relates to the field of data compression technologies, and in particular, to a file processing method and an electronic device.

Background

Research data indicate that insufficient storage space is one of the main reasons for a user to replace an electronic device. Particularly for electronic devices with limited storage space, such as 128GB cell phones, there is often a risk of insufficient storage space after two years. Moreover, as the use time increases, the storage space occupied by applications, videos, pictures and other data in the electronic device will remain linearly increasing, seriously affecting the use of the electronic device.

However, in the process of implementing the embodiment of the present application, the inventor finds that in the prior art, a user is generally required to manually clean, such as delete, data in the electronic device, or compress the data in the electronic device, so as to release the storage space in the electronic device, which is complicated in process.

Disclosure of Invention

In view of the above, the present application provides a file processing method and an electronic device, which can complete the space cleaning of the electronic device without perception of a user.

In a first aspect, an embodiment of the present application provides a file processing method, which may be applied to electronic devices such as a mobile phone, a tablet, and the like that need to clean a storage space. The electronic device may display a first interface, where the first interface includes metadata of a first file, where the metadata of the first file includes a file name of the first file, and the first file is any file in the electronic device. And under the condition that the preset condition is met, the electronic equipment automatically compresses the first file to obtain the second file. The file size of the second file is smaller than the file size of the first file. The electronic device deletes the first file and stores the second file in a storage position of the first file. The electronic device displays a second interface, wherein the second interface comprises metadata of a second file, and the metadata of the second file comprises a file name and a file size of the second file. The file name of the second file is the same as the file name of the first file, and the file name comprises a main name and an extension.

In summary, in the application, the electronic device can automatically complete the compression processing without manual operation by a user, thereby saving the storage space. And before and after compression, the user can look up the same file name from the same storage location, so that the user cannot perceive that the file is compressed.

In one possible design manner of the first aspect, the metadata of the first file further includes at least one of a generation time, an author, a thumbnail, and a storage location of the first file, and the metadata of the second file further includes at least one of a generation time, an author, a thumbnail, and a storage location of the second file. And, the generation time, author, thumbnail, and storage location of the second file are the same as the generation time, author, thumbnail, and storage location of the second file.

That is, the metadata of the file remains substantially unchanged before and after compression. Thus, even if the user enters a detail page of metadata, it is not easy to find that the file is compressed.

In another possible design manner of the first aspect, the foregoing meets a preset condition, including at least one of the following:

the current time reaches a timing time, which is a time when the user does not use the electronic device. That is, the file may be compressed at idle time.

The battery power of the electronic device is higher than the preset power. That is, the file can be compressed when the amount of power is sufficient.

And the load of the CPU of the electronic device is lower than the preset load. That is, the file can be compressed when the load of the electronic device is low.

the time that the first file was last used, the time interval from the current time exceeds a preset duration. That is, the first file is a cold file that is unused for a long time. That is, the electronic device can compress the cold files which are not used for a long time, so that the files which are not used for a long time are prevented from occupying excessive storage space, and the compression efficiency is improved.

The first file is an uncompressed file. The compression efficiency is low because the compressed files are compressed again, and the storage space is not saved obviously. Based on the method, the uncompressed file is compressed, so that the effect of saving storage space caused by compression is remarkably improved. Namely, the compression efficiency is improved.

And the first file is a file with an extension of the first extension or with a coding format of the first coding format. In the electronic device, the number of files with partial formats is large, and the data volume of each file is large, and a large amount of storage space is occupied. For example, the JPEG format of picture files and h.264 encoded video files produced by camera applications typically occupy a significant amount of memory space in a cell phone. Files other than these are either small in number or small in data size per file, typically taking up less memory space. For example, PNG format web page pictures, which typically occupy little storage space. Based on the method, the compression is mainly performed on the files with specific expansion names or specific coding formats which occupy larger storage space, so that the effect of saving the storage space caused by compression can be remarkably improved, namely the compression efficiency is improved.

In another possible design manner of the first aspect, the method further includes: if the first file is a picture file and the first tag is not included in the metadata of the first file, it is determined that the first file is an uncompressed file. The first label is used for indicating that the first file is a file obtained by automatic compression of the electronic equipment.

That is, the electronic device may accurately determine whether the picture file is a compressed file based on the first tag. Therefore, the picture file which is not automatically compressed by the electronic equipment can be compressed, and the compression efficiency is improved.

In another possible design of the first aspect, if the first file is a video file and the encoding format of the first file is not the second encoding format, it is determined that the first file is an uncompressed file. Wherein the second encoding format is an encoding format employed when the electronic device automatically compresses the video file.

That is, the electronic device can accurately determine whether the video file is a compressed file based on the encoding format. Therefore, video files which are not automatically compressed by the electronic equipment can be compressed, and the compression efficiency is improved.

In another possible design manner of the first aspect, if the first file is not a picture file or a video file, and the extension of the first file is the second extension, or the metadata of the first file includes the first tag, it is determined that the first file is an uncompressed file. The second preset extension name is an extension name of a file obtained by compression of a user, and the first label is used for indicating that the first file is a file obtained by automatic compression of electronic equipment.

That is, for files other than the picture file and the video file, whether the file is a file obtained by manual compression by a user can be determined based on the extension, whether the file is a file obtained by automatic compression by an electronic device can be determined based on the tag, so that whether the file is a file obtained by compression can be accurately determined, the file obtained by compression is compressed, and compression efficiency is improved.

In another possible design manner of the first aspect, the method further includes: the electronic equipment displays a third interface, wherein the third interface comprises a first control, and the first control is used for starting a file compression function. And the electronic equipment responds to the preset operation of the user on the first control, and records a second label which indicates that the file compression function is started. The electronic device automatically compresses a first file, including: in the case that the second tag is included in the electronic device, the electronic device automatically compresses the first file.

That is, the electronic device automatically compresses the file only after the user triggers the file compression function to be started, so that the compression meets the requirement of the user.

In another possible design of the first aspect, the third interface is an application interface of a first application, where the first application is used for managing all files in the electronic device; or the third interface is an application interface of a second application, and the second application is used for managing files of a preset type in the electronic equipment. The first application may be a cell phone manager application, a file management application, or the like. The second application may be an album application.

That is, the compression function, i.e., the full compression function, for all files in the electronic device may be turned on from the first application. The compression function, i.e. the partial compression function, of a part of the files in the electronic device, i.e. files of a preset type, may also be started from the second application.

In another possible design manner of the first aspect, the third interface is an application interface of the second application, where the meeting the preset condition includes: the first file is a file with a third extension, and the third extension is an extension included in a file of a preset type.

That is, after the partial compression function is turned on, the electronic device only compresses the file of the preset type, thereby realizing targeted compression of the file.

In another possible design manner of the first aspect, the electronic device automatically compresses the first file, including: if the first file is a video file, the electronic equipment adopts a second coding format to recode the video data of the first file, and recoded video data is obtained. And merging the recoded video data with the metadata of the first file to obtain a second file. And modifying the file size of the first file in the metadata of the first file to the file size of the second file to obtain the metadata of the second file.

In another possible design manner of the first aspect, the electronic device automatically compresses the first file, including: and if the first file is a picture file, the electronic equipment recodes the image data of the first file by adopting a third coding format to obtain recoded image data. And merging the recoded image data with the metadata of the first file to obtain a second file. And modifying the file size of the first file in the metadata of the first file to the file size of the second file to obtain the metadata of the second file.

In another possible design manner of the first aspect, the electronic device automatically compresses the first file, including: if the first file is not a picture file or a video file, the electronic device compresses the content data of the first file by adopting a preset compression algorithm to obtain compressed content data, wherein the preset compression algorithm is a compression algorithm provided by a flash-friendly file system F2 FS. And merging the compressed content data with the metadata of the first file to obtain a second file. And modifying the file size of the first file in the metadata of the first file to the file size of the second file to obtain the metadata of the second file.

That is, the electronic device can implement compression in different manners for different types of files, so as to improve the compression effect. And, after the electronic device completes the compression of the content data, the metadata of the file before the compression (i.e. the first file) is combined with the content data after the compression, so that the metadata of the file before the compression (i.e. the second file) can be used.

In another possible design manner of the first aspect, the method further includes: the first tag is added to the metadata of the second file. By adding the first tag, it is convenient to further determine whether the second file is a compressed file or not.

It should be noted that, the common encoding format of the video file can be easily read, so for the video file, whether the file is a compressed file can be determined directly based on the encoding format, without adding a tag. Thus, the number of times of adding the label can be reduced, and resources can be saved.

In another possible design manner of the first aspect, after obtaining the second file, the method further includes: and responding to the access operation of the user to the second file, decompressing the second file by the electronic equipment, and displaying the decompressed file content.

That is, for the file automatically compressed by the electronic device, if the access operation of the user is received, the file may be decompressed and then displayed. In this way, the content data for displaying the compressed file can be displayed without the user performing the decompression operation.

In another possible design manner of the first aspect, after obtaining the second file, the method further includes: and responding to the sharing operation of the user on the second file, and decompressing the second file by the electronic equipment to obtain the decompressed file. And sharing the decompressed file. Therefore, the files sent to other users can be ensured to be the files which are seen by the users in the mobile phone.

In a second aspect, embodiments of the present application also provide an electronic device including a display screen, a memory, and one or more processors. The display screen, the memory, and the processor are coupled. The memory is for storing computer program code comprising computer instructions which, when executed by the processor, cause the electronic device to perform the method of the first aspect and any of its possible designs.

In a third aspect, embodiments of the present application provide a chip system applied to an electronic device including a display screen and a memory; the system-on-chip includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected through a circuit; the interface circuit is configured to receive a signal from a memory of the electronic device and to send the signal to the processor, the signal including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method according to the first aspect and any one of its possible designs.

In a fourth aspect, the present application provides a computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any one of its possible designs.

In a fifth aspect, the present application provides a computer program product which, when run on a computer, causes the computer to perform the method according to the first aspect and any one of its possible designs.

It will be appreciated that the advantages achieved by the electronic device according to the second aspect, the chip system according to the third aspect, the computer storage medium according to the fourth aspect, and the computer program product according to the fifth aspect may refer to the advantages of the first aspect and any one of the possible designs thereof, which are not described herein.

Drawings

FIG. 1 is a diagram of a mobile phone interface according to an embodiment of the present application;

fig. 2 is a hardware configuration diagram of an electronic device according to an embodiment of the present application;

fig. 3 is a software architecture diagram of an electronic device according to an embodiment of the present application;

FIG. 4 is a second diagram of a mobile phone interface according to an embodiment of the present application;

FIG. 5 is a third diagram of a mobile phone interface according to an embodiment of the present application;

FIG. 6 is a flowchart illustrating a process of starting compression according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating a method for determining a file to be compressed according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a compression method for various files according to an embodiment of the present application;

FIG. 9 is a flowchart illustrating a compression process according to an embodiment of the present application;

FIG. 10 is a diagram of a mobile phone interface according to an embodiment of the present application;

FIG. 11 is a flowchart of file compression according to an embodiment of the present application;

FIG. 12 is a fifth diagram of a mobile phone interface according to an embodiment of the present application;

FIG. 13 is a sixth diagram of a mobile phone interface according to an embodiment of the present application;

FIG. 14 is a flowchart illustrating accessing a compressed file according to an embodiment of the present application;

fig. 15 is a block diagram of a chip system according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application are described below with reference to the accompanying drawings in the embodiments of the present application. In the description of embodiments of the application, the terminology used in the embodiments below is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the present application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include, for example, "one or more" such forms of expression, unless the context clearly indicates to the contrary. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" means one or more than two (including two). The term "and/or" is used to describe an association relationship of associated objects, meaning that there may be three relationships; for example, a and/or B may represent: a alone, a and B together, and B alone, wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise. The term "coupled" includes both direct and indirect connections, unless stated otherwise. The terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

Research data indicate that insufficient storage space is one of the main reasons for a user to replace an electronic device. Taking the electronic equipment as a mobile phone as an example, the reasons for the first three reasons of the passive mobile phone exchange ranking of the user are respectively as follows: the reason 1 is that the mobile phone is blocked or slow to operate; reason 2, the mobile phone is lost, stolen or damaged; for reason 3, the storage space of the mobile phone is insufficient. It is clear that insufficient storage space is an important reason for causing the user to passively swap handsets. Moreover, research also shows that for the currently mainstream mobile phones with 128GB storage configuration, 30% of serious users are at risk of insufficient storage space after two years of use.

It follows that freeing up storage space for electronic devices, increasing the space available to users is an extremely important task.

In conventional technologies, data in an electronic device can be cleaned, such as deleting pictures, videos, etc., only manually by a user, or the data in the electronic device can be compressed by a manual trigger of the user to release a storage space in the electronic device. This process is cumbersome and requires a user to determine which data is cleanable or compressible, requiring a high time cost.

Based on the above, the embodiment of the application provides a file processing method which can be applied to a scene that the occupation of data to the storage space of electronic equipment is required to be reduced and the available space of a user is increased.

Illustratively, the electronic device is a cell phone. With the lapse of time, the storage space occupied by the files such as pictures and videos in the mobile phone generally increases linearly, and by adopting the method of the embodiment of the application, the storage space occupied by the files such as pictures and videos can be reduced, and the available space of users can be increased.

Also exemplary, consider the electronic device as a smart phone. The storage space of the intelligent television is usually limited, and the application data in the intelligent television gradually occupy more storage space along with the time, so that the storage space occupied by the application data can be reduced, and the available space of a user can be increased by adopting the method of the embodiment of the application.

In the file processing method provided by the embodiment of the application, the electronic equipment can automatically (i.e. without manual operation of a user) compress various stored files. After compression is completed, the electronic device stores the compressed file in a storage location of the file before compression, and still can provide the same metadata as the file before compression. Wherein the metadata includes at least a file name (including a main name and an extension). That is, the electronic device can automatically complete the compression process without manual operation by the user, and the user can view the same metadata from the same storage location before and after the compression, so that the user does not perceive that the file is compressed.

Illustratively, before compression, the handset may display the interface 101 shown in FIG. 1, with the interface 101 including metadata for a plurality of files stored under the directory "aaa/bbb" of the handset. For example, file name "File 1.Pdf" of File 1, and file generation time "2022/12/1 am 9:51" are included in interface 101. Also for example, file name "File 2.Txt" for File 2, and file generation time "2022/11/8 am 10:00" are included in interface 101. As another example, file name "File 3.Doc" for File 3, and file generation time "2022/10/1 pm 8:00" are included in interface 101. After compression, file 1, file 2 and file 3 are still stored under the directory "aaa/bbb", and the cell phone may display the interface 102 shown in fig. 1, where the interface 102 includes metadata of a plurality of compressed files stored under the directory "aaa/bbb", which is the same as metadata in the interface 101. Taking file 1 as an example, in the interface 102, the file name after compression is still "file 1.Pdf", that is, the main name "file 1" and the extension name "pdf" are the same as those before compression, and are not changed due to compression; and, the compressed file generation time still remains as '2022/12/1 am 9:51', and the time update is not caused by compression.

Therefore, by adopting the method provided by the embodiment of the application, the file compression can be automatically completed and the storage space of the electronic equipment can be released under the condition that a user does not feel.

It should be explained here that a file is generally composed of data and metadata. Wherein, the data refers to the actual data in the file. Taking doc file as an example, the data refers to text content. For the sake of distinction herein, data is referred to as content data, such as image data, video data, and the like. Metadata is used to describe the characteristic properties of a file. Such as file size, storage location, file name, etc.

For convenience of explanation, an interface (e.g., interface 101, interface 1001, interface 1002, interface 1003, etc.) on which metadata of a file before compression is displayed may be referred to as a first interface, and an interface (e.g., interface 102, interface 1001, interface 1002, interface 1004, etc.) on which metadata of a file after compression is displayed may be referred to as a second interface.

The electronic device in the embodiment of the present application may be a mobile phone, a tablet computer, a desktop, a laptop, a handheld computer, a notebook, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), an internet book, an intelligent home appliance such as an intelligent television, an intelligent refrigerator, a cellular phone, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) \virtual reality (VR) device, or other devices capable of storing various files, and the embodiment of the present application is not limited in particular form to the electronic device.

The following describes in detail the implementation of the embodiment of the present application with reference to the drawings.

Referring to fig. 2, a schematic structural diagram of an electronic device 200 according to an embodiment of the present application is provided. As shown in fig. 2, taking an example in which the electronic device is a mobile phone, the electronic device may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (universal serial bus, USB) interface 230, a charge 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, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a sensor module 280, keys 290, a motor 291, an indicator 292, a camera 293, a display 294, a subscriber identity module (subscriber identification module, SIM) card interface 295, and the like.

It is to be understood that the configuration illustrated in this embodiment does not constitute a specific limitation on the electronic apparatus. In other embodiments, the electronic device may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 210 may include one or more processing units such as, for example: the processor 210 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device. In other embodiments, the electronic device may also use different interfacing manners in the foregoing embodiments, or a combination of multiple interfacing manners.

The charge management module 240 is configured to receive a charge input from a charger. The power management module 241 is used for connecting the battery 242, and the charge management module 240 and the processor 210. The power management module 241 receives input from the battery 242 and/or the charge management module 240 and provides power to the processor 210, the internal memory 221, the external memory, the display 294, the camera 293, the wireless communication module 260, and the like.

The wireless communication function of the electronic device may be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 250 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied on an electronic device. The mobile communication module 250 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc.

The wireless communication module 260 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc. for application on an electronic device.

The electronic device implements display functions through the GPU, the display screen 294, and the application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 210 may include one or more GPUs that execute program instructions to generate or change display information.

The display 294 is used to display images, videos, and the like. For example, in the embodiment of the present application, the display 294 is used to display the content such as the application icon, the shortcut menu option, and the delay setting window, so as to guide the user to set the delay time. The display 294 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (flex), a mini, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like.

The electronic device may implement shooting functions through an ISP, a camera 293, a video codec, a GPU, a display 294, an application processor, and the like. The ISP is used to process the data fed back by the camera 293. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also perform algorithm optimization on noise and brightness of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 293.

Internal memory 221 may be used to store computer executable program code that includes instructions. The processor 210 executes various functional applications of the electronic device and data processing by executing instructions stored in the internal memory 221. For example, in an embodiment of the present application, the processor 210 may respond to the user's operation of the application icon by executing the instruction stored in the internal memory 221 to display a shortcut menu of the second application, so as to guide the user to set the delay time length, thereby controlling the use of the application.

The electronic device may implement audio functions through an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an ear-headphone interface 270D, an application processor, and the like. Such as music playing, recording, etc.

The touch sensor 280K, also referred to as a "touch panel". The touch sensor 280K may be disposed on the display screen 294, and the touch sensor 280K and the display screen 294 form a touch screen, which is also referred to as a "touch screen". The touch sensor 280K is used to detect a touch operation acting on or near it. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 294. For example, in the embodiment of the present application, the touch sensor 280K is configured to detect a long press or a double click operation of an application icon by a user, detect a single click operation of a delay setting control by the user, and detect an operation of setting a delay time period by the user. In other embodiments, the touch sensor 280K may also be disposed on a surface of the electronic device at a different location than the display 294.

Keys 290 include a power on key, a volume key, etc. The motor 291 may generate a vibration alert. The indicator 292 may be an indicator light, which may be used to indicate a state of charge, a change in power, a message indicating a missed call, a notification, etc. The SIM card interface 295 is for interfacing with a SIM card. The SIM card may be inserted into the SIM card interface 295 or removed from the SIM card interface 295 to enable contact and separation from the electronic device. The electronic device may support 1 or N SIM card interfaces, N being a positive integer greater than 1.

The software in the electronic device can be configured by a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture or a cloud architecture. The software structure of the electronic device is described below by taking the android system of the hierarchical architecture as an example.

Fig. 3 is a block diagram of a software structure of an electronic device to which an embodiment of the present application is applicable. Taking an electronic device as an example of a mobile phone, a layered architecture divides a software system into a plurality of layers, and each layer has clear roles and division. The layers communicate with each other through a software interface. In some embodiments, the software system may be divided into an application layer, an application framework layer (framework), a An Zhuoyun row (Android run) and a system library (library), a hardware abstraction layer (hardware abstraction layer, HAL), and a kernel layer (kernel).

The application layer may include a series of application packages.

As shown in fig. 3, applications (applications) such as conversation, memo, browser, contact, camera, calendar, map, bluetooth, music, video, short message, etc. may be installed in the application layer.

In the embodiment of the application, an application providing a file management function is also installed in the application program layer. Applications for providing file management functions can be divided into two categories according to the range of files managed: all files in the mobile phone can be managed, such as a mobile phone manager application, a file management application, a setting application and the like; another type of file management system can manage part of files in a mobile phone, such as album application is mainly used for managing picture files and video files in the mobile phone.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions. As shown in FIG. 3, a window manager, a content provider, a view system, a resource manager, a notification manager, etc., may be included in the application framework layer, as embodiments of the present application are not limited in this respect.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like. The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc. The view system described above may be used to build a display interface for an application. Each display interface may be composed of one or more controls. In general, controls may include interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets (widgets), and the like. The resource manager provides various resources, such as localization strings, icons, pictures, layout files, video files, and the like, to the application program. The notification manager enables the application to display notification information in a status bar, can be used for conveying notification type messages, and can automatically disappear after a short stay without user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is presented in a status bar, a prompt tone is emitted, vibration is generated, and an indicator light blinks.

Android runtimes include core libraries and virtual machines. Android run time is responsible for scheduling and management of the Android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional (3D) graphics processing Libraries (e.g., openGL ES), two-dimensional (2D) graphics engines (e.g., SGL), etc.

The surface manager is used for managing the display subsystem and providing fusion of 2D and 3D layers for a plurality of application programs. Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphic processing library is used for realizing 3D graphic drawing, image rendering, synthesis, layer processing and the like. The 2D graphics engine is a drawing engine for 2D drawing.

The HAL hardware abstraction layer is a layer structure abstracted between a An Zhuona core (such as a Linux kernel) and an upper layer (such as an application program framework layer), is a package for a Linux driver, provides a unified interface for the upper layer, and shields the implementation details of the bottom hardware.

As shown in fig. 3, in the embodiment of the present application, a compression management module is disposed in the HAL. The compression management module can provide data support for realizing file compression of a bottom layer (such as a kernel layer) and can also provide relevant data support for compression effect of an upper layer.

Further, as shown in fig. 3, the compression management module includes a compression start module, a file screening module, an algorithm parameter management module, and a first space management module.

The compression starting module is used for determining whether the condition for starting the compression process is met, for example, the condition for starting the compression process is determined to be met when the timing time (such as 2 a.m.) is reached. For another example, the condition for starting the compression process is determined to be satisfied when the CPU load is lower than the preset load.

The file screening module is used for screening the compressible files. For example, files that have not been used recently (e.g., the last 30 days) are screened out from the electronic device as files that are compressed this time. For another example, a file in a preset format is screened out as the file compressed at this time.

The algorithm parameter management module is used for determining parameters of compression, such as compression algorithm, compression grade and the like.

The first space management module is used for managing the file size before compression (i.e. the initial size of the file) and the file size after compression (i.e. the size of the file actually occupies the storage space), so as to feed back the compression effect to an upper layer (such as an application program layer). That is, for any compressed file, the spatial capacity management module stores two sets of data, one set being the file size before compression and the other set being the file size after compression. Subsequently, based on the file size before compression and the file size after compression, an automatic compression effect can be provided for the user. By way of example, the file sizes of all files in the mobile phone before compression are summed to obtain the sum of the file sizes before compression, such as 100GB, and the file sizes of all files in the mobile phone after compression are summed to obtain the sum of the file sizes after compression, such as 90GB, the compression effect of saving 10GB can be displayed to the user.

The kernel layer, which is located below the HAL, is the layer between hardware and software. Various drivers may be included in the kernel layer for driving hardware operations. For example, the kernel layer includes a display driver, a camera driver, an audio driver, a sensor driver, and the like, which is not limited in any way by the embodiment of the present application.

As shown in FIG. 3, in the embodiment of the present application, the kernel layer further includes a flash-friendly file system (Flash Friendly File System, F2 FS). F2FS is a log append file system (Append Logging File System) specifically designed for flash memory devices.

The compression function provided by F2FS is used for most types of file compression, and also for volume (partition) compression. By way of example, F2FS may be used for compression of files such as document files (e.g.,. Txt,. Doc,. Ppt, etc.), system configuration files, application files, etc.

Further, as shown in fig. 3, the F2FS may include a transparent compression interface, a second spatial management module, and a compression algorithm. The transparent compression interface is used for accessing the file processing flow in the embodiment of the application in the existing file processing (such as file reading, opening and writing) flow, so that the F2FS can be used for conventional file processing and can also be used for the file processing flow of the application. The compression algorithm includes LZO, LZ4HC, zstd, etc. The second space management module, similar to the first space management module described above, may be used to manage the file size before compression and the file size after compression. However, the file size before compression and the file size after compression recorded in the first space management module are reported by the second space management module.

The file processing method provided by the embodiment of the application can be executed by the electronic equipment with the hardware structure and the software structure. The file processing scheme of the application is mainly described below by taking the example that the electronic equipment is a mobile phone.

The application provides a file processing scheme, which mainly relates to the following stages: stage 1, compression setting; stage 2, starting compression; stage 3, determining files to be compressed; stage 4, compression treatment; stage 5, compressing effect feedback; stage 6, compressed file reading. These stages will be described separately below.

Stage 1, compression setting.

The compression setting means that the mobile phone turns on or off the file compression function based on the user's operation. Specifically, the mobile phone may turn on or off the file compression function based on the user's operation in the application for managing files. After the file compression function is started, the mobile phone can automatically complete file compression and release the storage space of the electronic equipment under the condition that a user does not feel.

As can be seen from the foregoing description, in the mobile phone, applications for managing files may be classified into two types, one type (e.g., a mobile phone manager application, a file management application, a setting application, etc., which may be referred to as an application a) may manage all files in the mobile phone, and the other type (e.g., an album application, which may be referred to as an application B, which may be referred to as a second application) may manage part of files (which may be referred to as files of a preset type) in the mobile phone.

Accordingly, the file compression function can be divided into a full-volume compression function and a partial compression function. The mobile phone can start or close the full compression function based on the operation of the user in the application A. After the full compression function is started, the mobile phone can compress all files. The handset may turn on or off part of the compression function based on the user's operation in application B. After the partial compression function is started, the mobile phone can compress partial files. The partial file refers to a file that the application B can manage. For example, if application B is an album application, then the partial files refer to picture files and video files.

Compression settings for the full compression function and the partial compression function will be described below, respectively.

First, the full compression function.

The handset may display an interface (also referred to as a third interface) of application a that includes a first compression control (also referred to as a first control) for opening and closing of the full compression function. Taking the application a as an example of a mobile phone manager application, the mobile phone may display the interface 401 shown in fig. 4, where the interface 401 is a main interface of the mobile phone manager application. A setup button 402 of the cell phone manager application is included in the interface 401. In response to a user clicking on a set button 402 in interface 401, the handset may display interface 403. Interface 403 is a setup interface for a cell phone manager application. Included in interface 403 is a "file compress" button 404 for turning on or off the full compression function. I.e., the "file compress" button 404 is the first compression control.

The state of the first file compression control comprises an opening state and a closing state, wherein the opening state is used for indicating that the full-volume compression function is opened, and the closing state is used for indicating that the full-volume compression function is closed. For example, the state of the "File compress" button 404 in the interface 403 shown in FIG. 4 is an off state, indicating that the full compression function is off. As another example, the status of the "file compress" button 404 in the interface 405 shown in fig. 4 is an on state, indicating that the full compression function is on.

The handset may detect operation of the first compression control by the user. In response to an opening operation (such as clicking, long pressing, sliding, and the like, and also referred to as a preset operation) of the first compression control in the closed state by the user, the mobile phone can switch the state of the first compression control to the open state and open the full compression function. And responding to the closing operation (such as clicking, long pressing, sliding and the like) of the first compression control in the opening state by a user, and switching the state of the first compression control into the closing state by the mobile phone, and closing the full compression function. Taking the example of turning on the full compression function, in response to the clicking operation of the "file compression" button 404 in the interface 403 shown in fig. 4 by the user, the mobile phone may display the interface 405 shown in fig. 4, the "file compression" button 404 is switched from the off state in the interface 403 to the on state in the interface 405, and the full compression function is turned on.

Second, partial compression function.

The handset may display an interface (also referred to as a third interface) of application B that includes a second compression control (also referred to as a first control) for opening and closing of the partial compression function. Taking the example that application B is an album application, the mobile phone may display the interface 501 shown in fig. 5, where the interface 501 is the main interface of the album application. A setting button 502 of the album application is included in the interface 501. In response to a user clicking on a set button 502 in interface 501, the handset may display interface 503. The interface 503 is a setting interface of the camera application. Included in interface 503 is a "picture/video compression" button 504 for turning on or off a portion of the compression function. I.e., the "picture/video compression" button 504 is a second compression control.

Likewise, the states of the second compression control also include both an on state and an off state. The on state is used for indicating that the partial compression function is on, and the off state is used for indicating that the partial compression function is off. For example, the status of the "picture/video compression" button 504 in the interface 503 shown in fig. 5 is an off state, indicating that the partial compression function is off. As another example, the status of the "picture/video compression" button 504 in the interface 505 of fig. 5 is an on state, indicating that a portion of the compression function is on.

The handset may detect operation of the second compression control by the user. In response to a user opening operation (such as clicking, long pressing, sliding, and the like, and also referred to as a preset operation) of the second compression control in the closed state, the mobile phone can switch the state of the second compression control to the open state and open a part of compression functions. And responding to the closing operation (such as clicking, long pressing, sliding and the like) of the second compression control in the open state by the user, and switching the state of the second compression control into the closed state by the mobile phone, and closing part of compression functions. Taking the example of turning on the partial compression function, in response to the user clicking the "picture/video compression" button 504 in the interface 503 shown in fig. 5, the mobile phone may display the interface 505 shown in fig. 5, the "picture/video compression" button 504 is switched from the off state in the interface 503 to the on state in the interface 505, and the partial compression function is turned on.

Further, to facilitate user understanding of the file compression function, the handset may display introduction information for the file compression function that is used to introduce advantages (e.g., saving storage space) and/or disadvantages (e.g., requiring more time for subsequent access) of the file compression function. Illustratively, the introduction information is displayed at a location proximate to the first compression control or the second compression control. For example, the introduction information is information 406 in the interface 403 shown in fig. 4, that is, "turn on file compression function", which can compress the picture file and the video file in the local machine, release the storage space, and possibly increase the time consumed for accessing the file. On the one hand, the information 406 introduces the advantage of starting the partial compression function, namely, the picture file and the video file in the local machine can be compressed, and the storage space is released; on the other hand, the information 406 introduces the disadvantage of turning on the partial compression function, which may increase the time-consuming access to the file. The time consuming for accessing the file refers to the time consuming from when the mobile phone detects a request of a user to view a certain file to when the file content of the file is displayed to the user.

After the file compression function is started, the mobile phone may also record first tag information (may also be referred to as a second tag), where the first tag information is used to instruct the file compression function to start. After the compression function is closed, the mobile phone can also record second tag information, wherein the second tag information is used for indicating that the compression function is closed. For example, the first tag information is 1, indicating that the compression function is on; the second tag information is 0, indicating that the compression function is turned off. In this way, it is possible to determine whether or not the relevant processing of file compression, such as starting compression, determining a file to be compressed, or the like, needs to be performed based on the first tag information and/or the second tag information.

After the file compression function is started, the mobile phone can record indication information for indicating the application for starting the file compression function, so that the file for compression can be determined conveniently according to the indication information. For example, the indication information is "album application", from which it can be subsequently determined that the files for which compression is directed are picture files and video files. For another example, the record indication information is "mobile phone manager application", and the files aimed at by compression can be determined to be all files in the mobile phone later.

Stage 2, compression is started.

Start compression refers to: in the case of turning on the file compression function, such as in the case of the presence of the first tag information, the handset detects whether the first condition for starting compression is currently satisfied. If the first condition is met, the mobile phone is indicated to be suitable for starting compression currently, scanning can be started, files needing compression can be determined, and then the stage 3 can be started; if the first condition is not satisfied, the mobile phone is not suitable for starting compression currently, and the subsequent processing is not continued, if the stage 3 is not continued.

In a specific implementation, the mobile phone may determine that the first condition for starting compression is currently satisfied after detecting the arrival timing time. For example, the timing time is 2 a.m., then the first condition for starting compression may be determined to be satisfied when the real-time reaches 2 a.m.

The timing time is the time when the mobile phone is not used by the user. The handset may determine the timing time by counting its own time of use. In this way, for each handset, its particular timing time can be determined.

Illustratively, the use time of the handset a is concentrated between 8 and 22 points, and is rarely used after 22 points and before 8 points on the next day. The mobile phone a can determine a certain time point from 22 to 8 days after the timing time, such as 2 a.m. by analyzing the use time.

Also exemplary, handset b is rarely used between 10 and 20 points, and its use time is mainly concentrated after 20 points and before 9 days next. The mobile phone b can determine a certain time point between 10 and 20 points, such as 12 am, by analyzing the use time.

The above description has mainly been made with respect to a specific time point as an example. In practice, the timing time may include date information, month information, and the like. Illustratively, the timing times are 2 am of 5, 15 and 25 days per month.

In a specific implementation manner, after detecting that the CPU load of the mobile phone is lower than the preset load, the mobile phone may determine that the first condition for starting compression is currently satisfied. Wherein, the CPU load is lower than the preset load, which indicates that the CPU has sufficient resources available for data compression.

It should be appreciated that, in order to improve the rationality of the time to start compression, in another specific implementation, the mobile phone may also determine that the first condition to start compression is currently met after detecting that the timing time is reached and detecting that the CPU load of the mobile phone is lower than the preset load.

In another specific implementation manner, when the mobile phone detects that the arrival timing time and/or the CPU load is lower than the preset load and detects that the battery power of the mobile phone is higher than the preset power, it is determined that the first condition for starting compression is currently met. The preset power may be set based on the power to be consumed by the compression process (e.g., stage 2 and stage 3). For example, if the power required to be consumed in the stage 2 and the stage 3 is a0, the preset power may be set to a1, and a1> a0. Therefore, the battery power of the mobile phone can be ensured to be enough to be consumed in the compression process.

Referring to fig. 6, one exemplary implementation of phase 2 is as follows: after the timing time is reached, the mobile phone detects whether the electric quantity of the battery is higher than a preset electric quantity. If the battery power is higher than the preset power, the mobile phone further detects whether the CPU load is lower than the preset load. If the CPU load is lower than the preset load, the mobile phone determines that the first condition for starting compression is currently met, and the compression can be started. Otherwise, if the battery power is lower than or equal to the preset power or the CPU load is higher than or equal to the preset load, the mobile phone determines that the first condition for starting compression is not met currently, and compression cannot be started. Therefore, the mobile phone can start a series of condition detection for starting compression after the timing time is reached, and detection at any time and any place is not needed, so that the power consumption of the mobile phone is reduced. Of course, in the example shown in fig. 6, the mobile phone may also detect whether the CPU load is lower than the preset load, and then detect whether the battery power is higher than the preset power.

And 3, determining the file to be compressed.

Determining a file to be compressed refers to: after the first condition for starting compression is met, the handset may start a full disc scan and determine, for each scanned file (which may also be referred to as a first file), whether the file meets a second condition. For convenience of explanation, the first condition and the second condition may be collectively referred to as a preset condition. If the file satisfies the second condition, it may be determined that the file is a file to be scanned, and then compression processing needs to be performed on the file, i.e. stage 4 is entered. If the file does not satisfy the second condition, it may be determined that the file is not a file to be scanned, and no compression processing need be performed on the file later, i.e., no stage 4 and its operations need to be performed.

Specifically, for any scanned file, the mobile phone may determine whether the file satisfies the second condition based on parameters such as time, extension, compression tag, encoding format, and the like, in which the file was last used.

Specific implementations of determining whether the file satisfies the second condition based on the time when the file was last used, the extension, the compression tag, and the encoding format, respectively, will be described below.

In one mode, whether the file is a cold file is determined based on the time the file was last used, thereby determining whether the file satisfies the second condition.

Wherein the file being used includes the user directly manipulating the file, resulting in the file being used. For example, a user clicks on a thumbnail of a picture to view a picture file, and the picture file is used. Alternatively, the file being used includes invoking the file during operation of the handset, resulting in the file being used. For example, when a user opens an application, the mobile phone invokes a file supporting the application to run, resulting in the file supporting the application to run being invoked.

In some embodiments, the cold files in the handset are primarily compressed. Cold files refer to files that are not used for a long time to compress. In this way, excessive storage space occupied by files that are not used for a long time can be avoided.

Based on this, the handset can calculate the time the file was last used, the time interval from the current time. It is detected whether the time interval exceeds a preset duration. The preset time period can be 1 month, 3 months, 6 months and the like. If the time interval exceeds the preset time length, the file is a cold file, and the second condition is met; if the time interval does not exceed the preset time, the file is not a cold file, and the second condition is satisfied.

That is, in the first mode, the mobile phone may determine, as the file to be compressed, a file whose time interval from the current time exceeds a preset duration, that is, a cold file that is not used for a long time. The compression efficiency can be improved for cold file compression in the follow-up process.

In a second mode, whether the file is a compressed file is determined based on the extension, compression tag and/or encoding format of the file, so as to determine whether the file meets a second condition.

The compression efficiency is low because the compressed files are compressed again, and the storage space is not saved obviously. Based on this, in some embodiments, the mobile phone compresses only the uncompressed file, so as to significantly improve the effect of saving the storage space caused by compression. Namely, the compression efficiency is improved. In this embodiment, the mobile phone may determine whether the file is a compressed file based on the extension, the compression tag and/or the encoding format. If the file is obtained by compression, the second condition is not satisfied; if the file is not compressed, the second condition is satisfied.

In one particular implementation, the handset may determine whether the file is a file that is manually compressed by the user based on the extension.

The file name typically includes a main name and an extension. Illustratively, the file name is "My work record. Txt", where "My work record" is the main name and ". Txt" is the extension.

Typically, the extension changes after the user manually compresses the file. For example, change from extension. Doc to extension. RAR. Based on this, the handset can detect whether the extension of the file is extension a (which may also be referred to as a second extension), which includes all possible extensions of the file that the user manually compresses, such as, RAR, ZIP, ARJ. If the extension of the file is extension A, then it is determined that the file is a manually compressed file by the user. That is, the file is a compressed file. If the file name of the file is not extension A, it is determined that the file is not a manually compressed file by the user.

In a specific implementation, the mobile phone may determine whether the file is a file automatically compressed by the mobile phone based on the compression tag.

In order to prevent the user from perceiving that the file is compressed, after the scheme of the application is adopted to automatically compress the file, the mobile phone still displays the same extension name as before compression. Therefore, for the file automatically compressed by adopting the scheme of the application, whether the file is the file obtained by compression or not can not be identified by the extension. Meanwhile, in order to distinguish the files before compression and after compression, after the mobile phone automatically compresses the files, a preset compression tag (also called a first tag) may be added to metadata of the files, so as to indicate that the files are files obtained by the mobile phone automatically compressing the files.

Based on the above, the mobile phone can detect whether the metadata of the file includes a preset compression tag. If the metadata comprises a preset compression label, determining that the file is a file obtained by automatic compression of the mobile phone. That is, the file is a compressed file. If the metadata of the file does not comprise the preset compression label, determining that the file is not the file obtained by automatic mobile phone compression.

It should be noted here that the compression tag is generally only used for identifying whether the file is a compressed file or not by the mobile phone, and is not displayed to the user. That is, the user does not find that the file is compressed based on the compression tag.

In a specific implementation, the mobile phone may determine whether the file is a file automatically compressed by the mobile phone based on the encoding format.

The encoding formats generally include a picture encoding format, an audio encoding format, and a video encoding format, among others.

In some embodiments, for multimedia files such as picture files, audio files, and video files, the compression is typically accomplished by recoding. For example, for video files encoded with h.264 (or may be referred to as AVC), h.265 (or may be referred to as HEVC) encoding may be used to further reduce space usage. And, the mobile phone can identify the common coding format from the file. Then, the mobile phone can determine whether the file is automatically compressed by the mobile phone by identifying the coding format. For example, if the encoding format of the video file is identified as h.265, it may be determined that the file is a file obtained by automatically compressing the mobile phone.

That is, for multimedia files, the mobile phone does not need to add a preset compression tag, and can determine whether the files are automatically compressed by the mobile phone or not by identifying the coding format.

Based on this, the handset can detect whether the encoding format of the file is encoding format a (which may also be referred to as a second encoding format). The encoding format A is an encoding format which can be adopted by the mobile phone to automatically compress the multimedia file, such as an H.265 encoding format. If the coding format of the file is the coding format A, determining that the file is a file obtained by automatic compression of the mobile phone. That is, the file is a compressed file. If the encoding format of the file is not the encoding format A, determining that the file is not the file obtained by automatic compression of the mobile phone.

It should be noted that, before the mobile phone adopts the scheme of the present application to automatically compress the file for the first time, the mobile phone may only adopt the specific implementation of "determining whether the file is a file obtained by manually compressing the file by the user based on the extension" in the second mode to determine whether the file is a compressed file. After the mobile phone adopts the scheme of the application to finish at least one automatic compression, the file obtained by manual compression of the user and the file obtained by automatic compression of the mobile phone exist in the mobile phone at the same time, at the moment, the mobile phone can combine multiple specific implementations in the second mode, and the file is determined not to be the file obtained by compression only when the file is determined not to be the file obtained by compression in the multiple specific implementations. Thus, files which are not obtained by manual compression of a user or automatic compression of a mobile phone can be determined as files to be compressed. For example, the extension of the file is not extension a, the metadata of the file does not include a preset compression tag, and the encoding format of the file is not encoding format a, so that it is determined that the file is not a compressed file, and the second condition is satisfied.

That is, in the second mode, the mobile phone may determine a file that is not compressed (including manual compression by the user and automatic compression by the mobile phone) as a file to be compressed. The compression efficiency can be improved for the file compression which is not obtained by compression.

And thirdly, determining whether the file is a file occupying a large storage space based on the extension and/or the coding format, thereby determining whether the file meets a second condition.

In the mobile phone, the number of files with partial formats is large, and the data volume of each file is large, so that a large amount of storage space in the mobile phone is occupied. For example, the JPEG format of picture files and h.264 encoded video files produced by camera applications typically occupy a significant amount of memory space in a cell phone. Files other than these are either small in number or small in data size per file, typically taking up less memory space. For example, PNG format web page pictures, which typically occupy little storage space.

In some embodiments, the compression is mainly performed on files occupying a larger storage space, so that the storage space saving effect caused by compression can be remarkably improved, that is, the compression efficiency is improved.

Based on the method, the mobile phone can determine whether the file is a file occupying a larger storage space according to the extension and/or the coding format. If the file occupies a larger memory space, the second condition is not satisfied. If the file occupies a larger storage space, the second condition is satisfied.

Specifically, the mobile phone may detect whether the extension of the file is extension B (may also be referred to as a first extension). Extension B includes all possible extensions of the file that occupy a larger memory space, such as JPEG, JPG, MP4, etc. The handset may also detect whether the encoding format of the file is encoding format B (which may also be referred to as the first encoding format). Encoding format B includes all possible encoding formats of the file that occupy a larger storage space, such as h.264, h.265, etc.

If the extension is extension B or the coding format is coding format B, determining that the file is a file occupying larger storage space, and meeting a second condition. If the extension is not extension B and the encoding format is not encoding format B, determining that the file is not a file occupying a larger storage space, and not meeting the second condition.

That is, in the third mode, the mobile phone can determine the file occupying a larger storage space as the file to be compressed. The subsequent compression of files occupying larger storage space can be realized, and the compression efficiency is improved.

In a fourth mode, it is determined whether the file type of the file is a file type (i.e., a preset type) that needs to be compressed based on the extension, thereby determining whether the file satisfies the second condition.

Among them, file types include, but are not limited to, one or more of document files (such as those generated by word, PDF, excel, PPT, etc.), video files, audio files, picture files, and executable files (such as those having extensions of. Exe,. Sys,. Com, etc.). It should be appreciated that each file type has a corresponding extension. For example, the extensions of the picture files include JPEG, & TIFF, & RAW, & BMP, & GIF, & PNG; the extensions of the video files include MP4, & AVI, & DAT, & MKV, & FLV, & VOB. Thus, the handset can detect the file type by identifying the extension.

In some embodiments, the handset turns on the partial compression function, only requiring compression of a portion of the file. Thereby achieving targeted compression. For example, the handset may initiate a compression function for a file managed by application B in response to a user's operation of a second compression control in application B. Taking the example that the application B is an album application, the files managed by the album application are typically the picture files and the video files in the mobile phone, and then the partial compression function is specific to the picture files and the video files in the mobile phone.

Based on this, in the case where the partial compression function is turned on, as in the case where the instruction information instructs the application B, the cellular phone can determine whether the file is a file that needs to be compressed, that is, a file managed by the partial compression function, based on the extension. Specifically, the mobile phone may detect whether the extension of the file is extension C (may also be referred to as a third extension). Extension C includes all possible extensions of the files that the application opening the partial compression function (i.e., application B) can manage. By way of example, application B is an album application and the files that the album application may manage include picture files and video files, extension C includes all possible extensions of the picture files and video files, such as extensions of JPEG, TIFF, GIF, PNG, MP4, AVI, DAT, MKV, etc. If the extension of the file is extension C, determining that the file type of the file is the file type to be compressed, and meeting a second condition. If the extension of the file is not extension C, it is determined that the file type of the file is not the file type that needs to be compressed, and the second condition is not satisfied.

That is, in the fourth mode, the mobile phone can determine the file targeted by the partial compression function as the file to be compressed, so as to achieve targeted compression.

The foregoing description separately describes the implementation of the first to fourth modes, and at least two of the first to fourth modes may be used in combination in actual implementation. By way of example, combining the first, second, and third modes, a cold file that is not compressed and occupies a large memory space may be determined as a file to be compressed. Also by way of example, combining modes one through four, a cold file that is uncompressed, occupies a large memory space, and is of a file type that needs to be compressed may be determined as a file to be compressed.

Taking the combination of the first mode and the second mode as an example, referring to fig. 7, after the compression is started, the mobile phone can detect whether the scanned file is a cold file in the first mode. If the file is a cold file, the mobile phone can further detect whether the file is a compressed file in a second mode. The method can detect whether the file is a compressed file according to different file types and different implementations, so that the method can detect whether the file is the compressed file according to the specific detection, and all implementations are not needed to be adopted for detection. With continued reference to fig. 7, if a picture file, a second manner of determining whether the file is a compressed file based on the implementation of the compression tag may be employed. If the file is a video file, the implementation of the second mode based on the encoding format can be used to determine whether the file is a compressed file. For example, if the encoding format is h.265 format, determining that the file is a compressed file; the encoding format is h.264 format, it is determined that the file is not compressed. If the file is other than the picture file and the video file, the mobile phone can adopt the realization based on the extension and the compression label in the second mode to determine whether the file is the compressed file. And if the file is determined not to be obtained by compression, determining the file as the file to be compressed.

And 4, compressing.

The compression process refers to: and after determining any scanned file as the file to be compressed, compressing the file.

Before describing the compression process in detail, a brief description of the relevant knowledge of data compression follows.

In a mobile phone, storage space occupied by media files such as pictures, audio and video is extremely large. And, these media files are typically encoded, resulting in data compression.

For example, the picture file (such as a photograph taken by a camera) on a mobile phone is mostly in JPEG format. The JPEG format is the format most commonly used on multimedia devices and the internet for storing and transmitting pictures. In addition, in the process of obtaining a picture file in the JPEG format, the picture data is compressed by processing procedures such as discrete cosine transform (Discrete Cosine Transform, DCT) and huffman coding. That is, most of the picture files on the mobile phone, such as the JPEG format picture files, are obtained after compression.

Also for example, the mainstream coding mode adopted by the video file (such as the video shot by the camera) on the mobile phone is h.264 (or may be called AVC). The video information can be compressed by H.264 coding, and the data volume is reduced. After H.264 encoding, the video is encapsulated, and the video is encoded and encapsulated to form a video file, such as an MP4 file. Also, h.264 is a lossy compression. That is, the video files on the mobile phone, such as MP4 files, are also obtained after compression.

Meanwhile, the compression algorithm of F2FS, such as LZO, LZ4HC, zstd, etc., is low in compression efficiency for multimedia files already compressed, such as video, pictures, etc.

Based on this, in the present application, for multimedia files, further compression may be achieved in a manner other than the compression algorithm provided by F2FS, i.e. in a manner of re-encoding. For example, for a picture file, the compression encoding may be further performed by adopting an arithmetic encoding manner. Also exemplary, for video files, the encoding format of h.265 (or HEVC) may be further employed for compression encoding. Thereby further saving storage space.

It should be noted that, although the original picture files and video files on the mobile phone are obtained by compression, in the second mode of the previous stage 3 (i.e. determining the files to be compressed), the "compressed files" do not include the original picture files and video files in the mobile phone, but include the recoded picture files and video files. For example, a video file encoded with h.264 will not be identified as a compressed file, but a video file encoded with h.265 will be identified as a compressed file.

In addition to the media files described above, other files in the handset can be compressed, typically using a compression algorithm in F2FS, thereby saving storage space.

Specifically, after determining that the file is a file to be compressed, the mobile phone further determines the compression mode based on the file type. For example, referring to fig. 8, the cell phone may be compressed in different manners for a picture file, a video file, and other files than the picture file and the video file, respectively. For example, for a picture file of JPEG, it may be determined to implement lossless compression using Lepton library re-encoding (which may also be referred to as a third encoding format), or lossy compression using MozJPEG library re-encoding (which may also be referred to as a third encoding format). For another example, for a video file obtained by h.264 encoding, if the mobile phone supports h.265 hard encoding, it may be determined to select to directly output h.265; if the handset does not support H.265 hard coding, the video file can be converted into H.265 by using a soft coding mode. For another example, for other files than the picture file and the video file, it may be determined that compression is achieved using a compression algorithm (which may also be referred to as a preset compression algorithm) provided by F2 FS.

In the compression process, after the compression mode is determined based on the file type, the mobile phone can compress only the content data of the file, and the metadata is kept unchanged to complete the compression. Thereby ensuring that metadata such as file names, file generation time and the like are kept consistent before and after compression.

Referring to fig. 9, the mobile phone may compress content data (e.g., denoted as content data 1) in a file before compression (i.e., a file to be compressed) to obtain content data (e.g., denoted as content data 2) of the compressed file. Wherein the data amount of the content data 2 is smaller than the data amount of the content data 1. The mobile phone may combine the metadata (which may be referred to as metadata 1) of the file before compression, such as the file name (including the main name and the extension), the information such as the generation time and the thumbnail, and the content data 2 to obtain a compressed file (which may also be referred to as a second file). In this way, the metadata of the file after compression can be ensured to be the same as the metadata of the file before compression.

Typically, the file size of the compressed file is smaller than the file size of the file prior to compression. For example, the video file before compression is 1GB, and the video file after compression is reduced to 800MB. In order to make the user clear the real size of the file and avoid misleading the user, the mobile phone can update the file size in the metadata 1 to the file size of the compressed file. In addition, other information in the metadata 1 is kept unchanged.

Finally, the mobile phone deletes the file before compression and stores the compressed file in the storage position of the file before compression, so that the user can still access the compressed file from the original storage position. And, because the metadata of the file after compression is the same as the metadata of the file before compression, the metadata of the file after compression is presented to the user, and the user is hard to perceive that the file has been compressed.

For example, referring to fig. 10, before compression, the handset may display an interface 1001 shown in fig. 10, where the interface 1001 includes partial metadata of a plurality of files before compression stored under a directory "aaa/bbb" of the handset. For example, file 3 file name "file 3.Doc" is included in interface 1001, generating time "2022/10/1 afternoon 8:00". After the mobile phone detects the long-press operation of the user on the file 3 in the interface 1001, the interface 1002 shown in fig. 10 may be displayed, where the interface 1002 includes "send", "move", "delete" and "more" buttons. When the mobile phone detects that the user clicks the "more" button in the interface 1002, the interface 1003 shown in fig. 10 may be displayed, where the interface 1003 includes metadata of the file 3 before compression, such as a file name "file 3.Doc", a storage location "AAA/bbb", a file size "400MB", a generation time "2022/10/1 pm 8:00", and an author "AAA", etc.

With continued reference to fig. 10, since the file names and generation times are unchanged before and after compression, the handset may still display the interface 1001 shown in fig. 10 after compression. After the mobile phone detects the long-press operation of the user on the file 3 in the interface 1001, the interface 1002 shown in fig. 10 may be displayed, where the interface 1002 includes "send", "move", "delete" and "more" buttons. When the mobile phone detects that the user clicks the "more" button in the interface 1002, an interface 1003 shown in fig. 10 may be displayed, where the interface 1003 includes metadata of the compressed file 3 in more detail, such as a file name "file 3.Doc", a storage location "AAA/bbb", a file size "350MB", a generation time "2022/10/1 pm 8:00", and an author "AAA", etc.

It is apparent that by comparing the interface 1003 and the interface 1004, only the file size is updated before and after compression, and the remaining metadata, such as the file name, generation time, storage location, author, etc., remain unchanged.

Furthermore, in order to distinguish the file obtained by the automatic compression of the mobile phone, after the compressed file is obtained by the compression processing of the stage 4, a preset compression tag can be added in metadata of the compressed file. The preset compression label indicates that the file is obtained by automatic compression of the mobile phone. In this way, it may then be determined whether the file is a compressed file based on the compression tag.

In addition, for multimedia files, further compression is typically achieved by recoding. For example, for video files, further compression may be achieved using h.265 encoding format recoding. Moreover, for common encoding formats, such as h.265 encoding format, the handset can read directly from the file. That is, the mobile phone can determine whether the multimedia file is a compressed file by reading the encoding format, without determining based on the compression tag. Therefore, for multimedia files, such as video files, after the compressed file is obtained through the compression processing of stage 4, the mobile phone may not add a preset compression tag to metadata of the compressed file. Subsequently, the handset may determine whether the file is a compressed file based on the encoding format.

In addition, in order to avoid that the user perceives that the file is already compressed, the mobile phone can hide the preset compression label.

Thus, through the stages 1-4, the automatic compression of the file is completed. To facilitate an understanding of the above-described stages 1-4, a specific implementation of stages 1-4 is described below in connection with the complete example shown in FIG. 11.

S1101, turn on or off the file compression function. See for a specific discussion of stage 1 above.

The file compression function may be a full compression function or a partial compression function.

S1102, determining that the timing time arrives.

S1103, detecting whether the battery power is higher than a preset power. If yes, then execution S1104; if not, the method ends.

S1104, detecting whether the CPU load is lower than a preset load. If yes, executing S1105; if not, the method ends.

The above-mentioned steps S1102-S1104, i.e. the process of detecting whether the first condition for starting compression is satisfied, can be seen in particular from the description of the previous stage 2.

S1105, start full disc scan.

After the full-disc scanning is started, the files in the mobile phone are scanned one by one.

S1106, detecting whether there are any unscanned files. If yes, executing S1107 to continue the subsequent processing for the document not scanned; if not, the method ends.

S1107, detecting whether the file is a cold file. If yes, executing any one of S1108-S1110 to determine whether the file is a compressed file; if so, the process need not be continued for the currently scanned file, and execution may jump to S1106.

S1108, if the file is a picture file, determining whether the file is a compressed file based on the compression label. If not, executing S1111, and further executing compression processing for the picture file; if so, the process need not be continued for the currently scanned file, and execution may jump to S1106.

S1109, if it is a file other than the picture file and the video file, determining whether the file is a compressed file based on the extension and the compression flag. If not, executing S1112, and further executing compression processing for other files; if so, the process need not be continued for the currently scanned file, and execution may jump to S1106.

The extension name is used for determining whether the file is a file obtained by manual compression of a user, and the compression label is used for determining whether the file is a file obtained by automatic compression of a mobile phone.

S1110, if the file is a video file, determining whether the file is a compressed file based on the coding format. If not, then S1114 is performed, further compression processing is performed for the video file; if so, the process need not be continued for the currently scanned file, and execution may jump to S1106.

The steps S1105-S1110 are the processes of starting scanning and detecting whether the currently scanned file is the file to be compressed meeting the second condition, and can be specifically referred to the description of the previous stage 3.

S1111, adopting lossless recoding of pictures to obtain compressed content data.

And S1112, compressing by adopting an LZ4 algorithm to obtain compressed content data.

For other files and video files, during the compression process, the following S1114 needs to be performed:

s1113, adding a preset compression label.

By adding the preset compression label, the follow-up file obtained by compression is determined based on the preset compression label.

S1114, adopting video recoding to obtain compressed content data.

S1115, merging the compressed content data and the metadata of the file before compression, and modifying the size of the file to obtain the compressed file.

S1116, deleting the file before compression, and storing the compressed file in the storage position of the file before the file.

The above-mentioned S1111-S1116 are the process of compressing the file to be compressed, and the description of the previous stage 4 can be referred to specifically.

And 5, feeding back the compression effect.

In some embodiments, after the automatic compression of the file is completed, the mobile phone may also feed back the compression effect to the user, so as to prompt the user that the compression saves the storage space.

For example, after the compression is completed, the handset may display an interface 1201 shown in fig. 12, where the interface 1201 includes a prompt 1202 from the handset manager application, "this compression has saved 500MB of storage for you, clicking on viewable details". Thereby prompting the user that the compression saves 500MB of storage space. In response to the clicking operation of the user on the prompt 1202, the mobile phone may further display an interface 1203 shown in fig. 12, where the interface 1203 includes details of the current compression, such as the number of files compressed this time, and occupation conditions of storage space before and after the compression.

In this embodiment, the mobile phone needs to record the file size before compression in the compression process. In this way, after compression is completed, the compression effect can be determined based on the file size before compression and the file size after compression.

Stage 6, compressed file reading.

Compressed file reading refers to: and acquiring content data of the compressed file after the compressed file is obtained.

After the automatic compression of the file is completed, the mobile phone can detect the access operation of the user to the compressed file, respond to the access operation, firstly execute the file decompression processing, and then display the decompressed content data to the user. Thereby realizing the display of the content data of the compressed file to the user.

For example, the mobile phone may display an interface 1301 shown in fig. 13, where the interface 1301 includes a plurality of files, such as file 1, file 2, and file 3. If the file 3 is a compressed file, the mobile phone may decompress the file 3 first in response to the user clicking the file 3 in the interface 1301 (i.e. the access operation is a clicking operation). After decompression is completed, an interface 1302 shown in fig. 13 is displayed, and the content of the file 3 is included in the interface 1302.

The specific implementation of the display file will be specifically described below.

Referring to fig. 14, after receiving an access operation of a user, the mobile phone can detect whether a currently accessed file is a file automatically compressed by the mobile phone. For a specific implementation of detecting whether the currently accessed file is a file obtained by automatically compressing the mobile phone, refer to the description of the second mode in the foregoing stage 3, which is not repeated herein. If the current accessed file is a file obtained by automatic compression of the mobile phone, the file needs to be further decompressed and then displayed to the user. If the current accessed file is not the file obtained by automatic compression of the mobile phone, the current accessed file can be processed directly according to the existing file processing flow.

With continued reference to fig. 14, after detecting that the file is a file automatically compressed by the mobile phone, the decompressing process further includes: if the accessed file is a picture file, the handset may decode and display the content data in the file. If the accessed file is a video file, the mobile phone can transcode and display the content data in the file, such as transcoding the H.265 coding format to the H.264 coding format and displaying the transcoded content data. If the accessed file is other files except the picture file and the video file, the mobile phone can be decompressed and displayed by adopting a decompression algorithm corresponding to the compression algorithm in compression.

The user performs an access operation on the file, indicating that the file is used, which is not a cold file that is not used for a long period of time. In some embodiments, the handset only compresses the cold file. In this embodiment, after detecting an access operation of the user to the file obtained by automatic compression of the mobile phone, the mobile phone decompresses the file, and may store the decompressed file composed of the content data and the metadata in a storage location of the compressed file. So that recently used files are in an uncompressed state. In addition, the mobile phone can also match the file size in the metadata with the decompressed file. And the mobile phone can delete the preset compression label in the metadata.

In some scenarios, the user may also share the file automatically compressed by the mobile phone to other users. Since the user does not perceive that the file has been automatically compressed by the handset, if the other user's device does not support viewing the compressed file, the compressed file may not be opened and the user may be confused accordingly. For example, the doc file has been automatically compressed into a file of the RAR by the cell phone, but because the extension displayed on the cell phone is still the doc file, the user does not know that the file has been compressed into the RAR, and after it sends the compressed RAR file to other users, if the devices of other users do not support the RAR file, it may cause the other users to fail to open the file.

Based on this, in some embodiments, after receiving the sharing operation of the user on the file, if it is determined that the file is a file obtained by the mobile phone by automatic compression, the mobile phone may decompress the file and then share the file to other users. If the file is determined not to be the file obtained by automatic compression of the mobile phone, the mobile phone shares the file according to the normal flow. Therefore, the files sent to other users can be ensured to be the files which are seen by the users in the mobile phone.

The embodiment of the application also provides electronic equipment, which can comprise: a memory and one or more processors. The memory is coupled to the processor. The memory is for storing computer program code, the computer program code comprising computer instructions. When the processor executes the computer instructions, the electronic device may execute the functions or steps executed by the mobile phone in the above method embodiment, so as to implement file compression.

The present application also provides a chip system, as shown in fig. 15, the chip system 1500 includes at least one processor 1501 and at least one interface circuit 1502. The processor 1501 and the interface circuit 1502 may be interconnected by wires. For example, interface circuit 1502 may be used to receive signals from other devices (e.g., a memory of an electronic apparatus). For another example, interface circuit 1502 may be used to send signals to other devices (e.g., processor 1501). Illustratively, the interface circuit 1502 may read instructions stored in the memory and send the instructions to the processor 1501. The instructions, when executed by the processor 1501, may cause the electronic device to perform the various steps in the embodiments described above. Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

The embodiment also provides a computer readable storage medium, in which computer instructions are stored, which when executed on an electronic device, cause the electronic device to execute the functions or steps executed by the mobile phone in the above method embodiment, so as to implement file compression.

The present embodiment also provides a computer program product, which when running on a computer, makes the computer execute the functions or steps executed by the mobile phone in the above method embodiment, so as to implement file compression.

In addition, embodiments of the present application also provide an apparatus, which may be embodied as a chip, component or module, which may include a processor and a memory coupled to each other; the memory is used for storing computer executing instructions, and when the device runs, the processor can execute the computer executing instructions stored in the memory, so that the chip executes each function or step executed by the mobile phone in the method embodiment to realize file compression.

The electronic device, the communication system, the computer readable storage medium, the computer program product or the chip provided in this embodiment are used to execute the corresponding method provided above, so that the benefits achieved by the electronic device, the communication system, the computer readable storage medium, the computer program product or the chip can refer to the benefits in the corresponding method provided above, and are not repeated herein.

From the foregoing description of the embodiments, it will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of functional modules is illustrated, and in practical application, the above-described functional allocation may be implemented by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to implement all or part of the functions described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated unit may be stored in a readable storage medium if implemented in the form of a software functional unit and sold or used as a stand-alone product. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Finally, it should be noted that the above-mentioned embodiments are merely for illustrating the technical solution of the present application and not for limiting the same, and although the present application has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications and equivalents may be made to the technical solution of the present application without departing from the spirit and scope of the technical solution of the present application.

Claims

1. A method for processing a file, the method being applied to an electronic device, the method comprising:

the electronic equipment displays a first interface, wherein the first interface comprises metadata of a first file, the metadata of the first file comprises a file name of the first file, and the first file is any file in the electronic equipment;

under the condition that a preset condition is met, the electronic equipment automatically compresses the first file to obtain a second file, wherein the file size of the second file is smaller than that of the first file;

the electronic equipment deletes the first file and stores the second file in a storage position of the first file;

the electronic equipment displays a second interface, metadata of the second file is included in the second interface, the metadata of the second file includes a file name and a file size of the second file, the file name of the second file is identical to the file name of the first file, and the file name includes a main name and an extension name.

2. The method of claim 1, wherein the metadata of the first file further comprises at least one of a time of generation, an author, a thumbnail, and a storage location of the first file; metadata of the second file further includes at least one of a generation time, an author, a thumbnail, and a storage location of the second file;

the generation time, the author, the thumbnail and the storage position of the second file are the same as those of the second file.

3. The method according to claim 1 or 2, wherein the satisfaction of the preset condition comprises at least one of:

the current time reaches the timing time;

the battery electric quantity of the electronic equipment is higher than the preset electric quantity; the method comprises the steps of,

the load of the CPU of the electronic equipment is lower than a preset load.

4. A method according to any one of claims 1-3, wherein the satisfaction of the preset conditions comprises at least one of:

the time of the last time of the first file is used, and the time interval from the current time exceeds the preset duration;

the first file is an uncompressed file;

The first file is a file with an extension of a first extension or a first coding format.

5. The method according to claim 4, wherein the method further comprises:

if the first file is a picture file and the metadata of the first file does not include a first tag, determining that the first file is an uncompressed file;

the first tag is used for indicating that the first file is a file obtained by automatic compression of the electronic equipment.

6. The method of claim 3 or 4, wherein if the first file is a video file and the encoding format of the first file is not a second encoding format, determining that the first file is an uncompressed file;

the second coding format is a coding format adopted when the electronic equipment automatically compresses the video file.

7. The method of any of claims 3-6, wherein if the first file is not a picture file nor a video file and the extension of the first file is a second extension or the metadata of the first file includes a first tag, determining that the first file is an uncompressed file;

The second preset extension name is an extension name of a file obtained by compression of a user, and the first label is used for indicating that the first file is a file obtained by automatic compression of the electronic equipment.

8. The method according to any one of claims 1-7, further comprising:

the electronic equipment displays a third interface, wherein the third interface comprises a first control, and the first control is used for starting a file compression function;

the electronic equipment responds to the preset operation of the user on the first control, and records a second label which indicates that the file compression function is started;

the electronic device automatically compresses the first file, including:

and under the condition that the second label is included in the electronic equipment, the electronic equipment automatically compresses the first file.

9. The method of claim 8, wherein the third interface is an application interface of a first application that is used to manage all files in the electronic device; or alternatively, the process may be performed,

the third interface is an application interface of a second application, and the second application is used for managing files of a preset type in the electronic equipment.

10. The method of claim 9, wherein the third interface is an application interface of the second application, and the meeting the preset condition includes:

the first file is a file with a third extension, and the third extension is an extension included in the file of the preset type.

11. The method of any of claims 1-10, wherein the electronic device automatically compresses the first file, comprising:

if the first file is a video file, the electronic equipment recodes the video data of the first file by adopting a second coding format to obtain recoded video data;

combining the recoded video data with the metadata of the first file to obtain the second file;

and modifying the file size of the first file in the metadata of the first file to the file size of the second file to obtain the metadata of the second file.

12. The method of any of claims 1-11, wherein the electronic device automatically compresses the first file, comprising:

if the first file is a picture file, the electronic equipment recodes the image data of the first file by adopting a third coding format to obtain recoded image data;

Combining the recoded image data with the metadata of the first file to obtain the second file;

13. The method of any of claims 1-12, wherein the electronic device automatically compresses the first file, comprising:

if the first file is not a picture file or a video file, the electronic device compresses the content data of the first file by adopting a preset compression algorithm to obtain compressed content data, wherein the preset compression algorithm is a compression algorithm provided by a flash-friendly file system F2 FS;

combining the compressed content data with the metadata of the first file to obtain the second file;

14. The method according to claim 12 or 13, characterized in that the method further comprises:

and adding a first label in the metadata of the second file.

15. The method according to any one of claims 1-13, wherein after said obtaining the second file, the method further comprises:

and responding to the access operation of the user to the second file, decompressing the second file by the electronic equipment, and displaying the decompressed file content.

16. The method of any of claims 1-14, wherein after the obtaining the second file, the method further comprises:

responding to the sharing operation of the user on the second file, and decompressing the second file by the electronic equipment to obtain a decompressed file;

and sharing the decompressed file.

17. An electronic device comprising a memory and a processor, the memory and the processor coupled; wherein the memory has stored therein computer program code comprising computer instructions which, when executed by the processor, cause the electronic device to perform the method of any of claims 1-16.

18. A computer readable storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the method of any of claims 1-16.

19. A chip system for application to an electronic device comprising a processor and a memory, the chip system comprising one or more interface circuits and one or more processors, the interface circuits and the processors being interconnected by wires, the interface circuits being adapted to receive signals from the memory of the electronic device and to send the signals to the processor, the signals comprising computer instructions stored in the memory, which when executed by the processor, cause the electronic device to perform the method of any of claims 1-16.