Data acquisition method, electronic equipment and computer storage medium

Abstract

The invention discloses a data acquisition method, electronic equipment and a computer storage medium, and belongs to the technical field of mounting. The method comprises the following steps: after a first device receives a target service starting message sent by a second device, starting a target service in the first device to generate target data. The second device is mounted on the first device, the first file descriptor is obtained from the second device, and the first file descriptor is the file descriptor of the target file. And generating a corresponding second file descriptor according to the first file descriptor. And writing the target data into the target file according to the second file descriptor. Thus, the effect that the second device starts the target service in the first device to generate the target data and write the target data into the target file in the second device is achieved, and under the condition, a user can obtain the target data generated by the target service in the first device from the second device only through operation on the second device side. Therefore, convenient cross-device data transmission is realized.

Description

Technical Field

[0001] The present application relates to the field of mounting technology, and in particular to a device mounting method, an electronic device and a computer storage medium. Background Art

[0002] At present, more and more users own and use multiple devices. The isolation of data and capabilities among multiple devices requires users to operate multiple devices at the same time, which is very inconvenient and has a relatively high time cost.

[0003] For example, when a user is taking notes using a note taking app on a tablet, and wants to insert an image taken with a mobile phone, the user needs to first take an image with the mobile phone, then share the image to the tablet, and finally insert the image shared from the mobile phone into the note taking app on the tablet. In this process, the user needs to operate both the mobile phone and the tablet, which is a complicated process and time-consuming. Summary of the invention

[0004] The present application provides a data acquisition method, an electronic device and a computer storage medium, which can realize convenient cross-device data transmission. The technical solution is as follows:

[0005] In a first aspect, a data acquisition method is provided, which is applied to a first device. In the method, a target service startup message sent by a second device is received; a target service in the first device is started to generate target data; the second device is mounted; a first file descriptor is obtained from the second device, the first file descriptor is a file descriptor of a target file, and the target file is a file in the second device for storing target data; a corresponding second file descriptor is generated according to the first file descriptor; and the target data is written to the target file according to the second file descriptor.

[0006] In the present application, the second device can start the target service in the first device to generate target data and write it into the target file in the second device. In this case, the user can obtain the target data generated by the target service in the first device from the second device only by operating on the second device side, thereby realizing convenient cross-device data transmission and facilitating user use.

[0007] Optionally, before mounting the second device, the method further includes: after generating the target data, sending a file information acquisition message to the second device; and receiving a target file name sent by the second device, where the target file name is the name of the target file.

[0008] Acquiring a first file descriptor from a second device includes: sending a file open message carrying a target file name to the second device; and receiving a first file descriptor corresponding to the target file name sent by the second device.

[0009] Optionally, sending a file open message carrying the target file name to the second device includes: sending a metadata acquisition message carrying the target file name to the second device; receiving metadata of the target file sent by the second device; and sending the file open message carrying the target file name to the second device based on the metadata.

[0010] Optionally, writing target data to a target file according to a second file descriptor includes: obtaining a first write message generated by a target service and carrying the second file descriptor and the target data; obtaining a first file descriptor corresponding to the second file descriptor in the first write message; generating a second write message carrying the target data in the first write message and the first file descriptor; and sending a second write message to a second device, the second write message being used to indicate that the target file is written to the target file corresponding to the first file descriptor.

[0011] In a second aspect, a data acquisition method is provided, which is applied to a second device, and the method includes: in response to a first operation, sending a target service startup message to the first device, the first operation is used to indicate the acquisition of target data, the target service startup message is used to start the target service, and the target service is used to generate target data; mounting to the first device; sending a first file descriptor to the first device, the first file descriptor is the file descriptor of the target file, and the target file is a file in the second device for storing target data; receiving the target data sent by the first device, and writing the target data to the target file corresponding to the first file descriptor, and the target data is sent by the second device according to the second file descriptor corresponding to the first file descriptor.

[0012] Optionally, before mounting to the first device, the method further includes: receiving a file information acquisition message sent by the first device; opening a target file, acquiring a target file name and a first file descriptor, establishing a corresponding relationship between the target file name and the first file descriptor, wherein the target file name is the name of the target file; and sending the target file name to the first device;

[0013] Sending a first file descriptor to a first device includes: receiving a file open message carrying a target file name sent by a second device; obtaining a first file descriptor corresponding to the target file name in the file open message; and sending the first file descriptor to the first device.

[0014] Optionally, before receiving the file open message carrying the target file name sent by the second device, the method further includes: receiving a metadata acquisition message carrying the target file name sent by the second device; and sending the metadata of the target file to the second device.

[0015] Optionally, receiving the target data sent by the first device includes: receiving a second write message sent by the first device, the second write message carrying the target data and the first file descriptor, the second write message being generated based on the first write message, and the first write message carrying the second file descriptor and the target data.

[0016] Optionally, establishing a correspondence between the target file name and the first file descriptor includes: verifying the legitimacy of the target file name and the first file descriptor; if the legitimacy check of the target file name and the first file descriptor passes, determining whether a correspondence has been established with other file descriptors for the target file name; if a correspondence has not been established with other file descriptors for the target file name, establishing a correspondence between the target file name and the first file descriptor.

