Method, device, terminal and system for multiplexing main process resources

Abstract

The application relates to the technical field of resource reuse, and discloses a processing method, device, terminal and system for reusing resources of a main process, which can initialize all resources required by a slave process in the main process, such as communication resources, device state resources and service interface resources, thereby avoiding the redundant operation of repeatedly initializing resources by the slave process, and enabling the slave process to obtain an interface agent of the main process through a cross-process communication interface binding relationship, so that the resource reuse rate is significantly improved and the risk of insufficient memory is reduced; and the resources are converted into a communication interface service that can be directly called by the slave process, so that the slave process can establish a binding relationship through a cross-process mechanism and obtain a proxy object of the cross-process communication interface, that is, the transparency of cross-process calling is realized through AIDL, the slave process does not need to pay attention to underlying communication details, and only needs to call an interface method through the proxy object to complete device control and information synchronization, communication delay control is in the order of milliseconds, and the real-time performance of user interaction and device response is ensured.

Description

Technical Field

[0001] This invention relates to the field of resource reuse technology, and in particular to a processing method, apparatus, terminal and system for reusing main process resources. Background Technology

[0002] In the field of mobile application development, the integration of native Android with the Unity engine has become an important technical path for achieving complex interactive experiences.

[0003] In traditional approaches, Unity modules typically run in the same process as native Android modules, or Unity acts as the main process carrying all functionality. Both of these methods lead to severe resource redundancy issues. For example, when the Unity module and the native Bluetooth module are loaded simultaneously, repeated resource initialization (such as Bluetooth adapters and network connection pools) can cause a 40%-50% surge in peak application memory usage, significantly increasing the risk of crashes due to out-of-memory (OOM) errors. Furthermore, system resource contention (such as CPU and I / O) further reduces application stability. Some solutions attempt to run Unity as a separate process, achieving memory decoupling through process isolation. While this improves stability, due to Android's process sandbox mechanism, the Unity process cannot directly access core resources initialized by the main process (such as Bluetooth connections, network sessions, and database connections). Reinitializing these resources not only wastes resources but can also cause device control logic chaos due to multi-process resource conflicts (such as communication anomalies caused by repeated Bluetooth device connections).

[0004] Therefore, it is particularly important to propose a new resource reuse method that allows Unity to access system resources initialized by the main process while running in an independent process, thereby reducing redundant initialization and improving the running efficiency and stability of the process. Summary of the Invention

[0005] This invention provides a method, apparatus, terminal, and system for reusing main process resources, enabling a slave process (Unity) to access system resources initialized by the main process while running independently, without the need for repeated initialization, thereby improving the running efficiency and stability of the process.

[0006] The first aspect of this invention discloses a method for reusing main process resources, the method being applied to a control terminal, the control terminal having a main process installed, the method comprising: The main process initializes the target resources used by the slave processes, including communication resources, device status resources, and service interface resources. After initializing the target resource, the main process converts the target resource into a corresponding inter-process communication interface service; The main process starts the cross-process communication interface service to the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service; After detecting that the slave process has established a binding relationship with the cross-process communication interface, the master process sends the proxy object of the cross-process communication interface to the slave process.

[0007] As an optional implementation, in a first aspect of the present invention, the main process initializes the target resources used by the slave process, including: Initialize the communication adapter that connects to the controlled device; The controlled device is scanned and identified to obtain the device attribute parameters of the controlled device, and the device attribute parameters of the controlled device are stored in a predetermined device state pool; Start the inter-process communication interface service, register the inter-process communication interface service in the preset configuration file, initialize the callback interface of the inter-process communication interface service, and save the initialized callback interface instance of the inter-process communication interface service; wherein, the callback interface of the inter-process communication interface service is used to push the status parameters of the controlled device to the slave process.

[0008] As an optional implementation, in a first aspect of the present invention, the method further includes: Once a binding relationship is established between the slave process and the inter-process communication interface, the master process detects the device control request sent by the slave process through the inter-process communication interface service; wherein, the device control request carries the device control parameters of the controlled device, and the device control request is sent by the slave process to the master process through the proxy object of the inter-process communication interface; A device control command corresponding to the device control parameters is generated, and the device control command is sent to the controlled device through a communication module matched with the controlled device; wherein, the device control command is used to enable the controlled device to perform corresponding control operations.

[0009] As an optional implementation, in a first aspect of the present invention, the method further includes: When it is detected that the device status parameters of the controlled device need to be synchronized to the slave process, the master process obtains the device status parameters of the controlled device from the device status pool; wherein, the device status parameters of the controlled device include the current status parameters of the controlled device; the master process updates the real-time status parameters of the controlled device during its operation to the device status pool through a communication module matched with the controlled device; The device status parameters of the controlled device are sent to the status listener of the slave process through the callback interface of the cross-process communication interface service; wherein, the status listener of the slave process is used to synchronize the device status parameters of the controlled device to the user through the output device of the slave process.

[0010] A second aspect of the present invention discloses another method for reusing main process resources, the method being applied to a control terminal, the control terminal having slave processes installed, the method comprising: After detecting that the inter-process communication interface service has been started by the main process, the slave process initializes the communication bridge layer and sends a service binding request to the main process through the communication bridge layer by calling the communication interface proxy. The service binding request is used to request the establishment of a binding relationship with the inter-process communication interface, which corresponds to the inter-process communication interface service. The inter-process communication interface service is obtained by converting the target resource after initialization by the main process. The target resource is the resource required by the slave process for device control. After detecting that a binding relationship has been established with the inter-process communication interface, the slave process receives the proxy object of the inter-process communication interface from the main process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the inter-process communication interface from the main process.

[0011] As an optional implementation, in a second aspect of the invention, the method further includes: After detecting that the proxy object of the cross-process communication interface has been successfully obtained from the main process, the slave process determines the device control parameters required by the user for the controlled device. Based on the device control parameters, a device control request for the controlled device is generated; wherein, the device control request is used to request the main process to control the controlled device, and the device control request carries the device control parameters of the controlled device; The slave process uses the proxy object of the inter-process communication interface to send a device control request for the controlled device to the master process through the inter-process communication interface service; wherein, the device control parameters of the controlled device carried in the device control request are used by the master process to generate corresponding device control instructions, and the device control instructions are used to control the controlled device.

