Method, device and electronic equipment for processing application requests

Abstract

The present disclosure provides a method, device and electronic equipment for processing application program request, which can be applied to the technical field of computer. The method comprises the following steps: in response to receiving a target request of an application program for calling a target hardware, determining a current state of the application program, the target request being used for obtaining configuration information of the target hardware; in the case that the current state is a starting state, sending the pre-stored configuration information of the target hardware to the application program, the configuration information being obtained from the target hardware by a specified service when a preset condition is met.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, and electronic device for processing application requests. Background Technology

[0002] When an application is launched for the first time or after a long period of inactivity, it needs to access relevant hardware to initialize and configure hardware resources. This process may slow down the application's startup speed. Summary of the Invention

[0003] According to a first aspect of this disclosure, a method for processing an application request is provided, comprising: in response to receiving a target request from an application for invoking target hardware, determining the current state of the application, wherein the target request is for obtaining configuration information of the target hardware; and, if the current state is a startup state, sending pre-stored configuration information of the target hardware to the application, wherein the configuration information is obtained from the target hardware by a designated service when preset conditions are met.

[0004] According to embodiments of this disclosure, in response to receiving a target request from an application to invoke target hardware, the current state of the application is determined, including: obtaining the process identifier of the application and the amount of content rendered; if the process identifier is newly created and the amount of content rendered is greater than a preset threshold, the current state of the application is determined to be the startup state.

[0005] According to embodiments of this disclosure, when the current state is the startup state, sending pre-stored configuration information of the target hardware to the application includes: intercepting a target request from a target process; indicating an association between the target process and the application; reading the configuration information of the target hardware from a preset storage space based on the target request; generating response information based on the configuration information to reply to the target request based on the response information.

[0006] According to embodiments of this disclosure, a mapping relationship exists between a target process and an application process. Intercepting a target request from a target process includes: determining, based on the mapping relationship, whether the process initiating the target request is a target process associated with an application currently in a running state; if the process initiating the target request is a target process, intercepting the target request; wherein the target process is responsible for handling the underlying operations of the target hardware, the target process is created or activated when the application first requests data from the target hardware, and the application process initiates the target request through the target process.

[0007] According to embodiments of this disclosure, the preset storage space is the storage space corresponding to the operating system kernel mode. When the current state is the startup state, the pre-stored configuration information of the target hardware is sent to the application, including: reading the configuration information of the target hardware from the storage space corresponding to the kernel mode; constructing response information of the target request based on the configuration information; and returning the response information to the application.

[0008] According to embodiments of this disclosure, the preset conditions include system startup, and the method further includes: sending an acquisition request initiated by a specified service to the target hardware; the acquisition request is initiated by the specified service when the system starts, and is used to acquire configuration information of the target hardware, wherein the application is deployed on the system; in response to receiving the configuration information of the target hardware, storing the configuration information in a preset storage space.

[0009] According to embodiments of this disclosure, the preset conditions further include a change in the target hardware state, and the method further includes: in response to a change in the target hardware state from a disabled state to an enabled state, sending target information to a designated service, the target information being used to instruct the designated service to obtain configuration information of the target hardware; and in response to receiving newly obtained configuration information, updating the original configuration information in the preset storage space based on the newly obtained configuration information.

[0010] According to embodiments of this disclosure, the method further includes: when the current state is running, not intercepting the target request, but sending the target request to the target hardware.

[0011] According to a second aspect of this disclosure, an apparatus for processing application requests is provided, comprising: a determining module, configured to determine the current state of the application in response to receiving a target request from an application for invoking target hardware, wherein the target request is for obtaining configuration information of the target hardware; and a sending module, configured to send pre-stored configuration information of the target hardware to the application when the current state is a startup state, wherein the configuration information is obtained from the target hardware by a designated service when preset conditions are met.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; a memory storing computer program instructions; and hardware for performing a specific function; wherein the processor is configured to execute the computer program instructions to perform the following steps: in response to receiving a target request from an application for invoking target hardware, determining the current state of the application, the target request being for obtaining configuration information of the target hardware; and, if the current state is a startup state, sending pre-stored configuration information of the target hardware to the application, the configuration information being obtained from the target hardware by a designated service when preset conditions are met.

[0013] According to a fourth aspect of this disclosure, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0014] According to a fifth aspect of this disclosure, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0015] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 This illustration schematically depicts an application scenario of a method for processing application requests according to an embodiment of the present disclosure.

