Graphic processing mode switching method, and electronic device

Abstract

The present application relates to the technical field of terminals. Provided are a graphic processing mode switching method, and an electronic device. The method comprises: displaying a first interface of a first application, wherein the first interface is generated in a first graphic processing mode; during the display of the first interface, detecting that a first event occurs in the first application, wherein the first event is an abnormal event that is triggered by the first graphic processing mode; in response to the first event, when the first application meets a preset condition, switching the graphic processing mode corresponding to the first application from the first graphic processing mode to a second graphic processing mode; and displaying a second interface of the first application, wherein the second interface is generated in the second graphic processing mode. In this way, the probability of an anomaly occurring in an application of an electronic device can be reduced.

Description

Graphics processing mode switching method and electronic device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 7, 2024, with application number 202410175972.8 and invention name “A Graphics Processing Mode Switching Method and Electronic Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to a graphics processing mode switching method and an electronic device. Background Art

[0003] Vulkan is an application programming interface (API) for two-dimensional (2D) and three-dimensional (3D) graphics processing, first announced by the Khronos Group at the 2015 Game Developers Conference (GDC). Vulkan supports multi-threaded rendering, significantly reducing graphics API overhead and processor load compared to OpenGL for Embedded Systems (OpenGL ES). Vulkan has been called the "next generation of OpenGL" and is intended to replace OpenGL ES.

[0004] Currently, some electronic devices use Vulkan to perform graphics processing tasks. However, Vulkan's compatibility with some applications is not yet sufficient, and electronic devices may encounter stability and performance issues when using Vulkan for graphics processing. Summary of the Invention

[0005] The present application provides a graphics processing mode switching method and an electronic device, which can improve the stability and performance of the electronic device and reduce the probability of abnormalities occurring in applications in the electronic device.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In the first aspect, a method for switching a graphics processing mode is provided, the method comprising: displaying a first interface of a first application, the first interface being generated using a first graphics processing mode. In the process of displaying the first interface, if a first event is detected in the first application, the first event is an abnormal event triggered by the first graphics processing mode, and in response to the first event, when the first application meets a preset condition, the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode. The second interface of the first application is displayed, the second interface being generated using the second graphics processing mode. In this way, the electronic device can provide an adaptive graphics processing mode for the application, thereby reducing the probability of abnormal events such as application interface freezes and application crashes, improving the stability and performance of the application, and enhancing the user experience.

[0008] In a possible implementation of the first aspect, the first graphics processing mode is one of Vulkan and OpenGL ES, and the second graphics processing mode is another graphics processing mode of Vulkan or OpenGL ES that is different from the first graphics processing mode. If the first graphics processing mode is Vulkan, the second graphics processing mode is OpenGL ES. If the first graphics processing mode is OpenGL ES, the second graphics processing mode is Vulkan. In this way, when the electronic device detects that an abnormal event has occurred in an application, it can switch the graphics processing mode corresponding to the application from Vulkan to OpenGL ES, or vice versa.

[0009] In another possible implementation of the first aspect, the preset conditions include at least one of the following: in a preset application list; the number of abnormal events reaches a preset threshold; the number of mode switches is less than or equal to a preset switching threshold, and the number of mode switches represents the number of switches between the first graphics processing mode and the second graphics processing mode.

[0010] The preset condition is used to determine whether to switch the graphics processing mode corresponding to the application. The preset condition can be set according to the actual application scenario or needs. The electronic device can quickly confirm whether to switch the graphics processing mode corresponding to the first application through the preset condition.

[0011] In another possible implementation of the first aspect, the preset application list is received from a cloud device, or the preset application list is preconfigured in the electronic device. If the preset application list is received from a cloud device, the electronic device can obtain the latest preset application list by downloading a small amount of data from the cloud device, thereby updating the preset application list and configuring the preset application list without having to restart the device.

[0012] In another possible implementation of the first aspect, the preset application list includes multiple applications and graphics processing information corresponding to the multiple applications; before displaying the first interface of the first application, it also includes: searching for the application name of the first application in the preset application list; if the application name of the first application is found in the preset application list, obtaining the graphics processing information of the first application; if the graphics processing information of the first application is the first information, using Vulkan to generate the first interface of the first application, and the first information is used to indicate Vulkan; if the graphics processing information of the first application is the second information, using OpenGL ES to generate the first interface of the first application, and the second information is used to indicate OpenGL ES.

[0013] In this implementation, the electronic device can indicate the graphics processing mode corresponding to the first application through the graphics processing information of the first application in the preset application list, so that when the first application is started, the electronic device can confirm the graphics processing mode to be used by obtaining the graphics processing information of the first application.

[0014] In another possible implementation of the first aspect, the method further includes: in response to the first event, if the first application meets a preset condition, switching the graphics processing information of the first application from the first information to the second information, or switching the graphics processing information of the first application from the second information to the first information. In this manner, the electronic device can timely update the graphics processing information of the first application, so that the electronic device executes the graphics processing tasks of the first application using a graphics processing mode adapted for the first application.

[0015] In another possible implementation of the first aspect, after the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode, the method further includes: setting the number of abnormal events to 0. In this manner, after the graphics processing mode corresponding to the first application is switched, the number of abnormal events is cleared to zero, so that the electronic device re-counts the number of abnormal events that occurred in the first application in the new graphics processing mode.

[0016] In another possible implementation of the first aspect, the first event is an interface freeze event. The method further includes: obtaining an interface response delay of the first application; if the interface response delay of the first application is greater than a preset duration, confirming that an interface freeze event has been detected in the first application. In this manner, when an interface freeze event occurs in the first application, the electronic device can switch the graphics processing mode corresponding to the first application to reduce the probability of the first application experiencing an interface freeze event again.

[0017] In another possible implementation of the first aspect, the first event is a target flash back event. If a flash back event occurs in the first application, an event log of the flash back event is obtained. If keyword information of the first graphics processing mode is detected in the event log, it is confirmed that the target flash back event of the first application has been detected. In this way, the electronic device can switch the graphics processing mode corresponding to the first application when a target flash back event occurs in the first application, so as to reduce the probability of the target flash back event occurring again in the first application. The target flash back event is a flash back event caused by Vulkan or OpenGL ES.

[0018] In another possible implementation of the first aspect, the method further includes: if a first event of the first application is detected, adding 1 to the number of abnormal events. In this way, the number of abnormal events occurring in each graphics processing mode of the first application can be counted.

[0019] In another possible implementation of the first aspect, after the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode, the number of mode switches for the first application is incremented by 1. In this way, the electronic device can count the number of times the first application switches from Vulkan to OpenGL ES and / or the number of times it switches from OpenGL ES to Vulkan, and use the counted number of mode switches as a basis for determining whether to switch the graphics processing mode.

[0020] In another possible implementation of the first aspect, after the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode, during the display of the second interface, if a second event is detected in the first application, where the second event is an abnormal event triggered by the second graphics processing mode, the graphics processing mode corresponding to the first application is switched from the second graphics processing mode to the first graphics processing mode in response to the second event. In this manner, the electronic device can also switch the graphics processing mode corresponding to the first application from the second graphics processing mode back to the first graphics processing mode, thereby selecting an appropriate graphics processing mode for the graphics processing task of the first application and reducing the probability of abnormal events occurring in the first application.