[0017] In a third aspect, an electronic device is provided, wherein the structure of the electronic device includes a processor and a memory, wherein the memory is used to store a program that supports the computer device to execute the data acquisition method provided in the first aspect, and to store data involved in implementing the data acquisition method described in the first aspect. The processor is configured to execute the program stored in the memory. The computer device may also include a communication bus, wherein the communication bus is used to establish a connection between the processor and the memory.

[0018] In a fourth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, the computer executes the data acquisition method described in the first aspect.

[0019] In a fifth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the data acquisition method described in the first aspect.

[0020] The technical effects obtained by the above-mentioned second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the above-mentioned first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application;

[0022] Figure 2 is a block diagram of a software system of an electronic device provided in an embodiment of the present application;

[0023] Figure 3 It is a schematic diagram of a usage scenario provided by an embodiment of the present application;

[0024] Figure 4is a schematic diagram of a distributed system provided in an embodiment of the present application;

[0025] Figure 5 is a flow chart of a data acquisition method provided in an embodiment of the present application;

[0026] Figure 6 It is a schematic diagram of a mounted directory tree provided in an embodiment of the present application;

[0027] Figure 7 is a flow chart of a device mounting process provided by an embodiment of the present application;

[0028] Figure 8 is a block diagram of a software system of a first device and a second device provided in an embodiment of the present application;

[0029] Fig. 9 is a flow chart of a data acquisition method provided in an embodiment of the present application;

[0030] Fig.10 This is a schematic diagram of creating a distributed file service provided by an embodiment of the present application;

[0031] Fig.11 It is a schematic diagram of the correspondence between a file name and fd provided in an embodiment of the present application;

[0032] Fig.12 It is a schematic diagram of a target module obtaining fd provided in an embodiment of the present application;

[0033] Fig.13 It is a schematic diagram of a mounting step provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0035] It should be understood that the "multiple" mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of this application, the words "first" and "second" are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not limit them to be different.

[0036] The phrases such as "one embodiment" or "some embodiments" described in the present application mean that the specific features, structures or characteristics described in the embodiment are included in one or more embodiments of the present application. Therefore, the phrases such as "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments" that appear in the differences in the present application do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. In addition, the terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0037] The electronic device involved in the embodiments of the present application is described below.

[0038] Figure 1 1 is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application. Figure 1 The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging 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, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. Among them, the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0039] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0040] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0041] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0042] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0043] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0044] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created by the electronic device 100 during use (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0045] The USB interface 130 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transfer data between the electronic device 100 and a peripheral device. It can also be used to connect headphones to play audio through the headphones. The USB interface 130 can also be used to connect other devices, such as AR devices, etc.

[0046] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device 100 through the power management module 141.

[0047] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and provides power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193 and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

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

[0049] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0050] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0051] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

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

[0053] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode or an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is an integer greater than 1.

[0054] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0055] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0056] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is an integer greater than 1.

[0057] The electronic device 100 can implement audio functions, such as music playback, recording, etc., through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D and the application processor.

[0058] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0059] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key inputs and generate key signal inputs related to user settings and function control of the electronic device 100.

[0060] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. Touch operations acting on different areas of the display screen 194 can also correspond to different vibration feedback effects. Different application scenarios (such as: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0061] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0062] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is an integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0063] Next, the software system of the electronic device 100 will be described.

[0064] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software system of the electronic device 100.

[0065] Figure 2 1 is a block diagram of a software system of an electronic device 100 provided in an embodiment of the present application. Figure 2 The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into an application layer, an application framework layer, an Android runtime (AndroidRuntime) and a system layer, and a kernel layer.

[0066] The application layer can include a series of application packages. Figure 2 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0067] The application framework layer provides application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions. Figure 2As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc. The window manager is used to manage window programs. The window manager can obtain the size of the display screen, determine whether there is a status bar, lock the screen, capture the screen, etc. The content provider is used to store and obtain data and make these data accessible to applications. These data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc. The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build the display interface of the application, and the display interface can be composed of one or more views, for example, including a view for displaying a text message notification icon, including a view for displaying text, and including a view for displaying pictures. The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.). The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, etc. The notification manager enables the application to display notification information in the status bar, which can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of an icon or scroll bar text, such as a notification of an application running in the background. The notification manager can also be a notification that appears on the screen in the form of a dialog window, such as a text message in the status bar, a reminder sound, an electronic device vibrating, an indicator light flashing, etc.

[0068] Android Runtime includes core libraries and virtual machines. Android Runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one is the function that the Java language needs to call, and the other is the Android core library. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0069] The system layer can include multiple functional modules, such as: surface manager, media library, 3D graphics processing library (such as: OpenGL ES), 2D graphics engine (such as: SGL), etc. The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc. The 2D graphics engine is a drawing engine for 2D drawing.

[0070] The kernel layer is the layer between hardware and software. The kernel layer can include display drivers, camera drivers, audio drivers, sensor drivers, etc.

[0071] The application scenarios involved in the embodiments of the present application are described below.

