Interface calling method and device, terminal, storage medium and program product

Abstract

The application discloses an interface calling method and device, a terminal, a storage medium and a program product, and belongs to the technical field of terminals. The method comprises the following steps: in the case that a first view object has a calling demand for target business data corresponding to a second view object, acquiring a target key value based on the target business data, the first view object being a sub-view object in the second view object, and the target key value being unique; based on the target key value, searching for a target inversion of control IoC interface from a global interface registration center, and the global interface registration center storing a corresponding relationship between at least one candidate IoC interface and a candidate key value; and calling the target IoC interface through the first view object to acquire the target business data corresponding to the second view object. The method can omit a transmission link between upper view objects and lower view objects in the process of using the IoC interface, and improves the use efficiency of the IoC interface.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an interface calling method, device, terminal, storage medium and program product. Background Technology

[0002] During application development, application pages have complex view hierarchies. For example, the view hierarchy of an application page might be: View1>View2>View3>View4>View5>View6>View7, meaning that View1 contains View2, View2 contains View3, View3 contains View4, and so on, with View6 containing View7.

[0003] During application page display, lower-level views need to know the context and other data of upper-level views during creation and display. For example, view7 needs to know the context and other data of view1 during operation. In related technologies, view1 implements an IoC interface. When view7 needs to access the corresponding context and other data from view1, view1 can pass the IoC interface down the view hierarchy to view7, allowing view7 to call the IoC interface to obtain the context and other data from view1.

[0004] Clearly, when using the IoC interface, the relevant technologies rely on the hierarchical relationship to pass the data to the lower-level user objects. In cases where the page relationships are more complex, this will seriously reduce the efficiency of using the IoC interface. Summary of the Invention

[0005] This application provides an interface calling method, apparatus, terminal, storage medium, and program product. The technical solution is as follows:

[0006] According to one aspect of this application, an interface invocation method is provided, the method comprising:

[0007] When the first view object has a call requirement for the target business data corresponding to the second view object, the target key value is obtained based on the target business data. The first view object is a sub-view object in the second view object, and the target key value is unique.

[0008] Based on the target key value, the target Inversion of Control (IoC) interface is searched from the global interface registry center, which stores the correspondence between at least one candidate IoC interface and candidate key value.

[0009] The target IoC interface is invoked through the first view object to obtain the target business data corresponding to the second view object.

[0010] According to another aspect of this application, an interface invocation device is provided, the device comprising:

[0011] The acquisition module is used to acquire a target key value based on the target business data when the first view object has a call requirement for the target business data corresponding to the second view object. The first view object is a sub-view object in the second view object, and the target key value is unique.

[0012] The lookup module is used to search for the target Inversion of Control (IoC) interface from the global interface registry center based on the target key value. The global interface registry center stores the correspondence between at least one candidate IoC interface and candidate key value.

[0013] The calling module is used to call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

[0014] According to one aspect of this application, a terminal is provided, comprising: a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the interface calling method as described above.

[0015] According to another aspect of this application, a computer-readable storage medium is provided, which stores a computer program that is loaded and executed by a processor to implement the interface calling method as described above.

[0016] According to another aspect of this application, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A terminal's processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned interface invocation method.

[0017] The beneficial effects of the technical solutions provided in this application include at least the following:

[0018] This provides a method for invoking IoC interfaces. When a first view object (child view object) needs to call corresponding business data from a second view object (upper-level view object), the first view object can directly search for and call the target IoC interface for calling the target business data from the global interface registry based on the target key value. The entire interface call process does not require the second view object to pass the IoC interface to the first view object. This eliminates the need to consider the complex page structure between the second and first view objects when using the IoC interface, and omits the transmission chain between the upper-level view object and the lower-level view object during the use of the IoC interface, thus improving the efficiency of IoC interface usage. At the same time, it also eliminates the need to develop complex interface transmission functions between pages during development, simplifying development operations and improving development efficiency. Attached Figure Description

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

[0020] Figure 1 This application provides a complex page structure diagram;

[0021] Figure 2 This application illustrates a schematic diagram of an interface call process according to an exemplary embodiment.

[0022] Figure 3 A flowchart illustrating an exemplary embodiment of the present application for an interface invocation method is shown.

[0023] Figure 4 A flowchart of an interface invocation method provided by another exemplary embodiment of this application is shown;

[0024] Figure 5 A schematic diagram illustrating the registration process of an IoC interface is shown in an exemplary embodiment of this application;

[0025] Figure 6 A flowchart of an interface invocation method provided by another exemplary embodiment of this application is shown;

[0026] Figure 7 This illustration shows a schematic diagram illustrating the process of obtaining a target key value in an exemplary embodiment of this application;

[0027] Figure 8 This application shows a complete schematic diagram illustrating the interface call process in an exemplary embodiment.

[0028] Figure 9 This is a structural block diagram of an interface calling device provided in an exemplary embodiment of this application;

[0029] Figure 10 A structural block diagram of a terminal provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0031] First, a brief introduction to the terms used in the embodiments of this application:

[0032] Inversion of Control (IoC) interface: In application development, it is common to encounter situations where lower-level view objects need to obtain data such as the context of upper-level view objects. In order for lower-level view objects to obtain relevant data from upper-level view objects, the IoC interface is implemented in the upper-level view objects. This allows lower-level view objects to obtain the real-time state and data of upper-level view objects by calling the IoC interface.