[0021] In a second aspect, the present application provides an electronic device comprising: a memory, a processor, and a computer program stored in the memory. When the processor runs the computer program, the electronic device executes the method described in the first aspect and any possible implementation thereof.

[0022] In a third aspect, the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed by an electronic device, the electronic device executes the method described in the first aspect and any possible implementation thereof.

[0023] In a fourth aspect, the present application provides a computer program product comprising program instructions, including a computer program, which, when executed by an electronic device, enables the computer to perform the method described in the first aspect and any possible implementation thereof. For example, the computer may be the electronic device described above.

[0024] In a fifth aspect, the present application provides a chip system, which is applied to an electronic device. The chip system includes an interface circuit and a processor. The interface circuit and the processor are interconnected via a circuit. The interface circuit is configured to receive signals from a memory and send signals to the processor, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device executes the method described in the first aspect and any possible implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] FIG1 is a schematic diagram showing a performance comparison between Vulkan and OpenGL ES provided in an embodiment of the present application;

[0026] FIG2 is a schematic diagram of a function call during a rendering process of an electronic device provided by an embodiment of the present application;

[0027] FIG3 is a schematic diagram of an event log provided in an embodiment of the present application;

[0028] FIG4 is a hardware structure block diagram of a mobile phone 100, an example of an electronic device provided in an embodiment of the present application;

[0029] FIG5 is a software structure block diagram of a mobile phone 100, an example of an electronic device provided in an embodiment of the present application;

[0030] FIG6 is a flowchart of a method for switching a graphics processing mode provided in an embodiment of the present application;

[0031] FIG7 is a flowchart of a graphics processing mode selection provided by an embodiment of the present application;

[0032] FIG8 is a flowchart of obtaining a preset application list provided in an embodiment of the present application;

[0033] FIG9 is a schematic diagram of status information provided in an embodiment of the present application;

[0034] FIG10 is a flowchart of another method for switching graphics processing modes provided in an embodiment of the present application;

[0035] FIG11 is a schematic diagram of another event log provided in an embodiment of the present application;

[0036] FIG12 is a flowchart of an embodiment of the present application for determining whether a preset condition is met. DETAILED DESCRIPTION

[0037] OpenGL ES is a subset of the Open Graphics Library (OpenGL), a 3D graphics library designed for embedded devices such as mobile phones and tablets. OpenGL ES includes multiple functions and is widely used for graphics processing tasks in electronic devices. However, with the development of electronic device hardware and the increasing demand for graphics processing, OpenGL ES has struggled to achieve breakthroughs in aspects such as frame rate and energy consumption. Vulkan, a newly proposed graphics processing library, can improve graphics processing performance. Vulkan is the next step in the evolution of graphics processing, replacing OpenGL ES.

[0038] Currently, many electronic devices use Vulkan instead of OpenGL ES to perform graphics processing tasks. Compared to OpenGL ES, electronic devices using Vulkan can improve the efficiency of graphics processing tasks and reduce the response latency of application interfaces. For example, take the electronic device being a mobile phone as an example. As shown in Figure 1, mobile phone 1 uses Vulkan to perform graphics processing tasks, and mobile phone 2 uses OpenGL ES to perform graphics processing tasks. For a test scenario in which mobile phones 1 and 2 run the same application, the average response latency of mobile phone 1 in response to a user operation of sliding the application interface and controlling the sliding of the application interface is tested, and the average response latency of mobile phone 2 in response to a user operation of sliding the application interface and controlling the sliding of the application interface is tested. After testing, the average response latency corresponding to mobile phone 1 was reduced by 31% compared to the average response latency corresponding to mobile phone 2. It can be seen that the use of Vulkan in electronic devices can reduce the response latency of the application interface.

[0039] However, Vulkan support in electronic devices is not as comprehensive as OpenGL ES, and some stability and performance issues still exist. For example, when electronic devices use Vulkan to generate application interfaces, the application interface may freeze or crash, affecting the user experience.

[0040] In one example, an electronic device uses Vulkan to generate an application interface for a search application, and displays the application interface for the search application at a screen refresh rate of 120 Hz. As shown in Figure 2, the electronic device renders a frame image (or rendering frame) of the application interface of the search application through a rendering thread (Render Thread). During the rendering process, the rendering thread calls at least one function to render the frame image, and this at least one function includes a drawing function in Vulkan. The drawing function takes about 180 milliseconds to draw the frame image. Normally, the drawing time for a frame image is about 30 milliseconds. In this case, the application interface displayed by the electronic device will become stuck, reducing the user experience.

[0041] In another example, an electronic device, through a web view (webView), calls the Vulkan graphics pipeline creation function (vkCreateGraphicsPipelines) to create a rendering pipeline to display a web page in a browser application. Because the web view calls vkCreateGraphicsPipelines too many times and no cache is configured, the web page will be stuck.

[0042] In another example, an electronic device uses Vulkan to render the video interface of a video application. While running the video application, the electronic device experiences a crash. The event log for this crash is shown in Figure 3. Analysis of this backtrace log reveals that the crash is caused by a null Vulkan image pointer (GrVkImage).

[0043] In another example, an electronic device uses Vulkan to render the news interface of a news application. While running the news application, the electronic device experiences a crash. Analysis of the news application's backtrace log reveals that the crash is caused by a Vulkan driver error.

[0044] From the above examples, we can see that although the use of Vulkan in electronic devices can reduce the response delay of the application interface, since the support for Vulkan in electronic devices is not as complete as OpenGL ES, there are still some problems when using Vulkan to perform graphics processing tasks.

[0045] An embodiment of the present application provides a method that can reduce the probability of abnormal events such as interface freeze and application crash in an electronic device. The electronic device displays a first interface of a first application, and the first interface is generated using a first graphics processing mode. If the electronic device detects an abnormal event that has occurred in the first application, the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode if the first application meets a preset condition. After switching the image processing mode corresponding to the first application to the second image processing mode, the electronic device generates a second interface of the first application using the second image processing mode, and displays the second interface of the first application.

[0046] The first graphics processing mode is a graphics processing mode in Vulkan and OpenGL ES, and the second graphics processing mode is another graphics processing mode in Vulkan and OpenGL ES that is different from the first graphics processing mode. If the first graphics processing mode is Vulkan, the second graphics processing mode is OpenGL ES. If the first graphics processing mode is OpenGL ES, the second graphics processing mode is Vulkan. In this way, when an electronic device detects that an abnormal event has occurred in an application, it can switch the graphics processing mode corresponding to the application from Vulkan to OpenGL ES, or from OpenGL to Vulkan. In this way, the electronic device can provide an adaptive graphics processing mode for the application, thereby reducing the probability of abnormal events such as application interface freezes and application crashes, improving the stability and performance of the application, and improving the user experience.

[0047] It is understandable that although the electronic device is configured with the Vulkan graphics processing solution, in order to maintain compatibility with OpenGL ES, the electronic device also supports the OpenGL ES graphics processing solution. Of course, in the embodiments of this application, the switching of graphics processing modes is described using Vulkan and OpenGL ES as an example, but it is not limited to Vulkan and OpenGL ES. The graphics processing mode may also include other graphics processing modes besides Vulkan and OpenGL ES.