[0072] Currently, more and more users own and use multiple devices. The isolation of data and capabilities among multiple devices requires users to operate multiple devices at the same time when using them. This is very inconvenient and the time cost is relatively high. Therefore, the coordination of data and capability resources among multiple devices becomes increasingly important.

[0073] For example, Figure 3 As shown in Figure (a), when a user uses a note application on a tablet computer to take notes, he wants to insert an image taken by a mobile phone. In this case, the user needs to first take an image with the mobile phone, then share the taken image to the tablet computer, and finally insert the image shared from the mobile phone into the note application on the tablet computer. In this process, the user needs to operate both the mobile phone and the tablet computer, which is a complicated process and time-consuming.

[0074] To this end, the embodiment of the present application provides a data acquisition method that can access data of other devices through file descriptors and provide cross-device data access and transmission capabilities. Figure 3As shown in Figure (b), the solution provided by the embodiment of the present application can enable the user to insert the image taken by the mobile phone into the note application in the tablet computer only by operating on the tablet computer side. Specifically, the tablet computer can directly call the camera of the mobile phone to take the image and transfer the image data to the note application in the tablet computer through the access file descriptor mechanism for insertion, which can simplify the user operation process and improve the user experience. In addition, the solution provided by the embodiment of the present application is a universal file descriptor access mechanism, which is compatible with the kernel file read and write interface. For example, data reading and writing can directly use the standard POSIX interface, so that the adaptation cost is low when the application is used.

[0075] The data acquisition method provided in the embodiment of the present application can be applied to a distributed system. The distributed system includes multiple devices, and any two of the multiple devices have the ability to mount access, so that any two of the multiple devices can realize cross-device browsing, searching and file transfer.

[0076] Next, the distributed system provided in the embodiment of the present application is described.

[0077] Figure 4 Schematic diagram of a distributed system provided by an embodiment of the present application. Figure 4 , the distributed system includes multiple devices 400.

[0078] Any one of the plurality of devices 400 may be the above Figure 1 to Figure 2 The electronic device 100 described in the embodiment, for example, any one of the multiple devices 400 can be a mobile phone, a tablet computer, etc., which is not limited in the embodiment of the present application.

[0079] Any device 400 (which may be referred to as a second device) among the multiple devices 400 may be mounted to another device 400 (which may be referred to as a first device). In this case, the first device may be used as a client, and the second device may be used as a server. The server is mounted to the client, and the client may access files in the server.

[0080] There may be multiple clients or multiple servers among the multiple devices 400. Moreover, any one of the multiple devices 400 may be a client or a server. In other words, any one of the multiple devices 400 may be mounted with other devices 400 or may be mounted to other devices 400.

[0081] Optionally, any one of the multiple devices 400 may have multiple applications (also referred to as business applications). Multiple applications in this device 400 may apply to mount other devices 400 on this device 400, and the other devices 400 that the multiple applications apply to mount may be the same device or different devices. The multiple applications may access files in the mounted devices 400. For example, the multiple applications may include a file manager, a workstation, a gallery, a camera, etc., and this embodiment of the application does not limit this to anything else.

[0082] The data acquisition method provided in the embodiment of the present application is described below.

[0083] In order to make the collaboration of data resources between multiple devices more efficient and convenient, an embodiment of the present application provides a data acquisition method. In this method, the correspondence between the first file descriptor and the file name is saved on a device at one end, the opposite device is mounted on the device at the other end, and then the first file descriptor in the opposite device can be obtained by opening the corresponding file name on the device, and the second file descriptor can be obtained according to the first file descriptor. The device can write data to the file corresponding to the first file descriptor in the opposite device by writing data to the file corresponding to the second file descriptor.

[0084] Figure 5 is a flow chart of a data acquisition method provided in an embodiment of the present application. Figure 5 , the method comprises the following steps:

[0085] Step 501: In response to a first operation, the second device sends a target service start message to the first device.

[0086] The first operation is used to instruct the acquisition of target data. The target service start message is used to instruct the start of a target service, where the target service is a service that generates target data.

[0087] For example, the first operation may be triggered by a user, for example, the first operation may be an operation in which the user selects a camera of the first device from a camera list displayed on the second device. The target service may be a camera shooting service. The target data may be an image shot by the camera.

[0088] For example, after the second device is connected to the first device, the user can open the note application in the second device, and then open the camera selection interface in the note application. The camera selection interface displays a camera list, and the camera list displays the logo of the second device's own camera, and can also display the logo of the camera of the first device connected to the second device. If the user selects the logo of the camera of the first device in the camera list, the first operation will be triggered. In response to the first operation, the second device can send a target service startup message to the first device. In this case, the target service startup message is used to indicate the startup of the camera shooting service, that is, to indicate the startup of the camera to shoot an image.

[0089] In some embodiments, the first operation may be triggered in a target interface (such as the camera selection interface described above). In this case, after the second device displays the target interface, the distributed file service may be started and the server capabilities of the distributed file service may be initialized. The distributed file service is a service for mounting the second device to the first device. After the second device is mounted to the first device, the second device is the server and the first device is the client.

[0090] In this case, when the second device starts the distributed file service, it can determine whether the distributed file service already exists. If it exists, it is directly started. If it does not exist, it creates the distributed file service and then starts it.

