A method and electronic device for detecting white screen on Quick App cards

Abstract

This application provides a method and electronic device for detecting blank screens of Quick App cards. The method relates to the field of terminal technology. The method includes: for a Quick App card, determining whether there are any abnormal control states in the multiple layers of parent and child controls of the corresponding card view control; if abnormal control states are found, the Quick App card can be determined to be blank. This method facilitates the electronic device in promptly determining whether the JS card is displaying its content correctly, and also provides data support for the subsequent timely resolution of blank screen issues, effectively improving the user's terminal experience.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a white screen detection method and electronic device for Quick App cards. Background Technology

[0002] Quick App cards are components or features used within the Quick App ecosystem. Developed using a JS engine (also known as JS cards), they are embedded as plugins into various host applications (desktop, negative one screen, Quick Service Center, etc.). JS cards are issued in two ways: users add cards to host applications through the Quick Service Center, and operations teams proactively push cards to host applications, issuing them through the application's operational placement. Besides providing a good user experience, JS cards can also generate significant commercial revenue.

[0003] However, the loading process for JS cards is lengthy, and any abnormality at any stage can lead to a blank screen issue. Therefore, there is an urgent need for a blank screen detection method for Quick App cards, so that electronic devices can promptly determine whether the JS card is displaying its content correctly. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method and electronic device for detecting blank screens on Quick App cards. In this method, the electronic device can determine if a card is blank by verifying the control states of multiple layers of parent and child controls within the card view control. This provides data support for subsequent solutions to blank screen issues on the card, improving the user's terminal experience.

[0005] In a first aspect, this application provides a white screen detection method for Quick App cards. The method includes: for a Quick App card, determining whether there are any abnormal control states in the multi-level parent controls and multi-level child controls of the corresponding card view control; if there are abnormal control states, determining that the Quick App card is a white screen.

[0006] In this embodiment, the electronic device verifies the control states of the multi-layered parent and child controls of the card view control to determine whether there are controls with abnormal control states among the parent and child controls of the card view control. When there are controls with abnormal control states, it can be determined that the card is blank, which makes it easier for the electronic device to determine whether the JS card is displaying the card content normally in a timely manner. It also provides data support for the electronic device to solve the card blank screen problem in a timely manner, thereby improving the user's terminal experience.

[0007] According to the first aspect, for the Quick App card, determining whether there are any abnormal control states in the multi-layer parent and child controls of the corresponding card view control includes: traversing and verifying the Kth layer parent control of the card view control to determine whether there are any abnormal control states in the Kth layer parent control; the value of K is the first verification loop count plus one; the initial value of the first verification loop count is 0; if there is an abnormal control state in the Kth layer parent control, the Quick App card is determined to be a blank screen; if there is no abnormal control state in the Kth layer parent control, the first verification loop count is incremented by one; it is determined whether the first verification loop count is less than a first threshold; if the first verification loop count is less than the first threshold, the step of traversing and verifying the Kth layer parent control of the card view control to determine whether there are any abnormal control states in the Kth layer parent control is returned.

[0008] In this embodiment, the electronic device verifies the control state of the multi-layer parent controls of the card view control to determine whether there are controls with abnormal control states in the parent controls of the card view control. When there are controls with abnormal control states, it can be determined that the card is a blank screen, thereby improving the efficiency of blank screen detection for quick app cards, providing data support for subsequent electronic devices to solve card blank screen issues, and improving the user's terminal experience.

[0009] According to the first aspect, or any implementation of the first aspect above, the method further includes: when the first verification loop count is equal to or greater than the first threshold, traversing the Mth layer of sub-controls of the verification card view control to determine whether there is a control state abnormality in the Mth layer of sub-controls; the value of M is the second verification loop count plus one; the initial value of the second verification loop count is 0; when there is no control state abnormality in the Mth layer of sub-controls, incrementing the second verification loop count by one; determining whether the second verification loop count is less than the second threshold; when the second verification loop count is less than the second threshold, returning to the step of traversing the Mth layer of sub-controls of the verification card view control to determine whether there is a control state abnormality in the Mth layer of sub-controls; when the second verification loop count is greater than or equal to the second threshold, determining that there is no control state abnormality in the control.

[0010] In this embodiment, when there are no abnormal control states in the multi-layer parent controls of the card view control, the electronic device verifies the control states of the multi-layer child controls of the card view control to determine whether there are controls with abnormal control states in the child controls of the card view control. When there are controls with abnormal control states, it can be determined that the card is a blank screen, thereby improving the accuracy of blank screen detection for quick app cards, providing data support for subsequent electronic devices to solve the blank screen problem of cards, and improving the user's terminal experience.

[0011] According to the first aspect, or any implementation of the first aspect above, the process of traversing and verifying the Kth-level parent controls of the card view control to determine whether there is an abnormal control state of the parent control in the Kth-level parent control includes: traversing and verifying the Kth-level parent controls of the card view control, and for each parent control in the Kth-level parent control, determining whether the attribute value of the parent control is null; if the attribute value of the parent control is null, determining that there is an abnormal control state of the parent control; if the attribute value of the parent control is not null, determining whether the parent control is visible; if the parent control is invisible, determining that there is an abnormal control state of the parent control; if the parent control is visible, determining whether the parent control is transparent; if the parent control is transparent, determining that there is an abnormal control state of the parent control; and if the parent control is not transparent, determining that the control state of the parent control is normal.

[0012] In this embodiment, the abnormal state of the parent control includes three situations: (1) the attribute value of the parent control is null; (2) the parent control is invisible; (3) the parent control is transparent. If the parent control's state exhibits any of the above situations, it can be determined that the parent control's state is abnormal.

