CN117520279A

CN117520279A - File storage method and electronic equipment

Info

Publication number: CN117520279A
Application number: CN202210912647.6A
Authority: CN
Inventors: 李韦露; 赵凯晓
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-07-30
Filing date: 2022-07-30
Publication date: 2024-02-06

Abstract

The application provides a file storage method and electronic equipment. The method comprises the steps that when the electronic equipment stores files, the electronic equipment compresses the files stored in the first path to obtain compressed files, the compressed files are transferred to the second path, and the files stored in the first path are deleted. When a user accesses a file that wants a first path, the electronic device may read the compressed file from a second path that has a mapping relationship with the first path and decompress the compressed file, after which the application may return the file that the user wants to access. According to the technical scheme, the files are compressed, the storage space occupied by the files can be reduced, the application program does not sense compression and decompression of the files, and the use feeling of a user is good.

Description

File storage method and electronic equipment

Technical Field

The embodiment of the application relates to the technical field of terminals, in particular to a file storage method and electronic equipment.

Background

With the development of the information age, users can acquire a variety of data information (e.g., pictures, videos, etc.). The user needs to store data in the electronic device used based on his own needs. However, since the storage space of the electronic device is fixed at present, the phenomenon of insufficient storage space of the electronic device occurs with the increase of the use duration of the user.

Thus, how to improve the phenomenon of insufficient storage space is a problem to be solved.

Disclosure of Invention

The application provides a file storage method and electronic equipment, which can reduce the storage space occupied by files, and an application program does not sense the compression and decompression of the files, so that the use feeling of a user is good.

In a first aspect, the present application provides a method for storing files, where the method is applied to a first electronic device, and in the method, a media library is provided in the first electronic device, where the media library has a function of providing file storage for an application program installed on the first electronic device, and the application program includes a first application program.

In response to a first operation initiated by the first application, the media library performs storage of the first file, the first operation indicating that the first file is stored to a first path.

The media library stores the first file to a second path.

The first path and the second path have a mapping relationship, the first path is a target path of the first application program operating the first file, and the second path is an actual storage path of the first file.

Wherein the media library may record a data table of the file as shown in table 1.

Field name	Type(s)
		_id	INTEGER (INTEGER)
_data	TEXT (TEXT)
		transform_type	INTEGER (INTEGER)
transformed_path	TEXT (TEXT)

TABLE 1

The type of the field_id is integer type, the field_id represents the index of the file to be accessed, and the index of the file serving as the unique identifier can accelerate the query speed.

The type of field_data is a text type, and the field_data represents an absolute path of file storage to be accessed.

In some implementations, the first path can be a path represented by field_data.

The type of the field transform_type is an integer type, and the field transform_type indicates whether the file format of the file to be accessed is converted.

The type of the field converted_path is a text type, and the field converted_path indicates an absolute path in which a file to be accessed is actually stored in the electronic device 100.

In some embodiments, the second path may be a path represented by the field transformed_path.

According to the method, decoupling of the application program and the electronic equipment operating system is achieved in the file storage process, the application program still accesses the file according to the first path, the application program does not need to update codes to process the compressed file actually stored in the second path, namely the application program does not sense compression and decompression and storage of the file, and development work of the application program is saved.

Moreover, the user does not have to care about the internal processing of the file, nor does he have to change the way he accesses the file, while harvesting the good experience that storage space is conserved.

With reference to the first aspect, in some embodiments, in the method, in response to a second operation of the first application program to access the first file, the media library determines the first file under the second path according to a mapping relationship between the first path and the second path, and provides a function of accessing the first file for the first application program, where the second operation indicates that the first file is in the first path.

Therefore, the application program can access the first file according to the first path, and the electronic equipment media library accesses the first file from the hardware layer according to the mapping relation between the first path and the second path, so that the development workload of the application program is saved.

With reference to the first aspect, in some embodiments, in the method, the media library provides the application with the first path to access the first file.

In one possible implementation, the media library may generate the data table shown in table 1 above, and send the first path indicated by the field_data to the application.

Thus, the application program can access the file according to the first path, and the development workload of the application program is saved.

With reference to the first aspect, in some embodiments, in the method, the storing, by the media library, the first file to the second path specifically includes:

the media library compresses the first file and stores the compressed file after the first file is compressed to the second path.

In some implementations, the media library of the electronic device can compress files to be stored. For example, the compression process may be performed according to the compression scheme indicated by the field transform_type in table 1.

Therefore, the application program can save the storage space under the condition of not perceiving the compression, decompression and storage of the file, and the user experience is good.

With reference to the first aspect, in some embodiments, in the method, the reading, by the media library of the first electronic device, the first file from the second path specifically includes:

the media library of the first electronic device reads the compressed file of the first file from the second path, and decompresses the compressed file to obtain the first file.

In some implementations, the media library of the electronic device can decompress the file to be accessed. For example, the decompression processing may be performed according to the compression scheme indicated by the field transform_type in table 1.

With reference to the first aspect, in some embodiments, in the method, a storage space corresponding to the second path belongs to the first electronic device. Therefore, the file can be stored in the first electronic device, namely the storage mode is local storage, and the safety can be ensured.

With reference to the first aspect and the third aspect, in some implementations, in the method, the providing, by the media library, a function of accessing the first file for the first application includes:

the media library of the first electronic device obtains a file descriptor corresponding to the second path, and the file descriptor is used for sending the first file to the application program of the first electronic device by the media library of the first electronic device.

In some embodiments, when accessing a file, the media library maps to a second path according to the first path, and then obtains a file descriptor for the second path, and the file descriptor may be sent to the application.

With reference to the first aspect, in some implementations, in the method, when the storage space indicated by the second path belongs to the second electronic device, in response to a first operation initiated by the first application program, the media library performs storage on the first file, and the first operation indicates that the first file is stored to the first path specifically includes:

the first electronic device establishes a communication connection with the second electronic device.

The first electronic device sends the first file to the second electronic device to store the first file at the second electronic device.

The second path includes: an identification of the second electronic device and a storage path of the first file stored in the second electronic device.

According to the method, decoupling of the application program and the electronic equipment operating system is achieved in the file storage process, the application program still accesses the file according to the first path, the application program does not need to update codes to process the compressed file actually stored in the second path, namely the application program does not sense compression and decompression and storage of the file, and development work of the application program is saved. Moreover, the user does not have to care about the internal processing of the file, nor does he have to change the way he accesses the file, while harvesting the good experience that storage space is conserved. In addition, the storage space of other electronic devices can be fully utilized.

With reference to the first aspect, in some embodiments, in the method, in response to a second operation of the first application to access the first file, the determining, by the media library, the first file under the second path according to a mapping relationship between the first path and the second path specifically includes:

the media library determines the second path according to the mapping relation between the first path and the second path.

The media library sends a request to the second electronic device according to the second path and receives the first file sent by the second electronic device.

The media library sends the first file to the application of the first electronic device.

In this way, the first file may be actually stored in the second electronic device, so as to achieve the effect of expanding the storage space, and the application program does not sense that the file is stored in other devices, and the information about the first file acquired by the application program is the field_id and the field_data in table 1.

With reference to the first aspect, in some embodiments, in the method, a manner in which the first electronic device and the second electronic device establish a communication connection includes any one of the following: bluetooth connection, wireless local area network connection, high fidelity wireless communication, infrared connection, and near field connection.

With reference to the first aspect, in some embodiments, in the method, the first electronic device logs in to the same system account as the second electronic device.

With reference to the first aspect, in some embodiments, in the method, the second electronic device is a standby device of the first electronic device that is carried around.

For example, the user may carry two handsets, the first electronic device may be one of the handsets, and the second electronic device may be the other of the handsets.

In some embodiments with reference to the first aspect, in the method, the second electronic device is a companion device of the first electronic device. For example, the first electronic device may be a cell phone, the second electronic device may be a vehicle, and the user may use the cell phone to store a first file (e.g., a document, a photograph, a video, etc.), which is actually stored in the vehicle.

With reference to the first aspect, in some embodiments, in the method, the first file includes a photograph or a video, the method further includes: detecting that a user takes the photo or the video through a camera application program or stores the photo or the video through a social application program, wherein a storage path displayed in the application program of the photo or the video is the first path;

The media library of the first electronic device responds to a second operation of the first application program for accessing the first file, and the second operation specifically comprises the following steps.

The first electronic device detects that the user opens the photo or video through a social application or gallery.