[0012] A third aspect of this invention discloses yet another method for reusing main process resources, the method being applied to a control terminal, the control terminal having a main process and slave processes installed, the method comprising: The main process initializes the target resources used by the slave process, including communication resources, device status resources, and service interface resources. After initializing the target resource, the target resource is converted into a corresponding cross-process communication interface service, and the cross-process communication interface service is started for the slave process; After detecting that the cross-process communication interface service has been started, the slave process initializes the communication bridge layer and sends a service binding request to the master process through the communication bridge layer by calling the communication interface proxy; wherein, the service binding request is used to request to establish a binding relationship with the cross-process communication interface; The main process generates a proxy object of the cross-process communication interface corresponding to the cross-process communication interface service based on the service binding request, and sends the proxy object of the cross-process communication interface to the communication interface proxy of the slave process through the cross-process communication interface service. The slave process receives the proxy object of the inter-process communication interface from the main process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the inter-process communication interface from the main process.

[0013] A fourth aspect of the present invention discloses a processing apparatus for reusing main process resources. The apparatus is applied to a control terminal, the control terminal having a main process installed thereon, the main process comprising: An initialization module is used to initialize the target resources used by the process, including communication resources, device status resources, and service interface resources. The conversion module is used to convert the target resource into a corresponding cross-process communication interface service after initializing the target resource; A communication module is used to start the cross-process communication interface service for the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service; The communication module is further configured to send the proxy object of the cross-process communication interface to the slave process after detecting that the slave process has established a binding relationship with the cross-process communication interface.

[0014] As an optional implementation, in a fourth aspect of the present invention, the specific method by which the initialization module initializes the target resources used by the process includes: Initialize the communication adapter that connects to the controlled device; The controlled device is scanned and identified to obtain the device attribute parameters of the controlled device, and the device attribute parameters of the controlled device are stored in a predetermined device state pool; Start the inter-process communication interface service, register the inter-process communication interface service in the preset configuration file, initialize the callback interface of the inter-process communication interface service, and save the initialized callback interface instance of the inter-process communication interface service; wherein, the callback interface of the inter-process communication interface service is used to push the status parameters of the controlled device to the slave process.

[0015] As an optional implementation, in a fourth aspect of the invention, the apparatus further includes: The detection module is used to detect device control requests sent by the slave process through the cross-process communication interface after detecting that the slave process has established a binding relationship with the cross-process communication interface; wherein the device control request carries the device control parameters of the controlled device, and the device control request is sent by the slave process to the master process through the proxy object of the cross-process communication interface; The generation module is used to generate the device control instructions corresponding to the device control parameters; The communication module is further configured to send the device control command to the controlled device through a communication module matched with the controlled device; wherein the device control command is used to enable the controlled device to perform corresponding control operations.

[0016] As an optional implementation, in a fourth aspect of the invention, the apparatus further includes: The acquisition module is used to acquire the device status parameters of the controlled device from the device status pool when it is detected that the device status parameters of the controlled device need to be synchronized to the slave process; wherein, the device status parameters of the controlled device include the current status parameters of the controlled device; the master process updates the real-time status parameters of the controlled device during its operation to the device status pool through a communication module matched with the controlled device; The communication module is further configured to send the device status parameters of the controlled device to the status listener of the slave process through the callback interface of the cross-process communication interface service; wherein, the status listener of the slave process is configured to synchronize the device status parameters of the controlled device to the user through the output device of the slave process.

[0017] The fifth aspect of this invention discloses a control terminal, wherein the control terminal has a master process and a slave process installed, and the control terminal includes: Memory containing executable program code; A processor coupled to the memory; The processor invokes the executable program code stored in the memory to execute some or all of the steps in any of the methods described in the first to third aspects of the present invention.

[0018] The sixth aspect of the present invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute some or all of the steps in any of the methods described in the first to third aspects of the present invention.

[0019] The seventh aspect of this invention discloses a resource reuse system applied to a control terminal, comprising a main process and a slave process. The main process and the slave process communicate with each other through an inter-process communication interface service. The main process is communicatively connected to a controlled device. The main process and the slave process respectively execute some or all of the steps in the methods described in any of the first to third aspects of this invention to control the controlled device and synchronize the device status parameters of the controlled device to the slave process.

[0020] Compared with the prior art, the present invention has the following beneficial effects: In this embodiment of the invention, the main process installed on the control terminal initializes the target resources used by the slave process. The target resources include communication resources, device status resources, and service interface resources. After initializing the target resources, the main process converts the target resources into corresponding cross-process communication interface services. The main process then initiates the cross-process communication interface service to the slave process. The cross-process communication interface service is used to establish a binding relationship between the slave process and the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service. After detecting that the slave process has established a binding relationship with the cross-process communication interface, the main process sends the proxy object of the cross-process communication interface to the slave process. As can be seen, this invention can initialize all the resources required by the slave process (such as communication resources, device status resources, and service interface resources, specifically such as Bluetooth adapters, device connection pools, and function management modules) through the main process installed on the control terminal, and abstract these resources into cross-process communication interface services (such as IMashService). This fundamentally avoids the redundant operation of slave processes (such as the Unity process) repeatedly initializing resources. The slave process only needs to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, which significantly improves the resource reuse rate, greatly reduces memory consumption, and effectively reduces the risk of insufficient memory. After initialization, it is converted into a communication interface service that the slave process can directly call, so that the slave process can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. The slave process does not need to pay attention to the underlying communication details. It only needs to call the interface method through the proxy object to complete the device control (such as adjusting the brightness of the light). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a method for reusing main process resources disclosed in an embodiment of the present invention; Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of the present invention; Figure 3 This is a flowchart illustrating another method for reusing main process resources disclosed in an embodiment of the present invention. Figure 4 This is a flowchart illustrating another method for reusing main process resources disclosed in an embodiment of the present invention. Figure 5 This is a schematic diagram of the structure of a processing device for reusing main process resources disclosed in an embodiment of the present invention; Figure 6 This is a schematic diagram of another processing device for reusing main process resources disclosed in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of another processing device for reusing main process resources disclosed in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of another processing device for reusing main process resources disclosed in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a control terminal disclosed in an embodiment of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0024] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand, explicitly and implicitly, that the embodiments described herein can be combined with other embodiments.

[0026] This invention discloses a method, apparatus, terminal, and system for reusing resources in the main process. In the main process, all resources required by the slave process (such as communication resources, device status resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) are initialized, and these resources are abstracted into cross-process communication interface services (such as IMashService). This fundamentally avoids redundant resource initialization operations in slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse rate, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, these resources are converted into communication interface services that slave processes can directly call, allowing slave processes to establish binding relationships and obtain the proxy object of the cross-process communication interface through the cross-process mechanism. This achieves transparency in cross-process calls through AIDL, eliminating the need for slave processes to concern themselves with underlying communication details. They only need to call interface methods through the proxy object to complete device control (such as adjusting light brightness), with communication latency controlled at the millisecond level, ensuring real-time user interaction and device response. Detailed explanations follow.