[0013] According to the first aspect, or any implementation of the first aspect above, the process of traversing and verifying the M-th layer of sub-controls of the card view control to determine whether there is a sub-control with an abnormal control state includes: traversing and verifying the M-th layer of sub-controls of the card view control; for each sub-control in the M-th layer, determining whether the sub-control has a zero value; if the number of sub-controls is zero, determining whether there is a sub-control with an abnormal control state; if the number of sub-controls is not zero, determining whether the sub-control is visible; if the sub-control is invisible, determining whether there is a sub-control with an abnormal control state; if the sub-control is visible, determining whether the sub-control is transparent; if the sub-control is transparent, determining whether there is a sub-control with an abnormal control state; and if the sub-control is not transparent, determining that the sub-control has a normal control state.

[0014] In this embodiment, the abnormal control state of a child control includes three situations: (1) the number of child controls is 0; (2) the child control is invisible; (3) the child control is transparent. If any of the above situations occur in the control state of a child control, it can be determined that the control state of the child control is abnormal.

[0015] According to the first aspect, or any implementation of the first aspect above, the method further includes: when there is no abnormality in the control state of the control, obtaining a card view from the display interface; drawing the card view onto a specified bitmap; randomly selecting multiple pixels from the specified bitmap, and calculating the proportion of each color value based on the color value of the pixel; determining whether the largest proportion is less than a third threshold; if the largest proportion is less than the third threshold, determining that the quick app card is displayed normally; if the largest proportion is greater than or equal to the third threshold, determining that the quick app card is a white screen.

[0016] In this application embodiment, another white screen detection method for Quick App cards is also provided as a supplement to the first aspect. In this method, the electronic device draws the card view onto a specified bitmap, and then randomly selects multiple pixels from the specified bitmap. Based on the color value of the pixel, the proportion of each color value is counted. If the maximum proportion is greater than or equal to a third threshold, the card can be determined to be a white screen, thereby improving the white screen detection efficiency and accuracy for Quick App cards, providing data support for subsequent electronic devices to solve card white screen problems, and improving the user's terminal experience.

[0017] According to the first aspect, or any implementation of the first aspect above, the method further includes: the quick app engine receiving a card display notification sent by the host application and recording the receiving time; the quick app engine executing the method as described in any of the above aspects when the interval between the receiving time and the receiving time is preset.

[0018] In this embodiment, there are multiple ways to load quick app cards. The display state and timing of quick app cards differ depending on the loading method. Therefore, a unified white screen detection timing is needed for different loading methods to ensure the effectiveness of white screen detection. This embodiment comprehensively considers two loading methods for quick app cards (non-pre-rendered loading and pre-rendered loading), thus determining that the electronic device can execute the white screen detection method after a preset delay following the host app card being displayed (reflected in the moment the processing module receives the card display notification). This allows the white screen detection method to cover multiple card loading scenarios, improving its usability.

[0019] According to the first aspect, or any implementation of the first aspect above, the host application includes at least: the negative one screen, the desktop, and the quick app center.

[0020] In a second aspect, this application provides an electronic device comprising: one or more processors; a memory; and a computer program, wherein the computer program is stored in the memory and, when executed by one or more processors, causes the electronic device to perform instructions of the method in the first aspect or any possible implementation thereof.

[0021] The second aspect and any implementation thereof correspond to the first aspect and any implementation thereof, respectively. The technical effects of the second aspect and any implementation thereof are similar to those of the first aspect and any implementation thereof, and will not be repeated here.

[0022] Thirdly, this application provides a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method of the first aspect or any possible implementation thereof.

[0023] The third aspect and any implementation thereof correspond to the first aspect and any implementation thereof, respectively. The technical effects of the third aspect and any implementation thereof are similar to those of the first aspect and any implementation thereof, and will not be repeated here. Attached Figure Description

[0024] Figure 1 A schematic diagram illustrating a card loading process provided in an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0026] Figure 3 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0027] Figure 4 A flowchart illustrating a white screen detection method for Quick App cards provided in an embodiment of this application;

[0028] Figure 5 A schematic diagram of a quick app card rendering hierarchy provided in an embodiment of this application;

[0029] Figure 6 A flowchart illustrating another white screen detection method for Quick App cards provided in this application embodiment;

[0030] Figure 7 A schematic diagram of the interface for loading quick app cards provided in this application embodiment;

[0031] Figure 8 A flowchart illustrating a white screen detection method for a non-pre-rendered card loading scenario provided in an embodiment of this application;

[0032] Figure 9This is a flowchart illustrating a white screen detection method for a pre-rendered card loading scene provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0035] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0036] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0038] Quick App cards are components or features used within the Quick App ecosystem. Developed using a JS engine (also known as JS cards), they are embedded as plugins into various host applications (desktop, negative one screen, Quick Service Center, etc.). JS cards are issued in two ways: users add cards to host applications through the Quick Service Center, and operations teams proactively push cards to host applications, issuing them through the application's operational placement. Besides providing a good user experience, JS cards can also generate significant commercial revenue.

[0039] However, the loading process for JS cards is lengthy, and any abnormality at any stage can lead to a blank screen issue. Therefore, there is an urgent need for a blank screen detection method for Quick App cards, so that electronic devices can promptly determine whether the JS card is displaying its content correctly.

[0040] Figure 1 This is a schematic diagram illustrating a card loading process provided in an embodiment of this application. Before introducing the embodiments of this application, firstly based on... Figure 1 The application scenarios of the embodiments of this application will be described. For example... Figure 1 As shown, the card loading process includes the following steps S10-S28.

[0041] Step S10: The host application creates a card container.

[0042] The host applications include, but are not limited to, the desktop, the negative one screen, and the quick service center.

