Memory sharing method and device, terminal and storage medium

Abstract

The invention provides a memory sharing method and device, a terminal and a storage medium, and is applied to the terminal, the terminal carries a container, the terminal carries a host operating system and a container operating system, the container operating system is arranged in the container, the container is provided with a host device node, and the host device node is arranged in the container. The container operating system carries at least one APP, both the host operating system and the container operating system are Linux and derivative systems thereof, and the method specifically comprises the following steps that in response to an operation instruction for any APP, any APP accesses a shared memory for the host operating system and the container operating system based on a host device node, according to the method and the device, the memory can be shared under the condition that the host operating system is any Linux system or a derivative system of the Linux system.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of terminal software technology, and in particular to a memory sharing method, device, terminal and storage medium. Background Art

[0002] In order to meet user needs, multiple systems can be installed in the same terminal at the same time. For Linux systems, container technology can be used, that is, to build a virtualized container. The system running in the container is called the container operating system (also known as GuestOS), and the system that carries the container is the host operating system (also known as HostOS). For the container operating system, its applications can run in isolated containers, and resource restrictions, mounted storage, network configuration, etc. can be set for different containers.

[0003] In the related art, the SystemV shared memory mechanism provided by the container operating system can be utilized to use shared memory so that the APP running in the container can be started based on the shared memory.

[0004] However, in some Linux systems, the SystemV shared memory mechanism is trimmed. In this case, the host operating system cannot implement memory sharing based on SystemV. Some apps can only use a slower performance method to implement internal logic. In fact, some apps in the container cannot be used or run. Summary of the invention

[0005] The embodiments of the present invention provide a memory sharing method, device, terminal and storage medium to achieve memory sharing when the host operating system is any Linux system or its derivative system.

[0006] The embodiment of the present application provides a memory sharing method, which is applied to a terminal, wherein the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, and the host operating system and the container operating system are both Linux and its derivative systems, and specifically include the following steps:

[0007] In response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the running for any APP;

[0008] Among them, any APP exists in at least one APP.

[0009] Through the memory sharing method provided in the embodiment of the present application, shared memory can be implemented without the help of the SystemV shared memory mechanism, and memory can be shared when the host operating system is any Linux system or its derivative system.

[0010] One possible way is that, in response to the running instruction for any APP, before the step of any APP constructing an access path based on the host device node, the method further includes:

[0011] Bind the host device node to the container.

[0012] One possible way is that, in response to the running instruction for any APP, the step of any APP constructing an access path based on the host device node includes:

[0013] In response to an execution instruction for any APP, access a dynamic library for any APP;

[0014] Based on the dynamic library for any APP, operations are performed on the host device node, and the shared memory for the host operating system and the container operating system is accessed to execute the operation for any APP.

[0015] One possible way is to access a dynamic library for any APP in response to an operation instruction for any APP; to perform operations on a host device node based on the dynamic library for any APP, access a shared memory for a host operating system and a container operating system, and execute the operation for any APP. The process includes:

[0016] An access path for the host device node is determined based on the host device node, the container root path, and the path within the container.

[0017] One possible way is that, in response to a running instruction for any APP, the process of accessing the dynamic library for any APP includes:

[0018] Access the determined absolute path of the dynamic library based on any APP, and access the dynamic library for any APP.

[0019] One possible way is that, in response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node, and before executing the step of running any APP, the method further includes:

[0020] Set the global environment variable for the container or the local environment variable for the container to the absolute path determined based on the dynamic library of any APP.

[0021] One possible approach is to set the local environment variable for the container to an absolute path based on the dynamic library of any APP;

[0022] Before accessing the determined absolute path of the dynamic library based on any APP, the method further includes:

[0023] In response to a running instruction for any APP, a system interface is called to start any APP.

[0024] In a second aspect, the present application provides a memory sharing device, which is applied to a terminal, the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, and the host operating system and the container operating system are both Linux and its derivative systems, including:

[0025] Response module: used to respond to the running instruction for any APP, and any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the operation for any APP;

[0026] Among them, any APP exists in at least one APP.

[0027] In a third aspect, the present application provides an electronic device, including:

[0028] at least one processor; and

[0029] at least one memory in communication with the processor, wherein:

[0030] The memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the method of the first aspect.

