WO2020135485A1

WO2020135485A1 - Result acquisition method, apparatus and device

Info

Publication number: WO2020135485A1
Application number: PCT/CN2019/128240
Authority: WO
Inventors: 冯绍波; 王根良; 邵哲平
Original assignee: 华为技术有限公司
Priority date: 2018-12-25
Filing date: 2019-12-25
Publication date: 2020-07-02
Also published as: CN111367683A

Abstract

Disclosed are a result acquisition method, apparatus and device for reducing the number of times a target API in a terminal device is invoked, reducing a system load, and improving the system performance. The method in the embodiments of the present application comprises: in response to a first request instruction for a target API, invoking the target API, so as to acquire a return result of the target API; and correspondingly storing the target API and the return result in a cache. Therefore, in response to a second request instruction for the target API, the return result corresponding to the target API can be searched for in the cache, without the need to invoke the target API again, in order to obtain the return result of the target API, so that the number of times the target API is invoked is reduced, thereby reducing the system load and improving the performance of the system.

Description

Method, device and equipment for obtaining results

This application requires the priority of the Chinese patent application filed on December 25, 2018 in the Chinese Patent Office with the application number 201811592873.0 and the invention titled "A method, device and equipment for obtaining results", the entire contents of which are incorporated herein by reference Applying.

Technical field

This application relates to the field of mobile terminals, and in particular, to a method, device, and device for obtaining results.

Background technique

Generally speaking, in the terminal system, in order to ensure the security of the data, each process runs independently and cannot directly use the resources of other processes. However, in some application scenarios, a process may need to use the resources of other processes, for example, a service process can provide services for the process where the application is located, so that the application can use the resources of the service process to achieve the desired function, such as service The process can provide terminal memory information, hard disk information, etc. for the application.

The service process provides services for the process where the application is located, and can be implemented through inter-process communication (IPC). Specifically, corresponding application programming interfaces (APIs) can be set for these services in advance. The application can use the resources in the service process by calling the APIs corresponding to the services to achieve the desired functions.

The interaction between the terminal system and the user is usually more, so the system API is called more times to obtain service information. However, frequent calls to system APIs will increase the load on the entire system, thereby reducing system performance.

Summary of the invention

Embodiments of the present application provide a method, device, and device for obtaining a result. By storing a return result corresponding to a target API in a cache, the number of calls to the target API is reduced, system load is reduced, and system performance is improved.

The first aspect of the present application provides a method for obtaining results. The method includes:

In response to the first request instruction to the target API, call the target API to obtain a return result of the target API;

Correspondingly storing the target API and the returned result in the cache;

In response to the second request instruction to the target API, look up the returned result corresponding to the target API in the cache.

In the above method, in response to the first request instruction to the target API, the target API is called to obtain the return result of the target API, and the target API and the return result are stored in the cache correspondingly, therefore, in response to the second request to the target API Instruction, you can find the return result corresponding to the target API in the cache, without having to call the target API again to get the return result of the target API, reducing the number of calls to the target API, thereby reducing system load and improving system performance.

In some possible implementation manners, the searching the cache for the returned result corresponding to the target API includes:

Searching in the cache for the returned result corresponding to the target API and satisfying the valid time condition.

The returned result corresponding to the target API found in the cache satisfies the valid time condition. Therefore, the returned result is a valid result, thereby improving the accuracy of the returned result.

In some possible implementations, the method further includes:

If there is no return result corresponding to the target API satisfying the valid time condition in the cache, the target API is called to obtain the return result corresponding to the target API.

If there is no return result corresponding to the target API in the cache, or the return result corresponding to the target API in the cache does not meet the time condition, it is considered that there is no return result corresponding to the target API that meets the valid time condition in the cache. The results are returned for reacquisition, so the target API can be called again to meet user needs.

In some possible implementations, the method further includes:

Deleting the returned result corresponding to the target API in the cache that does not meet the valid time condition.

After finding the return result corresponding to the target API, you can delete the return result that does not meet the valid time condition to save storage space.

In some possible implementations, the type of the target API is the first preset type.