[0043] In some embodiments, the host application may create a card container for the corresponding card in response to a user's card-adding operation. This card-adding operation could be, for example, a user adding a card to the host application via the Quick Service Center.

[0044] In other embodiments, the host application may create a card container corresponding to the push card instruction. This push card instruction could be, for example, a social application's push instruction for trending news.

[0045] Step S11: The host application sends a card view control creation request to the processing module in the Quick App Engine.

[0046] The processing modules in the Quick App Engine include, for example, the Card SDK. The Card View Control Creation Request is used to request the Card SDK to create a CardView control for the card.

[0047] Step S12: After creating the card view control, the processing module returns a message to the host application indicating that the card view control has been successfully created.

[0048] Step S13: After creating the card view control, the processing module obtains the card application resources of the card.

[0049] Among them, card application resources include at least card definition, style, logic and other information.

[0050] In some embodiments, the processing module obtains the card application resources of a card by: determining whether the card application resources are stored locally; if the card application resources are stored locally, retrieving the card application resources from the local storage; and if the card application resources are not stored locally, downloading and storing the card application resources from the Quick App Cloud.

[0051] Step S14: After creating the card view control, the processing module sends a communication channel establishment request to the communication service module.

[0052] Understandably, when communication is implemented based on the V8 engine (such as Google's JavaScript engine), this communication service module can also be called a V8 service module. The communication channel establishment request is used to request the establishment of communication between the processing module and the Quick App card side.

[0053] Step S15: The communication service module responds to the communication channel establishment request and establishes communication between the JS card module and the processing module.

[0054] The communication between the JS card module and the processing module is, for example, JSBridge communication.

[0055] Step S16: When the communication between the JS card module and the processing module is established, the JS card module returns a successful communication service binding response to the communication service module.

[0056] The successful communication service binding response is used to notify that communication between the JS card module and the processing module has been established.

[0057] Step S17: The communication service module returns a successful communication service binding response to the processing module.

[0058] Step S18: The processing module parses the card application resources.

[0059] The card application resources may be a file in formats such as JSON, XML, or YAML, or a compressed package containing all the resources required for the card. The processing module parses the card application resources to extract information such as the card's structure, style, and event handling, which is then used for subsequent rendering and interaction.

[0060] Step S19: The processing module creates the root view of the card view control based on the card application resource parsing results.

[0061] The root view (DecorLayout) of the CardView control defines the basic structure and style of the card, such as background, margins, and borders. This root view includes other subviews and controls of the card.

[0062] Step S20: The processing module creates a page based on the card application resource parsing results.

[0063] A page is a logical unit of card content, which can contain multiple view controls, interaction logic, and state management. A page typically has a main body, which contains the page's main content, such as text, images, buttons, and other controls. After obtaining the page definition, the processing module creates the page body based on the page information and adds it to the page's structure.

[0064] Step S21: After the page is created, the processing module sends a notification that the page initialization is complete.

[0065] Step S22: After the page is created, the processing module sends a view on-screen notification to the host application.

[0066] Step S23: The host application responds to the on-screen notification and controls the display of the card.

[0067] It is understandable that steps S22 and S23 can be executed before or simultaneously with page rendering. In this case, when the host application controls the display of the card, it can first display a placeholder image or skeleton image of the card (without specific content), and then display the specific content after the card page is fully rendered. Alternatively, steps S22 and S23 can be executed after page rendering is complete. In this case, when the host application controls the display of the card, it can directly display the rendered card.

[0068] Step S24: In response to the page initialization completion notification, the communication service module sends a page content rendering notification to the JS card module.

[0069] Step S25: The JS card module responds to the page content rendering notification by sending a page rendering event to the communication service module.

[0070] The page rendering event is used to instruct the processing module to perform rendering actions.

[0071] Step S26: The communication service module sends the page rendering event to the processing module.

[0072] Step S27: The processing module responds to the page rendering event and renders the card content.

[0073] Step S28: The processing module sends a rendering completion message to the host application so that the host application can control the display of the card.

[0074] Steps S10-S28 above illustrate the loading process of a Quick App card in an electronic device. During this loading process, if any step is abnormal, the Quick App card will ultimately appear as a blank screen, meaning it will be a white or transparent card. Abnormalities during the card loading process include the following situations: Situation 1 to Situation 6.

[0075] Scenario 1: In step S10, the host application fails to create the card container.

[0076] Scenario 2: In step S10, when the host application creates a card, it sets the container exception to invisible or transparent.

[0077] Case 3: In steps S12-S13, the processing module abnormally sets the card view control to invisible or transparent when creating the card view control.

[0078] Case 4: In step S19, the processing module fails to create the root view.

[0079] Case 5: In step S20, the processing module fails to create the page or the page body.

[0080] Case 6: Communication connection between the JS card module and the processing module is abnormal.

[0081] Regarding scenario six, it is understandable that when the communication connection between the JS card module and the processing module is abnormal, the JS card module and the processing module cannot interact, which will lead to abnormal rendering of card content.

[0082] Situations one through five above can be categorized as container exceptions, while situation six can be categorized as rendering exceptions. Due to these two types of exceptions, a white screen may appear after the Quick App card loads. To ensure a good user experience, electronic devices need to promptly determine if a white screen issue has occurred after the Quick App card loads, so that problems can be resolved in a timely manner.

[0083] Therefore, this application provides a white screen detection method for Quick App cards, which traverses the page hierarchy and detects the control status of each level to accurately determine whether a Quick App card is white screened, facilitating timely handling of white screen issues by electronic devices and improving the user's terminal experience.

[0084] The white screen detection method for Quick App cards provided in this application can be applied to electronic devices, such as wearable electronic devices (e.g., watches), portable computers (e.g., mobile phones), tablets, laptops, personal computers (PCs), augmented reality (AR) / virtual reality (VR) devices, in-vehicle computers, etc. The following embodiments do not impose any special restrictions on the specific form of the electronic device.

[0085] Before describing the technical solutions of the embodiments of this application, the electronic devices of the embodiments of this application will first be described in conjunction with the accompanying drawings. Figure 2 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. It should be understood that... Figure 2 The electronic device 100 shown is merely an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 2 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0086] Electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0087] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0088] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0089] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory.