[0027] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for reusing main process resources disclosed in an embodiment of the present invention. Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of the present invention. Figure 1-2 The described method can be applied to scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios. Furthermore, this method is applied to a control terminal, which has a master process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 2 The present invention will be described as follows: Figure 1 As shown, the method may include the following operations: 101. The main process initializes the target resources used by the slave processes, including communication resources, device status resources, and service interface resources.

[0028] In embodiments of the present invention, such as Figure 2As shown, the main process (such as the Android native process or the iOS native process) corresponds to the server, and the slave processes (such as the Unity 3D process) correspond to the client. The server and client together form the control terminal. The number of slave processes can be greater than or equal to one, and resource reuse can be performed using the method of this invention for any slave process. Communication resources include, but are not limited to, wired or wireless communication resources. Wireless communication resources include one of Bluetooth, NFC, WiFi, or ZigBee communication resources, specifically determined by the communication method between the controlled device and the main process. Device status resources are specifically determined by the type of controlled device. For example, for a smart lighting control device, device status resources include the device's on / off status, brightness, color, light effect, identifier, and MAC address.

[0029] 102. After initializing the target resource, the main process converts the target resource into the corresponding inter-process communication interface service.

[0030] In this embodiment of the invention, the main process abstracts the target resource into a standardized cross-process communication interface service, such as IMashService (i.e., AIDL service), through a cross-process communication interface language (such as Android Interface Definition Language AIDL).

[0031] 103. The main process starts the cross-process communication interface service to the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service.

[0032] 104. After detecting that a binding relationship has been established between the slave process and the cross-process communication interface, the master process sends the proxy object of the cross-process communication interface to the slave process.

[0033] In this embodiment of the invention, the main process starts an inter-process communication interface service for the slave process, that is, exposes the inter-process communication interface to the slave process. At this time, if the slave process detects that the inter-process communication interface service has been started by the main process, it starts to initialize the communication bridge layer, such as AndroidBridge, and calls the communication interface proxy, such as BluetoothProxy, through the communication bridge layer to send a service binding request to the main process. The main process generates a proxy object of the inter-process communication interface corresponding to the inter-process communication interface service according to the service binding request, and sends the proxy object of the inter-process communication interface to the communication interface proxy of the slave process through the inter-process communication interface service. The slave process then receives the proxy object of the inter-process communication interface from the main process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy. The binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the inter-process communication interface from the main process. That is, the slave process can then directly reuse the target resources that the main process has initialized through the inter-process communication interface service via the proxy object while running independently.

[0034] It is evident that implementation Figure 1 The described method initializes all resources required by the slave process (such as communication resources, device state resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) in the main process and abstracts these resources into cross-process communication interface services (such as IMashService). This fundamentally avoids redundant operations of repeated resource initialization by slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that slave processes can directly call, so that slave processes can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. Slave processes do not need to pay attention to the underlying communication details. They only need to call the interface method through the proxy object to complete device control (such as adjusting the brightness of lights). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response.

[0035] In this embodiment of the invention, optionally, the main process initializes the target resources used by the slave process, including: Initialize the communication adapter that connects to the controlled device; The controlled device is scanned and identified to obtain its device attribute parameters, which are then stored in a pre-defined device state pool, such as DevicePool. Start the cross-process communication interface service, register the cross-process communication interface service in the preset configuration file, and initialize the callback interface of the cross-process communication interface service. Save the initialized callback interface instance of the cross-process communication interface service. The callback interface of the cross-process communication interface service is used to push the status parameters of the controlled device to the slave process.

[0036] In this embodiment of the invention, after the application starts, the main process first loads the application class and initializes global configurations, such as the database and network framework. It then calls the communication manager to obtain the communication adapter for initialization. Different communication resources correspond to different communication managers and adapters; for example, Bluetooth communication resources correspond to a Bluetooth manager and adapter. After the communication adapter is initialized, the corresponding communication method scan is initiated, such as the Bluetooth module communication scan, to search for nearby controlled devices and establish communication connections with them. Furthermore, through the corresponding communication protocol, such as the GATT protocol, the device control interface is obtained to acquire device attribute parameters of the controlled devices, such as device identifier and MAC address (see the description of device state resources above). These device attribute parameters are then stored in the device state pool. Next, the main process starts an inter-process communication (IPC) interface service, such as IMESHService, as the entry point for IPC. It registers the IPC interface service in a pre-defined configuration file to ensure the Unity process can bind to the service. It also initializes the callback interfaces of the IPC interface service, such as IMESHCallback (used to push device state changes to slave processes). The initialized callback interface instance is saved for subsequent calls when state changes occur. The callback interfaces of the IPC interface service are used to push the status parameters of the controlled device to slave processes. The pre-defined configuration file is used to declare basic application information, components (such as Activities and Services), communication permissions, process configurations, etc.

[0037] As can be seen, in implementing this embodiment of the invention, the main process first completes the initialization of the communication adapter (such as a Bluetooth adapter), then scans and identifies the controlled device and stores its device attribute parameters in the device state pool, completing the initialization of device state resources. Finally, it initializes the cross-process communication interface, completing the initialization of all resources required by the slave process. This improves the efficiency and comprehensiveness of resource initialization. The slave process does not need to repeatedly perform redundant operations such as device scanning and connection, and can directly reuse the communication resources already established by the main process, greatly reducing memory usage and effectively reducing the risk of insufficient memory. Furthermore, by obtaining the interface proxy object through the binding service, low-latency control of the controlled device is achieved, with communication latency controlled at the millisecond level. When the device state changes, the main process actively pushes the state to the slave process through the callback interface, and the slave process synchronously updates the device state, ensuring that the virtual model is consistent with the real device state.

[0038] In an optional embodiment, the method may further include the following steps: Once a binding relationship is established between a process and the inter-process communication interface, the main process detects the device control request sent by the process through the inter-process communication interface service. The device control request carries the device control parameters of the controlled device and is sent from the process to the main process through the proxy object of the inter-process communication interface. The main process generates device control commands corresponding to the device control parameters and sends the device control commands to the controlled device through a communication module that matches the controlled device, such as a Bluetooth module; the device control commands are used to enable the controlled device to perform corresponding control operations.

[0039] In this optional embodiment, after successfully obtaining the proxy object of the cross-process communication interface from the main process, the slave process determines the device control parameters required by the user for the controlled device, and generates a device control request for the controlled device based on the device control parameters. The device control request is used to request control of the controlled device, and the device control request carries the device control parameters of the controlled device. For example, for the control of smart lamps, there is a virtual lamp on the slave process that completely corresponds to the actual layout of the smart lamp, which is displayed to the user. The control operation triggered by the user on the virtual lamp on the interactive interface, such as brightness sliding, is detected to obtain the brightness control parameters. Then, the proxy object of the cross-process communication interface is used to send the device control request for the controlled device to the main process through the cross-process communication interface service.