The first preset type indicates that the return result of the target API is related to time, but the difference between multiple return results is not large. Therefore, it can be determined whether the return result corresponding to the target API meets the valid time condition. If it is, it means that the return result is valid. If not, the returned result is considered invalid.

In some possible implementations, the method further includes:

Deleting the returned result in the cache that does not meet the valid time condition.

In order to effectively manage the cache, you can delete the returned results that do not meet the valid time condition, so as to save storage space and the efficiency of the search for returned results.

In some possible implementations, the method further includes:

According to the type of the to-be-processed API, determine whether the to-be-processed API is a target API, and the target API is a first preset type or a second preset type; the first preset type represents multiple times of the target API The return results are different, and the difference between the multiple return results is less than or equal to a preset difference, and the second preset type indicates that the multiple return results of the target API are the same.

The target API is of a specific type in the to-be-processed API, such as the first preset type or the second preset type, and the returned result corresponding to the target API can be stored to reduce the number of times the target API is called.

In some possible implementations, the method further includes:

When the service information of the target service corresponding to the target API changes, delete the return result corresponding to the target API in the cache, or update the return result corresponding to the target API in the cache.

The return result corresponding to the target API can also be deleted or updated according to the service information, so that the return result corresponding to the target API is more accurate.

In some possible implementation manners, the responding to the first request instruction to the target API, invoking the target API, and obtaining a return result of the target API includes:

In response to the first request instruction to the target API, if the return result corresponding to the target API does not exist in the cache, the target API is called to obtain the return result corresponding to the target API.

In response to the first request instruction to the target API, the return result corresponding to the target API may be searched first, and if the cache does not exist, then the target API is called to reduce the number of times the target API is called.

A second aspect of an embodiment of the present application provides an apparatus for obtaining results. The apparatus includes:

A first calling unit, configured to call the target API in response to a first request instruction to the target API, and obtain a return result of the target API;

A storage unit, configured to store the target API and the returned result correspondingly in the cache;

The searching unit is configured to search for the returned result corresponding to the target API in the cache in response to the second request instruction to the target API.

In some possible implementations, the search unit is specifically used to:

In response to the second request instruction to the target API, search the cache for the return result corresponding to the target API that satisfies the valid time condition.

In some possible implementations, the device further includes:

The second calling unit is configured to call the target API to obtain the return result corresponding to the target API if the return result corresponding to the target API that meets the valid time condition does not exist in the cache.

In some possible implementations, the device further includes:

The first deleting unit is configured to delete the returned result corresponding to the target API in the cache that does not satisfy the valid time condition.

In some possible implementations, the device further includes:

The second deleting unit is configured to delete the returned result in the cache that does not meet the valid time condition.

In some possible implementations, the device further includes:

A target API determining unit, configured to determine whether the API to be processed is a target API according to the type of the API to be processed, and the target API is a first preset type or a second preset type; the first preset type is characterized The multiple return results of the target API are different, and the difference between the multiple return results is less than or equal to a preset difference. The second preset type indicates that the multiple return results of the target API are the same.

In some possible implementations, the device further includes:

The updating unit is configured to delete the return result corresponding to the target API in the cache when the service information of the target service corresponding to the target API changes, or, to the target API corresponding to the cache Return the result to update.

In some possible implementation manners, the first calling unit is specifically configured to:

A third aspect of the embodiments of the present application provides a result acquisition device, where the device includes a processor and a memory;

The memory is used to store instructions;

The processor is configured to execute the instructions in the memory and execute a method for obtaining results provided in the first aspect of the embodiments of the present application.

A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, including instructions, which when executed on a computer, causes the computer to obtain a result acquisition method provided by the first aspect of the embodiment of the present application.

A fifth aspect of an embodiment of the present application provides a computer program product containing instructions, which, when run on a computer, causes the computer to obtain a result acquisition method provided by the first aspect of the embodiment of the present application.

It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

In a method, device and device for obtaining a result provided by an embodiment of the present application, in response to the first request instruction to the target API, the target API is called to obtain the return result of the target API, and the target API and the return are correspondingly stored in the cache As a result, therefore, in response to the second request instruction to the target API, the return result corresponding to the target API can be found in the cache without calling the target API again to get the return result of the target API, reducing the number of calls to the target API, Thereby reducing system load and improving system performance.

