Software calling control method and device, intelligent equipment, storage medium and program product

Abstract

The invention discloses a software calling control method and device, intelligent equipment, a storage medium and a program product, relates to the technical field of system architecture, is applied to the intelligent equipment and comprises the steps that when a first upper-layer service of the intelligent equipment initiates a calling request for a target bottom-layer function, the target bottom-layer function is called; obtaining a target declaration type pre-declarated by at least one upper layer service for the target bottom layer function; if the target declaration type is a takeover declaration, intercepting the calling request, redirecting the calling request to a second upper-layer service which sends the takeover declaration, and replacing original execution logic for the target bottom-layer function in the first upper-layer service with new execution logic for the target bottom-layer function in the second upper-layer service; and calling the target underlying function through the new execution logic. According to the method, a technical path for carrying out software differentiation development on the basis of the same hardware is provided for an intelligent equipment manufacturer, and the difficulty of product homogenization caused by dependence on a standardized underlying scheme is effectively broken through.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system architecture, and particularly relates to a software call control method, a software call control device, an intelligent device, a storage medium and a computer program product. BACKGROUND

[0002] At present, software development of intelligent devices (such as mobile phones and televisions) highly depends on a complete set of ready-made software and hardware solutions provided by chip manufacturers, including hardware design references, adapted operating systems, standard drivers and basic system services. Although the use of a complete set of ready-made software and hardware solutions can significantly reduce the development difficulty and cost of device manufacturers and ensure the stability of the basic performance of intelligent devices, there are problems that different brands of intelligent devices are increasingly converging in function, user experience and even performance optimization. Intelligent device manufacturers are difficult to independently define and differentially develop the functions of intelligent devices without modifying the underlying system code, that is, function development is difficult to break away from the dependence on underlying implementation, which eventually leads to different brands of intelligent devices becoming the same, and the homogenization between products of different brands is serious.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a software call control method, a software call control device, an intelligent device, a storage medium and a computer program product, which aims to solve the technical problem that the function development of products of different brands is difficult to break away from the dependence on underlying implementation caused by conventional solutions.

[0005] To achieve the above purpose, the present application provides a software call control method applied to an intelligent device, which comprises the following steps: When a first upper layer service of the intelligent device initiates a call request for a target underlying function, a target declaration type declared by at least one upper layer service for the target underlying function is acquired; If the target declaration type is a takeover declaration, the call request is intercepted, the call request is redirected to a second upper layer service issuing the takeover declaration, and a new execution logic of the second upper layer service for the target underlying function replaces an original execution logic of the first upper layer service for the target underlying function; The target underlying function is called through the new execution logic.

[0006] In an embodiment, after the step of redirecting the call request to the second upper layer service issuing the takeover declaration, the method further comprises the following steps: The call request and the call parameters associated with the call request are sent to the second upper-layer service through the communication channel established with the second upper-layer service; Through the communication channel, the processing result returned by the new execution logic of the target underlying function called by the second upper-layer service is received.

[0007] In one embodiment, the step of redirecting the call request to the second upper-layer service that issued the takeover declaration includes: Based on the function identifier of the target underlying function, query the service identifier of the second upper-layer service in the preset declaration registration center that is associated with the function identifier and whose declaration type is takeover declaration; Based on the service identifier, the call request is redirected to the second upper-layer service.

[0008] In one embodiment, after the step of obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: If the target declaration type is a listener declaration, then when the target underlying function is called through the original execution logic of the target underlying function in the first upper-layer service, the call information of the target underlying function will be sent to the third upper-layer service that issued the listener declaration.

[0009] In one embodiment, prior to the step of obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: Receive a declaration request from at least one upper-layer service, wherein the declaration request includes a function identifier of the target underlying function to be declared, the expected declaration type, and the service identifier of the upper-layer service issuing the declaration; Based on the function identifier, the declaration type, and the service identifier, a declaration request record is generated and recorded in a preset declaration registration center.

[0010] In one embodiment, when there are multiple upper-layer services issuing takeover declarations for the target underlying function, the method further includes: Obtain arbitration reference information from each upper-level service that issued a takeover declaration; The arbitration reference information is processed based on preset arbitration rules to generate an arbitration decision, and a second upper-level service is determined from multiple upper-level services that have issued takeover declarations based on the arbitration decision.