[0090] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0091] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0092] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0093] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0094] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc.

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

[0096] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0097] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0098] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0099] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0100] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0101] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0102] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0103] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0104] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0105] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0106] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0107] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0108] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can be corresponding to touch operations applied to different applications (such as taking photos, playing audio, etc.). Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, or to indicate messages, missed calls, notifications, etc.

[0109] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0110] Figure 3 This is a software structure block diagram of an electronic device 100 provided in an embodiment of this application.

[0111] The layered architecture of the electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0112] The application layer can include a series of application packages.

[0113] like Figure 3 As shown, the application package can include applications such as camera, gallery, calendar, call, map, navigation, desktop, negative one screen, quick service center, quick app cards, etc.

[0114] In this embodiment, the desktop, the negative one screen, and the quick service center can all serve as the host application for the quick app card.

[0115] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0116] like Figure 3 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, quick app engine, etc.

[0117] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0118] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0119] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0120] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0121] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0122] The Quick App Engine includes a processing module and a communication service module.

[0123] Among them, the processing modules in the Quick App Engine include, for example, the Card SDK in the Quick App Engine. The Card SDK can perform the following functions: (1) obtain the required card and business data from the server so that it can be displayed and processed on the front end; (2) access common JSAPIs and third-party controls: the Card SDK is responsible for handling the access of these APIs and controls, so that the card can more easily integrate these external resources; (3) render the card.

[0124] The communication service module in the Quick App engine can also be called the V8 service module. The communication channel establishment request is used to request communication between the processing module and the Quick App card side.

[0125] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0126] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0127] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0128] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0129] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0130] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0131] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0132] A 2D graphics engine is a graphics engine for 2D drawing.

[0133] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0134] Understandable Figure 3 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer layers than illustrated, and each layer may include more or fewer components; this application does not impose any limitations.

[0135] Based on the software structure of the electronic device shown above, this application provides a white screen detection method for Quick App cards. Figure 4 This is a flowchart illustrating a white screen detection method for Quick App cards provided in an embodiment of this application. This white screen detection method for Quick App cards is applied to electronic devices, specifically to the processing module within a Quick App engine. Figure 4 As shown, the white screen detection method for quick app cards includes steps S401-S408.

[0136] Step S401: Traverse and verify the Kth-level parent control of the card view control to determine whether there is an abnormal control state of the parent control in the Kth-level parent control.

[0137] Where K is the first validation loop count + 1. The first validation loop count refers to the number of times the parent controls of the card view control have been traversed and validated. The initial first validation loop count is 0, and the first validation loop count is incremented by one after each layer of parent controls has been validated.

[0138] As can be seen from the aforementioned abnormal situations during the card loading process (situations one through six), at different rendering nodes, if page control elements cannot be added normally or are set to invisible or transparent, the card will appear as a white screen. Therefore, in this white screen detection method for Quick App cards, based on the card's rendering layer, the control status of each layer is checked to determine whether the card is a white screen (whether a white card or a transparent card appears). A white screen card means that the card's interface elements are displayed blankly, without displaying any content or information.

[0139] Figure 5 This diagram illustrates a rendering hierarchy for a quick app card, as provided in an embodiment of this application. The cards are rendered hierarchically from the outside in, as shown below. Figure 5 As shown, the host application first creates a card container for the card. Next, the processing module creates a card view control (CardView) and, by parsing the card application resources, creates the root view (DecorLayout) of the card view control. After obtaining the page from the card application resources, it creates the page body, which is, for example, a scrollable Scroller container. This page body contains multiple pieces of content, and when the processing module receives a rendering event from the Quick App card side, it renders this content. As can be seen from the diagram of this card rendering hierarchy, CardView is the outermost view that the processing module (Quick App engine side) can control. However, in real-world scenarios, both the parent and child controls of CardView may experience abnormal control states. Therefore, it is necessary to validate both the parent and child controls of CardView to determine whether the card is displayed as a blank screen.

[0140] In one example provided in this application embodiment, the first parent control of CardView includes, for example, FrameLayout (a single-frame layout control), the second parent control includes, for example, AppCardRoundView (an application card rounded corner view control), and the third parent control includes, for example, LinearLayout (a linear arrangement control). It is understood that each parent control of CardView can also be other controls, which will not be specifically described in this application embodiment.

[0141] In this embodiment of the application, the step of traversing the Kth layer parent control of the card view control and determining whether there is an abnormal control state of the parent control in the Kth layer parent control (step S401 above) includes: steps one to seven below.

[0142] Step 1: Iterate through and validate the Kth level parent controls of the card view control. For each parent control in the Kth level parent control, determine whether the property value of that parent control is null.

[0143] Step 2: If any parent control's property value is null, determine if there is an abnormal state of the parent control.

[0144] If the parent control's property value is empty, it means that the control is not mounted, which will cause the card to be displayed as a blank screen.

[0145] Step 3: If the parent control's property value is not empty, determine whether the parent control is visible.

[0146] "Visible" refers to the control being set to a visible state.

[0147] Step 4: If any parent control is not visible, determine if the control with a parent control has an abnormal state.

[0148] Step 5: If the parent control is visible, determine whether the parent control is transparent.

[0149] Transparency refers to the control being set to a transparent state, such as 100% transparency.