BRIEF DESCRIPTION

In order to more clearly explain the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required in the description of the embodiments. Obviously, the drawings in the following description are only some of the implementations described in the present application For example, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings.

FIG. 1 is a schematic diagram of information interaction for obtaining results in the prior art;

2 is a flowchart of a method for obtaining results in an embodiment of the present application;

FIG. 3 is a schematic diagram of a scenario embodiment in an embodiment of the present application;

4 is a structural block diagram of an apparatus for obtaining results in an embodiment of the present application;

FIG. 5 is a structural block diagram of a result acquisition device in an embodiment of this application.

detailed description

Embodiments of the present application provide a method, device, and device for obtaining results, which are used to reduce the number of target API calls in a terminal device, reduce system load, and improve system performance.

The terms "first", "second", "third", "fourth", etc. (if any) in the description and claims of this application and the above drawings are used to distinguish similar objects without using To describe a specific order or sequence. It should be understood that the data so used can be interchanged under appropriate circumstances so that the embodiments described herein can be implemented in an order other than what is illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, processes, methods, systems, products or devices that contain a series of steps or units are not necessarily limited to those clearly listed Those steps or units, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or equipment.

In the terminal system, in order to ensure the security of the data, each process runs independently and cannot directly use the resources of other processes. Therefore, the service process provides services for the process where the application is located, and can be realized through inter-process communication. Specifically, the corresponding API can be set for the service in advance, and the application program can call the API to use the corresponding resource in the service process to achieve the desired function. For example, an application can call the system API to obtain information such as the terminal's memory, hard disk, whether it supports Bluetooth, and whether it supports flash. However, with the continuous enrichment of mobile smart terminal functions, the interaction between terminal systems and users is increasing, and the number of times applications call system APIs to obtain service information, and frequent calls to system APIs will cause the entire system The load of the system increases, which degrades the performance of the system, which in turn leads to serious power consumption of the terminal equipment and stuck, which affects the user's use.

In the existing terminal system, in the process of using the application program, the application program may repeatedly call the API. Referring to FIG. 1, which is a schematic diagram of information interaction for obtaining results in the prior art, an application can make three API calls and send three information query requests to a system service. Corresponding to each information query request, the system service obtains a query The result is returned to the application. The information query request here may be to query whether the terminal device supports a certain function, such as the Bluetooth function and the flash function. However, some of the returned results may not be related to time, that is to say, the process of calling the API three times is the same, and the query results returned by the system service are also the same. Therefore, making three API calls is completely unnecessary, resulting in unnecessary Waste of resources.

Based on the above technical problems, the embodiments of the present application provide a method, device and device for obtaining a result. When responding to the first request instruction to the target API, the target API is called to obtain the return result of the target API and stored in the cache correspondingly The target API and the corresponding return result. Therefore, in response to the second request instruction to the target API, the return result corresponding to the target API can be found in the cache without having to call the target API again to obtain the return result of the target API. The number of target API calls to reduce system load and improve system performance. In other words, corresponding to the three information query requests shown in Figure 1, the optimal result is that as long as the first information query is required, the target API is called once and the returned result is obtained. During the query, the corresponding return result is obtained from the cache, which greatly reduces the number of calls to the target API.

Referring to FIG. 2, FIG. 2 is a flowchart of a method for obtaining results in an embodiment of the present application. The following specifically describes the method for obtaining results provided by the embodiments of the present application.

S101: In response to the first request instruction to the target API, call the target API to obtain a return result of the target API.

The target API corresponds to the target service. It can be a predefined function provided by the operating system or service provider. The application can call the API to obtain the target service without the source code of the target service or without understanding the internal principles. Resources in the process.

For example, in the Android system, inter-process communication can be achieved through Binder. The Android framework itself can provide a series of system services and provide Java/C++ APIs to call these services. Therefore, you can transfer the query request from the process where the application is located to the service process based on the Binder mechanism by calling the API. After the service process obtains the corresponding query result, the query result is returned to the process where the application is located through the Binder mechanism.