[0011] Furthermore, to achieve the above objectives, this application also proposes a software invocation control device for use in smart devices, the software invocation control device comprising: The acquisition module is used to acquire the target declaration type pre-declared by at least one upper-layer service for the target underlying function when the first upper-layer service of the smart device initiates a call request for the target underlying function; The replacement module is used to redirect the call request to the second upper-layer service that issued the takeover declaration if the target declaration type is a takeover declaration, and replace the original execution logic of the target underlying function in the first upper-layer service with the new execution logic of the target underlying function in the second upper-layer service. The calling module is used to invoke the target underlying function through the new execution logic.

[0012] In addition, to achieve the above objectives, this application also proposes an intelligent device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the software invocation control method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the software call control method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the software call control method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: In conventional technologies, equipment manufacturers rely heavily on chip manufacturers' complete off-the-shelf hardware and software solutions, which limits product function development to fixed underlying implementations, making it difficult to achieve independent and differentiated function development, and ultimately leading to a serious homogenization dilemma.

[0016] The software call control method of this application enables smart device manufacturers to independently define and implement differentiated function development without modifying the underlying system code. Specifically, when a first upper-layer service of a smart device initiates a call request to a target underlying function, it obtains the target declaration type pre-declared by at least one upper-layer service for that target underlying function. If the target declaration type is a takeover declaration, the call request is intercepted and redirected to the second upper-layer service that issued the takeover declaration. The new execution logic for the target underlying function in the second upper-layer service replaces the original execution logic for the target underlying function in the first upper-layer service, and finally, the call to the target underlying function is completed through the new execution logic.

[0017] The above method enables smart device manufacturers to flexibly declare the takeover of specific underlying functions through upper-layer services. This replaces the execution paths that previously relied on fixed implementations by chip manufacturers with newly developed execution logic, achieving autonomy and customizability in function implementation without affecting the stability of the underlying system. In this way, this application provides smart device manufacturers with a technical path for differentiated software development on the same hardware foundation, effectively breaking the product homogenization dilemma caused by reliance on standardized underlying solutions. This allows smart device manufacturers to quickly iterate on unique features based on their own needs, enhancing their software competitiveness. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating an embodiment of the software call control method of this application. Figure 1 ; Figure 2 A flowchart illustrating an embodiment of the software call control method of this application. Figure 2 ; Figure 3 A flowchart illustrating an embodiment of the software call control method of this application. Figure 3 ; Figure 4 This is a schematic diagram of the module structure of the software call control device in this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the software call control method of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] It should be noted that the executing entity in this embodiment can be a system service framework or software system in a smart device (such as a smartphone, smart TV, smart wearable device, or smart vehicle system), or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, server, or embedded system capable of implementing the above functions. The following description uses a software system as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, embodiments of this application provide a software call control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the software call control method of this application.

[0026] In this embodiment, applied to a smart device, the software call control method includes steps S1~S3: Step S1: When the first upper-layer service of the smart device initiates a call request to the target underlying function, obtain the target declaration type pre-declared by at least one upper-layer service for the target underlying function; In one feasible embodiment, when a first upper-layer service in a smart device initiates a call request to a target lower-layer function, the software system responds to the call request and performs an operation to obtain the declared type.

[0027] Optionally, the first upper-layer service refers to the software entity in the smart device that originally initiated the call to the target underlying function, such as a system application provided by the chip manufacturer.

[0028] Optionally, the target underlying function refers to a specific capability provided by hardware or underlying drivers in a smart device, such as image processing, audio decoding, or sensor data reading.

[0029] Optionally, a call request is an instruction or message issued by an upper-layer service when it requests the execution of a target lower-layer function.

[0030] Optionally, the software system can obtain the target declaration type pre-declared by at least one upper-layer service for the target underlying function being invoked by querying a preset declaration registry.

[0031] Optionally, the declaration type is an identifier actively registered by the upper-layer service, which may include takeover declarations and listener declarations, used to indicate what processing strategy (takeover processing or listener processing) the software system should take when the target underlying function is called.