After the media library determines the first file under the second path according to the mapping relationship between the first path and the second path, the method further comprises:

the first electronic device displays a photograph or plays a video of the second path.

the media library of the first electronic device responds to the second operation of the first application program for accessing the first file, and specifically comprises the following steps:

the first electronic device detects that a user sends the photo or video through a social application;

The electronic device transmits the photograph or video under the second path.

With reference to the first aspect, in some embodiments, in the method, the first file includes audio, the method further includes: detecting an operation of storing or recording the audio by a user through an audio application program, wherein a storage path displayed by the audio in the application program is the first path;

the first electronic device detects that a user opens the audio through an audio application;

the first electronic device plays the audio under the second path.

In a second aspect, an embodiment of the present application provides an electronic device, including: a memory, one or more processors; the memory is coupled to one or more processors, the memory for storing computer program code, the computer program code comprising computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as in the first aspect or any implementation of the first aspect.

In a third aspect, embodiments of the present application provide a computer-readable storage medium comprising instructions that, when executed on an electronic device, cause the electronic device to perform a method as in the first aspect or any implementation of the first aspect.

It will be appreciated that the electronic device provided in the second aspect and the computer storage medium provided in the third aspect are both configured to perform the method provided in the embodiment of the present application. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

Fig. 1 is a schematic structural diagram of an electronic device 100 according to an embodiment of the present application.

Fig. 2A to fig. 2D are schematic views of some users who store and view files according to embodiments of the present application.

Fig. 3 is a schematic block diagram of a software structure of the electronic device 100 according to an embodiment of the present application.

Fig. 4 is a flowchart of a method for storing files according to an embodiment of the present application.

Fig. 5 is a flowchart of a method for accessing a file according to an embodiment of the present application.

Fig. 6 is a schematic diagram of a system architecture of a FUSE according to an embodiment of the present application.

Fig. 7 is a communication system provided in an embodiment of the present application.

Fig. 8 is a schematic block diagram of a software structure of another electronic device 100 according to an embodiment of the present application.

Fig. 9 is a flowchart of another method for storing files according to an embodiment of the present application.

Fig. 10 is a flowchart of another method for accessing a file according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and thoroughly described below with reference to the accompanying drawings. Wherein, in the description of the embodiments of the present application, "/" means or is meant unless otherwise indicated, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and in addition, in the description of the embodiments of the present application, "plural" means two or more than two.

The terms "first," "second," and the like, are used below for descriptive purposes only and are not to be construed as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature, and in the description of embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" is two or more.

The term "User Interface (UI)" in the following embodiments of the present application is a media interface for interaction and information exchange between an application program or an operating system and a user, which enables conversion between an internal form of information and an acceptable form of the user. The user interface is source code written in a specific computer language such as java, extensible markup language (extensible markup language, XML), and the like, and the interface source code is analyzed and rendered on the electronic device 100, so that the interface source code is finally presented as content which can be identified by a user. A commonly used presentation form of the user interface is a graphical user interface (graphic user interface, GUI), which refers to a user interface related to computer operations that is displayed in a graphical manner. It may be a visual interface element of text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, etc., displayed in the display of the electronic device 100.

In order to more clearly describe the method provided by the embodiment of the present application, the electronic device provided by the embodiment of the present application is described below.

Fig. 1 shows a schematic configuration of an electronic device 100.

The electronic device 100 may be a cell phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a netbook, a cellular phone, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) device, a Virtual Reality (VR) device, an artificial intelligence (artificial intelligence, AI) device, a wearable device, a vehicle-mounted device, a smart home device, and/or a smart city device, without limitation, the electronic device 100 may also include a non-portable terminal device such as a laptop computer (labtop) having a touch-sensitive surface or touch panel, a desktop computer having a touch-sensitive surface or touch panel, and the like. The embodiment of the present application does not particularly limit the specific type of the electronic device 100.

As shown in fig. 1, the electronic device 100 may include a processor 110, an external memory 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, a user identification module (subscriber identification module, SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration 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, and the like.

It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 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.

The processor 110 may include one or more processing units, such as: the processor 110 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 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.

In some implementations, the processor 110 may determine whether a conversion has occurred in the file format of the file to be accessed and whether the file to be accessed is actually stored in the peer electronic device. The processor 110 may also change the file format of the file to be accessed and generate a splice path for the file to be accessed.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others. It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present invention is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

The internal memory 121 may be referred to as a running memory, may be disposed in the processor 110, may be a cache memory, and may particularly refer to a buffer (buffer) or a cache memory (cache), and may be mainly used to store running data generated during running of an electronic device such as a mobile phone. If the processor 110 needs to reuse the instruction or data, it can be called directly from the internal memory 121, avoiding reading the external memory 120, reducing the latency of the processor 110 and thus improving the efficiency of the system. The operation data and the like stored in the internal memory 121 are lost at the time of power failure, and are not saved.

The internal memory 121 may include one or more random access memories (random access memory, RAM) and one or more non-volatile memories (NVM).

The random access memory may include a static random-access memory (SRAM), a dynamic random-access memory (dynamic random access memory, DRAM), a synchronous dynamic random-access memory (synchronous dynamic random access memory, SDRAM), a double data rate synchronous dynamic random-access memory (double data rate synchronous dynamic random access memory, DDR SDRAM, such as fifth generation DDR SDRAM is commonly referred to as DDR5 SDRAM), etc.; the nonvolatile memory may include a disk storage device, a flash memory (flash memory).

The FLASH memory may include NOR FLASH, NAND FLASH, 3D NAND FLASH, etc. divided according to an operation principle, may include single-level memory cells (SLC), multi-level memory cells (MLC), triple-level memory cells (TLC), quad-level memory cells (QLC), etc. divided according to a storage specification, may include universal FLASH memory (english: universal FLASH storage, UFS), embedded multimedia memory cards (embedded multi media Card, eMMC), etc. divided according to a storage specification.

The random access memory may be read directly from and written to by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other on-the-fly programs, may also be used to store data for users and applications, and the like.

The nonvolatile memory may store executable programs, store data of users and applications, and the like, and may be loaded into the random access memory in advance for the processor 110 to directly read and write.

The external memory 120 may be used to store an operating system, installed applications, registration information, user data, etc., which is not lost when powered down and is still stored in the external memory 120 when powered back on. The external Memory 120 may include a Read-Only Memory (ROM), a secure digital card (Secure Digital Memory Card, SD card), and the like. ROM may be used primarily to store read-only data such as operating system, underlying software, initialization information, etc. While SD cards are generally open to users, users can modify and access the files above. The external memory 120 may be a non-volatile memory that enables expansion of the memory capabilities of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory 120 to realize a data storage function. Files such as music, video, photos, and documents are stored in an external nonvolatile memory.

The memory space of the external memory 120 may be generally 16-256G. At present, the size of a high-definition photo is generally 4 MB-15 MB, the size of 1080p definition video of one hour is generally 80G-90G, the memory space occupied by social type application programs such as WeChat and the like is generally more than 10G, and one user can generate data volume of 1 GB-2 GB probably in one day. Therefore, in the process of using the electronic device such as the mobile phone for a long time, the electronic device 100 has a problem of insufficient storage space, and cannot meet the use requirement of the user.

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

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals.

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

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating 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. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor.

The wireless communication module 160 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., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, demodulates and filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

In some implementations, the mobile communication module 150 and the wireless communication module 160 may implement a communication connection function with a peer electronic device.

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

The display screen 194 is used to display images, videos, and the like. The display 194 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) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

In some implementations, the display 194 may cause an application layer of the electronic device to send a file access request in response to a touch operation by a user. The display 194 may also display specific file data after the access is successful.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

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

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals.

The earphone interface 170D is used to connect a wired earphone.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card may be inserted into the SIM card interface 195, or removed from the SIM card interface 195 to enable contact and separation with the electronic device 100.

The fig. 1 embodiment is merely intended to exemplify one typical architecture of an electronic device. Without limitation, as shown in fig. 1, in practice, the electronic device 100 may have more or fewer components, as this application is not limited in this regard.

As mentioned in the embodiment of fig. 1, during the long-term use of the electronic device 100 by the user, there is a problem that the storage space of the electronic device 100 cannot meet the storage requirement that the user continuously exists.