[0040] As can be seen, in implementing this optional embodiment, after the process establishes a binding relationship, it sends a device control request to the main process through a proxy object of the cross-process communication interface, carrying device control parameters, such as the brightness value of a smart lamp. The main process's cross-process communication interface service detects and parses the request in real time, generates standardized device control instructions, and then accurately sends them to the controlled device through a communication module, such as a Bluetooth module. There is no need for the slave process to repeatedly initialize communication resources. The slave process directly reuses the resources that the main process has already initialized to control the controlled device, reducing the device control latency to the millisecond level.

[0041] In another alternative embodiment, the method may further include the following steps: When the master process detects that it needs to synchronize the device status parameters of the controlled device with the slave process, it obtains the device status parameters of the controlled device from the device status pool. The device status parameters of the controlled device include the current status parameters of the controlled device. The master process updates the real-time status parameters of the controlled device during its operation to the device status pool through the communication module matched with the controlled device. The device status parameters of the controlled device are sent to the status listener of the slave process, such as StateListener, through the callback interface of the cross-process communication interface service, such as IMashCallback. The status listener of the slave process is used to synchronize the device status parameters of the controlled device with the user through the output device of the slave process (such as interactive interface, voice recognition, etc.).

[0042] In this optional embodiment, optionally, after the controlled device receives a device control command, it executes a control operation matching the device control command, obtains the corresponding device status parameters, and stores them in the device status pool. Further optionally, when the slave process sends a device status acquisition request to the master process through the cross-process communication interface service, or when the device status pool detects that the controlled device has updated new status parameters to the device status pool, it indicates that the device status parameters of the controlled device need to be synchronized with the slave process. Further optionally, the status listener synchronizes the current status parameters of the controlled device to the user through the output device of the slave process. This can be understood as directly outputting the device status parameters of the controlled device to the user through an interactive interface or voice recognition device, or it can be understood as driving the controlled device in a virtual device scene within the slave process based on the received device status parameters, and then realistically presenting that scene to the user through an interactive interface, such as the display effect of a 3D scene of smart lighting, achieving virtual-real synchronization.

[0043] As can be seen, in implementing this optional embodiment, the main process continuously receives real-time status parameters of the controlled device and dynamically updates them to the device status pool, ensuring that the data in the pool is completely synchronized with the real device status. When it is necessary to synchronize the status with the slave process, the main process actively pushes the current status parameters to the status listener of the slave process through the callback interface of the cross-process communication interface service. After receiving the parameters, the status listener directly feeds back the device status (such as brightness value, on / off status) to the user through the interactive interface of the slave process, and drives the virtual device scene update of the slave process (such as the brightness change of the 3D lighting model), realizing virtual-real synchronization. This eliminates the resource consumption of the slave process repeatedly polling the status, and ensures that the status update delay is controlled within milliseconds through asynchronous push. At the same time, the main process uniformly maintains the device status pool, reducing cross-process data redundancy, reducing memory resource consumption, and greatly reducing the risk of insufficient memory.

[0044] In another optional embodiment, the device state pool may correspond to multiple controlled devices, i.e., the main process manages the device state parameters of multiple controlled devices, and the process's interactive interface contains 3D scene-based digital twin models of these multiple controlled devices for real-time synchronization of the real state of the controlled devices. In this case, the method may further include the following steps: The process detects intelligent linkage operations triggered by the user on the interactive interface for multiple controlled virtual devices, pops up the corresponding parameter configuration interface based on the intelligent linkage operations, and detects the critical adjustment parameters triggered by the user on the parameter configuration interface for multiple virtual devices. From the critical adjustment parameters corresponding to multiple virtual devices, the main critical adjustment parameter and the secondary critical adjustment parameter are selected. The main critical adjustment parameter is used to indicate that the state of the corresponding controlled device is adjusted according to the secondary critical adjustment parameter only when the real-time state parameter of the corresponding controlled device reaches the main critical adjustment parameter. Based on the main critical adjustment parameters and the corresponding virtual device identifier, the slave critical adjustment parameters and the corresponding virtual device identifier, an intelligent linkage control request is generated and sent to the cross-process communication interface service of the main process through the proxy object. The intelligent linkage control request includes the main critical adjustment parameters and the corresponding virtual device identifier, the slave critical adjustment parameters and the corresponding virtual device identifier. The main process receives intelligent linkage control requests, stores the content of the requests in a local database, sets an enable flag, and identifies the corresponding master controlled device using the identifier of the virtual device corresponding to the master critical adjustment parameter. It then communicates with the master controlled device via its communication method (e.g., Bluetooth or NFC) to obtain its real-time status parameters. When the real-time status parameters of the master controlled device reach the master critical adjustment parameter, a status adjustment command is generated based on the master critical adjustment parameter, the slave critical adjustment parameter, and the identifier of their respective virtual devices. This command is then sent to the corresponding controlled device via the appropriate communication method, allowing the device to perform the corresponding adjustment operation. After any controlled device completes its adjustment, the adjusted device status parameters are updated in the device status pool.

[0045] The updated device status parameters of multiple controlled devices are obtained from the device status pool and called back to the status listener of the slave process through the callback interface of the cross-process communication interface service. The status listener corresponding to each controlled device is used to display a virtual scene to the user through the interactive interface of the slave process, which is consistent with the actual state of the device status parameters of the controlled device after adjustment.

[0046] The optional implementation will be illustrated with a scenario-based example, specifically: The process detects that user Xiao Li enters the living room 3D digital twin scene through the Unity 3D APP on his mobile phone, clicks the smart linkage button to configure rules, selects the temperature and humidity sensor as the trigger source, sets the temperature >28℃ as the main critical condition, and associates two actions: adjusting the brightness of the living room light group (ceiling light A, floor lamp B) to 30% and turning on the smart air conditioner and adjusting it to 24℃. After clicking save, the slave process sends the device adjustment parameters to the Android main process through the proxy object via the cross-process communication interface service; the main process stores the device adjustment parameters in the local database and sets the enable flag, and at the same time connects to the temperature and humidity sensor via Bluetooth, receiving temperature data every 2 seconds. When the temperature rises to 29℃, the sensor reports data via Bluetooth. After the main process matches the trigger condition, it sends a brightness adjustment command to the living room lighting group via the Bluetooth Mesh protocol and an on command to the air conditioner via the Bluetooth GATT protocol. When the brightness of the lighting group drops to 30% and the air conditioner starts, the status is fed back to the main process via Bluetooth. The main process updates the device state pool and synchronizes the latest status to the Unity 3D state listener through the callback interface of the cross-process communication interface service. Finally, the virtual lighting model in the 3D scene dims, the air conditioner model shows that it is running, and a linkage prompt pops up on the screen, realizing a smart control closed loop with consistent virtual and real status.

