Page processing method and related equipment

By automating the manipulation of the document object model tree to identify target elements and update styles, the problem of low efficiency in manually generating skeleton screens is solved, achieving efficient and fast skeleton screen generation.

CN122019904APending Publication Date: 2026-05-12TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2024-11-11
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

In existing technologies, generating skeleton screens requires manual coding, which consumes a lot of time and effort, resulting in low development efficiency.

Method used

By acquiring the page's rendering data, manipulating the document object model tree, identifying the target element, and selecting the appropriate style from the skeleton screen styles for updating, the skeleton screen is automatically generated.

Benefits of technology

It enables efficient generation of skeleton screens, reduces the workload of developers in manually writing code, improves development efficiency, and ensures that the generated skeleton screens are consistent with the page structure.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122019904A_ABST
    Figure CN122019904A_ABST
Patent Text Reader

Abstract

The invention provides a page processing method and related equipment, and the method comprises the steps: obtaining rendering data of a page, the rendering data comprising a document object model tree; the document object model tree comprises a plurality of nodes, and each node corresponds to one element in the page; operating the document object model tree, and determining a target element in the page; determining a skeleton screen style corresponding to the element type of the target element from at least one skeleton screen style; each skeleton screen style in the at least one skeleton screen style is used for controlling presentation features of elements in the page; according to the skeleton screen style corresponding to the element type, style updating is conducted on the target element in the document object model tree, rendering information of the skeleton screen of the page is obtained, the rendering information is used for displaying the skeleton screen of the page, and the skeleton screen can be efficiently generated for the page.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to a page processing method and related equipment. Background Technology

[0002] On mobile or PC platforms, long loading times can lead to a poor user experience. Therefore, a skeleton screen is provided during the loading process to enhance interface interaction. A skeleton screen displays the basic structure of the page before all page data has loaded. Currently, generating skeleton screens primarily involves manually writing code, including page cropping and setting CSS (Cascading Style Sheets) styles, which requires a significant investment of time and effort. Summary of the Invention

[0003] This application provides a page processing method and related equipment that can efficiently generate a page skeleton screen.

[0004] On one hand, embodiments of this application provide a page processing method, which includes:

[0005] Obtain the page's rendering data, which includes the Document Object Model (DOM) tree. The DOM tree consists of multiple nodes, each corresponding to an element on the page.

[0006] Manipulate the document object model tree to determine the target element on the page;

[0007] From at least one skeleton screen style, determine the skeleton screen style corresponding to the element type of the target element; each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of elements on the page;

[0008] Based on the skeleton screen style corresponding to the element type, the style of the target element in the document object model tree is updated to obtain the rendering information of the page's skeleton screen. The rendering information is used to display the page's skeleton screen.

[0009] On one hand, embodiments of this application provide a page processing apparatus, the apparatus comprising:

[0010] The acquisition unit is used to acquire the rendering data of the page. The rendering data includes the document object model tree; the document object model tree includes multiple nodes, each node corresponding to an element on the page.

[0011] The processing unit is used to manipulate the document object model tree and determine the target element on the page.

[0012] The processing unit is also used to determine the skeleton screen style corresponding to the element type of the target element from at least one skeleton screen style; each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of elements in the page.

[0013] The processing unit is also used to update the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type, so as to obtain the rendering information of the skeleton screen of the page. The rendering information is used to display the skeleton screen of the page.

[0014] The target element is a text element. When the processing unit updates the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type to obtain the rendering information of the page's skeleton screen, it can be specifically used for:

[0015] Create a new tag inline element for the target element;

[0016] Wrap the target element in an inline element;

[0017] Add the class name of the skeleton screen style corresponding to the element type to the inline elements in order to update the style of the target elements in the document object model tree;

[0018] Based on the inline elements with the class name corresponding to the skeleton screen style of the element type, and other elements in the document object model tree, the rendering information of the page's skeleton screen is obtained.

[0019] The target element is an image element, and the skeleton screen style corresponding to the element type includes the first skeleton screen style and the second skeleton screen style.

[0020] When the processing unit updates the styles of target elements in the document object model tree according to the skeleton screen styles corresponding to the element types, and obtains the rendering information of the page's skeleton screen, it can be specifically used for:

[0021] Create a new tag inline element for the target element;

[0022] Wrap the target element in an inline element;

[0023] Add a class name for the first skeleton screen style to the inline element and a class name for the second skeleton screen style to the target element to update the style of the target element in the document object model tree.

[0024] The rendering information of the skeleton screen of the page is obtained from the inline element of the tag with the class name of the first skeleton screen style added, the target element with the class name of the first skeleton screen style added, and other elements in the document object model tree.

[0025] The first skeleton screen style is used to control the presentation characteristics of the target element as the first presentation characteristic; the second skeleton screen style is used to control the presentation characteristics of the target element as the second presentation characteristic.

[0026] Wherein, the target element is of icon type. When the processing unit updates the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type to obtain the rendering information of the page's skeleton screen, it can be specifically used for:

[0027] Add the class name of the skeleton screen style corresponding to the icon element type to the target element to update the style of the target element in the document object model tree;

[0028] Based on the target element with the class name corresponding to the skeleton screen style of the added icon element type, and other elements in the document object model tree, the rendering information of the page's skeleton screen is obtained.

[0029] The skeleton screen of the page is displayed in the target browser; when the processing unit determines the skeleton screen style corresponding to the element type of the target element from at least one skeleton screen style, it can be specifically used for:

[0030] From at least one skeleton screen style, determine one or more skeleton screen styles that are compatible with the target browser; each skeleton screen style compatible with the target browser corresponds to a different element type.

[0031] Determine the skeleton screen style corresponding to the element type of the target element from one or more skeleton screen styles compatible with the target browser.

[0032] The page is configured with a Uniform Resource Locator (URL), which the retrieval unit can specifically use to retrieve the page's rendering data:

[0033] Based on the configured route Uniform Resource Locator, obtain the page's configuration logic file;

[0034] Extract elements from the configuration logic file and construct a document object model tree based on the extracted elements;

[0035] Manipulate the Document Object Model tree in a simulated browser environment to inline external stylesheets into the page;

[0036] Filter the inline stylesheets to obtain the page rendering data.

[0037] The device is applied to the skeleton screen generation plugin, which generates rendering information for the skeleton screen on the page; the processing unit is also used for:

[0038] When the skeleton screen generation plugin detects a change in the page, it obtains the updated rendering data of the changed page.

[0039] Based on the updated rendering data, the rendering information of the skeleton screen of the page is updated to obtain the updated rendering information of the skeleton screen.

[0040] The processing unit is also used for:

[0041] Generate the skeleton screen logic file based on the skeleton screen rendering information;

[0042] Based on the output path of the skeleton screen, store the logic file of the skeleton screen; and,

[0043] If an error occurs during the generation of the skeleton screen rendering information, a prompt message will be output, indicating the error message and its location.

[0044] On one hand, embodiments of this application provide a computer device, the computer device comprising:

[0045] A processor is used to execute computer programs;

[0046] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the page processing method described above.

[0047] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is loaded by a processor and executed as described above regarding the page processing method.

[0048] On one hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions implement the above-described page processing method when executed by a processor.

