File storage method, file access method, electronic device, and storage medium

Abstract

Embodiments of the present application provide a file storage method, a file access method, an electronic device and a storage medium, and relate to the field of information technology. The method comprises: obtaining an installation package file; decompressing a runtime library compressed file in the installation package file to obtain a runtime library file corresponding to the runtime library compressed file; recording a correspondence relationship and a first offset, and releasing one or more data blocks of the runtime library compressed file in the installation package file; wherein the correspondence relationship is used to represent the correspondence relationship between the one or more data blocks of the runtime library compressed file in the installation package file and the runtime library file, and the first offset is used to represent the offset of the one or more data blocks of the runtime library compressed file in the installation package file. The method provided by the embodiments of the present application can save the space occupied by the installation package file, thereby improving the storage efficiency.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a file storage method, a file access method, an electronic device, and a storage medium. Background Technology

[0002] With the development of mobile internet technology, terminal devices have become indispensable in people's work, life, and entertainment, leading to a surge in a large number of terminal device applications. These applications cover a wide range of aspects of work and life, including office work, entertainment, social networking, shopping, and financial management. Users install numerous applications after prolonged use of their terminal devices to meet their diverse needs in daily life and work. These applications occupy a portion of the terminal device's storage space, storing various files required for their operation.

[0003] Android is a mobile operating system widely used in mobile phones, tablets, televisions, and other terminal devices. These devices contain storage devices such as flash memory to store instructions and data files needed for application execution. Applications typically do not directly access these storage devices; instead, they send file creation and read / write operation requests to the operating system's file system modules (such as f2fs or ext4). The file system then selects the data storage location and interacts with the storage devices. The file system uses an inode data structure to manage stored files, with each file corresponding to a unique inode. Each inode has a unique number and records the address of the logical data block on the storage device where the file data is stored.

[0004] While the Android system interfaces running on mobile phones, tablets, TVs, and other terminal devices vary, the application installation process follows a common workflow: application developers release APK format installation package files, the terminal operating system unpacks the APK file, and stores the files within the package on the terminal device. An APK file is a packaged file based on the JAR format, which in turn is designed and defined based on the mainstream ZIP compressed file format. Therefore, the APK file format is essentially similar to a ZIP compressed archive. An APK file contains various resource files required for application operation, including dex files containing application instructions, runtime library files (with the .so extension), and data files such as images and text.

[0005] The general process of installing applications on an Android system is as follows: The system's application installer unpacks the APK file and stores the runtime library files contained within it in the application's installation directory. The APK file itself is also stored in the application's installation directory. Because both the APK file and the runtime library files obtained from unpacking the APK are stored in the application's installation directory after installation, the runtime library files exist repeatedly: they are stored in compressed form within the APK file, and each runtime library file exists independently outside the APK file. Since the contents of the runtime library files are frequently used during application startup and operation, this storage method allows applications to read data directly without decompressing the APK package, thus accelerating application performance. However, the repeated storage space occupied by the runtime library files wastes valuable storage space. For example, for 40 popular applications, the repeated runtime library files within the APK occupy more than 1GB of storage space, equivalent to more than 300 3MB photo files. Summary of the Invention

[0006] This application provides a file storage method, a file access method, an electronic device, and a storage medium to provide a way to store installation package files, which can save the space occupied by the installation package files on the terminal and thus improve storage efficiency.

[0007] In a first aspect, embodiments of this application provide a file storage method, including:

[0008] Obtain the installation package file;

[0009] Decompress the runtime library compressed file in the installation package file to obtain the runtime library file corresponding to the compressed runtime library file;

[0010] Record the correspondence and the first offset, and release one or more data blocks of the runtime library compressed file in the installation package file; wherein, the correspondence is used to characterize the correspondence between one or more data blocks of the runtime library compressed file in the installation package file and the runtime library file, and the first offset is used to characterize the offset of one or more data blocks of the runtime library compressed file in the installation package file in the installation package file.

[0011] In this embodiment of the application, by recording the location of the compressed file in the installation package and deleting the compressed file in the installation package after decompression, the space occupied by the installation package file on the terminal can be saved, thereby improving storage efficiency.

[0012] In one possible implementation, the installation package file also includes a compressed data file.

[0013] In one possible implementation, releasing one or more data blocks of the runtime library compressed file within the installation package includes:

[0014] Extract one or more data blocks from all runtime library compressed files in the installation package file.

[0015] In this embodiment of the application, storage space can be significantly saved by releasing all compressed files.

[0016] In one possible implementation, releasing one or more data blocks of the runtime library compressed file within the installation package includes:

[0017] Extract one or more data blocks from the runtime library compressed file in the installation package file.

[0018] In this embodiment of the application, by releasing part of the compressed file, the compressed file can be deleted as needed, thereby improving flexibility.

