Local cloud collaborative shared object library calling method and device, equipment and medium

Abstract

The invention provides a local cloud collaborative shared object library calling method and device, equipment and a medium, and the method comprises the steps: determining a target shared object library file needing to be called when a shared object library calling event is triggered, and determining the resource demand information of the target shared object library file; acquiring equipment state information of the equipment end and connection state information of communication connection between the equipment end and the cloud end; determining a calling strategy for the target shared object library file according to the resource demand information, the equipment state information and the connection state information; and calling the target shared object library file by the equipment end and / or the cloud end according to the calling strategy. Through the application, the execution position (local or cloud) of each function in the shared object library can be dynamically decided by detecting the resource demand of the shared object library, the state of equipment, the state of communication connection and the like. The cloud computing power utilization can be maximized while the real-time performance is ensured.

Description

Technical Field

[0001] This application belongs to the technical field of IoT edge computing, specifically relating to a method, apparatus, device, and medium for calling a shared object library for local cloud collaboration. Background Technology

[0002] IoT terminal devices (such as smart cameras, wearable devices, environmental sensors, etc.) generally use Wi-Fi modules to achieve wireless connectivity and rely on local SO libraries (Shared Object Library) to provide algorithm support.

[0003] In related technologies, functions in SO libraries can be called locally; however, local hardware resources are limited, leading to problems such as insufficient storage space, limited computing performance, and difficulties in updating algorithms. On the other hand, relying entirely on cloud execution can cause response delays when the network is unstable, or even cause complete functional failure due to communication interruptions. Summary of the Invention

[0004] In view of the above problems, a method, apparatus, device, and medium for invoking a shared object library in a local cloud-based collaborative manner are proposed to overcome or at least partially solve the above problems, including: A method for invoking a shared object library for local-cloud collaboration, applied on a device, wherein the device is connected to the cloud for communication, the method comprising: When a shared object library call event is triggered, the target shared object library file to be called is determined, and the resource requirement information of the target shared object library file is determined. Obtain the device status information of the device and the connection status information of the communication connection between the device and the cloud; Based on the resource requirement information, the device status information, and the connection status information, determine the invocation strategy for the target shared object library file; According to the invocation strategy, the target shared object library file is invoked by the device and / or the cloud.

[0005] Optionally, determining the invocation strategy for the target shared object library file based on the resource requirement information, the device status information, and the connection status information includes: Based on the resource requirement information, determine the computational complexity and real-time requirements of the target shared object library file; The target score is determined based on the computational complexity, the real-time requirements, the device status information, and the connection status information. When the target score exceeds the threshold, a calling strategy is generated to call the target shared object library file from the cloud. When the target score does not exceed the threshold, a calling strategy is generated for the device to call the target shared object library file.

[0006] Optionally, the method further includes: Detect the communication connection between the device and the cloud; In the event of an interruption in the communication connection between the device and the cloud, a calling strategy is generated for the device to invoke the target shared object library file.

[0007] Optionally, when the invocation strategy is a strategy of invoking the target shared object library file by the cloud, the step of invoking the target shared object library file by the device and / or the cloud according to the invocation strategy includes: The device determines the first change information of the target shared object library file and uploads the first change information to the cloud; the cloud is used to adjust the target shared object library file according to the first change information and then call the adjusted target shared object library file to generate result information. Receive the result information returned by the cloud.

[0008] Optionally, the method further includes: Receive the second change information returned by the cloud, wherein the second change information is generated by the cloud based on the target shared object library file after the result information is generated; Based on the second change information, the target shared object library file is adjusted.

[0009] This application also provides a method for invoking a shared object library in a local-cloud collaborative manner, applied in the cloud, wherein the cloud and the device are connected in communication, and the method includes: The system determines the connection status information of the communication connection between the device and the cloud, and sends the connection status information to the device. When a shared object library call event is triggered, the device determines the target shared object library file to be called and the resource requirements of the target shared object library file. It also obtains the device status information of the device and determines the calling strategy for the target shared object library file based on the resource requirements information, the device status information, and the connection status information. When the invocation strategy is to invoke the target shared object library file by invoking the cloud, the target shared object library file is invoked.

[0010] Optionally, the cloud deploys a function repository that stores multiple shared object library files, and calling the target shared object library file includes: Determine the device architecture of the device and obtain the target shared object library file from the function repository based on the device architecture; Based on the device architecture, an execution environment is constructed, and the target shared object library file is called within the execution environment.

[0011] Optionally, the step of calling the target shared object library file includes: The system receives first change information of the target shared object library file uploaded by the device, adjusts the target shared object library file according to the first change information, and then calls the adjusted target shared object library file to generate result information. The result information is sent to the device.

[0012] Optionally, the method further includes: Based on the target shared object library file after generating the result information, generate second change information; The device sends the second change information to the device terminal; the device terminal is used to adjust the target shared object library file according to the second change information.

[0013] This application also provides a local-cloud collaborative shared object library invocation device, applied to a device end, wherein the device end is communicatively connected to the cloud, and the device includes: The first information determination module is used to determine the target shared object library file to be called when the shared object library call event is triggered, and to determine the resource requirement information of the target shared object library file. The information acquisition module is used to acquire the device status information of the device and the connection status information of the communication connection between the device and the cloud. The strategy determination module is used to determine the invocation strategy for the target shared object library file based on the resource requirement information, the device status information, and the connection status information. The first execution module is used to invoke the target shared object library file by the device and / or the cloud according to the invocation strategy.

[0014] This application also provides a shared object library invocation device for local-cloud collaboration, applied in the cloud, wherein the cloud is communicatively connected to the device, and the device includes: The second information determination module is used to determine the connection status information of the communication connection between the device and the cloud, and send the connection status information to the device; the device is used to determine the target shared object library file to be called when the shared object library call event is triggered, and determine the resource requirement information of the target shared object library file; obtain the device status information of the device; and determine the calling strategy for the target shared object library file based on the resource requirement information, the device status information and the connection status information. The second execution module is used to invoke the target shared object library file when the invocation strategy is to invoke the target shared object library file by invoking the target shared object library file from the cloud.

[0015] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the above-described method for invoking a shared object library for local cloud collaboration.

[0016] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for invoking a shared object library for local cloud collaboration.