[0049] In this embodiment, rendering data of the page is obtained, including a Document Object Model (DOM) tree. The DOM tree includes multiple nodes, each corresponding to an element on the page. The DOM tree is manipulated to determine the target element on the page. From at least one skeleton screen style, the skeleton screen style corresponding to the element type of the target element is determined. Each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of the elements on the page. Based on the skeleton screen style corresponding to the element type, the style of the target element in the DOM tree is updated to obtain the rendering information of the page's skeleton screen. The rendering information is used to display the page's skeleton screen. It can be seen that by manipulating the DOM tree to determine the target element on the page, and determining the corresponding skeleton screen style according to the element type of the target element, and then using the skeleton screen style corresponding to the element type to update the style of the target element in the DOM tree to obtain the rendering information of the page's skeleton screen, the page's skeleton screen can be generated efficiently and quickly without manually considering the page's structure and style. Furthermore, by updating the style of the target element in the DOM tree based only on the page's rendering data, it is possible to ensure that the generated skeleton screen is as consistent as possible with the page's structure. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1a This is a schematic diagram of a page and a skeleton screen according to an embodiment of this application;

[0052] Figure 1b An architecture diagram of a page processing system provided in this application embodiment;

[0053] Figure 2 A schematic diagram of a page processing flow provided in an embodiment of this application;

[0054] Figure 3 A flowchart illustrating a page processing method provided in an embodiment of this application;

[0055] Figure 4 A flowchart illustrating a page processing method provided in an embodiment of this application;

[0056] Figure 5 A flowchart illustrating a page processing method provided in an embodiment of this application;

[0057] Figure 6This is a schematic diagram of the structure of a page processing device provided in an embodiment of this application;

[0058] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0060] First, the relevant technical terms provided in the embodiments of this application will be explained.

[0061] I. Page and Skeleton Screen

[0062] The page can be an HTML (Hypertext Markup Language) page. This page may include at least one element, which may include text elements, image elements, icon elements, etc., and this application embodiment does not impose any limitations. Figure 1a The diagram shown is a schematic representation of a page and skeleton screen provided in an embodiment of this application. Figure 1a In this case, the page only contains text elements. The skeleton screen is a rough layout of the page displayed before the page rendering data has finished loading, for example... Figure 1a The skeleton screen shown here displays the general layout structure of the page. Once the actual page rendering data is obtained, the skeleton screen is replaced, and the actual page content is rendered. Displaying the general layout structure of the page through the skeleton screen during the page data loading process can alleviate the anxiety of users (such as users) while waiting for the page to load, making the page loading process more natural and smooth.

[0063] II. Headless Browser

[0064] A headless browser is a browser without a user interface that can run in the background, supports JavaScript execution, and can simulate object operations in the browser, such as clicking, scrolling, etc.

[0065] In this embodiment of the application, headless browser technology is used to simulate a browser accessing a page, thereby obtaining the DOM (Document Object Model) tree of the page.

[0066] III. CSS (Cascading Style Sheets)

[0067] CSS provides a style description for HTML, defining how elements on a page are displayed. In this embodiment, CSS includes page CSS styles and skeleton screen styles. Skeleton screen styles can be used to control the presentation characteristics of elements on the page, resulting in a specific skeleton screen effect. These presentation characteristics can be, for example, transparency, color, etc.

[0068] IV. webpack

[0069] Webpack is a code compilation tool with an entry point, an exit point, loaders, and plugins. It's a static module bundler for modern JavaScript applications. In this embodiment, plugin instances can be inserted into Webpack to configure a skeleton screen generation plugin, which can then automatically generate skeleton screens for the page.

[0070] This application provides a page processing solution that can automatically generate skeleton screens, reducing the workload of developers manually writing skeleton screens and achieving efficient generation of page skeleton screens. Specifically, embodiments of this application can employ headless browser technology to simulate browser access to the page, obtain the page's DOM tree, and extract key elements of the page (hereinafter referred to as target elements) by analyzing the page's DOM tree. Considering factors such as the page's structure, style, and images, the style of the target elements is updated. Based on the style-updated target elements, a pre-rendered result of the page's skeleton screen (hereinafter referred to as rendering information) can be generated. Furthermore, the generated skeleton screen rendering information can be output as an HTML file (hereinafter referred to as the skeleton screen logic file) for storage.

[0071] In some embodiments, this application provides a skeleton screen generation plugin (also known as a webpack plugin). This skeleton screen generation plugin can automatically generate skeleton screen rendering information for a page and package the generated skeleton screen rendering information into a skeleton screen logic file.

[0072] As can be seen, the embodiments of this application provide the following beneficial effects: (1) The embodiments of this application provide a skeleton screen generation algorithm, which analyzes the DOM structure of the page, extracts the key elements of the page, updates the style of the key elements, and generates the pre-rendered result of the skeleton screen of the page. This algorithm needs to consider the structure, style, images and other factors of the page, and can automatically generate skeleton screens, improve development efficiency, and effectively ensure that the generated skeleton screen can restore the layout and content of the page as much as possible. (2) The embodiments of this application can generate the rendering information of the skeleton screen and output the generated skeleton screen rendering information into the skeleton screen logic file, so that the skeleton screen can be quickly displayed when the page is loaded, improving the user experience. At the same time, the rendering information of the skeleton screen does not need to be rendered again, which reduces the server load to a certain extent and improves the performance of the website. (3) The skeleton screen plugin provided by the embodiments of this application can help developers quickly generate skeleton screens, improve development efficiency, and achieve efficient generation of skeleton screens for the page.

[0073] It should be understood that the page processing solution provided in this application can be applied to page development processes, automatic page iteration, and other processes. For example, during page development, it can improve the interactive experience. Specifically, in daily project development, there are situations where page loading times are long, causing users to face a blank screen for a period of time. To improve this poor user experience, skeleton screens can be developed for the page. However, manually creating skeleton screens requires a lot of time and effort, and each page needs to be developed separately, which undoubtedly increases the burden on developers. In this case, the skeleton screen generation plugin provided in this application can be used to quickly and automatically generate skeleton screens through simple configuration. In this way, not only can development time in the R&D process be reduced, but overall development efficiency can also be improved. For another example, during project iteration, the page interface may change with changes in requirements. At this time, it is necessary to recreate skeleton screens that match the updated page. If a manual approach is used, the previous work must be repeated, and skeleton screens must be redeveloped, which will undoubtedly waste a lot of time. However, using the skeleton generation plugin, it can intelligently and automatically regenerate the corresponding skeleton screens according to the updated interface, making the skeleton screens consistent with the actual page, thereby greatly improving development efficiency and project maintainability.

[0074] The page processing system provided in the embodiments of this application will be described in detail below.

[0075] Please see Figure 1b This is an architecture diagram of a page processing system provided in an embodiment of this application. The page processing system may include a terminal device 101 and a server 102; this application does not limit the number of terminal devices and servers, and the terminal device 101 and server 102 may be directly or indirectly connected via wired or wireless means; wherein:

[0076] Terminal device 101 can be a device used by the page developer. It can be used to display a specific page and the rendering information of its skeleton screen. A skeleton screen generation plugin can be configured on terminal device 101, allowing the generation of skeleton screens for different pages. Terminal device 101 can be a smartphone, tablet, laptop, desktop computer, smart vehicle, smart wearable device, etc.

[0077] Server 102 can provide technical services to terminal device 101. Specifically, server 102 can store page configuration logic files and page skeleton screen rendering information, etc. Server 102 can generate skeleton screens for the page. This server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0078] In some embodiments, combined with Figure 1b The diagram illustrates the page processing flow between the terminal device and the server. Please refer to [link / reference]. Figure 2 The page processing flow includes at least the following steps:

[0079] (1) Configure the skeleton screen generation plugin on terminal device 101

[0080] In this embodiment, the skeleton screen generation plugin is configured by adding a plugin instance to the webpack configuration file. This plugin instance is the skeleton screen generation plugin. When the skeleton screen generation plugin detects the page completion event (such as the ˋafter-emitˋ event) configured in the webpack configuration file, it can execute steps (2)-(3).