[0048] For example, the electronic devices described in the embodiments of the present application may be mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) and virtual reality (VR) devices, media players, wearable devices, and the like. The embodiments of the present application do not impose any particular restrictions on the specific form of the electronic devices.

[0049] In the embodiment of the present application, the electronic device is a mobile phone 100 as an example, and the hardware structure of the electronic device is described through the mobile phone 100. As shown in Figure 4, the mobile phone 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identification module (SIM) card interface 195.

[0050] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a data processing unit (DPU), a baseband processor, and / or a neural-network processing unit (NPU), a driver processor, etc. Different processing units may be independent devices or integrated into one or more processors. The processor 110 may be the nerve center and command center of the mobile phone 100. The processor 110 may generate an operation control signal based on the instruction opcode and the timing signal to complete the control of instruction fetching and execution.

[0051] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0052] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0053] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the mobile phone 100 by running the instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 can execute instructions stored in the internal memory 121, and the internal memory 121 may include a program storage area and a data storage area. The internal memory 121 may include a high-speed random access memory, such as a double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0054] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also provide power to the mobile phone 100 through the power management module 141.

[0055] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160. In some embodiments, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0056] The wireless communication function of the mobile phone 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. In some embodiments, antenna 1 of the mobile phone 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technology.

[0057] The mobile communication module 150 can provide wireless communication solutions for mobile phone 100, including 2G / 3G / 4G / 5G. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from antenna 1, filter and amplify the received electromagnetic waves, and transmit them to the modem processor for demodulation.

[0058] The wireless communication module 160 can provide wireless communication solutions for application on the mobile phone 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), etc.

[0059] The mobile phone 100 can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0060] The sensor module 180 may include a pressure sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a Hall sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc. The mobile phone 100 may collect various data through the sensor module 180 .

[0061] Mobile phone 100 implements display functionality through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0062] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0063] In some implementations, a touch sensor may be provided within the display screen 194 , with the touch sensor and display panel forming a touch screen, also known as a "touch screen." The touch sensor, also known as a "touch panel" (TP), is configured to detect touch operations, such as clicks and slides, applied thereto or in the vicinity thereof. The touch sensor may transmit the detected touch operations to an application processor to determine the type of touch event. The mobile phone 100 may provide visual output related to the touch operations via the display screen 194 .

[0064] Mobile phone 100 can implement a camera function through an ISP, camera 193, video codec, GPU, display 194, and application processor. The ISP is used to process data fed back by camera 193. Camera 193 is used to capture still images or videos. In some embodiments, mobile phone 100 may include one or more cameras 193.

[0065] It is to be understood that the interface connection relationship between the modules illustrated in this embodiment is merely a schematic illustration and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also include more or fewer modules than those provided in the above embodiments, and different interface connection methods or a combination of multiple interface connection methods may be used between the modules. The hardware structure of the electronic device provided in the embodiments of the present application may also refer to the hardware structure of the mobile phone 100 shown in the figure. The methods in the following embodiments can all be implemented in an electronic device having the above hardware structure.

[0066] The software system of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture, or a cloud architecture. In the embodiment of the present application, the electronic device is the mobile phone 100, and the software system of the electronic device adopts the layered architecture of the Android system as an example to illustrate the software structure of the electronic device.

[0067] Figure 5 is a block diagram of the software structure of the mobile phone 100 according to an embodiment of the present application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system may include an application layer, an application framework layer, an Android runtime (ART) and system libraries, a hardware abstraction layer (HAL), and a kernel layer.

[0068] The application layer may include a series of application packages. For example, an application package may include themes or wallpapers, window applications, game applications, video applications, camera applications, desktop applications, screen recording applications, screen projection applications, fingerprint applications, settings applications, system user interfaces (System UI), and other applications. This embodiment of the application does not impose any restrictions on this.

[0069] The application framework layer provides an application programming interface (API) and a programming framework for the applications of the application layer. For example, the application framework layer can provide an application framework, a view framework, a hardware framework, a graphics framework, etc. Among them, the graphics architecture is used to provide a graphics processing interface. The graphics framework may include drawing (Canvas), hardware rendering (Hardware), encoding and decoding (such as Bitmap), interface texture (Surface Texture), interface view (GLSurface View), OpenGL ES API and Vulkan API, etc. The application framework layer can also provide some services. For example, the application framework layer may include activity management service (ActivityManagerService, AMS), window management service (WindowManagerService, WMS), display management service (DisplayManagerService, DMS), input management service (InputManagerService, IMS), package management service (Package Manager Service, PMS), etc., and the embodiments of this application do not impose any restrictions on this.

[0070] The Android runtime consists of core libraries and a virtual machine (VM). The Android runtime is responsible for scheduling and management of the Android system. The core libraries consist of two parts: one containing the Java language's callable functions and the other the Android core library. The application layer and the application framework layer run in the VM. The VM executes the Java files in the application layer and application framework layer as binary files. The VM is responsible for performing functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0071] The system library can include multiple functional modules. For example, the system library includes multiple functional modules for rendering, such as the Hardware Accelerated Rendering Engine for UI (HWUI), GraphicBuffer / Queue, 2D graphics processing library (e.g., SKIA), and 3D graphics processing library (e.g., OpenGL ES, Vulkan). The system library also includes multiple functional modules for display control, such as SurfaceFlinger (for layer synthesis and display control) and RenderEngine. The system library can also include Media Libraries, SQLit, Camera library, Input library, etc.

[0072] The HAL layer encapsulates the Linux kernel driver, provides an interface to the upper layer, and shields the implementation details of the underlying hardware. For example, the HAL layer can include multiple HAL modules for rendering, such as the graphics memory allocator (Gralloc) HAL and the graphics processor (gfx libs) HAL. The HAL layer can also include multiple HAL modules for display control, such as the hardware compositor (HWC) HAL and the display (Display) HAL. The HAL layer can also include the touch (TP) HAL, etc.

[0073] The kernel layer is the layer between hardware and software. It includes drivers and system services. Drivers include at least the memory management (ION) driver, GPU driver, DPU driver, display driver, and input driver. ION and GPU drivers are used for rendering, while DPU and display drivers are used for display control.

[0074] The following is an example of the workflow of the software and hardware of the mobile phone 100, with reference to the application interface display scenario.

[0075] In response to a user click on the camera application icon on the desktop, mobile phone 100 launches the camera application. The camera application calls the graphics framework in the application framework layer and calls OpenGL ES or Vulkan through the application programming interface (e.g., the OpenGL ES API or the Vulkan API) in the graphics framework. Mobile phone 100 renders the camera application's application interface (API) using OpenGL ES or Vulkan. During the rendering of the camera application's application interface, mobile phone 100 also calls the HAL module for rendering in the HAL layer and the driver for rendering in the kernel layer, such as the Gralloc HAL and the GPU driver. Combined with the GPU, the rendering task of the application interface is processed to generate multiple graphics windows corresponding to the application interface. Mobile phone 100 further synthesizes the multiple graphics windows (or layers) using the display control function module (e.g., SurfaceFlinger) and the rendering engine in the system library to obtain the camera application's application interface. Mobile phone 100 then displays the camera application's application interface on display screen 194 using the display control HAL module (e.g., the display HAL) and the driver (e.g., the display driver).

[0076] It is understood that this embodiment is only a schematic illustration of the workflow of an electronic device displaying an application interface and does not constitute a limitation on the display of the application interface. In other embodiments, the electronic device may also use other software structures or software modes to display the application interface.