[0032] Step S2: If the target declaration type is a takeover declaration, then the call request is intercepted and redirected to the second upper-level service that issued the takeover declaration. The new execution logic of the target's underlying function in the second upper-level service replaces the original execution logic of the target's underlying function in the first upper-level service. In one feasible embodiment, if the target declaration type obtained by the software system is a takeover declaration, the software system will initiate a call interception and routing mechanism.

[0033] Alternatively, a takeover declaration is one type of declaration that indicates another upper-level service, i.e., a second upper-level service, intends to take over the processing of the target's underlying functionality.

[0034] Optionally, the software system intercepts call requests for target underlying functions that should have been sent directly from the first upper-layer service to the underlying hardware. Specifically, the software system intercepts these requests through call interception logic embedded in the call path. This call interception logic monitors the call flow in real time and triggers interception processing when a target call is detected.

[0035] Optionally, after intercepting the call request, the software system performs a call request redirection operation, that is, the intercepted call request is sent to a second upper-layer service that has previously issued a takeover declaration for the underlying function of the target, thereby bypassing the original underlying execution path.

[0036] Optionally, the new execution logic customized in the second upper-layer service to achieve differentiated functions will replace the original execution logic expected by the first upper-layer service, which depends on fixed underlying hardware or drivers, thereby realizing functional customization and differentiated experience in smart devices.

[0037] Optionally, the new execution logic is a software algorithm or business rule independently developed by the smart device manufacturer, while the original execution logic refers to the standard hardware function implementation path provided by the chip manufacturer.

[0038] Step S3: Invoke the target underlying function through the new execution logic.

[0039] In one feasible embodiment, after the call request is successfully redirected to the second upper-layer service, the software system calls the target underlying function through the new execution logic provided by the second upper-layer service.

[0040] Optionally, the calling process involves a second upper-layer service driving the underlying hardware or simulating hardware functions at the software level to call the target underlying function. However, it will still ensure that the processing result can be returned to the original caller or other components of the system. But its actual execution path and final effect are controlled by the new execution logic of the second upper-layer service. This achieves the technical effect of allowing the upper-layer software to flexibly define and take over the underlying functions on the same hardware without modifying the underlying code.

[0041] For example, refer to Figure 2 Step 1: The first upper-layer service of the smart device initiates a call request to the target underlying function. Since the second upper-layer service has pre-declared a takeover declaration for this target underlying function, the call request is intercepted. Step 2: The intercepted call request is redirected to the second upper-layer service that declared the takeover declaration. Step 3: The second upper-layer service uses its internal new execution logic to ultimately drive and invoke the target underlying function, thus achieving a differentiated functional experience on the same hardware. Step 4: The target underlying function returns the execution result to the first upper-layer service that initiated the call, through the second upper-layer service, thus completing a complete takeover scheme transparent to the original caller.

[0042] This embodiment provides a software call control method. When a first upper-layer service of a smart device initiates a call request to a target underlying function, it obtains the target declaration type pre-declared by at least one upper-layer service for that target underlying function. If the target declaration type is a takeover declaration, the call request is intercepted and redirected to the second upper-layer service that issued the takeover declaration. The new execution logic for the target underlying function in the second upper-layer service replaces the original execution logic for the target underlying function in the first upper-layer service, and finally, the call to the target underlying function is completed through the new execution logic. This method allows smart device manufacturers to flexibly declare the takeover of specific underlying functions through upper-layer services, thereby replacing the execution path that originally relied on fixed implementations by chip manufacturers with self-developed new execution logic. This achieves autonomy and customizability of function implementation without affecting the stability of the underlying system. In this way, this application provides smart device manufacturers with a technical path for differentiated software development on the same hardware foundation, effectively breaking the product homogenization dilemma caused by reliance on standardized underlying solutions. This allows smart device manufacturers to quickly iterate on unique functions based on their own needs, enhancing their software competitiveness.

[0043] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Furthermore, after step S2, which redirects the call request to the second upper-layer service that issued the takeover declaration, the method further includes: Step S21: Send the call request and the call parameters associated with the call request to the second upper-layer service through the communication channel established with the second upper-layer service; In one feasible embodiment, after the software system redirects the call request to the second upper-layer service that issued the takeover declaration, the software system performs the step of transferring data through the established communication channel.