[0081] (2) Terminal device 101 renders the page according to the route URL (Uniform Resource Locator) through the skeleton screen generation plugin: This process mainly pre-renders the page, that is, it is achieved by const dom = awaitJSDOM.fromURL(url,{resources,}).

[0082] ① Terminal device 101 can send a network request to server 102. This network request includes a routing URL, which can be used to request the download of the configuration logic file for the page corresponding to the routing URL. The configuration logic file for this page can be HTML code. Then, server 102 can respond to the network request and return the configuration logic file for that page to terminal device 101.

[0083] ② Terminal device 101 parses the configuration logic file: After downloading, the JSDOM HTML parser is used to parse the configuration logic file and build a DOM tree. The DOM tree includes multiple nodes, each corresponding to an element on the page. These elements include, but are not limited to, text elements, image elements, icon elements, etc.

[0084] ③ Terminal device 101 executes JavaScript code to manipulate the DOM tree. When executing JavaScript code, it simulates a browser environment, providing global objects such as window and document, as well as DOM API (Application Programming Interface), event system and other functions, thereby enabling manipulation of the DOM tree.

[0085] ④ Terminal device 101 inlines external stylesheets into the page. Specifically, it inlines external stylesheets into elements on the page. By inlining external stylesheets into the page, additional HTTP requests can be reduced. This helps improve page load speed and performance.

[0086] ⑤ Terminal device 101 can filter invalid CSS: It filters inline external stylesheets to remove unnecessary CSS rules, thereby reducing the size of CSS files.

[0087] ⑥ The terminal device 101 pre-renders the page based on the constructed DOM tree, inlines the external style sheets in the page into the page, and filters invalid CSS, obtains the rendering data of the page, and outputs the rendering data as an HTML file for saving. That is, the rendering data is output as an HTML file by using const html = serialize().

[0088] (3) Terminal device 101 generates a skeleton screen based on the rendered page using a skeleton screen generation plugin. In this step, terminal device 101 can manipulate the DOM tree in the page's rendering data to generate the skeleton screen for that page. Specifically, it manipulates the DOM tree to determine the target elements on the page, which can be text elements, icon elements, image elements, etc.; and adds specific skeleton screen styles to the target elements, thereby displaying the final skeleton screen effect based on the target elements with added skeleton screen styles. Generating a skeleton screen based on the rendered page may include:

[0089] ① Add skeleton screen styles to terminal device 101: Specifically, add a style element (i.e., style element) to the page, which includes at least one skeleton screen style. These skeleton screen styles can be used to control the presentation characteristics of elements on the page, such as setting the background color to gray, setting the text color to transparent, disabling text selection and mouse events, etc.

[0090] ② Terminal device 101 operates on the DOM tree in the rendering data to determine the target element on the page, and from at least one skeleton screen style, determines the skeleton screen style corresponding to the element type of the target element. For example, if the target element is a text element, then the skeleton style corresponding to the text element can be determined to control the text element to be transparent. As another example, if the target element is an icon element, then the skeleton style corresponding to the icon element can be determined to control the icon element to be transparent and have a background color that is the target color.

[0091] ③The terminal device 101 updates the style of the target element in the DOM tree according to the skeleton screen style corresponding to the element type of the target element, so that the target element can present a skeleton screen effect according to the skeleton screen style.

[0092] ④ The terminal device 101 generates the rendering data for the skeleton screen of the page based on the target element after the style update and other elements in the DOM tree.

[0093] (4) The terminal device 101 saves the rendering data of the skeleton screen to the corresponding directory. Specifically, the rendering data of the skeleton screen can be used to generate a logical file of the skeleton screen (i.e., a skeleton screen HTML file) and saved to the corresponding directory.

[0094] As can be seen, in this embodiment, a skeleton screen generation plugin is configured to render the page based on the route URL and generate a skeleton screen based on the rendered page. By configuring the webpack plugin, skeleton screen generation can be automated, reducing the workload of developers manually writing skeleton screens and achieving efficient generation of skeleton screens for the page. This may also improve development efficiency. In addition, by rendering the page based on the route URL, the style of the target element can be updated using the corresponding skeleton screen style after the page is rendered, which can ultimately generate a skeleton screen efficiently and make the final generated skeleton screen restore the layout and content of the page as much as possible.

[0095] It should be noted that the above page processing interaction process is for illustrative purposes only and does not limit the specific execution process of the terminal device and the server. Optionally, the server 102 can render the page and generate a skeleton screen based on the rendered page, while the terminal device 101 can be used to present the rendering result of the skeleton screen and the rendering result of the page.

[0096] It is understood that the system architecture diagrams described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0097] The page processing method provided in the embodiments of this application will be described in detail below.

[0098] Please see Figure 3 This is a flowchart illustrating a page processing method provided in an embodiment of this application. The page processing method can be executed by a computer device, which can be a terminal device or a server in the aforementioned system; the page processing method may include the following steps S301-S304:

[0099] S301. Obtain the rendering data of the page. The rendering data includes the document object model tree. The document object model tree includes multiple nodes, and each node corresponds to an element on the page.

[0100] The rendering data can be the rendering result of the page. It should be understood that page elements can include image elements, icon elements, text elements, attribute elements, button elements, form elements, etc. An image element can correspond to a node in the Document Object Model (DOM) tree; the node corresponding to this image element can be called an image node. Similarly, an icon element can correspond to a node in the DOM tree; the node corresponding to this icon element can be called an icon node. Likewise, a text element can correspond to a node in the DOM tree; the node corresponding to this text element can be called a text node.

[0101] S302. Manipulate the document object model tree to determine the target element on the page.

[0102] As one implementation, step S302 may include: manipulating the document object model tree, traversing the elements on the page, and determining the target element on the page. The target element here may include, but is not limited to, text elements, image elements, icon elements, etc., and this embodiment does not impose any limitations on this.

[0103] S303. From at least one skeleton screen style, determine the skeleton screen style corresponding to the element type of the target element; each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of elements on the page.

[0104] The presentation features can include, for example, transparency, text color, element background color, etc. In other words, skeleton screen styles can include setting the background color to the target color (e.g., light gray), setting the text color to transparent, disabling text selection and mouse events, etc. In one implementation, at least one skeleton screen style can be provided in advance. Specifically, a `style` element can be added to the page, containing at least one skeleton screen style (i.e., a CSS skeleton screen style). In this application, at least one skeleton screen style can be implemented using a class. These skeleton screen styles will be applied to elements with specific class names. That is, the corresponding skeleton screen style class name interface implementation can be added to the target element to add the skeleton screen style, enabling the element to present the effect of the corresponding skeleton screen style (i.e., the presentation feature), thereby achieving the skeleton screen effect. For example, implementing at least one skeleton screen style using a class can be as follows:

[0105] .skeletion{

[0106] background:#f2f2f2; / / Background color is light gray

[0107] color:transparent!important; / / Set text color to transparent

[0108] text-decoration:none! important;

[0109] user-select:none! important;

[0110] }

[0111] .skeletionimg{

[0112] opacity:0; / / Set the opacity to 0

[0113] display:inline-block;

[0114] }

[0115] As can be seen from the above, .skeletion represents the class name of a skeleton screen style, through which the background color of the element can be controlled to be the target color (i.e., light gray), and the text color to be transparent; .Skeletionimg represents the class name of another skeleton screen style, through which the opacity of the element can be controlled to be 0.

[0116] In one implementation, each skeleton screen style corresponds to a different element type. The skeleton screen style corresponding to the element type of the target element can be determined from at least one skeleton screen style. For example, if the element type of the target element is a text element, then the skeleton style corresponding to the text element can be determined to be the skeleton screen style that controls the transparency of the text element.