[0150] Step 6: When any parent control is transparent, determine if there is a parent control whose state is abnormal.

[0151] Step 7: When the parent control is opaque, the state of the determined control is not abnormal.

[0152] By using steps one through seven above, the electronic device can effectively determine whether there is any abnormality in the control state of the parent control.

[0153] In this embodiment of the application, if there is an abnormal control state of the parent control in the Kth layer parent control, the following step S402 is executed.

[0154] Step S402: Determine that the card is a blank screen.

[0155] In this context, a blank screen for a card means that the interface elements of the card are displayed as blank, without any content or information.

[0156] Step S403: If the control state is abnormal and there is no parent control in the Kth layer parent control, increment the first verification loop count by one.

[0157] Step S404: Determine whether the number of the first verification loop is less than the first threshold.

[0158] The first threshold can be set according to the actual application, such as 3, 4 or 5.

[0159] Understandably, the more verification loops, the higher the accuracy of white screen detection, but the greater the device power consumption. Therefore, the most suitable first threshold can be selected by comprehensively considering both the accuracy of white screen detection and device power consumption. For example, the preferred first threshold is 3.

[0160] In this embodiment of the application, if the number of the first verification loop for the parent control is less than the first threshold, the process returns to the aforementioned step S401.

[0161] If the number of validation loops for the parent control is less than the first threshold, it means that the number of validation loops has not yet been reached. Therefore, the validation is performed on the parent control one level above.

[0162] Step S405: If the number of the first verification loop for the parent control is equal to or greater than the first threshold, traverse the Mth layer child controls of the verification card view control to determine whether there are any child controls with abnormal control states in the Mth layer child controls.

[0163] Where M is the second validation loop count + 1. The initial second validation loop count is 0, and the second validation loop count is incremented by one after each layer of sub-controls is validated.

[0164] In this embodiment of the application, the step of traversing the Mth layer of sub-controls of the card view control and determining whether there are any sub-controls with abnormal control states in the Mth layer of sub-controls (step S405 above) includes: steps one to seven below.

[0165] Step 1: Iterate through the M-th layer of child controls in the card view control, identify each child control in the M-th layer, and determine whether the number (ChildCount) of that child control is 0.

[0166] Step 2: If the number of any child controls is 0, determine if the control with child controls is in an abnormal state.

[0167] If the number of child controls is 0, it means that the control does not exist, which will cause the card to be displayed as a blank screen.

[0168] Step 3: If the number of child controls is not 0, determine whether the child controls are visible.

[0169] Step 4: If any child control is not visible, determine if the control with child controls is in an abnormal state.

[0170] Step 5: With the child control visible, determine whether the child control is transparent.

[0171] Step 6: When any child control is transparent, determine if there is a control with an abnormal state among the child controls.

[0172] Step 7: When the child control is opaque, the state of the determined control is not abnormal.

[0173] By using steps one through seven above, the electronic device can effectively determine whether there are any abnormalities in the control state of the sub-controls.

[0174] In this embodiment of the application, if there is an abnormal control state of a sub-control in the M-th layer, the above step S402 is executed to determine that the card is a blank screen.

[0175] In one example provided in this application embodiment, the first layer of child controls of CardView includes, for example, the root view (DecorLayout) of the card view control, the second layer of parent control includes, for example, the page body (Body), and the third layer of parent control includes, for example, the content (element) in the page body. It is understood that each layer of child controls of CardView can also be other controls, which will not be specifically described in this application embodiment.

[0176] Step S406: If the control state is abnormal and there is no sub-control in the M-level sub-control, increment the second verification loop count by one.

[0177] Step S407: Determine whether the number of the second verification loop is less than the second threshold.

[0178] The second threshold can be set according to the actual application, such as 3, 4 or 5.

[0179] Understandably, the more verification loops, the higher the accuracy of white screen detection, but the greater the device power consumption. Therefore, the most suitable second threshold can be selected by comprehensively considering both the accuracy of white screen detection and device power consumption. For example, the preferred second threshold is 3.

[0180] If the number of validation loops for the child control is less than the second threshold, return to the aforementioned step S405.

[0181] Step S408: If the number of validation loops for the sub-control is equal to or greater than the second threshold, determine that the card is displayed normally.

[0182] This application provides a white screen detection method for Quick App cards. In this method, the electronic device verifies the control states of multiple parent and child controls of the card view control to determine whether there are controls with abnormal control states among the parent and child controls of the card view control. When there are controls with abnormal control states, the card can be determined to be a white screen, thereby improving the white screen detection efficiency for Quick App cards, providing data support for subsequent electronic devices to solve card white screen problems, and improving the user's terminal experience.

[0183] The above Figure 4 The provided white screen detection method for Quick App cards is a page-level detection method. This application also provides another white screen detection method for Quick App cards, which is a pixel sampling detection method. Figure 6 This is a flowchart illustrating another white screen detection method for quick app cards provided in an embodiment of this application. This alternative white screen detection method for quick app cards is applied to the processing module. For example... Figure 6 As shown, another white screen detection method for quick app cards includes: steps S601-S606.

[0184] Step S601: Obtain the card view from the display interface.

[0185] Here, card view refers to the image information contained in the card.

[0186] Step S602: Draw the card view onto the specified bitmap.

[0187] The size of the specified bitmap is fixed, for example, 50*50, to facilitate the random selection of pixels later.

[0188] In this embodiment, the electronic device can use the `draw` method to draw the ImageView from the display interface onto a specified 50*50 Bitmap. It is understood that this embodiment does not retrieve the original CardView display content from the electronic device, but instead draws the card view itself, which effectively reduces the memory usage of the electronic device.

[0189] Step S603: Randomly select multiple pixels from the specified bitmap, and calculate the proportion of each color value based on the color value of the pixel.