[0033] In related technologies, in processing such as Figure 1 The interface call process shown in the complex page structure diagram is as follows ( Figure 1 The page structure, from the outermost to the innermost layer, includes View1-View2-View3-View4-View5-View6-View7, with View1 being the outermost and View7 being the innermost. If View7 needs to access contextual information from View1 when it's being displayed, the relevant technologies require passing the IoC interface layer by layer through View1-View2-View3-View4-View5-View6 to View7. Only after View7 receives the passed IoC interface can it use it to access the contextual information of View1. This process of using the IoC interface is quite cumbersome.

[0034] To address the cumbersome use of IoC interfaces in related technologies, this application provides a new method for using IoC interfaces, such as... Figure 2The diagram illustrates an exemplary embodiment of the interface call process according to this application. The upper-layer View 201 registers the IoC interface and its unique key-value pair with the global interface registry 203. When the lower-layer View 202 needs to call the IoC interface, it uses the obtained unique key-value pair to search for the IoC interface in the global interface registry 203 and returns the found IoC interface to the lower-layer View 202. This allows the lower-layer View to directly obtain and use the IoC interface from the global interface registry, eliminating the cumbersome development process of passing the IoC interface layer by layer in complex pages, thereby simplifying development operations and improving development efficiency.

[0035] Please refer to Figure 3 The diagram illustrates a flowchart of an interface invocation method provided in an exemplary embodiment of this application. Taking the application of this method to a terminal as an example, the method includes:

[0036] Step 301: If the first view object has a call requirement for the target business data corresponding to the second view object, obtain the target key value based on the target business data. The first view object is a subview object in the second view object, and the target key value is unique.

[0037] When using the IoC interface to call business data of a higher-level view object, related technologies encounter a problem: since a higher-level view cannot directly communicate with any lower-level view, the IoC interface must be passed layer by layer from the higher-level view to the lower-level view, according to the view hierarchy. For example, the view hierarchy might be: View1>View2>View3>View4>View5>View6>View7, where View1 contains View2, View2 contains View3, View3 contains View4, and so on, up to View6 contains View7. If the IoC interface is implemented in View1, and View7 needs to use the IoC interface to call data from View1, since View1 cannot directly transmit the IoC interface to View7, the IoC interface must be passed from View1 to View2, then to View3, and finally to View7. The more complex the application page (the more nested the view hierarchy), the more cumbersome this layer-by-layer passing method becomes, and the lower the efficiency of using the IoC interface. To address the issue of low efficiency in using IoC interfaces in related technologies, this application maintains a global interface registry center. IoC interfaces can be registered with this center, and each IoC interface corresponds to a unique key-value pair. When a lower-level view object needs to call an IoC interface, it can directly retrieve it from the global interface registry center and use it directly. This eliminates the need for the upper-level view object to pass the IoC interface layer by layer to the lower-level view object, saving time and improving the efficiency of IoC interface usage.

[0038] Since several IoC interfaces are registered in the global interface registry, in order for lower-level view objects to find the required IoC interface from the global interface registry, and since each IoC interface has a unique corresponding key value, in one possible implementation, when the first view object has a call requirement for the target business data corresponding to the second view object, the target key value that can match the target IoC interface used to call the target business data can be obtained based on the target business data to be called, and then the target IoC interface can be found from the global interface registry based on the uniqueness of the target key value.

[0039] The target business data may be the context information corresponding to the second view object; or it may be other view content related to the second view object. The specific content of the target business data is not limited in the embodiments of this application.

[0040] Regarding the process of obtaining target key values ​​based on target business data, since the target IoC interface is used to call target business data of the target type, when distinguishing the key values ​​of different IoC interfaces, the interface types of different IoC interfaces can be defined according to the target type of the target business data called by the target IoC interface, and then the key value can be generated based on the interface type. Correspondingly, when obtaining the target key value in the first view object, the target interface type of the target IoC interface can be determined according to the target business data to be called, and then the target key value can be obtained by matching based on the target interface type.

[0041] It should be noted that the interface calling method provided in this application embodiment is only applicable to scenarios where a lower-level view object calls the business data of a higher-level view object. That is, the first view object is a child view object of the second view object. For example, if the view hierarchy of the target application page is: View1>View2>View3>View4>View5>View6>View7, then the interface calling method provided in this embodiment can be used when View7 calls the business data of View1. However, the interface calling method provided in this embodiment cannot be applied when View4 calls the business data of View7.

[0042] Optionally, for scenarios where the first view object has a business data call requirement for the second view object, the call can be triggered when the first view object is created and displayed, or it can be triggered during the display process. This application embodiment does not limit the timing of the call requirement.

[0043] Step 302: Based on the target key value, search for the target IoC interface from the global interface registry center. The global interface registry center stores the correspondence between at least one candidate IoC interface and candidate key value.

[0044] Since the target key uniquely corresponds to the target IoC interface, and the global interface registry stores the correspondence between several candidate IoC interfaces and candidate key values, in one possible implementation, once the first view object obtains the target key, it can directly search for candidate key values ​​matching the target key value from the global registry based on the target key value, and then determine the candidate IoC interface associated with the candidate key value as the target IoC interface. This allows the first view object to directly obtain the target IoC interface, and the process of obtaining the target IoC interface does not depend on the view object hierarchy, thus improving the efficiency of obtaining and using the target IoC interface.

[0045] Step 303: Call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

[0046] Since the target IoC interface is used to call the target business data corresponding to the second view object, in one possible implementation, once the first view object obtains the target IoC interface, it can obtain the target business data corresponding to the second view object by calling the target IoC interface.

[0047] In summary, this application provides a method for invoking an IoC interface. When a first view object (subview object) has a need to call business data corresponding to a second view object (upper-level view object), the first view object can directly search for and call the target IoC interface for calling the target business data from the global interface registry based on the target key value. The entire interface call process does not require the second view object to pass the IoC interface to the first view object. This eliminates the need to consider the complex page structure between the second and first view objects during the use of the IoC interface, and omits the transmission link between the upper-level view object and the lower-level view object during the use of the IoC interface, thus improving the efficiency of IoC interface usage. At the same time, during development, there is no need to develop complex interface transmission functions between pages, simplifying development operations and improving development efficiency.

[0048] In order to find the target IoC interface required by the lower-level view object from the global interface center, it is necessary to ensure that when the lower-level view object has a need to call the target IoC interface, the global interface center has already registered the mapping relationship between the target IoC interface and the target key value.

[0049] like Figure 4 As shown, a flowchart of an interface invocation method provided in another exemplary embodiment of this application is illustrated. Taking the application of this method to a terminal as an example, the method includes:

[0050] Step 401: Once the second view object is created, generate at least one candidate IoC interface corresponding to the second view object, and candidate key values ​​corresponding to each candidate IoC interface.

[0051] Since the first view object is a subview object of the second view object, the first view object must be created first, followed by the second view object. In order to enable the lower-level subview object to call the business data of the upper-level view object during the creation and display process, in one possible implementation, when the application needs to display the second view object in the foreground, the second view object is created. After the second view object is created, the corresponding IoC interface and unique key-value pair can be generated, and the IoC interface and unique key-value pair can be registered in the global interface registry center. This allows the IoC interface corresponding to the second view object to be called based on the key-value pair during the subsequent creation of or display of the subview object of the second view object.

[0052] Since the second view object corresponds to multiple types of candidate business data, in order to reduce the coupling between different candidate business data, in one possible implementation, candidate IoC interfaces of different interface types can be encapsulated based on the multiple types of candidate business data corresponding to the second view object, and unique candidate key values ​​corresponding to different candidate IoC interfaces can be generated; that is, the second view object may correspond to at least one candidate IoC interface and candidate key value.

[0053] In an exemplary example, the process of generating candidate IoC interfaces and candidate key values ​​may include steps 401A to 401C (that is, step 401 may include steps 401A to 401C).

[0054] Step 401A: Based on at least one type of candidate business data corresponding to the second view object, determine at least one candidate interface type, where different candidate interface types correspond to different types of candidate business data.

[0055] In order to distinguish between different types of candidate business data, in one possible implementation, at least one candidate interface type can be determined based on at least one type of candidate business data corresponding to the second view object, with different candidate interface types corresponding to different types of candidate business data.

[0056] Optionally, different interface types can be directly represented by the type to which different candidate business data belong. For example, if the business data is divided into candidate type 1, candidate type 2 and candidate type 3, the corresponding candidate interface types can be: candidate interface type 1 (corresponding to the business data of candidate type 1), candidate interface type 2 (corresponding to the business data of candidate type 2) and candidate interface type 3 (corresponding to the business data of candidate type 3).

[0057] Step 401B: Create candidate IoC interfaces corresponding to each candidate interface type. Different candidate IoC interfaces are used to call different types of candidate business data.

[0058] In one possible implementation, for each candidate interface type, a candidate IoC interface is created, allowing different candidate IoC interfaces to call different types of candidate business data. For example, if the candidate interface types corresponding to the second view object include: candidate interface type 1 (corresponding to business data of candidate type 1), candidate interface type 2 (corresponding to business data of candidate type 2), and candidate interface type 3 (corresponding to business data of candidate type 3), then the second view object can implement three candidate IoC interfaces: candidate IoC interface 1 (used to call business data of candidate type 1), candidate IoC interface 2 (used to call business data of candidate type 2), and candidate IoC interface 3 (used to call business data of candidate type 3).

[0059] Step 401C: Based on the candidate interface type corresponding to the candidate IoC interface and the Context information of the second view object, generate candidate key-value pairs corresponding to the candidate IoC interface.

[0060] Candidate key values ​​are strings that uniquely identify candidate IoC interfaces. Since the target application maintains several views, and each view may have multiple candidate IoC interfaces, to distinguish between candidate IoC interfaces of different views and different candidate IoC interfaces of the same view, considering that different view objects have different context information and different IoC interfaces of the same view object have different interface types, in one possible implementation, candidate key values ​​for the candidate IoC interfaces corresponding to the candidate IoC interfaces can be generated based on the candidate interface type corresponding to the candidate IoC interface and the context information of the second view object. Specifically, the candidate interface type distinguishes candidate IoC interfaces of different interface types, and the context information distinguishes candidate IoC interfaces of different view objects.

[0061] In the process of generating unique candidate key values ​​based on candidate interface types and Context information, the candidate interface type can be used as the prefix string of the candidate key value, and the Context information can be processed by a hash algorithm to obtain the hash value corresponding to the Context information. Then, the candidate interface type and the hash value corresponding to the Context information can be combined to generate the unique candidate key value corresponding to the candidate IoC interface.

[0062] Step 402: Register the candidate IoC interface and candidate key-value pair to the global interface registry center.

[0063] In order to enable the subview objects under the second view object to find the candidate IoC interface corresponding to the second view object from the global interface registry, in one possible implementation, after the terminal generates the candidate IoC interface and the unique corresponding candidate key value corresponding to the second view object, it can register the candidate IoC interface and the candidate key value with the global interface registry.

[0064] like Figure 5 The diagram illustrates the registration process of an IoC interface according to an exemplary embodiment of this application. After the upper-layer View 501 is created, it can implement the IoC interface and its methods; generate a unique key value based on the interface type and the context of the upper-layer View 501; register the IoC interface and the unique key value in the global interface center 502; and set the unique key value in the tag data 503 of the upper-layer View 501.

[0065] It should be noted that this embodiment only uses the second view object as an example to illustrate the process of registering candidate IoC interfaces and candidate key values ​​in the global interface registry. In the actual operation of the target application, after any view object is created, the candidate IoC interface and candidate key value corresponding to any view object can be registered to the global interface registry in accordance with the above registration process so that other lower-level sub-view objects can call them.

[0066] Optionally, since other view objects only call the corresponding business data after the view object is created, in order to avoid registering other candidate IoC interfaces and candidate key-value pairs that do not need to be called in the global interface registry, it is set that when the view object is created during the target application's runtime, its corresponding candidate IoC interfaces and candidate key-value pairs are registered in the global interface registry. Conversely, if the target application is closed, the candidate IoC interfaces and candidate key-value pairs registered in the corresponding global interface registry will also be deleted, and the candidate IoC interfaces and candidate key-value pairs will be re-registered in the global interface registry after the target application is restarted.

[0067] Step 403: If the first view object has a call requirement for the target business data corresponding to the second view object, determine the target interface type corresponding to the type of the target business data.

[0068] Based on the above registration process of candidate IoC interfaces and candidate key values, it can be clearly seen that there is a certain correspondence between candidate IoC interfaces, candidate interface types, candidate key values, and candidate type business data. Therefore, in one possible implementation, when the first view object has a call requirement for the target business data corresponding to the second view object, the type of the target business data to be called (that is, the target type to which the target business data belongs) can be determined first, and then the target interface type of the target IoC interface to be called can be determined based on the relationship between the type and the interface type.

[0069] Step 404: Obtain the target key-value pair based on the target interface type.

[0070] Since the unique target key value of the target IoC interface is generated by the target interface type, in one possible implementation, once the first view object determines the target interface type of the target IoC interface, it can search for and obtain the target key value corresponding to the target IoC interface based on the target interface type.

[0071] In the process of matching target key values ​​based on target interface type, since the prefix of the target key value is the target interface type, the candidate key values ​​whose key value prefix matches the target interface type can be determined as the target key values.

[0072] It should be noted that for IoC interfaces of the same type, the same type of business data is called, even if the key values ​​corresponding to the IoC interfaces are different (affected by the context information of different view objects); therefore, when obtaining the target key value, you can match only based on the target interface type without needing to obtain the context information of the view object for matching.

[0073] Step 405: If a candidate key value matching the target key value exists in the global interface registration center, the candidate IoC interface corresponding to the candidate key value is determined as the target IoC interface.

[0074] In one possible implementation, when the target key value corresponding to the target IoC interface used to call the target business data is obtained, the target IoC interface corresponding to the target key value can be directly searched from the global interface center. If there is a candidate key value matching the target key value in the global interface center, the candidate IoC interface corresponding to the candidate key value is determined as the target IoC interface and returned to the first view object. If there is no candidate key value matching the target key value in the global interface center, it means that the corresponding target IoC interface cannot be found, and an empty value can be returned to the first view object.

[0075] Step 406: Call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

[0076] The implementation method of this step can be referred to step 303, and will not be repeated here in this embodiment.

[0077] In this embodiment, after the second view object is created, candidate IoC interfaces and unique candidate key values ​​are generated for the second view object, and the candidate IoC interfaces and candidate key values ​​are registered to the global interface registration center. This allows the lower-level sub-view objects of the second view object to search for the required target IoC interface from the global interface center during the creation and display process, ensuring the normal invocation of the target IoC interface. In addition, different IoC interfaces of different interface types can be set for different types of business data, reducing the coupling of different types of business data and improving the invocation efficiency of business data.

[0078] As can be seen from the above embodiments, accurately and promptly finding the key-value pair corresponding to the IoC interface when a view object calls the IoC interface is a key issue that needs to be considered in the process of using the IoC interface. In this embodiment, considering the efficiency of key-value retrieval, a series of key-value retrieval strategies are provided, such as retrieving it from the cached data of the first view object; or retrieving it from the first label data of the first view object; or retrieving it from the label data of the parent view object of the first view object, etc.

[0079] Please refer to Figure 6 The diagram illustrates a flowchart of an interface invocation method provided in another exemplary embodiment of this application. Taking the application of this method to a terminal as an example, the method includes:

[0080] Step 601: If the first view object has a call requirement for the target business data corresponding to the second view object, obtain the target key value from the cached data corresponding to the first view object based on the target business data.

[0081] In this embodiment, the locations where the target key value may be stored include: the cache data corresponding to the first view object, the first tag data corresponding to the first view object, and the tag data of the parent view object corresponding to the first view object.

[0082] Considering the various storage locations where the target key value might be stored, and taking into account the efficiency of retrieving the target key value, the time required to retrieve the target key value from the cached data corresponding to the first view object is less than the time required to retrieve the target key value from the first tag data corresponding to the first view object, which in turn is less than the time required to retrieve the target key value from the tag data corresponding to the parent view object of the first view object. Therefore, in order to retrieve the target key value more promptly, in one possible implementation, when the first view object has a request to call the business data corresponding to the second view object, the first view object, based on the target business data, prioritizes retrieving the target key value from its own cached data.

[0083] The implementation method for obtaining the target key value based on the target business data can be referred to the above embodiment, and will not be repeated here.

[0084] Regarding the scenario where the cached data corresponding to the first view object may store the target key value: When the first view object calls the target IoC interface for the first time, the cached data of the first view object does not store the key value of the target IoC interface; after the first view object has called the target IoC interface, that is, the first view object has obtained the target key value corresponding to the target IoC interface, in order to facilitate the first view object to still need to use the target key value to call the target IoC interface in the future, the target key value can be stored in the cached data corresponding to the first view object, so that the cached data of the first view object may store the target key value; that is, the cached data can cache the key values ​​of the historical IoC interface calls corresponding to the first view object.

[0085] Among them, the historical IoC interfaces of the first view object are the IoC interfaces that the first view object has called in the past, that is, the IoC interfaces that have been called before the first view object has a call requirement for the target business data corresponding to the second view object. The key values ​​of these historically called IoC interfaces will be stored in the cache data corresponding to the first view object, so that the first view object can use them in subsequent calls to business data.

[0086] For illustration, if the historical IoC interfaces called by the first view object include IoC interface 1, IoC interface 2, and IoC interface 3, then the cached data of the first view object will cache the key-value pairs corresponding to the historical IoC interfaces called, namely: key-value pair 1 for IoC interface 1, key-value pair 2 for IoC interface 2, and key-value pair 3 for IoC interface 3. If the first view object needs to call IoC interface 4, and IoC interface 4 is not a historical IoC interface called, then the cached data of the first view object will not cache the key-value pair 4 corresponding to IoC interface 4.

[0087] Step 602: If the target key value is not obtained from the cached data corresponding to the first view object, the target key value is obtained from the first tag data corresponding to the first view object.

[0088] Optionally, when the first view object calls the target IoC interface for the first time, or when the first view object does not call the target IoC interface for the first time but the target IoC interface is not cached in the cache data of the first view object, there may be a situation where the target key value cannot be obtained from the cache data corresponding to the first view object. In order to continue to obtain the target key value for subsequent calls to the target IoC interface, in one possible implementation, when the target key value is not obtained from the cache data corresponding to the first view object, the target key value can be obtained first from the first tag data corresponding to the first view object.

[0089] It should be noted that if the target key value can be obtained from the cached data corresponding to the first view object, step 604 can be executed; if the target key value cannot be obtained from the cached data corresponding to the first view object, step 602 needs to be executed to obtain the target key value from the first label data of the first view object.

[0090] When the first label data of the first view object stores a target key value, it can be roughly divided into two types:

[0091] (1) When registering the candidate IoC interface and candidate key value corresponding to the second view object in the global registry center, or when generating the candidate key value corresponding to the second view object, the candidate key value can be directly stored in the label data of each view object contained in the view object tree. If the view object tree contains the first view object and the second view object, the first label data corresponding to the first view object will also store multiple candidate key values ​​corresponding to the second view object (the target key value is one of the candidate key values).

[0092] (2) When generating the candidate key value corresponding to the second view object, the candidate key value is only stored in the second label data corresponding to the second view object. When the subsequent lower-level sub-view object needs to obtain the candidate key value, it can obtain the candidate key value from the second label data of the second view object and pass the candidate key value from the second view object to the lower-level sub-view object based on the transmission link shown by the view object tree. If the transmission link includes the first view object, the first view object can also obtain the candidate key value corresponding to the candidate IoC interface and store it in the first label data corresponding to the first view object, even though the first view object has not called the candidate IoC interface.

[0093] Regarding the two scenarios described above for storing target key values ​​in the first tag data, it can be seen that the first tag data can store key values ​​that have been passed historically by the first view object, as well as key values ​​of the IoC interface corresponding to the first view object.

[0094] The key values ​​passed historically by the first view object refer to the key values ​​that the lower-level child view objects of the first view object needed to pass from the parent view object of the first view object to the lower-level child view object when calling the IoC interface. However, the first view object did not use this key value to call its corresponding IoC interface. Therefore, this key value will only be stored in the first label data of the first view object, and not in the cache data of the first view object. Furthermore, storing the key value in the first label data of the first view object when it is passed from the first view object to the lower-level child view object allows the first view object to directly look up the key value in its own first label data without having to obtain it from the parent view object, thus further improving the efficiency of subsequent key value retrieval.

[0095] As can be seen, the key values ​​of the historical IoC interface calls are the key values ​​of the IoC interfaces that the first view object has used in the past, while the key values ​​that have been passed in the past are the key values ​​of the IoC interfaces that the first view object has not used in the past. However, the key values ​​of the IoC interfaces that the child view objects of the first view object have used in the past need to be passed from the parent view object of the first view object to the child view object.

[0096] In an exemplary example, if the view object tree structure is: View1>View2>View3>View4>View5>View6>View7, and View7 has called the target IoC interface corresponding to View1 before View5 calls the target IoC interface corresponding to View1, then during the process of View7 calling the target IoC interface corresponding to View1, the target key value is passed to View7 via View1-View2-View3-View4-View5-View6. Since the target key value has passed through View5, it can be stored in the label data corresponding to View5, so that when View5 calls the target IoC interface, the target key value corresponding to the target IoC interface can be directly obtained from the label data corresponding to View5.

[0097] Optionally, after obtaining the target key value from the first tag data corresponding to the first view object, in order to improve the efficiency of subsequent repeated calls to the target IoC interface by the first view object, the target key value can be stored in the cache data corresponding to the first view object. This way, when the first view object calls the target IoC interface later, it can directly obtain the target key value from the cache data corresponding to the first view object, thereby improving the timeliness of target key value retrieval and further improving the call efficiency of the target IoC interface.

[0098] Step 603: If the target key value is not obtained from the first label data corresponding to the first view object, the target key value is obtained from the label data of the parent view object corresponding to the first view object.

[0099] Optionally, if the first view object can obtain the target key value from the first label data, then step 604 can be executed; if the first view object does not obtain the target key value from the first label data, then step 603 needs to be executed to further obtain the target key value from the label data of the parent view object corresponding to the first view object.

[0100] During the operation of the target application, the system maintains a view object tree corresponding to the target application. This view object tree can indicate the parent-child relationship between various view objects in the target application. Therefore, both the first view object and the second view object are located in the view object tree of the target application, and the second view object is the parent view object of the first view object.

[0101] Since the candidate key value corresponding to the second view object will be stored at least in the second label data corresponding to the second view object, and the second view object is the parent view object of the first view object, in one possible implementation, when the target key value (the target key value is one of the candidate key values) cannot be obtained from the first label data corresponding to the first view object, the target key value can be obtained from the label data of the parent view object corresponding to the first view object.

[0102] Optionally, after the first view object obtains the target key value from the label data of the parent view object, in order to avoid the first view object still needing to obtain the target key value from the label data of the parent view object when calling the target IoC interface later, in one possible implementation, when the target key value is obtained from the label data of the parent view object corresponding to the first view object, the target key value can be stored in the cache data corresponding to the first view object, so that when the first view object calls the target IoC interface later, it can directly obtain the target key value from the cache data corresponding to the first view object, thereby improving the timeliness of target key value acquisition and further improving the calling efficiency of the target IoC interface.

[0103] Because the view objects in the view object tree follow a certain parent-child relationship, and a child view object can only obtain relevant data from its corresponding unique parent view object, when retrieving the target key value, it is also necessary to search for the target key value layer by layer according to the hierarchical relationship indicated by the view object tree. For example, if the hierarchical relationship between the view objects in the view object tree is: View1>View2>View3>View4>View5>View6>View7, if View7 needs to find the target key value stored in View1, then View7 needs to search in View6 first. If it is not found, then View6 searches in View5, and if it is not found, then View5 searches in View4, and so on, until View2 finds the target key value in View1, and then returns the found target key value to View7. In an exemplary example, the process of retrieving the target key value from the label data of the parent view object corresponding to the first view object may include steps 603A to 603C.

[0104] Step 603A: Search for the target key value in the label data of the i-th level parent view object corresponding to the first view object, where i is a positive integer.

[0105] In one possible implementation, when searching for a target key value in the label data of the parent view object corresponding to the first view object, the search is first performed in the label data of the first-level parent view object corresponding to the first view object, according to the hierarchical relationship indicated by the view object tree. The first-level parent view object is the parent view object directly connected to the first view object. If the target key value is found in the first-level parent view object, it is returned to the first view object. If the target key value is not found in the first-level parent view object, the first-level parent view object continues to search for the target key value in the label data of the second-level parent view object, which is the parent view object of the first-level parent view object. This process continues until the target key value is found. In other words, when searching for a target key value in the label data of a parent view object, the target key value is searched in the label data of the i-th level parent view object corresponding to the first view object, where i is a positive integer.

[0106] Step 603B: If the target key value is found in the label data of the i-th level parent view object, return the target key value to the first view object.

[0107] Optionally, if the target key value is found in the label data of the i-th level parent view object, the target key value can be returned to the first view object; otherwise, if the target key value is not found in the label data of the i-th level parent view object, the search for the target key value continues in the label data of the parent view object of the i-th level parent view object.

[0108] Similar to the need to search through layers when looking up a target key value, when the target key value is found from the i-th parent view object and then returned to the first view object by the i-th parent view object, it also needs to be passed to the first view object layer by layer according to the hierarchical relationship indicated by the view object tree; in an exemplary example, step 603B may include step one and step two.

[0109] Step 1: If the target key value is found in the label data of the i-th level parent view object, determine the transmission link in the view object tree from the i-th level parent view object to the first view object.

[0110] In one possible implementation, when the target key value is found in the label data of the i-th level parent view object, the target key value needs to be passed from the i-th level parent view object to the first view object according to the transmission link indicated by the view object tree. Therefore, it is first necessary to determine the transmission link between the i-th level parent view object and the first view object in the view object tree.

[0111] Step 2: Based on the transmission link, pass the target key value from the i-th level parent view object to the first view object.

[0112] Once the transmission chain is determined, the target key value can be passed from the i-th level parent view object to the first view object according to the transmission relationship indicated by the transmission chain. For example, if the view hierarchy indicated by the view object tree is: View1>View2>View3>View4>View5>View6>View7, and View7 needs to find the target key value stored in View1, after View2 finds the target key value from View1, it needs to pass the target key value from View1 to View7. Therefore, the target key value needs to be passed from View1 to View2, from View2 to View3, from View3 to View4, from View4 to View5, and from View6 to View7, so that View7 can obtain the target key value.

[0113] Optionally, taking the above view hierarchy as an example, after View7 receives the target key value passed by View1, to avoid View5 needing to go through a process of searching and returning layer by layer when retrieving the target key value from View1, in one possible implementation, the target key value can be directly stored in the label data of each view object included in the transmission chain during the transmission of the target key value. This allows other lower-level sub-view controls to obtain the target key value without going through the repeated search and return process, improving the efficiency of obtaining the target key value. For example, during the process of View7 receiving the target key value returned by View1, the target key value can be directly stored in the label data of each view object included in the transmission chain from View1 to View7. That is, during the transmission of the target key value, the label data of View2, View3, View4, View5, and View6 will also store the target key value. Then, when View5 needs to obtain the target key value corresponding to View1, since the target key value is already stored in the label data corresponding to View5, it can directly obtain the target key value from the label data corresponding to View5.

[0114] Step 603C: If the target key value is not found in the label data of the i-th level parent view object, the target key value is obtained from the label data of the (i+1)-th level parent view object, where the (i+1)-th level parent view object is the parent view object of the i-th level parent view object.

[0115] Optionally, if the target key value is not found in the label data of the i-th level parent view object, then the target key value is retrieved from the label data of the parent view object (the (i+1)-th level parent view object) of the i-th level parent view object; if the target key value is not found in the label data of the (i+1)-th level parent view object, then the target key value is retrieved from the label data of the parent view object of the (i+1)-th level parent view object, and so on, until the target key value is retrieved.

[0116] Optionally, the target application's view object tree has a root node. To avoid entering an infinite loop state when the target key value is not found at the root node, in one possible implementation, if the i-th level parent view object is the root node of the view object tree and the target key value is not found in the label data of the i-th level parent view object, a null value can be returned to the first view object, indicating that the target key value cannot be found and the search for the target key value needs to be stopped.

[0117] like Figure 7The diagram illustrates a process for obtaining a target key value according to an exemplary embodiment of this application. The lower-level sub-View 701 first matches a key value from its cached data based on the interface type. If the target key value can be obtained from the cached data of the lower-level sub-View 701, the target IoC interface is retrieved from the global interface registry center using the target key value. If the target key value is not obtained from the cached data of the lower-level sub-View 701, the target key value is obtained from the tag data of the lower-level sub-View 701. If the target key value is obtained from the tag data of the lower-level sub-View 701, the target key value can be stored in the cached data of the lower-level sub-View 701 for later retrieval and retrieval of the target IoC interface from the global interface registry center using the target key value. If the target key value is not found in the tag data of the lower-level child View701, the parent View of the lower-level child View701 is retrieved, and it is determined whether the parent View is the page's initial container View (the page's initial container View can be called DecorView: DecorView is the root node view object of the view tree in the Android system, and is the page's native top-level view object. To avoid entering an infinite loop, if the parent view object is DecorView, a null value is returned, and the key value retrieval stops). If the parent View is the page's initial container View, the process ends because the target IoC interface could not be retrieved. If the parent View is not the page's initial container View, the parent View is assigned to the lower-level child View701, thus recursively looping through the view's tag data to retrieve the target key value. When the target IoC interface is retrieved from the global interface registry based on the target key value, the target IoC interface is returned to the lower-level child View701; if the target IoC interface is not retrieved from the global interface registry based on the target key value, the process ends because the target IoC interface could not be retrieved, and a null value is returned to the lower-level child View701.

[0118] Step 604: Based on the target key value, search for the target Inversion of Control (IoC) interface from the global interface registry center. The global interface registry center stores the correspondence between at least one candidate IoC interface and candidate key value.

[0119] Step 605: Call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

[0120] The implementation methods for steps 604 and 605 can be referred to the above embodiments, and will not be repeated here.

[0121] In this embodiment, by setting a certain target key value acquisition strategy: cached data of the first view object - first label data of the first view object - label data of the parent view object corresponding to the first view object, the acquisition efficiency of the target key value can be improved. In addition, after obtaining the target key value from the first label data or the label data of the parent view object, storing the target key value in the cached data of the first view object can improve the acquisition efficiency of the subsequent target key value, thereby improving the efficiency of subsequent calls of the first view object to the target IoC interface.

[0122] like Figure 8 The diagram illustrates a complete process of interface invocation according to an exemplary embodiment of this application. The upper-layer View 801 registers the IoC interface and its unique key value with the global interface registry center 803, and simultaneously stores the unique key value in the second tag data 802 corresponding to the upper-layer View 801. When the lower-layer View 804 needs to invoke the IoC interface, it can retrieve the unique key value by searching upwards through the View tree. After retrieving the unique key value, it returns the found unique key value to the lower-layer View 804. Once the lower-layer View 804 obtains the unique key value, it can use the unique key value to search for the IoC interface from the global interface registry center 803; the global interface registry center 803 can then return the found IoC interface to the lower-layer View 804. Optionally, when searching for a unique key value in the underlying View 804, the search can be performed first from the cached data of the underlying View 804 (not shown in the figure); if no unique key value is found in the cached data, the unique key value can be searched from the first label data 805 of the underlying View 804; if no unique key value is found from the first label data 805, the unique key value is retrieved by searching upwards based on the View tree.

[0123] Figure 9 This is a structural block diagram of an interface calling apparatus provided in an exemplary embodiment of this application. The apparatus includes:

[0124] The acquisition module 901 is used to acquire a target key value based on the target business data when the first view object has a call requirement for the target business data corresponding to the second view object. The first view object is a sub-view object in the second view object, and the target key value is unique.

[0125] The lookup module 902 is used to look up the target Inversion of Control (IoC) interface from the global interface registry center based on the target key value. The global interface registry center stores the correspondence between at least one candidate IoC interface and candidate key value.

[0126] The calling module 903 is used to call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

[0127] Optionally, the device further includes:

[0128] The generation module is used to generate at least one candidate IoC interface corresponding to the second view object and the candidate key value corresponding to each candidate IoC interface after the second view object is created.

[0129] The registration module is used to associate and register the candidate IoC interface and the candidate key value with the global interface registration center;

[0130] The search module 902 is also used for:

[0131] If a candidate key value matching the target key value exists at the global interface registry, the candidate IoC interface corresponding to the candidate key value is determined as the target IoC interface.

[0132] Optionally, the generation module is further configured to:

[0133] Based on at least one type of candidate business data corresponding to the second view object, at least one candidate interface type is determined, and different candidate interface types correspond to different types of candidate business data.

[0134] Create the candidate IoC interface corresponding to each of the candidate interface types. Different candidate IoC interfaces are used to call different types of candidate business data.

[0135] Based on the candidate interface type corresponding to the candidate IoC interface and the context information of the second view object, the candidate key value corresponding to the candidate IoC interface is generated;

[0136] The acquisition module 901 is further configured to:

[0137] If the first view object has a call requirement for the target business data corresponding to the second view object, determine the target interface type corresponding to the type to which the target business data belongs;

[0138] Based on the target interface type, obtain the target key value.

[0139] Optionally, the acquisition module 901 is further configured to:

[0140] The candidate key values ​​whose key value prefixes match the target interface type are determined as the target key values.

[0141] Optionally, the device further includes:

[0142] The storage module is used to store the candidate key value in the second tag data corresponding to the second view object when the candidate key value corresponding to the second view object is generated.

[0143] Optionally, the acquisition module 901 is further configured to:

[0144] If the first view object has a call requirement for the target business data corresponding to the second view object, the target key value is obtained from the cached data corresponding to the first view object based on the target business data. The cached data caches the key values ​​of the historical IoC interface calls corresponding to the first view object.

[0145] Optionally, the device further includes:

[0146] The acquisition module 901 is further configured to acquire the target key value from the first tag data corresponding to the first view object when the target key value is not acquired from the cached data corresponding to the first view object. The first tag data stores the key values ​​that the first view object has historically passed and the key values ​​of the IoC interface corresponding to the first view object.

[0147] Optionally, the device further includes:

[0148] The storage module is configured to store the target key value in the cache data corresponding to the first view object when the target key value is obtained from the first tag data corresponding to the first view object.

[0149] Optionally, the first view object and the second view object are located in the view object tree of the target application, and the second view object is the parent view object of the first view object;

[0150] The acquisition module 901 is further configured to acquire the target key value from the label data of the parent view object corresponding to the first view object when the target key value is not acquired from the first label data corresponding to the first view object.

[0151] Optionally, the device further includes:

[0152] The storage module is used to store the candidate key value into the label data of each view object contained in the view object tree when the candidate key value corresponding to the second view object is generated.

[0153] Optionally, the storage module is further configured to store the target key value in the cache data corresponding to the first view object when the target key value is obtained from the label data of the parent view object corresponding to the first view object.

[0154] Optionally, the acquisition module 901 is further configured to:

[0155] The target key value is retrieved from the label data of the i-th level parent view object corresponding to the first view object, where i is a positive integer;

[0156] If the target key value is found in the label data of the i-th level parent view object, the target key value is returned to the first view object.

[0157] If the target key value is not found in the label data of the i-th level parent view object, the target key value is obtained from the label data of the (i+1)-th level parent view object, where the (i+1)-th level parent view object is the parent view object of the i-th level parent view object.

[0158] Optionally, the device further includes:

[0159] The return module is configured to return a null value to the first view object when the i-th level parent view object is the root node of the view object tree and the target key value is not found in the label data of the i-th level parent view object.

[0160] Optionally, the acquisition module 901 is further configured to:

[0161] If the target key value is found in the label data of the i-th level parent view object, the transmission link between the i-th level parent view object and the first view object in the view object tree is determined.

[0162] Based on the transmission link, the target key value is passed from the i-th level parent view object to the first view object.

[0163] Optionally, the device further includes:

[0164] The storage module is also used to store the target key value in the label data of each view object included in the transmission link during the process of transmitting the target key value based on the transmission link.

[0165] In summary, this paper provides a method for invoking IoC interfaces. When a first view object (child view object) needs to call corresponding business data of a second view object (upper-level view object), the first view object can directly find and call the target IoC interface for calling the target business data from the global interface registry based on the target key value. The entire interface call process does not require the second view object to pass the IoC interface to the first view object. This eliminates the need to pay attention to the complex page structure between the second and first view objects during the use of the IoC interface, and omits the transmission link between the upper-level view object and the lower-level view object during the use of the IoC interface, thus improving the efficiency of IoC interface usage. At the same time, it also eliminates the need to develop complex interface transmission functions between pages during development, simplifying development operations and improving development efficiency.

[0166] Please refer to Figure 10 This diagram illustrates a structural block diagram of a terminal 1000 provided in an exemplary embodiment of this application. The terminal 1000 may be a portable mobile terminal, such as a smartphone, tablet computer, Moving Picture Experts Group Audio Layer III (MP3) player, or Moving Picture Experts Group Audio Layer IV (MP4) player. The terminal 1000 may also be referred to as a user device, portable terminal, or other names.

[0167] Typically, terminal 1000 includes a processor 1001 and a memory 1002.

[0168] Processor 1001 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1001 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). Processor 1001 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1001 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1001 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0169] The memory 1002 may include one or more computer-readable storage media, which may be tangible and non-transitory. The memory 1002 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 are used to store at least one instruction, which is executed by the processor 1001 to implement the interface calling method provided in the embodiments of this application.