[0117] In another implementation, considering the differences in browser support for skeleton screen styles, manual creation of skeleton screens requires consideration of compatibility issues, increasing the developer's workload. Therefore, in this embodiment, the specific implementation of step S303 for displaying the page's skeleton screen in the target browser can be: (1) determining one or more skeleton screen styles compatible with the target browser from at least one skeleton screen style; each skeleton screen style compatible with the target browser corresponds to a different element type. (2) determining the skeleton screen style corresponding to the element type of the target element from one or more skeleton screen styles compatible with the target browser. Through the above method, the problem of differences in browser support for skeleton screen styles is automatically handled, reducing development difficulty and effectively ensuring the compatibility of the generated skeleton screen in different browsers.

[0118] S304. Based on the skeleton screen style corresponding to the element type, update the style of the target element in the document object model tree to obtain the rendering information of the skeleton screen of the page. The rendering information is used to display the skeleton screen of the page.

[0119] For different element types, the implementation methods for updating the style of the target element in this application embodiment are different.

[0120] (1) The target element's element type is text element, meaning the target element is a text element used to display text on the page. In this case, step S304 may include: creating a new inline tag element (i.e., a span element) for the target element, wrapping the target element within the inline tag element, and adding a class name for the skeleton screen style corresponding to the element type to the inline tag element to update the style of the target element in the document object model tree; then, based on the inline tag element with the added class name for the skeleton screen style corresponding to the element type, and other elements in the document object model tree, obtaining the rendering information of the page's skeleton screen. It should be understood that adding a class name for the skeleton screen style corresponding to the element type to an inline tag element allows the node corresponding to the target element to display the corresponding skeleton screen style effect. For example, adding a class name for the skeleton screen style corresponding to the element type to an inline tag element could be `skeletion`, which would allow the text node corresponding to the text element to display the skeleton screen style effect corresponding to that `skeletion`, resulting in the text node corresponding to the text element displaying a light gray background and transparent text.

[0121] (2) The target element's element type is an icon element, meaning the target element is an icon element (i.e., the 'i' element on the page), used to display icons on the page. In this case, step S304 may include: adding a class name for the skeleton screen style corresponding to the icon element type to the target element to update the style of the target element in the document object model tree; obtaining the page's skeleton screen rendering information based on the target element with the added class name for the skeleton screen style, and other elements in the document object model tree. It should be understood that adding a class name for the skeleton screen style corresponding to the icon element type to the target element allows the corresponding node of the target element to display the skeleton screen style effect. For example, adding a class name for the skeleton screen style corresponding to the icon element type to the target element could be `skeletion`, which would allow the icon node corresponding to the icon element to display the skeleton screen style effect corresponding to `skeletion`, resulting in the node corresponding to the icon element displaying a gray background and transparent text. Adding a class name for the skeleton screen style corresponding to the icon element type to the target element can be implemented through code, i.e.:

[0122] document.querySelectorAll('i').forEach((node)=>{

[0123] node.classList.add('skeletion')

[0124] })

[0125] (3) The target element is an image element, that is, the target element is an image element (i.e., the img element in the page), which is used to display the image in the page. At this time, step S304 may include: creating a new tag inline element for the target element; wrapping the target element in the tag inline element; adding a first skeleton screen style class name to the tag inline element and adding a second skeleton screen style class name to the target element to update the style of the target element in the document object model tree; obtaining the skeleton screen rendering information of the page based on the tag inline element with the first skeleton screen style class name added, the target element with the first skeleton screen style class name added, and other elements in the document object model tree;

[0126] The first skeleton screen style controls the presentation characteristic of the target element to be the first presentation characteristic; the second skeleton screen style controls the presentation characteristic of the target element to be the second presentation characteristic. The first and second presentation characteristics are different. It should be understood that adding the class name of the first skeleton screen style to an inline element and the class name of the second skeleton screen style to the target element will make the target element display the effects of the first and second skeleton screen styles, respectively. For example, if the class name of the first skeleton screen style added to the inline element is `skeletion`, and the class name of the second skeleton screen style added to the target element is `skeletionimg`, this will make the target element display the image background with the target color (i.e., the first presentation characteristic) and the image content with 0% opacity (i.e., the second presentation characteristic), resulting in the image node corresponding to the image element displaying a gray background and transparent image content. Adding the class name of the skeleton screen style corresponding to the element type to the target element can be achieved through code, i.e.:

[0127] document.querySelectorAll('img')

[0128] .forEach((node)=>{

[0129] node.classList.add('skeletionimg')

[0130] })

[0131] }

[0132] It should be understood that there can be one or more target elements. Therefore, the styles of the corresponding target elements can be updated based on the skeleton screen styles corresponding to their element types, thus obtaining the page's skeleton screen rendering information. In some feasible implementations, the styles of target elements in the Document Object Model (DOM) tree are updated according to the skeleton screen styles corresponding to their element types, resulting in style-updated target elements. Based on these style-updated target elements, other elements in the DOM tree, and data other than the DOM tree in the rendering data, the page's skeleton screen rendering information is generated. Furthermore, updating the styles of the target elements according to their element types can be understood as pre-rendering the target elements, ultimately obtaining the page's skeleton screen rendering information.

[0133] In this embodiment, rendering data of the page is obtained, including a Document Object Model (DOM) tree. The DOM tree includes multiple nodes, each corresponding to an element on the page. The DOM tree is manipulated to determine the target element on the page. From at least one skeleton screen style, the skeleton screen style corresponding to the element type of the target element is determined. Each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of the elements on the page. Based on the skeleton screen style corresponding to the element type, the style of the target element in the DOM tree is updated to obtain the rendering information of the page's skeleton screen. The rendering information is used to display the page's skeleton screen. It can be seen that by manipulating the DOM tree to determine the target element on the page, and determining the corresponding skeleton screen style according to the element type of the target element, and then using the skeleton screen style corresponding to the element type to update the style of the target element in the DOM tree to obtain the rendering information of the page's skeleton screen, the page's skeleton screen can be generated efficiently and quickly without manually considering the page's structure and style. Furthermore, by updating the style of the target element in the DOM tree based only on the page's rendering data, it is possible to ensure that the generated skeleton screen is as consistent as possible with the page's structure.

[0134] Please see Figure 4 This is a flowchart illustrating a page processing method provided in an embodiment of this application. The page processing method can be executed by a computer device, which can be a terminal device or a server in the aforementioned system. The page processing method may include the following steps S401-S407:

[0135] S401. Obtain the page's configuration logic file based on the configured route Uniform Resource Locator.

[0136] The Uniform Resource Locator (URL) is a combination of a local URL on the computer device and a route address. The local URL can refer to the resources needed to render the page, while the route address refers to the route address corresponding to the page for which the skeleton screen needs to be generated. For example, the URL could be http: / / 127.0.0.1:5000 / cvm.

[0137] In this embodiment, before executing step S401, a resource loader needs to be defined to load external resources outside the page during the page rendering process. In this embodiment, general rules for the resource loader need to be defined to load external resources outside the page, thereby reducing rendering time and improving efficiency. The general rules for defining the resource loader are as follows:

[0138] isUseCache: boolean, / / Whether to use resource caching

[0139] cacheList:[], / / cache list

[0140] isOnlyLocal: boolean. / / Whether to only read (i.e. load) local static resources.

[0141] }

[0142] 1. Resource Caching: The defined resource loader supports resource caching. Setting this option to `true` enables resource caching. When resource caching is enabled, loaded resources are cached in the object. In subsequent resource loading requests, if the requested resource is already in the cache, the cached resource is returned directly instead of being reloaded.