[0017] Figure 2 A flowchart illustrating a method for processing application requests according to an embodiment of the present disclosure is shown schematically.

[0018] Figure 3 The schematic diagram illustrates one of the principles of a method for processing application requests according to an embodiment of the present disclosure;

[0019] Figure 4 A schematic diagram of a method for processing application requests according to an embodiment of the present disclosure is shown for the second time.

[0020] Figure 5 The schematic diagram illustrates a principle of determining the current state of an application in response to receiving a target request from an application for invoking target hardware, according to an embodiment of the present disclosure.

[0021] Figure 6 This schematically illustrates a structural block diagram of an apparatus for processing application requests according to an embodiment of the present disclosure;

[0022] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a method for processing application requests according to an embodiment of the present disclosure. Detailed Implementation

[0023] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0024] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0025] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0026] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0027] In the technical solution disclosed herein, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0028] Before introducing the technical solutions provided in the embodiments of this disclosure, the relevant technologies involved in this disclosure will be explained first.

[0029] When an application performs a cold start (i.e., its first launch or restart after a long period of inactivity), it needs to interact with the hardware to initialize hardware resources and determine hardware configuration information. Due to the inherent responsiveness of the hardware and the complexity of the interaction process, the interaction time between the application and the hardware may be lengthy, slowing down the application's startup. Firstly, accessing the hardware requires waking it up and waiting for it to become ready, which can consume considerable time. Secondly, the interaction between the application and the hardware involves multiple layers, such as the application layer, system driver layer, and hardware interface layer. During this interaction, communication delays and data transmission errors may occur, leading to longer hardware access times.

[0030] Since the application startup process is usually synchronous, meaning that the application's requests must wait for the hardware to respond before execution can continue, a slow hardware response will result in a slow application startup.

[0031] Based on the above, this disclosure provides a method for processing application requests. During a cold start of an application, the method intercepts the target request issued by the application and directly sends pre-stored configuration information to the application without accessing hardware, thus completing the target request. This effectively avoids the time consumption caused by hardware access and improves the application startup speed.

[0032] Figure 1 The illustration schematically depicts an application scenario of a method for processing application requests according to embodiments of the present disclosure. For example... Figure 1 As shown, application scenario 100 according to an embodiment of this disclosure may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0033] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal device. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal device, or even web pages.

[0034] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0035] It should be noted that the method for processing application requests provided in this disclosure embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the apparatus for processing application requests provided in this disclosure embodiment can generally be disposed in server 105 and / or terminal devices 101-103.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0037] Figure 2 A flowchart illustrating a method for processing application requests according to an embodiment of this disclosure is shown schematically. Figure 3 One of the schematic diagrams of a method for processing application requests according to an embodiment of the present disclosure is illustrated.

[0038] like Figure 2 , Figure 3 As shown, the method for processing application requests according to embodiments of this disclosure may include operations S210 to S220.

[0039] In operation S210, in response to receiving a target request from an application to invoke target hardware, the current state of the application is determined, and the target request is used to obtain configuration information of the target hardware.

[0040] In operation S220, when the current state is the startup state, the pre-stored configuration information of the target hardware is sent to the application. The configuration information is obtained from the target hardware by the specified service when preset conditions are met.

[0041] In some embodiments, when an application needs to invoke target hardware, it sends a target request to invoke the target hardware. Upon receiving the target request, the access control module in the operating system determines the current state of the application that initiated the request and, based on the current state, decides whether to intercept the target request.

[0042] If the application's current state is determined to be startup, the target request is intercepted (i.e., the target request is not sent to the target hardware), and the target hardware's configuration information is retrieved from pre-stored data. This configuration information is then sent to the requesting application. The pre-stored configuration information can be retrieved from the hardware and stored by a designated service when preset conditions are met. For example, the designated service can read the configuration information from the target hardware at system startup, when the target hardware state changes, or at fixed time intervals, and store it in the system's database or cache. When the application initiates a request while in a startup state, the system directly reads the configuration information from these pre-stored locations and sends it to the application, without needing to retrieve it from the target hardware again in real time.

[0043] Sending pre-stored target hardware configuration information directly to the application during application startup can effectively avoid real-time interaction with the target hardware every time the application requests to start, thus shortening access time, improving system response speed, and reducing hardware load.

[0044] According to one embodiment of this disclosure, the method further includes: when the current state is running, not intercepting the target request, and sending the target request to the target hardware.