[0091] Step 502: The first device receives a target service start message, starts the target service to generate target data, and sends a file information acquisition message to the second device.

[0092] The file information acquisition message is used to request to acquire information of a file for storing target data.

[0093] Step 503: After receiving the file information acquisition message, the second device opens the target file, obtains the target file name and the first file descriptor, establishes a corresponding relationship between the target file name and the first file descriptor, and sends the target file name to the first device.

[0094] The target file name is the name of the target file, and the first file descriptor is the file descriptor of the target file, that is, the file corresponding to the first file descriptor is the target file.

[0095] Optionally, the operation of the second device establishing the correspondence between the target file name and the first file descriptor may be: verifying the legitimacy of the target file name and the first file descriptor; if the legitimacy check of the target file name and the first file descriptor passes, determining whether a correspondence has been established between the target file name and other file descriptors; if a correspondence has not been established between the target file name and other file descriptors, establishing a correspondence between the target file name and the first file descriptor.

[0096] In some embodiments, when the validity check of the target file name and the first file descriptor passes, it can be determined first whether the distributed file service has been started. If it has been started, it is determined whether a corresponding relationship has been established between the target file name and other file descriptors. If a corresponding relationship has not been established between the target file name and other file descriptors, a corresponding relationship between the target file name and the first file descriptor is established.

[0097] Step 504: After receiving the target file name, the first device mounts the second device and sends a file open message carrying the target file name to the second device.

[0098] After the first device mounts the second device, the files in the second device can be accessed.

[0099] Optionally, after the first device mounts the second device, it may send a metadata acquisition message carrying a target file name to the second device, where the metadata acquisition message is used to request metadata of the target file corresponding to the target file name, where the metadata may include file size, etc. After receiving the metadata acquisition message, the second device may send the metadata of the target file to the first device.

[0100] The file open message is used to indicate opening the target file corresponding to the target file name.

[0101] Optionally, the first device may also send a file open message carrying the target file name to the second device according to the metadata. Since the metadata is metadata of the target file, sending the file open message to the second device according to the metadata may facilitate the normal opening of the target file by the second device.

[0102] Step 505: After receiving the file open message, the second device obtains a first file descriptor corresponding to the target file name in the file open message, and sends the first file descriptor to the first device.

[0103] Step 506: After receiving the first file descriptor, the first device generates a second file descriptor according to the first file descriptor, and writes target data into the target file according to the second file descriptor.

[0104] The first file descriptor corresponds to the second file descriptor. Optionally, the first file descriptor is a file descriptor that complies with the read and write rules of the first device. The second file descriptor is a file descriptor that complies with the read and write rules of the second device. The second file descriptor can be obtained by processing the first file descriptor.

[0105] After obtaining the second file descriptor, the first device is to write the target data to the file corresponding to the second file descriptor. In this case, the target service will generate a first write message carrying the second file descriptor. In this case, since the first device is mounted with the second device and the second file descriptor is generated based on the first file descriptor, when the first device obtains the first write message, it will obtain the first file descriptor corresponding to the second file descriptor in the first write message, and then generate a second write message carrying the target data in the first write message and the first file descriptor, and send the second write message to the second device. After receiving the second write message, the second device can write the target data in the second write message to the target file corresponding to the first file descriptor in the second write message.

[0106] In this case, for the first device, after the target service in the first device is started and generates target data, the name of the target file for storing the target data (i.e., the target file name) is first obtained, and then the target file is opened according to the target file name to obtain the second file descriptor, and then the target data is written to the file corresponding to the second file descriptor. Therefore, for the target service in the first device, its processing logic is relatively general and has universal applicability.

[0107] For the second device, it first starts the target service, then opens the target file for storing the target data, obtains the first file descriptor of the target file, and then obtains the target data generated by the target service, and writes the target data into the target file corresponding to the first file descriptor. For the second device, its processing logic is also relatively general and has universal applicability.

[0108] As can be seen from the above, the solution provided by the embodiment of the present application is a universal file descriptor access mechanism that is compatible with the kernel file read and write interface, thereby making the adaptation cost relatively low when the device is used.

[0109] In an embodiment of the present application, after the first device receives the target service startup message sent by the second device, it starts the target service in the first device to generate target data. After that, the first device mounts the second device and obtains the first file descriptor from the second device. The first file descriptor is the file descriptor of the target file, and the target file is a file in the second device used to store target data. A corresponding second file descriptor is generated according to the first file descriptor. The target data is written to the target file according to the second file descriptor. In this way, the effect of the second device starting the target service in the first device to generate target data and write it to the target file in the second device is achieved. In this case, the user can obtain the target data generated by the target service in the first device from the second device only by operating on the second device side, thereby realizing convenient cross-device data transmission and facilitating user use.

[0110] The following describes the process of mounting the second device on the first device.

[0111] First, the mount directory tree involved in the embodiment of the present application is described.

[0112] The mount directory tree can also be called the mount manager tree (MMT).

[0113] Figure 6 Schematic diagram of a mounted directory tree provided in an embodiment of the present application. Figure 6 As shown, the mount directory tree is a tree structure. The data of each node in the mount directory tree is a directory. The data of the root node of the mount directory tree can be called a root directory, and the data of other nodes in the mount directory tree except the root node can be called a subdirectory.