To solve this problem, users may use a network disk to store data. The user can store the data such as photos, videos and the like which want to be reserved in the network disk. However, this approach has security problems such as data leakage and data loss, and also often requires payment. Cloud space similar to a network disk is also widely adopted because it supports users to store data onto a cloud server, and only the cloud space is focused on storage management of media resources such as photos, videos and the like. Cloud space also has risks such as data leakage, data loss and the like, and the problem that expansion needs payment.

In this embodiment, for a file such as a photo, a video, etc. stored in a first path by an application program (such as a gallery), the electronic device 100 may compress the file to obtain a compressed file of the file, and then transfer the compressed file to a second path, and delete the file stored in the first path. When the user wants to access the file at the first path through the application program, the electronic device can find a second path mapped by the user through the first path, read the compressed file of the file from the second path, decompress and restore the file, and finally return the file to the application program for the user to view. The first path and the second path refer to storage paths in a local storage space on the electronic device 100, where the local storage space may be a storage space provided by the external memory 120.

In one possible implementation, for a file of a user through an application (e.g., gallery) photograph, video, etc., the electronic device 100 may store the file to the second path. When a user wants to access the file at the first path through the application, the electronic device 100 may find its mapped second path through the first path, read the file from the second path, and finally return the file to the application for the user to view. The first path and the second path refer to storage paths in a local storage space on the electronic device 100, where the local storage space may be a storage space provided by the external memory 120.

A document storage scenario according to an embodiment of the present application is described below with reference to fig. 2A to fig. 2B: the photo stores the scene.

FIG. 2A illustrates a user interface 300 provided by a social class application. As shown in fig. 2A, in user interface 300, a photograph 301 is presented. The electronic device 100 may save the photograph 301 in response to a user operation (e.g., a long press operation) that the user has acted on the photograph.

Specifically, as shown in fig. 2B, when a long press or the like is detected for the photo 301, the electronic device 100 may provide the user with a download option 302 for the user to download the photo. The electronic device may store the photo downloaded by the user to the following storage path: "storage/patterned/0/Pictures/dongtai/happy. Jpg".

Fig. 2C illustrates a photo browsing user interface 320 provided by a gallery. As shown in fig. 2C, a user may view a photo 301 downloaded through a social class application in a user interface 320. Also, as shown in fig. 2D, the electronic device 100 may further view stored information of the photograph 301 in response to a user operation (e.g., a click operation) by the user on the detail option 303.

The stored information may include a storage path, such as "storage/scheduled/0/Pictures/dongtai/happy. Jpg", as shown in detail 304 in fig. 2D, and may also include a file size, such as "3MB", a file name and format, such as "happy. Jpg".

The storage path "storage/patterned/0/Pictures/dongtai/happy/jpg" may be a logical storage path of the photo 301, and may be used by the gallery to access the photo 301.

The mapping of the logical storage path to the physical storage (e.g., external storage 120) is not intended to be exclusive of the scope of the present discussion as to how the logical storage path and the physical storage path are mapped.

Next, based on the photo storage scenario described above, the software architecture of the electronic device 100 is described in conjunction with fig. 3.

As shown in fig. 3, the software architecture of the electronic device 100 may include: an application layer, a media library, and a kernel layer. Wherein:

the application layer may include picture management class applications such as gallery, social class applications such as WeChat, etc. As in the photo storage scenario described above with reference to fig. 2A-2D, a user may obtain a file such as a photo of interest through a social class application such as WeChat, and may store the file such as the photo to be retained through a picture management class application such as gallery.

The media library may comprise: the device comprises a compression/decompression module and a storage conversion module.

In some examples, among others, the compression/decompression module may be used to compress a file to be stored (e.g., photo 301"happy. Jpg") from an application (e.g., gallery) to obtain a compressed file (e.g., "happy. Zip"). The compress/decompress module may also decompress the compressed file (e.g., "happy. Zip") upon a file access request by the user to access the first path, resulting in a file to be accessed (e.g., "happy. Jpg" of photo 301).

In one possible embodiment, the compression method is not limited to the compression methods such as "zip", "7z" and "rar", and the format may be converted, for example, the format 1 of the file has a size of m1, the format 2 of the file has a size of m2, m1 is greater than m2, and the conversion of the file from the format 1 to the format 2 is also the compression method allowed in the embodiments of the present application.