[0190] Randomly selecting pixels can be achieved by uniformly selecting multiple pixels. The number of pixels selected can be determined based on the size of the bitmap; for example, for a 50x50 bitmap, 500 pixels can be randomly extracted.

[0191] Step S604: Determine whether the maximum percentage is less than the third threshold.

[0192] The third threshold can be set to any value greater than 80%, such as 85%, 90%, or 95%.

[0193] Step S605: If the maximum percentage is less than the third threshold, determine that the card is displayed normally.

[0194] Step S606: If the maximum percentage is greater than or equal to the third threshold, determine that the card is a blank screen.

[0195] Understandably, if the card is blank and has no content displayed, then the card's color values ​​are mostly white, light gray, or a uniform color. Therefore, it is necessary to calculate the proportion of each color value. If the proportion of a certain color value is extremely large, it means that the card is almost a uniform color, and the card is very likely a blank screen.

[0196] In the embodiments of this application, the Figure 6 Another white screen detection method for Quick App cards shown can be used with... Figure 4 The white screen detection methods shown are executed together. For example, in step S409 above, if the number of validation loops for the sub-controls is equal to or greater than the second threshold, the electronic device executes... Figure 6 The white screen detection method shown is intended to further improve the accuracy of white screen detection.

[0197] This application provides another method for detecting white screen on Quick App cards. In this method, the electronic device draws the card view onto a specified bitmap, and then randomly selects multiple pixels from the specified bitmap. Based on the color value of the pixels, the proportion of each color value is calculated. If the maximum proportion is greater than or equal to a third threshold, the card can be determined to be a white screen, thereby improving the efficiency and accuracy of white screen detection for Quick App cards, providing data support for subsequent electronic devices to solve card white screen issues, and improving the user's terminal experience.

[0198] The two white screen detection methods for quick app cards shown above can effectively detect whether a quick app card is blank. However, quick app cards can be loaded in various ways, and the display state and timing of the quick app card differ in different loading methods. Therefore, a unified white screen detection timing is needed for different loading methods to ensure the effectiveness of white screen detection.

[0199] Figure 7 This is a schematic diagram of the interface for loading quick app cards provided in an embodiment of this application. Figure 7 As shown, the loading methods for quick app cards in electronic devices include: non-pre-rendered and pre-rendered methods. The non-pre-rendered method... Figure 7 As reflected in (1) to (3) in the text, the pre-rendering method is achieved through... Figure 7 (4) to (5) are reflected in the text.

[0200] This explanation pertains to the non-pre-rendering method. When pre-rendering is not enabled, the card, while waiting to load, will... Figure 7As shown in (1), the electronic device's interface displays a placeholder image 71 corresponding to the card (the remaining positions are application icons 72). Here, the card placeholder image refers to the dashed border or schematic diagram used in interface design or page layout to represent the card's position, size, and shape. It does not contain the actual content displayed on the card, but serves as a reference or template. When the card is loaded, as shown in (1), the placeholder image is displayed. Figure 7 As shown in (2), the card placeholder image begins to change gradually, and the interface of the electronic device displays the corresponding card skeleton diagram 73. The card skeleton diagram refers to the basic structural framework in card design or interface layout. It shows the main components of the card, their arrangement, and the relationships between them. This skeleton diagram does not contain specific details or decorative elements, but focuses on the overall layout and structural design of the card. When the card is loaded, as shown in (2), the card placeholder image gradually changes, and the interface of the electronic device displays the corresponding card skeleton diagram 73. Figure 7 As shown in (3), the card is loaded and displayed as a complete card 74.

[0201] This section explains the pre-rendering method. When pre-rendering is enabled, the card will display the image while waiting to load or during loading. Figure 7 As shown in (4), the card is not visible in the interface of the electronic device. This continues until the card is fully loaded, as... Figure 7 As shown in (5) in the diagram, the complete card 74 is displayed.

[0202] Understandably, in non-pre-rendered card loading scenarios, if there are problems with the card loading process, the card will continuously display an unplaced image or a skeleton image, resulting in a blank screen. In pre-rendered card loading scenarios, if there are problems with the card loading process, the card will not be loaded at all, resulting in a blank screen.

[0203] For non-pre-rendered scenarios, the host application starts displaying cards after the container finishes rendering. However, for pre-rendered scenarios, the cards are only displayed after a specific event is sent on the JS side (usually after the card element finishes rendering). A unified detection timing needs to be found. Therefore, considering both loading methods for Quick App cards, electronic devices can delay the execution of the white screen detection method for a preset time after the host application card appears on the screen. This allows the white screen detection method to cover various card loading scenarios, improving its usability. The execution timing of the white screen detection method is explained in detail below for different card loading scenarios.

[0204] Figure 8This is a flowchart illustrating a white screen detection method for a non-pre-rendered card loading scenario provided in an embodiment of this application. The white screen detection method is applied to an electronic device, which includes a host application, a processing module, a communication service module, and a JS card module. The processing module and the communication service module are modules under a quick app engine. For scenarios where the card loading method is non-pre-rendered, the white screen detection method includes the following steps S800-S823.

[0205] Step S800: The host application creates a card container.

[0206] Step S801: The host application sends a card view control creation request to the processing module in the Quick App Engine.

[0207] Step S802: After creating the card view control, the processing module returns a message to the host application indicating that the card view control has been successfully created.

[0208] Step S803: After creating the card view control, the processing module obtains the card application resources of the card.

[0209] Step S804: After creating the card view control, the processing module sends a communication channel establishment request to the communication service module.

[0210] Step S805: In response to the communication channel establishment request, the communication service module establishes communication between the JS card module and the processing module.