[0114] for example, Figure 6 The data of the root node of the mounted directory tree shown is the root directory " / mnt / appfuse / dfs", the data of each node in the next layer of nodes of the root node are sub-directories " / " and " / default", the data of each node in the next layer of nodes are " / device1" and " / device2", the data of each node in the next layer of nodes are " / sdcard", and the data of each node in the next layer of nodes is " / memory".

[0115] Each node in the mount directory tree indicates a mount directory, that is, indicates a mount point. For example, the mount directory indicated by each node in the mount directory tree can be a disk directory.

[0116] The mount directory indicated by the root node of the mount directory tree is the root directory of the mount directory tree, that is, the directory of the local file system, that is, the mount point of the local file system. Other nodes in the mount directory tree except the root node indicate the mount directories of other devices, that is, the mount points of other devices. The mount directory indicated by any other node in the mount directory tree except the root node is a directory composed of the data of all nodes in the path from the root node to this node.

[0117] for example, Figure 6The mount directory indicated by the root node of the mount directory tree shown is " / mnt / appfuse / dfs", and the mount directories indicated by each node in the next layer of nodes of the mount directory tree are " / mnt / appfuse / dfs / " and " / mnt / appfuse / dfs / default", and the mount directories indicated by each node in the next layer of nodes are " / mnt / appfuse / dfs / default / device1" and " / mnt / appfuse / dfs / default / device2", and the mount directories indicated by each node in the next layer of nodes are " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard", and the mount directory indicated by each node in the next layer of nodes is " / mnt / appfuse / dfs / default / device2 / sdcard / memory".

[0118] Among them, the mount directory tree contains the mount directory of the target device directory which mounts other devices, and the target device directory is the directory in the other device. For example, Figure 6 In the mount directory tree shown, the end of the mount directories " / mnt / appfuse / dfs / default / device1 / sdcard" and " / mnt / appfuse / dfs / default / device2 / sdcard" is the target device directory " / sdcard", and the end of the mount directory " / mnt / appfuse / dfs / default / device2 / sdcard / memory" is the target device directory " / sdcard / memory". The root directory in the target device directory " / sdcard" is " / sdcard", and the root directory in the target device directory " / sdcard / memory" is " / sdcard".

[0119] In some embodiments, if the data of a node in the mount directory tree is the root directory in the target device directory, then mount information (also referred to as MountInfo) may be set for this node. Figure 6 As shown, you can set the mount information for the node where the root directory " / sdcard" in the target device directory is located.

[0120] The mount information of a node may include a reference count, a device identifier (also called a device ID (Identity document)), an application identifier, and may further include read and write permissions, etc.

[0121] The reference count is the number of times the mount directory indicated by this node is mounted by the application. The device identifier is the identifier of the other device corresponding to the mount directory indicated by this node. The application identifier is the identifier of the application that mounts the mount directory indicated by this node, such as the package name of the application. The read and write permissions refer to the read and write permissions of the files in the mount directory indicated by this node, which can include read-only, write-only, and read-write.

[0122] Figure 7 is a flow chart of a device mounting process provided by an embodiment of the present application. Figure 7 , the method comprises the following steps:

[0123] Step 701: The first device mounts the local file system.

[0124] The local file system is a file system used in the first device to mount other devices. After the first device mounts the local file system, it can use the local file system to mount other devices. For example, the local file system can be a disk file system, etc., and the embodiments of the present application do not limit this to a single one.

[0125] The first device may mount the local file system according to the target mount directory. The target mount directory is a directory of the local file system. Moreover, the target mount directory is the mount point of the local file system on the first device, and is also the mount point of other devices subsequently mounted on the first device. For example, the target mount directory may be pre-set, such as / mnt / appfuse / dfs.

[0126] Step 702: The first device generates a mount directory tree according to the target mount directory.

[0127] For example, the mount directory tree may be set in the memory of the first device.

[0128] The data of the root node of the mount directory tree is the target mount directory. The mount directory indicated by the root node is the target mount directory, that is, the mount point of the local file system. Other nodes in the mount directory tree except the root node indicate the mount directories of other devices, that is, the mount points of other devices. The mount directory indicated by any node in the mount directory tree except the root node is a directory composed of the data of all nodes in the path from the root node to this node.

[0129] After the first device generates the mount directory tree, other devices can be mounted according to the mounting requirements of the application.

[0130] Step 703: The first device obtains mounting request information.

[0131] Optionally, the mount request information may be generated by the first device after receiving the target file name. The mount request information is used to request mounting the second device.

[0132] For example, the mount request information may carry mount parameters. The mount parameters may include the second device identifier, and may further carry the file system type, etc. Optionally, the mount parameters may also include a callback function for receiving the mount result.

[0133] The second device identifier is the identifier of the second device to be mounted by the mount request information. The file system type is the type of the local file system.

[0134] In some cases, after obtaining the mount request information, the first device may verify the legality of the mount parameters in the mount request information. For example, the first device may verify whether the length of the second device identifier in the mount request information is legal.