[0017] The embodiments of this application have the following advantages: In this application, when a shared object library call event is triggered, the target shared object library file to be called is determined, along with its resource requirements. Device status information and connection status information between the device and the cloud are obtained. Based on the resource requirements, device status, and connection status information, a calling strategy for the target shared object library file is determined. According to the calling strategy, the target shared object library file is called by the device and / or the cloud. This application allows for dynamic decision-making regarding the execution location (local or cloud) of each function in the shared object library by detecting its resource requirements, device status, and communication connection status. This application maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates due to local resource constraints. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of a local-cloud collaborative shared object library invocation method according to an embodiment of this application; Figure 2This is a flowchart illustrating the steps of another local-cloud collaborative shared object library invocation method according to an embodiment of this application; Figure 3 This is a flowchart illustrating the steps of another local-cloud collaborative shared object library invocation method according to an embodiment of this application; Figure 4 This is a flowchart illustrating the steps of another local-cloud collaborative shared object library invocation method according to an embodiment of this application; Figure 5 This is a flowchart illustrating the steps of another local-cloud collaborative shared object library invocation method according to an embodiment of this application; Figure 6 This is a schematic diagram of a local cloud collaborative invocation according to an embodiment of this application; Figure 7 This is a schematic diagram of another local cloud collaborative invocation embodiment of this application; Figure 8 This is a flowchart illustrating the steps involved in generating a calling strategy according to an embodiment of this application. Figure 9 This is a flowchart illustrating the steps of distributed execution according to an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a local cloud collaborative shared object library calling device according to an embodiment of this application; Figure 11 This is a schematic diagram of another local cloud-based collaborative shared object library invocation device according to an embodiment of this application. Detailed Implementation

[0019] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In some related technologies, it is possible to migrate the entire shared object library (e.g., SO library), but this does not enable flexible scheduling of critical functions; In some related technologies, developers may be required to refactor the code, but this makes it difficult to maintain compatibility with existing standard interfaces.

[0021] These problems severely restrict the functional expansion and performance improvement of IoT devices, thus necessitating a solution that can guarantee real-time performance while also considering resource utilization and ease of development. To address this, this application provides a method for calling a shared object library in a local-cloud collaborative manner. This method dynamically determines the execution location (local or cloud) of each function in the shared object library by detecting the resource requirements of the shared object library, the device status, and the communication connection status. This application maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates caused by local resource constraints.

[0022] Reference Figure 1 This document illustrates a flowchart of a local-cloud collaborative shared object library invocation method according to an embodiment of this application. This method can be applied to a device; the device can be an IoT terminal device, such as a smart camera, wearable device, or environmental sensor. The device can communicate with the cloud; for example, the device can wirelessly connect to the cloud via a Wi-Fi module.

[0023] like Figure 1 As shown, the method for invoking the shared object library for local cloud collaboration may include the following steps: Step 101: When the shared object library call event is triggered, determine the target shared object library file to be called and determine the resource requirements information of the target shared object library file.

[0024] Shared object libraries can refer to SO libraries, DLLs in Windows systems, or .dylibs in macOS systems.

[0025] In this context, SO libraries refer to dynamic link libraries in Linux and Unix-like systems. These are binary files containing multiple functions, variables, and other symbols, typically with the .so extension (e.g., libexample.so). Similar to .dll files in Windows, they are binary files containing reusable code and data, primarily used for code sharing and dynamic loading.

[0026] In this application, functions in the shared object library can be called from both the cloud and the local machine, and executed locally or in the cloud. For cloud execution, the hardware resources in the cloud are superior to those in the local machine, thus avoiding problems such as limited computing performance and difficulty in updating algorithms. However, cloud execution may not be able to meet real-time requirements.

[0027] For local execution, direct execution eliminates the need to upload data to the cloud, thus meeting real-time requirements. However, local hardware resources are inferior to those in the cloud, potentially leading to limitations in computational performance and difficulties in algorithm updates. To address this, this application can determine the target shared object library file to be invoked from the shared object library before triggering a shared object library call event.

[0028] The shared object library call event refers to an event triggered on the device side that requires calling a function in the shared object library. The target shared object library file can be a file that needs to be called by the device or the cloud; this file can be a function.

[0029] After identifying the target shared object library file, it can be analyzed to determine the resource requirements for executing that file, such as the estimated CPU (Central Processing Unit) cycle consumption. CPU cycle consumption refers to the total number of CPU clock cycles used (or consumed) by a program, function, or instruction set from start to finish.

[0030] A clock cycle is the most basic unit of time for CPU operation, determined by the CPU's main clock frequency. For example, a 3.0 GHz CPU has a clock cycle of approximately 1 / 3000000000 seconds. The fewer the number of cycles consumed, the faster the code execution and the higher the efficiency. Execution time (seconds) ≈ Number of clock cycles × Clock cycle length.

[0031] For example, the estimated CPU cycle consumption of a target SO library file can be obtained by statically analyzing its ELF (Executable and Linkable Format) header information. Specifically, static analysis estimates the CPU cycle consumption of functions by analyzing the SO library's binary file without actually executing the program.

[0032] The process first parses the header of the ELF file, locating the .text section which stores machine instructions, the .symtab symbol table which records function entry points and sizes, and (if present) the .debug_info debug section which contains rich source-level information. The core of the analysis is traversing the disassembled instruction sequence: assigning different cycle weights to different types of instructions according to the CPU instruction set architecture manual (e.g., addition instructions have 1 cycle, while memory access instructions may have dozens of cycles), and identifying key structures.

[0033] The total estimated cycle time is calculated as: Total estimated cycle time = Basic instruction cost + ∑ (Single loop cost) + ∑ (Function call cost), where: Nullorder_num: The total number of basic instructions that are not loops or calls within a function.

[0034] Avg: Average cycle cost per instruction (this is an empirical value, such as 1.5 cycles / instruction).

[0035] Loop_1, Loop_2, ...: The identified loops.

[0036] Cycleorder_num: The number of instructions in the loop body of the i-th loop.

[0037] Cycle_num: The estimated number of iterations for the i-th loop (average or median number of iterations).

[0038] α: Loop overhead factor (empirical value, such as 1.1, indicating that due to operations such as jumps and conditional judgments, the actual cost of looping is 10% higher than that of simple accumulation).

[0039] C_call: The estimated average cost of each function call (an empirical value, such as 100 cycles, used to estimate the cost of calling an external function).

[0040] Based on the above formula, an estimated CPU cycle consumption value can be calculated.

[0041] Step 102: Obtain the device status information on the device side, as well as the connection status information of the communication connection between the device side and the cloud.

[0042] In some embodiments, device status information and connection status information of communication connections between devices can also be obtained.

[0043] The device status information may refer to the device's CPU utilization, available memory, temperature, etc. For example, the device status information can be determined by detecting the device itself; this application embodiment does not limit this.

[0044] Connection status information can refer to the status of the communication connection between the device and the cloud, such as network quality and network QoS (Quality of Service) status.

