Memory sharing method and apparatus, terminal, and storage medium

Abstract

The present application provides a memory sharing method and apparatus, a terminal, and a storage medium. The method is applied to a terminal, the terminal is equipped with a container and is equipped with 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, 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 derivative systems thereof. The method specifically comprises the following steps: in response to an operation instruction for any app, on the basis of the host device node, said any app accessing a shared memory for the host operating system and the container operating system, and executing an operation for said any app. The present application can achieve memory sharing when the host operating system is any Linux system or a derivative system thereof.

Description

Memory sharing method, device, terminal and storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on September 27, 2023, with application number 202311270717.3 and application name “Memory Sharing Method, Device, Terminal and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] 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

[0003] To meet user needs, multiple systems can be installed on the same terminal at the same time. For Linux systems, container technology can be used, that is, a virtualized container is built. 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.

[0004] In related technologies, 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.

[0005] 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 slower performance methods to implement internal logic. In fact, some apps in the container cannot be used or run.

[0006] Summary of the Invention

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

[0008] 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 both the host operating system and the container operating system are Linux or its derivative systems, specifically comprising the following steps:

[0009] In response to the execution 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 execution for any APP;

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

[0011] Through the memory sharing method provided in the embodiment of the present application, shared memory can be implemented without resorting to the System V shared memory mechanism, and memory can be shared when the host operating system is any Linux system or its derivative systems.

[0012] In one possible manner, in response to an execution instruction for any APP, before the step of any APP constructing an access path based on the host device node, the method further includes:

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

[0014] In one possible manner, in response to an execution instruction for any APP, the steps of any APP constructing an access path based on the host device node include:

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

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

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

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

[0019] One possible approach is that, in response to a run instruction for any APP, the process of accessing the dynamic library for any APP includes:

[0020] Access the absolute path determined based on any APP's dynamic library, and access the dynamic library for any APP.

[0021] In one possible manner, in response to an execution 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 executing the execution for any APP, the method further includes:

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

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

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

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

[0026] In a second aspect, the present application provides a memory sharing device, 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, including:

[0027] 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;

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

[0029] In a third aspect, the present application provides an electronic device, comprising:

[0030] at least one processor; and

[0031] at least one memory communicatively coupled to the processor, wherein:

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

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

[0034] 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 repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. 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 paying any creative work.

[0036] FIG1 is a flow chart of container control in the related art;

[0037] FIG2 is a schematic diagram of a memory sharing method in related art;

[0038] FIG3 is a schematic diagram of a memory sharing method in a related art in which the host operating system does not support SystemV;

[0039] FIG4 is a schematic diagram of a memory sharing method in another related art in which the host operating system does not support SystemV;

[0040] FIG5 is a structural diagram of an electronic device provided by the present application;

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

[0042] 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;

[0043] FIG7 is a schematic diagram of the absolute path of a dynamic library provided in an embodiment of the present application;

[0044] FIG8 is a schematic diagram of a memory sharing method according to an embodiment of the present application;

[0045] FIG9 is a software diagram of an electronic device provided in an embodiment of the present application;

[0046] FIG10 is another schematic diagram of the memory sharing method provided in an embodiment of the present application;

[0047] FIG11 is a flow chart of a memory sharing method provided in an embodiment of the present application;

[0048] FIG12 is a structural diagram of a memory sharing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to better understand the technical solutions of the embodiments of the present invention, the embodiments of the present invention are described in detail below with reference to the accompanying drawings.

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

[0051] 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," 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 otherwise.

[0052] To meet user needs, multiple systems can be installed on the same terminal at the same time. For Linux systems, container technology can be used, that is, a virtualized container is built. 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.

[0053] For Linux systems, there are many applications in the container. In order to enable the container's APP (Application, application) to run, here, for the APP in the container, its operation process is shown in Figure 1. First, you need to configure the container parameters and create the container based on the container parameters. After the container is created, start the container and then start the application. At this time, the application runs.

[0054] In related technologies, the 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.

[0055] Combined with 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 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.

[0056] However, this sharing method has disadvantages. Since multiple containers are isolated from each other, it is necessary to rely on the kernel capabilities of the host operating system. APP (application) implements shared memory access through mmap, or implements shared memory through the memory mechanism provided by the operating system (such as Android's Ashmem or Linux's System). Please refer to Figure 1 for details. Taking the host operating system and the container operating system as EulerOS as an example, the APP in the container first 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.