[0044] Optionally, the communication channel is an information transmission path pre-built by the software system to achieve reliable data exchange between the interception layer and the upper-layer service. This communication channel ensures that the call request and call-related data can be accurately and efficiently delivered to the second upper-layer service. The interception layer is a software-defined call interception and routing logic layer embedded in the underlying function call path by the software system. It is used to dynamically intercept call requests and make intelligent routing decisions based on the declaration type.

[0045] Optionally, the interception layer can be located on the call path between the system service framework and the hardware abstraction layer. It is used to monitor the call flow in real time, query the declaration registry center, and perform corresponding redirection or listening operations based on the query results. The software system decouples business logic from the underlying implementation through the interception layer, providing flexible functional intervention capabilities for upper-layer services.

[0046] Optionally, the software system may use this communication channel to send the previously intercepted call request, along with the call parameters associated with that call request, to the second upper-layer service.

[0047] Optionally, the calling parameters refer to the data information sent along with the calling request, including specific data, configuration information or execution context required to trigger the execution of the target underlying function, such as resolution and color format parameters in image processing instructions, or sampling rate and precision settings in sensor reading instructions. The calling parameters are the information input necessary for the new execution logic in the second upper-layer service to run correctly.

[0048] Optionally, the communication channel established by the software system can be implemented using various inter-process communication mechanisms, such as Binder communication, Socket communication, or message queues. The specific implementation depends on the operating system and architecture characteristics of the smart device. Understandably, the communication channel needs to possess high reliability, low latency, and secure transmission characteristics to ensure the real-time performance and accuracy of the call redirection process.

[0049] Optionally, during data transmission, the software system is also responsible for maintaining the integrity of the calling context, ensuring that the second-layer service can correctly understand the calling intent and execution environment. The entire redirection and data transfer process is transparent to the first-layer service, maintaining compatibility with the original interface while enabling deep functional customization.

[0050] Step S22: Receive the processing result returned by the new execution logic call to the target underlying function from the second upper-layer service through the communication channel.

[0051] In one feasible embodiment, the software system continues to perform the operation of receiving processing results through the communication channel.

[0052] Optionally, the new execution logic of the second upper-layer service for the target underlying function will complete the corresponding calculation or processing process based on the received call request and call parameters.

[0053] Optionally, the processing result is the output data generated after the new execution logic completes the processing of the target's underlying function, such as image frame data processed by a software algorithm, or a status signal indicating that a function call has been successfully executed.

[0054] Optionally, the software system receives the processing result returned by this second upper-layer service through a communication channel.

[0055] Understandably, once the complete call process is completed and taken over by the upper-layer service, the software system not only hands over the execution rights to the second upper-layer service, but also receives the final processing result, thus enabling the original call initiator to obtain the expected call feedback, even though the underlying implementation path has been completely replaced.

[0056] Optionally, the return of the processing result makes the entire takeover process transparent and compatible with the original caller, maintaining the stability of the interfaces between software modules.

[0057] In one feasible implementation, step S2, which involves redirecting the call request to the second upper-layer service that issued the takeover declaration, includes: Step S23: Based on the function identifier of the target underlying function, query the service identifier of the second upper-layer service in the preset declaration registry that is associated with the function identifier and whose declaration type is takeover declaration. In one feasible embodiment, when the software system determines that a call request needs to be redirected, it performs a step of querying based on the function identifier of the target underlying function.

[0058] Optionally, the function identifier of the target underlying function is a string or code used to uniquely identify that specific underlying capability within the software system, such as an enumeration value or hash value representing "image post-processing".

[0059] Optionally, the software system uses this function identifier as a query index to perform retrieval in a preset declaration registry.

[0060] Optionally, the default declaration registry is a storage component that records all declaration request records submitted in advance by upper-layer services. Each declaration request record is associated with a function identifier, declaration type, and the service identifier of the upper-layer service that made the declaration.

[0061] Understandably, the purpose of the software system query is to find the declaration request record that is associated with the function identifier and whose declaration type is clearly a takeover declaration, so as to determine the service identifier of the second upper-level service that made the takeover declaration from the declaration request record.