[0077] As described above, in an embodiment of the present application, the electronic device can, when an abnormal event occurs in the application, switch the graphics processing mode corresponding to the application from the first graphics processing mode to the second graphics processing mode to reduce the probability of an abnormal event occurring in the application. In an embodiment of the present application, the abnormal event that occurs in the application is an abnormal event that occurs in the interface generation stage, such as an abnormal event that occurs in the process of generating the application interface using OpenGL ES or Vulkan. If the electronic device detects that an abnormal event has occurred in the application, it can be considered that the abnormal event is caused by OpenGL ES or Vulkan. In this case, the electronic device switches the first graphics processing mode to the second graphics processing mode to reduce the probability of an abnormal event occurring in the application again.

[0078] It can be understood that the graphics processing mode is a graphics processing solution for generating an application interface, such as OpenGL ES and Vulkan. The process of an electronic device generating an application interface through a graphics processing mode may include multiple processes such as graphics drawing and graphics rendering, involving multiple functions corresponding to the graphics processing mode. When an electronic device generates an application interface through a graphics processing mode, it can be understood that the electronic device generates an application interface through multiple functions corresponding to the graphics processing mode. The graphics processing mode may also be referred to as a graphics processing channel, a graphics processing pipeline, etc. In some implementations, the graphics processing mode may also correspond only to a graphics rendering process. In this case, the graphics processing mode may also be referred to as a rendering channel, a rendering pipeline, etc.

[0079] The following describes the method provided by the embodiment of the present application, taking the electronic device as a mobile phone 100 as an example. As shown in FIG6 , the method provided by the embodiment of the present application includes the following steps:

[0080] S601, the mobile phone 100 displays a first interface of a first application, where the first interface is generated using a first graphics processing mode.

[0081] The first application is one of multiple applications installed in mobile phone 100. For example, the first application can be a video application or a game application. Mobile phone 100 runs the first application and displays the first interface of the first application. The first interface is any interface of the first application. For example, mobile phone 100 receives a user operation to launch the first application. In response to the user operation, mobile phone 100 launches the first application and generates the first interface of the first application using multiple functions corresponding to the first graphics processing mode. After generating the first interface of the first application, mobile phone 100 displays the first interface of the first application. The first graphics processing mode is Vulkan or OpenGL ES.

[0082] In some implementations, the graphics processing mode corresponding to the first application can be pre-set. For example, some applications in mobile phone 100 default to Vulkan, while other applications in mobile phone 100 default to OpenGL ES. After launching the first application, mobile phone 100 generates the application interface of the first application using the default graphics processing mode corresponding to the first application.

[0083] In other implementations, a preset application list is provided in the mobile phone 100. The preset application list is used to record the identifier (such as the application name) of at least one application that uses Vulkan to execute the graphics processing task of the first application. If the application name of the first application is in the preset application list, that is, the first application is in the preset application list, after the mobile phone 100 starts the first application, it uses Vulkan to execute the graphics processing task of the first application and generates the first interface of the first application. In this case, the first graphics processing mode is Vulkan. If the application name of the first application is not in the preset application list, that is, the first application is not in the preset application list, after the mobile phone 100 starts the first application, it uses OpenGL ES to execute the graphics processing task of the first application and generates the first interface of the first application. In this case, the first graphics processing mode is OpenGL ES.

[0084] In some other implementations, the graphics processing information of the first application is further provided in the mobile phone 100. The mobile phone 100 can determine the graphics processing mode corresponding to the first application through the graphics processing information of the first application.

[0085] For example, the preset application list set by mobile phone 100 may include multiple application names and graphics processing information corresponding to each of the multiple application names. The graphics processing information indicates the graphics processing mode corresponding to the application. The graphics processing information may be first information or second information. The first information indicates Vulkan. The second information indicates OpenGL ES. After launching a first application, mobile phone 100 searches the preset application list for the application name of the first application. If the preset application list contains the application name of the first application, mobile phone 100 retrieves the graphics processing information of the first application from the preset application list. If the graphics processing information of the first application is the first information, mobile phone 100 uses Vulkan to perform the graphics processing tasks of the first application and generates the first interface of the first application. In this case, the first graphics processing mode is Vulkan. If the graphics processing information of the first application is the second information, mobile phone 100 uses OpenGL ES to perform the graphics processing tasks of the first application and generates the first interface of the first application. In this case, the first graphics processing mode is OpenGL ES.

[0086] Through the above-mentioned various implementation methods, the mobile phone 100 can determine the graphics processing mode corresponding to the first application, and thus execute the graphics processing task of the first application through the graphics processing mode corresponding to the first application when running the first application.

[0087] The following example describes the process of the mobile phone 100 selecting Vulkan or OpenGL ES for the first application to execute the graphics processing task of the first application based on the preset application list. As shown in Figure 7, the mobile phone 100 starts the first application in response to the user operation. The first application of the mobile phone 100 calls the rendering pipeline type acquisition function (such as peekRenderPipelineType) and determines whether the first application supports Vulkan through the rendering pipeline type acquisition function. For example, the mobile phone 100 can obtain the first performance parameter of the first application, such as the first performance parameter can be recorded as supportSkiavk. The first performance parameter is used to indicate whether the first application supports Vulkan. If the first application does not support Vulkan, the mobile phone 100 can use OpenGL ES to execute the graphics processing task of the first application. Of course, if the first application does not support Vulkan, the mobile phone 100 can also try to use Vulkan to execute the graphics processing task of the first application.

[0088] If the first application supports Vulkan, the mobile phone 100 further determines whether the first application is an application recommended to use Vulkan. For example, the mobile phone 100 can obtain the second performance parameter of the first application, such as the second performance parameter can be recorded as ro.hwui.use_vulkan. The second performance parameter is used to indicate whether the first application is recommended to use Vulkan. If the first application is not an application recommended to use Vulkan, the mobile phone 100 uses OpenGL ES to perform the graphics processing tasks of the first application. If the first application is an application recommended to use Vulkan, it is further determined whether the first application is a system application. If the first application is a system application, the mobile phone 100 uses Vulkan to perform the graphics processing tasks of the first application. If the first application is not a system application, the mobile phone 100 determines whether the first application is in the preset application list. The preset application list can be used to indicate third-party applications that use Vulkan by default. If the first application is in the preset application list, it can be considered that the first application is a third-party application that uses Vulkan by default. In this case, the mobile phone 100 uses Vulkan to perform the graphics processing tasks of the first application, generates the first interface of the first application through the Vulkan rendering pipeline, and displays the first interface of the first application. If the first application is not in the preset application list, it can be considered that the first application is a third-party application that uses OpenGL ES by default. In this case, the mobile phone 100 uses OpenGL ES to perform the graphics processing tasks of the first application, generates the first interface of the first application through the OpenGL ES rendering pipeline, and displays the first interface of the first application.

[0089] In other examples, if the first application is in a preset application list, mobile phone 100 may further obtain graphics processing information of the first application from the preset application list. If the graphics processing information of the first application is the first information, mobile phone 100 uses Vulkan to perform the graphics processing tasks of the first application and generates the first interface of the first application through the Vulkan rendering pipeline. If the graphics processing information of the first application is the second information, mobile phone 100 uses OpenGL ES to perform the graphics processing tasks of the first application and generates the first interface of the first application through the OpenGL ES rendering pipeline.