[0031] In a fourth aspect, the present application provides a computer-readable storage medium, which stores computer instructions, and the computer instructions enable a computer to execute the method of the first aspect.

[0032] It should be understood that the second to fourth aspects of the embodiments of the present invention are consistent with the technical solutions of the first aspect of the embodiments of the present invention, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be described in detail. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0034] Figure 1 It is a flow chart of container control in the related art;

[0035] Figure 2 It is a schematic diagram of a memory sharing method in the related art;

[0036] Figure 3 A schematic diagram of a memory sharing method in a related art where the host operating system does not support SystemV;

[0037] Figure 4 A schematic diagram of a memory sharing method in a related art where the host operating system does not support SystemV;

[0038] Figure 5 A block diagram of an electronic device provided for the implementation of this application;

[0039] FIG6( a ) is a schematic diagram of a host device node binding according to an embodiment of the present application;

[0040] FIG6( b ) is a schematic diagram of a path within a container of a host device node provided in an embodiment of the present application;

[0041] Figure 7 A schematic diagram of the absolute path of the dynamic library provided in the embodiment of the present application;

[0042] Figure 8 A schematic diagram of a memory sharing method provided in an embodiment of the present application;

[0043] Fig. 9 A software diagram of an electronic device provided in an embodiment of the present application;

[0044] Fig.10 Another schematic diagram of the memory sharing method provided in the embodiment of the present application;

[0045] Fig.11 A flow chart of a memory sharing method provided in an embodiment of the present application;

[0046] Fig.12 A structural diagram of a memory sharing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to better understand the technical solution of the embodiment of the present invention, the embodiment of the present invention is described in detail below with reference to the accompanying drawings.

[0048] It should be clear that the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments in the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the embodiments of the present invention.

[0049] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of the present invention. The singular forms "a", "an", "the" and "the" used in the embodiments of the present invention and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0050] In order to meet user needs, multiple systems can be installed in the same terminal at the same time. For Linux systems, container technology can be used, that is, to build a virtualized container. The system running in the container is called the container operating system (also known as GuestOS), and the system that carries the container is the host operating system (also known as HostOS). For the container operating system, its applications can run in isolated containers, and resource restrictions, mounted storage, network configuration, etc. can be set for different containers.

[0051] For Linux systems, there are many applications in the container. In order to enable the APP (Application) in the container to run, here, for the APP in the container, its running process is as follows: Figure 1 As shown, you first need to configure the container parameters and give them to create a container. After the container is created, start the container and then start the application. At this time, the application runs.

[0052] In the related art, the shared memory mechanism provided by the container operating system can be utilized to use the shared memory so that the APP running in the container can be started based on the shared memory.

[0053] Combination Figure 2 Regarding shared memory, shared memory is a way of inter-process communication in modern operating systems. In operating systems such as Ubuntu (Ubuntu operating system) and OpenEuler (open source Euler operating system), multiple processes are run to access the same memory area and write data together. As a result, all processes sharing the area can directly read the written content without communication, completing the exchange of data across processes. For different operating systems, the sharing methods are also different. In Linux systems and their derivative systems, some systems use the Ashmem shared memory mechanism.

[0054] However, this sharing method has disadvantages. Since multiple containers are isolated from each other, it is necessary to use the kernel capabilities of the host operating system. APP (application) implements shared memory access through mmap, or through the memory mechanism provided by the operating system (such as Android's Ashmem or Linux's System). For details, please refer to Figure 1 Taking EulerOS as an example, the host operating system and the container operating system are both EulerOS. First, the APP in the container calls shmget, shmat, shmdt and shmctl. Specifically, shmget is used to obtain a shared memory identifier or create a shared memory object, and shmat is used to map the shared memory area object to the address space of the calling process. Shmdt is a decoupling function used to detach the shared memory from the current process. Shmctl is specifically used to delete the shared memory. At this time, the host operating system provides calls to shmget, shmat, shmdt and shmctl based on the SystemV shared memory mechanism.