In the embodiment of the present application, the target API may be the first preset type. The first preset type indicates that the return result of the target API is related to time, but the difference between multiple return results is not large, that is, the time to call the target API is different, and the difference between the return results is less than or equal to the preset difference, for example For the positioning function of the mobile terminal, when the time gap for calling the target API is not large, the location gap of the mobile terminal is also small.

Whether the target API is the first preset type may be preset by the provider of the target service corresponding to the target API, or may be preset by an operating system developer, or may be automatically determined by the terminal device. Among them, the terminal device can determine the type of the target API according to the historical record of the target API call and the historical return result. Specifically, it can compare the time of calling the target API multiple times, and compare the historical return results obtained after multiple calls to the target API. If the change rate of the historical return result is less than or equal to the preset rate, the target API has the first preset type.

It should be noted that the terminal device determines the type of the target API according to the historical records and historical return results of calling the target API, and can also refer to the current scene of the terminal device, for example, when the user is walking, the location of the terminal device is within a short time gap Small, at this time, it can be considered that the API corresponding to the positioning function can be the first preset type, but when the terminal device is on a vehicle with a fast moving speed, the gap in a short time is large, then the corresponding function of the positioning function cannot be considered API is the first preset type. The current scene of the terminal device can be obtained according to the information of the sensor of the terminal device.

In the embodiment of the present application, the target API may also be the second preset type. The second preset type indicates that the return result of the target API is independent of time, that is, the multiple return results of the target API are always the same.

Whether the target API is the second preset type may be preset by the provider of the target service corresponding to the target API, or may be preset by the operating system developer, or may be automatically determined by the terminal device. The terminal device can determine the type of the target API according to the history records of the call to the target API and the historical return results. Specifically, it can compare whether multiple historical return results are always the same.

That is to say, the target API is an API with a first preset type or a second preset type, and the return result of other APIs other than that has a greater correlation with the calling time, so it is not the target API and does not belong to the embodiment of this application Need to consider the scope. Which target APIs are included can be determined by the service thread in multiple pending APIs, and then the determination result is sent to the thread where the application is located. Of course, the service thread can also send the type of pending API to the thread where the application is located. The thread where the program resides determines whether the API is the target API according to the type of API.

In the embodiment of the present application, the service thread may be the thread where the system service is located. Of course, in order not to affect other modules, the service thread may run in a separate thread, which is not limited again.

The first request instruction to the target API may be generated according to the user's operation on the terminal device, for example, the user starts the application operation, or clicks on the corresponding control when there is a query or use demand for the target service; The first request instruction of the target API may also be automatically generated, for example, the information of the target service may be queried periodically, so the first request instruction is generated.

Call the target API to get the return result of the target API. Taking the Android system as an example, by calling the hasSystemFeature function, you can obtain whether the current terminal device supports a certain function or feature. As an example, the application can query whether the current terminal device supports the Bluetooth function by calling the pm.hasSystemFeature(PackageManager.FEATURE_BLUETOOTH) function, and the returned result can be "yes" or "no"; the application can also be called by pm.hasSystemFeature(PackageManager.FEATURE_CAMERA_FLASH) function, query whether the current device has a flash, the return result can be "yes" or "no".

The application can make further operations according to the return result of the target API, for example, when the current terminal device supports the Bluetooth function, the Bluetooth function can be used.

S102, correspondingly store the target API and the returned result in the cache.

After the return result of the target API is obtained, the target API and the return result can be stored in the cache correspondingly. The cache here is the cache in the process where the application is located, so that the application can read the cache to obtain the return result of the target API without having to obtain it through inter-process communication; the cache here can also be the cache in the service process In this way, the process where the application is located can obtain the return result in the cache through inter-process communication with the service process, and the service process does not need to perform the action of obtaining the return result again.