[0047] As can be seen, in implementing this optional embodiment, the main process manages the real-time device parameters of multiple controlled devices through a unified device state pool, combines local database storage of linkage rules and sets enable flags to ensure rule persistence and traceability; and the slave process uses a 3D scene-based digital twin model to build an intuitive interactive interface, allowing users to trigger linkage operations through virtual devices, and automatically filter main and slave critical adjustment parameters to generate intelligent linkage control requests containing device identifiers and parameters, which are transmitted across processes to the main process's cross-process communication interface service AIDLService through an AIDL proxy object; the main process monitors the real-time status of the main controlled device based on rules, and when the status reaches the main critical value, it dynamically generates a status adjustment command and sends it to the slave controlled device, updates the device state pool after completion, and synchronizes the latest status to the slave process's status listener through a callback interface, ultimately achieving consistent virtual and real status visualization feedback in the 3D scene. AIDL enables the reuse of main process resources and low-latency data interaction between main and slave processes, reduces blocking of slave process rendering threads, improves cross-process communication efficiency, and supports combined logic of multiple controlled devices (such as triggering by the main controlled device and executing by the slave controlled device) to meet the needs of complex scenarios. Furthermore, by synchronizing the status of real devices in real time through a digital twin model, users can intuitively perceive the linkage effect, thus improving the user experience.

[0048] Example 2 Please see Figure 3 , Figure 3This is a flowchart illustrating another method for reusing main process resources disclosed in an embodiment of the present invention. Figure 3 The described method can be applied to scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios. This method is applied to a control terminal, which has a master process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 3 As shown, the method may include the following operations: 201. After detecting that the cross-process communication interface service has been started by the main process, the slave process initializes the communication bridge layer and sends a service binding request to the main process by calling the communication interface proxy through the communication bridge layer. The service binding request is used to request the establishment of a binding relationship with the cross-process communication interface. The cross-process communication interface corresponds to the cross-process communication interface service. The cross-process communication interface service is converted from the target resource after being initialized by the main process. The target resource is the resource required by the slave process for device control.

[0049] In this embodiment of the invention, after receiving a service binding request, the main process generates a proxy object of the cross-process communication interface corresponding to the cross-process communication interface service, and sends the proxy object of the cross-process communication interface to the communication interface proxy of the slave process through the cross-process communication interface service.

[0050] 202. After detecting that a binding relationship has been established with the cross-process communication interface, the slave process receives the proxy object of the cross-process communication interface from the master process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the cross-process communication interface from the master process.

[0051] It is evident that implementation Figure 3The described method initializes all resources required by the slave process (such as communication resources, device state resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) in the main process and abstracts these resources into cross-process communication interface services (such as IMashService). This fundamentally avoids redundant operations of repeated resource initialization by slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that slave processes can directly call, so that slave processes can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. Slave processes do not need to pay attention to the underlying communication details. They only need to call the interface method through the proxy object to complete device control (such as adjusting the brightness of lights). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response.

[0052] In an optional embodiment, the method may further include the following steps: After detecting that the proxy object of the cross-process communication interface has been successfully obtained from the main process, the process determines the device control parameters required by the user for the controlled device. Based on the equipment control parameters, a device control request for the controlled device is generated; wherein, the device control request is used to request control of the controlled device, and the device control request carries the equipment control parameters of the controlled device; The proxy object using the inter-process communication interface sends a device control request for the controlled device to the main process through the inter-process communication interface service; wherein, the device control parameters of the controlled device carried in the device control request are used by the main process to generate corresponding device control instructions, which are used to control the controlled device.

[0053] In this optional embodiment, the device control parameters of the controlled device carried in the device control request are used by the main process to generate device control instructions corresponding to the device control parameters and send the device control instructions to the controlled device so that the controlled device can perform the corresponding control operation after receiving the device control instructions.

[0054] As can be seen, after obtaining the proxy object from the main process, this optional embodiment sends a device control request carrying device control parameters (such as the brightness value of a smart lamp) to the main process through the proxy object of the cross-process communication interface. The cross-process communication interface service of the main process detects and parses the request in real time, generates standardized device control instructions, and then accurately sends them to the controlled device through a communication module, such as a Bluetooth module. There is no need for the process to repeatedly initialize communication resources. The process directly reuses the resources that the main process has already initialized to control the controlled device, reducing the device control latency to the millisecond level.

[0055] It should be noted that, for other descriptions of the main process and the slave process in Embodiment 2, please refer to the detailed description of the relevant content in Embodiment 1 above, and will not be repeated here.

[0056] Example 3 Please see Figure 4 , Figure 4 This is a flowchart illustrating another method for reusing main process resources disclosed in an embodiment of the present invention. Figure 4 The described method can be applied to scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios. This method is applied to a control terminal, which has a master process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 4 As shown, the method may include the following operations: 301. The main process initializes the target resources used by the slave processes. The target resources include communication resources, device status resources, and service interface resources.

[0057] 302. After initializing the target resource, convert the target resource into the corresponding cross-process communication interface service, and start the cross-process communication interface service for the slave process.

[0058] 303. After detecting that the cross-process communication interface service has been started, the process initializes the communication bridge layer and sends a service binding request to the main process by calling the communication interface proxy through the communication bridge layer; wherein, the service binding request is used to request to establish a binding relationship with the cross-process communication interface.

[0059] 304. Based on the service binding request, the main process generates a proxy object for the cross-process communication interface corresponding to the cross-process communication interface service, and sends the proxy object of the cross-process communication interface to the communication interface proxy of the slave process through the cross-process communication interface service.

[0060] 305. The slave process receives the proxy object of the cross-process communication interface from the master process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the cross-process communication interface from the master process.

[0061] It is evident that implementation Figure 4 The described method initializes all resources required by the slave process (such as communication resources, device state resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) in the main process and abstracts these resources into cross-process communication interface services (such as IMashService). This fundamentally avoids redundant operations of repeated resource initialization by slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that slave processes can directly call, so that slave processes can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. Slave processes do not need to pay attention to the underlying communication details. They only need to call the interface method through the proxy object to complete device control (such as adjusting the brightness of lights). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response.

[0062] It should be noted that, for other descriptions of the main process and the slave process in Embodiment 3, please refer to the detailed descriptions of the relevant content in Embodiments 1 and 2 above, and will not be repeated here.