[0055] Reference Figure 3 as well as Figure 4 It can be seen that multiple isolated container operating systems and the host operating system share a kernel, which also leads to derivative problems. Assume that the host operating system is the Android operating system and the container operating system is the Linux operating system. In most situations, the Linux system can easily implement most system calls, but shared memory is a special case: in order to prevent global kernel resource leakage, the Android system prunes the SystemV mechanism and uses Ashmem anonymous shared memory to replace the SystemV shared memory mechanism to achieve memory sharing. Since the host operating system does not support SystemV shared memory at this time, the container operating system cannot use shmget, shmat, shmdt and shmctl related system-level calls to implement shared memory. Based on this, a large number of communication applications can only implement business logic through the less efficient Socket method, which leads to reduced performance of applications in the container, and even some APPs that only support the SystemV shared memory mechanism cannot be used.

[0056] To this end, the present application provides a memory sharing method that can be applied to all Linux scenarios, especially when the host operating system does not support System V mechanism shared memory, thereby improving the performance of the container operating system.

[0057] First, let's introduce the terminal provided by this application:

[0058] Figure 5 A schematic structural diagram of an electronic device 100 is shown.

[0059] 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. 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.

[0060] It is to be understood that the structure illustrated in the embodiment of the present invention 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 separate 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.

[0061] 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 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.

[0062] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0063] 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.

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

[0065] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple groups of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 communicates with the touch sensor 180K through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0066] The I2S interface can be used for audio communication. In some embodiments, the processor 110 can include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to achieve communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 via the I2S interface to achieve the function of answering a call through a Bluetooth headset.

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

[0068] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to implement the Bluetooth function. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 through the UART interface to implement the function of playing music through a Bluetooth headset.

[0069] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the electronic device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the electronic device 100.

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

[0071] 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 interface can also be used to connect other electronic devices, such as AR devices, etc.

[0072] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0073] 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. In the embodiment of the present invention, the Android system of the layered architecture is taken as an example to exemplify the software structure of the electronic device 100.

[0074] Here is a scenario:

[0075] The user is using a terminal, which is equipped with a container. The terminal is also equipped with a host operating system and a container operating system. The container operating system is placed in the container. Furthermore, the host operating system and the container operating system use the Linux system or a derivative system of the Linux system. Specifically, the host operating system is the Android system, and the container operating system is EulerOS (Euler operating system).

[0076] In this regard, it should be noted that the above host operating system and container operating system are merely examples provided by the present application and are not limitations of the present application.

[0077] At this time, the terminal is running a container operating system, and there is at least one APP in the container operating system, such as A, B, and C. It can be understood that A, B, and C represent three APPs loaded in the container operating system.

[0078] At this time, the user wants to run A. At this time, the user first triggers the running instruction for A. At this time, the container operating system accesses the shared memory based on the host device access node, and the A system runs based on the shared memory.

[0079] It should be noted that in the embodiments provided in the present application, the host device node is pre-bound to the container, and the host operation node binding method is different for different host operating systems.

[0080] In this way, when the host operating system is Linux or its derivative system, the terminal can realize memory sharing without the help of SystemV mechanism, thereby realizing the full-scenario applicability of Linux memory sharing.

[0081] Therefore, in the case where the terminal provided in the present application is equipped with a container and the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, and the host operating system and the container operating system are both Linux and its derivative systems, the memory sharing method provided in the embodiment of the present application specifically includes the following steps:

[0082] In response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the running for any APP;

[0083] Among them, any APP exists in at least one APP.

[0084] It is understandable that in the embodiments provided in the present application, the host device access node has the ability to access the shared memory.

[0085] On the basis of the foregoing embodiment, in the embodiment provided by the present application, before the user issues the A run instruction, the terminal side needs to bind the host device node to the container.

[0086] In other words, in response to the running instruction for any APP, before any APP constructs an access path based on the host device node, the method further includes:

[0087] Bind the host device node to the container.

[0088] Optionally, for the binding method, the binding mount method can be used. The so-called binding mount is to mount the target file or target directory to a new target path again. After mounting, the target file or target directory can be accessed through the two new paths. At the same time, it is assumed that modifications to the target file from the new and old paths will also take effect.

[0089] Of course, the binding and mounting method provided in this application is only one feasible method. Those skilled in the art may refer to other equivalent methods to achieve the same effect as the binding and mounting of this application, thereby achieving the sharing of device nodes between the host operating system and the container operating system.

