A rendering method and electronic device

CN122816733APending Publication Date: 2026-09-25HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510353292.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-03-24
Publication Date
2026-09-25

AI Technical Summary

Technical Problem

然而,在通过Modifier渲染子节点对应的组件的过程中,存在冗余数据占用内存,整个渲染过程的渲染效率较低

Benefits of technology

[0037]上述第二方面至第五方面提供的方案,用于实现或配合实现上述第一方面中对应提供的方法,因此可以与第一方面中对应的方法达到相同或相应的有益效果,此处不再进行赘述。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122816733A_ABST
    Figure CN122816733A_ABST
Patent Text Reader

Abstract

Embodiments of the present application disclose a rendering method and an electronic device. The method comprises: when a node tree of a first interface is created, a first electronic device puts a plurality of attributes of a first component into a first Modifier of a first node corresponding to the first component; receiving a refresh signal for the first interface, the first electronic device traverses the node tree of the first interface; when the first node is traversed, the first electronic device renders the first component according to a first Drawable of the first Modifier, the first Drawable being generated by the first electronic device according to the plurality of attributes of the first Modifier. In this way, the electronic device can directly generate the Drawable based on the Modifier containing the plurality of attributes, without generating the Drawable through the RSProperties attribute slot, thereby improving the rendering efficiency and avoiding redundant data occupying the memory in the rendering process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a rendering method and an electronic device. Background Technology

[0002] With the development of technology, electronic devices have gradually become an indispensable tool in people's lives. Electronic devices can display user interfaces containing images, videos, and other content on the screen. Before displaying the user interface on the screen, the electronic device needs to render the components at different levels of the user interface in the form of a node tree. The root node of the node tree corresponds to the user interface, and different child nodes of the node tree correspond to different components in the user interface.

[0003] Child nodes in a node tree can hold one or more Modifiers. A Modifier is a rendering node decorator containing a single property, which can be used to set values ​​such as the size and position of the component corresponding to the node. Currently, electronic devices can render the component corresponding to a child node using its Modifier. However, in the process of rendering the component corresponding to a child node using a Modifier, redundant data consumes memory, resulting in low rendering efficiency. Summary of the Invention

[0004] Currently, a node typically carries one or more Modifiers, and each Modifier contains only one property. During the rendering process of components corresponding to child nodes of the node tree, the electronic device needs to first set the properties of all nodes in the node tree into the RSProperties property slot using the ApplyModifier function. The RSProperties property slot can be understood as a set of properties that the Modifier needs to process during rendering. Each Modifier inserts its own properties into the RSProperties property slot, and all nodes in the node tree carry all the properties in the RSProperties property slot. Thus, before generating a Drawable (also called drawing logic), each node needs to traverse all the properties in the RSProperties property slot to obtain the properties that the corresponding Drawable depends on, resulting in low rendering efficiency and redundant data consuming memory. The aforementioned Drawable can be understood as a drawing logic (drawing rule) used to generate drawing instructions that drive the graphics processing unit (GPU). The form of the Drawable can be, for example, code, script, etc., and this application embodiment does not limit this. Among them, the drawing instructions that drive the GPU (also known as Drawable commands) are low-level graphics operation commands that can be used to draw the components corresponding to nodes on the screen.

[0005] To address the aforementioned problems, this application provides a rendering method and an electronic device. This method can be applied to a first electronic device. The method includes: when creating a node tree of a first interface, the first electronic device can place multiple attributes of a first component into a first Modifier of the first node corresponding to the first component; upon receiving a refresh signal for the first interface, the first electronic device can traverse the node tree of the first interface; when traversing to a first node, the first electronic device can render the first component according to a first Drawable of the first Modifier, where the first Drawable is generated by the first electronic device based on multiple attributes of the first Modifier. Through the method provided by this application, the electronic device can directly generate a Drawable based on a Modifier containing multiple attributes in a node, without needing to generate a Drawable through the RSProperties attribute slot, thus improving rendering efficiency and avoiding redundant data consuming memory during the rendering process.

[0006] In a first aspect, this application provides a rendering method applied to a first electronic device. The method includes: when creating a node tree of a first interface, placing multiple attributes of a first component into a first decorator Modifier of the first node corresponding to the first component; wherein the first node of the node tree corresponds to the first component of the first interface; upon receiving a refresh signal for the first interface, traversing the node tree; and when traversing to the first node, rendering the first component according to the first drawing logic of the first Modifier.

[0007] The first electronic device can be Figure 9 The electronic device 100 shown; the first interface can be any interface displayed on the screen, for example... Figure 1B The user interface 1010 shown is... Figure 1A The node tree shown can be the node tree of the user interface 1010; the first component can be any component in the first interface; the first node can be any child node in the node tree, and the first node corresponds to the first component; the first modifier can be any rendering node decorator carried by the first node; the first drawing logic can be a drawing logic (drawing rule) for generating drawing instructions for driving the GPU of the first component. The form of the first drawing logic can be, for example, code, script, etc., and this application embodiment does not limit it. In this application embodiment, the first drawing logic (first Drawable) is the drawing logic contained in the first modifier, and this drawing logic is the drawing logic of multiple attributes.

[0008] For example, the first electronic device can create Figure 1B The node tree shown in the user interface 1010 is a node tree that is Figure 1A The node tree shown. The control 1015 corresponding to leaf node 3 needs boundary drawing. The application corresponding to user interface 1010 can send the three properties BorderWidth, BorderColor, and BorderStyle, which are dependent on the drawing logic of leaf node 3, to the rendering service. (This is in the context of creation.) Figure 1A When the node tree shown is displayed, the first electronic device can use the rendering service to put the three properties of control 1015—BorderWidth, BorderColor, and BorderStyle—into the RSBorderModifier of leaf node 3. Then, upon receiving a refresh signal for user interface 1010 from the application corresponding to user interface 1010, the first electronic device can traverse the tree using the rendering service. Figure 1AThe node tree shown. When traversing to leaf node 3, the first electronic device can generate the boundary drawing logic through the rendering service based on the three attributes BorderWidth, BorderColor, and BorderStyle contained in RSBorderModifier, and render control 1015 according to the boundary drawing logic.

[0009] By using the method provided in the first aspect, the first electronic device can directly generate drawing logic based on a Modifier containing multiple attributes in a node, without having to generate drawing logic through the RSProperties attribute slot. This simplifies the rendering framework, improves rendering efficiency, avoids redundant data occupying memory during the rendering process, and saves memory.

[0010] In conjunction with the first aspect, in some embodiments, the first drawing logic is generated by the first electronic device based on multiple attributes of the first modifier.

[0011] In some embodiments, the first electronic device may first generate first drawing logic based on multiple attributes contained in the first modifier, and then place the first drawing logic into the first modifier. For example, as shown... Figure 5 As shown, the Modifier contains attributes and drawing logic. There are multiple attributes. The drawing logic of the Modifier is based on the implementation method of the component corresponding to the node drawn by the above multiple attributes (i.e., the rendering method of multiple attributes). This drawing logic is generated by the first electronic device according to the multiple attributes contained in the Modifier.

[0012] In conjunction with the first aspect, in some embodiments, multiple attributes are attributes that the first modifier depends on for generating the first drawing logic.

[0013] It should be noted that the properties that the Modifier generates based on the corresponding drawing logic can be understood as the properties that the Modifier needs to generate the corresponding drawing logic.

[0014] In conjunction with the first aspect, in some embodiments, multiple attributes are all attributes that the first modifier depends on to generate the first drawing logic.

[0015] For example, if the attributes of the first component issued by the application corresponding to the first interface do not include common attributes, then the first electronic device can directly generate the first drawing logic based on all the attributes that the first drawing logic depends on, contained in the first modifier. The common attributes can be attributes required by more than a preset number (e.g., 5) of different types of modifiers when generating the drawing logic.

[0016] In conjunction with the first aspect, in some embodiments, multiple attributes of the first component are placed into the first decorator Modifier of the first node corresponding to the first component. Specifically, this includes: placing multiple attributes into the first Modifier by querying a first table, wherein the first table records the dependencies between multiple attributes and the first drawing logic.

[0017] For example, the first table may include, but is not limited to, the dependencies between attributes and drawing logic of the first type, and the dependencies between attributes and drawing logic of the second type. If the drawing logic of the first type depends on attributes 1, 2, 3, and 4, and the drawing logic of the second type depends on attributes 5 and 6, then attributes 1, 2, 3, and 4 can be included in the first modifier, and attributes 5 and 6 can be included in the second modifier. It should be noted that, besides tables, the recording format of the dependencies between attributes and different types of drawing logic can also be other, and this embodiment does not limit this.