[0019] One possible implementation also includes:

[0020] If one or more data blocks store data from the installation package file or the compressed file, then one or more data blocks are not released.

[0021] In this embodiment of the application, accidental deletion of data blocks including data compressed files can be avoided.

[0022] One possible implementation also includes:

[0023] Mark the installation package file that has already had its data blocks released; the mark is used to indicate that the installation package file has had its data blocks released.

[0024] In this embodiment of the application, it is possible to avoid the situation where the compressed file space becomes inaccessible after it is released.

[0025] Secondly, embodiments of this application also provide a file access method applied to an electronic device, the electronic device having an application installed, including:

[0026] The application sends an access request to the file system; the access request is used to access one or more data blocks that have been freed in the installation package file, and the access request includes a second offset and the data length;

[0027] The file system queries the runtime library files corresponding to one or more freed data blocks;

[0028] The file system compresses the runtime library files obtained from the query to obtain a compressed file of the accessed runtime library;

[0029] The file system obtains the first offset, reads from the accessed runtime library compressed file based on the first offset, the second offset, and the data length, and returns the reading result to the application.

[0030] Thirdly, embodiments of this application provide a file storage device, including: a processor and a memory, wherein the memory is used to store a computer program; and the processor is used to run the computer program and perform the method described in the first aspect.

[0031] Fourthly, embodiments of this application provide a file access device, including: a processor and a memory, wherein the memory is used to store a computer program; and the processor is used to run the computer program and perform the method described in the second aspect.

[0032] Fifthly, embodiments of this application provide an electronic device, including:

[0033] The memory is used to store computer program code, the computer program code including instructions, which, when read from the memory by the electronic device, cause the electronic device to perform the method as described in the first and second aspects.

[0034] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the methods described in the first and second aspects.

[0035] In a seventh aspect, embodiments of this application provide a computer program that, when executed by a computer, performs the methods described in the first and second aspects.

[0036] In one possible implementation, the program in aspect seven can be stored wholly or partially on a storage medium packaged with the processor, or it can be stored wholly or partially on a memory not packaged with the processor. Attached Figure Description

[0037] Figure 1 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application;

[0038] Figure 2 A flowchart illustrating the file storage method provided in this application embodiment;

[0039] Figure 3 This is a schematic diagram of file decompression and storage provided in an embodiment of this application;

[0040] Figure 4 This is a schematic diagram of data block release provided in an embodiment of this application;

[0041] Figure 5 This is a schematic diagram illustrating the release of some data blocks provided in an embodiment of this application;

[0042] Figure 6A schematic diagram of the software structure of the electronic device provided in the embodiments of this application;

[0043] Figure 7 A flowchart illustrating the file access method provided in this application embodiment;

[0044] Figure 8 This is a schematic diagram of file compression provided for an embodiment of this application;

[0045] Figure 9 This is a schematic diagram of the structure of a file storage device provided in an embodiment of this application;

[0046] Figure 10 This is a schematic diagram of the structure of a file access device provided in an embodiment of this application. Detailed Implementation

[0047] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0048] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0049] With the development of mobile internet technology, terminal devices have become indispensable in people's work, life, and entertainment, leading to a surge in a large number of terminal device applications. These applications cover a wide range of aspects of work and life, including office work, entertainment, social networking, shopping, and financial management. Users install numerous applications after prolonged use of their terminal devices to meet their diverse needs in daily life and work. These applications occupy a portion of the terminal device's storage space, storing various files required for their operation.

[0050] Android is a mobile operating system widely used in mobile phones, tablets, televisions, and other terminal devices. These devices contain storage devices such as flash memory to store instructions and data files needed for application execution. Applications typically do not directly access these storage devices; instead, they send file creation and read / write operation requests to the operating system's file system modules (such as f2fs or ext4). The file system then selects the data storage location and interacts with the storage devices. The file system uses an inode data structure to manage stored files, with each file corresponding to a unique inode. Each inode has a unique number and records the address of the logical data block on the storage device where the file data is stored.

[0051] While the Android system interfaces running on mobile phones, tablets, TVs, and other terminal devices vary, the application installation process follows a common workflow: application developers release APK format installation package files, the terminal operating system unpacks the APK file, and stores the files within the package on the terminal device. An APK file is a packaged file based on the JAR format, which in turn is designed and defined based on the mainstream ZIP compressed file format. Therefore, the APK file format is essentially similar to a ZIP compressed archive. An APK file contains various resource files required for application operation, including dex files containing application instructions, runtime library files (with the .so extension), and data files such as images and text.