[0090] It is understandable that the applications whose application names are in the preset application list use Vulkan by default to perform graphics processing tasks. However, in some cases, such as when the mobile phone 100 uses Vulkan to perform graphics processing tasks of the applications in the preset application list, abnormal events such as interface freeze or flash back occur. In this case, the mobile phone 100 can also use OpenGL ES to perform graphics processing tasks of the applications in the preset application list. It can be seen that the preset application list is not only used to indicate the applications that correspond to Vulkan by default, but also to indicate applications with switchable graphics processing modes. The mobile phone 100 can determine the graphics processing mode corresponding to the first application through the graphics processing information provided by the preset application list.

[0091] S602 , during the process of displaying the first interface, the mobile phone 100 detects a first event of the first application.

[0092] The first event is an abnormal event caused by Vulkan or OpenGL ES. For example, the first event is an interface freeze or crash caused by Vulkan or OpenGL ES. If, while displaying the first interface, mobile phone 100 detects that the first event has occurred in the first application, it can be considered that mobile phone 100 has experienced performance degradation or stability degradation while processing the graphics processing task of the first application using the first graphics processing mode. In this case, mobile phone 100 executes S603.

[0093] If the first event does not occur in the first application, it can be considered that the mobile phone 100 performs well in terms of performance and stability when processing the graphics processing task of the first application using the first graphics processing mode. In this case, the mobile phone 100 continues to use the first graphics processing mode to execute the graphics processing task of the first application and displays the first interface generated by the first graphics processing mode.

[0094] S603 , in response to the first event, the mobile phone 100 determines whether the first application meets a preset condition.

[0095] The preset condition is used to determine whether to switch the graphics processing mode corresponding to the application. The preset condition can be set according to the actual application scenario or requirements. In response to the first event of the first application, the mobile phone 100 determines whether to switch the graphics processing mode corresponding to the first application based on the preset condition.

[0096] If the first application meets the preset conditions, the mobile phone 100 may switch the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode, that is, execute S604. If the first application does not meet the preset conditions, the mobile phone 100 does not switch the graphics processing mode corresponding to the first application.

[0097] In some implementations, the preset conditions include at least one of the following: the name of the first application is in a preset application list; the number of abnormal events reaches a preset threshold; the number of mode switches corresponding to the first application is less than a preset threshold, where the mode switch number represents the number of switches between the first graphics processing mode and the second graphics processing mode. When the mobile phone 100 is in the first graphics processing mode, the mode switch number represents the number of switches from the first graphics processing mode to the second graphics processing mode. When the mobile phone 100 is in the second graphics processing mode, the mode switch number represents the number of switches from the second graphics processing mode to the first graphics processing mode.

[0098] As described above, the preset application list is also used to indicate applications for which graphics processing modes can be switched. If the name of the first application is in the preset application list, the first application can be considered an application for which graphics processing modes can be switched. If the mobile phone 100 detects that a first event has occurred in the first application, it further determines whether the first application is in the preset application list to confirm whether the graphics processing mode corresponding to the first application can be switched.

[0099] The number of abnormal events is the number of abnormal events that occur in the first application in the first graphics processing mode. For example, when the mobile phone 100 executes any graphics processing of the first application through the first graphics processing mode, the number of abnormal events that occur in the first application is counted. If the number of abnormal events that occur in the first application reaches a preset number threshold (such as reaching a preset number threshold of 3 times, 4 times, etc.), it can be considered that the first application has experienced multiple abnormal events in the first graphics processing mode, and the first graphics processing mode is less compatible with the first application. Therefore, the number of abnormal events can also be used as a basis for judging whether to switch the graphics processing mode corresponding to the first application. If the mobile phone 100 detects that the first event has occurred in the first application, it further determines whether the number of abnormal events has reached the preset number threshold to confirm whether to switch the graphics processing mode corresponding to the first application.

[0100] In the first graphics processing mode, the mode switching count is used to indicate the number of times the first graphics processing mode is switched to the second graphics processing mode. For example, if the mode switching count is equal to 1, it means that the mobile phone 100 has performed one switch from Vulkan to OpenGL ES or OpenGL ES to Vulkan. If the mode switching count of the first application is less than the preset switching threshold (such as less than 1 time), it can be considered that the mobile phone 100 has not yet switched the graphics processing mode corresponding to the first application, or the mode switching count of the first application is small, and the mobile phone 100 can reduce the probability of the first event occurring again by switching the graphics processing mode corresponding to the first application. Therefore, the mode switching count can also be used as a basis for judging whether to switch the graphics processing mode corresponding to the first application. If the mobile phone 100 detects that the first event has occurred in the first application, it further determines whether the mode switching count of the first application is less than the preset switching threshold to confirm whether to switch the graphics processing mode corresponding to the first application.

[0101] The above-mentioned preset conditions can be used as a basis for determining whether the mobile phone 100 switches the graphics processing mode corresponding to the first application. By using the preset conditions, the mobile phone 100 can quickly determine whether to switch the graphics processing mode corresponding to the first application.

[0102] In some implementations, the preset application list further records the number of abnormal events and / or mode switching times corresponding to multiple applications. In response to a first event of a first application, mobile phone 100 obtains the number of abnormal events and / or mode switching times for the first application from the preset application list, and further determines whether a preset condition is met based on the number of abnormal events and / or mode switching times for the first application.

[0103] S604: The mobile phone 100 switches the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode.

[0104] If the first application meets the preset conditions, the mobile phone 100 switches the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode. For example, taking the first graphics processing mode as Vulkan and the second graphics processing mode as OpenGL ES, if the first application meets the preset conditions, the mobile phone 100 switches the graphics rendering interface called from the Vulkan API to the OpenGL ES API, and calls the OpenGL ES rendering pipeline through the OpenGL ES API to switch the rendering pipeline corresponding to the first application from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline.

[0105] In some implementations, the mobile phone 100 may switch the graphics processing mode corresponding to the first application based on the graphics processing information of the first application in the preset application list. For example, if the first application meets a preset condition, the mobile phone 100 switches the graphics processing information of the first application in the preset application list from the first information to the second information, or switches the graphics processing information of the first application from the second information to the first information. If the mobile phone 100 detects a change in the graphics processing information of the first application in the preset application list, it switches the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode.

[0106] In the above implementation, the mobile phone 100 indicates the graphics processing mode corresponding to the first application using the graphics processing information of the first application in the preset application list. In some examples, after the mobile phone 100 changes the graphics processing information of the first application in the preset application list, when the mobile phone 100 restarts the first application, it re-obtains the graphics processing information of the first application from the preset application list. The mobile phone 100 further uses the graphics processing mode indicated by the changed graphics processing information to perform the graphics processing task of the first application. Because the graphics processing information of the first application in the preset application list has changed, the graphics processing mode used by the mobile phone 100 for the first application has also changed, thereby switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode. In other examples, the mobile phone 100 can switch the graphics processing mode corresponding to the first application based on the changed graphics processing information of the first application in the preset application list without restarting the first application, thereby switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode. The embodiments of the present application do not restrict the timing of switching the graphics processing mode corresponding to the first application.

[0107] S605 , the mobile phone 100 displays a second interface of the first application, where the second interface is generated using a second graphics processing mode.