[0018] In conjunction with the first aspect, in some embodiments, before placing multiple attributes of the first component into the first decorator Modifier of the first node corresponding to the first component, the method further includes: generating a first table based on the attributes of the first component and the dependencies of different drawing logics.

[0019] In this way, when creating the node tree of the first interface, the first electronic device can query the first table to put multiple attributes of the first component into the first modifier of the first node corresponding to the first component.

[0020] In conjunction with the first aspect, in some embodiments, the properties of the first component further include a Bounds property. When creating the node tree of the first interface, the method further includes: putting the Bounds property into the second Modifier of the first node; when traversing to the first node, the method further includes: removing the Bounds property from the second Modifier.

[0021] The second Modifier can be the Modifier corresponding to the public property. This Modifier containing the public property does not generate drawing logic when other Modifiers generate drawing logic. Instead, it can move the public property from the Modifier containing the public property to the public class so that the Modifier that needs the public property can obtain the public property from the public class when generating drawing logic.

[0022] In some embodiments, the properties of the first component may include common properties, which may be properties required by more than a preset number (e.g., 5) of different types of modifiers when generating the drawing logic.

[0023] For example, the Bounds property is a public property that most geometry modifiers require when generating drawing logic. When creating the node tree of the first interface, the first electronic device can put the Bounds property into the RSBoundsModifier of the first node. This RSBoundsModifier does not generate drawing logic when other modifiers generate drawing logic; instead, it can move the Bounds property from the RSBoundsModifier to the ModifierContext public class, so that geometry modifiers that require the Bounds property can obtain the Bounds property from the ModifierContext public class when generating drawing logic.

[0024] In conjunction with the first aspect, in some embodiments, the first drawing logic is generated by the first electronic device based on multiple attributes of the first Modifier and the acquired Bounds attribute.

[0025] In some embodiments, the first electronic device may not place the public attributes in any individual modifier, but instead place them in a public class, so that modifiers that need the public attributes can obtain them from the public class when generating drawing logic. It should be noted that a public class is a carrier for storing public attributes. Besides a public class, other carriers can also be used to store public attributes, and this application embodiment does not impose any limitations on this.

[0026] For example, the first electronic device may not place the Bounds property in any individual geometry modifier, but instead place the Bounds property in the ModifierContext public class, so that geometry modifiers that need the Bounds property can obtain the Bounds property from the ModifierContext public class when generating drawing logic. It should be noted that the ModifierContext public class is a carrier for storing the Bounds property. Besides the ModifierContext public class, other carriers can also be used to store the Bounds property, and this application embodiment does not limit this.

[0027] In conjunction with the first aspect, in some embodiments, when the first Modifier is a geometry Modifier, the attributes of the geometry Modifier include the position of the first component and / or the size of the first component. When the first Modifier is a background Modifier, the attributes of the background Modifier include the background color of the first component and / or the background image of the first component. When the first Modifier is a content Modifier, the attributes of the content Modifier include the content color of the first component and / or the content style of the first component. When the first Modifier is a foreground Modifier, the attributes of the foreground Modifier include the foreground color of the first component and / or the foreground boundary of the first component. When the first Modifier is an overlay Modifier, the attributes of the overlay Modifier include the attributes of the first component after the foreground is drawn, which include one or more of the following: dividing lines, shadow effects, and filter effects.

[0028] In conjunction with the first aspect, in some embodiments, the positional attributes of the first component include one or more of the following: Pivot attribute, Translate attribute, and the size attributes of the first component include one or more of the following: Bounds attribute, Scale attribute.

[0029] In conjunction with the first aspect, in some embodiments, the first modifier includes one or more of the following: geometry modifier, background modifier, content modifier, foreground modifier, and overlay modifier.

[0030] It's important to note that the aforementioned geometry modifiers, background modifiers, content modifiers, foreground modifiers, overlay modifiers, etc., are logical classifications of modifiers, not actual execution units within the rendering process. These different types of modifiers can include one or more modifiers containing multiple attributes; these attribute-containing modifiers are the actual execution units within the rendering process. For example, geometry modifiers include geometric transformation modifiers and boundary drawing modifiers. Geometric transformation modifiers contain multiple attributes such as Bounds, Pivot, Quaternion, Scale, Translate, and Persp, while boundary drawing modifiers contain multiple attributes such as Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap. Geometry modifiers are a logical classification of modifiers; geometric transformation modifiers and boundary drawing modifiers are the actual execution units within the rendering process.

[0031] In conjunction with the first aspect, in some embodiments, the method further includes: generating drawing instructions for driving the GPU of the first component based on the first drawing logic; and rendering the first component based on the drawing instructions for driving the GPU.

[0032] In some embodiments, after generating the first drawing logic, the first electronic device can generate drawing instructions for the first component that drive the GPU based on the first drawing logic and send them to the GPU driver in the kernel, so that the first electronic device can render the first component corresponding to the first node based on the aforementioned drawing instructions for driving the GPU. The drawing instructions for driving the GPU (also known as Drawable commands) are low-level graphics operation commands that can be used to draw the first component corresponding to the first node on the screen.

[0033] In a second aspect, this application provides an electronic device, which includes a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program, and when the processor executes the computer program, the electronic device performs the method described in any of the first aspects above.

[0034] Thirdly, this application provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in any of the first aspects above.

[0035] Fourthly, this application provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects above.

[0036] Fifthly, this application provides a chip including a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, causing the chip to perform the method described in any of the first aspects above.

[0037] The solutions provided in the second to fifth aspects above are used to implement or cooperate with the methods provided in the first aspect above, and therefore can achieve the same or corresponding beneficial effects as the methods in the first aspect, which will not be elaborated here. Attached Figure Description

[0038] Figures 1A-1B This is a schematic diagram of a node tree and its corresponding components provided in an embodiment of this application;

[0039] Figure 2 This is a schematic diagram illustrating the implementation process of an implicit animation provided in an embodiment of this application;

[0040] Figure 3 This is a schematic diagram illustrating a process of generating a Drawable through an RSProperties property slot, as provided in an embodiment of this application.

[0041] Figure 4 This is a schematic diagram of a modifier for generating a Drawable through an RSProperties property slot, provided in an embodiment of this application.

[0042] Figure 5 This is a schematic diagram of the structure of a Modifier provided in an embodiment of this application;

[0043] Figure 6 This is a schematic diagram illustrating a process of generating a Drawable using a Modifier containing multiple attributes, as provided in an embodiment of this application.

[0044] Figure 7 This is a schematic diagram of a modifier containing multiple attributes provided in an embodiment of this application;

[0045] Figure 8 This is a flowchart illustrating a rendering method provided in an embodiment of this application;

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

[0047] Figure 10This is a schematic diagram of a software architecture provided in an embodiment of this application. Detailed Implementation

[0048] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be a limitation of this application.

[0049] With the development of technology, electronic devices have gradually become an indispensable tool in people's lives. Electronic devices can display user interfaces containing images, videos, and other content on the screen. Before displaying the user interface on the screen, the electronic device needs to render the components at different levels of the user interface in the form of a node tree. The root node of the node tree corresponds to the user interface, and different child nodes of the node tree correspond to different components in the user interface.

[0050] Figures 1A-1B An exemplary embodiment of this application provides a node tree and its corresponding components.

[0051] like Figures 1A-1B As shown, Figure 1A The node tree shown contains three levels of nodes: root node, group nodes, and leaf nodes. The group nodes include group node 1 and group node 2, and the leaf nodes include leaf node 1, leaf node 2, and leaf node 3. Leaf node 1 is a child node of group node 1, and leaf nodes 2 and 3 are children nodes of group node 2. The root node can correspond to the user interface displayed on the screen of an electronic device. For example, Figure 1A The root node of the node tree shown can be connected to... Figure 1B The user interfaces 1010 shown correspond one-to-one. Grouping nodes can be used to organize interface elements on the screen to represent logical grouping or modularization, such as all components within a window. For example, Figure 1A The group node 1 of the node tree shown can be connected with... Figure 1B The windows 1011 shown correspond one-to-one. Figure 1A The group node 2 of the node tree shown can be connected with... Figure 1B The windows 1012 shown correspond one-to-one. Leaf nodes can be used to represent UI elements on the screen, such as components. For example, Figure 1A Leaf node 1 of the node tree shown can be connected to... Figure 1B The text content 1013 (i.e., text 1) in window 1011 shown corresponds one-to-one. Figure 1A Leaf node 2 of the node tree shown can be connected to... Figure 1B The text content 1014 (i.e., text 2) in window 1012 shown corresponds one-to-one. Figure 1A Leaf node 3 of the node tree shown can be connected to... Figure 1BThe controls 1015 (i.e. "OK" controls) in window 1012 shown correspond one-to-one.