[0090] Based on the foregoing, the host device node has been bound to the container. In order to achieve access to the host device node, in the embodiment provided in the present application, in order to form a system call interface, a dynamic library is formed in the container, and operation control is performed according to the Ashmem specification to perform operations on the host device node and obtain or destroy shared memory.

[0091] That is, in the embodiment provided in the present application, the terminal responds to the running instruction for any APP, and the step of any APP constructing an access path based on the host device node includes:

[0092] The terminal accesses the dynamic library for any APP in response to the running instruction for any APP;

[0093] The terminal performs operations on the host device node based on the dynamic library for any APP, accesses the shared memory for the host operating system and the container operating system, and executes the operation for any APP.

[0094] One possible implementation method is that the dynamic library is a SystemV shared memory simulation dynamic library, thereby forming hooks for the system call interfaces shmget, shmat, shmdt, and shmctl, so that when the application calls the above interfaces, the logic directly accesses the host device node mapped to the container through the logic implemented in the dynamic library, thereby completing the use of shared memory.

[0095] In some embodiments, an APP based in the container system can directly access the host device node. In this scenario, it also complies with the response to the running instructions for any APP. Any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the running logic for any APP. In other words, assuming that an APP in the container can access the host device node without the help of a dynamic library, it is also included in the protection scope of this application.

[0096] At the same time, assuming that you need to start an APP in the container, you can use the container management server to set the specified path as the container root path through chroot (changing the root directory) and other methods, and determine the path in the container to directly access the host device node, thereby forming an access path for the host device node.

[0097] Please refer to Figure 6(a). For example, the host device node / dev / ashmem is bound to the container file path. Combined with Figure 6(b), / data / contianer_root is specified as the container root path, / hostdev / ashmem is the path within the container, and the access path is / dev / ashmem / data / contianer_root / hostdev / ashmem. That is, the access path for the host device node can be determined based on the host device node, the container root path and the path within the container. The APP in the container can access the host device node based on this access path.

[0098] Thus, the terminal responds to the running instruction for any APP, accesses the dynamic library for any APP; performs operations on the host device node based on the dynamic library for any APP, accesses the shared memory for the host operating system and the container operating system, and executes the running process for any APP, including:

[0099] An access path for the host device node is determined based on the host device node, the container root path, and the path within the container.

[0100] It should be noted that in FIG. 6( b ), / dev / ashmem / data / contianer_root / hostdev / ashmem corresponds to the access path for the host device node.

[0101] Through the above-mentioned method, the access path for the host device node is determined, and the dynamic library can access the access path for the host device node according to the access path.

[0102] At the same time, refer to Figure 7 In the embodiments provided in the present application, the dynamic library can be accessed by the absolute path set when the container is started.

[0103] In the above scenario, based on the fact that the host operating system is the Android operating system, the absolute path can be / usr / lib / shm_adapter.so, as shown in the following example: Figure 7 As shown, when the APP in the container accesses this absolute path, operations can be performed on the mapped host device node according to the aforementioned access path for the host device node. Specific executable operations include but are not limited to: open, icotl and mmap.

[0104] Furthermore, open is used to open the host device node, icotl: is used to perform functions such as opening, closing, reading, and writing shared memory, and mmap is used to create shared memory.

[0105] It can be seen that the process of the terminal accessing the dynamic library for any APP in response to the running instruction for any APP includes:

[0106] Access the determined absolute path of the dynamic library based on any APP, and access the dynamic library for any APP.

[0107] Further integration Figure 7 In the embodiment, / usr / lib / shm_adapter.so corresponds to the absolute path determined by the dynamic library based on any APP.

[0108] This enables access to the dynamic library. When an APP in the container calls an APP, the dynamic library is called, and the host device node is accessed according to the access path of the host device node. Operations are performed on the host device node, and shared memory is created, so that the APP in the container can run based on the shared memory.

[0109] At the same time, in the embodiment provided by the present application, in order to enable the APP in the container to access the dynamic library, in the embodiment provided by the present application, the dynamic library is accessed by an absolute path, that is, / usr / lib / shm_adapter.so in the corresponding figure. In order to obtain the aforementioned absolute path, the global environment variable for the container can be set to the absolute path, so as to realize the preloading of the dynamic library. Therefore, when the global environment variable for the container is called, the dynamic library can be loaded, and the APP in the container does not need to call hmget, shmat, shmdt, and shmctl.