[0108] After switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode, mobile phone 100 generates a second interface for the first application using multiple functions corresponding to the second graphics processing mode. After generating the second interface for the first application, mobile phone 100 displays the second interface for the first application. The second graphics processing mode is a graphics processing mode in Vulkan or OpenGL ES that is different from the first graphics processing mode.

[0109] Through the solution provided by the embodiment of the present application, the mobile phone 100 can switch the graphics processing mode corresponding to the first application when an abnormal event is detected in the first application, so as to reduce the probability of the abnormal event occurring again in the first application and improve the user experience.

[0110] In some implementations, after the graphics processing mode corresponding to the first application is switched from the first graphics processing mode to the second graphics processing mode, if the mobile phone 100 detects a second event occurring in the first application while displaying the second interface, the mobile phone 100 switches the graphics processing mode corresponding to the first application from the second graphics processing mode to the first graphics processing mode in response to the second event. The second event is an abnormal event triggered by the second graphics processing mode. For example, the second event is an interface freeze or crash event caused by Vulkan or OpenGL ES.

[0111] For example, when the mobile phone 100 is displaying the second interface, if it detects that a second event has occurred in the first application, in response to the second event, the mobile phone 100 determines whether the first application meets the preset conditions. If the first application meets the preset conditions, the mobile phone 100 switches the graphics processing mode corresponding to the first application from the second graphics processing mode to the first graphics processing mode. The process of the mobile phone 100 switching the graphics processing mode corresponding to the first application from the second graphics processing mode to the first graphics processing mode is similar to the process of the mobile phone 100 switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode. Please refer to the description above and will not be repeated here.

[0112] As mentioned above, the mobile phone 100 can determine the graphics processing mode corresponding to the first application through a preset application list. The preset application list is described below through some implementation methods.

[0113] The preset application list may be pre-configured in the mobile phone 100. Alternatively, the preset application list is received by the mobile phone 100 from a cloud device.

[0114] For example, mobile phone 100 can receive a list of preset applications from a cloud device. For example, when an updated operating system update package is available, the cloud device (such as a cloud server) can include the list of preset applications in a system update package for mobile phone 100 and send the system update package to mobile phone 100. Mobile phone 100 receives the system update package sent by the cloud device and further obtains the list of preset applications from the system update package. In this way, mobile phone 100 can update the list of preset applications while using the system update package to update the operating system.

[0115] For another example, a cloud device (such as a cloud server) can send a preset application list to the mobile phone 100 when there is an update in the preset application list (such as an updated application name or graphics processing information). The mobile phone 100 can then select an appropriate graphics processing mode for the application based on the preset application list. In this way, the cloud device can flexibly set the preset application list. The mobile phone 100 can obtain the latest preset application list by downloading a small amount of data from the cloud device, thereby updating the preset application list and achieving the purpose of configuring the preset application list without restarting.

[0116] In some implementations, the mobile phone 100 can save the preset application list in a preset file. The mobile phone 100 can obtain the preset application list in the preset file. Exemplarily, the preset file can be recorded as DynamicFpaXml. As shown in Figure 8, the mobile phone 100 obtains the attribute parameters (such as Properties) of the first application through the rendering pipeline type acquisition function. If the attribute parameters of the first application indicate that the first application supports Vulkan, the mobile phone 100 accesses the graphics system interface (Accelerated Graphics Port, AGP) service (AGPService) through binder (a cross-process communication mechanism). Furthermore, the mobile phone 100 accesses the preset file DynamicFpaXml under the graphics system interface service file (AGPService.cpp) through AGPService to obtain the preset application list.

[0117] In some implementations, the preset application list includes the application names of multiple applications and status information of the multiple applications. Each application corresponds to one application name and one piece of status information. The application name may be the application package name of the application. The status information may include one or more of graphics processing information, the number of abnormal events, and the number of mode switches.

[0118] For example, taking the status information in a preset application list, which includes graphics processing information, the number of exception events, and the number of mode switches, as an example, the status information for one application is shown in FIG9 . In this example, the status information is represented as a 4-bit binary character. The first two digits of the status information represent the number of exception events. "00" represents 0, "01" represents 1, "10" represents 2, and "11" represents 3. The maximum number of exception events is 3, meaning the preset threshold number of exception events is equal to 3. The third digit of the status information represents the number of mode switches. A "0" digit indicates that the application has not switched between Vulkan and OpenGL ES. A "1" digit indicates that the application has switched between Vulkan and OpenGL ES. The maximum value of the mode switch count is 1, meaning the preset threshold number of mode switches is equal to 1. The fourth digit of the status information represents the graphics processing information. When the graphics processing information is "1" (the first example), the application's corresponding graphics processing mode is Vulkan. When the graphics processing information is "0" (the second example), the application's corresponding graphics processing mode is OpenGL ES.

[0119] The following is an example of the method provided by the embodiment of the present application, taking into account the above-mentioned example of status information and the occurrence of a target flash back event in the first application (an example of the first event). The target flash back event is a flash back event triggered by a Vulkan function or an OpenGL ES function. The occurrence of a target flash back event in the first application indicates that an abnormality has occurred in the stability of the first application. In the example, taking the first graphics mode as Vulkan and the second graphics processing mode as OpenGL ES as an example, as shown in Figure 10, the following steps are included:

[0120] S1001: When the mobile phone 100 uses the Vulkan rendering pipeline to execute a graphics processing task of a first application, it is detected that a crash event occurs in the first application.

[0121] When running a first application, mobile phone 100 uses the Vulkan rendering pipeline to process graphics processing tasks of the first application, such as using the Vulkan rendering pipeline to render the application interface of the first application. While mobile phone 100 uses the Vulkan rendering pipeline to process the graphics processing tasks of the first application, if the first application interrupts and automatically exits, it can be considered that a flash back event has occurred in the first application.

[0122] S1002, the mobile phone 100 obtains the event log of the flash back event.

[0123] If a crash occurs in the first application, the mobile phone 100 generates an event log for the crash. The event log for the crash is used to record event information of the crash on the mobile phone 100. For example, the event log for the crash contains timestamps, event types, stack information, etc. The cause of the crash can be analyzed through the event log. When the mobile phone 100 detects that a crash occurs in the first application, the mobile phone 100 obtains the event log for the crash to analyze whether the crash of the first application is a target crash caused by a Vulkan function.

[0124] S1003 , the mobile phone 100 determines whether there is Vulkan keyword information in the event log of the flash back event.

[0125] Mobile phone 100 can obtain the stack information of the event log of the crash event through AMS. The stack information is used to record function call relationships. Furthermore, mobile phone 100 determines whether the stack information contains Vulkan keyword information. For example, mobile phone 100 searches the stack information for Vulkan keyword information such as "Vk," "vk," "Vulkan," and "vulkan" through character matching.

[0126] If the event log of the crash event contains Vulkan keyword information, the crash event is considered to be caused by a Vulkan function (an example of a target crash event). For example, the event log of the crash event of the first application is shown in Figure 11, which includes the keyword information "vulkan" and "Vk", so the crash event is considered to be caused by a Vulkan function. In this case, the mobile phone 100 executes S1004.

[0127] If the Vulkan keyword information does not exist in the event log of the flash back event, it is considered that the flash back event is not caused by a Vulkan function (an example of a target flash back event). In this case, the mobile phone 100 executes S1006.