[0045] In some embodiments, if the application is running, it forwards the target request to the target hardware, which processes the target request and returns the result to the application.

[0046] During the runtime phase, the application needs to obtain the latest configuration information of the target hardware in real time in order to perform corresponding operations and adjustments based on the actual state of the hardware. When the application is running, the target request is sent directly to the target hardware to meet the application's real-time requirements.

[0047] The startup state typically represents the beginning of a process, possibly before complete initialization or during the initial configuration loading phase. During this phase, the application needs configuration information from the target hardware to complete its own initialization setup, ensuring proper interaction and collaboration with the target hardware. For example, each graphics processing application needs to obtain configuration information such as the graphics card's memory size and core frequency upon startup to allocate memory resources and set rendering parameters accordingly.

[0048] During the startup phase, applications typically need to obtain basic configuration information from the target hardware to initialize their own parameters and settings. In this process, the real-time requirements for information retrieval are not high. Requests can be intercepted, and pre-stored configuration information can be used to respond to the target request, avoiding immediate access to the target hardware at startup. This reduces latency and overhead associated with hardware access, thereby speeding up application startup.

[0049] Figure 4 A schematic diagram of a method for processing application requests according to an embodiment of the present disclosure is shown for the second time.

[0050] To facilitate understanding of the technical solution disclosed herein, the following is combined with Figure 4 The method for processing application requests provided in this disclosure is further described.

[0051] like Figure 4 As shown, Dispatcher is a designated service that can be used to obtain configuration information from the target hardware when preset conditions are met. MF is the Media Foundation, which, in this embodiment, acts as an intermediate layer to receive target requests from applications and pass them to IRPs for processing. IRPs are data structures in the kernel used to represent I / O requests (I / O Request Packets), which can be used to transmit related requests and responses. Store represents a preset storage space that can be used to store pre-obtained hardware configuration information. Boost is the judgment logic in the operating system's access control module (not shown in the figure), which can be used to determine whether to intercept IRP requests. APPs represent applications that need to use the target hardware.

