Application of diagnostic method and device for rendering exception, storage medium and electronic equipment

Abstract

This application provides a method, apparatus, storage medium, and electronic device for diagnosing application rendering anomalies. The method includes: in response to detecting a target call request of a specified application, tracking the target rendering transaction corresponding to the target call request, so that each graphics rendering call has a traceable transaction identifier and execution context, thereby transforming the originally isolated, black-box rendering behavior into a recordable and associative complete execution chain; in the case of tracking the failure of the target rendering transaction, diagnosing the multi-dimensional rendering context corresponding to the target rendering transaction, forming structured diagnostic information strongly associated with the failed transaction by synchronously collecting multi-dimensional data, obtaining a multi-dimensional diagnostic report, and pushing the multi-dimensional diagnostic report to a specified receiving end, so that the anomaly changes from an unobservable state to an analyzable and locatable observable state, thereby more accurately locating the location where the rendering anomaly occurs.

Description

Technical Field

[0001] This application relates to the field of graphics rendering, and more specifically, to a method and apparatus for diagnosing rendering anomalies, a storage medium, and an electronic device. Background Technology

[0002] In application development, the stability of graphics rendering is directly related to user experience. Currently, the graphics rendering process of applications (e.g., View system, Canvas, OpenGL ES or Vulkan) relies on the underlying rendering services (e.g. SurfaceFlinger and HWUI). However, when rendering failure occurs, the systems in the above-mentioned technologies usually only return generalized error codes (such as EGL_BAD_SURFACE) to the application layer, making it difficult to locate the root cause of the problem. Summary of the Invention

[0003] This application provides a method, apparatus, storage medium, and electronic device for diagnosing application rendering anomalies, so as to at least solve the technical problem in the related art that the location of the anomaly cannot be located when an application rendering anomaly occurs.

[0004] According to one aspect of the embodiments of this application, a method for diagnosing application rendering anomalies is provided, comprising: in response to detecting a target invocation request of a specified application, tracking a target rendering transaction corresponding to the target invocation request, wherein the target invocation request is a graphics rendering invocation request initiated by the specified application; if the target rendering transaction is found to have failed to execute, diagnosing the multidimensional rendering context corresponding to the target rendering transaction to obtain a multidimensional diagnostic report, wherein the multidimensional diagnostic report is used to describe the diagnosed target rendering anomaly occurring in the target rendering transaction; and pushing the multidimensional diagnostic report to a specified receiving end.

[0005] According to another aspect of the embodiments of this application, a diagnostic apparatus for application rendering anomalies is also provided, comprising: an interception layer, configured to track a target rendering transaction corresponding to a target rendering request in response to detecting a target rendering request of a specified application, wherein the target rendering request is a graphics rendering request initiated by the specified application; a multi-dimensional diagnostic engine, configured to diagnose the multi-dimensional rendering context corresponding to the target rendering transaction when the execution of the target rendering transaction is found to have failed; and a feedback module, configured to generate a multi-dimensional diagnostic report based on the diagnostic results of the multi-dimensional diagnostic engine and push the multi-dimensional diagnostic report to a specified receiving end, wherein the multi-dimensional diagnostic report is used to describe the diagnosed target rendering anomaly that occurred in the target rendering transaction.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0009] This application addresses the issue of tracking target rendering transactions corresponding to detected target calls from a specified application. Each graphics rendering call is then accompanied by a traceable transaction identifier and execution context, transforming the previously isolated, black-box rendering behavior into a recordable and associative complete execution chain. In cases where a target rendering transaction fails, the application diagnoses the multi-dimensional rendering context corresponding to that transaction. By synchronously collecting multi-dimensional data, structured diagnostic information strongly correlated with the failed transaction is generated, resulting in a multi-dimensional diagnostic report. This establishes a direct mapping between the anomaly and its underlying cause. The multi-dimensional diagnostic report is then pushed to a designated receiver, transforming the anomaly from an unobservable state to an analyzable and locatable observable state. This allows for more accurate location of the rendering anomaly, thus resolving the technical problem in related technologies where the location of the anomaly cannot be pinpointed when rendering anomalies occur. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of an application scenario for a method for diagnosing application rendering anomalies according to an embodiment of this application;

[0011] Figure 2 This is a flowchart illustrating an optional method for diagnosing application rendering anomalies according to an embodiment of this application.

[0012] Figure 3 This is a flowchart of an optional method for diagnosing application rendering anomalies according to an embodiment of this application;

[0013] Figure 4 This is an overall architecture block diagram of an optional system according to an embodiment of this application;

[0014] Figure 5 This is a structural block diagram of an optional diagnostic device for application rendering anomalies according to an embodiment of this application;

[0015] Figure 6 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] According to one aspect of the embodiments of this application, a method for diagnosing application rendering anomalies is provided. Optionally, in this embodiment, the above-described method for diagnosing application rendering anomalies may be applied to, but is not limited to, applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0019] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0020] The application rendering anomaly diagnosis method of this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the application rendering anomaly diagnosis method of this application embodiment can be executed by a client installed on terminal device 102.

[0021] Taking the application rendering anomaly diagnosis method executed by server 104 in this embodiment as an example, Figure 2 This is a flowchart illustrating an optional method for diagnosing application rendering anomalies according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps S202 to S206.

[0022] Step S202: In response to detecting a target call request from a specified application, the target rendering transaction corresponding to the target call request is tracked, wherein the target call request is a graphics rendering call request initiated by the specified application.

[0023] Step S204: If the execution of the target rendering transaction fails, the multidimensional rendering context corresponding to the target rendering transaction is diagnosed to obtain a multidimensional diagnostic report. The multidimensional diagnostic report is used to describe the target rendering anomaly that occurred in the target rendering transaction.

[0024] Step S206: Push the multidimensional diagnostic report to the designated receiving end.

[0025] The application rendering anomaly diagnosis method in this embodiment can be applied to the field of graphics rendering, and can be used to diagnose scenarios where application graphics rendering anomalies occur.

[0026] In application development (e.g., Android application development), the stability of graphics rendering directly affects the user experience. Currently, the graphics rendering process of applications (e.g., View system, Canvas, OpenGL ES, or Vulkan) relies on underlying rendering services such as SurfaceFlinger and HWUI. When rendering failures occur (such as Surface failure, GPU driver anomalies, resource exhaustion, etc.), the aforementioned technologies suffer from a significant deficiency in error information. That is, the system usually only returns a generalized error code (such as EGL_BAD_SURFACE) to the application layer, lacking specific failure reasons, context, and on-site data. This leaves developers facing a "black box," making it difficult to pinpoint the root cause of the problem.

[0027] To at least partially solve the aforementioned technical problems, this embodiment transforms rendering failure from a "black box" to a "white box," providing developers with accurate and multi-dimensional error diagnosis information and establishing an efficient real-time debugging and feedback mechanism. This shortens the problem localization time, makes the problem transparent, and completely changes the "unknowable" state of rendering failure. Through multi-dimensional correlation diagnosis, abstract error codes can be transformed into technical reports with clear directional information, which is expected to shorten the problem localization time by more than 70%.

[0028] In this embodiment, the specified application is the application used to execute the target invocation request. For example, the specified application may be an application on the Android operating system. The target invocation request is a graphics rendering invocation request initiated by the specified application. Optionally, the target invocation request may include View.draw(), GLES20.glDrawArrays(), Vulkan vkQueueSubmit(), Vulkan command submission, and Choreographer.postCallback(), etc.