[0170] In some embodiments, the terminal 1000 may also optionally include a peripheral device interface 1003.

[0171] Peripheral interface 1003 can be used to connect at least one input / output (I / O) related peripheral device to processor 1001 and memory 1002. In some embodiments, processor 1001, memory 1002 and peripheral interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1001, memory 1002 and peripheral interface 1003 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0172] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the interface calling method provided in the above method embodiments.

[0173] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A terminal's processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the interface invocation method provided in the above-described method embodiments.

[0174] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0175] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0176] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An interface invocation method, characterized in that, The method includes: When the first view object has a call requirement for the target business data corresponding to the second view object, the target key value is obtained based on the target business data. The first view object is a sub-view object in the second view object, and the target key value is unique. Based on the target key value, the target IoC interface is searched from the global interface registry center, which stores the correspondence between at least one candidate IoC interface and candidate key value; The target IoC interface is invoked through the first view object to obtain the target business data corresponding to the second view object.

2. The method according to claim 1, characterized in that, The method further includes: Once the second view object is created, at least one candidate IoC interface corresponding to the second view object and candidate key values ​​corresponding to each candidate IoC interface are generated. The candidate IoC interface and the candidate key value are associated and registered with the global interface registration center; The step of searching for the target IoC interface from the global interface registry center based on the target key value includes: If a candidate key value matching the target key value exists at the global interface registry, the candidate IoC interface corresponding to the candidate key value is determined as the target IoC interface.