[0110] It can be seen that before the terminal accesses the determined absolute path of the dynamic library based on any APP, the method further includes:

[0111] Set the global environment variable for the container to the absolute path of the dynamic library based on any APP.

[0112] In conjunction with the above specific example, the absolute path is: / usr / lib / shm_adapter.so. At this time, the global environment variable for the container is: LD_PRELOAD = / usr / lib / shm_adapter.so.

[0113] Compared with the global environment variables, in some other embodiments, local caliber variables are used to set the absolute path determined based on the dynamic library of any APP.

[0114] It should be noted that in Linux systems, the difference between global environment variables and local environment variables is that local environment variables can only be used in the current shell process, not in the subshell of the current shell, and not in other shells, while global environment variables can be used in the current shell process and its subshells. Here, the shell is a program that acts as an interface between the user and the kernel. It allows the user to issue commands to the kernel and get responses from the kernel.

[0115] In view of this, in order to set the local environment variables for the container, the setenv system function can be used to set the local environment variables for the container, and the local environment variables for the container are set to the absolute path determined based on the dynamic library of any APP to realize the preloading of the dynamic library. Different from using the local environment variables for the container to realize the preloading of the dynamic library, when the local environment variables for the container are set to the absolute path determined based on the dynamic library of any APP, it is necessary to call the system interface corresponding to the startup of the APP.

[0116] The system interfaces here include but are not limited to: fork and exec.

[0117] Thus, another way of setting an absolute path is provided. In the embodiment, before accessing the absolute path determined based on the dynamic library of any APP, the method further includes:

[0118] In response to a running instruction for any APP, calling a system interface to start any APP;

[0119] Set the local environment variable for the container to the absolute path determined by any APP's dynamic library.

[0120] Compared with setting the global environment variables for the container to the absolute path determined based on the dynamic library of any APP, different control strategies can be adopted for different APPs in the container, which improves the flexibility of APP control. Assuming that in the same container, some APPs do not need to share memory, the processes based on these APPs will not be loaded into the dynamic library, reducing the invalid memory usage.

[0121] On the basis of the aforementioned embodiment, please refer to the figure. In the aforementioned user is using a terminal, and the terminal is equipped with a container Q, and the terminal is equipped with a host operating system and a container operating system. The container operating system is placed in the container. Furthermore, the host operating system and the container operating system adopt the Linux system or a derivative system of the Linux system. Specifically, the host operating system is the Android system, and the container operating system is the EulerOS system. In the scenario, the container operating system is equipped with three APPs A, B, and C.

[0122] Here, the user needs to start A. When container Q is created, first of all, for container Q, when container Q is created, the environment variables for container Q are set. Specifically, the global environment variables for the container or the local environment variables for the container can be set to the absolute path determined based on the dynamic library of any APP, and the host device node can be bound to container Q. Specifically, / dev / ashmem can be bound and mounted to the container file system path. I will not go into details here.

[0123] Based on this, that is, the operating environment and the configuration parameters of container Q are specified, container Q can be started. It should be noted that at this time, in response to A's startup instruction, the dynamic library for A is loaded through the environment variable, and the access path of the host device node is determined based on the host device of container Q, the container root path and the internal path of the container. Operations are performed on the host device node through the dynamic library to realize the operation of A.

[0124] Based on the above examples, please refer to Figure 8 , for the embodiment provided by this application, when setting the container parameters, first bind the host device node and set the environment variables, compared Figure 8 as well as Figure 1 The embodiment shown has no difference from the technical solutions of the related art when creating a container and starting to run the container. When running an application, the application is started and the dynamic library is loaded when the application is started. Based on the foregoing, the dynamic library can be loaded using environment variables. It can be understood that the environment variables here are global environment variables in some embodiments and local environment variables in other embodiments.

[0125] After the dynamic library is loaded, the APP accesses the dynamic library, and the dynamic library performs operations on the host device node based on the host device access path determined by the host device node, so that the APP runs based on the shared memory.

[0126] Here, in order to further explain the shared memory method provided by the present application, under the host operating system of Android, the implementation method of the present application is further explained in combination with the system software structure provided by the present application.

[0127] Fig. 9 1 is a software structure block diagram of the electronic device 100 according to an embodiment of the present invention.