[0029] A target rendering transaction refers to the rendering transaction corresponding to a target invocation request. Optionally, a target rendering transaction is a complete graphics rendering request processing transaction in a specified application, triggered by user interaction or system events and associated with complete context information. For example, a target rendering transaction may include the entire view tree drawing triggered by a View.draw() call; the entire frame rendering process completed in a Choreographer callback; or a Surface redraw request (such as SurfaceHolder.lockCanvas() → unlockCanvasAndPost()).

[0030] In related technologies, there is no rendering transaction. However, in the embodiments of this application, a target rendering transaction is set up for each target call request and tracked, so that the target call request can be quickly located when it is identified.

[0031] The target rendering transaction is a structured encapsulation of each graphics rendering request by the system, serving as an event anchor for diagnosis. The multidimensional rendering context, on the other hand, is a complete snapshot of the fault scene, composed of multidimensional information collected synchronously when the transaction fails. The core relationship between the two is that the target rendering transaction is the triggering carrier and tracing thread for diagnosis, while the multidimensional rendering context is the evidence set for root cause analysis. When the target rendering transaction fails, the system actively pulls and aggregates all context data bound to that transaction, organically integrating the originally discrete and isolated system state information into a traceable, analyzable, and localizable diagnostic panorama. This transforms the vague "black screen" phenomenon into a precise technical event that is traceable, reproducible, and interventionable, completely breaking the black-box dilemma of "phenomena without clues" in traditional rendering debugging.

[0032] Optionally, based on the context association identification mechanism of the graphics rendering call chain, a unique, temporal, and semantically related transaction identifier can be generated by capturing each graphics drawing request initiated by the application layer and its accompanying runtime environment characteristics to define the target rendering transaction to be diagnosed. Alternatively, by monitoring key event nodes in the graphics rendering pipeline and combining their triggering sources, resource dependencies, and system service response status, a rendering transaction boundary with causal consistency can be constructed, thereby accurately identifying and isolating the target rendering transaction to be diagnosed in concurrent rendering scenarios.

[0033] Optionally, by inserting a lightweight interception mechanism (such as Java layer dynamic proxy or Native layer PLT Hook) into the graphics rendering call chain of a specified Android application, in response to the detection of the target call request of the specified application, the target call request initiated by the specified application can be captured in real time, and the target rendering transaction corresponding to the target call request can be tracked.

[0034] For example, critical rendering calls can be intercepted non-intrusively using dynamic proxies (Java layer) or PLT Hooks (Native layer). In this way, by employing non-intrusive hooking and information enhancement methods targeting the Android graphics stack, rendering calls can be intercepted seamlessly at both the Java and Native layers, achieving end-to-end rendering monitoring without modifying application business logic or system source code.

[0035] A multidimensional rendering context refers to a set of information about the runtime environment state related to the target rendering transaction collected from multiple dimensions during the execution of the target rendering transaction. Optionally, the multidimensional rendering context may include application state rendering context, graphics application programming interface (API) state rendering context, system service state rendering context, and hardware rendering context.

[0036] A multidimensional diagnostic report is a report used to describe the target rendering anomalies that have occurred in the target rendering transaction. Optionally, a multidimensional diagnostic report may include the anomaly type, occurrence time, associated transaction ID, diagnostic results for each dimension, and a snapshot of the original data.

[0037] Optionally, when the execution path of the target rendering transaction is determined to be abnormally terminated, a multi-dimensional rendering context dependency graph with the target rendering transaction as the root node is constructed. The multi-dimensional rendering context dependency graph includes application logic state, graphics resource holding relationship, system service interaction sequence and underlying hardware constraints. Through the state mutation points and causal link analysis of each node in the multi-dimensional rendering context dependency graph, the most likely set of root causes that led to the transaction failure is automatically inferred, and a multi-dimensional diagnostic report including root cause confidence, scope of impact and associated evidence chain is output.

[0038] Optionally, when a target rendering transaction fails, multi-source heterogeneous runtime status data of multiple target levels are collected simultaneously based on a preset rendering context dimension model; the multi-source heterogeneous runtime status data are then subjected to time-series alignment, semantic normalization, and abnormal pattern matching to generate a structured and traceable multi-dimensional diagnostic report.

[0039] Target rendering exceptions refer to graphics rendering exceptions identified as failures or unexpected behavior within the target rendering transaction. For example, target rendering exceptions may include at least one of the following: onDraw() is not called or is skipped; eglSwapBuffers() returns EGL_BAD_SURFACE, EGL_CONTEXT_LOST, or EGL_BAD_ALLOC; glGetError() returns a non-zero error code (such as GL_INVALID_FRAMEBUFFER_OPERATION); rendering frame timeout (failure to complete within 16ms, triggering frame dropping); Surface state changing from SURFACE_CREATED to SURFACE_DESTROYED; GPU driver reporting GPU Hang or Context Reset; framebuffer integrity verification failure (such as color / depth buffer not being bound); insufficient application memory causing textures to not be reloaded after release, etc.

[0040] For example, an interception layer can be built. When the interception layer detects that the target rendering transaction has not been completed successfully (such as onDraw not being triggered, swapBuffers returning EGL_BAD_SURFACE, GPU context being lost, or frame buffer verification failing), the system automatically triggers a multi-dimensional diagnostic engine. The multi-dimensional diagnostic engine collects runtime context data in parallel from multiple dimensions (such as application status, graphics API status, system service status, and system service status) associated with the target rendering transaction, thereby obtaining a multi-dimensional diagnostic report. The multi-dimensional diagnostic report can clearly indicate the context in which the anomaly occurred and the cause of the anomaly.

[0041] The designated receiver is the receiver used to receive and display the multidimensional diagnostic report. Optionally, the designated receiver can be an integrated development environment (IDE) plugin, an independent debugging application (APP), or a remote log service.

[0042] Optionally, the structured report generated by the multidimensional diagnostic engine (i.e., the multidimensional diagnostic report) is pushed to the developer's IDE plugin or standalone debugging app in real time via a WebSocket connection. By pushing the multidimensional diagnostic report to a designated receiver, which can then visualize the report, the anomaly information can be delivered instantly, allowing for a more accurate identification of the root cause of rendering anomalies.

[0043] Through the embodiments provided in this application, in response to the detection of a target call request from a specified application, the target rendering transaction corresponding to the target call request is tracked, so that each graphics rendering call has a traceable transaction identifier and execution context, thereby transforming the originally isolated and black-box rendering behavior into a recordable and associative complete execution chain; in the case of the target rendering transaction failing to execute, the multi-dimensional rendering context corresponding to the target rendering transaction is diagnosed, and by synchronously collecting multi-dimensional data, a structured diagnostic information strongly associated with the failed transaction is formed, resulting in a multi-dimensional diagnostic report, which establishes a direct mapping relationship between the abnormal phenomenon and the underlying cause; the multi-dimensional diagnostic report is pushed to the specified receiving end, so that the abnormal phenomenon changes from an unobservable state to an analyzable and locatable observable state, thereby more accurately locating the location of the rendering abnormality. Therefore, it can solve the technical problem in related technologies that the location of the abnormality cannot be located when an application rendering abnormality occurs.