[0052] Taking the target hardware as a camera device as an example, Figure 4 In this context, "Camera Hardware" refers to the actual physical camera device (corresponding to...). Figure 3 The Camera module represents the logical device at the software level (such as the camera device's driver) of the camera device. It is used to represent the physical camera device in the system and handle various requests related to the camera device. For example, the "Camera" module is responsible for interacting with upper-layer applications (such as APPs), receiving requests from the applications, and translating these requests into calls to the underlying hardware or drivers.

[0053] It should be noted that, for ease of understanding, the embodiments of this disclosure use a camera device as the target hardware for detailed explanation and description. However, this does not mean that the target hardware involved in this disclosure is limited to camera devices. Other types of devices, as long as they meet the corresponding conditions and application scenario requirements, can also apply this solution, and these situations are also within the protection scope of this disclosure.

[0054] See Figure 4 The solid line portion illustrates how, when applications (APPs) need to access target hardware (Camera Hardware), they send a target request to the system. This request is first received by the target hardware driver (Camera) and sent to the intermediate layer MF, where it is then converted into IRPs for further processing. During the transmission of IRPs to the target hardware, the access control module in the system kernel determines whether the application is in a startup or running state. If the application is in a running state, the IRP continues to propagate down to the Camera Hardware. If the application is in a startup state, the IRP request is intercepted and not sent to the target hardware. The access control module reads the pre-stored configuration information of the target hardware from the preset storage space (Store) and sends the read configuration information to the application, completing the response to the target request.

[0055] See Figure 4 The dotted line section represents the process where, when preset conditions are met, a designated service (Dispatcher) sends an acquisition request to the target hardware driver (Camera). This request is used to obtain the target hardware's configuration information. After receiving the acquisition request from the Dispatcher, the Camera generates corresponding IRPs to process the request, sends the acquisition request to the target hardware, obtains the target hardware's configuration information, and stores the obtained configuration information in a preset storage space.

[0056] Figure 5 The schematic diagram illustrates a principle of determining the current state of an application in response to receiving a target request from an application for invoking target hardware, according to an embodiment of the present disclosure.

[0057] like Figure 5 As shown, in response to receiving a target request from an application to invoke the target hardware, the current state of the application is determined, including: obtaining the application's process identifier and the amount of content rendered; if the process identifier is newly created and the amount of content rendered is greater than a preset threshold, the current state of the application is determined to be the startup state.

[0058] In some embodiments, the current state of an application can be determined by the process identifier and the amount of content rendered.

[0059] A process identifier is a unique identifier assigned by the operating system to each running process to distinguish different processes.

[0060] The amount of content rendered refers to the multi-dimensional information involved in the process of rendering graphics, processing data, and presenting it to the user, including the scale of data, the complexity of graphic elements, and the amount of computation required.

[0061] When an application starts up, it typically needs to perform a significant amount of initial rendering work. Taking a game as an example, startup requires loading resources such as game scenes, character models, and texture maps, and performing an initial rendering to display the startup screen or initial scene. These initial rendering tasks load and process a large amount of graphics data at once, causing a sharp increase in the amount of content to be rendered.

[0062] Compared to the startup phase, although rendering also occurs during application runtime, it is usually for updating local scenes or dynamically changing elements. The amount of content rendered is relatively stable and is usually less than that during the startup phase.

[0063] The current state of the application can be determined by comparing the obtained process identifier and the amount of content rendered with preset conditions. If the process identifier indicates that the application is being created for the first time (i.e., the process is running for the first time) and the amount of content rendered is greater than a preset threshold, then the current state of the application is determined to be the startup state; otherwise, the application is considered to be in the running state.

[0064] For example, it can be determined whether a process identifier is being created for the first time by querying the system process history. Changes in the amount of rendered content can be indirectly determined through the Graphics Device Interface (GDI).

[0065] GDI (Graphics Interface) is an Application Programming Interface (API) for graphics and text output. When an application renders a large amount of content, it typically needs to create more GDI objects to complete the graphics rendering. For example, a GDI growth curve can be plotted based on collected data points, with time as the horizontal axis and GDI-related metrics (such as the number of GDI objects) as the vertical axis. At application startup, a large number of graphics resources need to be loaded and initialized, causing the amount of content to be rendered to increase rapidly. Simultaneously, to render the startup interface and initial scene, the application creates a large number of GDI objects, resulting in a rapid upward trend in the GDI growth curve. Once the application has completed loading initial resources and rendering the interface, and enters the runtime phase, the amount of content rendered gradually stabilizes, and the creation and management of GDI objects also enter a relatively stable state, causing the GDI growth curve to flatten. The growth rate of GDI objects can be determined by the slope of the GDI growth curve. When the number of GDI objects increases rapidly in a short period, the slope of the growth curve is large; when the creation of GDI objects enters a relatively stable state, the slope of the growth curve approaches 0.

[0066] The current state of an application can be determined by combining the process ID and the GDI growth curve. If the process ID is newly created and the GDI metric is growing rapidly, the application is considered to be in the startup state. If the process ID is not newly created or the GDI metric growth rate has slowed significantly, the application is considered to be in the running state.

[0067] The embodiments of this disclosure determine the current state of an application by combining process identifier and the amount of content rendered, which can effectively improve the accuracy and reliability of application state judgment, so as to process target requests accordingly based on the application state, and return pre-stored configuration information in a timely manner when the application starts, avoiding the delay caused by accessing the target hardware during the startup phase, and speeding up the application startup speed.

[0068] After determining the current state of the application, the access control module processes the target request accordingly based on the current state. For example, the access control module could be a filter driver deployed in the operating system kernel.

[0069] According to one embodiment of this disclosure, when the current state is the startup state, sending pre-stored configuration information of the target hardware to the application includes: intercepting a target request from the target process; reading the configuration information of the target hardware from a preset storage space based on the target request; generating response information based on the configuration information, and replying to the target request based on the response information.

[0070] In some embodiments, when the application is in the running state, requests sent by the target process are intercepted through a set interception point.

[0071] The target process can be a host service process associated with the application, responsible for managing hardware resources and handling hardware-related events and requests. For example, a process can be identified as a target process associated with an application by its process name or specific identification information.

[0072] In some embodiments, the application's target request is not handled by the application's own process, but rather by the host service process through the MF framework. For example, when an application requests access to target hardware, the system creates an svchost process to handle the application's request.

[0073] By analyzing the association between the application process and the svchost process, it's possible to identify whether the process initiating the request is the target process (i.e., whether the process is associated with an application that is currently running). If the svchost process is the target process (i.e., it is associated with an application that is currently running), the target request sent by that process is intercepted, and the response is based on the data already saved in the pre-stored space.

[0074] Configuration information can include basic hardware parameters (such as camera resolution, frame rate, focus mode, etc.), driver-related information, security settings, etc. Key information can be extracted from intercepted target requests to retrieve the corresponding target hardware configuration information from a preset storage space. Key information may include, for example, the type of target hardware requested, the specific operation, etc. For instance, if the target request is to obtain the camera's highest resolution setting, configuration information related to the camera resolution can be found in the preset storage space.

[0075] Based on the configuration information of the target hardware, the system generates response information according to the format and specifications required by the target request, and sends the generated response information back to the target process to respond to the target request sent by the application.

[0076] In this embodiment of the disclosure, when the application starts, the pre-stored configuration information of the target hardware is sent to the application, avoiding the process of the application and the target hardware obtaining cooperation and parameters through interaction. This effectively shortens the application startup time, reduces the occupation of system resources, and effectively improves resource utilization efficiency.

[0077] According to one embodiment of this disclosure, intercepting a target request from a target process includes: determining, based on a mapping relationship, whether the process initiating the target request is a target process associated with an application currently in a running state; and if the process initiating the target request is a target process, intercepting the target request.

[0078] In some embodiments, the target process and the application target process are responsible for handling the underlying operations of the target hardware. The target process is created or activated when the application first requests data from the target hardware, and the application process initiates the target request through the target process.

[0079] An application process is an instance of an application that uses services provided by the operating system to complete various tasks (such as interacting with hardware). Application processes interact with hardware by calling interfaces and services provided by the operating system. The target process can be a host service process, used to host and manage multiple system services; the application process can interact with the hardware by calling the target process.

[0080] The target process is preloaded and runs when the system starts. When an application first requests a service related to specific hardware, the corresponding target process can be activated to handle the target request. If the service is not yet hosted by the target process, the operating system will dynamically create a target process instance to host the service.

[0081] There is a mapping relationship between the target process and the application process. When a request arrives at the interception point, the interception module obtains the process identifier and request content of the request. It can determine the process that sent the request based on the obtained process identifier, determine which application process the request is associated with based on the mapping relationship between the process and the application process, and query the current state of the application. If the current state of the application is running, the process that initiated the target request is identified as the target process, and the target request is intercepted.

[0082] For example, when the interception module receives request 1, it determines that the request was sent by svchost X through the process identifier. Based on the mapping relationship between the application process and the svchost process, it determines that the process svchost X is associated with application A. It queries the current state of application A. If the current state of application A is running, it determines that the process svchost X is the target process, performs an interception operation on request 1, prevents request 1 from reaching the target hardware, and returns response information built based on the configuration information.

[0083] This embodiment of the disclosure distinguishes the process that initiates the request through a mapping relationship, thereby indirectly realizing the identification and interception of the target request. This enables the application to start quickly while avoiding affecting the normal hardware access of other applications.

[0084] According to one embodiment of this disclosure, the preset storage space is the storage space corresponding to the operating system kernel mode. When the current state is the startup state, the pre-stored configuration information of the target hardware is sent to the application, including: reading the configuration information of the target hardware from the storage space corresponding to the kernel mode; constructing response information of the target request based on the configuration information; and returning the response information to the application.

[0085] In some embodiments, hardware accessory information pre-acquired based on a specified service can be stored in the storage space corresponding to the operating system kernel mode, so that the filter driver can directly access and read the configuration information, thereby improving the access speed.

[0086] For example, the pre-acquired configuration information can be stored in the corresponding kernel memory space, which can be allocated according to the hardware type, so that the corresponding storage space can be quickly located when reading the configuration information of the target hardware later, thereby improving the configuration information reading speed.

[0087] The system can read the target hardware's configuration information from the kernel-mode storage space based on the content of the target request. This configuration information may include, for example, the hardware model, parameter settings, and driver-related information. The read configuration information can then be packaged into a response message according to the format and structure required by the application and returned to the application.

[0088] Configuration information in kernel-mode storage space can be obtained and stored by a specified service when the system starts.

[0089] According to one embodiment of this disclosure, the preset conditions include system startup, and the method further includes: sending a second acquisition request initiated by a specified service to the target hardware; the second acquisition request is initiated by a specified application when the system starts, and is used to acquire configuration information of the target hardware, wherein an application is deployed on the system; in response to receiving the configuration information of the target hardware, the configuration information is stored in a preset storage space.

[0090] In some embodiments, the system starts up after the computer system is powered on or restarted. A designated service may be designed to run automatically during system startup. After the system completes basic initialization, the designated service starts and generates a second retrieval request for the target hardware based on its internal logic and preset tasks. This second retrieval request contains specific information about the target hardware configuration that needs to be obtained, such as the hardware model and parameter settings.

[0091] The designated service sends the generated second retrieval request to the operating system, which then forwards it to the target hardware to obtain its configuration information in advance. For example, the operating system can convert the second retrieval request into a signal that the hardware can understand and send it to the device driver corresponding to the target hardware. Upon receiving the second retrieval request, the device driver further converts it into a communication protocol format suitable for the target hardware and sends it to the target hardware.

[0092] Upon receiving a request, the target hardware reads its own configuration information based on the request content. This configuration information is written during the manufacturing process or set during use, and describes the hardware's characteristics and current state. The target hardware then organizes and encapsulates the read configuration information to generate response data.

[0093] The response data is transmitted to the operating system kernel. After receiving the configuration information returned by the target hardware, the operating system kernel stores the configuration information in a preset storage space.

[0094] Configuration information in kernel-mode storage can also be obtained and stored by a specific service when the target hardware changes.

[0095] According to one embodiment of this disclosure, the preset conditions further include a change in the state of the target hardware, and the method for processing application requests further includes: in response to a change in the state of the target hardware from a disabled state to an enabled state, sending target information to a specified application, the target information being used to instruct a specified service to obtain configuration information of the target hardware; and in response to receiving newly obtained configuration information, updating the original configuration information in the preset storage space based on the newly obtained configuration information.

[0096] In some embodiments, the status of the target hardware can be monitored in real time. When the status of the target hardware changes from disabled to enabled, target information is sent to a designated service. The target information may be, for example, a simple flag or a specific message code. Upon receiving the information, the designated service can identify it and trigger the corresponding operation to obtain configuration information.

[0097] Upon receiving the target information, the designated service generates a request for the target hardware to obtain its configuration information. The designated service can send the request to the target hardware through an interface provided by the operating system (such as a device driver interface). Upon receiving the request, the target hardware reads the corresponding configuration information from its own storage (such as EEPROM, registers, etc.), encapsulates it into a response data packet, and sends it back to the designated service. After receiving the response data packet, the designated service parses and processes it to extract the required configuration information.

[0098] After receiving newly acquired configuration information from a designated service, the operating system compares and verifies this information with the original configuration information in the pre-stored space to determine if the new information is valid and correct. Once the new configuration information passes verification, the operating system updates the original configuration information in the pre-stored space based on this new information. The update operation can involve modifying specific fields or replacing the entire configuration information structure.

[0099] The hardware configuration may be dynamically adjusted according to user needs or system operation. In this embodiment of the disclosure, the configuration information is updated in a timely manner when the target hardware status changes, which can effectively improve the real-time performance and accuracy of the configuration information, so that the application can perform corresponding operations based on the latest configuration information.

[0100] Based on the above-described method for processing application requests, embodiments of this disclosure also provide an apparatus for processing application requests. The following will be combined with... Figure 6 The device is described in detail.

[0101] Figure 6 A schematic block diagram of an apparatus for processing application requests according to an embodiment of the present disclosure is shown.

[0102] like Figure 6 As shown, the apparatus 600 for processing application requests in this embodiment includes a determining module 610 and a sending module 620.

[0103] The determining module 610 is used to determine the current state of the application in response to receiving a target request from the application to invoke the target hardware. The target request is used to obtain configuration information of the target hardware. In one embodiment, the determining module 610 can be used to perform the operation S210 described above, which will not be repeated here.

[0104] The sending module 620 is used to send pre-stored target hardware configuration information to the application when the current state is the startup state. The configuration information is obtained from the target hardware by a designated service when preset conditions are met. In one embodiment, the sending module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0105] According to embodiments of this disclosure, any plurality of modules in determining module 610 and transmitting module 620 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of determining module 610 and transmitting module 620 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or any other reasonable means of integrating or packaging circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these. Alternatively, at least one of determining module 610 and transmitting module 620 can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0106] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a method for processing application requests according to an embodiment of the present disclosure.