[0045] For example, network quality can be detected by the device itself, such as by obtaining RSSI (Received Signal Strength Indicator), round-trip delay, and available bandwidth through the Wi-Fi driver layer.

[0046] Network QoS status is detected by a cloud-based QoS monitor. Specifically, the QoS monitor assesses network status through a combination of active probing and passive listening. It periodically sends lightweight probe packets (such as Ping or dedicated signaling) to devices to accurately measure round-trip time (RTT) and packet loss rate.

[0047] Meanwhile, the QoS monitor listens to all past service data streams in real time, statistically analyzing their transmission time (jitter), throughput, and actual packet loss. The QoS monitor integrates these raw metrics with historical baseline data, using a weighted algorithm to calculate a comprehensive score reflecting the current network quality (e.g., good, average, congested). This evaluation result is then asynchronously fed back to the devices, providing them with a basis for decision-making.

[0048] Overall score = (S_l×W_l) + (S_j×W_j) + (S_p×W_p).

[0049] Where the delay S_l = 100 * (300 - current_latency) / (300 - 20); Jitter S_j = 100 * (300 - current_jitter) / (300 - 20); Packet loss rate S_p = 100 * (1 - current_loss / 0.1); current_latency is the current latency; current_jitte represents the current jitter; current_loss is the current packet loss rate; W_l, W_j, and W_p are preset weights that can be set according to actual conditions.

[0050] Step 103: Determine the calling strategy for the target shared object library file based on resource requirement information, device status information, and connection status information.

[0051] After determining the resource requirements, device status, and connection status information, a calling strategy for the target shared object library file can be determined based on these information.

[0052] For example, the execution location of the target shared object library file can be determined based on resource requirement information, device status information, and connection status information. For instance, when the network quality of the general connection is poor and cannot meet real-time requirements, a calling strategy can be determined to have the device call the target shared object library file for execution.

[0053] For example, when the network quality of the communication connection is normal and the resource demand is high, the calling strategy of calling the target shared object library file from the cloud can be determined.

[0054] Step 104: According to the invocation strategy, the target shared object library file is invoked by the device and / or the cloud.

[0055] After determining the invocation strategy, the target shared object library file can be invoked and executed by either the device or the cloud based on the invocation strategy. Alternatively, when there are multiple target shared object library files, they can be executed in a distributed manner by invoking portions of the target shared object library files by both the device and the cloud. This application embodiment does not impose any limitations on this approach.

[0056] In this embodiment, when a shared object library call event is triggered, the target shared object library file to be called is determined, along with its resource requirements. Device status information and connection status information between the device and the cloud are obtained. Based on the resource requirements, device status, and connection status information, a calling strategy for the target shared object library file is determined. According to the calling strategy, the target shared object library file is called by the device and / or the cloud. This application allows for dynamic decision-making regarding the execution location (local or cloud) of each function in the shared object library by detecting its resource requirements, device status, and communication connection status. This application also maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates due to local resource constraints.

[0057] Reference Figure 2 The flowchart illustrates another method for invoking a shared object library in a local-cloud collaborative manner according to an embodiment of this application, which may include the following steps: Step 201: When the shared object library call event is triggered, determine the target shared object library file to be called and determine the resource requirements information of the target shared object library file.

[0058] In this application, functions in the shared object library can be called from both the cloud and local machines, and the functions can be executed locally or in the cloud.

[0059] This application can determine the target shared object library file to be called from the shared object library when a shared object library call event is triggered.

[0060] After identifying the target shared object library file, the device can analyze it to determine the resource requirements needed to execute the target shared object library file.

[0061] Step 202: Obtain the device status information on the device side, as well as the connection status information of the communication connection between the device side and the cloud.

[0062] In some embodiments, device status information and connection status information of communication connections between devices can also be obtained.

[0063] Step 203: Based on the resource requirement information, determine the computational complexity and real-time requirements of the target shared object library file.

[0064] After determining the resource requirements, the computational complexity of the target shared object library file and the real-time requirements for its execution can be determined based on these requirements.

[0065] Computational complexity can also be measured by computational overhead, for example, it can include the estimated number of CPU cycles required to execute a function.

[0066] Real-time requirements can refer to the maximum allowable response time of a function.

[0067] Step 204: Determine the target score based on computational complexity, real-time requirements, device status information, and connection status information.

[0068] After determining the computational complexity, real-time requirements, device status information, and connection status information, the target score can be determined based on the computational complexity, real-time requirements, device status information, and connection status information.

[0069] For example, the target score can be calculated based on the following formula: score=α*(compute_cost)+β*(latency_req)+γ*(network_quality)+δ*(device_resource).

[0070] Where α, β, γ, δ are adjustable weighting coefficients, and α + β + γ + δ = 1; for example, α = 0.4, β = 0.3, γ = 0.2, δ = 0.1.

[0071] α is the computational complexity weight, used to measure the degree of influence of function computation on decision-making (dominant factor); β is the real-time requirement weight, characterizing the sensitivity of the function to latency; γ is the network loss weight, reflecting the constraint of the current network quality on cloud execution. Cloud execution refers to the process of offloading the function to the cloud for execution. The constraint means that poor network quality will limit and hinder the choice of "cloud execution"; δ is the weight of device status information.

[0072] compute_cost is resource requirement information that can be used to represent computational overhead; for example, it can refer to the estimated number of CPU cycles required to execute a function.

[0073] latency_req represents the real-time requirement and can be used to indicate latency requirements; for example, it can refer to the maximum allowable response time of the function.

[0074] network_loss is connection state information that can be used to represent network overhead, and can include current network packet loss rate and latency metrics. network_loss can also be a comprehensive score derived from a QoS monitor.

[0075] device_resource is used to represent device status information, such as the device's CPU utilization, current available memory, and current temperature.

[0076] In some embodiments, when a certain parameter index is continuously detected to be consistently poor, the corresponding weight can be temporarily reduced and other weights can be increased accordingly, with 0.1 as the base value for the change. The changes can be restored after the normal value is restored. This application embodiment does not limit this.

[0077] Step 205: When the target score exceeds the threshold, generate a calling strategy for calling the target shared object library file from the cloud.

[0078] In some embodiments, if the target score exceeds a preset threshold, it can be determined that the target shared object library file is executed by the cloud; at this time, a calling strategy for calling the target shared object library file by the cloud can be generated and the calling strategy can be executed.

[0079] The threshold can be set according to the actual situation. For example, the threshold can be 0.82. This embodiment of the invention does not limit this.

[0080] Step 206: When the target score does not exceed the threshold, generate a calling strategy for the device to call the target shared object library file.