[0062] Optionally, the service identifier can uniquely identify the second upper-layer service.

[0063] Step S24: Based on the service identifier, redirect the call request to the second upper-layer service.

[0064] In one feasible embodiment, after successfully obtaining the service identifier of the second upper-layer service, the software system performs a redirection step based on the service identifier.

[0065] Optionally, the software system uses the service identifier to accurately locate the location or access path of the target service instance (i.e., the second upper-layer service).

[0066] Optionally, the software system may forward the original call request, which was initially initiated and intercepted by the first upper-layer service, to the corresponding second upper-layer service according to the path indicated by the service identifier.

[0067] Understandably, redirection is when a software system dynamically modifies the destination of a call request at runtime, thereby shifting control and execution of the underlying functionality of that target from the default underlying hardware path to custom software logic carried by a second-level service.

[0068] Optionally, the entire process relies on the declaration request records maintained by the declaration registry center, which enables flexible configuration and dynamic resolution of call routes. This allows the function takeover behavior to be managed and changed through declarations, rather than being hard-coded in the underlying code.

[0069] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. In addition, after step S1, which involves obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: Step S10: If the target declaration type is a listener declaration, then when the target underlying function is called through the original execution logic of the target underlying function in the first upper-layer service, the call information of the target underlying function is sent to the third upper-layer service that issued the listener declaration.

[0070] In one feasible embodiment, after the software system obtains the target declaration type for the target underlying function, if the target declaration type is determined to be a listening declaration, the software system will perform a parallel information transmission operation.

[0071] Optionally, a listener declaration is a specific type of declaration that indicates that a certain upper-level service, namely the third upper-level service that issued the declaration, intends to be aware of the occurrence of the target's underlying function being called and its context information without interfering with the original execution flow.

[0072] Optionally, the software system will not intercept or change the original call execution path, allowing the first upper-layer service to continue to call the target lower-layer function through its original execution logic of the target lower-layer function.

[0073] Optionally, the original execution logic refers to the default function implementation path provided by the chip manufacturer that directly drives the underlying hardware or uses standard system services.

[0074] Optionally, during this parallel process, the software system captures the call information of this call to the target's underlying functions in real time.

[0075] Optionally, the call information is a data set containing details related to this call event, such as the timestamp of the call, the identity of the first upper-layer service that initiated the call, the specific parameter values ​​passed to the target underlying function, and context data such as the possible call sequence number.

[0076] Optionally, the software system may send the call information to the third upper-layer service that issued the listening declaration through a pre-established communication mechanism (i.e., another communication channel).

[0077] Understandably, the third upper-layer service can transparently perceive the real-time status of the underlying function being called, and can perform recording, statistical analysis, state synchronization or other auxiliary operations based on this call information, without affecting the original call request of the first upper-layer service or its final execution result.

[0078] Optionally, this monitoring mechanism provides a non-intrusive observation capability for upper-layer services, enabling functional monitoring, data collection, or system behavior analysis.

[0079] In one feasible implementation, prior to step S1, which involves obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: Step S11: Receive a declaration request from at least one upper-layer service, wherein the declaration request includes the function identifier of the target underlying function to be declared, the expected declaration type, and the service identifier of the upper-layer service issuing the declaration. In one feasible embodiment, before the software system can process the call request based on the declaration of the upper-layer service, it is necessary to complete the registration and collection of declaration information, which is achieved by receiving declaration requests and recording the declaration request records.

[0080] Optionally, the software system receives a declaration request from at least one upper-layer service, which is a registration intention form proactively submitted by the upper-layer service to the software system, indicating what type of processing strategy it wishes to apply to a particular underlying function.

[0081] Optionally, the declaration request includes several key elements: the function identifier of the target underlying function to be declared, a keyword or code used to uniquely identify the target underlying capability within the software system; the desired declaration type, i.e. the processing strategy selected by the upper-layer service, such as "takeover" or "listen"; and the service identifier of the upper-layer service issuing the declaration, used to uniquely locate and identify the address or name of the upper-layer service within the software system.

[0082] Understandably, the software system receives the declaration request, providing the necessary strategic basis for subsequent call interception and routing.

[0083] Step S12: Based on the function identifier, declaration type, and service identifier, a declaration request record is generated and the declaration request is recorded in the preset declaration registration center.