[0052] The general process of installing applications on an Android system is as follows: The system's application installer unpacks the APK file and stores the runtime library files contained within it in the application's installation directory. The APK file itself is also stored in the application's installation directory. Because both the APK file and the runtime library files obtained from unpacking the APK are stored in the application's installation directory after installation, the runtime library files exist repeatedly: they are stored in compressed form within the APK file, and each runtime library file exists independently outside the APK file. Since the contents of the runtime library files are frequently used during application startup and operation, this storage method allows applications to read data directly without decompressing the APK package, thus accelerating application performance. However, the repeated storage space occupied by the runtime library files wastes valuable storage space. For example, for 40 popular applications, the repeated runtime library files within the APK occupy more than 1GB of storage space, equivalent to more than 300 3MB photo files.

[0053] To address the aforementioned problems, this application proposes a file storage method applied to an electronic device 100. The electronic device 100 can be a mobile terminal. A mobile terminal can also be referred to as a terminal device, user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user apparatus. The mobile terminal can also be a wearable device, such as a smartwatch or smart bracelet. This application does not impose any special limitations on the specific form of the electronic device 100 implementing this technical solution.

[0054] The following is combined with Figure 1 First, we introduce the exemplary electronic devices provided in the following embodiments of this application. Figure 1 A schematic diagram of the structure of the electronic device 100 is shown.

[0055] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0056] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0057] The processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. In this embodiment, the processor 110 may receive the image stream from the rear camera and output a preview image; adjust the rendering parameters of the preview image or adjust the hardware parameters of the rear camera when the touch sensor 180K detects a specific gesture; and change the shooting parameters adjusted by the gesture on the small screen based on the user's gesture recognized by the gesture recognition unit.

[0058] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0059] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0060] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0061] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0062] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0063] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0064] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0065] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0066] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0067] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0068] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0069] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0070] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0071] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0072] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0073] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0074] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0075] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0076] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0077] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0078] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1. In this embodiment, electronic device 100 may include a main screen and a small screen. The main screen may be located on the front of electronic device 100, and the small screen may be located on the back of electronic device 100. The main screen can be used to display a window for a camera application and can be used to display preview images. This small screen can be a small screen integrated on the back of the electronic device 100, displaying a preview image when the user takes a selfie using the rear camera. In normal mode (e.g., standby mode), the small screen can display a clock.

[0079] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0080] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0081] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0082] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0083] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0084] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0085] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0086] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0087] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0088] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0089] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0090] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0091] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In some embodiments, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic device 100 may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0092] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0093] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0094] The gyroscope sensor 180B can be used to determine the motion attitude of the electronic device 100. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device 100 about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the shake of the electronic device 100, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to counteract the shake of the electronic device 100 by moving in the opposite direction, thus achieving image stabilization. The gyroscope sensor 180B can also be used in navigation and motion-sensing game scenarios.

[0095] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0096] The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can use the magnetic sensor 180D to detect the opening and closing of the flip cover. In some embodiments, when the electronic device 100 is a flip phone, the electronic device 100 can detect the opening and closing of the flip cover using the magnetic sensor 180D. Then, based on the detected opening and closing state of the cover or the flip cover, features such as automatic flip unlocking can be set.

[0097] The 180E accelerometer can detect the magnitude of acceleration of electronic device 100 in various directions (typically three axes). When electronic device 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the posture of electronic devices and applied to applications such as screen orientation switching and pedometers.

[0098] A distance sensor 180F is used to measure distance. Electronic device 100 can measure distance via infrared or laser. In some embodiments, during a shooting scene, electronic device 100 can utilize the distance sensor 180F to measure distance for rapid focusing.

[0099] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The electronic device 100 emits infrared light outward through the LED. The electronic device 100 uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 can determine that there is no object near the electronic device 100. The electronic device 100 may use the proximity sensor 180G to detect when a user holds the electronic device 100 close to their ear for a call, so as to automatically turn off the screen to save power. The proximity sensor 180G can also be used in holster mode and pocket mode for automatic unlocking and locking of the screen.

[0100] The ambient light sensor 180L is used to sense the brightness of ambient light. The electronic device 100 can adaptively adjust the brightness of the display screen 194 based on the sensed ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also work with the proximity sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

[0101] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can utilize the characteristics of the collected fingerprints to achieve fingerprint unlocking, accessing application locks, taking photos with fingerprints, answering calls with fingerprints, etc.

[0102] Temperature sensor 180J is used to detect temperature. In some embodiments, electronic device 100 uses the temperature detected by temperature sensor 180J to execute a temperature handling strategy. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, electronic device 100 performs thermal protection by reducing the performance of a processor located near temperature sensor 180J to reduce power consumption. In other embodiments, when the temperature is below another threshold, electronic device 100 heats battery 142 to prevent abnormal shutdown of electronic device 100 due to low temperature. In still other embodiments, when the temperature is below yet another threshold, electronic device 100 boosts the output voltage of battery 142 to prevent abnormal shutdown due to low temperature.