The storage conversion module may be configured to store the compressed file (e.g., "happy. Zip") output by the compression module to a storage path different from the file to be stored (e.g., "happy. Jpg"), and delete the file to be stored (e.g., "happy. Jpg"), which is equivalent to transferring the file to be stored (e.g., "photograph 301" happy. Jpg ") from a first path (e.g.," storage/patterned/0/Pictures/tangtai/") to a second path (e.g.," storage/patterned/Pictures/").

The storage conversion module may also be responsible for maintaining the data structures exemplarily shown in table 1.

TABLE 1

As shown in table 1, table 1 illustrates data table contents of a local file stored at the electronic device 100, and the local storage data table may include, but is not limited to, a field_id, a field_data, a field transform_type, and a field transform_path.

For example, if the electronic device 100 application layer learns that the file data. Txt is stored in the directory untitled10 under the D disc of the electronic device 100, the field_data of the file data. Txt may be denoted as D:_ntitled10\data. Txt. In the embodiment of the present application, the specific content of the field_data is not limited.

In some embodiments, the path represented by field_data may be referred to as a first path.

In some implementations, when the file format displayed in the application for the file to be accessed is consistent with the file format actually stored in the electronic device 100, the value of the field transform_type may be 0 or the value of the field transform_type may be null; when the file format of the file to be accessed displayed in the application program is fm1 and the file format of the file to be accessed actually stored in the electronic device 100 is fm2, the value of the field transform_type may be 1, where the value of the field transform_type being 1 may refer to the file format conversion algorithm 1 for format conversion of the file format fm1 and the file format fm 2; similarly, when the file format displayed in the application program is fm1 and the file format of the file to be accessed actually stored in the electronic device 100 is fm3, the value of the field transform_type may be 2, where the value of the field transform_type of 2 may refer to the conversion algorithm 2 for the format conversion between the file format fm1 and the file format fm 3.

The type of the field converted_path is a text type, and the field converted_path indicates an absolute path in which a file to be accessed is actually stored in the electronic device 100. In some implementations, when the value of the field transform_type is 0 or null, the field transform_path does not exist; when the value of the above-mentioned field transform_type is not 0 and is not null, that is, the file format in which the file to be accessed is actually stored in the electronic device 100 is not consistent with the file format displayed in the application program, the actual file path in which the file to be accessed is stored in the electronic device 100 is different from the file path displayed in the application program, and the field transform_path may represent the actual file path in which the file to be accessed is stored in the electronic device 100. For example, if the electronic device 100 changes the file format of the file data. Txt to zip, the converted file name is data. Zip, and the file data. Zip is stored in the directory untitled15 under the F disc of the electronic device 100, the field converted_path of the file data. Zip may be denoted as F:_ntitled15\data. Zip.

It should be noted that, when the field converted_path of the file to be accessed does not exist, that is, when the file format of the file to be accessed does not change in the actual storage process, the field_data may represent a file path of the file to be accessed actually stored in the electronic device 100; when a field converted_path of the file to be accessed exists, that is, when the file format of the file to be accessed is converted in the actual storage process, the field_data may represent a file path displayed on the application program by the file to be accessed, and the file to be accessed after the file format conversion is not stored in the file path represented by the field_data but is stored in the file path represented by the field converted_path. That is, the file path indicated by the field_data does not store the data information of the file to be accessed, and if the electronic device 100 needs to access the file, the application program can access the file to be accessed according to the field_data, and the system of the electronic device 100 needs to access the file to be accessed according to the file path indicated by the field transformed_path.

In some embodiments, the path represented by the field transformed_path may be referred to as a second path.

By the file storage method, the storage space occupied by the file in the electronic device 100 can be reduced, and the file format and the storage path of the file are not changed from the perspective of a user, so that the user experience can be maintained.

The table may record a mapping relationship of the first path (_data) and the second path (transformed_path), and a compression manner (transform_type) adopted for the file to be stored. The table may also record the identification (_id) of the file to be stored. When receiving a request for accessing a file to be accessed, the storage conversion module can find a second path mapped by the first path according to the first path, and reads the compressed file from a physical path corresponding to the second path. And finally, transmitting the compressed file to a compression/decompression module to realize decompression.

The kernel layer may include drivers for the various hardware, such as storage drivers, as well as virtual file systems (virtual file system, VFS). The storage drive may be coupled to the external memory 120, and may be used to control the external memory 120 to perform operations such as reading and writing.

Based on the software architecture shown in fig. 3, fig. 4 illustrates a method flow of implementing file storage by the electronic device 100.

As shown in fig. 4, the method flow of implementing file storage by the electronic device 100 is as follows:

s401, the application program stores the first file into the first path by the user, and transmits the file and the first path to the media library.

For example, the application may store the photo 301 selected by the user in the user interface 300 and send a first path (e.g., "stored/scheduled/0/Pictures/dongtai/happy. Jpg") of the photo 301 to the media library.

In some embodiments, whether a third party application or a system-owned application, when a user is able to perceive the presence of a file from the electronic device 100, that is, the user is able to observe the file in a screen, the file is said to occupy a certain storage path in the electronic device. I.e. the file is of a first path.

In one possible implementation, the first path may be automatically allocated by the application, i.e., when the application stores the first file, the application may generate a default storage path for the file and send the path to the media library. And the id may be sent to the application after the media library generates the database as described in table 1 above, and the information that the application may learn is the first path and the id.

S402, the media library compresses the file to generate a compressed file.

In some implementations, the electronic device 100 may process the file in the media library in response to a user performing a local storage operation on the file, after the electronic device 100 learns the first path of the file storage. The compression/decompression module in the media library can compress the file to generate a compressed file. That is, conversion of the file format and the file path occurs when the file is stored in the electronic device 100. Specifically, when the file is downloaded from the third party application to the electronic device or the file is formed by a function such as shooting by the electronic device, the file format of the file is an uncompressed file format. When the kernel layer of the electronic equipment receives the file sent by the media library, a compressed file is obtained after the file is compressed, and then the compressed file is stored in the hardware layer.

The file format displayed by the application layer is an uncompressed file format, and the file format stored by the hardware layer is a compressed file format. Therefore, when the media library of the electronic device 100 generates the data table of the file, two file formats of the file and the conversion relation of the file formats are recorded.

For example, after the compression/decompression module of the media library compresses the file, the media library may learn the manner of compression, such as the field transform_type.

S403, the media library stores the compressed file to the second path, and deletes the file of the first path.

In some implementations, the compression/decompression module of the media library compresses the file, and after obtaining the compressed file, the compressed file may be stored in the second path. Thus, when the hardware layer of the electronic device 100 stores a file that the user wants to store, the file actually stored in the hardware layer is in a compressed file format. After the media library stores the compressed file on the second path, the file at the first path may be deleted. That is, the first path does not store the above-mentioned file. But since the first path may map out the second path, the electronic device 100 may access files stored to the second path according to the first path.

For example, the media library may learn the mapping relationship between the first path and the second path, such as the field_data and the field transform_path shown in table 1.

By compressing and storing the file that the user wants to keep, the storage space occupied by the file in the electronic device 100 can be reduced. Thus, the user can store more files in the electronic device 100 used by the user, the requirement of storing a large number of files by the user can be met, and the files are stored in the local electronic device 100, so that the security is better compared with cloud storage.

Based on the software architecture shown in fig. 3, fig. 5 illustrates a method flow for implementing file access by the electronic device 100.

As shown in fig. 5, the flow of the method for implementing file access by the electronic device 100 is specifically as follows:

s501, a content provider (ContentProvider) in the application framework layer receives a file access request from an application program such as a gallery, for example, a photo access request generated by a user viewing a photo in the gallery. The content provider may transmit a file, such as a photo 301, to the media library that the application program, such as the gallery, wants to access in response to the file access request.

By way of example, the electronic device 100 may send an access request by:

the electronic device 100 may send a file access request to the media library through a content provider (contentProvider). In some embodiments, electronic device 100 may generally support five data storage approaches: sharing preferences (Shared Preferences), network storage, file storage, external storage, and lightweight databases (Structured Query Language, SQLite). The above-described storage generally supports processing of data by the electronic device 100 in a single application. When data in other applications (e.g., media libraries) needs to be manipulated, the component contentProvider needs to be relied on. The contentProvider is one of four components of Android, and can unify the access mode of data.

Further, the contentProvider may send an access request through a uniform resource identifier (Uniform Resource Identifier, URI). A URI generally includes three parts: scheme protocol, hostname (Authority), and path (path). The scheme of ContentProvider can be defined as content:///, by Android. Authority may be used to uniquely identify ContentProvider from which an external caller may use local ContentProvider. Path may be used to represent a file accessed by electronic device 100. For example, URIs may be expressed as content:// media/external/images/media/xxxxx.

The URI may assign a name to each resource (e.g., file), and each contentProvider may have a URI for representing the data provided by the contentProvider. That is, when the application layer of the electronic device 100 sends a data access request to the media library, the electronic device 100 may parse the URI corresponding to the data to obtain the data table shown in table 1 and generated by the file data to be accessed in the media library.

Here, only by the content provider, it is illustrated that there may be such an intermediate module between the application and the media library to take care of transferring files between the two, the naming of which is not limited in any way by the present application. The content provider may also be optional, i.e. file transfer may be directly between the application and the media library.

In addition to the content provider, the electronic device 100 may also send file access requests to the media library through a user space file system (FUSE). The user can realize operations such as accessing the file according to the interface provided by the FUSE, thereby realizing the running of the file system. The FUSE is different from a file system which is completely realized in a kernel mode, only the FUSE driver can be loaded in the kernel, and the kernel does not need to be recompiled, so that the workload of the kernel layer can be reduced. To better describe the second approach, the system architecture of FUSE is first described.

Referring to fig. 6, fig. 6 illustrates a schematic system architecture of a FUSE according to an embodiment of the present application. Fig. 6 includes a user state and a kernel state. User modalities may include, but are not limited to, applications, FUSE File System processes, FUSE libraries, and media libraries, among others. Kernel modes may include, but are not limited to, virtual file systems (Virtual File System, VFS), kernel-based file systems, block devices/dev/FUSE, FUSE drivers, and other kernel sub-modules.

The FUSE framework mainly comprises three parts of a FUSE driver, a FUSE library and a mounting tool FUSE. Among other things, FUSE can be used to interface with VFS as well as with FUSE file system processes.

In some implementations, after the VFS sends a file access request to the FUSE driver, the FUSE driver converts the request to a particular format and sends the request to the FUSE file system process. After the FUSE file system process responds to the access request, the processing result is returned to the FUSE driver, and the FUSE driver converts the result into a format required by the kernel and returns the result to the VFS.

The FUSE library may be used to enable communication with the kernel, receive requests from the block device/dev/FUSE, and translate the requests into one or more function calls, and then return the request results to the block device/dev/FUSE. The mount tool fuse can be used to mount the user file system, i.e. the top-level directory of the file to be accessed is connected to a certain directory of the root directory, and accessing the directory is equivalent to accessing the file.

In some implementations, the electronic device 100 can mount the file path to be accessed on a block device/dev/fuse.

The specific flow of a file request is described in detail in connection with the system architecture diagram of FUSE shown in FIG. 6: the user-state application program sends a file access request to the VFS of the kernel. After the VFS of the kernel receives the request, the VFS of the kernel sends the request to the kernel-state FUSE driver. The kernel-mode FUSE driver sends the request to the user-mode media library through the FUSE library and the FUSE file system process. At this time, the electronic device 100 may obtain the data table as shown in table 1 generated by the file data to be accessed in the media library according to the file access request.

In the embodiment of the present application, the manner of sending the file access request by the application layer is not limited, and other file access request manners besides the two manners may be included.

Wherein the file access request may carry a field_data representing the first path of the file, e.g. "storage/modulated/0/Pictures/dongtai/happy. The file access request may also include information such as, but not limited to, file size, file name, etc. The embodiments of the present application are not limited herein.

S502. the media library may determine the compression manner (e.g., field transform_type) used by the file that the user wants to access.

In some implementations, the media library may find the compression manner (e.g., field transform_type) used by the file in table 1 based on the file identification_id carried in the file access request.

Specifically, the value of the field transform_type in the data table of the file to be accessed may be determined to determine the compression mode. In some examples, when the field transform_type takes a value of 0 or a null value, it is indicated that no compressed file is generated by the file to be accessed.

The electronic device 100 may read out the file to be accessed directly from the physical address corresponding thereto through the first path field_data. When the field transform_type has a value and the value is not 0, it is explained that a compressed file is generated by the file to be accessed, and the compressed file is stored in the second path (field transform_path).

S503, the media library finds a second path mapped by the first path according to the first path carried in the file access request. And then, the media library can decompress the compressed file by using the determined compression mode to restore the uncompressed file.

After the media library of the electronic device 100 receives the file access request, the electronic device may find a second path mapped to the first path of the file according to the first path. That is, the application program accesses the file through the first path when the user accesses the file.

For example, after the media library of the electronic device 100 receives the file access request, a data table of the file to be accessed may be queried from the media library.

The specific content included in the data table of the file to be accessed may refer to the locally stored data table shown in table 1. The first path may refer to a file path represented by field_data, and the second path may refer to a file path represented by field transform_path.

In some implementations, the electronic device 100 may derive the second path through a value of a field transform_type in a data table of the file to be accessed. As can be seen from the related description information shown in table 1, the field transform_type may have no value, may have a value of 0, may have a value of another integer, and the different values represent different format conversion manners.

When the electronic device 100 determines that the value of the field transform_type in the data table of the file to be accessed is 0 or the field transform_type does not take a value, the file to be accessed does not undergo transformation of the file format, and when the transform_path is 0 or does not exist, it means that the electronic device 100 can learn that the file path represented by the field_data is the file path in which the file to be accessed is actually stored in the electronic device 100. The electronic device may access the file directly according to the first path.

When the electronic device 100 determines that the value of the field transform_type in the data table of the file to be accessed is not 0 and the field transform_type has a value, the file to be accessed is converted into a file format (i.e., converted from the file format fm1 into the file format fm2 or into another file format), the electronic device 100 may learn that the file path represented by the field transform_path is a file path (i.e., a second path) in which the compressed file is stored in the electronic device 100.

After the electronic device 100 finds the second path mapped to the first path according to the first path of the file, the electronic device 100 may obtain the compressed file from the hardware layer according to the physical path corresponding to the second path.

The compressed file may be decompressed in a media library. The mode of converting the file format is recorded in the media library, and the electronic equipment can decompress the compressed file according to the conversion mode.

For example, after the electronic device 100 reads the compressed file from the hardware layer, the compressed file may be decompressed from the compression manner in the data table according to the file to be accessed.

The specific content included in the data table of the file to be accessed may refer to the locally stored data table shown in table 1. The electronic device 100 may decompress the compressed file according to the value of the field transform_type in the data table of the file to be accessed. When the value of the field transform_type is 1, since the file format displayed in the application program is fm1 and the file format actually stored in the electronic device 100 is fm2, the conversion algorithm 1 indicated by the field transform_type may refer to the conversion algorithm 1 for converting the file format fm2 into the file format fm 1.

After the electronic device learns the second path, the electronic device 100 may return a file descriptor (fd) of the file to be accessed to an application layer (i.e., an application program that performs file access) according to the second path.

Where fd is the index created by the kernel for the purpose of more efficiently managing the open files. When an application of electronic device 100 opens or accesses a file, the kernel returns fd to the application layer. All system calls that perform Input and Output (I/O) operations need to go through fd. Each fd has a corresponding file, and different fd may point to the same file, and the same file may be opened by different processes or may be opened multiple times in the same process. The system of electronic device 100 may maintain a file descriptor table for each process, which may start with a value of 0. In general, when the electronic device 100 is turned on, fd has 3 initial values, and when the value of fd is 0, it represents a standard input, and when the value of fd is 1, it represents a standard output, and when the value of fd is 2, it represents a standard error. Illustratively, when the first file is opened or accessed after the electronic device 100 is booted, the value of fd for the file returned by the kernel may be 3.

After acquiring the fd of the file to be accessed, the electronic device 100 may determine a file handle opened by the fd of the file to be accessed, thereby determining an index node (i-node) corresponding to the file handle.

Where the file handle can be simply understood as an index, the operating system defaults to 1024 file handles.

Typically, the smallest unit of storage in a hard disk is a sector, which can store 512 bytes, i.e., 0.5KB, and the operating system of electronic device 100 reads a "block" consisting of multiple sectors when reading the hard disk, a common block can consist of 8 consecutive sectors, which can be 4KB in size.

As can be seen from the above, the file is stored in the block in the hard disk, and then meta information of the file (such as the creator of the file, the creation date of the file, and the size of the file) is also stored in the hardware. The i-node may be used to represent an area storing meta information of files, each file having an i-node corresponding thereto.

After the electronic device 100 determines the i-node of the file to be accessed, the operating system may read the file from the hard disk according to the i-node and return the file to the media library.

S504, the media library returns the file accessed by the user to the application program.

In particular, the media library may return the decompressed file to the application through the content provider.

After the electronic device 100 completes the decompression process, the electronic device 100 may display the accessed file described above.

For example, after the electronic device reads the compressed file from the hard disk and decompresses the compressed file, the file to be accessed (for example, displaying a picture or playing a video) may be displayed in the screen of the electronic device 100.

In this way, an application, such as a gallery, may present to the user a file, such as a photograph 301, that the user wants to access.

By the method for accessing the compressed file of the file, the application program still accesses the file according to the first path (for example, "storage/scheduled/0/Pictures/tangtai/happy. Jpg"), and does not need to update codes of the application program to process the compressed file actually transferred to the second path, namely, the application program does not sense the compression, decompression and transfer of the file, so that the development work of the application program is saved. Moreover, the user does not have to care about the internal processing of the file, nor does he have to change the way he accesses the file, while harvesting the good experience that storage space is conserved.

In one possible implementation, when the media library returns the file accessed by the user to the application program, the application program may send the id information acquired during storage to the media library, and after the media library queries the first path of the accessed file according to the id information, the step S503 is executed, where the media library returns the file accessed by the user to the application program.

In the flow shown in fig. 5, there may be a step of judging whether the file to be accessed is compressed according to the field converted_type, but this step is not necessary, and if the file to be stored from the application program is compressed and restored, this means that all the files stored on the electronic device need to be decompressed, that is, it is not necessary to judge whether the file to be accessed is decompressed.

The method flows in the embodiments of fig. 4 and fig. 5 are executed by each module in the software architecture of the electronic device, so the main execution body of the method flows may naturally be the electronic device, and specifically may be a processor or a processor system in the electronic device 100.

Not limited to photo storage, the electronic device 100 can also support storage of other types of files, such as files of documents, video, audio, and so forth. When the file to be stored is a document, the application program for transmitting the file to be stored to the media library may be a document editing application program; when the file to be stored is a video, the application transmitting the file to be stored to the media library may be a camera application, a social class application, or the like. The embodiments of the present application are not limited in this regard.

In some implementations, when the electronic device 100 detects that the camera APP takes a photograph or video, the electronic device 100 may compress the photograph or video for storage in the electronic device 100. The electronic device 100 may also access the photos or videos from a gallery or social APP, in particular by way of decompression. The electronic device 100 may also display the photograph or play the video.

In some implementations, when the electronic device 100 detects that the social class APP stores photos or videos, the electronic device 100 may compress the photos or videos for storage in the electronic device 100. The electronic device 100 may also access the photos or videos from a gallery or social APP, in particular by way of decompression. The electronic device 100 may also display the photograph or play the video.

In some implementations, when the electronic device 100 detects that the camera APP takes a photo or video, or the social APP saves the photo or video, the electronic device 100 may compress the photo or video for storage in the electronic device 100. The electronic device 100 may also access the photos or videos from the social class APP, in particular by way of decompression. The electronic device 100 may also send the photograph or video to other electronic devices.

In some implementations, when the electronic device 100 detects that the audio APP stores or records audio, the electronic device 100 may compress the audio for storage in the electronic device 100. The electronic device 100 may also access the audio from the audio APP, in particular by way of decompression. The electronic device 100 may also play the audio described above.

Not limited to the above method for storing files in the local electronic device 100, another file storing method is also provided in the embodiments of the present application. In this method, the electronic device 100 may transmit a first file in the application program to other devices connected to the electronic device 100 to request that the file be stored on the other devices, for example, a picture, a video, and the like stored in the application program. After that, the file stored in the electronic device 100 is deleted. When a user wants to access the file at the first path through the application, the electronic device may send a request to the other electronic device of the first path map to request the other electronic device to return the file.

The first path refers to a storage path in a local storage space on the electronic device 100, where the local storage space may be a storage space provided by the external memory 120.

In the case that the user has a plurality of other idle electronic devices, or the storage space of the other electronic devices that the user has is larger, the embodiment of the present application does not limit the above situation, but may also have other situations, where the electronic device 100 may select to store the file in the other electronic devices (i.e., the peer electronic device) instead of the local device. But the application layer in the electronic device 100 displays the first path, and the file path stored by the actual file may be a third path, where the third path may be a splicing path (including the peer electronic device id and the storage path in the peer electronic device). The detailed description of the third path may refer to the following description, and will not be repeated here. Not limited to the above, there may be more or fewer cases that cause the electronic device 100 to store a file in the counterpart electronic device. When the electronic device 100 stores a file in the opposite-end electronic device, if the electronic device 100 needs to access the file through the first path, the stored file may be accessed according to the splice path. For a detailed description of how to access a file according to a splice path, reference may be made to the following description, which is not repeated here.

A communication system provided in the embodiments of the present application is described in detail below.

Referring to fig. 7, fig. 7 schematically illustrates a communication system 10 provided in an embodiment of the present application. As shown in fig. 7, the communication system includes, but is not limited to, an electronic device 100 and an electronic device 101. The electronic device 100 may be referred to as a local device, and a user may store and access files from the electronic device 100. The electronic device 101 may refer to an electronic device at the opposite end, where the electronic device at the opposite end may actually store a file to be accessed.

It should be noted that, the electronic device 100 and the electronic device 101 may be a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) device, a Virtual Reality (VR) device, an artificial intelligence (artificial intelligence, AI) device, a wearable device, a vehicle-mounted device, a smart home device, and/or a smart city device, and the specific types of the electronic device 100 and the electronic device 101 are not particularly limited in the embodiments of the present application.