[0084] In one feasible embodiment, upon receiving a declaration request, the software system performs the steps of forming a declaration request record based on the content of the declaration request and storing the declaration request record.

[0085] Optionally, the software system will extract the function identifier, declaration type, and service identifier contained in the declaration request, and organize the function identifier, declaration type, and service identifier according to a predetermined format to form a structured declaration request record.

[0086] Optionally, the software system stores the declaration request records in a pre-defined declaration registry.

[0087] Optionally, the default declaration registry is a database or configuration center that is internal to the software system or connected to a smart device, used to centrally store and manage all declaration relationships. The declaration registry records the declaration types that all upper-layer services have pre-declared for each lower-layer function.

[0088] Understandably, through this implementation method, the software system establishes and maintains a global, queryable declaration policy mapping table (i.e., the mapping relationship between the target underlying function identifier, the upper-level service identifier, and the declaration type). This enables the software system to quickly determine whether there is a declaration for calling the underlying function and the specific type of the declaration by querying this declaration registry center when any underlying function is called subsequently, thereby driving the corresponding interception, redirection, or notification behavior.

[0089] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Furthermore, when there are multiple upper-layer services issuing takeover declarations for the target underlying function, the method further includes the following steps: Step D1: Obtain arbitration reference information from each upper-level service that issued a takeover declaration; In one feasible embodiment, when the software system queries the declaration registry and finds that there are multiple upper-layer services that have issued takeover declarations for the current target underlying function, the software system initiates an arbitration decision in order to determine which upper-layer service should ultimately execute the takeover logic.

[0090] Optionally, the software system obtains arbitration reference information from each upper-layer service that issued a takeover declaration. The arbitration reference information is metadata or attribute information used to assist the software system in making a ruling, including but not limited to the priority value pre-configured for each upper-layer service, the timestamp of its registered takeover declaration, the importance tag of the functional module to which the service belongs, or the current health status and load of the service.

[0091] Optionally, the software system can collect arbitration reference information from various candidate upper-layer services by accessing additional fields stored in the declaration registry or by querying relevant services in real time.

[0092] Step D2: Process the arbitration reference information based on the preset arbitration rules, generate an arbitration decision, and determine the second upper-level service from multiple upper-level services that have issued takeover declarations based on the arbitration decision.

[0093] In one feasible embodiment, after collecting arbitration reference information from all relevant upper-layer services, the software system executes an arbitration decision based on preset arbitration rules.

[0094] Optionally, the preset arbitration rules are predefined logical judgment criteria used to guide how to compare and process the collected arbitration reference information.

[0095] Optionally, the preset arbitration rules can stipulate "selecting the upper-level service with the highest priority value", "selecting the upper-level service with the earliest registration declaration time", or a weighted scoring algorithm.

[0096] For example, the weighted scoring algorithm can be based on a multi-factor weighted evaluation algorithm, whereby the software system calculates a comprehensive score for each upper-layer service that issues a takeover declaration. Specifically, the comprehensive score = priority weight × priority value + time weight × normalized registration time + importance weight × importance value + health weight × health status index + load weight × (1 - normalized load value). The priority weight, time weight, importance weight, health weight, and load weight are preset constant values ​​that sum to 1. For example, the priority weight is set to 0.4, the time weight to 0.2, the importance weight to 0.2, the health weight to 0.1, and the load weight to 0.1. The priority value is pre-configured by the upper-layer service; a higher value indicates a higher priority. The normalized registration time is converted into a ratio relative to the earliest registration time (earliest registration time corresponds to 1, latest registration time corresponds to 0). The importance value is mapped according to the label of the functional module to which the service belongs (e.g., "high" is mapped to 1, "medium" to 0.5, and "low" to 0.2). A health status index of 1 indicates that the service is healthy and available, and 0 indicates that it is unhealthy. The normalized load value is converted into a ratio relative to the maximum load capacity (the lower the load, the smaller the value). After calculating the comprehensive score of each service, the software system selects the upper-layer service with the highest score as the second upper-layer service.

[0097] Optionally, the software system can use preset arbitration rules to calculate and evaluate the various arbitration reference information obtained, and generate an arbitration decision.