[0081] Conversely, if the target score does not exceed the preset threshold, it can be determined that the target shared object library file is executed by the device. In this case, a calling strategy for the device to call the target shared object library file can be generated and executed.

[0082] Step 207: According to the invocation strategy, the target shared object library file is invoked by the device and / or the cloud.

[0083] After determining the invocation strategy, the target shared object library file can be invoked and executed by either the device or the cloud based on the invocation strategy. Alternatively, when there are multiple target shared object library files, they can be executed in a distributed manner by invoking portions of the target shared object library files by both the device and the cloud. This application embodiment does not impose any limitations on this approach.

[0084] In one embodiment of this application, the above method may further include the following steps: The system detects the communication connection between the device and the cloud; in the event of an interruption in the communication connection between the device and the cloud, it generates a calling strategy for the device to call the target shared object library file.

[0085] In some embodiments, the connection status information can be generated by a QoS monitor in the cloud; when the communication connection between the device and the cloud is interrupted, the device will not be able to receive this information and make a judgment. Therefore, the device can actively detect whether the communication connection between the device and the cloud is still in a normal state.

[0086] If the device detects an interruption in the communication connection between the device and the cloud, it can directly determine that the target shared object library file is currently being called by the device. In this case, the device can generate a calling strategy for calling the target shared object library file and execute that strategy.

[0087] In one embodiment of this application, when the invocation strategy is to invoke the target shared object library file from the cloud, step 104 or step 207 can be implemented through the following sub-steps: Sub-step 11: The device determines the first change information of the target shared object library file and uploads the first change information to the cloud; the cloud is used to adjust the target shared object library file according to the first change information and then call the adjusted target shared object library file to generate result information.

[0088] In some embodiments, for stateful functions, the output of the function depends not only on the input parameters but also on the internal state saved during its historical execution. For example, an add(int num) function, which is an accumulation counter, updates the "current accumulation value" after each call, and the result of the next call depends on this accumulation value; another example is a network protocol processing function that needs to maintain the connection context.

[0089] To address this, in order to ensure context synchronization, when the invocation strategy is determined to be the invocation strategy of calling the target shared object library file from the cloud, in addition to uploading business data, the device can also determine the difference between the current state of the memory page corresponding to the execution of the target shared object library file and the baseline state of the last synchronization, and upload this difference as the first change information to the cloud, so as to ensure that the cloud can complete context synchronization based on the difference.

[0090] Upon receiving the first change information, the cloud can adjust the target shared object library file based on this information. For example, the cloud can reconstruct the register state based on the first change information to complete the adjustment of the target shared object library file.

[0091] Then, the cloud can call the adjusted target shared object library file, as well as generate result information based on the business data uploaded by the device.

[0092] The first change information and the second change information (described later) refer to information stored in memory about the variable modification areas involved in the function call. When a function runs, it reads and modifies data in memory (e.g., modifying the value of a global variable, processing an passed array, etc.). These modified memory pages are called dirty pages. Using the hardware features of the Memory Management Unit (MMU), it's possible to track which specific memory pages were written to (modified) during function execution. Based on this, dirty page detection technology (based on MMU hardware features) can be used to mark the variable modification areas involved in the function call, thereby generating the first change information or the second change information.

[0093] In some embodiments, the specific data passed in during function calls can be compressed in layers; structured data can be compressed using CBOR binary encoding, while unstructured data (such as images) can be compressed using the Zstd algorithm. The compressed data can be transmitted to the cloud through a secure channel established by the TLS (Transport Layer Security) 1.3 hardware acceleration engine integrated in the Wi-Fi module.

[0094] In this process, the device and the cloud can establish a secure encrypted channel using the TLS handshake protocol. Then, the compressed data is transmitted encrypted through this established secure channel.

[0095] Sub-step 12: Receive the result information returned from the cloud.

[0096] After generating the result information, the cloud can send it to the device. Upon receiving the result information, the device can perform integrity verification on the result using SHA-256.

[0097] In some embodiments of this application, for sub-steps 11-12 described above, the embodiments of this application may further include the following steps: Receive the second change information returned by the cloud, which is generated by the cloud based on the target shared object library file after the generation result information; adjust the target shared object library file according to the second change information.

[0098] In some embodiments, when the cloud sends result information to the device, it can also generate a lightweight result package. This lightweight result package can apply Delta encoding to binary data and store only the changed parts, that is, the changed parts of the target shared object library file after the result information is generated.

[0099] For example, taking the target shared object library file as a function, the changed parts are all the changed "states" after the function is executed. This refers to the modified parts in the memory context, with the reference point being a copy of the original memory state on the device before the function execution.

[0100] Before a function call is moved to the cloud, the device not only sends dirty pages but also saves a complete copy (snapshot) of the function's memory space locally as a reference. This snapshot contains the state of all variables and parameters before the function execution.

[0101] After the function finishes execution in the cloud, the cloud generates a complete post-execution memory state. The cloud compares this post-execution state with the pre-execution state baseline received from the device. It then calculates the difference between the two states (i.e., the second change information). This difference packet is called the "lightweight result packet," which only contains the changed data blocks and their location information; its size is typically much smaller than the complete state.

[0102] After receiving the second change information, the device can perform context recovery based on the second change information; specifically, it can reconstruct the register state through the pre-saved CPU context.

[0103] For example, before deciding to offload a function call to the cloud and about to jump to network-transmitted code, the device's operating system immediately performs a critical operation: saving the CPU context of the current function.

[0104] "Context" refers to the state values ​​of all CPU registers at the moment the function is suspended, including: the instruction pointer register, the stack pointer register, general-purpose registers, and other status registers. The values ​​of these registers are immediately packed into a specific data structure in memory.

[0105] Once the device receives the second change information from the cloud and completes memory synchronization, the operating system needs to "revive" this function.

[0106] The operating system will locate the specific data structure that was previously saved and write its values ​​back to the corresponding CPU registers one by one.

[0107] In some embodiments, when a memory access exception occurs in the device, a copy-on-write mechanism can be used to copy the data when it is actually needed to modify the data (referring to the part of the function memory state that needs to be synchronized to the cloud). When a write exception occurs, a new physical page can be allocated, the original content copied, the page table updated to point to the new page, and marked as writable, thereby realizing memory mapping recovery.

[0108] In this embodiment of the application, when the shared object library call event is triggered, the target shared object library file to be called is determined, and the resource requirement information of the target shared object library file is determined.