[0103] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194. In this embodiment, touch sensor 180K can monitor touch points on the small screen in real time, perform gesture recognition based on the touch points, and determine touch gestures.

[0104] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords. The bone conduction sensor 180M can also contact the human pulse to receive blood pressure signals. In some embodiments, the bone conduction sensor 180M can also be incorporated into headphones to form bone conduction headphones. The audio module 170 can parse the voice signals from the vibrating bone segments of the vocal cords acquired by the bone conduction sensor 180M to realize voice functionality. The application processor can parse heart rate information from the blood pressure signals acquired by the bone conduction sensor 180M to realize heart rate detection functionality.

[0105] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0106] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0107] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0108] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0109] Now combined Figures 2-4 The file storage method provided in the embodiments of this application will be described.

[0110] like Figure 2 The diagram shown is a flowchart of one embodiment of the file storage method provided in this application, including:

[0111] Step 201: Obtain the installation package file.

[0112] Specifically, the installation package file can be obtained through user download, user import, or other methods. The installation package file can be an installation package supported by the Android system, such as an APK file. This installation package file can be the installation package for an Android application. The installation package can be a compressed file; for example, it can include multiple runtime library compressed files, each of which can include compressed data corresponding to that runtime library compressed file. It is understood that the installation package can also include other compressed files, such as compressed files containing images or text. The installation package file can be stored on a storage device through a file system, where the storage device can be a flash memory or a disk, etc. This application embodiment does not specifically limit the type of storage device described above.

[0113] Step 202: Decompress the compressed data of the runtime library file in the installation package file to obtain the runtime library file.

[0114] Specifically, once the installation package file is obtained, it can be installed. During the installation process, the compressed data of the runtime library files within the installation package file can be decompressed, thus obtaining the runtime library files. It's understandable that after decompressing the installation package file, both the installation package file and the resulting runtime library files can be stored in the file system. It should be noted that other compressed files within the installation package file (e.g., compressed data files such as images and text) do not need to be decompressed. Because the file system still retains the installation package file, duplicate runtime library files may be stored there. For example, one runtime library file may exist in compressed form within the installation package file (which is stored in the file system), and another runtime library file with the same content may be stored independently in decompressed form in the file system. For instance, suppose the installation package file includes a compressed runtime library file a', which is obtained by compressing runtime library file a. When the compressed runtime library file a' is decompressed within the installation package file, the runtime library file a is obtained. At this point, the file system stores duplicate runtime library files, such as runtime library compressed file a' and runtime library file a.