The electronic device 100 may establish a communication connection with the electronic device 101.

Specifically, the electronic device 100 and the electronic device 101 may respectively establish wireless connection based on a wireless communication technology, or may respectively establish wired connection based on a wired access technology. The wireless connection may be a wireless local area network (wireless local area network, WLAN) connection, a high-fidelity wireless communication (wireless fidelity, wi-Fi) connection, a bluetooth connection, an infrared connection, a near field communication (near field communication, NFC) connection, zigBee, other wireless communication technologies that occur in later developments, and the like.

In some implementations, the electronic device 100 and the electronic device 101 may automatically establish a communication connection, i.e., the distance between the two electronic devices 100 is capable of supporting establishment of the communication connection.

The electronic device 100 may also be configured to establish a communication connection with the electronic device 101 in response to a user operation, which is not limited in the embodiment of the present application.

Data transmission between the electronic device 100 and the electronic device 101 may be via a communication connection. For example, the electronic device 100 may transmit a file to be stored to the electronic device 101. The electronic device 101 may send the file to be accessed to the electronic device 100.

In some implementations, the electronic device 101 may also be replaced with a server. That is, the electronic device 100 may be communicatively connected to a server, and actually store files in the server.

In some implementations, electronic device 101 and electronic device 100 may have a soft bus functionality that is distinct from a traditional bus, which may enable device-to-device sensorless discovery and zero-latency transmission.