[0107] like Figure 7 As shown, an electronic device 700 according to an embodiment of the present disclosure includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory 702 or a program loaded from a storage portion 708 into a random access memory 703. The processor 701 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different steps of the method flow according to an embodiment of the present disclosure.

[0108] Random access memory 703 stores various programs and data required for the operation of electronic device 700. Processor 701, read-only memory 702, and random access memory 703 are interconnected via bus 704. Processor 701 executes various steps of the method flow according to embodiments of the present disclosure by executing programs in read-only memory 702 and / or random access memory 703. It should be noted that the programs may also be stored in one or more memories other than read-only memory 702 and random access memory 703. Processor 701 may also execute various steps of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0109] According to embodiments of this disclosure, the electronic device 700 may further include an input / output interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the input / output interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card, such as a local area network card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0110] Embodiments of this disclosure also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0111] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include the read-only memory 702 described above, and / or random access memory 703, and / or one or more memories other than read-only memory 702 and random access memory 703.

[0112] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this disclosure.

[0113] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0114] In embodiments of this disclosure, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by processor 701, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0115] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can execute entirely on a user computing device, partially on a user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

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

[0117] Those skilled in the art will understand that the features described in the various embodiments of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

Claims

1. A method for processing application requests, comprising: In response to receiving a target request from an application to invoke target hardware, the current state of the application is determined, wherein the target request is used to obtain configuration information of the target hardware; When the current state is the startup state, the pre-stored configuration information of the target hardware is sent to the application. The configuration information is obtained from the target hardware by a designated service when preset conditions are met.