[0044] In one exemplary embodiment, tracking a target rendering transaction corresponding to a target invocation request includes: performing an encapsulation operation on the target invocation request to form a target rendering transaction, wherein the encapsulation operation is used to add rendering transaction metadata to the target invocation request.

[0045] In this embodiment, the encapsulation operation refers to injecting relevant information into the target invocation request, thereby transforming the target invocation request into a target rendering transaction that is traceable, diagnosable, and interventionable. Specifically, the encapsulation operation can be used to add rendering transaction metadata to the target invocation request. Rendering transaction metadata refers to metadata related to the target rendering transaction corresponding to the target invocation request. Optionally, the rendering transaction metadata can be used to trace the multi-dimensional rendering context corresponding to the rendering transaction.

[0046] For example, rendering transaction metadata can be added to the target call request to form a target rendering transaction. In this way, by encapsulating and tagging the call information (i.e., the target call request), end-to-end rendering monitoring can be achieved without modifying the application's business logic and system source code.

[0047] Optionally, upon receiving a graphics rendering call request initiated by the application layer, the original target call request is reconstructed into a target rendering transaction with structured attributes by injecting semantic tags and runtime context metadata; or, each graphics rendering request is processed with state encoding, and the graphics rendering request is coupled and encapsulated with key state parameters in its execution context to generate a target rendering transaction carrying a timestamp, call path, resource identifier, and execution intent; the target rendering transaction serves as the sole carrier of the rendering transaction and is used to achieve end-to-end traceability and anomaly correlation in subsequent execution chains.

[0048] In this embodiment, by encapsulating the operation to add rendering transaction metadata to the target call request, the original stateless and unidentified target call request can be transformed into a structured transaction object with a unique identifier and rich context. This enables fine-grained recording of single rendering behavior that is traceable, identifiable, and associative, providing basic data units for subsequent diagnosis.

[0049] In one exemplary embodiment, performing an encapsulation operation on a target invocation request includes: encapsulating the target invocation request and attaching at least one of the following information to the target invocation request: transaction identifier, timestamp information, call stack information, hash value of the associated view component, and resource dependency list.

[0050] In this embodiment, the transaction identifier is an identifier used to uniquely identify the target call request; the timestamp information refers to the timestamp used to record the execution of the target rendering transaction; the call stack information refers to the reverse sequence of the program execution path, reflecting the complete context of the current function call, which can be used to locate the source of the exception; the hash value of the associated view component refers to the digest value generated by the hash algorithm for the view component attributes, used to achieve unique component identification without storing the complete object; the resource dependency list refers to the graphical resource items that a target rendering transaction depends on, used to analyze resource integrity and lifecycle matching.

[0051] Optionally, an interception layer is constructed to encapsulate each rendering request by attaching a unique ID (transaction identifier), timestamp, call stack, hash value of the associated view component, and resource dependency list to form a traceable "rendering transaction" (i.e., a traceable target rendering transaction).

[0052] This embodiment encapsulates the target call request and attaches at least one of the following: transaction identifier, timestamp information, call stack information, hash value of associated view component, and resource dependency list. This enables fine-grained data marking for each graphics rendering call, giving the originally atomic system call traceable and analyzable metadata attributes, thereby providing a structured data foundation for the independent location and restoration of rendering anomalies.

[0053] In an exemplary embodiment, diagnosing the multidimensional rendering context corresponding to the target rendering transaction to obtain a multidimensional diagnostic report includes: extracting features from each dimension of the multidimensional rendering context to obtain abnormal feature information, wherein the abnormal feature information is feature information that is extracted from at least one dimension of the multidimensional rendering context and is abnormal; identifying the target rendering anomaly based on the abnormal feature information, and generating a multidimensional diagnostic report according to a preset report structure, wherein the preset report structure includes at least one of the following: anomaly summary, rendering transaction identifier, anomaly component identifier, data snapshot, and repair suggestions.

[0054] In this embodiment, each rendering context in the multidimensional rendering context refers to the information of the runtime environment state of each dimension related to the target rendering transaction, collected from multiple dimensions. Optionally, each rendering context in the multidimensional rendering context includes multiple features. Feature extraction is performed on each rendering context in the multidimensional rendering context to obtain abnormal feature information. The abnormal feature information refers to feature information that is abnormal and extracted from at least one dimension of the multidimensional rendering context. For example, each rendering context in the multidimensional rendering context may include an application state context, a graphics API state context, a system service state context, and a hardware context.

[0055] Optionally, under the trigger condition of target rendering transaction failure, semantic-level state parsing is performed on each dimension of the multi-dimensional rendering context to extract feature patterns associated with abnormal system behavior. These feature patterns are high-order semantic identifiers of non-original state quantities that characterize the essence of rendering anomalies. Feature patterns may include, but are not limited to, state mutation sequences, resource holding conflicts, temporal dependency breaks, or environmental constraint violations, thereby forming abnormal feature information with diagnostic value. Alternatively, a normal behavior baseline model of the internal state space is constructed, and by comparing the deviation between the current state and the baseline model in real time, abnormal feature information with statistical significance or logical contradictions is identified. Abnormal feature information consists of state attributes that exhibit abnormal distribution within a single dimension or show inconsistent and uninterpretable relationships across multiple dimensions, used to support subsequent anomaly root cause inference.

[0056] Optionally, a rule engine or lightweight classification model can be used to match the extracted abnormal feature information with predefined abnormal type templates to identify the specific abnormal category and obtain the target rendering abnormality. For example, the target rendering abnormality could be "rendering interruption caused by Surface failure" or "drawing failure caused by GPU context loss". Alternatively, based on the semantic attributes and state association patterns carried by the abnormal feature information, a feature-root cause mapping match can be performed through a pre-built abnormal pattern knowledge base to identify the abnormal category to which the current target rendering abnormality belongs. The abnormal pattern knowledge base is formed by summarizing historical abnormal cases and contains statistical association rules and logical dependencies between feature combinations and fault types, thereby achieving systematic attribution from local features to global abnormal types.

[0057] A preset report structure refers to a predefined set of structured fields for standardizing diagnostic information output. It is used to uniformly organize and present descriptive content of anomalies. A preset report structure may include at least one of the following: anomaly summary, rendering transaction identifier, anomaly component identifier, data snapshot, and remediation suggestions.

[0058] Among them, the exception summary is a linguistic description of the exception, such as "An EGL_CONTEXT_LOST error was detected, accompanied by an abnormal increase in GPU temperature"; the rendering transaction identifier is a unique identifier assigned to the target rendering request; the exception component identifier is the identifier of the component that triggered the exception, such as the view component hash value (e.g., ViewHash: 0x1b4d2f) or shader program ID that triggered the exception; the data snapshot is a snapshot of the context data at the time the exception occurred, such as the call stack, resource list (e.g., texture ID, framebuffer ID), and the sequence of erroneous API calls (e.g., glBindFramebuffer → glDrawArrays → swapBuffers → EGL_ERROR); and the repair suggestion is a pre-defined suggestion mapped according to the exception type, such as "Rebuild EGLContext" or "Release non-critical texture caches".