[0052] Child nodes of the node tree (including group nodes and leaf nodes) carry modifiers used to decorate the nodes. Currently, this modifier is a render node decorator containing a single property, where the modifier's property can be used to set values ​​such as the size and position of the corresponding component of the node. For example, the declaration of a modifier's property can be as follows:

[0053]

[0054] It should be noted that electronic devices can modify nodes using multiple modifiers that contain the same type of attributes. For example, a node can have three modifiers that contain color attributes, with the attribute values ​​being blue, green, and red, respectively. These three colors can be set together on the component corresponding to the node.

[0055] Understandably, the Modifier's structure ensures that rendering is data-driven, where the data can be understood as the properties of the component corresponding to the node. The Modifier is only responsible for rendering the component corresponding to the node based on the input data, such as retrieving color from properties to draw the component's shape. In this way, whenever the data is updated, the Modifier can render the component based on the new data, thus achieving data-driven rendering.

[0056] Furthermore, electronic devices can implement implicit animations using modifiers. Implicit animations are the opposite of explicit animations. Explicit animations require developers to calculate the property values ​​for each frame and set them on the component to control the intermediate processes of the animation. Implicit animations, on the other hand, only require developers to specify the start frame (i.e., the initial frame) and the end frame (i.e., the final frame). The system can automatically handle the intermediate processes of the animation, without requiring developers to specify each frame in detail.

[0057] Figure 2 An example is shown illustrating the implementation process of an implicit animation provided in an embodiment of this application.

[0058] like Figure 2As shown, each component corresponds to a leaf node in the node tree. This node can include one or more Modifiers, such as `OpacityModifier1`, `OpacityModifier2`, `RotationModifier`, `CustomDrawingModifier`, and `ZOrderModifier`. It's important to note that `OpacityModifier1` and `OpacityModifier2` are two Modifiers containing opacity properties, and they can be stacked together to modify the node's opacity. The `OpacityModifier` controls the component's opacity and is a system-animable Modifier. System-animable Modifiers are built-in system Modifiers that support animation effects and contain animable properties. The `RotationModifier` sets the component's rotation angle to achieve a rotation effect and is also a system-animable Modifier. The `CustomDrawingModifier` allows you to customize the component's drawing logic to achieve specific drawing functions and is a custom-animable Modifier. Custom-animable Modifiers are Modifiers implemented by developers according to their needs, supporting animation effects and containing animable properties. ZOrderModifier can be used to adjust the display order of components along the Z-axis (vertical axis), such as controlling the hierarchical relationship of components in the user interface. The larger the Z-axis value, the higher the component's hierarchy in the user interface. This ZOrderModifier is a non-animable Modifier. Non-animable Modifiers do not support animation effects and contain non-animable properties. They are typically used for static component decoration, such as setting component borders, background images, and other properties without intermediate transition states. It's understandable that the aforementioned opacity Modifier, rotation Modifier, and custom-drawn Modifier all contain animable properties; therefore, they all have the ability to set animable data to achieve animation effects. It's also understandable that the aforementioned system animable Modifier, custom animable Modifier, and non-animable Modifier are logical classifications of Modifiers, not actual execution units in the rendering process. The aforementioned opacity Modifier1, opacity Modifier2, rotation Modifier, custom-drawn Modifier, and ZOrderModifier are the actual execution units in the rendering process.

[0059] The implementation process of implicit animation may include: First, the electronic device can select a Modifier containing animable attributes (such as system animable Modifiers and custom animable Modifiers) from all Modifiers carried by the node, and obtain the animable data from the animable attributes in the animable attributes, which conforms to the animable data protocol; the animable data may include, but is not limited to, the start frame of the animation, the end frame of the animation, animation parameters such as duration and motion curves, where the motion curve can be used to indicate the pattern of change of animation attribute values; then, the electronic device... The implicit animation creation management module can be used to create processes for animation interpolation calculations. Then, the electronic device can calculate the attribute values ​​of each frame in the intermediate process of the animation based on the animation parameters. For example, if the transparency of a screen display changes from 0 to 1, the animation duration is 1 second, and the animation motion curve is a linear curve, the electronic device can calculate the transparency value of each frame that changes at a uniform speed within 1 second through interpolation, thereby achieving a smooth transition effect. Finally, the electronic device can update the attribute values ​​of each frame in the intermediate process of the animation frame by frame, and replace the calculated attribute values ​​of the ending frame of the animation with the attribute values ​​of the ending frame in the animable data.

[0060] During the rendering process of components corresponding to child nodes in the node tree, the electronic device needs the Modifier carried by the node to generate a Drawable (also known as drawing logic) through the RSProperties property slot. This Drawable can be understood as a drawing logic (drawing rule) used to generate drawing instructions for the graphics processing unit (GPU) driving the component. The form of the Drawable can be, for example, code, script, etc., and this embodiment does not limit this. Further, the electronic device can generate drawing instructions for the GPU driving the component based on the Drawable and send them to the GPU driver in the kernel, so that the electronic device can render the component corresponding to the node based on the drawing instructions. These drawing instructions are low-level graphics operation commands that can be used to draw the component corresponding to the node on the screen. It should be noted that the RSProperties property slot can be understood as a set of properties that the Modifier needs to process during the rendering process. Each Modifier will insert its own properties into the RSProperties property slot, and the content and order of the properties contained in the RSProperties property slot are strictly defined.

[0061] Figure 3 An exemplary embodiment of this application illustrates a process for generating a Drawable via an RSProperties property slot.

[0062] like Figure 3 As shown, a node has one or more attributes, which are contained in one or more Modifiers carried by that node. Each attribute corresponds one-to-one with a Modifier; that is, a Modifier contains only one attribute. During the rendering of components corresponding to child nodes of the node tree, the electronic device first traverses the node tree and sets the attributes of all nodes in the tree into RSProperties attribute slots by calling the ApplyModifier function through the Modifier. After obtaining the RSProperties attribute slots, all nodes in the node tree carry all the attributes in the RSProperties attribute slots. Then, the electronic device can traverse all the attributes in the RSProperties attribute slots carried by each node to obtain the attributes that the corresponding Drawable depends on. These attributes satisfy a preset condition in the RSProperties attribute slots carried by the node; this preset condition can be, for example, a non-null value. Finally, the electronic device can generate the corresponding Drawable based on the obtained attributes that the Drawable depends on. It should be noted that a node can generate one or more Drawables; this embodiment does not limit the number of generated Drawables. It should be noted that if a node generates multiple Drawables, the generation of these Drawables is based on a fixed order specified in the code. It should also be noted that the attributes that the aforementioned Drawables depend on can be understood as the attributes required to generate the corresponding Drawable. Furthermore, it should be noted that a Drawable can be generated by one or more Modifiers carried by the node through the RSProperties attribute slot; this embodiment does not limit the number of Modifiers required to generate a Drawable. Finally, it should be noted that the Drawable here is generated by an electronic device through the RSProperties attribute slot.

[0063] For example, a node is Node1, which has six properties: RSProperty1, RSProperty2, RSProperty3, RSProperty4, RSProperty5, and RSProperty6. These six properties correspond one-to-one with six modifiers: RSModifier1, RSModifier2, RSModifier3, RSModifier4, RSModifier5, and RSModifier6, respectively. During the rendering of the component corresponding to Node1, the electronic device needs to traverse the node tree containing Node1 and set the properties of all nodes in the tree into the RSProperties property slots by calling the ApplyModifier function through the Modifier. In Node1, the six modifiers RSModifier1, RSModifier2, RSModifier3, RSModifier4, RSModifier5, and RSModifier6 all call the ApplyModifier function to set the six properties RSProperty1, RSProperty2, RSProperty3, RSProperty4, RSProperty5, and RSProperty6 into the RSProperties property slots, respectively. After obtaining the RSProperties property slots, Node1 carries all the properties in the RSProperties property slots. Then, the electronic device can iterate through all the properties in the RSProperties property slots carried by Node1 to obtain the properties that RSDrawable1 and RSDrawable2 depend on. In the RSProperties property slots carried by Node1, the six properties RSProperty1, RSProperty2, RSProperty3, RSProperty4, RSProperty5, and RSProperty6 are not null values. Finally, the electronic device can generate RSDrawable1 based on the acquired RSProperty1, RSProperty2, RSProperty3, and RSProperty4, and generate RSDrawable2 based on the acquired RSProperty5 and RSProperty6.