3. The method according to claim 2, characterized in that, The generation of at least one candidate IoC interface corresponding to the second view object, and the candidate key value corresponding to each candidate IoC interface, includes: Based on at least one type of candidate business data corresponding to the second view object, at least one candidate interface type is determined, and different candidate interface types correspond to different types of candidate business data. Create the candidate IoC interface corresponding to each of the candidate interface types. Different candidate IoC interfaces are used to call different types of candidate business data. Based on the candidate interface type corresponding to the candidate IoC interface and the context information of the second view object, the candidate key value corresponding to the candidate IoC interface is generated; When the first view object has a request to call the target business data corresponding to the second view object, obtaining the target key value based on the target business data includes: If the first view object has a call requirement for the target business data corresponding to the second view object, determine the target interface type corresponding to the type to which the target business data belongs; Based on the target interface type, obtain the target key value.

4. The method according to claim 3, characterized in that, The step of obtaining the target key value based on the target interface type includes: The candidate key value whose key value prefix matches the target interface type is determined as the target key value.

5. The method according to claim 2, characterized in that, The method further includes: When generating the candidate key value corresponding to the second view object, the candidate key value is stored in the second label data corresponding to the second view object.

6. The method according to any one of claims 1 to 5, characterized in that, When the first view object has a request to call the target business data corresponding to the second view object, obtaining the target key value based on the target business data includes: If the first view object has a call requirement for the target business data corresponding to the second view object, the target key value is obtained from the cached data corresponding to the first view object based on the target business data. The cached data caches the key values ​​of the historical IoC interface calls corresponding to the first view object.