[0109] In this application, functions in the shared object library can be called from both the cloud and local machines, and executed locally or in the cloud; device status information and connection status information between the device and the cloud are obtained; the computational complexity and real-time requirements of the target shared object library file are determined based on resource requirement information; a target score is determined based on computational complexity, real-time requirements, device status information, and connection status information; when the target score exceeds a threshold, a calling strategy for the cloud to call the target shared object library file is generated; when the target score does not exceed the threshold, a calling strategy for the device to call the target shared object library file is generated; and the target shared object library file is called by the device and / or the cloud according to the calling strategy. Through this embodiment, while ensuring real-time performance, the utilization of cloud computing power can be maximized, thereby avoiding problems such as limited computing performance and difficulty in algorithm updates due to local resource constraints.

[0110] The above describes the method for calling the shared object library for local-cloud collaboration provided in this application from the perspective of the device side; next, the method for calling the shared object library for local-cloud collaboration provided in this application will be described from the perspective of the cloud side: Reference Figure 3 The flowchart illustrates another method for invoking a shared object library in a local-cloud collaborative manner according to an embodiment of this application, which may include the following steps: Step 301: Determine the connection status information of the communication connection between the device and the cloud, and send the connection status information to the device; the device is used to determine the target shared object library file to be called when the shared object library call event is triggered, and determine the resource requirement information of the target shared object library file; obtain the device status information of the device; and determine the calling strategy for the target shared object library file based on the resource requirement information, device status information and connection status information.

[0111] In some embodiments, the QoS monitor in the cloud can generate connection status information of the communication connection between the device and the cloud, and send the connection status information to the device so that the device can generate the invocation policy.

[0112] When the device triggers a shared object library call event, it can first determine the target shared object library file to be called from the shared object library.

[0113] The shared object library call event can refer to an event triggered on the device side that requires calling a function in the shared object library. The target shared object library file can refer to a file in the library that needs to be called by the device or the cloud; this file can be a function.

[0114] After identifying the target shared object library file, the device can analyze it to determine the resource requirements needed to execute the target shared object library file.

[0115] In addition, the device can also obtain device status information. After obtaining the device status information, resource requirement information, and connection status information, the device can determine the calling strategy for the target shared object library file based on these information.

[0116] In some embodiments, if the invocation strategy is to execute the target shared object library file by invoking it from the device, the device can directly invoke the target shared object library file for execution.

[0117] Step 302: When the invocation strategy is to invoke the target shared object library file from the cloud, invoke the target shared object library file.

[0118] Conversely, if the invocation strategy is to invoke the target shared object library file from the cloud, the device can send a notification to the cloud instructing it to execute the request. Upon receiving this notification, the cloud can invoke the target shared object library file from the shared object library for execution.

[0119] In this embodiment, the cloud determines the connection status information of the communication connection between the device and the cloud, and sends the connection status information to the device. When a shared object library call event is triggered, the device determines the target shared object library file to be called and its resource requirements. It also obtains the device status information. Based on the resource requirements, device status, and connection status information, it determines the calling strategy for the target shared object library file. When the calling strategy is for the cloud to call the target shared object library file, the target shared object library file is called. This embodiment maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates due to local resource constraints.

[0120] Reference Figure 4 The flowchart illustrates another method for invoking a shared object library in a local-cloud collaborative manner according to an embodiment of this application, which may include the following steps: Step 401: Determine the connection status information between the device and the cloud, and send the connection status information to the device.

[0121] In some embodiments, the QoS monitor in the cloud can generate connection status information of the communication connection between the device and the cloud, and send the connection status information to the device so that the device can generate the invocation policy.

[0122] When the device triggers a shared object library call event, it can first determine the target shared object library file to be called from the shared object library.

[0123] The shared object library call event can refer to an event triggered on the device side that requires calling a function in the shared object library. The target shared object library file can refer to a file in the shared object library that needs to be called by the device or the cloud; this file can be a function.

[0124] After identifying the target shared object library file, the device can analyze it to determine the resource requirements needed to execute the target shared object library file.

[0125] In addition, the device can also obtain device status information. After obtaining the device status information, resource requirement information, and connection status information, the device can determine the calling strategy for the target shared object library file based on these information.

[0126] In some embodiments, if the invocation strategy is to execute the target shared object library file by invoking it from the device, the device can directly invoke the target shared object library file for execution.

[0127] Step 402: A function repository is deployed in the cloud, which stores multiple shared object library files. When the invocation strategy is to invoke the target shared object library file from the cloud, the device architecture on the device side is determined, and the target shared object library file is obtained from the function repository according to the device architecture.

[0128] In some embodiments, different devices have different functions and protocols, and therefore require different shared object library files. In response, if the invocation strategy is to invoke the target shared object library file from the cloud, the device may include function identifiers (such as function names), version numbers, and device architecture (such as armv8) in its request to the cloud.

[0129] Once received, the cloud can determine the device architecture based on this information and, according to the device architecture, search for the target shared object library file that matches the device architecture in the function repository (a database storing all versions of shared object libraries). This ensures that the version of the function being run is consistent with the device's expectations.

[0130] Step 403: Based on the device architecture, construct the execution environment and call the target shared object library file in the execution environment.

[0131] After identifying the target shared object library file that matches the device architecture, the cloud can build a suitable execution environment based on the device architecture and execute the target shared object library file within that execution environment.

[0132] For example, a dynamic loader in the cloud can automatically convert instruction sets to create an isolated execution environment in an Intel SGX-based TEE container, based on the device architecture.

[0133] The dynamic loader is a component of the operating system responsible for loading compiled shared object library files from disk into memory, resolving symbol references within them, and preparing them for execution; it is the underlying component of any dynamic link library.

[0134] The function repository pre-stores versions of the same function for different architectures. Based on the device architecture field in the request, the cloud selects the corresponding ARM or x86 version of the shared object library file, which is then loaded into the cloud server's (x86 environment) memory by the cloud's dynamic loader. The appropriate version runs on the cloud.

[0135] In some embodiments, to ensure the security and privacy of user code and data in the cloud, and to prevent cloud platform administrators or other tenants from spying on them, the shared object library is loaded before or simultaneously. The execution environment (TEE container) is created first, and then the secure target shared object library file and the business data encrypted and transmitted from the device are loaded into this container.

[0136] In this embodiment, the connection status information of the communication connection between the device and the cloud is determined and sent to the device. The cloud-deployed function repository stores multiple shared object library files. When the invocation strategy is to invoke the target shared object library file from the cloud, the device architecture is determined, and the target shared object library file is obtained from the function repository based on the device architecture. An execution environment is constructed based on the device architecture, and the target shared object library file is invoked within the execution environment. Through this embodiment, a suitable target shared object library file can be matched and executed based on the device architecture, ensuring that the shared object library file executed in the cloud matches the device architecture. This ensures that the version of the running shared object library file is consistent with the device's expectations.