[0135] If the legitimacy check of the mount parameters in the mount request information fails, the first device does not continue to perform the following step 704, but directly determines that the mount result is a mount failure, and returns the mount result, for example, the mount result can be returned according to the callback function in the mount request information. The mount result can also carry an error code, which is used to indicate the reason for the mount failure.

[0136] If the legitimacy check of the mount parameters in the mount request information passes, the first device can also determine whether the module that generates the mount request information has the mount permission. For example, the first device can parse the local configuration file and determine whether the module has the mount permission based on the local configuration file. If the module has the mount permission, the first device can continue to execute the following step 704; otherwise, the first device does not continue to execute the following step 704, but directly determines that the mount result is a mount failure and returns the mount result.

[0137] In this case, the first device performs the mount operation only when the mount parameters in the mount request information are legal and the module has the mount permission, thereby improving the mount success rate.

[0138] In some cases, the first device may also perform a mount negotiation with the second device before executing step 704. If the mount negotiation with the second device is successful, the first device continues to perform step 704, thereby improving the mount success rate. If the mount negotiation with the second device fails, the first device does not continue to perform step 704, but directly determines that the mount result is a mount failure and returns the mount result.

[0139] If the second device is not currently mounted, the mount negotiation content between the first device and the second device includes: whether the second device supports the distributed file capability and whether the distributed file switch in the second device is turned on. If the second device supports the distributed file capability and the distributed file switch in the second device is turned on, it is determined that the mount negotiation between the first device and the second device is successful; otherwise, it is determined that the mount negotiation between the first device and the second device has failed.

[0140] If the second device is currently mounted, the mount negotiation content between the first device and the second device includes: whether the distributed file switch in the second device is turned on. If the distributed file switch in the second device is turned on, it is determined that the mount negotiation between the first device and the second device is successful; otherwise, it is determined that the mount negotiation between the first device and the second device fails.

[0141] The distributed file capability is used to indicate that the electronic device supports the device mounting solution provided in the embodiment of the present application. If the second device supports the distributed file capability, the second device is Figure 4 In the distributed system shown is an electronic device 400, the second device supports being mounted to other electronic devices in the distributed system.

[0142] The distributed file switch is used to indicate whether the electronic device allows the device mounting solution provided in the embodiment of the present application to be implemented. If the distributed file switch in the second device is turned on, it means that the second device currently allows itself to be mounted on other devices. If the distributed file switch in the second device is turned off, it means that the second device currently does not allow itself to be mounted on other devices.

[0143] Step 704: The first device creates a node in the mount directory tree according to the mount request information, and the data of the node is the second device identifier.

[0144] After the first device creates this node in the mount directory tree, the second device is mounted. In this case, the mount result can be determined to be a successful mount, and the mount result is returned, for example, the mount result can be returned according to the callback function in the mount request information.

[0145] For example, before creating this node, a parent node of this node may also be created, and the data of the parent node of this node is a specified subdirectory. The specified subdirectory may be preset, for example, the specified subdirectory may be preset group information, and the group information may be default. The group information is used to indicate the group to which the second device belongs.

[0146] In some embodiments, after executing step 703, the first device may first determine whether there is a node with data for the second device identifier in the mount directory tree. If there is a node with data for the second device identifier in the mount directory tree, it means that the second device has been mounted before, and the first device may not execute step 704. If there is no node with data for the second device identifier in the mount directory tree, it means that the second device has not been mounted before, and the first device may execute step 704 to mount the second device.

[0147] Further, after performing the above operations, the first device can initialize the client file system, and the first device can send an initialization message to the second device, the initialization message being used to instruct the second device to initialize the server file system. After receiving the initialization message, the second device can initialize its own server file system, and obtain metadata of the root directory of the second device, and then send the metadata to the first device. After receiving the metadata, the first device can store the metadata.

[0148] In some embodiments, the first device can not only mount the second device, but also unmount the mounted second device.

[0149] In the first case, the first device may uninstall the second device when the second device is disconnected from the first device.

[0150] Optionally, when the first device goes offline or the second device goes offline, the first device and the second device are disconnected.

[0151] The operation of the first device uninstalling the second device may be: the first device deletes the node where the second device identifier is located in the mounting directory tree and all nodes under the node.

[0152] In the third case, the first device may obtain uninstallation request information, where the uninstallation request message carries the second device identifier, and the first device uninstalls the second device according to the second device identifier.

[0153] The operation of the first device uninstalling the second device according to the second device identifier may be: the first device deletes the node where the second device identifier is located in the mounting directory tree and all nodes under the node.

[0154] In some embodiments, the method described above can be implemented by relevant modules in the software systems of the first device and the second device. Figure 8 The software system shown is an exemplary illustration of the data acquisition method described above.

[0155] Figure 8 is a block diagram of a software system of a first device and a second device provided in an embodiment of the present application. Figure 8, the block diagram of the software system can be a zero-layer framework layer.

[0156] The software system of the first device may include an application, a system framework layer, a target module, a distributed file software development kit (SDK), a distributed file client, and a data transmission module. The distributed file client includes a mount management module, a data processing module, a metadata processing module, and a communication processing module. The application, the target module, the distributed file client, and the data transmission module may all be located in the application layer. The system framework layer may be located in the application framework layer.