[0063] Example 4 Taking stage lighting control as an example, this invention's native Android and Unity cross-process integration solution is explained. Specifically, a smartphone is used as the control terminal to control the stage lighting. The smartphone has a smart lighting control server (main process) installed for the stage lighting control scenario, and a 3D lighting control app installed as a slave process. The smart lighting control server is the central control box for the stage lighting scenario, responsible for managing Bluetooth connections, the status of all smart lights (such as on / off, brightness, and color), and providing AIDL cross-process communication interface services, i.e., providing services such as checking and adjusting lights. The Unity slave process displays a 3D lighting model, allowing users to adjust lighting parameters by clicking / sliding the model. The model needs to be synchronized with the real bulb status in real time. Specifically: Step 1: After the main process starts, initialize the Bluetooth adapter corresponding to the smart lamp, scan and connect to the smart lamp, store the identifiers, types, MC addresses, etc. of the connected smart lamps in the device status pool DevicePool (Map<MAC address, smart lamp status object>). At the same time, start the Bluetooth control import service IMeshService (AIDL service) to expose the Bluetooth control interface, so as to complete the initialization of Bluetooth, lamp status and Bluetooth control interface.

[0064] Step 2: After the Unity process starts, load the 3D lighting scene of the smart lamp, and call the Bluetooth proxy BluetoothProxy (AIDL proxy) through the bridge connection layer AndroidBridge (C# class), bind the Bluetooth control interface service IMeshService of the main process, and obtain the proxy object of the Bluetooth control interface.

[0065] Step 3: The Unity process detects the brightness control operation triggered by the user on the virtual lamp (i.e., 3D lamp model) of the smart lamp on its interaction interface, obtains the brightness control parameters of the smart lamp, generates a corresponding brightness control request based on the brightness control parameters, and then uses AndroidJavaObject to call the setBrightness(MAC address, 40%) method of the Bluetooth proxy BluetoothProxy through its bridge connection layer AndroidBridge. The Bluetooth proxy BluetoothProxy sends the brightness control request to the Bluetooth control interface service IMeshService of the main process through the cross-process Binder mechanism.

[0066] Step 4: The main process receives the brightness control request through the Bluetooth control interface service IMeshService, and forwards the brightness control request to the Bluetooth manager BluetoothManager. The Bluetooth manager BluetoothManager sends a brightness adjustment instruction to the smart lamp through the connected Bluetooth channel. After the smart lamp adjusts its brightness, it updates its brightness and other statuses to the device status pool DevicePool.

[0067] Step 5: The main process detects the status change of the smart lamp through its device status pool DevicePool, and pushes the brightness status of the smart lamp to the status listener StateListener of the Unity process through the callback interface IMeshCallback of the Bluetooth control interface service; Step 6: The status listener StateListener of the Unity process receives the zero brightness status update, and drives the virtual lamp 3D model of the smart lamp to adjust the brightness display to achieve virtual-real synchronization.

[0068] As can be seen, the method described in this invention initializes all resources required by the Unity process, such as Bluetooth connection resources, lighting status resources, and service interface resources, in the main process, and abstracts these resources into Bluetooth control interface services. This fundamentally avoids redundant resource initialization operations by the Unity process. The Unity process only needs to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that can be directly called by the slave process, so that the Unity process can establish a binding relationship and obtain the proxy object of the cross-process communication interface through the cross-process mechanism. That is, it achieves transparency of cross-process calls through AIDL, and the slave process has no... Attention must be paid to the underlying communication details. Light control (such as adjusting light brightness) can be completed simply by calling interface methods through a proxy object. Communication latency is controlled at the millisecond level to ensure real-time user interaction and device response. The main process continuously receives real-time status parameters of the smart lights and dynamically updates them to the device state pool to ensure that the data in the pool is completely synchronized with the smart light status. The main process pushes the current status parameters of the smart lights to the state listener of the Unity process through the callback interface of the cross-process communication interface service. After receiving the parameters, the state listener directly feeds back the status of the smart lights to the user through the interactive interface of the Unity process, and drives the virtual device scene update of the Unity process to achieve virtual-real synchronization without the resource consumption of repeated state polling by the Unity process.

[0069] It should be noted that, for other descriptions of the main process and the slave process in Embodiment 4, please refer to the detailed descriptions of the relevant content in Embodiments 1-3 above, and will not be repeated here.

[0070] Example 5 Please see Figure 5 , Figure 5 This is a schematic diagram of a processing device for reusing main process resources disclosed in an embodiment of the present invention. Figure 5 The described device is applied in scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios. The device is applied to a control terminal, which has a main process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 5 As shown, the device may include: Initialization module 401 is used to initialize the target resources used by the process, including communication resources, device status resources and service interface resources. The conversion module 402 is used to convert the target resource into the corresponding cross-process communication interface service after initialization. The communication module 403 is used to start a cross-process communication interface service for the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service; The communication module 403 is also used to send the proxy object of the cross-process communication interface to the slave process after detecting that a binding relationship has been established between the slave process and the cross-process communication interface.

[0071] It is evident that implementation Figure 5 The described device initializes all resources required by the slave process (such as communication resources, device state resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) in the main process. These resources are then abstracted into cross-process communication interface services (such as IMashService), fundamentally avoiding redundant resource initialization operations in slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that slave processes can directly call, so that slave processes can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. Slave processes do not need to pay attention to the underlying communication details, but only need to call the interface method through the proxy object to complete device control (such as adjusting light brightness). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response.

[0072] In this embodiment of the invention, optionally, the initialization module 401 initializes the target resources used by the process in the following ways: Initialize the communication adapter that connects to the controlled device; The controlled equipment is scanned and identified to obtain the equipment attribute parameters of the controlled equipment, and the equipment attribute parameters of the controlled equipment are stored in a pre-determined equipment status pool; Start the cross-process communication interface service, register the cross-process communication interface service in the preset configuration file, and initialize the callback interface of the cross-process communication interface service. Save the initialized callback interface instance of the cross-process communication interface service. The callback interface of the cross-process communication interface service is used to push the status parameters of the controlled device to the slave process.

[0073] It is evident that implementation Figure 5The described device's main process first initializes the communication adapter (such as a Bluetooth adapter), then scans and identifies the controlled device and stores its device attribute parameters in the device state pool, completing the initialization of device state resources. Finally, it initializes the cross-process communication interface, completing the initialization of all resources required by the slave process. This improves the efficiency and comprehensiveness of resource initialization. The slave process does not need to repeatedly perform redundant operations such as device scanning and connection, and can directly reuse the communication resources already established by the main process, greatly reducing memory usage and effectively reducing the risk of insufficient memory. Furthermore, by obtaining the interface proxy object through the binding service, low-latency control of the controlled device is achieved, with communication latency controlled at the millisecond level. When the device state changes, the main process actively pushes the state to the slave process through the callback interface, and the slave process synchronously updates the device state, ensuring that the virtual model is consistent with the real device state.

[0074] In an optional embodiment, such as Figure 6 As shown, the device may also include; The detection module 404 is used to detect device control requests sent by the process through the cross-process communication interface service after a binding relationship is established between the process and the cross-process communication interface. The device control request carries the device control parameters of the controlled device and is sent from the process to the main process through the proxy object of the cross-process communication interface. The generation module 405 is used to generate equipment control instructions corresponding to the equipment control parameters; The communication module 403 is also used to send device control commands to the controlled device through a communication module matched with the controlled device; wherein the device control commands are used to enable the controlled device to perform corresponding control operations.

[0075] It is evident that implementation Figure 6 The described device, after establishing a binding relationship, sends a device control request to the main process through a proxy object of the cross-process communication interface, carrying device control parameters, such as the brightness value of a smart lamp. The main process's cross-process communication interface service detects and parses the request in real time, generates standardized device control commands, and then accurately sends them to the controlled device through a communication module, such as a Bluetooth module. There is no need for the slave process to repeatedly initialize communication resources. The slave process directly reuses the resources already initialized by the main process to control the controlled device, reducing the device control latency to the millisecond level.

[0076] In another alternative embodiment, such as Figure 6 As shown, the device may further include: The acquisition module 406 is used to acquire the device status parameters of the controlled device from the device status pool when it is detected that the device status parameters of the controlled device need to be synchronized to the slave process; wherein, the device status parameters of the controlled device include the current status parameters of the controlled device; the master process updates the real-time status parameters of the controlled device during its operation to the device status pool through the communication module matched with the controlled device; The communication module 403 is also used to send the device status parameters of the controlled device to the status listener of the slave process through the callback interface of the cross-process communication interface service. The status listener of the slave process is used to synchronize the device status parameters of the controlled device to the user through the output device of the slave process.

[0077] It is evident that implementation Figure 6 The described device's main process continuously receives real-time status parameters from the controlled devices and dynamically updates them to the device state pool, ensuring complete synchronization between the pool's data and the actual device state. When it's necessary to synchronize the state with the slave processes, the main process actively pushes the current status parameters to the slave process's state listener via the callback interface of the cross-process communication service. After receiving the parameters, the state listener directly provides feedback on the device state (such as brightness value and on / off status) to the user through the slave process's interactive interface. Simultaneously, it drives updates to the slave process's virtual device scene (such as brightness changes in the 3D lighting model), achieving virtual-real synchronization. This eliminates the resource consumption of repeated state polling by the slave processes and ensures that state update latency is controlled within milliseconds through asynchronous pushes. Furthermore, the main process uniformly maintains the device state pool, reducing cross-process data redundancy, minimizing memory resource consumption, and significantly reducing the risk of memory shortages.

[0078] Example 6 Please see Figure 7 , Figure 7 This is a schematic diagram of another processing device for reusing main process resources disclosed in an embodiment of the present invention. Figure 7 The described device is applied in scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios. The device is applied to a control terminal, which has a main process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 7 As shown, the device may include: The target initialization module 501 is used to initialize the communication bridge layer of the slave process after detecting that the cross-process communication interface service has been started by the main process, and send a service binding request to the main process by calling the communication interface proxy through the communication bridge layer. The service binding request is used to request to establish a binding relationship with the cross-process communication interface. The cross-process communication interface corresponds to the cross-process communication interface service. The cross-process communication interface service is converted from the target resource after being initialized by the main process. The target resource is the resource required by the slave process to control the device.

[0079] In this embodiment of the invention, after receiving a service binding request, the main process generates a proxy object of the cross-process communication interface corresponding to the cross-process communication interface service, and sends the proxy object of the cross-process communication interface to the communication interface proxy of the slave process through the cross-process communication interface service.

[0080] The target communication module 502 is used to receive the proxy object of the cross-process communication interface from the main process through the communication interface proxy after detecting that a binding relationship has been established with the cross-process communication interface, and to send a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the process has successfully obtained the proxy object of the cross-process communication interface from the main process.

[0081] It is evident that implementation Figure 7 The described device initializes all resources required by the slave process (such as communication resources, device state resources, and service interface resources, specifically Bluetooth adapters, device connection pools, and function management modules) in the main process. These resources are then abstracted into cross-process communication interface services (such as IMashService), fundamentally avoiding redundant resource initialization operations in slave processes (such as the Unity process). Slave processes only need to obtain the interface proxy of the main process through the cross-process communication interface binding relationship, significantly improving resource reuse, greatly reducing memory consumption, and effectively reducing the risk of insufficient memory. After initialization, it is converted into a communication interface service that slave processes can directly call, so that slave processes can establish a binding relationship through the cross-process mechanism and obtain the proxy object of the cross-process communication interface. That is, the cross-process call is made transparent through AIDL. Slave processes do not need to pay attention to the underlying communication details, but only need to call the interface method through the proxy object to complete device control (such as adjusting light brightness). The communication latency is controlled at the millisecond level, ensuring the real-time performance of user interaction and device response.

[0082] In an optional embodiment, such as Figure 8 As shown, the device may further include: The determination module 503 is used to determine the device control parameters required by the user for the controlled device after detecting that the proxy object of the cross-process communication interface has been successfully obtained from the main process. The target generation module 504 is used to generate a device control request for the controlled device based on the device control parameters. The device control request is used to request control of the controlled device and carries the device control parameters of the controlled device. The target communication module 502 is further configured to use a proxy object of the cross-process communication interface to send a device control request for the controlled device to the main process through the cross-process communication interface service; wherein, the device control parameters of the controlled device carried in the device control request are used by the main process to generate corresponding device control instructions, which are used to control the controlled device.

[0083] It is evident that implementation Figure 8 After obtaining the proxy object from the main process, the described device sends a device control request carrying device control parameters (such as the brightness value of a smart lamp) to the main process through the proxy object of the cross-process communication interface. The cross-process communication interface service of the main process detects and parses the request in real time, generates standardized device control instructions, and then accurately sends them to the controlled device through a communication module, such as a Bluetooth module. There is no need for the process to repeatedly initialize communication resources. The process can directly reuse the resources that have been initialized by the main process to control the controlled device, reducing the device control latency to the millisecond level.

[0084] Example 7 Please see Figure 9 , Figure 9 This is a schematic diagram of a control terminal disclosed in an embodiment of the present invention. The control terminal can be applied to scenarios requiring resource reuse, such as smart home scenarios and stage lighting control scenarios, and has a main process and slave processes installed. The control terminal can be any smart terminal with control functions, such as a smartphone, smart tablet, or smartwatch. Figure 9 As shown, the control terminal may include: Memory 601 storing executable program code; Processor 602 coupled to memory 601; The processor 602 calls the executable program code stored in the memory 601 to execute some or all of the steps in any of the processing methods for reusing main process resources disclosed in Embodiments 1 to 4 of the present invention.

[0085] Example 8 This invention discloses a computer storage medium storing computer instructions. When these computer instructions are invoked, they are used to execute some or all of the steps in any of the processing methods for reusing main process resources disclosed in Embodiments 1 to 4 of this invention.

[0086] Example 9 This invention discloses a resource reuse system, which is applied to a control terminal. The control terminal has a main process and a slave process installed. The main process and the slave process communicate with each other through an inter-process communication interface service. The main process communicates with the controlled device. The main process and the slave process respectively execute the matching steps in any of the processing methods for reusing the main process resources disclosed in Embodiments 1 to 4 of this invention to control the controlled device and synchronize the device status parameters of the controlled device to the slave process.

[0087] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0088] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0089] Finally, it should be noted that the above embodiments are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for reusing main process resources, the method being applied to a control terminal, characterized in that, The control terminal has a main process installed, and the method includes: The main process initializes the target resources used by the slave processes, including communication resources, device status resources, and service interface resources. After initializing the target resource, the main process converts the target resource into a corresponding inter-process communication interface service; The main process starts the cross-process communication interface service to the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service; After detecting that the slave process has established a binding relationship with the cross-process communication interface, the master process sends the proxy object of the cross-process communication interface to the slave process.