7. The method according to claim 6, characterized in that, The method further includes: If the target key value is not obtained from the cached data corresponding to the first view object, the target key value is obtained from the first tag data corresponding to the first view object. The first tag data stores the key values ​​that the first view object has historically passed, as well as the key values ​​of the IoC interface corresponding to the first view object.

8. The method according to claim 7, characterized in that, The method further includes: If the target key value is obtained from the first tag data corresponding to the first view object, the target key value is stored in the cache data corresponding to the first view object.

9. The method according to claim 7, characterized in that, The first view object and the second view object are located in the view object tree of the target application, and the second view object is the parent view object of the first view object; The method further includes: If the target key value is not obtained from the first label data corresponding to the first view object, the target key value is obtained from the label data of the parent view object corresponding to the first view object.

10. The method according to claim 9, characterized in that, The method further includes: When generating the candidate key value corresponding to the second view object, the candidate key value is stored in the label data of each view object contained in the view object tree.

11. The method according to claim 9, characterized in that, The method further includes: If the target key value is obtained from the label data of the parent view object corresponding to the first view object, the target key value is stored in the cache data corresponding to the first view object.

12. The method according to claim 9, characterized in that, The step of obtaining the target key value from the label data of the parent view object corresponding to the first view object includes: The target key value is retrieved from the label data of the i-th level parent view object corresponding to the first view object, where i is a positive integer; If the target key value is found in the label data of the i-th level parent view object, the target key value is returned to the first view object. If the target key value is not found in the label data of the i-th level parent view object, the target key value is obtained from the label data of the (i+1)-th level parent view object, where the (i+1)-th level parent view object is the parent view object of the i-th level parent view object.