[0064] As can be seen, the rendering efficiency of generating Drawables via RSProperties property slots is low because the electronic device needs to traverse the node tree to obtain RSProperties property slots before generating the Drawable, and also needs to traverse all properties in the RSProperties property slots to obtain the properties that the corresponding Drawable depends on. Furthermore, since each node needs to carry all properties from the RSProperties property slot, while the properties that the corresponding Drawable depends on only occupy a portion, there is redundant data consuming memory. For example, after traversing the node tree, the electronic device obtains an RSProperties property slot containing 100 properties. Although node 1 only needs 20 properties to generate the Drawable, node 1 still needs to carry all 100 properties from the RSProperties property slot, and node 1 needs to traverse from those 100 properties to obtain the 20 properties that the Drawable depends on.

[0065] It's important to clarify that currently, modifiers can logically be categorized into geometry modifiers, background modifiers, content modifiers, foreground modifiers, and so on. Different types of modifiers can include one or more modifiers containing a single attribute. It's important to understand that these categories (geometry, background, content, foreground, etc.) are logical classifications of modifiers, not actual execution units within the rendering process. Modifiers with a single attribute are the actual execution units in the rendering process. For example, geometry modifiers include translation modifiers and scaling modifiers; a translation modifier contains only the translation attribute, and a scaling modifier contains only the scaling attribute. Geometry modifiers are a logical classification; translation and scaling modifiers are the actual execution units in the rendering process.

[0066] Figure 4 An exemplary embodiment of this application provides a modifier for generating Drawables via RSProperties property slots.

[0067] like Figure 4As shown, an exemplary geometry modifier (i.e., RSGeometryModifier) ​​is illustrated. This geometry modifier (i.e., RSGeometryModifier) ​​includes, but is not limited to, BoundsModifier, PivotModifier, QuaternionModifier, ScaleModifier, TranslateModifier, and PerspModifier. Each of these six modifiers contains only one attribute. Taking the above six modifiers as examples, each containing the six attributes Bounds, Pivot, Quaternion, Scale, Translate, and Persp, the modifier and the attribute correspond one-to-one.

[0068] In one possible implementation, the component corresponding to node 1 needs to undergo geometric transformation. For example, the application sends a Drawable containing the geometric transformation to the rendering service, which depends on six properties: Bounds, Pivot, Quaternion, Scale, Translate, and Persp. Node 1 carries six Modifiers: BoundsModifier, PivotModifier, QuaternionModifier, ScaleModifier, TranslateModifier, and PerspModifier. These six Modifiers respectively contain the six properties: Bounds, Pivot, Quaternion, Scale, Translate, and Persp. Each property corresponds one-to-one with its Modifier. Then, the system's main rendering thread traverses the node tree. When traversing to node 1, since node 1 carries all properties in the RSProperties property slot, the main rendering thread can traverse all properties in the RSProperties property slot to obtain the six properties (Bounds, Pivot, Quaternion, Scale, Translate, and Persp) that the Drawable depends on for the geometric transformation, thus generating a Drawable with the geometric transformation.

[0069] In another possible implementation, the component corresponding to node 1 needs to perform boundary drawing. Taking the six attributes Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap that the application sends to the rendering service for boundary drawing as an example, node 1 carries six modifiers: BoundsModifier, BorderWidthModifier, BorderColorModifier, BorderStyleModifier, BorderDashWidthModifier, and BorderDashGapModifier. These six modifiers respectively contain the six attributes Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap, with each attribute corresponding to a modifier. Then, the system's main rendering thread traverses the node tree. When traversing to node 1 in the node tree, since node 1 carries all the properties in the RSProperties property slot, the rendering main thread can traverse all the properties in the RSProperties property slot to obtain the six properties that the boundary drawing Drawable depends on: Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap, in order to generate a boundary drawing Drawable. This boundary drawing Drawable can include the following rules: if the component's boundary is a solid line with the same width, the electronic device can use drawing logic 1 to draw the component's boundary; if the component's boundary corners are rounded, the electronic device can use drawing logic 2 to draw the component's boundary; if the component's boundary is a dashed line, the electronic device can use drawing logic 3 to draw the component's boundary.

[0070] To address the aforementioned issues, this application provides a rendering method and an electronic device. This method can be applied to a first electronic device. The method includes: when creating a node tree of a first interface, the first electronic device can place multiple attributes of a first component into a first Modifier of the first node corresponding to the first component; upon receiving a refresh signal for the first interface, the first electronic device can traverse the node tree of the first interface; when traversing to a first node, the first electronic device can render the first component according to a first Drawable of the first Modifier, where the first Drawable is generated by the first electronic device based on multiple attributes of the first Modifier. Through the method provided by this application, the electronic device can directly generate a Drawable based on a Modifier containing multiple attributes in a node, without needing to generate a Drawable through the RSProperties attribute slot, thus improving rendering efficiency and avoiding redundant data consuming memory during the rendering process.

[0071] It should be noted that the first Drawable (also referred to as the first drawing logic) can be understood as a drawing logic (drawing rule) used to generate drawing instructions for driving the GPU of the first component. The form of the first Drawable can be, for example, code, script, etc., and this application embodiment does not limit this. In this application embodiment, in addition to multiple attributes, the first Modifier also includes a first Drawable, which is the drawing logic for the multiple attributes of the first component. In some embodiments, the first electronic device can first generate the first Drawable according to the multiple attributes included in the first Modifier, and then put the first Drawable into the first Modifier. For example, as shown... Figure 5 As shown, the Modifier contains attributes and drawing logic. There are multiple attributes, and the Modifier's drawing logic is based on the implementation method of the component corresponding to the node (i.e., the rendering method of the multiple attributes). This drawing logic is generated by the first electronic device according to the multiple attributes contained in the Modifier. For example, the declaration of the Modifier's drawing logic can be as follows:

[0072]

[0073]

[0074] In some embodiments, after generating the first Drawable, the first electronic device can generate drawing instructions for the first component that drive the GPU based on the first Drawable and send them to the GPU driver in the kernel, so that the first electronic device can render the first component corresponding to the first node based on the aforementioned drawing instructions for the GPU. The drawing instructions for the GPU (also called Drawable commands) are low-level graphics operation commands that can be used to draw the first component corresponding to the first node on the screen.

[0075] The root node of the node tree corresponds to the first interface, and the first node of the node tree corresponds to the first component of the first interface.

[0076] For example, the first electronic device can create Figure 1B The node tree shown in the user interface 1010 is a node tree that is Figure 1A The node tree shown. The control 1015 corresponding to leaf node 3 needs border drawing. The application corresponding to user interface 1010 can send the three properties BorderWidth, BorderColor, and BorderStyle, which are dependent on the Drawable for border drawing of leaf node 3, to the rendering service. (This is done during the creation process.) Figure 1A When the node tree shown is displayed, the first electronic device can use the rendering service to put the three properties of control 1015—BorderWidth, BorderColor, and BorderStyle—into the RSBorderModifier of leaf node 3. Then, upon receiving a refresh signal for user interface 1010 from the application corresponding to user interface 1010, the first electronic device can traverse the tree using the rendering service. Figure 1A The node tree shown. When traversing to leaf node 3, the first electronic device can generate a boundary drawing Drawable based on the three attributes BorderWidth, BorderColor, and BorderStyle contained in RSBorderModifier through the rendering service, and render control 1015 according to the drawing logic drawn based on the boundary.

[0077] Figure 6 An exemplary embodiment of this application illustrates a process for generating a Drawable using a Modifier that includes multiple attributes.

[0078] like Figure 6As shown, a node has one or more properties, which are contained in the Modifier carried by that node. A Modifier can include multiple properties, which are the properties that the Modifier depends on to generate the corresponding Drawable. It should be noted that the properties that the Modifier depends on to generate the corresponding Drawable can be understood as the properties that the Modifier needs to generate the corresponding Drawable. In this way, the node does not need to carry all the properties in the RSProperties property slot, avoiding the involvement of redundant data during rendering and saving memory.