[0157] The software system of the second device may include an application, a system framework layer, a target module, a distributed file SDK, a distributed file client, and a data transmission module. The distributed file client includes a mount management module, a file descriptor management module, and a communication processing module. The application, the target module, the distributed file client, and the data transmission module may all be located in the application layer. The system framework layer may be located in the application framework layer.

[0158] The core modules of this solution are the distributed file client and distributed file server as well as the distributed file SDK provided to the outside. The distributed file client and server provide the application and system framework layer with the ability to access the device file descriptor, and rely on the data transmission module to realize the direct communication between the client and the server.

[0159] The application in the second device needs to call the server-side capabilities of the distributed file SDK through the system framework layer and the target module in turn to complete the construction of the correspondence between the file name and the file descriptor. The application in the first device also needs to call the client-side capabilities of the distributed file SDK through the system framework layer and the target module to complete the file opening. For example, the camera application in the first device can write the captured image into the file opened by the note application in the second device to complete the cross-device transmission of the captured image.

[0160] Next, take the target service as the camera shooting service as an example, combined with Figure 8 The software system shown exemplifies the data acquisition method in the embodiment of the present application.

[0161] Fig. 9 is a flow chart of a data acquisition method provided in an embodiment of the present application, see Fig. 9 The method may include the following steps (1) to (16).

[0162] (1) The note application in the second device opens the note and enters the camera selection interface.

[0163] (2) The system framework layer in the second device displays a camera list in the camera selection interface and pulls up a target module in the second device. The camera list includes a camera identifier of the second device and a camera identifier of the first device.

[0164] (3) The target module in the second device starts the distributed file service and initializes the server capability of the distributed file service, and at the same time notifies the target module in the first device to start the distributed file service.

[0165] Alternatively, see Fig.10 , the target module in the second device can create a distributed file service before pulling up the distributed file service. Specifically, the second device can determine whether the distributed file service corresponding to the note application exists; if it exists, it returns a creation failure; if it does not exist, it creates the distributed file service and returns a creation success.

[0166] (4) The note application in the second device selects the mobile phone camera to take a photo, and the target module in the second device notifies the target module in the first device to launch the shooting service of the camera application.

[0167] (5) After the camera application in the first device completes taking the photo, the anonymous binder of the system framework layer in the second device is obtained through the target module in the first device.

[0168] (6) The camera application in the first device performs an opening operation on the anonymous binder.

[0169] (7) The target module in the first device notifies the target module in the second device to open the note file (i.e., the file used to save the photo data) and obtains the corresponding file name and file descriptor fd.

[0170] (8) The target module in the second device calls the interface of the distributed file server (including but not limited to the createFile interface) to establish a correspondence between the file name and fd, and notifies the target module in the first device to complete the file creation, and the notification carries the file name.

[0171] Alternatively, see Fig.11 , the operation of establishing the correspondence between the file name and fd can be: verify the legality of the file name and fd. If the verification fails, the establishment failure is returned; if the verification succeeds, it is determined whether the distributed file service has been started. If it is not started, the establishment failure is returned. If it is started, it is determined whether the file name has established a correspondence with other file descriptors. If the file name has established a correspondence with other file descriptors, the establishment failure is returned. If the file name has not established a correspondence with other file descriptors, the correspondence between the file name and fd is established, and the timer is started to time the life cycle of the correspondence, and the establishment success is returned.

[0172] (9) The target module in the first device calls the mount interface of the distributed file client to complete the mounting of the second device.

[0173] (10) The target module in the first device uses the file name to call the file opening interface (including but not limited to the openFile interface) of the distributed file client to obtain fd.

[0174] Alternatively, see Fig.12 , the operation of the target module in the first device obtaining fd can be: the target module in the first device calls the file opening interface in the distributed file SDK to send a file opening request to the metadata processing module in the first device. The metadata processing module in the first device sends a request to the server module in the second device through the communication processing module in the first device to obtain the file metadata. The server module in the second device returns the obtained metadata to the client module in the first device. The metadata processing module in the first device calls the file opening interface of the data processing module in the first device. The data processing module in the first device sends a request to the server module in the second device through the communication processing module in the first device to obtain the file descriptor. The server module in the second device returns the obtained file descriptor to the client module in the first device. The data processing module in the first device maps the obtained fd to generate a new fd'. The data processing module in the first device returns fd' to the application in the first device layer by layer. After the application obtains this file descriptor (fd'), it can call the standard POSIX interface to read and write data to realize the access to its device file descriptor capability.

[0175] (11) The distributed file client generates a new fd' according to fd and returns it to the target module in the first device.

[0176] (12) The target module in the first device passes fd' to the camera application in the first device.

[0177] (13) The camera application in the first device writes the image data through fd'.

[0178] (14) The distributed file client transmits the written image data to the distributed file server.

[0179] (15) The distributed file server writes the image data to the file corresponding to fd.

[0180] (16) After the distributed file server completes writing the image data, it notifies the distributed file client of the success of the writing.

[0181] The above process implements the whole process of the note application in the second device calling the camera application in the second device to complete the photo taking and then inserting the picture into the note application.

[0182] Combine the following Fig.13 To explain the mounting steps in step (9) above, see Fig.13 The mounting step may include the following steps (1) to (11).

[0183] (1) The target module in the first device calls the mount interface provided by the distributed file SDK and sends a mount request message to the distributed file client.

[0184] (2) The mount management module in the first device generates a unique mount identifier (ie, lakeId) and then performs a mount operation.

[0185] (3) The mount management module in the first device parses the local configuration file to determine whether the target module in the first device has mount permission.

[0186] (4) The mount management module in the first device performs mount negotiation with the second device.

[0187] The negotiation content includes: whether the device supports distributed file capabilities, whether the distributed file switch of the device is turned on, etc.

[0188] (5) The mount management module in the first device manages the local mount information.

[0189] Optionally, the mount management module in the first device may create a target mount directory of the local file system and generate a mount directory tree.

[0190] (6) The mount management module in the first device initializes the distributed file client file system.

[0191] (7) The mount management module in the first device initializes the distributed file server file system.

[0192] (8) The distributed file server in the second device returns metadata after completing the initialization of the local file system.

[0193] (9) The mount management module in the first device saves the metadata to the metadata processing module.

[0194] (10) The mount management module in the first device creates a node in the mount directory tree to mount the second device.

[0195] (11) The mount management module in the first device returns the mount result to the target module in the first device through a callback.

[0196] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can 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 instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. 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 a website site, computer, server or data center by wired (such as: coaxial cable, optical fiber, data subscriber line (Digital Subscriber Line, DSL)) or wireless (such as: infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)).