[0115] Now combined Figure 3 The decompression of the installation package file is illustrated with an example. For example... Figure 3As shown, the installation package file 300 is stored in the file system. The installation package file 300 contains three compressed runtime library files: a first compressed runtime library file 301, a second compressed runtime library file 302, and a third compressed runtime library file 303. Next, the installation package file 300 is decompressed, resulting in three runtime library files, for example, a first runtime library file 301', a second runtime library file 302', and a third runtime library file 303'. The first runtime library file 301' is the runtime library file obtained by decompressing the first compressed runtime library file 301, the second runtime library file 302' is the runtime library file obtained by decompressing the second compressed runtime library file 302, and the third runtime library file 303' is the runtime library file obtained by decompressing the third compressed runtime library file 303. At this point, the file system includes both compressed runtime library files (e.g., first runtime library compressed file 301, second runtime library compressed file 302, and third runtime library compressed file 303) and decompressed runtime library files (first runtime library file 301', second runtime library file 302', and third runtime library file 303').

[0116] Step 203: Record the correspondence between one or more data blocks of the runtime library compressed file in the installation package file and the runtime library file, as well as the first offset of one or more data blocks of the runtime library compressed file in the installation package file in the installation package file, and release one or more data blocks of the runtime library compressed file in the installation package file.

[0117] Specifically, after decompressing the installation package file to obtain the runtime library file, the correspondence between one or more data blocks of the compressed data of the runtime library file in the installation package file and the runtime library file itself can be recorded, as well as the first offset of one or more data blocks of the compressed data of the runtime library file in the installation package file within the installation package file. In practical implementation, according to the format definition of the installation package file (e.g., APK file), each compressed file contained in the APK file can be scanned, and it can be determined whether it is a runtime library file with the .so extension based on the filename stored in the metadata. For each runtime library file, the application's installation directory can be scanned to find the corresponding independently stored runtime library file (e.g., ...). Figure 3 The first runtime file 301', the second runtime file 302', or the third runtime file 303' are stored in the archive, and the correspondence between the compressed runtime file and the independently stored runtime file is recorded.

[0118] Furthermore, the aforementioned correspondence and the first offset information can be stored in the metadata of the installation package file within the inode metadata area of ​​the file system. Specifically, the aforementioned correspondence can be used to characterize the relationship between one or more data blocks of compressed data from all runtime files in the installation package file and the decompressed runtime files. For example, this correspondence may include the inode number of the runtime file corresponding to one or more data blocks of compressed data from the runtime files in the installation package file. The aforementioned first offset is used to characterize the offset of the first byte of one or more data blocks of compressed data from the runtime files in the installation package file within the installation package file. For example, the first byte of the compressed runtime file corresponds to the 1314th byte of the installation package file.

[0119] It should be noted that the above correspondence can record the inode number of the runtime library file. This runtime library file can be obtained by decompressing the same installation package file, or it can be a runtime library file with the same content after decompressing the installation package file of another application. Some runtime libraries may be referenced by multiple applications; therefore, multiple application installation directories may contain runtime library files with the same content.

[0120] Next, after recording the correspondence and first offset information of one or more data blocks of the compressed data of the runtime files in the installation package file, one or more data blocks of the compressed data of the runtime files in the installation package file can be released, thereby saving storage space of the electronic device 100. In specific implementation, the above-mentioned release operation can be to set the logical storage address of the corresponding one or more data blocks to 0 in the database index of the installation package file and reclaim these data blocks, that is, clear the storage space occupied by these data blocks. It can be understood that when releasing one or more data blocks, it can be to release one or more data blocks of the compressed data of all runtime files in the installation package file, or it can be to release one or more data blocks of the compressed data of some runtime files in the installation package file.

[0121] Now combined Figure 4 An example is provided. Figure 4As shown, the file system stores an installation package file 300, metadata 310 of the installation package file 300, and a set of decompressed files 320. The installation package file 300 includes multiple released compressed data and other compressed data. For example, the released compressed data may include first released compressed data 401, second released compressed data 402, and third released compressed data 403, while the other compressed data may include fourth other compressed data 404. The first released compressed data 401 may be a compressed file obtained by releasing data blocks from the first compressed runtime library file 301, the second released compressed data 402 may be a compressed file obtained by releasing data blocks from the second compressed runtime library file 302, and the third released compressed data 403 may be a compressed file obtained by releasing data blocks from the third compressed runtime library file 303. It is understood that the released compressed data stores compressed runtime library files, while the other compressed data stores compressed data of data files such as images and text. The decompressed file set 320 includes decompressed runtime library files, such as a first runtime library file 301', a second runtime library file 302', and a third runtime library file 303'. Metadata 310 includes information such as a correspondence relationship 311 and a first offset 312. The correspondence relationship 311 may include the inode number of the first runtime library file 301' corresponding to the first released data block 401, the inode number of the first runtime library file 302' corresponding to the second released data block 402, and the inode number of the first runtime library file 303' corresponding to the third released data block 403. The first offset 312 may include the offset of the first byte of the data block of the first released compressed data 401, the offset of the first byte of the data block of the second released compressed data 402, and the offset of the first byte of the data block of the third released compressed data 403 within the installation package file 300.

[0122] Optionally, after recording the correspondence between one or more data blocks of compressed runtime library data in the installation package file and the runtime library file, as well as the first offset of one or more data blocks of compressed runtime library data in the installation package file within the installation package file, the installation package file can be marked to indicate that it is an installation package for which space has been saved. Since the storage space has not yet been released, but to prevent applications from accessing the installation package file while data blocks are being released, and the file system has not yet recognized that the installation package file requires special processing, resulting in the inability to return compressed runtime library file data and thus affecting application execution, the installation package file can be marked first. By pre-setting the mark, the file system can still respond to application read requests even if the space release operation is not yet complete.

[0123] Furthermore, when the file system releases one or more data blocks (e.g., compressed runtime library files) in an installation package file, since a runtime library file may occupy multiple contiguous data blocks, and a data block may contain data from different compressed files (e.g., containing data from both runtime library compressed files and data compressed files), if a data block contains data from different compressed files, the data block storing the compressed data of the runtime library file will not be released. In other words, the file system can release a portion of the data blocks of a compressed runtime library file to be released, where this portion of the data block only contains data from the runtime library compressed file and not data from the data compressed file. Data blocks containing both runtime library compressed file data and data compressed file data are not released. For example, the file system can process the inode corresponding to the installation package file, setting the logical storage address record of the data block to be released to 0. Then, the file system performs a data block reclamation operation, making the released data block available for use by other files, thereby completing space release and improving space storage efficiency. It should be noted that storage devices typically divide storage units (e.g., data blocks) into granularities such as 612 bytes or 4KB. A runtime library compressed file may occupy a portion of a storage unit within an installation package file, and the same storage unit may also contain data from other compressed files within the installation package file. In other words, the same data block may contain data from different compressed files (e.g., a runtime library compressed file and a data compressed file). This application embodiment will not release the data block containing the runtime library compressed file data.

[0124] Now combined Figure 5 The method of releasing the above-mentioned portions is illustrated by example. Figure 5As shown, the runtime library compressed file 510 may include four parts of data, such as the first part 511, the second part 512, the third part 513, and the fourth part 514, which occupy the first data block 501, the second data block 502, the third data block 503, and the fourth data block 504, respectively. It can be understood that each data block can be a storage unit. The first data block 501 also includes the fifth part 521 of the first other file, and the fourth data block 504 also includes the sixth part 531 of the second other file. It can be understood that the aforementioned first and second other files can be compressed files of images or text (i.e., non-runtime library compressed files). Since the first data block 501 and the fourth data block 504 contain not only partial data of the runtime library compressed file 510 (e.g., first data 511 and fourth data 514), but also partial data of other files (e.g., fifth data 521 of the first other file and sixth data 531 of the second other file), and since the first and second other files have not been decompressed, the data cannot be recovered after releasing the fifth data 521 and the sixth data block 531. Therefore, the data stored in the first data block 501 and the fourth data block 504 cannot be released; that is, the first data block 501 and the fourth data block 504 cannot be released. Only the data stored in the second data block 502 and the third data block 503 is released, thereby completing the release of partial data blocks of the runtime library compressed file 510.

[0125] It is understood that the above embodiments are illustrated using Android system APK files, but do not constitute a limitation on the embodiments of this application. In some embodiments, this application is also applicable to other types of installation package files in the file field. Therefore, the embodiments of this application do not specifically limit the type of the above-mentioned installation package files.

[0126] It should be noted that the application scenario of this application embodiment can be that during the application installation process, the installer completes the decompression of the installation package file (e.g., apk file), or the system can set up a background worker thread to trigger the above method when the system is idle.

[0127] The above text passed Figures 2-5 The process of storing installation package files has been illustrated with an example. The following text will then explain... Figures 6-8 This example illustrates the process by which an application accesses an installation package file.

[0128] Figure 6This is a software system architecture diagram of electronic device 100. Application 600 runs on electronic device 100. Electronic device 100 can run Android or an Android-based operating system, using APK format files as application installation packages. After installation, various files (e.g., runtime library files) are stored on storage device 620. Figure 6 As shown, storage device 620 is used to store instructions and data files needed during application execution. Specifically, storage device 620 can store the installation package file (e.g., an APK file) itself, and the runtime library file obtained by decompressing the installation package file. Operating system 610 may include file system 611 and compression unit 612. Compression unit 612 is used to compress the runtime library file, thereby obtaining a compressed runtime library file. Furthermore, application 600 typically does not directly access storage device 620, but instead sends file creation, read / write operation requests to file system 611 in operating system 610. File system 611 can be of type f2fs or ext4; it is understood that the type of file system 611 can also be other types, and this embodiment does not specifically limit the type of file system 611. After receiving the creation, read / write operation requests, file system 611 can further select the data storage location and interact with storage device 620, thereby completing application access.

[0129] like Figure 7 The diagram shown is a flowchart illustrating one embodiment of the file access method provided in this application. Figure 7 The application scenarios illustrated can be application sharing, for example, a user can share an installation package file with another user through the application sharing function of an application. Other application scenarios are also possible, for example, a user can access one or more data blocks within an installation package file through an application. The following description uses access to one or more data blocks within an installation package file as an example, but does not constitute a limitation on the embodiments of this application. These include:

[0130] In step 701, application 600 sends an access request to file system 611 to access one or more data blocks that have been released in the installation package file.

[0131] Specifically, application 600 may send an access request to file system 611 to access one or more data blocks that have been freed in the installation package file. The access request may include a second offset and a data length for the one or more data blocks to be accessed. The second offset represents the offset of the one or more data blocks to be accessed within the installation package file, and the data length represents the length of the data being accessed.

[0132] In its implementation, application 600 can access one or more freed data blocks within the installation package file, where the freed data blocks may be runtime library compressed files. For example, file system 611 can provide a file read interface, such as `read_data_page(file, offset, size)`, to move file data blocks within a specified range from storage devices to DRAM, thereby allowing applications to directly read file data blocks from DRAM. It is understood that file read operations (including installation package files) typically go through the `read_data_page` interface, which is a generic interface.

[0133] Step 702, the file system 611 queries the runtime library file corresponding to the accessed freed data block.

[0134] Specifically, when the file system 611 receives an access request from the application 600, it can obtain the second offset of the one or more data blocks to be accessed in the installation package file, and can look it up in the logical address of the data block recorded in the metadata. If the logical address of the one or more data blocks to be accessed is 0, it means that the one or more data blocks to be accessed have been released.

[0135] Since one or more accessed data blocks do not contain data (e.g., the data has been released), the file system 611 can query the runtime library file corresponding to the accessed released data block to retrieve the accessed data again. In a specific implementation, the file system 611 can query the metadata of the accessed released data block to obtain the correspondence and a first offset. The first offset represents the offset of the compressed runtime library file within the installation package file. By comparing the second offset in the access request with the first offset recorded in the metadata—for example, each compressed runtime library file contains a first offset—the second offset can be compared one by one with the first offset of each compressed runtime library file. If the first offset of any compressed runtime library file (e.g., assuming the compressed runtime library file is a.so) matches the second offset, the correspondence (e.g., inode number) corresponding to that compressed runtime library file (a.so) can be obtained. The runtime library file corresponding to the accessed released data block can be found using this inode number. Once the file system 611 finds the inode number in the metadata, it can retrieve the corresponding runtime file based on that inode number.

[0136] In step 703, the compression unit 612 compresses the accessed runtime library file to obtain a compressed file of the accessed runtime library.

[0137] Specifically, after the file system 611 obtains the inode number, it can instruct the compression unit 612 to compress the accessed runtime library file, thereby obtaining a compressed runtime library file that corresponds to the inode number. When executing a compression algorithm (e.g., the deflate algorithm), the compression unit 612 should maintain consistency with the compression algorithm of the installation package file. This ensures that the compressed runtime library file obtained after compression is identical to the one in the installation package file; for example, the file length and content are consistent. After compressing the accessed runtime library file, the resulting compressed runtime library file can be stored in a compression data cache. This means that the compression data cache can be used to store the compressed runtime library file. This allows the application to directly access the compressed runtime library file in the cache without needing to compress it every time it accesses the file, avoiding the efficiency reduction caused by repeated compression and improving access efficiency.

[0138] It should be noted that before executing step 703, for example, after the file system 611 obtains the inode number, it can also query whether the compressed data cache already contains the accessed runtime library compressed file corresponding to the inode number. If the compressed data cache already contains the accessed runtime library compressed file corresponding to the inode number, the accessed data can be directly obtained from the compressed data cache. If the compressed data cache does not contain the accessed runtime library compressed file corresponding to the inode number, then step 703 can be further executed.

[0139] In step 704, the file system 611 reads the accessed runtime library compressed file according to the first offset, the second offset, and the data length, and returns the read content to the application 600.

[0140] Specifically, after the compression unit 612 compresses the accessed runtime library file to obtain a compressed runtime library file, the file system 611 can read from the compressed runtime library file based on the first offset, the second offset, and the data length, thereby obtaining the read content. In a specific implementation, the file system 611 can read from the position of the second offset minus the first offset in the compressed runtime library file, and after reading the accessed data length, obtain the read content. Then, the file system 611 can return the read content to the application 600.

[0141] Now combined Figure 8 The above access process is illustrated by example. Figure 8As shown, the first runtime library compressed file 810 in the installation package file includes four parts of data: the seventh part 811, the eighth part 812, the ninth part 813, and the tenth part 814. The seventh part 811 occupies the fifth data block 801, the eighth part 812 occupies the sixth data block 802, the ninth part 813 occupies the seventh data block 803, and the tenth part 814 occupies the eighth data block 804. The fifth data block 801 also contains the eleventh part 815 of other runtime library files, and the eighth data block 804 also contains the twelfth part 816 of other runtime library files. Therefore, the fifth data block 801 and the eighth data block 804 are not released. Assuming that the sixth data block 802 and the third data block 803 have been released, if the application accesses the sixth data block 802 at this time, the file system can determine the target runtime library file 840 corresponding to the inode number through the second offset 820 in the access request, the first offset 830 in the metadata, and the first correspondence (inode number). It is understood that the first runtime library compressed file 810 is a file stored in the installation package file after compressing the runtime library file corresponding to the aforementioned inode number. The target runtime library file 840 is a file obtained by decompressing the first runtime library compressed file 810. Since some data blocks in the first runtime library compressed file 810 have been released, the application cannot access the first runtime library compressed file 810. At this time, the target runtime library file 840 needs to be compressed, thereby further obtaining the second runtime library compressed file 850, which can be the accessed runtime library compressed file. The compression algorithm used for the data in the installation package file is consistent with the compression algorithm executed by the compression unit. Therefore, the length and content of the second runtime library compressed file 850 are consistent with those of the first runtime library compressed file 810. Next, the file system can read from the second runtime library compressed file 850. For example, it can read from the third offset 860 in the second runtime library compressed file 850, where the third offset 860 = the second offset 820 - the first offset 830. After reading the data length L, the program obtains the read content and returns it to the application.

[0142] Figure 9 This is a schematic diagram of the structure of one embodiment of the file storage device of this application, as shown below. Figure 9 As shown, the file storage device 90 may include: an acquisition module 91, a decompression module 92, and a release module 93; wherein,

[0143] Module 91 is used to obtain the installation package file;

[0144] The decompression module 92 is used to decompress the runtime library compressed file in the installation package file to obtain the runtime library file corresponding to the runtime library compressed file;

[0145] Release module 93 is used to record the correspondence and the first offset, and release one or more data blocks of the runtime library compressed file in the installation package file; wherein, the correspondence is used to characterize the correspondence between one or more data blocks of the runtime library compressed file in the installation package file and the runtime library file, and the first offset is used to characterize the offset of one or more data blocks of the runtime library compressed file in the installation package file in the installation package file.

[0146] In one possible implementation, the installation package file also includes a compressed data file.

[0147] In one possible implementation, the release module 93 is also used to release one or more data blocks of all runtime library compressed files in the installation package file.

[0148] In one possible implementation, the release module 93 is also used to release one or more data blocks of a portion of the runtime library compressed file in the installation package file.

[0149] In one possible implementation, the release module 93 is further configured not to release one or more data blocks if one or more data blocks store data of a data compressed file in the installation package file.

[0150] In one possible implementation, the file storage device 90 further includes:

[0151] The tagging module is used to mark installation package files that have had their data blocks released; the tag is used to identify that the installation package file has had its data blocks released.

[0152] Figure 10 This is a schematic diagram of the structure of one embodiment of the document access device of this application, as shown below. Figure 10 As shown, the file storage device 1000 may include: an access module 1010, a query module 1020, a compression module 1030, and a return module 1040; wherein,

[0153] Access module 1010 is used by the application to send an access request to the file system; wherein the access request is used to access one or more data blocks that have been released in the installation package file, and the access request includes a second offset and a data length;

[0154] The query module 1020 is used to query the file system for runtime library files corresponding to one or more released data blocks;

[0155] Compression module 1030 is used by the file system to compress the runtime library files obtained from the query, so as to obtain the compressed file of the accessed runtime library.

[0156] Return module 1040 is used to obtain the first offset from the file system, read from the accessed runtime library compressed file based on the first offset, the second offset, and the data length, and return the reading result to the application.

[0157] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0160] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A file storage method, characterized in that, The method includes: Obtain the installation package file; Decompress the runtime library compressed file in the installation package file to obtain the runtime library file corresponding to the runtime library compressed file; Record the correspondence and the first offset, and release one or more data blocks of the runtime library compressed file in the installation package file; wherein, the correspondence is used to characterize the correspondence between one or more data blocks of the runtime library compressed file in the installation package file and the runtime library file, and the first offset is used to characterize the offset of one or more data blocks of the runtime library compressed file in the installation package file in the installation package file.