Specifically, the soft bus can shield protocol differences of various devices through the protocol shelf and the soft and hard cooperative layer, the bus central module is responsible for analyzing commands to complete discovery and connection between the devices, and functions such as file transmission and message transmission between the devices are realized through the task bus and the data bus.

The soft bus simplifies the protocol stacks of the presentation layer, the session layer, the transmission layer and the network layer in the traditional protocol into one layer, so that the effective load can be improved, and the effective transmission bandwidth can be improved by 20%.

In some implementations, the electronic device 101 may be a standby device of the electronic device 100 that is carried with a user. For example, the user a carries two mobile phones (mobile phone 1 and mobile phone 2), the electronic device 100 may be the mobile phone 1, and the electronic device 101 may be the mobile phone 2. The user a stores file 1 (e.g., document, photograph, video, etc.) using the handset 1. Specifically, the target path stored in the application program of the mobile phone 1 by the file 1 is the path 1, and the file 1 is actually stored in the mobile phone 2, and the path 1 and the path 2 are recorded in the media library in the mobile phone 1, wherein the path 2 includes the identifier of the mobile phone 2 and the storage path stored in the mobile phone 2 by the file 1. When a user accesses the file 1 through the mobile phone 1, the application program can access according to the path 1, the media library in the mobile phone 1 can obtain the path 2 according to the mapping of the path 1, and then the file 1 is accessed from the mobile phone 2 according to the path 2.

In some implementations, the electronic device 101 may also be a companion device to the electronic device 100. When the electronic device 100 is a mobile phone, the electronic device 101 may be a mobile phone, a tablet computer, a notebook computer, a vehicle, or the like. For example, where electronic device 100 is a cell phone and electronic device 101 may be a vehicle, a user may use the cell phone to store file 1 (e.g., documents, photos, videos, etc.). Specifically, the target path stored in the application program of the mobile phone by the file 1 is the path 1, the file 1 is actually stored in the vehicle, and the path 1 and the path 2 are recorded in the media library in the mobile phone, wherein the path 2 comprises the identification of the vehicle and the storage path stored in the vehicle by the file 1. When a user accesses the file 1 through the mobile phone, the application program can access according to the path 1, the media library in the mobile phone can obtain the path 2 according to the mapping of the path 1, and then the file 1 is accessed from the vehicle according to the path 2.

Another scenario of file storage according to embodiments of the present application is described below.

The electronic device 100 may store the file in the counterpart electronic device and be able to view the file format and file path of the file in the electronic device 100. In some embodiments, the file formats and file paths displayed in the electronic device 100 are not the file formats and file paths that were actually stored in the peer electronic device for the files described above.

For example, the electronic device 100 may download and store the picture on the third application to the local device, and may view information such as a file format and a file path of the picture from the gallery. The method according to the embodiment of the present application will be described in detail below by taking a stored picture as an example.

Referring to the user interfaces shown in fig. 2A to 2D, the electronic device 100 may store pictures in the opposite-end electronic device, and may view the stored pictures and the storage formats and storage paths of the pictures in the electronic device 100. The details of the user interface may be referred to the above detailed description of fig. 2A to 2D, and will not be described herein.

It should be noted that, as shown in fig. 2D, the file format "jpg" in the file information displayed in the detailed information box 304 may be a file format in which the picture is actually stored in the peer electronic device. That is, when a file is stored in the counterpart electronic device, the file format displayed in the electronic device 100 may be identical to the file format actually stored.

The file path displayed in the detailed information box 304 is a storage path "storage/updated/0/Pictures/dongtai/happy. Jpg" of the file perceived by the user and the application layer of the electronic device 100. I.e. the displayed file path may be the first path described above. While the file path actually stored in the counterpart electronic device is not shown in the detailed information box 304. Alternatively, the file path of the file actually stored in the opposite-end electronic device may be "storage/updated/Pictures/{ device_id }/remote_path", where "{ device_id }" indicates the id of the opposite-end electronic device and "remote_path" indicates the file path of the file stored in the opposite-end electronic device. In the embodiment of the application, the file path actually stored in the opposite-end electronic device is not limited, and is set by the operating system of the opposite-end electronic device.

Next, based on the photo storage scenario described above, the software architecture of the electronic device 100 is described in conjunction with fig. 8.

Taking a layered architecture as an example, the embodiment of the present invention illustrates a software structure of the electronic device 100 when stored in a peer electronic device.

As shown in fig. 8, the electronic device 100 may divide the system into three layers: an application layer, a media library, and a kernel layer.

Taking the example of saving the Pictures from the application program shown in fig. 2A to 2D, the application program layer (for example, gallery, weChat) stores the Pictures img-xx.jpg in the opposite-end electronic device, where the format of the Pictures is happy.jpg, the size of the Pictures is 3MB, and the first path of the picture storage is storage/scheduled/0/Pictures/dongtai/happy.jpg.

When the pictures are processed in the media library, the electronic device 100 may transmit the pictures to the opposite-end electronic device for storage through the communication module, and the opposite-end electronic device may store the pictures in the opposite-end electronic device through the storage module of the media library thereof.

The compression/decompression module does not compress the picture, the format of the picture is still happy, jpg, and the size of the picture is still 3MB; the path mapping module may map the storage path storage/updated/0/Pictures/dongtai/happy. Jpg of the picture into the path storage/updated/Pictures/{ device_id }/remote_path. At this time, the first storage path has deleted the picture, and the actual storage path of the picture is the third path. And the opposite-end electronic equipment invokes the storage drive again, and stores the picture on the physical address corresponding to the third path.