[0059] In an optional embodiment, the interception layer detects that the Surface ID of the target rendering transaction changes from SurfaceID_887 to null in this frame, and SurfaceControl.getSurface() returns an empty object, indicating that the Surface is lost. The following abnormal features are extracted from the system service status dimension: surface_state=DESTROYED (Surface state feature); bufferqueue_depth=0 (buffer queue depth feature); sync_fence_signaled=false (synchronization fence not released feature); last_surface_change_reason = "Client called release()" (change reason from dumpsys); surface_owner_pid = 12345 (application PID). Combined with the application status dimension, it is found that the Surface is held by the video player component (VideoView), and the specified application recently called VideoView.stopPlayback(). Combined with the hardware dimension, it is found that the device is a low-memory model (available RAM < 100MB), indicating that the system actively destroyed the non-foreground Surface due to resource reclamation policies. The target rendering anomaly is identified as the Surface being reclaimed by the system during rendering (SurfaceHolder.surfaceCreated()). (Not called back), thus generating a multidimensional diagnostic report according to the preset report structure.

[0060] Optionally, based on a real-time feedback module, the structured report generated by the multi-dimensional diagnostic engine (i.e., the multi-dimensional diagnostic report) can be pushed in real-time to the developer's IDE plugin or standalone debugging app via a WebSocket connection. The multi-dimensional diagnostic report includes an error summary, the associated rendering transaction ID, the problematic component identifier, data snapshots (such as a list of resource IDs and a sequence of erroneous API calls), and preliminary repair suggestions. In this way, the real-time feedback and snapshot functionality enable developers and testers to quickly reproduce and resolve problems, significantly reducing the time and manpower costs of graphics compatibility debugging, accelerating product iteration, improving social and economic benefits, and greatly enhancing development and maintenance efficiency.

[0061] This embodiment extracts abnormal feature information from each dimension of the multidimensional rendering context to achieve root cause localization of rendering failures, rather than relying on fuzzy judgments based on a single error code. Based on a structured preset report template, a complete diagnostic report containing anomaly summary, transaction identifier, anomaly components, data snapshots, and repair suggestions is automatically generated, transforming the originally isolated and obscure system anomalies into understandable, traceable, and operable engineering information, significantly improving the accuracy and automation level of problem diagnosis.

[0062] In an exemplary embodiment, diagnosing the multidimensional rendering context corresponding to the target rendering transaction to obtain a multidimensional diagnostic report includes: diagnosing at least one of the following rendering contexts corresponding to the target rendering transaction to obtain a multidimensional diagnostic report: application state context, wherein the application state context is used to characterize the running state of a specified application; graphics API state context, wherein the graphics API state context is used to characterize the execution state of a graphics API; system service state context, wherein the system service state context is used to characterize the running state of a system rendering service; and hardware context, wherein the hardware context is used to characterize the running state of the device hardware of the electronic device running the specified application.

[0063] In this embodiment, the application state context refers to the set of running states of a specified application during the execution of the target rendering transaction. Optionally, the application state context can be used to determine whether the specified application itself has the conditions to initiate rendering normally. The graphics API state context refers to the set of execution state information returned by the graphics driver or verification layer when the specified application calls the graphics programming interface. Optionally, the graphics API state context can be used to determine whether the graphics instructions are correctly parsed and executed. The system service state context refers to the set of state information of the system services responsible for graphics compositing and management in the specified application. Optionally, the system service state context can be used to determine whether the rendering target is abnormally interrupted by the system layer. The hardware context refers to the set of running states of hardware resources directly related to graphics rendering in the electronic device running the specified application. Optionally, the hardware context can be used to determine whether the rendering failure is triggered by an underlying hardware anomaly.

[0064] This multi-dimensional real-time correlation diagnosis mechanism for rendering anomalies, by enhancing the interception layer to establish a holographic label for each rendering transaction and simultaneously collecting data from four dimensions—application status, graphics API status, system service status, and hardware context—for correlation analysis and root cause localization, constitutes a complete diagnostic chain from "phenomenon" to "root cause." This improves problem transparency and completely changes the "unknowable" state of rendering failure. Through multi-dimensional correlation diagnosis, abstract error codes can be transformed into technical reports with clear directional information, which is expected to shorten the problem localization time by more than 70%.

[0065] Optionally, semantic state profile parsing is performed on the application state context associated with the target rendering transaction to extract structural features reflecting the operational health of the application logic layer. These structural features may include, but are not limited to, the topological consistency of active components in the view tree, the temporal integrity of animation scheduling, the binding validity of resource lifecycles, and the blocking state of thread scheduling. This is used to determine whether there are logical anomalies or improper resource management in the application layer, thereby forming a basis for diagnosing the internal causes of rendering failure. Behavioral semantic modeling is performed on the graphics API state context triggered by the target rendering transaction to identify abnormal call patterns that violate the graphics pipeline contract. These abnormal call patterns may include, but are not limited to, illegal state machine transitions, object handle failure associations, resource binding conflicts, out-of-order synchronization primitives, or implicit shader compilation failures. This is used to construct a compliance assessment result for the API layer. Cross-layer dependency analysis is performed on the system service state context on which the target rendering transaction depends to extract system-level operational features related to service availability, resource allocation, and the health of the compositing queue. These system-level operational features may include, but are not limited to, the lifecycle validity of surface handles, the throughput blocking state of the buffer queue, the scheduling delay distribution of compositing tasks, and the response topology connectivity of service processes. This is used to determine whether the system service layer constitutes an external constraint for rendering anomalies. The hardware context of the target rendering studio's operating environment is sampled for environmental features and anomaly detection is performed. Hardware-level operating parameters related to graphics processing capabilities, thermodynamic constraints, and driver layer stability are extracted. These hardware-level operating parameters include, but are not limited to: uneven distribution of computing unit load, temperature threshold exceeding trend, abnormal clock frequency reduction behavior, and compatibility deviation between firmware version and rendering instruction set. This allows for the assessment of whether the hardware environment is a potential cause of rendering failure.

[0066] In one exemplary embodiment, the application state context includes at least one of the following: view tree structure, dirty region information, activity animation information, and process memory usage information; the graphics API state context includes at least one of the following: error stack information, verification layer messages, compilation log information, and buffer integrity information; the system service state context includes at least one of the following: display carrier validity information, buffer queue status information, and composition queue depth information; and the hardware context includes at least one of the following: graphics processor load information, graphics processor temperature information, and graphics processor driver version information.

[0067] Here, the view tree structure refers to all UI components (Views) being organized in a tree structure, with the root node being DecorView and the child nodes being layout containers and controls. Optionally, the view tree structure can be used to describe the hierarchy and rendering dependencies of the interface. For example, by traversing the currently active View hierarchy of a specified application, the type, hierarchy, visibility state, and layout parameters of each View can be obtained to determine whether there are invalid or abnormally nested view components, thereby eliminating rendering interruptions caused by layout logic errors.

[0068] Dirty region information refers to information in the system that identifies screen areas that need to be redrawn. Optionally, dirty region information can be triggered by invalidate(). For example, the coordinates and dimensions of areas marked as "need to be redrawn" in the Android View system can be collected, their distribution can be analyzed to see if it matches the expected rendering range, and abnormal scheduling behavior of the rendering engine caused by dirty region calculation errors or large areas of invalid dirty regions can be identified.

[0069] Activity animation information refers to the state information of currently running animation objects directly related to graphics rendering. Optionally, activity animation information may include animation type (such as Alpha, Translate, Scale, PropertyAnimator), the ID of the animation target View, current playback progress (0~1), duration, interpolator type, and whether it is in a paused / delayed state. For example, it can obtain the ID, target object, playback status, and remaining duration of currently running property animations, transition animations, or frame animations, and can determine whether there are abnormal animation references such as animation thread blocking or the target view being destroyed but still attempting to update.