[0128] S1004 , the mobile phone 100 determines whether the first application meets a preset condition.

[0129] If the Vulkan keyword information is present in the event log of the crash event, the mobile phone 100 further determines whether the first application meets the preset conditions. The mobile phone 100 can determine whether the first application meets the preset conditions based on the preset application list. The following example illustrates the process of the mobile phone 100 determining whether the first application meets the preset conditions based on the preset application list.

[0130] For example, as shown in FIG12 , the mobile phone 100 identifies that the event log for a crash event includes Vulkan keyword information. Furthermore, the mobile phone 100 uses the list management module to determine whether the first application is in the preset application list. If the first application is not in the preset application list, the mobile phone 100 terminates the current process. If the first application is in the preset application list, the mobile phone 100 reads the status information of the first application from the preset application list. This status information indicates the operation of the first application under the Vulkan rendering pipeline, such as the graphics processing mode corresponding to the first application (in this case, indicating Vulkan), the number of target crash events that occurred in the first application under the current graphics processing mode, and the number of mode switches from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline. For example, the mobile phone 100 reads the status information of the first application from the preset application list and parses the read status information, such as converting the status information into a binary number and performing bitwise operations on the status information, to obtain binary character status information. When using the Vulkan rendering pipeline, the graphics processing information in the status information is the first information, i.e., the fourth character of the status information is "1."

[0131] Furthermore, the mobile phone 100 determines whether the third character of the status information (indicating the number of mode switches) is 1, that is, it determines whether the rendering pipeline corresponding to the first application has been switched from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline in the past. If the third character of the status information is 1, it means that the mobile phone 100 has switched the rendering pipeline corresponding to the first application from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline in the past, and the mobile phone 100 has used the Vulkan rendering pipeline and the OpenGL ES rendering pipeline to perform the graphics processing tasks of the first application, and the first application has experienced a target flash back event. In this case, switching the rendering pipeline corresponding to the first application is unlikely to improve the stability of the first application, so the mobile phone 100 ends the current process and no longer switches the rendering pipeline of the first application from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline. If the third character of the status information is 0, it means that the mobile phone 100 has not switched the rendering pipeline corresponding to the first application from the Vulkan rendering pipeline to the OpenGL ES rendering pipeline. In this case, the mobile phone 100 adds 1 to the number of target flash back events of the first application (ie, adds 1 to the first two characters of the status information).

[0132] Furthermore, the mobile phone 100 determines whether the number of target flash back events that occur in the first application reaches 3 times (that is, determines whether the first two characters of the status information are "11"). If the number of target flash back events that occur in the first application reaches 3 times, it can be considered that the first application meets the preset conditions. When the first application meets the preset conditions, the mobile phone 100 will also update the status information of the first application. Specifically, the mobile phone 100 clears the number of target flash back events (that is, sets the first two characters of the status information to "00"), adds 1 to the number of mode switching times (that is, sets the third character of the status information to "1"), and sets the graphics processing information to the second information (that is, sets the fourth character of the status information to "0"). The mobile phone 100 further updates the updated status information of the first application to the preset application list.

[0133] If the first application meets the preset conditions, the mobile phone 100 executes S1005.

[0134] If the number of target flash back events occurring in the first application does not reach 3 times, it can be considered that the first application does not meet the preset condition.

[0135] S1005 , the mobile phone 100 uses the OpenGL ES rendering pipeline to process the graphics processing task of the first application.

[0136] The mobile phone 100 processes the target flash back event of the first application and terminates the application process of the first application. The mobile phone 100 further restarts the first application. For example, the mobile phone 100 may automatically restart the first application, or the mobile phone 100 restarts the first application in response to a user operation to start the first application.

[0137] Mobile phone 100 starts the first application and obtains the graphics processing information of the first application from the preset application list. When the first application meets the preset conditions, the graphics processing information of the first application in the preset application list is the second information, and the second information is used to indicate OpenGL ES. In this case, the rendering thread of mobile phone 100 uses the OpenGL ES rendering pipeline to process the graphics processing tasks of the first application. It can be understood that if the first application meets the preset conditions, mobile phone 100 switches the graphics processing information of the first application. When mobile phone 100 starts the first application again, mobile phone 100 switches the rendering pipeline corresponding to the first application from the Vulkan rendering pipeline to the OpenGL rendering pipeline, and processes the graphics processing tasks of the first application through the OpenGL rendering pipeline.

[0138] S1006 , the mobile phone 100 uses the Vulkan rendering pipeline to process the graphics processing task of the first application.

[0139] When the first application does not meet the preset condition, the graphics processing information of the first application in the preset application list is the first information, and the first information is used to indicate Vulkan. In this case, the rendering thread of the mobile phone 100 uses the Vulkan rendering pipeline to process the graphics processing task of the first application.

[0140] It is understood that the above examples are described using the example of the first graphics processing mode being Vulkan and the second graphics processing mode being OpenGL ES. After the mobile phone 100 switches the graphics processing mode corresponding to the first application from Vulkan to OpenGL ES, the mobile phone 100 uses the OpenGL ES rendering pipeline to execute the graphics processing tasks of the first application. While the mobile phone 100 uses the OpenGL ES rendering pipeline to execute the graphics processing tasks of the first application, if it is detected that the first application has a crash event (an example of the second event), the mobile phone 100 obtains the event log of the crash event and further determines whether there is OpenGL ES keyword information in the event log of the crash event. The OpenGL ES keyword information may include keyword information such as "OpenGLES," "opengles," and "gl." If there is OpenGL ES keyword information in the event log of the crash event, the mobile phone 100 determines whether the first application meets the preset conditions. At this time, the status information of the first application in the preset application list indicates the running status of the first application under the OpenGL ES rendering pipeline, such as the graphics processing mode corresponding to the first application (OpenGL ES at this time), the number of target flash back events of the first application in the current graphics processing mode, and the number of mode switches from the OpenGL ES rendering pipeline to the Vulkan rendering pipeline. If the first application meets the preset conditions, the mobile phone 100 switches the graphics processing mode corresponding to the first application from the OpenGL ES rendering pipeline to the Vulkan rendering pipeline. The process executed by the mobile phone 100 under OpenGL ES is consistent with the process executed under Vulkan in the above example, and will not be repeated here.

[0141] The following describes the method provided by an embodiment of the present application, taking the case of a first application experiencing an interface freeze event (an example of a first event) as an example. An interface freeze event is a freeze event triggered by a Vulkan function or an OpenGL ES function. The first application experiencing an interface freeze event indicates that the first application has experienced a performance anomaly.

[0142] Exemplarily, the mobile phone 100 can determine whether an interface freeze event has occurred in the first application based on the interface response delay of the first application. For example, when the mobile phone 100 uses a first graphics processing mode (such as Vulkan) to generate the application interface of the first application, it obtains the drawing time of a drawing function (such as drawVk) to draw a frame of image. This drawing time can be used as the interface response delay of the first application. Alternatively, the mobile phone 100 can calculate the average drawing time of the drawing function to draw multiple frames of images (such as 10 frames), and this drawing time can be used as the interface response delay of the first application. If the interface response delay of the first application is greater than a preset time (such as greater than a preset time such as 133 milliseconds), it is confirmed that an interface freeze event has occurred in the first application. Accordingly, if the first event is an interface freeze event, the status information of the first application in the preset application list includes the number of interface freeze events, the number of mode switches, and graphics processing information. Among them, the preset number threshold corresponding to the number of interface freeze events can be set to a value such as 10 times.