[0137] Reference Figure 5 The diagram illustrates a flowchart of another method for invoking a shared object library in a local-cloud collaborative manner, according to an embodiment of this application. The method may include the following steps: Step 501: Determine the connection status information between the device and the cloud, and send the connection status information to the device.

[0138] In some embodiments, the QoS monitor in the cloud can generate connection status information of the communication connection between the device and the cloud, and send the connection status information to the device so that the device can generate the invocation policy.

[0139] When the device triggers a shared object library call event, it can first determine the target shared object library file to be called from the shared object library.

[0140] The shared object library call event can refer to an event triggered on the device side that requires calling a function in the shared object library. The target shared object library file can refer to a file in the shared object library that needs to be called by the device or the cloud; this file can be a function.

[0141] After identifying the target shared object library file, the device can analyze it to determine the resource requirements needed to execute the target shared object library file.

[0142] In addition, the device can also obtain device status information. After obtaining the device status information, resource requirement information, and connection status information, the device can determine the calling strategy for the target shared object library file based on these information.

[0143] In some embodiments, if the invocation strategy is to execute the target shared object library file by invoking it from the device, the device can directly invoke the target shared object library file for execution.

[0144] Step 502: When the invocation strategy is to invoke the target shared object library file from the cloud, receive the first change information of the target shared object library file uploaded by the device, adjust the target shared object library file according to the first change information, and then invoke the adjusted target shared object library file to generate result information.

[0145] In some embodiments, in order to ensure context synchronization, when the invocation strategy is determined to be the invocation strategy of calling the target shared object library file from the cloud, in addition to uploading business data, the device can also determine the difference between the current state of the memory page corresponding to the execution of the target shared object library file and the baseline state of the last synchronization, and upload the difference as the first change information to the cloud, so as to ensure that the cloud can complete the context synchronization based on the difference.

[0146] Upon receiving the first change information, the cloud can adjust the target shared object library file based on this information. For example, the cloud can reconstruct the register state based on the first change information to complete the adjustment of the target shared object library file.

[0147] Then, the cloud can call the adjusted target shared object library file, as well as generate result information based on the business data uploaded by the device.

[0148] Step 503: Send the result information to the device.

[0149] After generating the result information, the cloud can send it to the device. Upon receiving the result information, the device can perform integrity verification on the result using SHA-256.

[0150] In some embodiments of this application, the above method may further include the following steps: Based on the target shared object library file after generating the result information, a second change information is generated; the second change information is sent to the device; the device is used to adjust the target shared object library file according to the second change information.

[0151] In some embodiments, when the cloud sends result information to the device, it can also generate a lightweight result package. This lightweight result package can apply Delta encoding to binary data and store only the changed parts, that is, the changed parts of the target shared object library file after the result information is generated.

[0152] For example, taking the target shared object library file as a function, the changed parts are all the changed "states" after the function is executed. This refers to the modified parts in the memory context, with the reference point being a copy of the original memory state on the device before the function execution.

[0153] Before a function call is moved to the cloud, the device not only sends dirty pages but also saves a complete copy (snapshot) of the function's memory space locally as a reference. This snapshot contains the state of all variables and parameters before the function execution.

[0154] After the function finishes execution in the cloud, the cloud generates a complete post-execution memory state. The cloud compares this post-execution state with the pre-execution state baseline received from the device. It then calculates the difference between the two states (i.e., the second change information). This difference packet is called the "lightweight result packet," which only contains the changed data blocks and their location information; its size is typically much smaller than the complete state.

[0155] After receiving the second change information, the device can perform context recovery based on the second change information; specifically, it can reconstruct the register state through the pre-saved CPU context.

[0156] For example, before deciding to offload a function call to the cloud and about to jump to network-transmitted code, the device's operating system immediately performs a critical operation: saving the CPU context of the current function.

[0157] "Context" refers to the state values ​​of all CPU registers at the moment the function is suspended, including: the instruction pointer register, the stack pointer register, general-purpose registers, and other status registers. The values ​​of these registers are immediately packed into a specific data structure in memory.

[0158] Once the device receives the second change information from the cloud and completes memory synchronization, the operating system needs to "revive" this function.

[0159] The operating system will locate the specific data structure that was previously saved and write its values ​​back to the corresponding CPU registers one by one.

[0160] In this embodiment, the connection status information of the communication connection between the device and the cloud is determined and sent to the device. When the invocation strategy is to call the target shared object library file from the cloud, the first change information of the target shared object library file uploaded by the device is received, and the target shared object library file is adjusted according to the first change information. Then, the adjusted target shared object library file is called to generate result information, and the result information is sent to the device. Through this embodiment, a low-overhead text-to-text differential synchronization mechanism can be achieved. For this application, function call continuity can still be maintained in a weak network environment.

[0161] The following sections, with accompanying diagrams and specific examples, further illustrate the method for invoking the shared object library in local-cloud collaboration: like Figure 6 The diagram illustrates a local cloud collaborative invocation according to an embodiment of this application: the device includes a Wi-Fi module, a network transmission layer, a core processing layer, and an application layer; wherein, the Wi-Fi module supports the Wi-Fi4 / 5 / 6 protocol stack; the network transmission layer includes a differential compression module, which is used to compress the first change information and then transmit it to the cloud (which can be a cloud platform or other devices) through a TLS secure tunnel via the Wi-Fi module.

[0162] The core processing layer may include an integrated function routing decision-maker and a local shared object library execution engine; the integrated function routing decision-maker can be used to generate invocation strategies, and the local shared object library execution engine can be used to invoke shared object library files locally for execution.

[0163] The application layer can include applications and standard shared object library interfaces. When an application triggers a shared object library call event, it can request the integrated function routing decision-maker to generate a call strategy by triggering the standard shared object library interface. When the call strategy is to call the target shared object library file from the device side, the integrated function routing decision-maker triggers the local shared object library execution engine to call and execute the target shared object library file.

[0164] The Wi-Fi module firmware incorporates a binary redirection engine, shielding the application layer from cloud call details. This enables transparent function migration without modifying or recompiling existing shared object library code. Furthermore, the same shared object library file can run simultaneously on ARM / MIPS / RISC-V architecture devices, and algorithm upgrades only require updating the function module in the cloud, significantly reducing OTA traffic.

[0165] The cloud includes function repositories for storing various versions of shared object library files, such as shared object library functions; these can include: 1. Function code body: The compiled binary code, which contains the specific business logic.