When correspondingly storing the target API and the returned result, if the type of the target API is the second preset type, the storage time of the returned result may also be recorded, for example, adding a timestamp to the returned result. This is because when the type of the target API is the second preset type, the return result is related to the time when the target API is called, that is, the longer the time from the call to the target API, the greater the possibility that the returned result will be invalid. Therefore, it can be The target API sets valid time conditions. If the storage time of the returned result meets the valid time condition, the returned result is regarded as valid data; if the stored time of the returned result does not satisfy the valid time condition, the returned result is regarded as invalid data.

The storage time can be the time when the returned result is stored. The storage time of the returned result that meets the valid time condition can be specifically that the storage time is later than the preset time; the storage time can also be the length of time the returned result is stored in the cache. The length of time can be determined according to the current time information and the time information when the returned result is stored. The storage time of the returned result meeting the valid time condition may be specifically that the storage time is shorter than the preset time.

For example, an application can call the getProcessMemoryInfo interface to obtain the memory of the process where the application is located to detect whether the process has a memory leak. Therefore, the returned result does not change too much over time, and the time stamp can be added to the returned result. , In order to determine whether the data is within the validity period in use, so as to increase the validity of the data.

In the embodiment of the present application, in order to improve the utilization rate of the cache, the invalid data in the cache can also be deleted, that is, when the type of the target API is the second preset type, it is determined whether the storage time of the return result of the target API meets the effective time If the condition is not met, the returned result is deleted.

It can be understood that if the type of the target API is the first preset type, the returned result is always valid, and the effective time condition can be any time. Of course, the storage time of the returned result may not be recorded, and the target is the default The return result of the API is valid data.

In addition, in order to improve the accuracy of the return result of the target API, when the service process detects that the service information of the target service corresponding to the target API changes, it sends an update reminder to the process where the application is located, such as wireless network changes, turning off the screen, etc. When the information changes, you can send an update reminder to the process where the application is located, and the update reminder can be sent by broadcast. The update reminder includes the identification of the target API, and the update reminder may also include service information of the target service corresponding to the target API. In the embodiment of the present application, in response to the update reminder, the thread where the application resides may delete the return result of the target API in the cache, or, based on the service information of the target service in the update reminder, update the return result of the target API in the cache to Ensure that the returned result in the cache is valid data.

For example, Android needs to repeatedly obtain storage information during the application startup process to determine whether the application data can be stored in a secure digital card (SD card) or internal storage device In, when the user inserts or removes the SD card, the storage information will change. Therefore, the service process can collect the storage information in real time, and send an update reminder to the process corresponding to the application when the storage information changes, so that the process where the application is located can delete or update the storage information in the cache.

In order to realize the service to update the process of the application, when the application is started, you can register with the service process, so that the service process can collect service information corresponding to the API related to the application. Specifically, the application can start a new thread when it is started, and send registration information to the service thread. The registration information can include the application identification and callback function. The service thread can determine which service information needs to be collected according to the application identifier. After detecting that the target service information corresponding to the target API related to the application has changed, it can send an update reminder to the thread where the application is located through a callback function.

Of course, in order to provide users with personalized services, the registration information may also include a user ID, and the service thread determines which service information needs to be collected based on the application ID and the user ID.

S103: In response to the second request instruction to the target API, search for a return result corresponding to the target API in the cache.

Similar to the first request instruction, the second request instruction may be generated according to the user's operation on the terminal device or may be automatically generated. In the prior art, in response to the second request instruction to the target API, the target API is called again to obtain The corresponding return result of the target API, so that multiple calls to the same target API increase the load on the system.

In the embodiment of the present application, in response to the second request instruction, the return result corresponding to the target API may be searched in the cache, thereby reducing the number of times the target API is called. If there is no return result corresponding to the target API in the cache, the target API can be called to obtain the return result corresponding to the target API.

If there is a storage time corresponding to the return result corresponding to the target API, you can find the return result corresponding to the target API and the storage time meeting the valid time condition in the cache. Specifically, you can directly search for the return result corresponding to the target API and the storage time meets the valid time condition; you can also first obtain the return result corresponding to the target API in the cache, and then determine whether the storage time of the obtained return result is satisfactory The valid time condition, if it is, the corresponding return result is found, if not, the return result can be deleted to improve the effective utilization of the cache.