[0143] 2. Load Local Static Resources Only: The defined resource loader supports loading only local static resources. This feature can be enabled by setting the `localOnly` option to `true`. When enabled, the resource's URL is checked during resource loading. If the hostname of the resource is determined from the URL (i.e., the URL in the route URL) to be different from the target hostname (127.0.0.1), the resource will not be loaded, and an empty Buffer object will be returned. If the hostname of the resource is determined from the URL to be the target hostname, the resource can be returned directly. This reduces unnecessary external resource requests and improves pre-rendering speed.

[0144] After defining the resource loader, configure the route's Uniform Resource Locator (URL) based on the combination of the URL and route address of the resource on the computer device, and execute S401. This allows the resource loader to load resources from the computer device during the rendering process, while simultaneously retrieving the page's configuration logic file.

[0145] In one implementation, retrieving the page's configuration logic file based on the configured route's Uniform Resource Locator (URL) may involve: initiating a network request (such as an HTTP request) using Node.js's built-in network request library to download the configuration logic file for the page corresponding to the URL. During this process, various network request events will be handled, such as redirection and error handling.

[0146] S402. Extract elements from the configuration logic file and construct a document object model tree based on the extracted elements.

[0147] Specifically, the configuration logic file can be parsed, elements can be extracted during the parsing process, and a DOM tree can be built based on the extracted elements. It should be understood that during the parsing of the configuration logic file, HTML tags, attributes, text content, etc., will be extracted, and a DOM tree will be built based on these HTML tags, attributes, and text content. In one implementation, the configuration logic file is HTML code, and the JSDOM HTML parser can be used to parse the configuration logic file.

[0148] S403. Manipulate the Document Object Model tree in a simulated browser environment to inline external style sheets into the page.

[0149] In this embodiment, JavaScript code can be run, and during the execution of the JavaScript code, a headless browser environment is simulated. Then, within the simulated browser environment, the Document Object Model (DOM) tree is manipulated to inline external stylesheets into the page, reducing additional HTTP requests. This helps improve page loading speed and performance. The browser environment includes, but is not limited to, providing global objects such as `window` and `document`, as well as functionalities such as the DOM API and the event system. A specific implementation of manipulating the DOM tree within the simulated browser environment to inline external stylesheets into the page can be: manipulating the DOM tree within the simulated browser environment to inline external stylesheets into corresponding elements on the page.

[0150] The implementation of inlining external styles into the page is as follows: document.querySelectorAll('link[rel="stylesheet"]').forEach((style)=>{ / / Iterate through link[[rel="stylesheet"], and find the corresponding elements of each node in the DOM tree.

[0151] const style = document.createElement('style') / / Create<style>元素

[0152] const cssText=cache[style.href].response.body.toString() / /

[0153] style.innerHTML=cssText

[0154] document.head.appendChild(style) / / 将style元素添加到HTML文档的<head>部分

[0155] })

[0156] }

[0157] S404、对内联的样式表进行过滤,得到页面的渲染数据。

[0158] 在本申请实施例中,可以对过滤无效的CSS样式,即对内联的样式表进行过滤,移除不需要的CSS规则,从而减小CSS文件的体积。

[0159] 可选地,可以延迟或异步执行配置逻辑文件中的头部脚本,头部脚本(Head-of-Document scripts)是指在HTML文档的<head>标签内部加载和执行的脚本。这些脚本通常用于执行一些初始化代码,比如设置全局变量,或者进行页面渲染前的准备工作。头部脚本的一个主要优点是它们可以在页面内容加载之前执行,这有助于提高页面的加载性能,因为它们不会阻塞DOM的构建。在一种实现过程中,可以根据配置选项,延迟(defer)或异步(async)执行头部脚本,这样可以提高渲染效率。该配置选项即用于将头部脚本设置为延迟加载或者异步加载。如异步执行头部脚本的配置实现方式如下:

[0160] document.querySelectorAll('script').forEach((script)=>{

[0161] script.setAttribute('async',”)

[0162] })

[0163] 可见,本申请实施例通过构建文档对象模型树、延迟或异步执行头部脚以及将页面中的外部样式表内联到页面等可以完成对页面的渲染,最终可以得到页面的渲染数据。

[0164] S405、操作文档对象模型树,确定页面中的目标元素;

[0165] S406、从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;

[0166] S407、根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。

[0167] 在本申请实施例中,本申请实施例可以获取页面的逻辑配置文件,并对逻辑配置文件进行解析构建DOM树,并将页面中的外部样式表内联到文档对象模型树中各个节点对应的元素;对内联的样式表进行过滤,得到页面的渲染数据,这样可以在后续进行骨架屏生成时,在页面的渲染数据基础上仅对DOM树中的目标元素进行样式更新,这样能够尽可能保障生成的骨架屏能够尽可能与页面的页面结构相同。然后从渲染数据包括的文档对象模型树中,确定页面中的目标元素;从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,可见,通过从文档对象模型树中,确定页面中的目标元素,并按照目标元素的元素类型确定目标元素对应的骨架屏样式,利用所确定的骨架屏样式对目标元素的样式进行更新,得到骨架屏的渲染信息,这样无需人工考虑页面的结构和样式,即可以高效且快速的生成页面的骨架屏,且通过预渲染的方式可以提高页面的性能,减轻服务器负载,提高对象体验。

[0168] 请参见图5,为本申请实施例提供的一种页面处理方法的流程示意图。该页面处理方法可以由计算机设备执行,该计算机设备可以是上述系统中的终端设备或者服务器,该页面处理方法可以包括如下步骤501-S508:

[0169] S501、配置骨架屏生成插件。

[0170] 在一种实现方式中,配置骨架屏插件的方式是在webpack的配置文件中添加一个插件实例,该插件实例即为骨架屏生成插件,例如:

[0171] const GeneratingSkeletonPlugin=require('generating-skeleton-plugin') / / 生成骨架屏插件

[0172] module.exports={

[0173] plugins:[

[0174] new GeneratingSkeletonPlugin({

[0175] routeList:[' / home',' / about'],指定需要生成骨架屏的路由地址

[0176] outDir:'skeleton' / / 指定骨架屏对应的HTML代码的输出目录

[0177] })]

[0179] }

[0180] 其中,本申请实施例中的骨架屏生成插件(即GeneratingSkeletonPlugin插件)可以接收关于页面的配置信息,该配置信息可以包括但不限于如下参数:

[0181] ①routeList(路由参数):指定需要生成骨架屏的路由地址。骨架屏生成插件会根据这些路由地址对应的页面的配置逻辑文件生成对应的骨架屏的逻辑文件(即HTML代码)。默认值为[ / ]。

[0182] ②outDir(目录参数):指定生成的骨架屏的逻辑文件的输出目录。骨架屏生成插件会把生成的骨架屏的逻辑文件保存到这个目录下。默认值为'. / skeleton'。

[0183] ③minify(压缩参数):指定是否需要压缩生成的骨架屏的逻辑文件。默认为true,即需要对生成的骨架屏的逻辑文件进行压缩。

[0184] S502、通过骨架屏生成插件根据配置的路由统一资源定位符,获取页面的配置逻辑文件。

[0185] 在一种实现中,通过骨架屏生成插件可以检测webpack的页面完成事件(如ˋafter-emitˋ事件);当骨架屏生成插件检测到该页面完成事件时,意味着页面的配置逻辑文件完成,可以执行生成骨架屏的动作,即执行S502-S507。其中,本申请实施例中可以通过页面完成事件的回调函数中去完成骨架屏的实现。

[0186] S503、通过骨架屏生成插件对配置逻辑文件进行元素提取,并基于所提取到的元素构建文档对象模型树。

[0187] S504、通过骨架屏生成插件在模拟的浏览器环境中操作文档对象模型树,将页面中的外部样式表内联到页面中。

[0188] S505、通过骨架屏生成插件对内联的样式表进行过滤,得到页面的渲染数据。