[0079] In some embodiments, before placing multiple attributes of the first component into the first Modifier of the first node corresponding to the first component, the first electronic device may generate a first table based on the attributes of the first component and the dependencies between different Drawables. When creating the node tree of the first interface, the first electronic device can query the first table to place multiple attributes of the first component into the first Modifier of the first node corresponding to the first component. The first table records the dependencies between the aforementioned multiple attributes and the first Drawable generated by the first Modifier. For example, the first table may include, but is not limited to, the dependencies between attributes and Drawables of a first type, and the dependencies between attributes and Drawables of a second type. If a Drawable of a first type depends on attributes 1, 2, 3, and 4, and a Drawable of a second type depends on attributes 5 and 6, then attributes 1, 2, 3, and 4 can be included in the first Modifier, and attributes 5 and 6 can be included in the second Modifier. It should be noted that, in addition to tables, the recording format of the dependencies between attributes and Drawables of different types can also be other, and this embodiment does not limit this.

[0080] After creating the node tree of the first interface, upon receiving a refresh signal for the first interface, the first electronic device can traverse the node tree of the first interface to generate a Drawable for each node. When traversing to the first node, the first electronic device can generate a first Drawable based on multiple attributes of the first Modifier to improve the rendering efficiency of generating the Drawable. Further, the first electronic device can generate drawing instructions for the GPU driving the first component based on the first Drawable and send them to the GPU driver in the kernel. Then, the first electronic device can render the first component corresponding to the first node based on the drawing instructions for the GPU driving the first component. It should be noted that the first node can generate one or more Drawables, and this application embodiment does not limit the number of generated Drawables. It should be noted that if the first node generates multiple Drawables, the generation of these multiple Drawables is based on a fixed order specified in the code. It should be noted that the first electronic device can directly generate the first Drawable based on the first Modifier because the first Modifier, which contains multiple attributes, has the ability to generate the first Drawable; for example, the first Modifier contains multiple attributes that the generation of the first Drawable depends on. In this way, the first electronic device no longer needs to generate Drawables through the RSProperties property slot, simplifying the rendering framework. After the GPU driver in the kernel receives all the drawing instructions of the first node, the first electronic device can render the first component corresponding to the first node based on all the drawing instructions of the first node.

[0081] For example, a node is Node1, which has six properties: RSProperty1, RSProperty2, RSProperty3, RSProperty4, RSProperty5, and RSProperty6. Among these, RSProperty1, RSProperty2, RSProperty3, and RSProperty4 are properties that RSDrawable1 depends on, and these four properties correspond to RSModifier1; RSProperty5 and RSProperty6 are properties that RSDrawable2 depends on, and these two properties correspond to RSModifier2. When traversing to Node1 in the node tree, the first electronic device can generate RSDrawable1 based on the four properties RSProperty1, RSProperty2, RSProperty3, and RSProperty4 that RSDrawable1 depends on, contained in RSModifier1, and generate RSDrawable2 based on the two properties RSProperty5 and RSProperty6 that RSDrawable2 depends on, contained in RSModifier2.

[0082] In some embodiments, the first modifier may include one or more of the following: geometry modifier, background modifier, content modifier, foreground modifier, and overlay modifier. These different types of modifiers may include one or more modifiers containing multiple attributes. It should be noted that the aforementioned geometry modifier, background modifier, content modifier, foreground modifier, overlay modifier, etc., are logical classifications of modifiers, not actual execution units in the rendering process. The modifiers containing multiple attributes are the actual execution units in the rendering process. For example, geometry modifiers include geometry transformation modifiers and boundary drawing modifiers. Geometry transformation modifiers contain multiple attributes such as Bounds, Pivot, Quaternion, Scale, Translate, and Persp, while boundary drawing modifiers contain multiple attributes such as Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap. The geometry modifier is a logical classification of modifiers, while the geometric transformation modifier and the boundary drawing modifier are the actual execution units in the rendering process.

[0083] For example, the properties of the geometry modifier may include the position of the first component and / or the size of the first component (e.g., properties of affine transformations such as rotation, translation, and scaling). The position property of the first component may include one or more of the following: Pivot property and Translate property. The size property of the first component may include one or more of the following: Bounds property and Scale property. The properties of the background modifier may include the background of the first component, such as properties drawn before the content (e.g., background color, background image, etc.). The properties of the content modifier may include the content of the first component (e.g., content color, content style, etc.). The properties of the foreground modifier may include the foreground of the first component, such as properties drawn after the content is drawn (e.g., foreground color, border, etc.). The properties of the overlay modifier may include the properties of the first component drawn after the foreground is drawn (e.g., dividing lines, shadow effects, filter effects, etc.).

[0084] In some embodiments, the attributes of the first component may include common attributes, which can be attributes required by more than a preset number (e.g., 5) of different types of modifiers when generating a Drawable. The first electronic device may not place the common attributes in any individual modifier, but rather in a common class, so that modifiers requiring the common attributes can obtain them from the common class when generating a Drawable. It should be noted that a common class is a carrier for storing common attributes. Besides common classes, other carriers can also be used to store common attributes, and this embodiment does not limit this. It should also be noted that before being placed in a common class, the common attribute may be included in the modifier corresponding to that common attribute. This modifier containing the common attribute does not generate a Drawable when other modifiers generate Drawables; instead, it can move the common attribute from the modifier containing the common attribute to the common class, so that modifiers requiring the common attribute can obtain it from the common class when generating a Drawable.

[0085] In some embodiments, the first modifier contains multiple attributes that are all the attributes that the first modifier depends on to generate the first Drawable. For example, if the attributes of the first component issued by the application corresponding to the first interface do not include public attributes, then the first electronic device can directly generate the first Drawable based on all the attributes that the first Drawable depends on, which are contained in the first modifier.

[0086] Figure 7 An exemplary embodiment of this application provides a modifier containing multiple attributes.

[0087] like Figure 7As shown, an exemplary geometric modifier (i.e., RSGeometryModifier) ​​is illustrated. This geometric modifier includes, but is not limited to, RSTransformModifier, which contains at least one property. For example, it may contain five properties: Pivot, Quaternion, Scale, Translate, and Persp. The Drawable of the geometric transformation depends on these six properties: Bounds, Pivot, Quaternion, Scale, Translate, and Persp. It should be noted that the Bounds property is a public property. Most geometric modifiers require the Bounds property when generating the Drawable. Therefore, the first electronic device can avoid placing the Bounds property in any individual geometric modifier. Instead, it can place the Bounds property in the ModifierContext public class so that geometric modifiers that require the Bounds property can retrieve it from the ModifierContext public class when generating the Drawable. It should be noted that the ModifierContext public class is a container for storing the Bounds property. Besides the ModifierContext public class, other carriers can be used to store the Bounds property, and this application embodiment does not impose any restrictions on this. When traversing the nodes of the node tree, the first electronic device can directly generate a geometric transformation Drawable based on the five properties Pivot, Quaternion, Scale, Translate, and Persp contained in RSTransformModifier, as well as the Bounds property obtained by RSTransformModifier from the ModifierContext public class.

[0088] Optionally, the geometry modifier (i.e., RSGeometryModifier) ​​may also include an RSBorderModifier (not shown in the figure), which contains at least one attribute, for example, five attributes: BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap. The boundary drawing Drawable depends on these six attributes: Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap. When traversing the nodes of the node tree, the first electronic device can directly generate a boundary drawing Drawable based on the five attributes (BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap) contained in the RSBorderModifier, as well as the Bounds attribute obtained by the RSBorderModifier from the ModifierContext public class.

[0089] It should be noted that before being placed into the ModifierContext public class, the Bounds property can be included in RSBoundsModifier. This RSBoundsModifier does not generate a Drawable when other Modifiers generate Drawables; instead, it moves the Bounds property from RSBoundsModifier to the ModifierContext public class so that geometry Modifiers that require the Bounds property can retrieve it from the ModifierContext public class when generating a Drawable. Optionally, the geometry Modifier (i.e., RSGeometryModifier) ​​can also include RSBoundsModifier (not shown in the figure), which contains the Bounds property.

[0090] In one possible implementation, the component corresponding to node 1 needs to undergo geometric transformation. For example, consider the six properties Bounds, Pivot, Quaternion, Scale, Translate, and Persp that the application uses to send geometric transformations to the rendering service, which are dependent on the Drawable. Node 1 carries an RSTransformModifier, which contains the five properties Pivot, Quaternion, Scale, Translate, and Persp.