[0098] Optionally, the arbitration decision specifies the only upper-level service that should be selected to perform the takeover operation in the current conflict scenario, namely the second upper-level service to be determined.

[0099] Understandably, in this embodiment, the software system selects the final executor from multiple candidate upper-layer services that have issued takeover declarations based on this arbitration decision. This ensures that when faced with multiple takeover intentions, the call request can be redirected deterministically and orderly, avoiding routing conflicts or undefined behavior, and guaranteeing the stability and determinism of the entire interception and routing mechanism.

[0100] For example, please refer to Figure 3 The first upper-layer service initiates a call request to a specific underlying function. Then, based on the function identifier of that underlying function, it queries the declaration registry to determine the target declaration type for that underlying function. Different processing strategies are then executed based on the retrieved target declaration type.

[0101] If the target declaration type is a takeover declaration, the call request is intercepted and redirected to the second upper-level service that issued the takeover declaration. The new execution logic in the second upper-level service replaces the original execution logic of the target's underlying function, and the target's underlying function is called through the new execution logic.

[0102] If the target declaration type is a listener declaration, then while processing the call to the target's underlying function through the original execution logic, the call information of this call event will be sent to the third upper-layer service that issued the listener declaration for recording and analysis.

[0103] Through the above process, based on the pre-declared configuration, dynamic control of underlying function calls is achieved, enabling flexible takeover or seamless monitoring of functions, effectively breaking the product homogenization dilemma caused by reliance on standardized underlying solutions.

[0104] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the software call control method of this application. Many simple variations based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0105] This application also provides a software call control device, please refer to... Figure 4 Applied to smart devices, the software call control device includes: The acquisition module 10 is used to acquire the target declaration type pre-declared by at least one upper-layer service for the target underlying function when the first upper-layer service of the smart device initiates a call request for the target underlying function; The replacement module 20 is used to redirect the call request to the second upper-layer service that issued the takeover declaration if the target declaration type is a takeover declaration, and replace the original execution logic of the target underlying function in the first upper-layer service with the new execution logic of the target underlying function in the second upper-layer service. Module 30 is invoked to invoke the target underlying function through the new execution logic.

[0106] Optionally, the alternative module 20 is further configured to send the call request and the call parameters associated with the call request to the second upper-layer service through a communication channel established with the second upper-layer service; Through the communication channel, the processing result returned by the new execution logic of the target underlying function called by the second upper-layer service is received.

[0107] Optionally, the alternative module 20 is further configured to query, based on the function identifier of the target underlying function, the service identifier of the second upper-layer service associated with the function identifier and whose declaration type is takeover declaration in a preset declaration registration center; Based on the service identifier, the call request is redirected to the second upper-layer service.

[0108] Optionally, the software call control device further includes a listening module, which, if the target declaration type is a listening declaration, sends the call information of the target underlying function to the third upper-layer service that issued the listening declaration when the target underlying function is called through the original execution logic of the target underlying function in the first upper-layer service.

[0109] Optionally, the acquisition module 10 is further configured to receive a declaration request from at least one upper-layer service, wherein the declaration request includes a function identifier of the target underlying function to be declared, the expected declaration type, and the service identifier of the upper-layer service issuing the declaration. Based on the function identifier, the declaration type, and the service identifier, a declaration request record is generated and recorded in a preset declaration registration center.

[0110] Optionally, the software invocation control device further includes an arbitration module for obtaining arbitration reference information from each upper-level service that issued a takeover declaration; The arbitration reference information is processed based on preset arbitration rules to generate an arbitration decision, and a second upper-level service is determined from multiple upper-level services that have issued takeover declarations based on the arbitration decision.

[0111] The software call control device provided in this application, employing the software call control method in the above embodiments, can solve the technical problem that conventional solutions make it difficult for the functional development of various brands' products to escape dependence on the underlying implementation. Compared with the prior art, the beneficial effects of the software call control device provided in this application are the same as those of the software call control method provided in the above embodiments, and other technical features in the software call control device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a smart device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the software call control method in the first embodiment described above.