2. The method according to claim 1, wherein determining the current state of the application in response to receiving a target request from the application to invoke the target hardware includes: Obtain the process identifier and the amount of content rendered by the application; If the process is identified as being created for the first time and the amount of content being rendered is greater than a preset threshold, the current state of the application is determined to be the startup state.

3. The method according to claim 1, wherein, when the current state is a startup state, sending pre-stored configuration information of the target hardware to the application includes: Intercept target requests from the target process; There is a relationship between the target process and the application; Based on the target request, read the configuration information of the target hardware from the preset storage space; Response information is generated based on the configuration information to reply to the target request.

4. The method according to claim 3, wherein there is a mapping relationship between the target process and the application process, and the interception of the target request from the target process includes: Based on the mapping relationship, determine whether the process that initiated the target request is a target process associated with an application that is currently in the running state; If the process initiating the target request is the target process, intercept the target request; The target process is responsible for handling the low-level operations of the target hardware. The target process is created or activated when the application first requests data from the target hardware, and the application process initiates the target request through the target process.

5. The method according to claim 3, wherein the preset storage space is the storage space corresponding to the operating system kernel mode, and the step of sending the pre-stored configuration information of the target hardware to the application when the current state is the startup state includes: Read the configuration information of the target hardware from the storage space corresponding to the kernel mode; The response information for the target request is constructed based on the configuration information; The response information is returned to the application.