[0091] It should be noted that the Bounds property is contained in RSBoundsModifier. RSBoundsModifier does not generate a Drawable when other Modifiers generate Drawables. Instead, the Bounds property can be put into the ModifierContext public class so that geometry Modifiers that need the Bounds property can obtain the Bounds property from the ModifierContext public class when generating the Drawable of the geometric transformation.

[0092] Then, the system's main rendering thread traverses the node tree. When traversing to node 1 of the node tree, the main rendering thread can directly generate a geometric transformation Drawable based on the five properties Pivot, Quaternion, Scale, Translate, and Persp contained in RSTransformModifier, as well as the Bounds property obtained by RSTransformModifier from the ModifierContext public class.

[0093] In another possible implementation, the component corresponding to node 1 needs to perform boundary drawing. Taking the six properties Bounds, BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap that the application sends to the rendering service for boundary drawing via the Drawable as an example, node 1 carries an RSBorderModifier, which contains the five properties BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap.

[0094] It should be noted that the Bounds property is contained in RSBoundsModifier. RSBoundsModifier does not generate Drawables when other Modifiers generate Drawables. Instead, the Bounds property can be put into the ModifierContext public class so that geometry Modifiers that need the Bounds property can obtain the Bounds property from the ModifierContext public class when generating Drawables with boundary drawing.

[0095] Then, the system's main rendering thread traverses the node tree. When traversing to node 1, the main rendering thread can directly generate a boundary drawing Drawable based on the five properties of BorderWidth, BorderColor, BorderStyle, BorderDashWidth, and BorderDashGap contained in RSBorderModifier, as well as the Bounds property obtained by RSBorderModifier from the ModifierContext public class. This Drawable can include the following rules: if the component's boundary is a solid line with the same width, the first electronic device can use drawing logic 1 to draw the component's boundary; if the component's boundary corners are rounded, the first electronic device can use drawing logic 2 to draw the component's boundary; if the component's boundary is a dashed line, the first electronic device can use drawing logic 3 to draw the component's boundary.

[0096] It can be seen that, with Figure 3 Compared to generating a Drawable via the RSProperties property slot, as shown, Figure 6The advantages of generating Drawables using Modifiers with multiple attributes are as follows: Since Modifiers with multiple attributes have the ability to generate corresponding Drawables, the first electronic device can directly generate the corresponding Drawable based on the Modifier, eliminating the need to generate Drawables through RSProperties attribute slots, thus simplifying the rendering framework. Furthermore, since generating Drawables through RSProperties attribute slots is no longer necessary, the first electronic device does not need to traverse the node tree to obtain RSProperties attribute slots before generating Drawables, nor does it need to traverse all attributes in the RSProperties attribute slots to obtain the attributes that the corresponding Drawable depends on, improving the rendering efficiency of Drawable generation. Moreover, each node in the node tree only needs to carry the Modifier containing the attributes that the Drawable depends on, without carrying all attributes from the RSProperties attribute slots, thus avoiding redundant data during the rendering process and saving memory.

[0097] In some embodiments, after the GPU driver in the kernel receives all the drawing instructions from the driving GPUs of the first node, the first electronic device can render the first component corresponding to the first node based on the drawing instructions from all the driving GPUs of the first node. For example, the different drawing instructions can be arranged in the order of execution from first to last as follows: drawing instructions generated by the geometry modifier, drawing instructions generated by the background modifier, drawing instructions generated by the content modifier, drawing instructions generated by the foreground modifier, and drawing instructions generated by the overlay modifier.

[0098] The following is a detailed flowchart illustrating a rendering method provided in an embodiment of this application.

[0099] Figure 8 The specific flow of a rendering method provided in an embodiment of this application is illustrated by way of example.

[0100] like Figure 8 As shown, the method may include:

[0101] S101. When creating the node tree of the first interface, the first electronic device puts multiple attributes of the first component into the first Modifier of the first node corresponding to the first component.

[0102] In this embodiment, when creating the node tree of the first interface, the first electronic device can place multiple attributes of the first component into the first Modifier of the first node corresponding to the first component. These multiple attributes are those on which the first Modifier depends for generating the first drawing logic. It should be noted that the attributes on which the first Modifier depends for generating the first drawing logic can be understood as the attributes required by the first Modifier to generate the first drawing logic. In some embodiments, the multiple attributes included in the first Modifier are all the attributes on which the first Modifier depends for generating the first drawing logic. For example, if the attributes of the first component issued by the application corresponding to the first interface do not include common attributes, then the first electronic device can directly generate the first drawing logic based on all the attributes on which the first drawing logic depends in the first Modifier.

[0103] The root node of the node tree corresponds to the first interface, and the first node of the node tree corresponds to the first component of the first interface.

[0104] In some embodiments, before placing multiple attributes of the first component into the first Modifier of the first node corresponding to the first component, the first electronic device may generate a first table based on the attributes of the first component and the dependencies between different drawing logics. When creating the node tree of the first interface, the first electronic device can query the first table to place multiple attributes of the first component into the first Modifier of the first node corresponding to the first component. The first table records the dependencies between the aforementioned multiple attributes and the first drawing logic generated by the first Modifier. For example, the first table may include, but is not limited to, the dependencies between attributes and first-type drawing logic, and the dependencies between attributes and second-type drawing logic. If the first-type drawing logic depends on attributes 1, 2, 3, and 4, and the second-type drawing logic depends on attributes 5 and 6, then attributes 1, 2, 3, and 4 can be included in the first Modifier, and attributes 5 and 6 can be included in the second Modifier. It should be noted that, in addition to tables, the recording format of the dependencies between attributes and different types of drawing logic can also be other, and this embodiment does not limit this.

[0105] In this way, nodes do not need to carry all the properties in the RSProperties property slot, avoiding the involvement of redundant data during the rendering process and saving memory.

[0106] S102, Upon receiving a refresh signal for the first interface, the first electronic device traverses the node tree.

[0107] S103. When traversing to the first node, the first electronic device renders the first component according to the first drawing logic of the first Modifier.

[0108] In this embodiment, after creating the node tree of the first interface, upon receiving a refresh signal for the first interface, the first electronic device can traverse the node tree of the first interface to generate drawing logic for each node. When traversing to the first node, the first electronic device can generate first drawing logic based on multiple attributes of the first modifier to improve the rendering efficiency of generating the drawing logic. It should be noted that the first drawing logic (also called the first Drawable) can be understood as a drawing logic (drawing rule) used to generate drawing instructions for driving the GPU of the first component. The form of the first drawing logic can be, for example, code, script, etc., and this embodiment does not limit this. In this embodiment, in addition to multiple attributes, the first modifier also contains first drawing logic, which is the drawing logic of multiple attributes of the first component. In some embodiments, the first electronic device can first generate the first drawing logic based on the multiple attributes contained in the first modifier and put the first drawing logic into the first modifier.

[0109] It should be noted that the first node can generate one or more drawing logics, and this embodiment does not limit the number of drawing logics generated. It should also be noted that if the first node generates multiple drawing logics, the generation of these multiple drawing logics is based on a fixed order specified in the code. In this way, the first electronic device no longer needs to generate drawing logic through the RSProperties property slot, simplifying the rendering framework.

[0110] In some embodiments, the attributes of the first component may include common attributes, which can be attributes required by more than a preset number (e.g., 5) of different types of modifiers when generating drawing logic. The first electronic device may not place the common attributes in any individual modifier, but rather in a common class, so that modifiers requiring the common attributes can obtain them from the common class when generating drawing logic. It should be noted that a common class is a carrier for storing common attributes. Besides common classes, other carriers can also be used to store common attributes, and this embodiment does not limit this. It should also be noted that before being placed in a common class, the common attribute may be included in the modifier corresponding to that common attribute. This modifier containing the common attribute does not generate a Drawable when other modifiers generate drawing logic; instead, it can move the common attribute from the modifier containing the common attribute to the common class, so that modifiers requiring the common attribute can obtain it from the common class when generating drawing logic.

[0111] In some embodiments, after generating the first drawing logic, the first electronic device can generate drawing instructions for the first component that drive the GPU based on the first drawing logic and send them to the GPU driver in the kernel, so that the first electronic device can render the first component corresponding to the first node based on the drawing instructions that drive the GPU. The drawing instructions that drive the GPU (also called Drawable commands) are low-level graphics operation commands that can be used to draw (or render) the first component corresponding to the first node on the screen.

[0112] In some embodiments, after the GPU driver in the kernel receives all the drawing instructions of the first node, the first electronic device can render the first component corresponding to the first node based on all the drawing instructions of the first node.