[0070] Process memory usage information refers to the total amount of physical and virtual memory occupied by the current application process, as well as the memory distribution information of key sub-modules. Optionally, process memory usage information may include total RSS (Resident Set Size), Java heap memory, native heap memory, graphics memory (Gralloc / OpenGL texture cache), and allocatable memory limit (VmPeak / VmHWM). For example, reading the real-time heap memory and native memory usage of a specified application process can detect whether there are memory leaks or instantaneous memory spikes, in order to assess the possibility of graphics buffer allocation failure due to memory resource shortages.

[0071] Error stack information refers to the record of the error call chain returned by the system or driver layer when a graphics API call fails. For example, it can capture the error code stack returned after an OpenGL ES or Vulkan API call (such as the return sequence of glGetError()), record the call chain and context in which the error occurred, and be used to locate the specific illegal API call point (such as using a deleted texture ID).

[0072] Validation layer messages refer to debugging information automatically output by the Validation Layer in the graphical API. For example, in an environment where Vulkan Validation Layers are enabled, runtime log information output by the Validation Layer is collected, including non-compliant resource bindings, synchronization errors, state conflicts, etc., to identify potential programming defects that conform to the Vulkan specification.

[0073] Compilation log information refers to the log output information generated by the driver during the compilation or linking process of the GPU shader. Optionally, compilation log information may include syntax errors, resource index out of bounds, unsupported instructions, etc. For example, the log content generated by the GPU shader during the compilation or linking stage can be obtained to determine whether the rendering failure is due to shader code exceptions.

[0074] Buffer integrity information refers to information about whether the framebuffer or surface buffer is in a valid and usable state at the logical or physical level during graphics rendering. Optionally, buffer integrity information may include whether the framebuffer is complete (GL_FRAMEBUFFER_COMPLETE), whether the color / depth / stencil buffer is valid, whether the buffer is occupied by other processes, or whether it has been reclaimed by the system. For example, the OpenGL framebuffer status can be checked using glCheckFramebufferStatus(); the validity of the native buffer can be checked using SurfaceControl.getBuffer() or AHardwareBuffer_isValid().

[0075] Display carrier validity information refers to whether the "display carrier" (i.e., Surface) used to carry application graphics output in the system is still recognized as valid by the system. For example, the Surface name and status can be checked by using Surface.isValid() (Java layer), ANativeWindow_isValid() (Native layer), or by calling dumpsys SurfaceFlinger | grepSurfaceView.

[0076] Buffer queue status information refers to the runtime status of the underlying buffer queue (BufferQueue) that connects the application to the SurfaceFlinger. Optionally, buffer queue status information may include the number of buffers in the queue (producer / consumer count), whether it is blocked, whether it is overflowing, whether there are unconsumed buffers, and whether it is in an "Abandoned" state. For example, the current state of the BufferQueue (such as the number of available buffers, the number of dequeued buffers, and the queue blocking status) can be obtained to analyze whether there is buffer starvation or producer-consumer imbalance causing frame dropping or rendering blocking.

[0077] Compositing queue depth information refers to the number of tasks backlogged in SurfaceFlinger's internal compositing task queue before compositing Surfaces from multiple applications onto the screen. For example, reading the length of the layer queue to be composed in SurfaceFlinger can help assess whether the system's compositing engine is experiencing rendering delays or drops due to excessive backlog of layers, which could indirectly cause rendering timeouts on the application side.

[0078] Graphics processor load information refers to the current computing resource utilization of the graphics processor. For example, by obtaining the current utilization percentage of the GPU through the system performance monitoring interface, performance bottlenecks caused by GPU overload that prevent rendering instructions from being executed in a timely manner can be identified.

[0079] Graphics processor temperature information refers to the current physical operating temperature. For example, reading the real-time temperature value of the GPU module in the SoC can help determine whether overheating triggers a frequency reduction or rendering throttling mechanism, which in turn causes a decrease or interruption in rendering performance.

[0080] Graphics processor driver version information refers to the version number of the graphics processor. For example, the version number of the GPU driver currently loaded on the system can be obtained and compared with a database of known issues to identify whether there are system-level rendering anomalies caused by driver version defects (such as EGL context leakage on a specific model).

[0081] In an optional embodiment, when the interception layer detects a rendering failure signal (such as onDraw not being executed or swapBuffers returning an error), a multi-dimensional diagnostic engine is automatically triggered. The multi-dimensional diagnostic engine performs application status diagnosis, graphics API status diagnosis, system service status diagnosis, and hardware context diagnosis in parallel. Among them, application status diagnosis includes analyzing the current view tree structure, dirty regions, active animations, and process memory usage; graphics API status diagnosis includes capturing OpenGL error stacks, Vulkan verification layer messages, shader compilation logs, and frame buffer integrity; system service status diagnosis includes querying the Surface (display carrier) validity, BufferQueue status, and composition queue depth through internal interfaces such as SurfaceControl (or downgraded to analysis using the dumpsys SurfaceFlinger command); and hardware context diagnosis includes reading GPU load, temperature, and driver version information and matching it with a cloud-based known problem feature library.

[0082] After obtaining the application state context, graphics API state context, system service state context, and hardware context, abnormal feature information is extracted from at least one of these contexts. Cross-dimensional correlation analysis is then performed on the abnormal feature information to identify isolated anomalies, cascading anomalies, and contradictory state combinations. Based on a preset root cause weight model, the dominant root cause type and secondary influencing factors are inferred. According to the dominant root cause type, a multidimensional diagnostic report is generated according to a preset report structure. The multidimensional diagnostic report may include an anomaly summary, rendering transaction identifier, anomaly component identifier, data snapshot, and repair suggestions.

[0083] This embodiment achieves multi-dimensional parallel analysis of the causes of single rendering transaction failures by collecting and diagnosing four types of heterogeneous context data: application status, graphics API execution status, system service management status, and hardware operation status. This transforms previously isolated error phenomena into a set of causally related diagnostic information, significantly improving the accuracy and coverage of root cause localization for rendering anomalies. Furthermore, by collecting and correlating quantitative indicators from these four dimensions—application status, graphics API status, system service status, and hardware context—it enables precise capture and status characterization of multi-source heterogeneous data on graphics rendering anomalies. This provides quantifiable, traceable, and comparable underlying evidence for identifying anomaly causes, significantly improving the granularity and accuracy of rendering failure diagnosis.

[0084] In an exemplary embodiment, after diagnosing the multidimensional rendering context corresponding to the target rendering transaction, the method further includes: selecting a target exception recovery strategy from a preset strategy library that matches the exception type of the target rendering exception, based on the exception type of the target rendering exception, wherein the preset strategy library stores at least one exception recovery strategy, and one of the at least one exception recovery strategies corresponds to at least one exception type; and performing a recovery operation on the target rendering exception according to the target exception recovery strategy to recover the target rendering exception.

[0085] In related technologies, when the application layer receives a rendering failure signal, the usual approach is to wait for the next rendering cycle or cause the application to become unresponsive or even crash. This lack of effective intervention methods and self-healing capabilities severely damages user experience and application reliability. Therefore, to solve the above-mentioned technical problems, this embodiment provides an adaptive recovery strategy when a rendering anomaly is detected to prevent the application from crashing directly and to ensure basic user experience and program robustness. After identifying a specific rendering anomaly type, the system can automatically trigger a preset recovery action that precisely matches the type, thereby improving application reliability and user satisfaction.