If there is no return result corresponding to the target API in the cache and the storage time meets the valid time condition, it is considered that no valid return result is found, and the target API can be called to obtain the return result corresponding to the target API.

Based on the above technical solution, S101 may also be specifically: in response to the first request instruction to the target API, if there is no return result corresponding to the target API in the cache, the target API is called to obtain the return result corresponding to the target API.

After the application is closed, the cache and the return result in the cache can be deleted. At the same time, a BinderDied call can be generated, and the service thread deletes the data related to the application, such as application callback information.

Based on the above technical solutions, the application has been tested in practice, and Tmall, Douyin, WeChat, CNTV v6.5.2 are pre-installed and installed on the mobile phone, stimulating the battlefield, Vipshop, Chedi, Tuniu Travel, Tencent Video, NetEase News 10 applications, and start 5 applications: Tmall, Douyin, WeChat, CNTV v6.5.2, stimulate the battlefield, will getPackageInfoAsUser (used to obtain the application package information), getPackageUidAsUser (used to obtain the application package Name), getApplicationInfoAsUser (for obtaining application information of the application), getVolumeList (for obtaining storage information of the current terminal device), getProcessMemoryInfo (for obtaining the memory of the process where the application is located), getDisplayInfo (for obtaining the terminal device's memory) Screen display information) As five target APIs, these five target API interfaces can be added to the following interface classes: ApplicationPackageManager, ApplicationPackageManager, ApplicationPackageManager, StorageManager, ActivityManager, DisplayManagerGlobal. As shown in Table 1, for the start of five applications, the average call time and call of each target API are not used (method 1) and after using the result acquisition method (method 2) of this application frequency.

Table 1 Actual test results

The embodiment of the present application provides a method for obtaining a result. In response to the first request instruction to the target API, the target API is called to obtain the return result of the target API, and the target API and the corresponding return result are stored in the cache correspondingly. In response to the second request instruction to the target API, the returned result corresponding to the target API can be searched in the cache. Because the application cache is in the thread where the application is located, the application can obtain the return result within the thread without calling the target API again to get the return result of the target API, which reduces the number of calls to the target API, thereby reducing System load, improve system performance.

The above method for obtaining the results is exemplarily described in conjunction with specific scenarios. Please refer to FIG. 3, which is a schematic diagram of a scenario embodiment in an embodiment of the present application.

1) The application starts. In the binding process phase (BindApplication), a new thread is started, the application program runs in the thread, and registration information is sent to the service process, and the registration information may include an application identification, a user identification, and a callback function.

2) The service thread determines the target API according to the thread ID and the user ID, notifies the application of the determination result according to the callback function, and starts to collect the service information of the target service corresponding to the target API.

3) In response to the first service request to the target API, the application program calls the target API to obtain the return result of the target API. For example, the application program can call the getVolumeList interface to obtain the storage information of the current terminal device.

4) The application program correspondingly stores the target API and the returned result in the cache. Specifically, you can first enable the caching mechanism of the getVolumeList interface in StorageManager.java, and then store the return result of the getVolumeList interface.

5) In response to the second service request to the target API, the application program looks up the return result corresponding to the target API from the cache.

6) The service thread collects that the service information of the target service corresponding to the target API changes, and sends an update notification to the application. For example, after the user removes the SD card and the service thread collects that the storage information has changed, it can send an update notification to the thread where the application is located through the callback information of the application.

7) The application deletes the return result corresponding to the target API according to the update notification.

8) In response to the third service request, the application program calls the target API, obtains the return result of the target API, and stores the target API and the return result in the cache correspondingly.

9) Exit the application, clear the cache, and clear the thread. At the same time, a BinderDied call is generated, and the service thread deletes application-related data, such as callback information.

In order to facilitate better implementation of the above solutions of the embodiments of the present application, related devices for implementing the above solutions are also provided below.

Please refer to FIG. 4, the result obtaining apparatus 400 provided by the embodiment of the present application specifically corresponds to the function of the result obtaining method provided above. The function can be realized by hardware, and can also be realized by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above functions, and the unit may be software and/or hardware. The device 400 may include:

The first calling unit 110 is configured to call the target API and obtain a return result of the target API in response to the first request instruction to the target API;

The storage unit 120 is configured to store the target API and the returned result correspondingly in the cache;

The searching unit 130 is configured to search for the returned result corresponding to the target API in the cache in response to the second request instruction to the target API.

In some possible implementations, the search unit is specifically used to:

In some possible implementations, the device further includes:

In a result obtaining apparatus provided in an embodiment of the present application, in response to a first request instruction to a target API, the target API is called to obtain the return result of the target API, and the target API and the return result are stored in the cache correspondingly. Therefore, In response to the second request instruction to the target API, the return result corresponding to the target API can be found in the cache without having to call the target API again to obtain the return result of the target API, which reduces the number of calls to the target API, thereby reducing the system load To improve system performance.

Next, the result acquisition device in the embodiment of the present application will be described. Please refer to FIG. 5, the result acquisition device 500 includes:

The receiver 501, the transmitter 502, the processor 503, and the memory 504 (wherein the number of the processor 503 in the device 500 for generating a message may be one or more, and one processor is taken as an example in FIG. 5). In some embodiments of the present application, the receiver 501, the transmitter 502, the processor 503, and the memory 504 may be connected through a bus or in other ways. In FIG. 5, connection through a bus is used as an example.

The memory 504 may include a read-only memory and a random access memory, and provide instructions and data to the processor 503. A portion of the memory 504 may also include NVRAM. The memory 504 stores an operating system and operation instructions, executable modules or data structures, or a subset thereof, or an extended set thereof, where the operation instructions may include various operation instructions for implementing various operations. The operating system may include various system programs for implementing various basic services and processing hardware-based tasks.

The processor 503 controls the operation of the terminal device, and the processor 503 may also be referred to as a CPU. In a specific application, each component of the device for generating a message is coupled together through a bus system. In addition to the data bus, the bus system may also include a power bus, a control bus, and a status signal bus. However, for the sake of clarity, various buses are called bus systems in the figure.

The method disclosed in the above embodiments of the present application may be applied to the processor 503 or implemented by the processor 503. The processor 503 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method may be completed by an integrated logic circuit of hardware in the processor 503 or instructions in the form of software. The foregoing processor 503 may be a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. The methods, steps, and logical block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in conjunction with the embodiments of the present application may be directly embodied and executed by a hardware decoding processor, or may be executed and completed by a combination of hardware and software modules in the decoding processor. The software module may be located in a random storage memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, and other mature storage media in the art. The storage medium is located in the memory 504, and the processor 503 reads the information in the memory 504, and completes the steps of the above method in combination with its hardware.

The receiver 501 can be used to receive input digital or character information, and generate signal input related to user plane device related settings and function control. The transmitter 502 can include a display device such as a display screen, and the transmitter 502 can be used to output through an external interface Number or character information.

In the embodiment of the present application, the receiver 501 and the transmitter 502 are used to implement data transmission and reception. The processor 503 is configured to transmit and receive data through the receiver 501 and the transmitter 502, and complete the result acquisition process performed by the foregoing result acquisition device.

Embodiments of the present application also provide a computer-readable storage medium for storing program code, and the program code is used to perform any one of the implementation methods in a result acquisition method of the foregoing embodiments.

Embodiments of the present application also provide a computer program product including instructions that, when run on a computer, cause the computer to execute any one of the method for obtaining a result of the foregoing embodiments.

Those skilled in the art can clearly understand that for the convenience and conciseness of the description, the specific working processes of the system, device and unit described above can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical, or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or software function unit.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application essentially or part of the contribution to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to enable a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program code .

As mentioned above, the above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, persons of ordinary skill in the art should understand that they can still The technical solutions described in the embodiments are modified, or some of the technical features are equivalently replaced; and these modifications or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

A method for obtaining results, characterized in that the method includes:

In response to the first request instruction to the target API, call the target API to obtain a return result of the target API;

Correspondingly storing the target API and the returned result in the cache;