[0166] 2. Metadata: Function unique identifier (UUID / shared object library name), version number (used to manage different versions, implement canary release, rollback, etc.), dependency description, resource requirement description (such as required memory, CPU computing power), target platform architecture (such as ARMv7, ARMv8, x86_64).

[0167] The cloud can also load ARM / x86 binary instructions on demand (achieving cross-platform compatibility of write once, run anywhere). The specific usage process is as follows: Devices (such as IoT devices and mobile phones) typically use ARM architecture processors, while cloud servers typically use x86 architecture processors. These two architectures have completely different machine instruction sets. When storing shared object library files, function repositories compile and store binary versions for multiple platforms (mainly ARM and x86) for the same function. When the integrated function routing decision-maker determines that a function should be executed in the cloud, the device sends its hardware architecture (e.g., arm64-v8a) information along with the request.

[0168] After receiving the request, the cloud will load the corresponding platform (in this case, the ARM version) shared object library file from the function repository on demand into the execution environment (such as AWS Lambda or a custom container) based on the architecture information reported by the device, and dynamically load the shared object library file to run.

[0169] After execution, the result information is returned to the device, and based on differential encoding, a second change information is generated and returned to the device. The device does not need to know the cloud architecture; it will always get the correct result. The cloud-based QoS monitor assesses the network status in real time and sends feedback to the device.

[0170] like Figure 7 The diagram illustrates another local-cloud collaborative invocation method according to an embodiment of this application: The device first initiates a call to the shared object library; at this time, the integrated function routing decision-maker generates a call strategy; for example, for functions with high computational load, parameters such as the first change information and business data can be compressed and encrypted, and transmitted to the cloud via the Wi-Fi module.

[0171] After receiving the data, the cloud can build an execution environment and dynamically load the target shared object library file. After generating the result information, the cloud can generate a second change information based on differential encoding and return it to the device.

[0172] The device can perform context recovery based on the second change information; and the application layer on the device can receive the result information.

[0173] For real-time sensitive functions, the target can share the object library file locally; after generating the result information locally, the result information can be directly returned to the application layer.

[0174] Reference Figure 8The diagram illustrates a flowchart of steps for generating a calling strategy according to an embodiment of this application: when a shared object library calling event is triggered, a calling strategy can be generated; specifically, a target score can be calculated from the perspectives of computational complexity, real-time requirements, comprehensive QoS score, device status information, etc., and the execution time (cloud or local) can be determined based on the target score.

[0175] Reference Figure 9 The following is a flowchart illustrating the steps of distributed execution according to an embodiment of this application: When the invocation strategy is to call the target shared object library file from the cloud for execution, the device can send a function call request to the cloud. After receiving the request, the cloud returns an ACK (Acknowledgment) signal and an estimated execution time to the device.

[0176] The device can also send incremental parameter data streams to the cloud; that is, business data and first change information. The cloud can execute the target shared object library file, record the memory modifications, generate differential results (only modifying fields, i.e., second change information; it can also send additional result information or include it in the differential results returned to the device) and return it to the device.

[0177] For example, in the distributed execution phase, a differential synchronization protocol can be used to transmit only the changed 128 memory pages (4.8KB in total) instead of the complete state (32KB). Optimize transmission speed and efficiency. When RSSI < -75dBm: Enable UDP + forward error correction; when RSSI ≥ -75dBm: Use QUIC protocol for independent transmission of multiple data streams to achieve bandwidth adaptive transmission.

[0178] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0179] Reference Figure 10 The diagram shows a structural schematic of a local cloud collaborative shared object library invocation device according to an embodiment of this application. This device can be applied to the device side.

[0180] like Figure 10 As shown, the device may include the following modules: The first information determination module 1001 is used to determine the target shared object library file to be called and the resource requirement information of the target shared object library file when the shared object library call event is triggered. The information acquisition module 1002 is used to acquire device status information on the device side, as well as connection status information of the communication connection between the device side and the cloud. The strategy determination module 1003 is used to determine the calling strategy for the target shared object library file based on resource requirement information, device status information and connection status information. The first execution module 1004 is used to invoke the target shared object library file by the device and / or the cloud according to the invocation strategy.

[0181] In one optional embodiment of this application, the strategy determination module 1003 is used to determine the computational complexity and real-time requirements of the target shared object library file based on resource demand information; determine the target score based on the computational complexity, real-time requirements, device status information, and connection status information; generate a calling strategy for calling the target shared object library file from the cloud when the target score exceeds a threshold; and generate a calling strategy for calling the target shared object library file from the device when the target score does not exceed the threshold.

[0182] In an optional embodiment of this application, the strategy determination module 1003 is further configured to detect the communication connection between the device and the cloud; and generate a calling strategy for the device to call the target shared object library file when the communication connection between the device and the cloud is interrupted.

[0183] In one optional embodiment of this application, the first execution module 1004 is used to determine the first change information of the target shared object library file when the calling strategy is to call the target shared object library file from the cloud, and upload the first change information to the cloud; the cloud is used to adjust the target shared object library file according to the first change information, and then call the adjusted target shared object library file to generate result information; and receive the result information returned by the cloud.

[0184] In an optional embodiment of this application, the first execution module 1004 is further configured to receive second change information returned by the cloud, the second change information being generated by the cloud based on the target shared object library file after generating the result information; and to adjust the target shared object library file according to the second change information. In this embodiment, when a shared object library call event is triggered, the target shared object library file to be called is determined, along with its resource requirements. Device status information and connection status information between the device and the cloud are obtained. Based on the resource requirements, device status, and connection status information, a calling strategy for the target shared object library file is determined. According to the calling strategy, the target shared object library file is called by the device and / or the cloud. This application allows for dynamic decision-making regarding the execution location (local or cloud) of each function in the shared object library by detecting its resource requirements, device status, and communication connection status. This application also maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates due to local resource constraints.

[0185] Reference Figure 11 The diagram shows a schematic of a local cloud collaborative shared object library invocation device according to an embodiment of this application. This device can be applied to the cloud.

[0186] like Figure 11 As shown, the device may include the following modules: The second information determination module 1101 is used to determine the connection status information of the communication connection between the device and the cloud, and send the connection status information to the device. The device is used to determine the target shared object library file to be called when the shared object library call event is triggered, and to determine the resource requirement information of the target shared object library file; to obtain the device status information of the device; and to determine the call strategy for the target shared object library file based on the resource requirement information, device status information and connection status information. The second execution module 1101 is used to invoke the target shared object library file when the invocation strategy is to invoke the target shared object library file from the cloud.