The storage conversion module may also be responsible for maintaining the data structures exemplarily shown in table 2.

Field name	Type(s)
		_id	INTEGER (INTEGER)
_data	TEXT (TEXT)
		remote_device_id	TEXT (TEXT)
remote_path	TEXT (TEXT)

TABLE 2

Table 2 illustrates the data table contents of the files stored at the peer electronic device generated by the media library of the electronic device 100, as shown in table 2, the distributed storage data table may include, but is not limited to, field_id, field_data, field remote_device_id, and field remote_path.

The field_id is of integer type, and can represent an index of a file to be accessed, and the index of the file serving as a unique identifier can accelerate query speed.

The type of field_data is a text type, and field_data may represent a file storage path stored by a user through an application. This storage path may be referred to as the first path of the file.

For example, if the application layer of the electronic device 100 knows that the photo 301 "happy/jpg" is stored in the storage/scheduled/0/Pictures/dongtai of the electronic device 100, the field_data in the data table of the photo 301 "happy/jpg" may be expressed as storage/scheduled/0/Pictures/dongtai/happy. In the embodiment of the present application, the specific content of the field_data is not limited.

The type of the field remote_device_id is a text type, and the field remote_device_id may represent an id of the counterpart electronic device stored by the file that the user wants to keep through the application.

In some examples, when the field remote_device_id takes a special value, such as "0," the field remote_device_id may indicate that the file that the user wants to keep is stored in the electronic device 100 and not in the counterpart electronic device.

In some implementations, when the field remote device id takes different values, the field remote device id may indicate that the file that the user wants to keep is stored in a different peer electronic device. For example, when the remote_device_id takes a value of "1", it indicates that the file that the user wants to keep is actually stored in the electronic device X1. For example, when the remote_device_id takes a value of "2", it indicates that the file that the user wants to keep is actually stored in the electronic device X2.

The type of the field remote_path is a text type, and the field remote_path may represent a storage path of a file to be accessed stored inside the peer electronic device. When the field remote_path takes a special value, such as "0", the field remote_path may indicate that the file that the user wants to keep is stored in the electronic device 100 and not in the counterpart electronic device.

Optionally, if the electronic device 100 needs to access the above files, the electronic device 100 cannot complete the accurate access to the file to be accessed according to the field remote_path, and further needs to perform a splicing process on the complete path of the file to be accessed to generate a splicing path (for example, splice the field remote_device_id with the field remote_path). This splice path may be referred to as a third path.

Illustratively, the id of the opposite-end electronic device is "{ device_id }", and the file data. Txt is stored in the directory untitled15 under the F disc of the opposite-end electronic device as the file path inside the opposite-end electronic device. The electronic device 100 may access the file data. Txt according to the splice path D:_ntitled10\ { device_id } \f:_ntitled15\data. Txt. In the embodiment of the present application, the specific content of the splicing path is not limited, and other forms of splicing paths may also exist.

The table may record a mapping relationship of the first path (_data) and the third path (concatenation of remote_device_id and remote_pat). The table may also record the identification (_id) of the file to be stored. When receiving a file access request that a user wants to access to the first path, the storage conversion module can find a third path mapped by the first path, and reads the file from a physical path corresponding to the third path in the opposite-end electronic device. And finally, the file is sent to the electronic device 100 to realize the access of the file.

The kernel layer may include drivers for the various hardware, such as storage drivers, as well as virtual file systems (virtual file system, VFS). The storage drive may be coupled to the external memory 120 and the communication module, and may be used to control the external memory 120 to perform operations such as reading and writing.

Based on the software architecture shown in fig. 8, fig. 9 illustrates a method flow of the electronic device 100 for implementing file storage in a peer electronic device.

As shown in fig. 9, a method flow of the electronic device 100 for storing a file in a peer electronic device is as follows:

and S901, the application program stores the first file into a first path by a user and transmits the file and the first path to a media library.

For example, the application may store the photo 301 selected by the user in the user interface 300 and send a first path (e.g., "stored/scheduled/0/Pictures/dongtai/happy. Jpg") of the photo 301 to the media library. In some embodiments, whether a third party application or a system-owned application, when a user is able to perceive the presence of a file from the electronic device 100, that is, the user is able to observe the file in a screen, the file is said to occupy a certain storage path in the electronic device. I.e. the file is of a first path.

S902, the electronic device 100 sends the file to the peer electronic device.

When the electronic device 100 selects to store the file in the counterpart electronic device, the electronic device may transmit the file to the counterpart electronic device through the communication module.

Specifically, after the electronic device 100 completes the communication connection with the counterpart electronic device (i.e., forms the communication system 10 described above), the electronic device 100 may send the file to the counterpart electronic device. After the receiving of the opposite-end electronic equipment is finished, the kernel layer of the opposite-end electronic equipment interacts with the hardware through a driver to store the file in the hardware of the opposite-end electronic equipment, and the hardware of the opposite-end electronic equipment sends the physical address of the file to the kernel layer of the opposite-end electronic equipment. And after the kernel layer of the opposite-end electronic equipment obtains the physical address of the file, generating a file path corresponding to the physical address. The peer electronic device may then send the id of the peer electronic device and the file path along which the file is stored within the peer electronic device to the electronic device 100. Therefore, when the media library of the electronic device 100 generates the data table of the file, the storage path of the file in the opposite electronic device is recorded.

For example, after the file is transferred to the peer electronic device, the media library may learn the id of the peer electronic device and the storage path stored in the peer electronic device, such as the field remote_device_id and the field remote_path.

S903, the electronic device 100 deletes the file in the electronic device 100.

After the electronic device 100 completes storing the file in the counterpart electronic device, the file at the electronic device 100 may be deleted. That is, the first path does not store the file. But since the first path may map out the third path, the electronic device 100 may access the file according to the first path.

The above-described manner of storing the file in the electronic device at the opposite end may be implemented, and the effect is equivalent to increasing the storage space for storing the file when the user uses the electronic device 100. And the files are stored in the known opposite-end electronic equipment, so that the security is better compared with cloud storage.

If the electronic device 100 needs to access a file, the electronic device 100 needs to access the file when a communication connection is established between the electronic device 100 and the counterpart electronic device.

Since the electronic device 100 stores the file to be accessed in the opposite-end electronic device, the file to be accessed is not stored locally, and if the electronic device 100 does not maintain communication connection with the opposite-end electronic device, the electronic device 100 cannot access the file stored in the opposite-end electronic device.

Based on the software architecture shown in fig. 8, fig. 10 illustrates a method flow for implementing file access by the electronic device 100.

As shown in fig. 10, the flow of the method for implementing file access by the electronic device 100 is specifically as follows:

in S1001, the content provider (ContentProvider) in the application framework layer receives a file access request from an application program such as a gallery, and the electronic device 100 may receive a user operation and, in response to the user operation, cause the application layer of the electronic device 100 to send the file access request to the media gallery. The user operation may include, but is not limited to: user operations (e.g., clicking operations, touching operations, etc.), voice instructions, gesture instructions, or pressing operations received by a mouse to which the electronic device 100 is connected when a cursor of the electronic device 100 is located on a file preview icon, received on a file preview control (e.g., a picture preview control). In the embodiment of the present application, the above user operation is not limited, and other forms of user operation may also exist.

By way of example, the electronic device 100 may send an access request in two ways:

one is for the electronic device 100 to send a file access request to the media library via the contentProvider.

Alternatively, the electronic device 100 may send a file access request to the media library via the FUSE. For the two ways of sending the access request, reference may be made to the detailed description in step S501, which is not described herein.

In this embodiment of the present application, the manner in which the application layer of the electronic device 100 sends the file access request to the media library is not limited, and may further include other file access request manners besides the two access manners.

S1002, the electronic device 100 determines the id of the peer electronic device stored in the file, and sends a request to the peer electronic device.

After the media library of the electronic device 100 receives the file access request, the electronic device 100 may determine the id to the peer electronic device to which the file is stored.

Illustratively, the media library of the electronic device 100 may obtain a data table (e.g., the data table shown in table 2) of the file to be accessed after receiving the file access request. The specific information contained in the data table of the file to be accessed may refer to the distributed storage data table shown in table 2. After the electronic device 100 acquires the data table information, the judgment analysis may be performed on the field information in the data table 2.