[0086] In this embodiment, the preset strategy library refers to a strategy library that stores at least one exception recovery strategy. Optionally, the preset strategy library can store the mapping relationship between exception types and exception recovery strategies in key-value pairs. For example, "EGL_CONTEXT_LOST" is mapped to the strategy of "rebuild EGLContext and reload Shader resources", and "SURFACE_INVALIDATED" is mapped to the strategy of "call SurfaceHolder.recreate() and rebind BufferQueue".

[0087] An exception recovery strategy refers to a preset exception recovery strategy; a target exception recovery strategy refers to a recovery strategy selected from the preset strategy library that matches the exception type of the target rendering exception.

[0088] One of the at least one exception recovery strategies corresponds to at least one exception type. It can be understood that one exception recovery strategy corresponds to one exception type.

[0089] After selecting a target exception recovery strategy that matches the exception type of the target rendering exception, the target rendering exception is recovered by performing recovery operations according to the target exception recovery strategy.

[0090] In an optional embodiment, if the exception type of the target rendering error is GPU context loss and there is ghost data in the current frame buffer, the current rendering target is switched to the off-screen FBO for screen clearing and redrawing. At the same time, an asynchronous resource reconstruction thread is started to rebuild the EGLContext and texture resources in the background. After the reconstruction is completed and verified to be correct, the off-screen buffer content is replaced with the main FrameBuffer, and a forced redraw instruction is triggered to eliminate visual ghosting.

[0091] In this way, the above adaptive recovery mechanism can automatically execute repair strategies when most common rendering anomalies occur (such as temporary Surface failure), avoiding application crashes or prolonged black screens, reducing the crash rate caused by rendering problems by more than 50%, greatly improving application reliability and user satisfaction, and enhancing user experience and system robustness.

[0092] Through this embodiment, after identifying a specific type of rendering anomaly, the system can automatically trigger a preset recovery action that precisely matches the type, thereby directly intervening in the rendering pipeline state to eliminate known anomaly causes without interrupting the application process, and achieving automated repair of the target rendering anomaly.

[0093] In one exemplary embodiment, performing recovery operations on a target rendering exception according to a target exception recovery strategy includes: if the exception type of the target rendering exception is a display carrier exception, rebuilding the management interface of the display carrier; if the exception type of the target rendering exception is a graphics rendering context exception of the graphics processor, destroying and rebuilding the graphics rendering context and reloading the graphics processor resources; if the exception type of the target rendering exception is a memory resource exception, sending a cache release instruction to a specified application to release at least a portion of the graphics cache occupied by the specified application, or dynamically reducing the rendering resolution corresponding to the graphics rendering call request of the specified application.

[0094] In this embodiment, the display carrier refers to the underlying carrier used by the specified application to output images. Optionally, the display carrier includes SurfaceHolder (for the View system), Surface (for the native SurfaceView), or BufferQueue (for SurfaceFlinger composition).

[0095] Optionally, when the exception type of the target rendering error is determined to be a display carrier failure (such as the Surface being reclaimed by the system or the BufferQueue being in an error state), a valid graphics output channel is re-established by calling the reconstruction interface provided by the system (such as SurfaceHolder.recreate() or the SurfaceControl reconstruction command), restoring the communication link between the specified application and the system rendering service, so that subsequent rendering commands can be received and processed normally. For example, when the Surface() is diagnosed as missing, an attempt is made to rebuild the SurfaceHolder.

[0096] A graphics rendering context refers to the context in which graphics API calls are executed. Optionally, a graphics rendering context can refer to an execution environment created by EGL (the platform interface for OpenGL ES) or Vulkan, which encapsulates information such as GPU state, shader programs, and memory bindings.

[0097] For example, when a GPU context loss (EGL_CONTEXT_LOST) is diagnosed, the EGLContext can be safely destroyed and rebuilt, and the GPU resources can be reloaded.

[0098] The cache release instruction refers to the instruction to release at least a portion of the graphics cache occupied by the specified application. The graphics cache refers to the temporary storage area allocated by the application in memory or video memory for graphics data (such as textures, frame buffers, vertex buffers), which can be used to accelerate the rendering process. The rendering resolution refers to the pixel size of the image output by the application in each frame rendering (such as 1920×1080).

[0099] Optionally, when insufficient memory is diagnosed, the application is instructed to release non-critical graphics cache or dynamically reduce the rendering resolution.

[0100] For example, when high memory usage or allocation failure is detected (such as glAllocateStorage returning ENOMM), a cache release command can be sent to the application layer through a callback mechanism to trigger it to actively release non-critical caches (such as expired off-screen caches and low-priority textures); or the rendering target resolution can be dynamically modified (such as reducing it from 1080p to 720p) without interrupting the rendering process, in order to reduce the memory bandwidth and video memory capacity required per frame, thereby avoiding the risk of memory overflow and maintaining the continuity of the rendering process.

[0101] Optionally, an adaptive exception handler can be constructed. This handler has a built-in configurable pre-defined strategy library. Based on the diagnostic results (i.e., the exception type of the target rendering exception), it matches the target exception recovery strategy with the exception type of the target rendering exception and executes the recovery action. In this way, through a strategy-based adaptive exception recovery system based on diagnostic results—that is, a strategy library with multiple pre-defined recovery strategies (such as resource reconstruction, context reset, and rendering degradation)—and the ability to automatically match and execute the corresponding recovery strategy based on the exception type output by real-time diagnostics, the application possesses the ability to self-heal from specific rendering failures.

[0102] This embodiment implements structured recovery actions for rendering anomalies such as display carrier failure, loss of graphics context, and insufficient memory resources. This enables precise repair of key components of the graphics rendering pipeline without terminating the application process. This allows specified applications to restore their graphics output capabilities when encountering specific system-level anomalies, avoiding black screens or crashes, and improving the continuity and stability of operation in graphics anomaly scenarios.

[0103] In an exemplary embodiment, after performing a recovery operation on a target rendering exception according to a target exception recovery strategy, the method further includes: in response to the failure of target rendering exception recovery, performing a degradation operation on a specified application to display an error display interface on the specified application.

[0104] In this embodiment, the degradation operation refers to performing an operation on a specified application to replace the current rendering operation when the target rendering anomaly is identified. The error display interface refers to a preset interface that displays the abnormal state, used to inform the user that the current state is abnormal, which can avoid the experience disruption caused by black screen, no response, or crash.

[0105] Optionally, after executing the target anomaly recovery strategy (such as rebuilding the Surface, resetting the EGLContext, releasing the cache, etc.) matched and triggered by the multidimensional diagnostic engine, the recovery operation is confirmed by state detection to confirm that the graphics rendering function has not been successfully restored. For example, the rendering pipeline does not re-output a valid frame within a limited time, the Surface state is still invalid, or the GPU context still reports an error after reconstruction.

[0106] Performing a downgrade operation on a specified application means, after confirming that recovery has failed, actively terminating the current high-load or high-complexity graphics rendering process, shutting down non-core visual components (such as animations, effects, and high-definition textures), and switching to the preset lightweight rendering mode.