[0057] Referring to Figures 3 and 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 in turn leads to reduced performance of applications in the container, and even some APPs that only support the SystemV shared memory mechanism cannot be used.

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

[0059] First, let’s introduce the terminal provided in this application:

[0060] FIG5 shows a schematic structural diagram of the electronic device 100 .

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

[0062] It should be understood that the structure illustrated in the embodiments 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, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0063] 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 processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

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

[0065] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly retrieve it from the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

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

[0067] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C bus lines. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, and the like via different I2C bus interfaces. For example, the processor 110 may be coupled to the touch sensor 180K via the I2C interface, enabling communication between the processor 110 and the touch sensor 180K via the I2C bus interface, thereby implementing the touch function of the electronic device 100.

[0068] 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 enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface, enabling the function of answering calls through a Bluetooth headset.

[0069] 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, enabling the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

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

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

[0072] The GPIO interface can be configured via software. The GPIO interface can be configured as either a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to the camera 193, display 194, wireless communication module 160, audio module 170, 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.

[0073] The USB interface 130 is an interface that complies with USB standards and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the electronic device 100, or to transfer data between the electronic device 100 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect other electronic devices, such as augmented reality devices.

[0074] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is merely an illustrative 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 from the above embodiments, or a combination of multiple interface connection methods.

[0075] The software system of the electronic device 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present invention, the Android system with a layered architecture is used as an example to illustrate the software structure of the electronic device 100.

[0076] Here is a scenario:

[0077] The user is using a terminal that 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.

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

[0079] At this time, the terminal is running a container operating system. 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.

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

[0081] It should be noted that in the embodiments provided in this 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.

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

[0083] Therefore, in the context of a terminal provided in the present application being equipped with a container and the terminal being equipped with a host operating system and a container operating system, the container operating system being placed in the container, the container being provided with a host device node, the container operating system being equipped with at least one APP, and both the host operating system and the container operating system being Linux or its derivative systems, the memory sharing method provided in the embodiments of the present application specifically includes the following steps:

[0084] In response to the execution 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 execution for any APP;

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

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

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

[0088] 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:

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

[0090] Optionally, for the binding method, the bind mount method can be used. The so-called bind 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, if the target file is modified from the new and old paths, it will also take effect.

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

[0092] 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 this 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.

[0093] 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:

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

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

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

[0097] In some embodiments, an APP within a container system can directly access a host device node. In this scenario, it also complies with the response to an execution 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 execution logic for any APP. In other words, assuming that an APP within a 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.

[0098] 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 methods such as chroot (changing the root directory), and determine the path in the container to directly access the host device node, thereby forming an access path for the host device node.

[0099] 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, and / hostdev / ashmem is the path within the container. 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.

[0100] Thus, the terminal responds to the running instruction for any APP and accesses the dynamic library for any APP; the process of performing operations 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 operation for any APP includes:

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

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

[0103] By the aforementioned 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.

[0104] Meanwhile, referring to FIG. 7 , in the embodiment provided in the present application, the dynamic library can be accessed specifically by the absolute path set when the container is started.

[0105] In the aforementioned 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 specifically shown in FIG7 . 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.

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

[0107] 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:

[0108] Access the absolute path determined based on any APP's dynamic library, and access the dynamic library for any APP.

[0109] Further in conjunction with the embodiment of FIG. 7 , / usr / lib / shm_adapter.so corresponds to the absolute path determined based on any APP's dynamic library.

[0110] This enables access to the dynamic library. When an APP in the container calls the 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.

[0111] 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 using 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.

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

[0113] Set the global environment variable for the container to the absolute path of any APP's dynamic library.

[0114] In conjunction with the specific above 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.

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

[0116] It's important to note that in Linux, the difference between global and local environment variables is that local environment variables are only available within the current shell process, not in its subshells or other shells, while global environment variables are available within the current shell process and its subshells. The shell is a program that acts as an interface between the user and the kernel, allowing the user to issue commands to the kernel and receive responses from it.

[0117] To address this, you can use the setenv system function to set local environment variables for the container. This function sets the local environment variables for the container to the absolute path of any app's dynamic library, enabling preloading of the dynamic library. Unlike preloading dynamic libraries using local environment variables for the container, setting the local environment variables for the container to the absolute path of any app's dynamic library requires calling the system interface to start the corresponding app.

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