[0128] 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 four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system library, and the kernel layer.

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

[0130] like Fig. 9 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0131] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0132] like Fig. 9 As 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, and the like.

[0133] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0134] Content providers are used to store and retrieve data and make it accessible to applications. The data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0135] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0136] 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.).

[0137] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0138] The notification manager enables applications to display notification information in the status bar. It 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 a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0139] Android Runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

[0140] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0141] The application layer and the application framework layer run in a 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 functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0142] The system library may 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.

[0143] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0144] 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.

[0145] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0146] A 2D graphics engine is a drawing engine for 2D drawings.

[0147] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0148] Further integration Fig. 9 Please refer to the Android system architecture shown in Fig.10 , container Q is in the application system layer, and the host operating system outside the container has C or C++ applications and JAVA programs. For applications outside the container, how the host operating system implements the call from the application system layer to the kernel layer is not described in detail here. Assuming that the user wants to start application A of Q in the container, based on the above, it is necessary to call the application layer based on the absolute path of the dynamic library for A to call the dynamic library for A, and then the dynamic library of A accesses the host device node under the management of the Ashmem mechanism based on the access path for the host device node, and performs operations on the host device node to realize the operation of application A based on shared memory.

[0149] It should also be noted that the management and operation of the host device node are completed at the Android kernel layer.

[0150] Please refer to Fig.11 , Fig.11 A flow chart of a memory sharing method is provided, which is applied to a terminal, wherein the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, and the host operating system and the container operating system are both Linux and its derivative systems, and specifically includes the following steps:

[0151] In response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the running for any APP;

[0152] Among them, any APP exists in at least one APP.

[0153] One possible way is that, in response to the running instruction for any APP, before the step of any APP constructing an access path based on the host device node, the method further includes:

[0154] Bind the host device node to the container.

[0155] One possible way is that, in response to the running instruction for any APP, the step of any APP constructing an access path based on the host device node includes:

[0156] In response to an execution instruction for any APP, access a dynamic library for any APP;

[0157] Based on the dynamic library for any APP, operations are performed on the host device node, and the shared memory for the host operating system and the container operating system is accessed to execute the operation for any APP.

[0158] One possible way is to access a dynamic library for any APP in response to an operation instruction for any APP; to perform operations on a host device node based on the dynamic library for any APP, access a shared memory for a host operating system and a container operating system, and execute the operation for any APP. The process includes:

[0159] An access path for the host device node is determined based on the host device node, the container root path, and the path within the container.

[0160] One possible way is that, in response to a running instruction for any APP, the process of accessing the dynamic library for any APP includes:

[0161] Access the determined absolute path of the dynamic library based on any APP, and access the dynamic library for any APP.

[0162] One possible way is that, in response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node, and before executing the step of running any APP, the method further includes:

[0163] Set the global environment variable for the container or the local environment variable for the container to the absolute path determined based on the dynamic library of any APP.

[0164] One possible approach is to set the local environment variable for the container to an absolute path based on the dynamic library of any APP;

[0165] Before accessing the determined absolute path of the dynamic library based on any APP, the method further includes:

[0166] In response to a running instruction for any APP, a system interface is called to start any APP.

[0167] Please refer to Fig.12 , Fig.12 A memory sharing device structure diagram provided in an embodiment of the present application is applied to a terminal, the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, and the host operating system and the container operating system are both Linux and its derivative systems, including:

[0168] Response module: used to respond to the running instruction for any APP, and any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the operation for any APP.

[0169] Fig.12 The memory sharing device provided in the embodiment shown can be used to execute the present application Fig.11 The technical solution of the method embodiment shown, its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

[0170] One possible way is to further include: a binding module: binding the host device node to the container.

[0171] One possible approach is that the response module is specifically used to:

[0172] In response to an execution instruction for any APP, access a dynamic library for any APP;

[0173] Based on the dynamic library for any APP, operations are performed on the host device node, and the shared memory for the host operating system and the container operating system is accessed to execute the operation for any APP.

[0174] The response module is also used to: respond to the running instruction for any APP, access the dynamic library for any APP; perform operations on the host device node based on the dynamic library for any APP, access the shared memory for the host operating system and the container operating system, and execute the running process for any APP, including:

[0175] An access path for the host device node is determined based on the host device node, the container root path, and the path within the container.