[0107] Optionally, displaying an error display interface on a specified application refers to the system loading and rendering a pre-designed static or low-resource-consumption interface in degraded mode. For example, the error display interface may contain concise text prompts (such as "Display error, attempting to recover"), basic icons, or placeholder images. The error display interface replaces the full application content that should have been rendered, thereby maintaining interface visibility and interactive feedback.

[0108] In an optional embodiment, Figure 3 This is a flowchart of an optional application rendering anomaly diagnosis method according to an embodiment of this application, such as... Figure 3 The diagram illustrates the entire decision-making and execution process from monitoring, diagnosis, feedback to recovery. For example, the workflow for applying diagnostic methods for rendering anomalies may include the following steps:

[0109] S1: System initialization, the interception layer begins monitoring.

[0110] S2: Intercepts the target rendering call request, encapsulates and traces it.

[0111] S3: Determine whether the rendering was successful / completed on time. If successful, the process ends; if it fails, proceed to S4.

[0112] S4: Triggers the multi-dimensional diagnostic engine to collect and correlate data.

[0113] S5: Generates multi-dimensional diagnostic reports and pushes them to the developer's end in real time.

[0114] S6: Match the target recovery strategy from the preset strategy library based on the diagnosed anomaly type.

[0115] S7: Execute the target recovery strategy and record the complete log of this event.

[0116] S8: Determine if the recovery was successful. If successful, the application continues to run; if core functions cannot be recovered, gracefully degrade to the error display screen to avoid a crash.

[0117] In another alternative embodiment, Figure 4 This is an optional system architecture block diagram according to an embodiment of this application, such as... Figure 4The diagram illustrates four core components: the interception layer, the diagnostic engine, the feedback module, and the exception handler, along with their connections to the host application and system services. A transparent, layered diagnostic and resilient recovery framework is constructed, deployed between the application and the system rendering service. This system primarily comprises an enhanced interception layer, a multi-dimensional diagnostic engine, a real-time feedback module, and an adaptive exception handler. The system is integrated into the target Android application via a lightweight SDK. The enhanced interception layer is coupled to the application's graphics API call chain (such as Choreographer callbacks, View.draw(), and GLES / Vulkan command streams) and the system rendering service. The input of the multi-dimensional diagnostic engine connects to the interception layer to obtain monitoring data, while its output connects to the real-time feedback module and the adaptive exception handler. The multi-dimensional diagnostic engine sends the exception type to the adaptive exception handler. Based on the exception type, the adaptive exception handler reads the corresponding recovery strategy from the strategy library and outputs control instructions to the application rendering pipeline according to the corresponding recovery strategy to execute the recovery strategy. At the application layer, the host Android application includes application business logic and graphics rendering pipeline. The enhanced interception layer detects the target call request of the specified application, forwards the call to the Android system rendering service (SurfaceFlinger / HWUI, etc.), and monitors the data flow of the multi-dimensional diagnostic engine. The multi-dimensional diagnostic engine queries the system status and sends the multi-dimensional diagnostic report to the real-time feedback module. The real-time feedback module connects with the developer debugging end (such as IDE plugins / standalone APP) via WebSocket / real-time connection.

[0118] In this embodiment, after the target anomaly recovery strategy fails, by performing a degradation operation and displaying an error display interface, the application can be prevented from being forcibly exited due to complete rendering failure, ensuring the continuous operation of the application process and providing clear visual feedback to the user, preventing unknown states such as black screen or no response, and maintaining basic user interaction perceptibility.

[0119] Through the above embodiments, a long-term quality monitoring system can be built. By collecting anonymous data online (with user authorization), an application rendering health dashboard can be established, and the rendering failure rate under different devices and system versions can be statistically analyzed. This provides data support for discovering common compatibility issues and driver defects, and empowers the continuous optimization of product quality.

[0120] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0122] According to another aspect of the embodiments of this application, a diagnostic apparatus for application rendering anomalies is also provided. This apparatus can be used to implement the diagnostic method for application rendering anomalies provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0123] Figure 5 This is a structural block diagram of an optional application rendering anomaly diagnostic device according to an embodiment of this application, such as... Figure 5 As shown, the diagnostic device for application rendering anomalies includes an interception layer 502, a multi-dimensional diagnostic engine 504, and a feedback module 506.

[0124] Interception layer 502 is used to track the target rendering transaction corresponding to the target call request in response to the detection of a target call request from a specified application. The target call request is a graphics rendering call request initiated by the specified application.

[0125] The 504 multi-dimensional diagnostic engine is used to diagnose the multi-dimensional rendering context corresponding to the target rendering transaction when the execution of the target rendering transaction is found to have failed.

[0126] Feedback module 506 is used to generate a multidimensional diagnostic report based on the diagnostic results of the multidimensional diagnostic engine and push the multidimensional diagnostic report to the designated receiving end. The multidimensional diagnostic report is used to describe the target rendering anomaly that has occurred in the target rendering transaction.

[0127] It should be noted that the interception layer 502 in this embodiment can be used to perform the above step S202, the multi-dimensional diagnostic engine 504 in this embodiment can be used to perform the above step S204, and the feedback module 506 in this embodiment can be used to perform the above step S206.

[0128] Through the embodiments provided in this application, in response to the detection of a target call request from a specified application, the target rendering transaction corresponding to the target call request is tracked, so that each graphics rendering call has a traceable transaction identifier and execution context, thereby transforming the originally isolated and black-box rendering behavior into a recordable and associative complete execution chain; in the case of the target rendering transaction failing to execute, the multi-dimensional rendering context corresponding to the target rendering transaction is diagnosed, and by synchronously collecting multi-dimensional data, a structured diagnostic information strongly associated with the failed transaction is formed, resulting in a multi-dimensional diagnostic report, which establishes a direct mapping relationship between the abnormal phenomenon and the underlying cause; the multi-dimensional diagnostic report is pushed to the specified receiving end, so that the abnormal phenomenon changes from an unobservable state to an analyzable and locatable observable state, thereby more accurately locating the location of the rendering abnormality. Therefore, it can solve the technical problem in related technologies that the location of the abnormality cannot be located when an application rendering abnormality occurs.

[0129] In one exemplary embodiment, the interception layer 502 is used to perform an encapsulation operation on the target invocation request to form a target rendering transaction, wherein the encapsulation operation is used to add rendering transaction metadata to the target invocation request.

[0130] In one exemplary embodiment, the interception layer 502 is used to encapsulate the target invocation request and attach at least one of the following information to the target invocation request: transaction identifier, timestamp information, call stack information, hash value of the associated view component, and resource dependency list.

[0131] In an exemplary embodiment, the feedback module 506 is configured to extract features from each dimension of the multidimensional rendering context to obtain abnormal feature information, wherein the abnormal feature information is feature information that is extracted from at least one dimension of the multidimensional rendering context and is abnormal; based on the abnormal feature information, the target rendering abnormality is identified, and a multidimensional diagnostic report is generated according to a preset report structure, wherein the preset report structure includes at least one of the following: abnormal summary, rendering transaction identifier, abnormal component identifier, data snapshot, and repair suggestion.

[0132] In an exemplary embodiment, the feedback module 506 is configured to diagnose at least one of the following rendering contexts corresponding to the target rendering transaction to obtain a multi-dimensional diagnostic report: application state context, wherein the application state context is used to characterize the running state of the specified application; graphics API state context, wherein the graphics API state context is used to characterize the execution state of the graphics API; system service state context, wherein the system service state context is used to characterize the running state of the system rendering service; and hardware context, wherein the hardware context is used to characterize the running state of the device hardware of the electronic device running the specified application.