6. The method according to claim 1, wherein the preset condition includes system startup, and the method further includes: Send an acquisition request initiated by a specified service to the target hardware; The acquisition request is initiated by the specified service when the system starts, and is used to obtain the configuration information of the target hardware. The application is deployed on the system. In response to receiving the configuration information of the target hardware, the configuration information is stored in a preset storage space.

7. The method according to claim 6, wherein the preset condition further includes a change in the target hardware state, and the method further includes: In response to the target hardware changing from a disabled state to an enabled state, target information is sent to the designated service, the target information being used to instruct the designated service to obtain the configuration information of the target hardware; In response to receiving newly acquired configuration information, the original configuration information in the preset storage space is updated based on the newly acquired configuration information.

8. The method according to claim 1, further comprising: When the current state is running, the target request is not intercepted, and the target request is sent to the target hardware.

9. An apparatus for processing application requests, comprising: A determination module is used to determine the current state of the application in response to receiving a target request from an application for invoking target hardware, wherein the target request is used to obtain configuration information of the target hardware; The sending module is used to send pre-stored configuration information of the target hardware to the application when the current state is the startup state. The configuration information is obtained from the target hardware by a designated service when preset conditions are met.

10. An electronic device, comprising: At least one processor; A memory that stores computer program instructions; Hardware used to perform specific functions; The processor is configured to execute the computer program instructions to perform the following steps: In response to receiving a target request from an application to invoke target hardware, the current state of the application is determined, wherein the target request is used to obtain configuration information of the target hardware; When the current state is the startup state, the pre-stored configuration information of the target hardware is sent to the application. The configuration information is obtained from the target hardware by a designated service when preset conditions are met.

Images