13. The method according to claim 12, characterized in that, The method further includes: If the i-th level parent view object is the root node of the view object tree, and the target key value is not found in the label data of the i-th level parent view object, return a null value to the first view object.

14. The method according to claim 12, characterized in that, When the target key value is found in the label data of the i-th level parent view object, returning the target key value to the first view object includes: If the target key value is found in the label data of the i-th level parent view object, the transmission link between the i-th level parent view object and the first view object in the view object tree is determined. Based on the transmission link, the target key value is passed from the i-th level parent view object to the first view object.

15. The method according to claim 14, characterized in that, The method further includes: During the transmission of the target key value based on the transmission link, the target key value is stored in the label data of each view object contained in the transmission link.

16. An interface calling device, characterized in that, The device includes: The acquisition module is used to acquire a target key value based on the target business data when the first view object has a call requirement for the target business data corresponding to the second view object. The first view object is a sub-view object in the second view object, and the target key value is unique. The lookup module is used to look up the target IoC interface from the global interface registry center based on the target key value. The global interface registry center stores the correspondence between at least one candidate IoC interface and candidate key value. The calling module is used to call the target IoC interface through the first view object to obtain the target business data corresponding to the second view object.

17. A terminal, characterized in that, The terminal includes a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the interface invocation method as described in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is loaded and executed by a processor to implement the interface invocation method as described in any one of claims 1 to 15.

19. A computer program product, characterized in that, The computer program product stores a computer program that is loaded and executed by a processor to implement the interface invocation method as described in any one of claims 1 to 15.

Images