[0133] In one exemplary embodiment, the application state context includes at least one of the following: view tree structure, dirty region information, activity animation information, and process memory usage information; the graphics API state context includes at least one of the following: error stack information, verification layer messages, compilation log information, and buffer integrity information; the system service state context includes at least one of the following: display carrier validity information, buffer queue status information, and composition queue depth information; and the hardware context includes at least one of the following: graphics processor load information, graphics processor temperature information, and graphics processor driver version information.

[0134] In an exemplary embodiment, the multi-dimensional diagnostic engine 504 is configured to, after diagnosing the multi-dimensional rendering context corresponding to the target rendering transaction, select a target exception recovery strategy from a preset strategy library that matches the exception type of the target rendering exception, wherein the preset strategy library stores at least one exception recovery strategy, and one of the at least one exception recovery strategies corresponds to at least one exception type; and perform a recovery operation on the target rendering exception according to the target exception recovery strategy to recover the target rendering exception.

[0135] In an exemplary embodiment, the multi-dimensional diagnostic engine 504 is configured to: rebuild the management interface of the display carrier when the exception type of the target rendering exception is a display carrier exception; destroy and rebuild the graphics rendering context and reload the graphics processor resources when the exception type of the target rendering exception is a graphics rendering context exception of the graphics processor; and send a cache release instruction to a specified application to release at least a portion of the graphics cache occupied by the specified application, or dynamically reduce the rendering resolution corresponding to the graphics rendering call request of the specified application when the exception type of the target rendering exception is a memory resource exception.

[0136] In one exemplary embodiment, the multi-dimensional diagnostic engine 504 is configured to perform a degradation operation on a specified application in response to a failure to recover from a target rendering exception after performing a recovery operation on the target rendering exception in accordance with the target exception recovery strategy, so as to display an error display interface on the specified application.

[0137] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0138] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0139] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0140] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0141] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0142] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0143] Figure 6 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 6As shown, the computer system 600 includes a Central Processing Unit (CPU) 601, which performs various appropriate actions and processes based on programs stored in ROM 602 or loaded into RAM 603 from storage section 608. Random access memory 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0144] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card or modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0145] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs various functions defined in the system of this application.

[0146] It should be noted that, Figure 6 The computer system 600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0147] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0148] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for diagnosing application rendering anomalies, characterized in that, include: In response to detecting a target invocation request from a specified application, the target rendering transaction corresponding to the target invocation request is tracked, wherein the target invocation request is a graphics rendering invocation request initiated by the specified application; If the execution of the target rendering transaction fails, the multidimensional rendering context corresponding to the target rendering transaction is diagnosed to obtain a multidimensional diagnostic report, wherein the multidimensional diagnostic report is used to describe the target rendering anomaly that occurred in the target rendering transaction. The multidimensional diagnostic report is pushed to the designated receiving end.

2. The method according to claim 1, characterized in that, The tracking of the target rendering transaction corresponding to the target invocation request includes: An encapsulation operation is performed on the target invocation request to form the target rendering transaction, wherein the encapsulation operation is used to add rendering transaction metadata to the target invocation request.

3. The method according to claim 2, characterized in that, The encapsulation operation performed on the target invocation request includes: The target call request is encapsulated and at least one of the following information is appended to it: transaction identifier, timestamp information, call stack information, hash value of the associated view component, and resource dependency list.

4. The method according to claim 1, characterized in that, The step of diagnosing the multidimensional rendering context corresponding to the target rendering transaction to obtain a multidimensional diagnostic report includes: Feature extraction is performed on each dimension of the multidimensional rendering context to obtain abnormal feature information, wherein the abnormal feature information is feature information that is extracted from at least one dimension of the multidimensional rendering context and is abnormal. Based on the abnormal feature information, the target rendering abnormality is identified, and the multidimensional diagnostic report is generated according to the preset report structure, wherein the preset report structure includes at least one of the following: abnormal summary, rendering transaction identifier, abnormal component identifier, data snapshot, and repair suggestion.

5. The method according to claim 1, characterized in that, The step of diagnosing the multidimensional rendering context corresponding to the target rendering transaction to obtain a multidimensional diagnostic report includes: A multi-dimensional diagnostic report is obtained by diagnosing the rendering context corresponding to at least one of the following: Application state context, wherein the application state context is used to characterize the running state of the specified application; A graphics API state context, wherein the graphics API state context is used to characterize the execution state of the graphics API; System service state context, wherein the system service state context is used to characterize the running state of the system rendering service; Hardware context, wherein the hardware context is used to characterize the operating state of the device hardware of the electronic device running the specified application.

6. The method according to claim 5, characterized in that, The application state context includes at least one of the following: view tree structure, dirty region information, activity animation information, and process memory usage information; The graphical API state context includes at least one of the following: error stack information, verification layer messages, compilation log information, and buffer integrity information; The system service status context includes at least one of the following: display carrier validity information, buffer queue status information, and synthesis queue depth information; The hardware context includes at least one of the following: graphics processor load information, graphics processor temperature information, and graphics processor driver version information.

7. The method according to any one of claims 1 to 6, characterized in that, After diagnosing the multidimensional rendering context corresponding to the target rendering transaction, the method further includes: Based on the exception type of the target rendering exception, a target exception recovery strategy matching the exception type of the target rendering exception is selected from the preset strategy library. The preset strategy library stores at least one exception recovery strategy, and one of the at least one exception recovery strategies corresponds to at least one exception type. According to the target anomaly recovery strategy, a recovery operation is performed on the target rendering anomaly to recover the target rendering anomaly.

8. The method according to claim 7, characterized in that, The step of performing recovery operations on the target rendering anomaly according to the target anomaly recovery strategy includes: If the error type of the target rendering error is a display carrier error, rebuild the management interface of the display carrier. If the exception type of the target rendering exception is a graphics rendering context exception of the graphics processor, destroy and rebuild the graphics rendering context, and reload the graphics processor resources. If the exception type of the target rendering exception is a memory resource exception, a cache release instruction is sent to the specified application to release at least a portion of the graphics cache occupied by the specified application, or the rendering resolution corresponding to the graphics rendering call request of the specified application is dynamically reduced.

9. The method according to claim 7, characterized in that, After performing recovery operations on the target rendering anomaly according to the target anomaly recovery strategy, the method further includes: In response to the failure to recover from the target rendering error, a degradation operation is performed on the specified application to display an error display interface on the specified application.

10. A diagnostic device for application rendering anomalies, characterized in that, include: An interception layer is used to track the target rendering transaction corresponding to the target call request in response to the detection of a target call request from a specified application, wherein the target call request is a graphics rendering call request initiated by the specified application. A multi-dimensional diagnostic engine is used to diagnose the multi-dimensional rendering context corresponding to the target rendering transaction when the execution of the target rendering transaction is found to have failed. The feedback module is used to generate a multidimensional diagnostic report based on the diagnostic results of the multidimensional diagnostic engine, and push the multidimensional diagnostic report to a designated receiving end. The multidimensional diagnostic report is used to describe the diagnosed target rendering anomaly that occurred in the target rendering transaction.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 9.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

Images