[0211] Step S806: When the communication between the JS card module and the processing module is established, the JS card module returns a successful communication service binding response to the communication service module.

[0212] Step S807: The communication service module returns a successful communication service binding response to the processing module.

[0213] Step S808: The processing module parses the card application resources.

[0214] Step S809: The processing module creates the root view of the card view control based on the card application resource parsing results.

[0215] Step S810: The processing module creates a page based on the card application resource parsing results.

[0216] Step S811: After the page is created, the processing module sends a notification that the page initialization is complete.

[0217] Step S812: After the page is created, the processing module sends a view on-screen notification to the host application.

[0218] For detailed explanations of the above steps, please refer to the preceding text. Figure 1The card loading process shown is not described in detail here.

[0219] Step S813: The host application responds to the on-screen notification and controls the display of the card.

[0220] It is understandable that steps S8181 and S813 can be executed before or simultaneously with page rendering. In this case, when the host application controls the display of the card, it can first display a placeholder image or skeleton image of the card (without specific content), and then display the specific content after the card page is rendered.

[0221] Step S814: In response to the page initialization completion notification, the communication service module sends a page content rendering notification to the JS card module.

[0222] Step S815: In response to the page content rendering notification, the JS card module sends the first page rendering event to the communication service module.

[0223] The first page rendering event is used to indicate the rendering of static resources on the page.

[0224] Step S816: The communication service module sends the first page rendering event to the processing module.

[0225] Step S817: The processing module responds to the first page rendering event and performs static resource rendering of the page.

[0226] Step S818: The JS card module responds to the first page rendering event and obtains dynamic resources.

[0227] Step S818 is executed synchronously with the aforementioned step S815.

[0228] Step S819: Upon completion of dynamic resource acquisition, the JS card module sends a second page rendering event to the communication service module.

[0229] The second page rendering event is used to indicate the rendering of dynamic resources on the page.

[0230] Step S820: The communication service module sends the second page rendering event to the processing module.

[0231] Step S821: The processing module responds to the second page rendering event and performs dynamic page resource rendering.

[0232] Step S822: The host application sends a card display notification to the processing module.

[0233] The card display notification is, for example, the onVisibilityChange event.

[0234] It is understandable that step S822 follows the aforementioned step S813. After the host application controls the card to display, the host application sends a card display notification to the processing module. That is, steps S812, S813, and S822 are two processes executed in parallel with steps S811 and S814-S821.

[0235] In some embodiments, the processing module receives a card display notification and records the time of receipt.

[0236] Step S823: When the processing module is at a preset time interval from the time the notification is received by the card, it executes the white screen detection method.

[0237] The preset duration can be set according to the actual application, such as 3s or 4s.

[0238] In this embodiment of the application, when the processing module receives the card display notification, it does not immediately perform white screen detection, but delays for a preset time to wait for the content on the page to finish rendering. This avoids the temporary white screen caused by the content on the page not finishing rendering, which can effectively improve the usability of the white screen detection method in this embodiment of the application and enable the white screen detection method to be applied to more scenarios.

[0239] Figure 9 This is a flowchart illustrating a white screen detection method for a pre-rendered card loading scenario provided in an embodiment of this application. The white screen detection method is applied to an electronic device, which includes a host application, a processing module, a communication service module, and a JS card module. The processing module and the communication service module are modules under a quick app engine. For scenarios where the card loading method is not pre-rendered, the white screen detection method includes the following steps S900-S823.

[0240] Step S900: The host application creates a card container.

[0241] Step S901: The host application sends a card view control creation request to the processing module in the Quick App Engine.

[0242] Step S902: After creating the card view control, the processing module returns a message to the host application indicating that the card view control has been successfully created.

[0243] Step S903: After creating the card view control, the processing module obtains the card application resources of the card.

[0244] Step S904: After creating the card view control, the processing module sends a communication channel establishment request to the communication service module.

[0245] Step S905: In response to the communication channel establishment request, the communication service module establishes communication between the JS card module and the processing module.

[0246] Step S906: When the communication between the JS card module and the processing module is established, the JS card module returns a successful communication service binding response to the communication service module.

[0247] Step S907: The communication service module returns a successful communication service binding response to the processing module.

[0248] Step S908: The processing module parses the card application resources.

[0249] Step S909: The processing module creates the root view of the card view control based on the card application resource parsing results.

[0250] Step S910: The processing module creates a page based on the card application resource parsing results.

[0251] Step S911: After the page is created, the processing module sends a notification that the page initialization is complete.

[0252] Step S912: After the page is created, the processing module sends a view on-screen notification to the host application.

[0253] For detailed explanations of the above steps, please refer to the preceding text. Figure 1 The card loading process shown is not described in detail here.

[0254] Step S913: The host application responds to the on-screen notification and controls the display of the card.

[0255] Steps S912 and S913 can be performed after the page rendering is complete. In this case, when the host application controls the display of the card, it can directly display the rendered card.

[0256] Step S914: In response to the page initialization completion notification, the communication service module sends a page content rendering notification to the JS card module.

[0257] Step S915: The JS card module responds to the page content rendering notification by sending a page rendering event to the communication service module.

[0258] Step S916: The communication service module sends the page rendering event to the processing module.

[0259] Step S917: The processing module responds to the page rendering event and renders the card content.

[0260] Step S918: The host application sends a card display notification to the processing module.

[0261] The card display notification is, for example, the onVisibilityChange event.

[0262] It is understandable that step S918 follows the aforementioned step S913. After the host application controls the card to display, the host application sends a card display notification to the processing module. That is, steps S912, S913, and S918 are two processes executed in parallel with steps S911 and steps S914-S917.

[0263] In some embodiments, the processing module receives a card display notification and records the time of receipt.