[0113] The following is a detailed description of the structural schematic diagram of the electronic device 100 provided in the embodiments of this application.

[0114] Figure 9 An electronic device 100 provided in an embodiment of this application is illustrated by way of example.

[0115] In this embodiment, the first electronic device may be referred to as electronic device 100. Electronic device 100 may be various types of smart terminal devices including a display screen (i.e., a screen), and this embodiment does not limit the specific type of electronic device 100. For example, electronic device 100 may be a mobile phone, or it may be a mobile tablet computer, in-vehicle tablet computer, desktop computer, laptop computer, handheld computer, smartwatch, smart TV, augmented reality (AR) device, virtual reality (VR) device, etc.

[0116] like Figure 9 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a display screen 130, a sensor module 140, etc. The sensor module 140 may include, but is not limited to, a pressure sensor 140A and a touch sensor 140B.

[0117] It is understood that the structures illustrated in the embodiments of this application 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 components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0118] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, 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.

[0119] 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.

[0120] 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. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0121] 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, photos, videos, and other data can be stored on the external memory card.

[0122] Internal memory 121 can be used to store one or more computer programs, which include instructions. Processor 110 can execute the instructions stored in internal memory 121, thereby causing electronic device 100 to perform the rendering methods provided in some embodiments of this application, as well as various functional applications and data processing. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system; it may also store one or more applications (such as a gallery, contacts, etc.). The data storage area may store data created during the use of electronic device 100 (such as photos, contacts, 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.

[0123] Electronic device 100 can perform display functions, such as displaying content (e.g., components) on a screen, through a GPU, a display screen 130, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 130 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute instructions to generate or modify display information.

[0124] The display screen 130 is used to display images, videos, etc. The display screen 130 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include one or N display screens 130, where N is a positive integer greater than 1. It should be noted that a display screen can also be referred to as a screen.

[0125] Pressure sensor 140A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 140A can be disposed on display screen 130. There are many types of pressure sensors 140A, 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 140A, 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 130, electronic device 100 detects the intensity of the touch operation based on pressure sensor 140A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 140A. 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.

[0126] Touch sensor 140B, also known as a touch panel or touch-sensitive surface, can be located on display screen 130. The touch sensor 140B and display screen 130 together form a touchscreen, also called a "touchscreen." Touch sensor 140B is used to detect 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 130. In other embodiments, touch sensor 140B may also be located on the surface of electronic device 100, in a different position than display screen 130.

[0127] The software architecture diagrams provided in the embodiments of this application will be described in detail below.

[0128] Figure 10 An exemplary embodiment of the software architecture provided in this application is shown.

[0129] The electronic device provided in this application embodiment can run an operating system (OS). This operating system can be various operating systems used in the industry, such as an operating system based on OpenHarmony, like HarmonyOS; or other operating systems such as Android. TMAn operating system can refer to the iOS mobile operating system; it can also refer to various open-source operating systems or their derivatives, such as Linux OS, and other embedded operating systems; it can also refer to future new operating systems, such as artificial intelligence (AI) operating systems. An operating system is a set of interconnected system software programs that manage and control the operation of electronic devices, utilize and run hardware and software resources, and provide public services to organize user interactions. In electronic devices, the operating system connects downwards to the physical hardware layer and upwards to provide a runtime environment for application software.

[0130] An operating system typically includes a kernel layer, a middleware layer, and an application layer. The application layer includes applications, which can include system applications and third-party applications. The middleware layer includes a suite of software providing various services to application developers, or frameworks providing services such as databases, multimedia, and graphics, or capabilities such as distributed scheduling and system scaling. For example, the middleware layer may include a framework layer and / or a system service layer. The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The system service layer includes the system's core capabilities, providing services to applications through the framework layer. The kernel layer is the layer between hardware and software. The kernel layer may include hardware drivers and the operating system kernel. In addition to providing hardware drivers, the kernel layer also supports functions such as memory management and system process management.

[0131] The electronic devices we use in our daily lives come in various types and forms, and are applied in a wide range of scenarios. Therefore, based on the different forms and functions of electronic devices, different application scenarios, and different user needs, the operating systems used in these devices may also differ. The basic functions implemented by the electronic device provided in this application can be implemented using a general-purpose operating system or a dedicated operating system. To more clearly illustrate the implementation of the embodiments of this application under a specific operating system, the architecture of HarmonyOS is shown below. Those skilled in the art can deduce the implementation of the embodiments of this application under other specific operating systems, such as Android. TM Implementation under operating systems, etc.

[0132] The software architecture of electronic devices can be divided into several layers. In some embodiments, from bottom to top, these layers are: kernel layer, system service layer, framework layer, and application layer. Layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem level depending on the deployment scenario of different device forms. Each subsystem can also be tailored, added, or combined at the functional level.

[0133] Kernel layer:

[0134] The Kernel Abstraction Layer (KAL) provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral device management.

[0135] Kernel Subsystem: Supports the selection of a suitable OS kernel for different resource-constrained devices, including but not limited to Linux kernel, HarmonyOS kernel, LiteOS (Lite Operating System), etc.

[0136] Driver Subsystem: The driver framework is the foundation for the open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. The driver framework includes: display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, etc. In this embodiment, the kernel layer can provide underlying hardware drivers and memory management functions for the rendering process. Figure 10 As shown, the driver framework can be a GPU driver. In this embodiment, the GPU driver can receive drawing instructions from the rendering service of the middleware layer and perform graphics rendering operations based on the drawing instructions. Simultaneously, the kernel layer manages system memory, allocating necessary memory space for the rendering process to ensure that image data can be stored and transmitted reasonably, avoiding rendering errors caused by insufficient memory or mismanagement. Furthermore, during the rendering process, the kernel layer is responsible for handling display-related interrupts and events. When the screen needs to update its display content, such as when user operations cause interface changes or timed refreshes, the kernel can receive the corresponding interrupt signal and promptly pass the interrupt event to the upper-layer module, triggering the start or adjustment of the rendering process.

[0137] System service layer:

[0138] The system service layer comprises the core capabilities of the system, providing services to applications through the framework layer. This layer includes, but is not limited to, the following subsystems:

[0139] The system's basic capability subsystem set provides fundamental capabilities for the operation, scheduling, and migration of distributed applications across multiple devices. This set may include distributed soft bus, distributed data management, distributed task scheduling, and Ark multi-language runtime; it may also include multi-modal input subsystem, graphics subsystem, security subsystem, and AI subsystem.

[0140] Basic software service subsystem set: provides public and general software services; the basic software service subsystem set may include event notification subsystem, telephone service subsystem, multimedia subsystem, etc.

[0141] Enhanced Software Service Subsystem Set: Provides differentiated enhanced software services for different devices; the enhanced software service subsystem set may include proprietary business subsystems for smart screens, proprietary business subsystems for wearables, proprietary business subsystems for the Internet of Things (IoT), etc.

[0142] Hardware service subsystem set: Provides hardware services; the hardware service subsystem set may include location service subsystem, user IAM (Identity and Access Management) subsystem, wearable proprietary hardware service subsystem, biometric identification, IoT proprietary hardware service subsystem, etc.

[0143] Distributed task scheduling enables distributed service management (discovery, synchronization, registration, and invocation), supporting remote startup, remote invocation, remote connection, and migration of applications across devices.

[0144] Distributed data management enables data synchronization, data storage, data sharing, and data access across all scenarios and devices.

[0145] The distributed soft bus provides communication-related capabilities for seamless interconnection between multiple devices, including: Wireless Local Area Network (WLAN) service capabilities, Bluetooth service capabilities, soft bus, inter-process communication RPC (Remote Procedure Call), and StarFlash communication capabilities.

[0146] Ark Multilingual Runtime is a unified compilation runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms.

[0147] Framework layer:

[0148] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The framework layer includes: the ArkUI framework (which provides a complete infrastructure for developing the user interface (UI) of system applications, including UI functionalities such as components, layouts, animations, and interactive events, as well as a real-time interface preview tool), the user application framework, and the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities). Different devices may run different operating systems, and therefore support different APIs.

[0149] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. The HarmonyOS API includes the Audio API (audio service), Push API (push service), and Account API (account service), among others.