[0189] S506、通过骨架屏生成插件操作文档对象模型树,确定页面中的目标元素。

[0190] S507、通过骨架屏生成插件从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;

[0191] S508、通过骨架屏生成插件根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。

[0192] 其中,步骤S503-S508的具体实现方式可以参见上述相应部分的描述,在此不再赘述。

[0193] 可选地,在本申请实施例中,还可自动化更新骨架屏,随着页面的变化和更新,骨架屏的逻辑文件也会自动更新,减少了维护成本和开发者的工作量。在一种实现方式中,通过骨架屏生成插件自动监测页面的变化,如CSS样式和图片的更新等等,自动更新生成的骨架屏的逻辑文件。当骨架屏生成插件检测到页面发生变化时,则获取变化后的页面的更新渲染数据;根据更新渲染数据,对页面的骨架屏的渲染信息进行更新,得到骨架屏的更新渲染信息,并根据骨架屏的更新渲染信息对骨架屏的逻辑文件进行更新。

[0194] 可选地,本申请实施例可以存储骨架屏的逻辑文件,这样便于在页面加载时快速展示出骨架屏,提升对象体验。在一种实现方式中,根据骨架屏的渲染信息,生成骨架屏的逻辑文件;根据骨架屏的输出路径,将骨架屏的逻辑文件进行存储。

[0195] 其中,根据骨架屏的输出路径,将骨架屏的逻辑文件进行存储可以包括如下步骤(1)-步骤(3):(1)判断是否需要对骨架屏的逻辑文件进行压缩,具体的,可以根据配置信息中的压缩参数(minify选项)来确定是否需要对骨架屏的逻辑文件进行压缩,若压缩参数指示需对骨架屏的逻辑文件进行压缩,则执行步骤(2);若压缩参数指示无需对骨架屏的逻辑文件进行压缩,则执行步骤(3)。(2)若压缩参数指示需对骨架屏的逻辑文件压缩,那么可以对骨架屏的逻辑文件进行压缩,得到压缩逻辑文件,并根据骨架屏的输出路径,将压缩逻辑文件进行存储。通过压缩骨架屏的逻辑文件可以减小文件大小,从而提高网页的加载速度。作为一种实现方式,使用minify方法对骨架屏的逻辑文件进行压缩处理。(3)若压缩参数指示无需对骨架屏的逻辑文件进行压缩,那么根据骨架屏的输出路径,将骨架屏的逻辑文件进行存储。配置信息中的压缩参数为route.html=minify(html,true)。

[0196] 根据骨架屏的输出路径,将骨架屏的逻辑文件进行存储可以包括如下步骤:

[0197] 步骤1,需要计算预渲染路由的输出路径,所谓的预渲染路由是指预渲染得到骨架屏的路由地址,该预渲染路由的输出路径即为骨架屏的输出路径(outputPath)。输出路径是用于存储骨架屏的逻辑文件的位置。如果没有设置该骨架屏的输出路径outputPath,可以使用默认的路径规则(outputPath+预渲染路由+index.html)来生成输出路径。计算该骨架屏的输出路径的实现方式如下:

[0198]

[0199] 步骤2,在计算好输出路径后,需要遍历路由地址(即页面对应的路由地址),并为该路由地址创建对应的输出目录。具体的,使用mkdirp方法来确保输出目录的父级目录都存在,然后将骨架屏的逻辑文件写入至骨架屏的输出路径。在一种实现方式中,可以使用Node.js的文件系统API(fs.writeFile)来将骨架屏的逻辑文件写入至骨架屏的输出路径。其中,fs.writeFile的代码实现如下:

[0200]

[0201]

[0202] 应当理解的是,页面的数量可以为多个,那么计算每个预渲染路由的输出路径,并遍历处理过的每个路由地址,并为遍历到的每个路由地址创建对应的输出目录,然后使用Promise对象对每个页面的骨架屏的逻辑文件进行异步操作,写入至相应的输出路径。

[0203] 可选地,若在生成骨架屏的渲染信息过程中出现的错误信息,本申请实施例还可收集生成骨架屏的渲染信息过程中出现的错误信息,具体的,使用try-catch语句来处理整个过程中可能出现的错误。如果在生成骨架屏的渲染信息过程中出现错误,会捕获错误并将错误信息打印到控制台,并输出提示信息,提示信息用于提示错误信息以及错误信息出现的位置,以便于我们定位和解决问题。try-catch语句来处理整个过程中可能出现的错误可以如下:

[0204]

[0205] 综上所述,本申请实施例可以实现了对页面的骨架屏的逻辑文件的生成、压缩、存储等操作,能够为提供了更好的网页加载体验;此外,通过骨架屏生成插件可提高开发者的工作效率和体验,让开发者更专注于业务逻辑的开发。

[0206] 在本申请实施例中,可以配置骨架屏生成插件,然后通过配置骨架屏生成插件根据配置的路由统一资源定位符,获取页面的配置逻辑文件;通过配置骨架屏生成插件对配置逻辑文件进行元素提取,并基于所提取到的元素构建文档对象模型树;在模拟的浏览器环境中操作文档对象模型树,将页面中的外部样式表内联到文档对象模型树中各个节点对应的元素;通过配置骨架屏生成插件对内联的样式表进行过滤,得到页面的渲染数据。通过配置骨架屏生成插件从文档对象模型树中,确定页面中的目标元素;从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;通过配置骨架屏生成插件根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。可见,通过配置骨架屏生成插件,可以自动化生成骨架屏,减少开发者手动编写骨架屏的工作,实现高效地生成页面的骨架屏。

[0207] 接下来对本申请实施例提供的页面处理装置进行阐述。

[0208] 请参见图6,图6是本申请实施例提供的一种页面处理装置的结构示意图,该页面处理装置可以是计算机设备中的一个计算机程序(包括程序代码),例如页面处理装置可以是计算机设备中的一个应用软件;该页面处理装置可以用于执行图3-图5所示的方法实施例中的部分或全部步骤。请参见图6,该页面处理装置包括如下单元:

[0209] 获取单元601,用于获取页面的渲染数据,渲染数据包括文档对象模型树;文档对象模型树包括多个节点,每个节点对应页面中的一个元素;

[0210] 处理单元602,用于操作文档对象模型树,确定页面中的目标元素;

[0211] 处理单元602,还用于从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;

[0212] 处理单元602,还用于根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。

[0213] 其中,目标元素的元素类型为文本元素类型;处理单元602在根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息时,可具体用于:

[0214] 为目标元素创建新的标签行内元素;

[0215] 将目标元素包裹在标签行内元素中;

[0216] 为标签行内元素添加元素类型对应的骨架屏样式的类名,以实现对文档对象模型树中的目标元素的样式更新;

[0217] 根据添加了元素类型对应的骨架屏样式的类名的标签行内元素,以及文档对象模型树中的其他元素,得到页面的骨架屏的渲染信息。

[0218] 其中,目标元素的元素类型为图片元素类型,元素类型对应的骨架屏样式包括第一骨架屏样式和第二骨架屏样式;

[0219] 处理单元602在根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息时,可具体用于:

[0220] 为目标元素创建新的标签行内元素;

[0221] 将目标元素包裹在标签行内元素中;

[0222] 为标签行内元素添加第一骨架屏样式的类名,以及为目标元素添加第二骨架屏样式的类名,以实现对文档对象模型树中的目标元素的样式更新;

[0223] 根据添加了第一骨架屏样式的类名的标签行内元素、添加了第一骨架屏样式的类名的目标元素,以及文档对象模型树中的其他元素,得到页面的骨架屏的渲染信息;

[0224] 其中,第一骨架屏样式用于控制目标元素的呈现特征为第一呈现特征;第二骨架屏样式用于控制目标元素的呈现特征为第二呈现特征。