In response to the second request instruction to the target API, look up the returned result corresponding to the target API in the cache.
The method according to claim 1, wherein the searching for the returned result corresponding to the target API in the cache includes:

Searching in the cache for the returned result corresponding to the target API and satisfying the valid time condition.
The method according to claim 2, wherein the method further comprises:

If there is no return result corresponding to the target API satisfying the valid time condition in the cache, the target API is called to obtain the return result corresponding to the target API.
The method of claim 3, further comprising:

Deleting the returned result corresponding to the target API in the cache that does not meet the valid time condition.
The method according to any one of claims 2-4, wherein the type of the target API is a first preset type, and the first preset type indicates that the target API returns different results multiple times, And the difference between the results returned multiple times is less than or equal to the preset difference.
The method according to claim 1, wherein the method further comprises:

Deleting the returned result in the cache that does not meet the valid time condition.
The method according to claim 1, wherein the method further comprises:

According to the type of the to-be-processed API, determine whether the to-be-processed API is a target API, and the target API is a first preset type or a second preset type; the first preset type represents multiple times of the target API The return results are different, and the difference between the multiple return results is less than or equal to a preset difference, and the second preset type indicates that the multiple return results of the target API are the same.
The method according to any one of claims 1-7, wherein the method further comprises:

When the service information of the target service corresponding to the target API changes, delete the return result corresponding to the target API in the cache, or update the return result corresponding to the target API in the cache.
The method according to any one of claims 1-8, wherein, in response to the first request instruction to the target API, calling the target API to obtain a return result of the target API includes:

In response to the first request instruction to the target API, if the return result corresponding to the target API does not exist in the cache, the target API is called to obtain the return result corresponding to the target API.
An apparatus for obtaining results, characterized in that the apparatus includes:

A first calling unit, configured to call the target API in response to a first request instruction to the target API, and obtain a return result of the target API;

A storage unit, configured to store the target API and the returned result correspondingly in the cache;

The searching unit is configured to search for the returned result corresponding to the target API in the cache in response to the second request instruction to the target API.
The device according to claim 10, wherein the search unit is specifically configured to:

In response to the second request instruction to the target API, search the cache for the return result corresponding to the target API that satisfies the valid time condition.
The device according to claim 11, wherein the device further comprises:

The second calling unit is configured to call the target API to obtain the return result corresponding to the target API if the return result corresponding to the target API that meets the valid time condition does not exist in the cache.
The device of claim 12, wherein the device further comprises:

The first deleting unit is configured to delete the returned result corresponding to the target API in the cache that does not satisfy the valid time condition.
The device according to any one of claims 11 to 13, wherein the type of the target API is a first preset type, and the first preset type indicates that the target API returns different results multiple times, And the difference between the results returned multiple times is less than or equal to the preset difference.
The device of claim 10, wherein the device further comprises:

The second deleting unit is configured to delete the returned result in the cache that does not meet the valid time condition.
The device of claim 10, wherein the device further comprises:

A target API determining unit, configured to determine whether the API to be processed is a target API according to the type of the API to be processed, and the target API is a first preset type or a second preset type; the first preset type is characterized The multiple return results of the target API are different, and the difference between the multiple return results is less than or equal to a preset difference. The second preset type indicates that the multiple return results of the target API are the same.
The device according to any one of claims 10-16, wherein the device further comprises:

The updating unit is configured to delete the return result corresponding to the target API in the cache when the service information of the target service corresponding to the target API changes, or, to the target API corresponding to the cache Return the result to update.
The device according to any one of claims 10-17, wherein the first calling unit is specifically configured to:

In response to the first request instruction to the target API, if the return result corresponding to the target API does not exist in the cache, the target API is called to obtain the return result corresponding to the target API.
A result acquisition device, characterized in that the device includes: a processor and a memory;

The memory is used to store instructions;

The processor is configured to execute the instructions in the memory and execute the method according to any one of claims 1-9.
A computer-readable storage medium including instructions which, when run on a computer, cause the computer to perform the method of any one of claims 1-9 above.
A computer program product containing instructions that, when run on a computer, causes the computer to perform the method of any one of claims 1-9 above.