[0187] In one optional embodiment of this application, a function repository is deployed in the cloud, which stores multiple shared object library files. The second execution module 1102 is used to determine the device architecture on the device side, and obtain the target shared object library file from the function repository according to the device architecture; according to the device architecture, an execution environment is constructed, and the target shared object library file is called in the execution environment.

[0188] In one optional embodiment of this application, the second execution module 1102 is used to receive first change information of the target shared object library file uploaded by the device, and after adjusting the target shared object library file according to the first change information, call the adjusted target shared object library file to generate result information; and send the result information to the device.

[0189] In an optional embodiment of this application, the second execution module 1102 is further configured to generate second change information based on the target shared object library file after generating result information; send the second change information to the device; and the device is configured to adjust the target shared object library file based on the second change information.

[0190] In this embodiment, the cloud determines the connection status information of the communication connection between the device and the cloud, and sends the connection status information to the device. When a shared object library call event is triggered, the device determines the target shared object library file to be called and its resource requirements. It also obtains the device status information. Based on the resource requirements, device status, and connection status information, it determines the calling strategy for the target shared object library file. When the calling strategy is for the cloud to call the target shared object library file, the target shared object library file is called. This embodiment maximizes cloud computing power utilization while ensuring real-time performance, thereby avoiding problems such as limited computing performance and difficulties in algorithm updates due to local resource constraints.

[0191] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described method for calling a shared object library for local cloud collaboration.

[0192] This application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-described method for calling a shared object library for local cloud collaboration.

[0193] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0194] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0195] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0196] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0197] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0198] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0199] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0200] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0201] The above provides a detailed description of a local cloud-based collaborative shared object library invocation method, apparatus, device, and medium. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for invoking a shared object library collaboratively in a local cloud, characterized in that, The method is applied to a device end, the device end is in communication connection with a cloud end, and the method comprises the following steps: When a shared object library calling event is triggered, a target shared object library file to be called is determined, and resource requirement information of the target shared object library file is determined; Device state information of the device end and connection state information of the communication connection between the device end and the cloud end are acquired; According to the resource requirement information, the device state information and the connection state information, a calling strategy for the target shared object library file is determined; According to the calling strategy, the target shared object library file is called by the device end and / or the cloud end.

2. The method of claim 1, wherein, The calling strategy for the target shared object library file is determined according to the resource requirement information, the device state information and the connection state information, and comprises the following steps: According to the resource requirement information, the calculation complexity and the real-time requirement of the target shared object library file are determined; According to the calculation complexity, the real-time requirement, the device state information and the connection state information, a target score is determined; When the target score exceeds a threshold value, a calling strategy in which the target shared object library file is called by the cloud end is generated; When the target score does not exceed the threshold value, a calling strategy in which the target shared object library file is called by the device end is generated.

3. The method of claim 1, wherein, The method further comprises the following steps: The communication connection between the device end and the cloud end is detected; When the communication connection between the device end and the cloud end is interrupted, a calling strategy in which the target shared object library file is called by the device end is generated.

4. The method of claim 1, wherein, When the calling strategy is the calling strategy in which the target shared object library file is called by the cloud end, according to the calling strategy, the target shared object library file is called by the device end and / or the cloud end, and comprises the following steps: The device end determines first change information of the target shared object library file, and uploads the first change information to the cloud end; the cloud end is used for calling an adjusted target shared object library file to generate result information after adjusting the target shared object library file according to the first change information; The result information returned by the cloud end is received.

5. The method of claim 4, wherein, The method further comprises the following steps: Second change information returned by the cloud end is received, the second change information is generated by the cloud end according to the target shared object library file after the result information is generated; The target shared object library file is adjusted according to the second change information.

6. A method for invoking a shared object library in a local cloud collaboration, the method comprising: The method is applied to a cloud end, the cloud end is in communication connection with a device end, and the method comprises the following steps: Connection state information of the communication connection between the device end and the cloud end is determined, and the connection state information is sent to the device end; the device end is used for determining a target shared object library file to be called when a shared object library calling event is triggered, and determining resource requirement information of the target shared object library file; device state information of the device end is acquired; according to the resource requirement information, the device state information and the connection state information, a calling strategy for the target shared object library file is determined; The calling strategy for the target shared object library file is determined according to the resource requirement information, the device state information and the connection state information, and comprises the following steps: When the calling strategy is a calling strategy that the cloud calls the target shared object library file, calling the target shared object library file.

7. The method of claim 6, wherein, The cloud is deployed with a function warehouse, and the function warehouse stores a plurality of shared object library files, and the calling the target shared object library file comprises: Determining the device architecture of the device end, and obtaining the target shared object library file from the function warehouse according to the device architecture; According to the device architecture, an execution environment is constructed, and the target shared object library file is called in the execution environment.

8. The method of claim 6, wherein, The calling the target shared object library file comprises: Receiving the first change information of the target shared object library file uploaded by the device end, and after adjusting the target shared object library file according to the first change information, calling the adjusted target shared object library file to generate result information; The result information is sent to the device end.

9. The method of claim 8, wherein, The method further comprises: According to the target shared object library file after generating the result information, generating second change information; The second change information is sent to the device end; the device end is used to adjust the target shared object library file according to the second change information.

10. A local cloud collaborative shared object library calling apparatus, characterized in that, Applied to the device end, the device end is in communication connection with the cloud, and the device comprises: A first information determination module is configured to determine the target shared object library file to be called and determine the resource requirement information of the target shared object library file when a shared object library calling event is triggered; An information acquisition module is configured to acquire device state information of the device end and connection state information of the communication connection between the device end and the cloud; A strategy determination module is configured to determine a calling strategy for the target shared object library file according to the resource requirement information, the device state information and the connection state information; A first execution module is configured to call the target shared object library file by the device end and / or the cloud according to the calling strategy.

11. A local cloud collaborative shared object library calling apparatus, characterized in that, Applied to the cloud, the cloud is in communication connection with the device end, and the device comprises: A second information determination module is configured to determine connection state information of the communication connection between the device end and the cloud, and send the connection state information to the device end; the device end is configured to determine a target shared object library file to be called and determine resource requirement information of the target shared object library file when a shared object library calling event is triggered, acquire device state information of the device end, and determine a calling strategy for the target shared object library file according to the resource requirement information, the device state information and the connection state information; A second execution module is configured to call the target shared object library file when the calling strategy is a calling strategy that the cloud calls the target shared object library file.

12. An electronic device, comprising: A computer program stored on the memory and capable of running on the processor, when executed by the processor, implements the local cloud cooperative shared object library calling method according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method for invoking the shared object library of the local cloud collaboration according to any one of claims 1 to 9.

Images