In some implementations, the value of the field remote_device_id in the data table of the file to be accessed may represent the peer electronic device id. Specifically, a value of zero for the field remote_device_id may indicate that the file to be accessed is not actually stored in the peer electronic device, but is stored in the electronic device 100. A value of the field remote device id that is not null may indicate that the file to be accessed is actually stored in the peer electronic device.

When the electronic device 100 determines that the value of the field remote_device_id in the data table of the file to be accessed is empty, the file to be accessed is actually stored in the electronic device 100 instead of the counterpart electronic device, and the electronic device 100 may learn that the file path represented by the field_data is the file path in which the file to be accessed is actually stored in the electronic device 100. The electronic device may access the file directly according to the first path.

When the electronic device 100 determines that the value of the field remote_device_id in the data table of the file to be accessed is not null, the file to be accessed is actually stored in the opposite-end electronic device, and the file path displayed on the electronic device 100 by the file to be accessed is not the file actual storage path. The electronic device 100 may learn that the file path indicated by the field remote_path is a file path in which the file to be accessed is actually stored in the peer electronic device.

After the electronic device 100 obtains the id of the peer electronic device, a request may be sent to the peer electronic device requesting that the peer electronic device send the file accessed by the electronic device 100 to the electronic device 100.

For example, after the electronic device 100 obtains the id of the electronic device at the opposite end, a request may be sent to the electronic device at the opposite end according to the data table of the file to be accessed queried by the media library.

In some implementations, the electronic device 100 may generate the splice path for accessing the file according to the id of the peer electronic device indicated by the field remote_device_id in the data table of the file to be accessed and the file path in which the file to be accessed indicated by the field remote_path is actually stored in the peer electronic device. The splice path may also be referred to as a third path. The electronic device 100 may send a request to the peer electronic device according to the third path.

Illustratively, the splice path may be expressed as storage/assembled/Pictures/{ device_id }/remote_path. The { device_id } is the id of the opposite-end electronic device indicated by the field remote_device_id, and the remote_path is the file path indicated by the field remote_path.

S1003, the peer electronic device sends the file to the electronic device 100.

After the electronic device 100 sends a request to the counterpart electronic device, the counterpart electronic device may send the file to the electronic device 100.

The peer electronic device reads the file from the hardware of the peer electronic device according to the physical address corresponding to the field remote_path in the splice path in the sent request, and sends the file to the electronic device 100.

S1004, the electronic device 100 receives the file and displays the accessed file in the electronic device 100.

After the electronic device 100 receives the file transmitted by the counterpart electronic device, the electronic device 100 may display the accessed file.

For example, after the counterpart electronic device transmits the file read-processed from the hardware to the electronic device 100, the file to be accessed (for example, displaying a picture or playing a video) may be displayed in the screen of the electronic device 100.

By the method for accessing the file stored in the opposite-end electronic device, the application program still accesses the file according to the first path (for example, "storage/scheduled/0/Pictures/dongtai/happy. Jpg"), and application program update codes are not needed to process the file actually restored to the third path, namely, the application program does not sense the restoration of the file, so that development work of the application program is saved. Moreover, the user does not have to care about the internal processing of the file, nor does he have to change the way he accesses the file, while harvesting the good experience that storage space is conserved.

In some implementations, the electronic device 100 may be referred to as a first electronic device and the counterpart electronic device may be referred to as a second electronic device.

It will be appreciated that the various user interfaces described in the embodiments of the present application are merely example interfaces and are not limiting to other embodiments of the present application. In other embodiments, different interface layouts may be adopted in the user interface, more or fewer controls may be included, other functional options may be added or reduced, and the following example interfaces may also be migrated to be used on other types of devices, so long as the technical solutions based on the same inventive concept provided in the present application are all within the scope of protection of the present application.

The embodiments of the present application may be arbitrarily combined to achieve different technical effects.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

In summary, the foregoing description is only exemplary embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made according to the disclosure of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of file storage, the method being applied to a first electronic device, comprising:

the first electronic equipment is provided with a media library, the media library has the function of providing file storage for an application program installed on the first electronic equipment, and the application program comprises a first application program;

in response to a first operation initiated by the first application program, the media library performs storage on the first file, and the first operation indicates that the first file is stored to a first path;

The media library stores the first file to a second path;

the first path and the second path have a mapping relation, the first path is a target path for the first application program to operate the first file, and the second path is an actual storage path of the first file.

2. The method according to claim 1, wherein the method further comprises:

and responding to a second operation of accessing the first file by the first application program, determining the first file under the second path by the media library according to the mapping relation between the first path and the second path, and providing a function of accessing the first file for the first application program, wherein the second operation indicates that the first file is in the first path.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

the application program further comprises a second application program, and the second application program is not the same application program with the first application program;

and responding to a third operation of the second application program for accessing the first file, wherein the media library determines the first file under the second path according to the mapping relation between the first path and the second path, provides a function of accessing the first file for the second application program, and indicates that the first file is in the first path.

4. A method according to claim 2 or 3, characterized in that the method further comprises:

the media library provides the application with the first path to access the first file.

5. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the storing, by the media library, the first file to the second path specifically includes:

and the media library compresses the first file and stores the compressed file after the first file is compressed to the second path.

6. The method according to any one of claims 2 to 4, wherein,

the reading the first file from the second path by the media library of the first electronic device specifically includes:

and the media library of the first electronic equipment reads out the compressed file of the first file from the second path, and decompresses the compressed file to obtain the first file.

7. The method according to any one of claims 1 to 6, wherein,

and the storage space corresponding to the second path belongs to the first electronic equipment.

8. The method according to any of claims 2-7, wherein the providing the first application with the functionality of accessing the first file by the media library comprises in particular:

The media library of the first electronic device obtains a file descriptor corresponding to the second path, wherein the file descriptor is used for sending the first file to the application program of the first electronic device by the media library of the first electronic device.

9. The method of claim 1, wherein the step of determining the position of the substrate comprises,

when the storage space indicated by the second path belongs to a second electronic device, responding to a first operation initiated by the first application program, and executing storage on the first file by the media library, wherein the first operation for indicating the first file to be stored to the first path specifically comprises:

the first electronic equipment and the second electronic equipment are in communication connection;

the first electronic device sends the first file to the second electronic device so as to store the first file in the second electronic device;

the second path includes: and the identification of the second electronic device and the storage path of the first file stored in the second electronic device.

10. The method as recited in claim 9, wherein the method further comprises:

responding to a second operation of the first application program for accessing the first file, and determining a second path by the media library according to the mapping relation between the first path and the second path;

The media library sends a request to the second electronic equipment according to the second path and receives the first file sent by the second electronic equipment;

the media library provides the first application with a function of accessing the first file, and the second operation indicates that the first file is in a first path.

11. The method according to claim 9 or 10, wherein the manner in which the communication connection is established between the first electronic device and the second electronic device comprises any one of: bluetooth connection, wireless local area network connection, high fidelity wireless communication, infrared connection, and near field connection.

12. The method of any of claims 9-11, wherein the first electronic device logs in to the same system account as the second electronic device.

13. The method according to any of claims 9-11, wherein the second electronic device is a spare device of the first electronic device that is carried around.

14. The method of any of claims 9-11, wherein the second electronic device is a companion device to the first electronic device.

15. The method of any of claims 1-14, wherein the first file comprises a photograph or video, the method further comprising: detecting that a user shoots the photo or the video through a camera application program or stores the photo or the video through a social application program, wherein a storage path of the photo or the video displayed in the application program is the first path;

the first electronic device detects that a user opens the photo or video through a social application program or gallery;

after the media library determines the first file under the second path according to the mapping relation between the first path and the second path, the method further comprises:

and the first electronic equipment displays the photo under the second path or plays the video under the second path.

16. The method of any of claims 1-14, wherein the first file comprises a photograph or video, the method further comprising: detecting that a user shoots the photo or the video through a camera application program or stores the photo or the video through a social application program, wherein a storage path of the photo or the video displayed in the application program is the first path;

the electronic device sends the photo or video under the second path.

17. The method of any of claims 1-14, wherein the first file comprises audio, the method further comprising: detecting an operation of storing or recording the audio by a user through an audio application program, wherein a storage path displayed by the audio in the application program is the first path;

The first electronic device plays the audio under the second path.

18. An electronic device comprising a memory for storing a computer program, one or more processors for invoking the computer program to cause the electronic device to perform the method of any of claims 1 to 17.

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