[0113] The following is for reference. Figure 5The diagram illustrates a structural schematic suitable for implementing the embodiments of this application. The intelligent devices in the embodiments of this application may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The smart device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 5 As shown, the smart device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the smart device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the smart device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagram shows smart devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The intelligent device provided in this application, employing the software call control method described in the above embodiments, can solve the technical problem that conventional solutions make it difficult for the functional development of various brands' products to escape dependence on the underlying implementation. Compared with the prior art, the beneficial effects of the intelligent device provided in this application are the same as those of the software call control method provided in the above embodiments, and other technical features of this intelligent device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the software call control method in the above embodiments.

[0120] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable storage medium may be included in a smart device; or it may exist independently and not be assembled into a smart device.

[0122] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0125] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described software invocation control method. This solves the technical problem that conventional solutions make it difficult for the functional development of various brands' products to escape dependence on the underlying implementation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the software invocation control method provided in the above embodiments, and will not be repeated here.

[0126] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the software call control method described above.

[0127] The computer program product provided in this application can solve the technical problem that conventional solutions make it difficult for the functional development of various brands of products to break free from their dependence on the underlying implementation. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the software call control method provided in the above embodiments, and will not be repeated here.

[0128] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A software call control method, characterized in that, Applied to smart devices, the software call control method includes: When the first upper-layer service of the smart device initiates a call request to the target lower-layer function, the target declaration type is obtained by at least one upper-layer service for the target lower-layer function in advance; If the target declaration type is a takeover declaration, then the call request is intercepted, the call request is redirected to the second upper-layer service that issued the takeover declaration, and the new execution logic of the target underlying function in the second upper-layer service replaces the original execution logic of the target underlying function in the first upper-layer service. The target underlying function is invoked through the new execution logic.

2. The method as described in claim 1, characterized in that, Following the step of redirecting the call request to the second upper-layer service that issued the takeover declaration, the method further includes: The call request and the call parameters associated with the call request are sent to the second upper-layer service through the communication channel established with the second upper-layer service; Through the communication channel, the processing result returned by the new execution logic of the target underlying function called by the second upper-layer service is received.

3. The method as described in claim 1, characterized in that, The step of redirecting the call request to the second upper-layer service that issued the takeover declaration includes: Based on the function identifier of the target underlying function, query the service identifier of the second upper-layer service in the preset declaration registration center that is associated with the function identifier and whose declaration type is takeover declaration; Based on the service identifier, the call request is redirected to the second upper-layer service.

4. The method as described in claim 1, characterized in that, Following the step of obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: If the target declaration type is a listener declaration, then when the target underlying function is called through the original execution logic of the target underlying function in the first upper-layer service, the call information of the target underlying function will be sent to the third upper-layer service that issued the listener declaration.

5. The method as described in claim 1, characterized in that, Prior to the step of obtaining the target declaration type pre-declared by at least one upper-layer service for the target underlying function, the method further includes: Receive a declaration request from at least one upper-layer service, wherein the declaration request includes a function identifier of the target underlying function to be declared, the expected declaration type, and the service identifier of the upper-layer service issuing the declaration; Based on the function identifier, the declaration type, and the service identifier, a declaration request record is generated and recorded in a preset declaration registration center.

6. The method as described in claim 1, characterized in that, When there are multiple upper-layer services issuing takeover declarations for the target underlying function, the method further includes: Obtain arbitration reference information from each upper-level service that issued a takeover declaration; The arbitration reference information is processed based on preset arbitration rules to generate an arbitration decision, and a second upper-level service is determined from multiple upper-level services that have issued takeover declarations based on the arbitration decision.

7. A software-invoking control device, characterized in that, Applied to smart devices, the software call control device includes: The acquisition module is used to acquire the target declaration type pre-declared by at least one upper-layer service for the target underlying function when the first upper-layer service of the smart device initiates a call request for the target underlying function; The replacement module is used to redirect the call request to the second upper-layer service that issued the takeover declaration if the target declaration type is a takeover declaration, and replace the original execution logic of the target underlying function in the first upper-layer service with the new execution logic of the target underlying function in the second upper-layer service. The calling module is used to invoke the target underlying function through the new execution logic.

8. A smart device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the software invocation control method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the software invocation control method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the software invocation control method as described in any one of claims 1 to 6.

Images