[0225] 其中,目标元素的元素类型为图标元素类型,处理单元602在根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息时,可具体用于:

[0226] 为目标元素添加图标元素类型对应的骨架屏样式的类名,以实现对文档对象模型树中的目标元素的样式更新;

[0227] 根据添加了图标元素类型对应的骨架屏样式的类名的目标元素,以及文档对象模型树中的其他元素,得到页面的骨架屏的渲染信息。

[0228] 其中,页面的骨架屏在目标浏览器中显示;处理单元602在从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式时,可具体用于:

[0229] 从至少一个骨架屏样式中,确定目标浏览器兼容的一个或多个骨架屏样式;目标浏览器兼容的各骨架屏样式分别对应不同的元素类型;

[0230] 从目标浏览器兼容的一个或多个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式。

[0231] 其中,页面配置有路由统一资源定位符,获取单元601在获取页面的渲染数据时,可具体用于:

[0232] 根据配置的路由统一资源定位符,获取页面的配置逻辑文件;

[0233] 对配置逻辑文件进行元素提取,并基于所提取到的元素构建文档对象模型树;

[0234] 在模拟的浏览器环境中操作文档对象模型树,将页面中的外部样式表内联到页面中;

[0235] 对内联的样式表进行过滤,得到页面的渲染数据。

[0236] 其中,该装置应用于骨架屏生成插件,骨架屏生成插件用于为页面生成骨架屏的渲染信息;处理单元602,还用于:

[0237] 当骨架屏生成插件检测到页面发生变化时,则获取变化后的页面的更新渲染数据;

[0238] 根据更新渲染数据,对页面的骨架屏的渲染信息进行更新,得到骨架屏的更新渲染信息。

[0239] 其中,处理单元602,还用于:

[0240] 根据骨架屏的渲染信息,生成骨架屏的逻辑文件;

[0241] 根据骨架屏的输出路径,将骨架屏的逻辑文件进行存储;以及,

[0242] 若在生成骨架屏的渲染信息过程中出现的错误信息,则输出提示信息,提示信息用于提示错误信息以及错误信息出现的位置。

[0243] 在本申请实施例中,获取页面的渲染数据,渲染数据包括文档对象模型树;文档对象模型树包括多个节点,每个节点对应页面中的一个元素;操作文档对象模型树,确定页面中的目标元素;从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。可见,通过操作文档对象模型树,确定页面中的目标元素,并按照目标元素的元素类型确定目标元素对应的骨架屏样式,进而利用根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,这样无需人工考虑页面的结构和样式,可以高效且快速的生成页面的骨架屏;此外,在页面的渲染数据基础上仅对DOM树中的目标元素进行样式更新,这样能够尽可能保障生成的骨架屏与页面的页面结构相同。

[0244] 接下来对本申请实施例提供的计算机设备进行阐述。

[0245] 进一步地,本申请实施例还提供了一种计算机设备的结构示意图,该计算机设备的结构示意图可参见图7;该计算机设备可以包括:处理器701、输入设备702,输出设备703和存储器704。上述处理器701、输入设备702、输出设备703和存储器704通过总线连接。存储器704用于存储计算机程序,计算机程序包括程序指令,处理器701用于执行存储器704存储的程序指令。

[0246] 在一个实施例中,处理器701通过运行存储器704中的程序指令,执行如下操作:

[0247] 获取页面的渲染数据,所述渲染数据包括文档对象模型树;所述文档对象模型树包括多个节点,每个节点对应所述页面中的一个元素;

[0248] 操作所述文档对象模型树,确定所述页面中的目标元素;

[0249] 从至少一个骨架屏样式中,确定所述目标元素的元素类型对应的骨架屏样式;所述至少一个骨架屏样式中的各骨架屏样式用于控制所述页面中元素的呈现特征;

[0250] 根据所述元素类型对应的骨架屏样式,对所述文档对象模型树中的目标元素进行样式更新,得到所述页面的骨架屏的渲染信息,所述渲染信息用于显示所述页面的骨架屏。

[0251] 其中,所述目标元素的元素类型为文本元素类型;处理器701在根据所述元素类型对应的骨架屏样式,对所述文档对象模型树中的目标元素进行样式更新,得到所述页面的骨架屏的渲染信息时,可具体执行如下操作:

[0252] 为所述目标元素创建新的标签行内元素;

[0253] 将所述目标元素包裹在所述标签行内元素中;

[0254] 为所述标签行内元素添加所述元素类型对应的骨架屏样式的类名,以实现对所述文档对象模型树中的所述目标元素的样式更新;

[0255] 根据添加了所述元素类型对应的骨架屏样式的类名的标签行内元素,以及所述文档对象模型树中的其他元素,得到所述页面的骨架屏的渲染信息。

[0256] 其中,所述目标元素的元素类型为图片元素类型,所述元素类型对应的骨架屏样式包括第一骨架屏样式和第二骨架屏样式;

[0257] 处理器701在根据所述元素类型对应的骨架屏样式,对所述文档对象模型树中的目标元素进行样式更新,得到所述页面的骨架屏的渲染信息时,可具体执行如下操作:

[0258] 为所述目标元素创建新的标签行内元素;

[0259] 将所述目标元素包裹在所述标签行内元素中;

[0260] 为所述标签行内元素添加所述第一骨架屏样式的类名,以及为所述目标元素添加所述第二骨架屏样式的类名,以实现对所述文档对象模型树中的所述目标元素的样式更新;

[0261] 根据添加了所述第一骨架屏样式的类名的标签行内元素、添加了所述第一骨架屏样式的类名的目标元素,以及所述文档对象模型树中的其他元素,得到所述页面的骨架屏的渲染信息;

[0262] 其中,所述第一骨架屏样式用于控制所述目标元素的呈现特征为第一呈现特征;所述第二骨架屏样式用于控制所述目标元素的呈现特征为第二呈现特征。

[0263] 其中,所述目标元素的元素类型为图标元素类型,处理器701在根据所述元素类型对应的骨架屏样式,对所述文档对象模型树中的目标元素进行样式更新,得到所述页面的骨架屏的渲染信息时,可具体执行如下操作:

[0264] 为所述目标元素添加所述图标元素类型对应的骨架屏样式的类名,以实现对所述文档对象模型树中的所述目标元素的样式更新;

[0265] 根据添加了所述图标元素类型对应的骨架屏样式的类名的目标元素,以及所述文档对象模型树中的其他元素,得到所述页面的骨架屏的渲染信息。

[0266] 其中,所述页面的骨架屏在目标浏览器中显示;处理器701在从至少一个骨架屏样式中,确定所述目标元素的元素类型对应的骨架屏样式时,可具体执行如下操作:

[0267] 从至少一个骨架屏样式中,确定所述目标浏览器兼容的一个或多个骨架屏样式;所述目标浏览器兼容的各骨架屏样式分别对应不同的元素类型;

[0268] 从所述目标浏览器兼容的一个或多个骨架屏样式中,确定所述目标元素的元素类型对应的骨架屏样式。

[0269] 其中,所述页面配置有路由统一资源定位符,处理器701在获取页面的渲染数据时,可具体执行如下操作:

[0270] 根据配置的路由统一资源定位符,获取所述页面的配置逻辑文件;

[0271] 对所述配置逻辑文件进行元素提取,并基于所提取到的元素构建所述文档对象模型树;

[0272] 在模拟的浏览器环境中操作所述文档对象模型树,将所述页面中的外部样式表内联到页面中;

[0273] 对内联的样式表进行过滤,得到所述页面的渲染数据。

[0274] 其中,处理器701,还可执行如下操作:

[0275] 当所述骨架屏生成插件检测到所述页面发生变化时,则获取变化后的页面的更新渲染数据;