[0176] One possible way is to further include: a setting module: used to set the global environment variable for the container or the local environment variable for the container to a determined absolute path based on the dynamic library of any APP.

[0177] One possible approach is to set the local environment variable for the container to an absolute path determined based on the dynamic library of any APP.

[0178] One possible approach is that the response module is further used to: respond to a running instruction for any APP and call a system interface to start any APP.

[0179] The embodiment of the present application provides an electronic device, which may be a terminal device or a circuit device built into the terminal device. The electronic device may be used to execute the functions / steps in the above method embodiment.

[0180] An embodiment of the present application provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a terminal device, the terminal device executes the functions / steps in the above method embodiment.

[0181] In the description of the embodiments of the present invention, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the embodiments of the present invention. In the embodiments of the present invention, the schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in the embodiments of the present invention and the features of the different embodiments or examples, without contradiction.

[0182] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of the embodiments of the present invention, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0183] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred implementation of the embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present invention belong.

[0184] The word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0185] It should be noted that the terminals involved in the embodiments of the present invention may include but are not limited to personal computers (Personal Computer; hereinafter referred to as: PC), personal digital assistants (Personal Digital Assistant; hereinafter referred to as: PDA), wireless handheld devices, tablet computers (Tablet Computer), mobile phones, MP3 players, MP4 players, etc.

[0186] In the several embodiments provided in the embodiments of the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0187] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0188] The above are only preferred embodiments of the embodiments of the present invention and are not intended to limit the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present invention should be included in the scope of protection of the embodiments of the present invention.

Claims

1. A memory sharing method, characterized in that: The method is applied to a terminal, the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, the host operating system and the container operating system are both Linux and its derivative systems, and specifically includes the following steps: In response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the running for any APP. Among them, any one of the APPs exists in the at least one APP.

2. The method according to claim 1, characterized in that Before the step of any APP constructing an access path based on the host device node in response to the running instruction for any APP, the method further includes: Bind the host device node to the container.

3. The method according to claim 2, characterized in that In response to the running instruction for any APP, the steps of any APP constructing an access path based on the host device node include: In response to an execution instruction for any APP, access a dynamic library for any APP; Based on the dynamic library for any APP, operations are performed on the host device node, and the shared memory for the host operating system and the container operating system is accessed to execute the operation for any APP.

4. The method according to claim 3, characterized in that The step of responding to the running instruction for any APP and accessing the dynamic library for any APP; and performing the operation on the host device node based on the dynamic library for any APP, accessing the shared memory for the host operating system and the container operating system, and executing the running for any APP includes: An access path for the host device node is determined based on the host device node, the container root path, and the path within the container.

5. The method according to claim 3, characterized in that: The process of accessing the dynamic library for any APP in response to the running instruction for any APP includes: Access the determined absolute path of the dynamic library based on any APP, and access the dynamic library for any APP.

6. The method according to claim 5, characterized in that In response to the running instruction for any APP, any APP accesses the shared memory for the host operating system and the container operating system based on the host device node, and before executing the step of running any APP, the method further includes: Set the global environment variable for the container or the local environment variable for the container to the determined absolute path based on the dynamic library of any APP.

7. The method according to claim 6, characterized in that The local environment variable for the container is set to an absolute path determined based on a dynamic library of any APP; Before accessing the determined absolute path of the dynamic library based on any APP, the method further includes: In response to a running instruction for any APP, a system interface is called to start the any APP.

8. A memory sharing device, characterized in that: Applied to a terminal, the terminal is equipped with a container, the terminal is equipped with a host operating system and a container operating system, the container operating system is placed in the container, the container is provided with a host device node, the container operating system is equipped with at least one APP, the host operating system and the container operating system are both Linux and its derivative systems, including: A response module: used to respond to an operation instruction for any APP, and any APP accesses the shared memory for the host operating system and the container operating system based on the host device node to execute the operation for any APP; Among them, any one of the APPs exists in the at least one APP.

9. An electronic device, characterized in that: include: at least one processor; as well as at least one memory in communication with the processor, wherein: The memory stores program instructions executable by the processor, and the processor can execute the method according to any one of claims 1 to 7 by calling the program instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions enable the computer to execute the method according to any one of claims 1 to 7.

Images