2. The method according to claim 1, characterized in that, The main process initializes the target resources used by the slave processes, including: Initialize the communication adapter that connects to the controlled device; The controlled device is scanned and identified to obtain the device attribute parameters of the controlled device, and the device attribute parameters of the controlled device are stored in a pre-determined device state pool; Start the inter-process communication interface service, register the inter-process communication interface service in the preset configuration file, initialize the callback interface of the inter-process communication interface service, and save the initialized callback interface instance of the inter-process communication interface service; wherein, the callback interface of the inter-process communication interface service is used to push the device status parameters of the controlled device to the slave process.

3. The method according to claim 2, characterized in that, The method further includes: Once a binding relationship is established between the slave process and the inter-process communication interface, the master process detects the device control request sent by the slave process through the inter-process communication interface service; wherein, the device control request carries the device control parameters of the controlled device, and the device control request is sent by the slave process to the master process through the proxy object of the inter-process communication interface; A device control command corresponding to the device control parameters is generated, and the device control command is sent to the controlled device through a communication module matched with the controlled device; wherein, the device control command is used to enable the controlled device to perform corresponding control operations.

4. The method according to claim 3, characterized in that, The method further includes: When it is detected that the device status parameters of the controlled device need to be synchronized to the slave process, the master process obtains the device status parameters of the controlled device from the device status pool; wherein, the device status parameters of the controlled device include the current status parameters of the controlled device; the master process updates the real-time status parameters of the controlled device during its operation to the device status pool through a communication module matched with the controlled device; The device status parameters of the controlled device are sent to the status listener of the slave process through the callback interface of the cross-process communication interface service; wherein, the status listener of the slave process is used to synchronize the device status parameters of the controlled device to the user through the output device of the slave process.