[0143] While executing a graphics processing task for a first application in the first graphics processing mode, if the mobile phone 100 detects that the first application has experienced an interface freeze, the mobile phone 100 determines whether the first application meets a preset condition. If the first application meets the preset condition, the mobile phone 100 switches the graphics processing mode of the first application from the first graphics processing mode to the second graphics processing mode. The process of determining whether the first application meets the preset condition and the subsequent process by the mobile phone 100 can be seen in the process shown in FIG. 10 and will not be further described here.

[0144] In the embodiment of the present application, although Vulkan has advantages over OpenGL ES in terms of performance and flexibility, there is still room for improvement in Vulkan's compatibility with two-dimensional graphics engines and Vulkan's driver implementation. To ensure the user experience, if an abnormal event in the application is caused by the use of the Vulkan rendering pipeline (the number of mode switches corresponding to the Vulkan rendering pipeline is 0 at this time), then when the number of abnormal events under Vulkan reaches a preset threshold (such as 3 times), the rendering pipeline corresponding to the application can be switched to the OpenGL ES rendering pipeline (the number of mode switches corresponding to the Vulkan rendering pipeline after the switch is 1). Accordingly, if after switching the rendering pipeline corresponding to the application from the Vulkan rendering pipeline to the OpenGLES rendering pipeline, if an exception event caused by the OpenGLES rendering pipeline occurs in the application (the number of mode switches corresponding to the OpenGLES rendering pipeline is 0 at this time), then when the number of exception events under OpenGLES reaches a preset threshold (such as 3 times), the rendering pipeline corresponding to the application can be switched back to the Vulkan rendering pipeline (the number of mode switches corresponding to the OpenGLES rendering pipeline after switching is 1). If an exception event still occurs in the application, since both the Vulkan rendering pipeline and the OpenGLES rendering pipeline can cause exception events in the application, the rendering pipeline corresponding to the application may not be switched in the subsequent process.

[0145] In other embodiments of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory. When the computer program is executed by the processor, the electronic device can perform the various functions or steps in the above-described method embodiments. Of course, the electronic device may also include other hardware structures. For example, the electronic device may also include hardware structures such as sensors and communication modules. The structure of the electronic device can refer to the structure of the mobile phone 100 shown in Figure 4.

[0146] An embodiment of the present application also provides a chip system, which is applied to an electronic device. The chip system includes at least one processor and at least one interface circuit. The processor and the interface circuit can be interconnected through lines. For example, the interface circuit can be used to receive signals from other devices (such as memories). For another example, the interface circuit can be used to send signals to other devices (such as processors). Exemplarily, the interface circuit can read a computer program stored in a memory and send the computer program to the processor. When the computer program is executed by the processor, the electronic device can perform the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0147] An embodiment of the present application also provides a computer-readable storage medium, which includes a computer program. When the computer program runs on the above-mentioned electronic device, it enables the electronic device to perform various functions or steps in the above-mentioned method embodiment.

[0148] The present application also provides a computer program product, which, when executed on a computer, enables the computer to perform the functions or steps of the above method embodiment. For example, the computer may be the above electronic device.

[0149] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0151] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0152] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0153] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0154] The above content is only a specific implementation method of the present application, but the protection scope of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the protection scope of the present application.

Claims

1. A method for switching a graphics processing mode, characterized in that: Applied to electronic equipment, the method includes: Displaying a first interface of a first application, where the first interface is generated using a first graphics processing mode; During the display of the first interface, a first event is detected in the first application, where the first event is an abnormal event triggered by the first graphics processing mode; In response to the first event, if the first application meets a preset condition, switching a graphics processing mode corresponding to the first application from the first graphics processing mode to a second graphics processing mode; A second interface of the first application is displayed, where the second interface is generated using the second graphics processing mode.

2. The method according to claim 1, characterized in that The first graphics processing mode is a graphics processing mode of Vulkan and OpenGL ES, and the second graphics processing mode is another graphics processing mode of Vulkan and OpenGL ES that is different from the first graphics processing mode.

3. The method according to claim 1 or 2, characterized in that The preset conditions include at least one of the following: In the preset application list; the number of abnormal events reaches a preset threshold; the number of mode switches is less than or equal to the preset switching threshold, and the mode switching number represents the number of switches between the first graphics processing mode and the second graphics processing mode.

4. The method according to claim 3, characterized in that The preset application list is received from a cloud device, or the preset application list is pre-configured in the electronic device.

5. The method according to claim 3 or 4, characterized in that The preset application list includes a plurality of applications and graphics processing information corresponding to the plurality of applications; Before displaying the first interface of the first application, the method further includes: Searching for the application name of the first application in a preset application list; If the application name of the first application is found in the preset application list, obtaining the graphics processing information of the first application; If the graphics processing information of the first application is first information, generating a first interface of the first application using Vulkan, where the first information is used to indicate Vulkan; If the graphics processing information of the first application is the second information, OpenGL ES is used to generate the first interface of the first application, and the second information is used to indicate OpenGL ES.

6. The method according to claim 5, characterized in that The method further comprises: In response to the first event, if the first application meets a preset condition, the graphics processing information of the first application is switched from the first information to the second information, or the graphics processing information of the first application is switched from the second information to the first information.

7. The method according to any one of claims 3 to 6, characterized in that After switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode, the method further includes: The number of abnormal events is set to 0.

8. The method according to any one of claims 1 to 7, characterized in that The first event is an interface freeze event; and the method further includes: Obtaining the interface response delay of the first application; If the interface response delay of the first application is greater than the preset time length, it is confirmed that an interface freeze event of the first application has been detected.

9. The method according to any one of claims 1 to 8, characterized in that The first event is a target flash back event; the method further includes: If a flash back event occurs in the first application, obtaining an event log of the flash back event; If keyword information of the first graphics processing mode is detected in the event log, it is confirmed that a target flash back event of the first application has been detected.

10. The method according to any one of claims 3 to 9, characterized in that The method further comprises: If the first event of the first application is detected, the number of abnormal events is increased by 1.

11. The method according to any one of claims 3 to 9, characterized in that After switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode, the method further includes: The number of mode switching times of the first application is increased by 1.

12. The method according to any one of claims 1 to 11, characterized in that After switching the graphics processing mode corresponding to the first application from the first graphics processing mode to the second graphics processing mode, the method further includes: During the display of the second interface, it is detected that a second event occurs in the first application, where the second event is an abnormal event triggered by the second graphics processing mode; In response to the second event, the graphics processing mode corresponding to the first application is switched from the second graphics processing mode to the first graphics processing mode.

13. An electronic device, characterized in that: The electronic device comprises a memory, a processor, and a computer program stored in the memory, and when the processor runs the computer program, the electronic device executes the method according to any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that A computer program is stored, and when the computer program is executed by an electronic device, the electronic device executes the method according to any one of claims 1 to 12.

15. A computer program product, characterized in that The invention comprises a computer program, which, when executed by an electronic device, enables the electronic device to perform the method according to any one of claims 1 to 12.

Images