2. The method according to claim 1, characterized in that, The installation package file also includes a data compression file.

3. The method according to claim 1 or 2, characterized in that, The step of releasing one or more data blocks of the runtime library compressed file in the installation package file includes: Extract one or more data blocks from all runtime library compressed files in the installation package file.

4. The method according to claim 1 or 2, characterized in that, The step of releasing one or more data blocks of the runtime library compressed file in the installation package file includes: Release one or more data blocks from the runtime library compressed file in the installation package file.

5. The method according to claim 2, characterized in that, The method further includes: If the one or more data blocks store data from the data compressed file in the installation package file, then the one or more data blocks will not be released.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: The installation package file that has had its data blocks released is marked; wherein the mark is used to identify that the installation package file has had its data blocks released.

7. A file access method, applied to an electronic device, characterized in that, The electronic device has an application installed, and the method includes: The application sends an access request to the file system; wherein the access request is used to access one or more data blocks that have been released in the installation package file, and the access request includes a second offset and a data length; The file system queries the runtime library files corresponding to the one or more data blocks that have been released; The file system compresses the runtime library files obtained from the query to obtain the accessed runtime library compressed file; The file system obtains a first offset, reads data from the accessed runtime library compressed file based on the first offset, the second offset, and the data length, and returns the reading result to the application. Wherein, the first offset is used to characterize the offset of one or more data blocks of the runtime compressed file in the installation package file within the installation package file, the second offset is used to characterize the offset of one or more data blocks being accessed within the installation package file, and the data length is used to characterize the length of the data being accessed this time.

8. An electronic device, characterized in that, include: A memory for storing computer program code, the computer program code including instructions, which, when read from the memory by the electronic device, cause the electronic device to perform the method as claimed in any one of claims 1-6 or the method as claimed in claim 7.

9. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-7.

Images