5. A method for reusing main process resources, the method being applied to a control terminal, characterized in that, The control terminal has a slave process installed, and the method includes: After detecting that the inter-process communication interface service has been started by the main process, the slave process initializes the communication bridge layer and sends a service binding request to the main process through the communication bridge layer by calling the communication interface proxy. The service binding request is used to request the establishment of a binding relationship with the inter-process communication interface, which corresponds to the inter-process communication interface service. The inter-process communication interface service is obtained by converting the target resource after initialization by the main process. The target resource is the resource required by the slave process for device control. After detecting that a binding relationship has been established with the inter-process communication interface, the slave process receives the proxy object of the inter-process communication interface from the main process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the inter-process communication interface from the main process.

6. The method according to claim 5, characterized in that, The method further includes: After detecting that the proxy object of the cross-process communication interface has been successfully obtained from the main process, the slave process determines the device control parameters required by the user for the controlled device. Based on the device control parameters, a device control request for the controlled device is generated; wherein, the device control request is used to request the main process to control the controlled device, and the device control request carries the device control parameters of the controlled device; The proxy object using the inter-process communication interface sends the device control request to the main process through the inter-process communication interface service; wherein, the device control parameters of the controlled device carried in the device control request are used by the main process to generate corresponding device control instructions, and the device control instructions are used to control the controlled device.

7. A method for reusing main process resources, the method being applied to a control terminal, characterized in that, The control terminal is equipped with a master process and a slave process, and the method includes: The main process initializes the target resources used by the slave process, including communication resources, device status resources, and service interface resources. After initializing the target resource, the target resource is converted into a corresponding cross-process communication interface service, and the cross-process communication interface service is started for the slave process; After detecting that the cross-process communication interface service has been started, the slave process initializes the communication bridge layer and sends a service binding request to the master process through the communication bridge layer by calling the communication interface proxy; wherein, the service binding request is used to request to establish a binding relationship with the cross-process communication interface; The main process generates a proxy object of the cross-process communication interface corresponding to the cross-process communication interface service based on the service binding request, and sends the proxy object of the cross-process communication interface to the communication interface proxy of the slave process through the cross-process communication interface service. The slave process receives the proxy object of the inter-process communication interface from the main process through the communication interface proxy, and sends a binding success notification to the communication bridge layer through the communication interface proxy; wherein, the binding success notification is used to indicate that the slave process has successfully obtained the proxy object of the inter-process communication interface from the main process.

8. A processing apparatus for reusing main process resources, the apparatus being applied to a control terminal, characterized in that, The control terminal is equipped with a main process, which includes: An initialization module is used to initialize target resources used by the process, including communication resources, device status resources, and service interface resources. The conversion module is used to convert the target resource into a corresponding cross-process communication interface service after initializing the target resource; A communication module is used to start the cross-process communication interface service for the slave process; wherein, the cross-process communication interface service is used to enable the slave process to establish a binding relationship with the cross-process communication interface, and the cross-process communication interface corresponds to the cross-process communication interface service; The communication module is further configured to send the proxy object of the cross-process communication interface to the slave process after detecting that the slave process has established a binding relationship with the cross-process communication interface.

9. A control terminal, characterized in that, The control terminal has a master process and a slave process installed, and the control terminal includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the processing method for reusing main process resources as described in any one of claims 1-7.

10. A resource reuse system, wherein the resource reuse system is applied to a control terminal, characterized in that, The control terminal is equipped with a master process and a slave process. The master process and the slave process communicate with each other through an inter-process communication interface service. The master process is connected to the controlled device. The master process and the slave process respectively execute the matching steps in the processing method for reusing master process resources as described in any one of claims 1-7 to control the controlled device and synchronize the device status parameters of the controlled device to the slave process.

Images