[0264] Step S919: When the processing module is at a preset time interval from the time the notification is received by the card, it executes the white screen detection method.

[0265] In this embodiment, when the processing module receives the card display notification, it does not immediately perform white screen detection, but delays for a preset time to wait for the content on the page to be rendered before the card is displayed. This can effectively improve the usability of the white screen detection method in this embodiment and enable the white screen detection method to be applied to more scenarios.

[0266] In this embodiment of the application, by combining the above-mentioned white screen detection method and detection timing, error information classification is established for white screen anomalies in different scenarios, and data reporting is carried out. The white screen anomalies are attributed through big data, thereby further solving the white screen problem of JS cards.

[0267] The steps performed by the electronic device in the white screen detection method for quick app cards provided in the above-described embodiments of this application can also be performed by a chip system included in the electronic device. This chip system may include a processor and a Bluetooth chip. The chip system can be coupled to a memory, enabling it to call a computer program stored in the memory during runtime to implement the steps performed by the electronic device. The processor in the chip system can be an application processor or a non-application processor.

[0268] This embodiment also provides a computer-readable medium storing computer instructions, which, when executed on an electronic device, cause the electronic device to perform the aforementioned method steps to implement the methods described in the above embodiments.

[0269] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the methods described in the above embodiments.

[0270] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the methods in the above-described method embodiments.

[0271] In this embodiment, the electronic device, computer-readable medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0272] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0273] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0274] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0275] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code. The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for detecting white screen for quick app cards, characterized in that, The method includes: For Quick App cards, determine whether there are any abnormal control states in the multi-level parent and child controls of the corresponding card view control; If a control's state is abnormal, the Quick App card will be displayed as a blank screen.

2. The method according to claim 1, characterized in that, For Quick App cards, determining whether there are any abnormal control states in the multi-level parent and child controls of the corresponding card view control includes: Iterate through the Kth-level parent controls of the card view control to determine if any of the parent controls in the Kth-level parent control have an abnormal control state; the value of K is the first verification loop count plus one; the initial value of the first verification loop count is 0; If there is an abnormal state of the parent control in the Kth layer parent control, determine that the Quick App card is a blank screen; If a control in the Kth layer has no parent control and its state is abnormal, increment the first validation loop count by one; Determine whether the number of the first verification loop is less than the first threshold; If the number of the first verification loop is less than the first threshold, return to the step of traversing the Kth layer parent control of the verification card view control and determining whether there is an abnormal control state of the parent control in the Kth layer parent control.

3. The method according to claim 2, characterized in that, The method further includes: If the first verification loop count is equal to or greater than the first threshold, the Mth layer of sub-controls of the verification card view control is traversed to determine whether there is an abnormal control state of any sub-control in the Mth layer of sub-controls; the value of M is the second verification loop count plus one; the initial value of the second verification loop count is 0; If the state of a control is abnormal and there is no sub-control in the M-th layer, increment the second validation loop count by one; Determine whether the second verification loop count is less than the second threshold; If the number of the second verification loop is less than the second threshold, return to the step of traversing the Mth layer of sub-controls of the verification card view control and determining whether there are any sub-controls with abnormal control states in the Mth layer of sub-controls; If the number of the second verification loop is greater than or equal to the second threshold, it is determined that the control state is not abnormal.

4. The method according to claim 2, characterized in that, The process of traversing and verifying the Kth-level parent controls of the card view control to determine whether there are any parent controls with abnormal control states includes: Iterate through the Kth level parent controls of the card view control and, for each parent control in the Kth level parent control, determine whether the attribute value of the parent control is null. If the attribute value of the parent control is empty, it is determined that the parent control has an abnormal control state. If the attribute value of the parent control is not empty, determine whether the parent control is visible. If the parent control is invisible, it is determined that there is a control whose parent control is in an abnormal state. If the parent control is visible, determine whether the parent control is transparent. If the parent control is in a transparent state, it is determined that there is an abnormal state of the parent control. If the parent control is not transparent, it is determined that the parent control's control state is normal.

5. The method according to claim 3, characterized in that, The process of traversing and verifying the Mth layer of child controls in the card view control to determine whether any child controls in the Mth layer have abnormal control states includes: Iterate through the Mth layer of child controls of the validation card view control, and for each child control in the Mth layer, determine whether the child control has a zero value; If the number of child controls is zero, it is determined that there is a control with abnormal state due to the presence of child controls. If the number of child controls is not zero, determine whether the child control is visible. If the child control is invisible, it is determined that there is a control with an abnormal state where the child control is not visible. If the child control is visible, determine whether the child control is transparent. If the child control is in a transparent state, it is determined that there is a control state abnormality in the child control; If the child control is not transparent, it is determined that the control state of the child control is normal.

6. The method according to claim 1, characterized in that, The method further includes: If there is no abnormality in the control's state, retrieve the card view from the display interface; Draw the card view onto the specified bitmap; Randomly select multiple pixels from the specified bitmap, and calculate the proportion of each color value based on the color value of the pixels; Determine whether the largest percentage is less than the third threshold; If the largest percentage is less than the third threshold, the quick app card is determined to be displayed normally; If the largest percentage is greater than or equal to the third threshold, the quick app card is determined to be a blank screen.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: The Quick App Engine receives card display notifications sent by the host application and records the moment of receipt; The quick app engine executes the method as described in any one of claims 1-6 when the time interval between the received time and the preset time interval is reached.

8. The method according to claim 7, characterized in that, The host application includes at least the following: the negative one screen, the desktop, and the quick app center.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Memory; And a computer program, wherein the computer program is stored on the memory, and when the computer program is executed by the one or more processors, causes the electronic device to perform the method as described in any one of claims 1-8.

10. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-8.

Images