[0150] In this embodiment, the middleware layer provides rendering-related services and frameworks, such as a rendering service. It should be noted that, as mentioned above, the middleware layer can include a framework layer and / or a system service layer; therefore, the rendering service can belong to either the framework layer or the system service layer. The middleware layer is responsible for receiving the attributes of the components to be rendered from the application layer, parsing and converting these attributes into drawing instructions suitable for execution by the underlying hardware. For example, complex graphical objects described by the application layer, such as buttons and text boxes, are decomposed into a series of basic graphical elements, such as triangles and rectangles, and the correct position, color, and other attributes are calculated for each element. This information is then sent to the GPU driver in the kernel layer for drawing. Furthermore, the middleware layer can also calculate the graphical changes in each frame based on animation parameters defined by the application layer, such as the start frame, end frame, duration, and motion curve of the animation, and convert these changes into drawing instructions, enabling interface elements to be displayed with smooth animation effects. In addition, the middleware layer can also combine and manage multiple animations, ensuring coordinated operation between them without conflicts or anomalies. Furthermore, the middleware layer can calculate the position and size of each UI element on the screen based on the layout rules set by the application layer, such as linear layout, relative layout, and grid layout. During rendering, the middleware layer can use this layout information to draw each UI element in its corresponding position, ensuring the overall aesthetics of the interface and the accuracy of user interaction. Simultaneously, when the screen size or device orientation changes, the middleware layer can recalculate the layout and trigger corresponding rendering updates to adapt to different display scenarios.

[0151] Application layer:

[0152] Applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social networking, travel, etc.

[0153] In this embodiment, the application layer is responsible for defining the specific content of the user interface, such as the display method of interface elements like text and images. Application developers create the interface layout by writing code, adding various controls such as buttons, text boxes, and lists, and setting their attributes, such as color, font, and size. These definitions provide the raw input data for the rendering process, determining the final content displayed on the screen. Furthermore, the application layer can also handle user interactions, such as touching the screen and clicking buttons, and trigger corresponding interface updates based on these actions. When the interface data in the application layer changes, such as changes in text content due to user input, button state switching, or the addition or removal of list items due to data updates, the application layer can send a refresh signal to the system for the user interface. This refresh signal is sent to the middleware layer and kernel layer, triggering the execution of the rendering process to ensure that the interface reflects these changes in a timely manner. In addition, the application layer can also trigger interface rendering updates periodically according to its own logic, such as dynamically displaying real-time data or looping animation effects. Furthermore, the application layer is also responsible for managing the application's own resources, such as image, audio, and video files. During the rendering process, when resources need to be loaded and displayed, the application layer can retrieve the corresponding resource data from local storage or the network and send it to the middleware layer for processing and rendering. For example, when displaying an image, the application layer can send the image file path or data to the middleware layer, which will then decode the image file and convert it into a format suitable for display on the screen, before drawing it through the GPU driver in the kernel layer.

[0154] In this embodiment, the rendering service can be used to receive the structure of the node tree of the first interface and the attributes of the first component to be rendered from the application layer. After receiving the structure of the node tree of the first interface and the attributes of the first component to be rendered from the application layer, the rendering service can also create a node tree based on the structure of the node tree of the first interface and the attributes of the first component to be rendered, and put multiple attributes of the first component into the first modifier of the first node corresponding to the first component; wherein, the first node of the node tree corresponds to the first component of the first interface. The multiple attributes are attributes that the first modifier depends on for generating the first Drawable. After creating the node tree of the first interface, the rendering service can also be used to receive a refresh signal for the first interface sent by the application layer. Upon receiving the refresh signal for the first interface, the rendering service can also be used to traverse the node tree of the first interface to generate a Drawable for each node. Furthermore, when traversing to the first node of the node tree, the rendering service can also be used to directly generate the first Drawable based on the multiple attributes of the first modifier. After generating the first Drawable, the rendering service can also use it to generate drawing instructions for the first component's GPU based on the first Drawable and send them to the GPU driver in the kernel layer, so that the GPU driver in the kernel layer can render the first component corresponding to the first node based on the drawing instructions after receiving all the drawing instructions for the first node.

[0155] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps performed by the electronic device in the above method embodiments, or the steps performed by the human-computer interaction module and the computing module.

[0156] This application also provides a computer program product that, when run on a terminal device, enables the terminal device to perform the steps executed by the electronic device in the above method embodiments.

[0157] This application also provides a chip system, which includes a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the steps performed by the electronic device in any of the method embodiments of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0158] The term "user interface (UI)," or simply "interface," used in the specification and accompanying drawings of this application, refers to the medium through which an application or operating system interacts and exchanges information with the user. It facilitates the conversion between the internal form of information and a form acceptable to the user. The user interface of an application is written in source code using specific computer languages ​​such as Java or Extensible Markup Language (XML). This source code is parsed and rendered on the terminal device, ultimately presenting user-recognizable content, such as images, text, and buttons. Controls, also known as widgets, are the basic elements of the user interface. Typical controls include toolbars, menu bars, textboxes, buttons, scrollbars, images, and text. The attributes and content of controls in the interface are defined using tags or nodes, such as XML tags. <textview> 、 <imgview> 、 <videoview>Nodes define the controls contained in the interface. A node corresponds to a control or property in the interface, and after parsing and rendering, the node is presented as the content visible to the user. In addition, many applications, such as hybrid applications, often contain web pages within their interfaces. A web page, also known as a page, can be understood as a special control embedded in the application interface. Web pages are source code written in a specific computer language, such as Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript (JS), etc. Web page source code can be loaded and displayed as user-readable content by a browser or a web page display component with browser-like functionality. The specific content contained in a web page is also defined through tags or nodes in the web page source code; for example, HTML uses tags or nodes to define the content. 、 、 <video> 、 <canvas>Used to define the elements and attributes of a webpage.

[0159] The most common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be an icon, window, control, or other interface element displayed on the screen of an electronic device. Controls can include visual interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets.

[0160] 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.

[0161] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0162] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is detected" can be interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0163] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0164] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / canvas> < / video> < / videoview> < / imgview> < / textview>

Claims

1. A rendering method applied to a first electronic device, characterized in that, The method includes: When creating the node tree of the first interface, multiple attributes of the first component are placed into the first decorator Modifier of the first node corresponding to the first component; wherein, the first node of the node tree corresponds to the first component of the first interface; Upon receiving a refresh signal for the first interface, traverse the node tree; When traversing to the first node, the first component is rendered according to the first drawing logic of the first Modifier.

2. The method according to claim 1, characterized in that, The first drawing logic is generated by the first electronic device based on the plurality of attributes of the first Modifier.

3. The method according to claim 1 or 2, characterized in that, The multiple attributes are the attributes that the first Modifier depends on to generate the first drawing logic.

4. The method according to any one of claims 1-3, characterized in that, The multiple attributes are all the attributes that the first Modifier depends on to generate the first drawing logic.

5. The method according to any one of claims 1-4, characterized in that, The step of placing multiple attributes of the first component into the first decorator (Modifier) ​​of the first node corresponding to the first component specifically includes: The multiple attributes are placed into the first Modifier by querying the first table, which records the dependencies between the multiple attributes and the first drawing logic.

6. The method according to claim 5, characterized in that, Before placing multiple properties of the first component into the first decorator (Modifier) ​​of the first node corresponding to the first component, the method further includes: The first table is generated based on the attributes of the first component and the dependencies between different drawing logics.

7. The method according to any one of claims 1-6, characterized in that, The first component's properties also include a Bounds property, and the method further includes, when creating the node tree of the first interface: Place the Bounds attribute into the second Modifier of the first node; When traversing to the first node, the method further includes: Remove the Bounds property from the second Modifier.

8. The method according to claim 7, characterized in that, The first drawing logic is generated by the first electronic device based on the plurality of attributes of the first Modifier and the obtained Bounds attribute.

9. The method according to any one of claims 1-8, characterized in that, When the first modifier is a geometry modifier, the properties of the geometry modifier include the position of the first component and / or the size of the first component.

10. The method according to claim 9, characterized in that, The positional attributes of the first component include one or more of the following: The Pivot property, the Translate property, and the size property of the first component include one or more of the following: the Bounds property and the Scale property.

11. The method according to any one of claims 1-10, characterized in that, The first Modifier includes one or more of the following: geometry Modifier, background Modifier, content Modifier, foreground Modifier, and overlay Modifier.

12. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is coupled to the processor and is used to store a computer program that, when executed by the processor, causes the electronic device to perform the method as described in any one of claims 1-11.

13. A computer storage medium, characterized in that, The computer storage medium stores a computer program that, when executed by a processor, causes the electronic device to perform the method as described in any one of claims 1-11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it causes the electronic device to perform the method as described in any one of claims 1-11.