[0197] The above are optional embodiments provided for the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the technical scope disclosed in the present application shall be included in the protection scope of the present application.

Claims

1. A data acquisition method, characterized in that: Applied to a first device, the method includes: Receiving a target service start message sent by a second device; Starting a target service in the first device to generate target data; Mounting the second device; Acquire a first file descriptor from the second device, where the first file descriptor is a file descriptor of a target file, and the target file is a file in the second device for storing the target data; Generate a corresponding second file descriptor according to the first file descriptor; The target data is written into the target file according to the second file descriptor.

2. The method according to claim 1, characterized in that Before mounting the second device, the method further includes: After generating the target data, sending a file information acquisition message to the second device; Receive a target file name sent by the second device, where the target file name is the name of the target file; The obtaining the first file descriptor from the second device comprises: Sending a file open message carrying the target file name to the second device; Receive the first file descriptor corresponding to the target file name sent by the second device.

3. The method according to claim 2, characterized in that The sending a file open message carrying the target file name to the second device includes: Sending a metadata acquisition message carrying a target file name to the second device; receiving metadata of the target file sent by the second device; The file open message carrying the target file name is sent to the second device according to the metadata.

4. The method according to any one of claims 1 to 3, characterized in that: Writing the target data into the target file according to the second file descriptor comprises: Obtaining a first write message generated by the target service and carrying the second file descriptor and the target data; Obtain the first file descriptor corresponding to the second file descriptor in the first write message; Generate a second write message carrying the target data in the first write message and the first file descriptor; A second write message is sent to the second device, where the second write message is used to instruct writing the target file to the target file corresponding to the first file descriptor.

5. A data acquisition method, characterized in that: Applied to the second device, the method includes: In response to a first operation, sending a target service start message to the first device, wherein the first operation is used to instruct to obtain target data, the target service start message is used to start a target service, and the target service is used to generate target data; Mounting to the first device; Sending a first file descriptor to the first device, where the first file descriptor is a file descriptor of a target file, and the target file is a file in the second device for storing the target data; The target data sent by the first device is received, and the target data is written into the target file corresponding to the first file descriptor, wherein the target data is sent by the second device according to a second file descriptor corresponding to the first file descriptor.

6. The method according to claim 5, characterized in that Before mounting to the first device, the method further includes: Receiving a file information acquisition message sent by the first device; Open the target file, obtain the target file name and the first file descriptor, and establish a corresponding relationship between the target file name and the first file descriptor, wherein the target file name is the name of the target file; Sending the target file name to the first device; The sending a first file descriptor to the first device includes: Receiving a file open message carrying the target file name sent by the second device; Obtain the first file descriptor corresponding to the target file name in the file open message; The first file descriptor is sent to the first device.

7. The method according to claim 6, characterized in that Before receiving the file open message carrying the target file name sent by the second device, the method further includes: Receiving a metadata acquisition message carrying the target file name sent by the second device; The metadata of the target file is sent to the second device.

8. The method according to any one of claims 5 to 7, characterized in that: The receiving the target data sent by the first device includes: Receive a second write message sent by the first device, the second write message carries the target data and the first file descriptor, the second write message is generated according to the first write message, and the first write message carries the second file descriptor and the target data.

9. The method according to claim 6, characterized in that The establishing a correspondence between the target file name and the first file descriptor includes: Verifying the validity of the target file name and the first file descriptor; If the validity check of the target file name and the first file descriptor passes, determining whether the target file name has established a corresponding relationship with other file descriptors; If the target file name has not established a corresponding relationship with other file descriptors, a corresponding relationship between the target file name and the first file descriptor is established.

10. An electronic device, characterized in that: The electronic device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 9 when executed by the processor.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 9.

Images