[0119] This provides another way to set the absolute path. In the embodiment, before accessing the absolute path determined based on the dynamic library of any APP, the method further includes:

[0120] In response to a run instruction for any APP, call the system interface to start any APP;

[0121] Set the local environment variable for the container to the absolute path of any APP's dynamic library.

[0122] Compared with setting the global environment variables for the container to the absolute path determined by 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 invalid memory usage.

[0123] Based on the above embodiment, please refer to the figure. In the above embodiment, the user is using a terminal, which 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 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 the EulerOS system. The container operating system is equipped with three APPs A, B, and C.

[0124] Here, the user needs to start A. When container Q is created, the environment variables for container Q are first 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 the container Q. Specifically, / dev / ashmem can be bound and mounted to the container file system path. I will not go into details here.

[0125] Based on this, that is, the operating environment and 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 will be loaded through the environment variables, and the access path of the host device node will be 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.

[0126] Based on the foregoing embodiments, please refer to Figure 8. For the embodiments provided in this application, when setting the container parameters, first bind the host device node and set the environment variables. Comparing Figure 8 and the embodiments shown in Figure 1, when creating a container and starting the running container, there is no difference from the technical solutions of the related technologies. When running the application, start the application and load the dynamic library when starting the application. 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 some other embodiments.

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

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

[0129] FIG9 is a block diagram of the software structure of the electronic device 100 according to an embodiment of the present invention.

[0130] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

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

[0132] As shown in FIG9 , the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and short message.

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

[0134] As shown in FIG9 , the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.

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

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

[0137] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0138] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including answering, hanging up, etc.).

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

[0140] The Notification Manager allows applications to display notifications in the status bar. These messages can be displayed briefly and then disappear automatically without user interaction. For example, the Notification Manager is used to notify users of completed downloads and message reminders. The Notification Manager can also display notifications in the top status bar of the system as icons or scrolling text, such as notifications from background applications, or as dialog windows on the screen. Examples include text messages in the status bar, beeps, vibrations on electronic devices, and flashing indicator lights.

[0141] Android Runtime includes core libraries and a virtual machine. Android runtime is responsible for scheduling and management of the Android system.

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

[0143] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

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

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

[0146] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

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

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

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

[0150] Further combined with the Android system architecture shown in Figure 9, please refer to Figure 10. The container Q is in the application system layer, and the host operating system outside the container has a C or C++ application and a JAVA program. For the application 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. Assume that the user wants to open the 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 for 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 the application A based on the shared memory.

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

[0152] Please refer to Figure 11, which provides a flow chart of 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. Specifically, the method includes the following steps:

[0153] In response to the execution 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 execution for any APP;

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

[0155] In one possible manner, in response to an execution instruction for any APP, before the step of any APP constructing an access path based on the host device node, the method further includes:

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

[0157] In one possible manner, in response to an execution instruction for any APP, the steps of any APP constructing an access path based on the host device node include:

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

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

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

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

[0162] One possible approach is that, in response to a run instruction for any APP, a process of accessing a dynamic library for any APP includes:

[0163] Access the absolute path determined based on any APP's dynamic library, and access the dynamic library for any APP.

[0164] In one possible manner, in response to an execution 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 executing the execution for any APP, the method further includes:

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

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

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

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

[0169] Please refer to FIG12 , which is a structural diagram of a memory sharing device provided in an embodiment of the present application. The device 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 both the host operating system and the container operating system are Linux and its derivative systems, including:

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

[0171] The memory sharing device provided in the embodiment shown in FIG12 can be used to execute the technical solution of the method embodiment shown in FIG11 of the present application. Its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

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

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

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

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

[0176] The response module is further configured to: respond to an execution instruction for any APP, access a dynamic library for any APP; perform operations on a host device node based on the dynamic library for any APP, access shared memory for the host operating system and the container operating system, and execute the execution for any APP. The process includes:

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

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

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

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

[0181] An 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 perform the functions / steps of the above method embodiment.

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

[0183] 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" 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 embodiment or example. 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 different embodiments or examples described in the embodiments of the present invention and the features of different embodiments or examples, unless they are mutually inconsistent.

[0184] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of such features. In the description of the embodiments of the present invention, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0185] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment 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 invention includes alternative implementations in which functions may be performed out of 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 those skilled in the art to which the embodiments of the invention pertain.

[0186] 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 the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

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

[0188] 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 merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. 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.

[0189] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional units.

[0190] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection 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