[0276] 根据所述更新渲染数据,对所述页面的骨架屏的渲染信息进行更新,得到所述骨架屏的更新渲染信息。

[0277] 其中,处理器701,还可执行如下操作:

[0278] 根据所述骨架屏的渲染信息,生成所述骨架屏的逻辑文件;

[0279] 根据所述骨架屏的输出路径,将所述骨架屏的逻辑文件进行存储;以及,

[0280] 若在生成所述骨架屏的渲染信息过程中出现的错误信息,则输出提示信息,所述提示信息用于提示所述错误信息以及所述错误信息出现的位置。

[0281] 在本申请实施例中,获取页面的渲染数据,渲染数据包括文档对象模型树;文档对象模型树包括多个节点,每个节点对应页面中的一个元素;操作文档对象模型树,确定页面中的目标元素;从至少一个骨架屏样式中,确定目标元素的元素类型对应的骨架屏样式;至少一个骨架屏样式中的各骨架屏样式用于控制页面中元素的呈现特征;根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,渲染信息用于显示页面的骨架屏。可见,通过操作文档对象模型树,确定页面中的目标元素,并按照目标元素的元素类型确定目标元素对应的骨架屏样式,进而利用根据元素类型对应的骨架屏样式,对文档对象模型树中的目标元素进行样式更新,得到页面的骨架屏的渲染信息,这样无需人工考虑页面的结构和样式,可以高效且快速的生成页面的骨架屏;此外,在页面的渲染数据基础上仅对DOM树中的目标元素进行样式更新,这样能够尽可能保障生成的骨架屏与页面的页面结构相同。

[0282] 本申请实施例中,术语"单元”是指有预定功能的计算机程序或计算机程序的一部分,并与其他相关部分一起工作以实现预定目标,并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的,一个处理器(或多个处理器或存储器)可以用来实现一个或多个单元。此外,每个单元都可以是包含该单元功能的整体单元的一部分。

[0283] 此外,这里需要指出的是:本申请实施例还提供了一种计算机可读存储介质,且计算机可读存储介质中存储有计算机程序,且该计算机程序包括程序指令,当处理器执行上述程序指令时,能够执行前文图3-图5所对应实施例中的方法,因此,这里将不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节,请参照本申请方法实施例的描述。作为示例,程序指令可以被部署在一个计算机设备上,或者在位于一个地点的多个计算机设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算机设备上执行。

[0284] 根据本申请的一个方面,提供了一种计算机程序产品,该计算机程序产品包括计算机程序,该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序,处理器执行该计算机程序,使得该计算机设备可以执行前文图3-图5所对应实施例中的方法,因此,这里将不再进行赘述。

[0285] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random AccessMemory,RAM)等。

[0286] 以上所揭露的仅为本申请较佳实施例而已,当然不能以此来限定本申请之权利范围,因此依本申请权利要求所作的等同变化,仍属本申请所涵盖的范围。< / style>

Claims

1. A page processing method, characterized in that, The method includes: Obtain the rendering data of the page, the rendering data including a document object model tree; the document object model tree includes multiple nodes, each node corresponding to an element in the page; Manipulate the document object model tree to determine the target element in the page; From at least one skeleton screen style, determine the skeleton screen style corresponding to the element type of the target element; each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of the elements in the page; Based on the skeleton screen style corresponding to the element type, the style of the target element in the document object model tree is updated to obtain the rendering information of the skeleton screen of the page. The rendering information is used to display the skeleton screen of the page.

2. The method as described in claim 1, characterized in that, The target element is a text element; the process of updating the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type to obtain the rendering information of the page's skeleton screen includes: Create a new tag inline element for the target element; Wrap the target element within the tag line element; Add the class name of the skeleton screen style corresponding to the element type to the element in the tag line to update the style of the target element in the document object model tree; The rendering information of the skeleton screen of the page is obtained based on the inline element with the class name corresponding to the skeleton screen style of the element type, and other elements in the document object model tree.

3. The method as described in claim 1, characterized in that, The target element is an image element, and the skeleton screen style corresponding to the element type includes a first skeleton screen style and a second skeleton screen style. The step of updating the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type to obtain the rendering information of the skeleton screen of the page includes: Create a new tag inline element for the target element; Wrap the target element within the tag line element; Add the class name of the first skeleton screen style to the inline element of the tag, and add the class name of the second skeleton screen style to the target element, so as to update the style of the target element in the document object model tree; The rendering information of the skeleton screen of the page is obtained based on the tag inline element with the class name of the first skeleton screen style added, the target element with the class name of the first skeleton screen style added, and other elements in the document object model tree. Wherein, the first skeleton screen style is used to control the presentation feature of the target element to be a first presentation feature; the second skeleton screen style is used to control the presentation feature of the target element to be a second presentation feature.

4. The method as described in claim 1, characterized in that, The target element is of icon type. The style of the target element in the document object model tree is updated according to the skeleton screen style corresponding to the element type to obtain the rendering information of the page's skeleton screen, including: Add the class name of the skeleton screen style corresponding to the icon element type to the target element to realize the style update of the target element in the document object model tree; Based on the target element with the class name corresponding to the skeleton screen style of the icon element type, and other elements in the document object model tree, the rendering information of the skeleton screen of the page is obtained.

5. The method according to any one of claims 1-4, characterized in that, The skeleton screen of the page is displayed in the target browser; determining the skeleton screen style corresponding to the element type of the target element from at least one skeleton screen style includes: From at least one skeleton screen style, determine one or more skeleton screen styles that are compatible with the target browser; each skeleton screen style that is compatible with the target browser corresponds to a different element type. From one or more skeleton screen styles compatible with the target browser, determine the skeleton screen style corresponding to the element type of the target element.

6. The method as described in claim 1, characterized in that, The page is configured with a Uniform Resource Locator (URL), and obtaining the page's rendering data includes: Based on the configured route Uniform Resource Locator, obtain the configuration logic file of the page; Extract elements from the configuration logic file and construct the document object model tree based on the extracted elements; Manipulate the document object model tree in a simulated browser environment to inline external style sheets into the page; The inline stylesheets are filtered to obtain the rendering data for the page.

7. The method as described in claim 1, characterized in that, The method is applied to a skeleton screen generation plugin, which is used to generate skeleton screen rendering information for the page; the method further includes: When the skeleton screen generation plugin detects a change in the page, it obtains the updated rendering data of the changed page. Based on the updated rendering data, the rendering information of the skeleton screen of the page is updated to obtain the updated rendering information of the skeleton screen.

8. The method as described in claim 1, characterized in that, The method further includes: Based on the rendering information of the skeleton screen, generate the logic file of the skeleton screen; Based on the output path of the skeleton screen, the logic file of the skeleton screen is stored; and, If an error occurs during the generation of the skeleton screen's rendering information, a prompt message is output, which indicates the error and its location.

9. A page processing apparatus, characterized in that, The device includes: The acquisition unit is used to acquire the rendering data of the page, the rendering data including a document object model tree; the document object model tree includes multiple nodes, each node corresponding to an element in the page; The processing unit is used to manipulate the document object model tree to determine the target element in the page; The processing unit is further configured to determine, from at least one skeleton screen style, the skeleton screen style corresponding to the element type of the target element; each skeleton screen style in the at least one skeleton screen style is used to control the presentation characteristics of elements in the page. The processing unit is further configured to update the style of the target element in the document object model tree according to the skeleton screen style corresponding to the element type, so as to obtain the rendering information of the skeleton screen of the page, and the rendering information is used to display the skeleton screen of the page.

10. A computer device, characterized in that, include: A processor is used to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, performs the page processing method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, performs the page processing method according to any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the page processing method according to any one of claims 1-8.