A dynamic source-based page rendering method and program product

Abstract

The application provides a page rendering method and program product based on a dynamic source. By intercepting a creation request of a page container and determining complexity of page content requested by the creation request, a target source corresponding to the page container is dynamically generated based on the complexity, so that different target sources correspond to page containers with different complexity. Then, by using a mechanism that different target sources correspond to different rendering processes, the page containers with different complexity are isolated into independent rendering processes for rendering. Thus, the source, a page source identifier, is converted into an allocation basis of the rendering processes, and centralized memory occupation under a single rendering process is converted into horizontal sharing of multiple rendering processes, thereby breaking the hard upper limit of the memory of the single rendering process. Meanwhile, the execution environments of the rendering processes are independent of each other, and time-consuming operations of a certain page container no longer block other page containers, thereby fundamentally solving the memory overflow and crash and rendering blocking problems under the single-process architecture.

Description

Technical Field

[0001] This application relates to the field of page rendering, and more specifically, to a page rendering method and program product based on dynamic sources. Background Technology

[0002] With the development of computer technology, desktop application development frameworks such as Electron have emerged to meet the development needs of cross-platform desktop applications. The Electron framework includes a main process and a rendering process, and can use web technologies such as HTML, CSS, and JavaScript to build application interfaces. Building upon this, integrated development environments (IDEs) such as Theia further support embedding web page tabs (e.g., WebviewPanel) within the application interface through page container creation interfaces to host functional pages such as low-code designers, visual charts, and large forms.

[0003] However, under the above architecture, all page containers created within the application run in the same rendering process by default. On the one hand, there is a hard limit to the memory capacity of a single rendering process (approximately 4GB). When a user opens multiple complex page containers simultaneously, the memory usage of each page container accumulates continuously in the same rendering process, easily exceeding this hard limit and causing the rendering process to crash due to Out-of-Memory (OOM), which in turn leads to the application window freezing or displaying a white screen. On the other hand, page containers in the same rendering process share the same execution channel. When a page container executes time-consuming script calculations or complex page operations, it will block the entire rendering process, causing other page containers to experience stuttering and slow response. Summary of the Invention

[0004] The purpose of this application is to provide a page rendering method and program product based on dynamic sources to avoid memory overflow crashes and rendering blockages during the rendering process.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a page rendering method based on dynamic sources, including: Intercept the creation request of the page container; wherein the page container is a container used to embed and display a page within the application interface; Determine the complexity of the page content requested to be loaded by the creation request; wherein the complexity characterizes the resource consumption of the page content during the rendering process; Based on the complexity, a target source corresponding to the page container is generated; wherein, the target source represents information used to identify the source of the page content; page containers with different complexities correspond to different target sources; The page content is rendered based on the target source; different target sources correspond to different rendering processes.

[0006] Secondly, embodiments of this application provide a program product that, when executed by a processor, implements the method as described in any one of the first aspects above.

[0007] Compared to existing technologies, the page rendering method and program product based on dynamic sources provided in this application intercepts the creation request of a page container and determines the complexity of the page content requested by the creation request. Based on the complexity, it dynamically generates the target source corresponding to the page container, so that page containers with different complexities correspond to different target sources. Then, by utilizing the mechanism that different target sources correspond to different rendering processes, page containers with different complexities are isolated to independent rendering processes for rendering. Thus, the page source identifier of "source" is transformed into the basis for allocating rendering processes, and the concentrated memory occupation under a single rendering process is transformed into horizontal distribution among multiple rendering processes, breaking through the hard limit of memory of a single rendering process. At the same time, the execution environment of each rendering process is independent of each other, and the time-consuming operation of one page container no longer blocks other page containers, fundamentally solving the memory overflow crash and rendering blocking problems under the single-process architecture.

[0008] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A schematic diagram of a page rendering architecture based on dynamic sources provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a page rendering method based on a dynamic source, provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 4 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 5 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 6 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 7 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 8 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 9 A flowchart illustrating another page rendering method based on dynamic sources provided in an embodiment of the present invention; Figure 10 A swimlane diagram illustrating a page rendering method based on a dynamic source, provided in an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0012] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0015] In existing technologies, desktop applications based on the Electron framework (such as integrated development environments based on the Theia framework) typically employ a single rendering process model: all page containers created within the application through page container creation interfaces (such as createWebviewPanel) run in the same rendering process by default, and each page container shares the memory space and execution channel of that rendering process. To address the memory limitations of a single rendering process, an easily conceivable improvement is to modify the underlying code of Electron or Chromium to statically set the memory limit for a single rendering process to a higher value (e.g., 8GB or 16GB).

[0016] In summary, existing technologies have the following problems: In single-process rendering mode, the memory usage of multiple complex page containers accumulates continuously in the same rendering process, easily exceeding the hard limit of approximately 4GB of memory for a single rendering process, triggering an Out-of-Memory (OOM) crash, causing the application window to freeze or display a white screen; furthermore, page containers in the same rendering process share the same execution channel, and when one page container performs a time-consuming operation, it will block the entire rendering process, causing other page containers to stutter and become unresponsive; while statically increasing the memory limit results in a fixed limit that cannot be dynamically adjusted with system load, and will still be exceeded as the number and complexity of page containers increase, only postponing the problem and failing to fundamentally solve the issues of memory constraints and rendering blockage.

[0017] To address the aforementioned technical issues, this application offers the following improvement approach: intercepting creation requests at the page container creation entry point, performing static structure analysis on the page content before rendering execution to assess its complexity; then dynamically grouping page containers based on real-time available memory information of the system, and dynamically generating different sources for different groups; utilizing the existing mechanism in the rendering framework where "different sources correspond to different rendering processes," page containers with different complexities are assigned to independent rendering processes for rendering, thereby achieving horizontal scaling and execution isolation of rendering resources without modifying the underlying framework code.

[0018] To achieve the above design objectives, this application provides a possible implementation of a page rendering architecture based on dynamic sources. Specifically, Figure 1 A schematic diagram of a page rendering architecture based on dynamic sources provided in an embodiment of the present invention is shown below. Figure 1 The architecture includes: main process 10, interception and evaluation module 11, dynamic grouping engine 12, and rendering process pool 20.

[0019] Among them, the main process 10 is the process used in the application to manage the creation of application windows and pages. It is used to coordinate the creation and scheduling of page containers, initiate complexity assessments, maintain various mapping relationships, and update the page display interface.

[0020] The interception and evaluation module 11 is deployed on the page container creation path of the main process. It is used to intercept the creation request of the page container, determine whether the creation request is valid, record the request information of valid requests, and perform static structure parsing on the page content before rendering to determine the complexity of the page content.

[0021] The dynamic grouping engine 12 combines the system's available memory information with the complexity level of the page content to determine the target group to which the page container belongs, generates the target source corresponding to the page container based on the target group, and maintains the mapping relationship between the target source and the page container's identifier, and between the target source and the rendering process's process identifier.

[0022] The rendering process pool 20 includes multiple independent rendering processes created according to the source. Each rendering process has its own independent memory space, which is used to render the page content of the corresponding target source, and receives the page content and returns the rendering result through the communication channel with the main process.

[0023] For example, in Figure 1 In the architecture shown, the multiple rendering processes in rendering process pool 20 are organized into groups: multiple page containers in the shared group share the same source A and are rendered by the rendering process 21 corresponding to source A; the medium groups each correspond to an independent source, and the number of page containers in the group does not exceed N, such as Figure 1The two medium-sized groups shown correspond to source B and source C, respectively, and are rendered by rendering process 22 corresponding to source B and rendering process 23 corresponding to source C; each page container in the independent group corresponds to a single source, such as... Figure 1 As shown, a page container of a certain complexity level corresponds to a single source D, which is rendered independently by the rendering process 24 corresponding to source D.

[0024] Specifically, taking a typical use case as an example: a user sequentially opens 6 simple-level tabs (information page, data report page, etc.), 15 medium-complexity tabs (data dashboard, medium-sized form page, etc.), and 1 complex-level tab (low-code designer page). The 6 simple-level tabs are all assigned to a shared group, corresponding to source A (e.g., "https: / / webview-simple-1.local"), and are rendered uniformly by rendering process 21; of the 15 medium-complexity tabs, the first 10 tabs are assigned to the first medium-complexity group.

[0025] For source B (e.g., "https: / / webview-medium-1.local"), rendering is performed by rendering process 22. When the number of tabs in the first medium group reaches the threshold N=10, the subsequent 5 tabs are assigned to the second medium group.

[0026] The corresponding source C (e.g., "https: / / webview-medium-2.local") is rendered by rendering process 23; tabs with higher complexity levels are grouped into separate groups.

[0027] The corresponding source D (e.g., "https: / / webview-complex-{uuid}.local") is rendered independently by rendering process 24.

[0028] Since source A, source B, source C and source D are different from each other, the rendering framework creates independent rendering processes 21, 22, 23 and 24. Each rendering process has its own independent memory space, thus horizontally distributing the memory usage of the 22 tabs to the 4 rendering processes. Furthermore, the blocking or abnormality of any rendering process will not affect the tabs in other rendering processes.

[0029] It should be noted that the correspondence between page containers, groups, sources, and rendering processes described above is as follows: each page container is assigned to a target group, and a target group can include multiple page containers; each group corresponds to a source, page containers belonging to the same group correspond to the same source, and page containers belonging to different groups correspond to different sources; each source corresponds to a rendering process, and different sources correspond to different rendering processes. Therefore, a many-to-one indirect correspondence is formed between page containers and rendering processes through groups and sources: multiple page containers belonging to the same group are all rendered in the same rendering process corresponding to the source of that group. Specifically, in shared groups, n page containers, one source, and one rendering process form an n:1:1 correspondence; in medium-sized groups, no more than N page containers, one source, and one rendering process form at most an N:1:1 correspondence; and in independent groups, one page container, one source, and one rendering process form a 1:1:1 correspondence. Furthermore, by mapping the identifiers of storage sources and page containers, as well as the process identifiers of rendering processes and sources, it is possible to locate the corresponding source and rendering process from the page container in a forward direction, and to trace the corresponding source and page container from the rendering process in a backward direction. This provides a basis for reusing, dynamically adjusting, and reconstructing rendering processes.

[0030] Optionally, based on the above architecture, this application provides a possible implementation of a page rendering method based on dynamic sources. Specifically, Figure 2 A flowchart illustrating a page rendering method based on a dynamic source, provided in an embodiment of the present invention, is shown below. Figure 2 The method includes: Step 100: Intercept the page container creation request.

[0031] The page container is a container used to embed and display pages within the application interface.

[0032] Step 101: Determine the complexity of the page content requested to be loaded by the creation request.

[0033] Complexity represents the resource consumption of page content during the rendering process.

[0034] Step 102: Based on complexity, generate the target source corresponding to the page container.

[0035] The target source represents information used to identify the source of the page content; page containers with different complexities correspond to different target sources.

[0036] Step 103: Render page content based on the target source.

[0037] Different target sources correspond to different rendering processes.

[0038] The page rendering method based on dynamic sources provided in this invention intercepts the creation request of a page container and determines the complexity of the page content requested by the creation request. Based on the complexity, it dynamically generates the target source corresponding to the page container, so that page containers with different complexities correspond to different target sources. Then, by utilizing the mechanism that different target sources correspond to different rendering processes, page containers with different complexities are isolated to independent rendering processes for rendering. Thus, the page source identifier "source" is transformed into the basis for allocating rendering processes, and the concentrated memory occupation under a single rendering process is transformed into horizontal distribution among multiple rendering processes, breaking through the hard limit of memory of a single rendering process. At the same time, the execution environment of each rendering process is independent of each other, and the time-consuming operation of one page container no longer blocks other page containers, fundamentally solving the memory overflow crash and rendering blocking problems under the single-process architecture.

[0039] Optionally, to achieve unified control at the page container creation entry point and ensure that creation requests entering the subsequent evaluation and rendering processes are secure, reliable, and traceable, the following provides a possible implementation method for intercepting page container creation requests. Specifically, in Figure 2 On this basis, Figure 3 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 3 Step 100 includes: Step 100-1: Set up an interceptor on the page container creation path of the main process.

[0040] The main process is the process used in the application to manage the creation of application windows and pages.

[0041] Step 100-2: Monitor and capture creation requests using an interceptor.

[0042] Step 100-3: Determine if the creation request is valid.

[0043] If the request is valid, proceed to step 100-4; if invalid, reject the creation request. Optionally, record the corresponding alarm log and / or return a rejection message to the initiator. The creation request will not proceed to the subsequent complexity evaluation and rendering process.

[0044] Optionally, the validity of the creation request is determined based on at least one of the request source, target address, and request type.

[0045] For example, the system has a pre-defined security rule base, which includes a trusted source list, address access rules, and a set of legal request types. Specifically: Regarding the request source, it checks whether the plugin or module initiating the creation request is registered in the trusted source list; if not, the creation request is deemed illegitimate. Regarding the target address, it checks whether the page address requested by the creation request matches the address access rules, such as whether it falls within the allowed domain range or whether it uses a prohibited protocol type; if a prohibited rule is matched, the creation request is deemed illegitimate. Regarding the request type, it checks whether the operation type of the creation request belongs to a pre-defined type in the set of legal request types; if the request type is unidentifiable or disguised, the creation request is deemed illegitimate.

[0046] Optionally, the decision can also be based on request frequency. For example, if the number of creation requests initiated by the same request source within a preset time window exceeds a frequency threshold, the creation request is deemed invalid to prevent malicious sources from exhausting system resources by creating page containers at high frequency. The above decisions can be used individually or in any combination, and this application does not limit their use.

[0047] Step 100-4: Record the request information for the creation request.

[0048] Optionally, the request information includes at least one of the following: request timestamp, request source, request type, and target page container identifier.

[0049] Among them, the request timestamp represents the time when the creation request was initiated, which is used to determine the order of requests, perform operation auditing, and count the frequency of requests; the request source represents the identity information of the plugin or module that initiated the creation request, which is used for security auditing and issue tracing; the request type represents the type of operation requested by the creation request, which is used to distinguish different types of requests and match the corresponding processing strategies; the target page container identifier represents the unique identifier of the page container to be created, which is used to associate the page container with its complexity, target source, and rendering process in subsequent processes.

[0050] The creation request interception scheme provided in this embodiment ensures that all page container creation requests are uniformly captured and there are no side entry points by setting an interceptor on the page container creation path of the main process; it intercepts malicious or abnormal creation requests by judging their legality, preventing them from consuming subsequent evaluation resources and process resources, thereby improving system security; and it provides a data foundation for complexity assessment, security auditing, and problem tracing by recording request information.

[0051] Optionally, to quantitatively predict the resource consumption during the rendering process before page content rendering is executed, and to provide an objective basis for subsequent grouping and source generation, the following provides a possible implementation method for determining the complexity of page content. Specifically, in Figure 2 On this basis, Figure 4 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 4 Step 101 includes: Step 101-1: Perform static structure analysis on the page content to obtain multiple complexity indicators.

[0052] Among them, static structure refers to the document structure characteristics of the page content when it is not rendered; each complexity index represents the complexity of the document structure in the corresponding dimension.

[0053] For example, multiple complexity metrics include at least two of the following: total number of page tags, maximum tag nesting depth, number of inline script blocks, number of external script references, number of inline script bytes, number of canvas elements, number of embedded frames, number of media elements, number of inline style bytes, and number of custom elements.

[0054] In one optional implementation, the definitions and static data collection methods for each complexity metric are shown in the table below: Table 1. Definition of Complexity Indicators

[0055] It should be noted that the above ten complexity indicators describe the complexity of the document structure in the corresponding dimensions, such as node size, layout hierarchy, script size, graphics processing overhead, media overhead, style overhead, and framework overhead. In actual implementation, at least two of them can be selected for complexity evaluation according to the business scenario, or other indicators that can reflect the complexity of the document structure can be added on this basis. This application does not limit the specific selection of complexity indicators.

[0056] Step 101-2: Determine the complexity of the page content based on multiple complexity metrics.

[0057] For example, taking a low-code designer tab as an example, after statically parsing its HTML string, we find that the total number of page tags is 5200, the maximum tag nesting depth is 46 levels, the number of inline script blocks is 6, the number of external script references is 22, the number of inline script bytes is 180KB, the number of canvas elements is 5, the number of embedded frames is 2, the number of media elements is 38, the number of inline style bytes is 60KB, and the number of custom elements is 24. These metrics, from different dimensions such as node size, layout hierarchy, script size, and graphics overhead, characterize the complexity of the page's document structure. By summarizing and calculating these metrics (see steps 101-2a to 101-2c below for details), we can obtain a comprehensive complexity reflecting the resource consumption of the page content.

[0058] The complexity determination scheme provided in this embodiment performs static structure analysis on the page content before rendering, which can predict the resource consumption level without running the page, resulting in low evaluation overhead and avoiding the security risks caused by running pages from unknown sources. At the same time, the multi-dimensional complexity index system describes the complexity of the document structure from different perspectives, making the complexity assessment more comprehensive and objective.

[0059] Alternatively, for step 101-2, the following is a possible implementation: Step 101-2a: Normalize each complexity index to a preset value range.

[0060] The preset value range is determined based on the simple baseline value and the complexity upper limit value corresponding to each complexity index.

[0061] For example, one possible normalization configuration is shown in the table below: Table 2. Example of Normalized Configuration

[0062] Specifically, the normalized results for each complexity index are: Normalized result = (Measured value) (Simple baseline value) ÷ (Complex upper limit value) (Simple baseline value); if the measured value is lower than the simple baseline value, the normalization result is 0; if the measured value is higher than the complex upper limit value, the normalization result is 1.

[0063] Optionally, the simple baseline value and the complex upper limit value can be determined based on the statistical results of historical page samples. For example, the typical low and typical high values ​​of each indicator in the historical page samples can be used as the simple baseline value and the complex upper limit value, respectively. It should be noted that the values ​​in the table above are only one optional example, and this application does not limit the specific values ​​of the simple baseline value and the complex upper limit value.

[0064] Step 101-2b: Perform a weighted summation of the normalized complexity indicators to obtain the complexity score.

[0065] Optionally, the complexity metrics related to the script are given a higher weight than other complexity metrics. This is because: during rendering and execution, scripts undergo parsing, compilation, and execution; the objects and closures they generate reside in heap memory for extended periods, representing a major source of runtime memory and computational resource consumption. Furthermore, a significant amount of layout and style overhead in the document is often dynamically driven by the script. Practical statistics also show a strong correlation between script-related complexity metrics and the actual memory usage of the page, hence the higher weighting given to them.

[0066] Step 101-2c: Determine the complexity of the page content based on the complexity score.

[0067] Optionally, step 101-2c can be implemented as follows: determine the target rating interval to which the complexity score belongs; where different rating intervals correspond to different complexity levels. Then, the complexity level corresponding to the target rating interval is determined as the complexity of the page content.

[0068] For example, using the low-code designer tab example above, we pre-configure simple baseline values ​​and complexity upper limits for various complexity metrics. The simple baseline value for the total number of page tabs is 200, and the complexity upper limit is 3000. The simple baseline value for the number of inline script bytes is 5KB, and the complexity upper limit is 200KB.

[0069] Furthermore, each indicator was normalized to the [0,1] range according to its simple baseline value and complex upper limit value: the total number of page tags of 5200 exceeded the complex upper limit value, and the normalization result was 1; the normalization result of the inline script bytes of 180KB was approximately 0.90.

[0070] The normalized metrics are weighted and summed. The number of inline script bytes has the highest weight (e.g., 0.22), followed by the number of canvas elements (e.g., 0.14), and the number of external script references has a weight of 0.12. The weights of the remaining metrics are configured sequentially, and the sum of all weights is 1. The resulting weighted sum gives a complexity score of 0.83. Furthermore, the preset score range [0, 0.3) corresponds to the simple level, (0.3, 0.6] to the medium level, and (0.6, 1] to the complex level. Since the complexity score of this tab, 0.83, falls within the range (0.6, 1], its complexity is determined to be at the complex level.

[0071] The scoring and grading scheme provided in this embodiment eliminates the dimensional differences between various complexity indicators through normalization, enabling indicators of different dimensions to be compared and summarized; it highlights the role of strong predictive factors such as script-related indicators through weighted summation, thereby improving the accuracy of complexity assessment; and it maps continuous complexity scores to discrete complexity levels through scoring intervals, allowing the assessment results to be directly matched with the corresponding grouping strategy, thus balancing assessment accuracy and execution efficiency.

[0072] Optionally, to combine the system's real-time memory status with the complexity level of the page content and allocate appropriate groups to the page container, thereby achieving on-demand allocation and dynamic scaling of rendering process resources, the following provides a possible implementation method for generating the target source corresponding to the page container. Specifically, in Figure 2 On this basis, Figure 5 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 5 Step 102 includes: Step 102-1: Obtain the available memory information of the system.

[0073] Step 102-2: Based on available memory information and complexity level, determine the target group to which the page container belongs.

[0074] Page containers belonging to the same group correspond to the same source, while page containers belonging to different groups correspond to different sources.

[0075] For example, if a user opens tab A (data report page) and tab B (information dashboard page) in succession, after evaluation, both are determined to be of simple complexity, and the system currently has sufficient memory, tab A and tab B are assigned to the same shared group. This shared group is associated with the source "https: / / webview-simple-1.local". Therefore, both tab A and tab B correspond to this source and are rendered by the same rendering process, sharing the memory space of this rendering process.

[0076] Subsequently, the user opens tab C (the 3D model editing page). After evaluation, its complexity is determined to be at a high level (complex). Tab C is then placed in a separate group, corresponding to the source "https: / / webview-complex-1.local", and rendered by a separate rendering process independent of tabs A and B. Thus, tabs of similar complexity share a rendering process to improve memory utilization, while more complex tabs occupy independent rendering processes to ensure isolation.

[0077] Step 102-3: Based on the target group, generate the target source corresponding to the page container.

[0078] The target source generation scheme provided in this embodiment introduces the available memory information of the system, enabling the grouping strategy to dynamically scale with changes in system load, avoiding excessive creation of rendering processes when memory is tight and insufficient utilization of process resources when memory is ample; through the corresponding rules of same source in the same group and different source in different groups, the grouping decision can be directly transformed into aggregation and isolation at the rendering process level, realizing simple tab aggregation to save resources and complex tab independence to ensure isolation.

[0079] Optionally, the complexity level is determined based on the scoring interval to which the complexity score belongs; different scoring intervals correspond to different complexity levels. Furthermore, different complexity levels can correspond to different groupings. The following provides a possible implementation method for step 102-2: Step 102-2a: When the complexity level is simple, assign the page container to the shared group.

[0080] In this shared group, multiple page containers share the same source.

[0081] Step 102-2b: When the complexity level is medium, assign the page container to the medium group.

[0082] Each intermediate group corresponds to an independent source, and the number of page containers within each intermediate group does not exceed N, where N is a positive integer.

[0083] Step 102-2c: When the complexity level is complex, assign the page container to an independent group.

[0084] Each page container in the independent group corresponds to a separate source.

[0085] The grouping scheme provided in this embodiment divides page containers into shared groups, medium groups, or independent groups according to their complexity level. This allows page containers with low resource consumption to aggregate shared rendering processes, while page containers with high resource consumption to exclusively use rendering processes. This achieves a balance between memory utilization and isolation granularity, providing a direct basis for differentiated source generation and process allocation.

[0086] Alternatively, for step 102-3, the following is a possible implementation: Step 102-3a: Count the number of page containers that are associated with the same source within the target group. Step 102-3b: If the quantity does not reach the quantity threshold corresponding to the target group, the same source is identified as the target source.

[0087] Optionally, the target source includes at least a protocol field and a domain field; wherein the domain field contains a group identifier prefix corresponding to the target group; the group identifier prefixes corresponding to page containers belonging to different groups are different.

[0088] Step 102-3c: When the quantity reaches the quantity threshold, generate a new source as the target source.

[0089] Among them, the higher the complexity level of the group, the smaller the corresponding number threshold.

[0090] For example, the preset quantity thresholds for complex, medium, and simple groups are 5, 10, and 20, respectively, thus reflecting that the higher the complexity level of the group, the smaller the quantity threshold.

[0091] The source "https: / / webview-complex-1.local" within the current complex group is associated with four page containers. When a new complexity level tab arrives, the number of page containers associated with the same source within its target group is counted as four, which is less than the threshold of five. Therefore, the same source "https: / / webview-complex-1.local" is determined as the target source for this tab, and this tab reuses the same rendering process as the previous four tabs. When another complexity level tab arrives, the count is five, reaching the threshold. Therefore, a new source "https: / / webview-complex-2.local" is generated as the target source for this tab, and this tab will be rendered in a newly created rendering process.

[0092] For example, the threshold for the number of simple groups is 20. When the number of page containers in a group that are already associated with the same source "https: / / webview-simple-1.local" reaches 20, newly arriving simple-level tabs will correspond to a newly generated source "https: / / webview-simple-2.local". Thus, more complex tabs occupy less rendering time with a smaller aggregation scale, achieving a balance between memory utilization and isolation effect.

[0093] Optionally, to translate the grouping and source generation decisions into actual process isolation rendering and ensure efficient data flow between the main process and each rendering process, the following provides a possible implementation method for establishing a mapping relationship between the target source and the page container. Specifically, in Figure 2 On this basis, Figure 6 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 6 Step 103 includes: Step 103-1: Determine the target rendering process corresponding to the target source.

[0094] Optionally, if the target source does not have a corresponding rendering process, a target rendering process corresponding to the target source may be created.

[0095] Step 103-2: Establish a communication channel between the main process and the target rendering process.

[0096] Step 103-3: Send the page content to the target rendering process for rendering via the communication channel.

[0097] Step 103-4: Receive the rendering results returned by the target rendering process through the communication channel, and update the display interface of the page container based on the rendering results.

[0098] Step 103-5: Establish and store the mapping relationship between the process identifier of the target rendering process and the target source.

[0099] The rendering scheme provided in this embodiment determines or creates independent rendering processes based on the target source, so that each rendering process has its own independent memory space. This transforms the concentrated memory occupation under a single process into horizontal distribution across multiple processes, achieving horizontal expansion of memory resources and mutual isolation of the execution environment. Through a bidirectional communication channel, reliable transmission of page content and rendering results between the main process and the rendering process is guaranteed. By storing the mapping relationship between process identifiers and target sources, the reuse lookup and lifecycle management of rendering processes are facilitated.

[0100] Optionally, to persist the mapping between the target source and the page container, so that subsequent rendering, refreshing, and dynamic adjustments of the page container can quickly locate its corresponding target source, the following provides a possible implementation method for maintaining the mapping relationship between the target source and the page container. Specifically, in Figure 2 On this basis, Figure 7 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 7 Following step 103, the following is also included: Step 104: Establish the mapping relationship between the target source and the page container's identifier. Step 105: Store the mapping relationship.

[0101] The mapping relationship is used to determine the target source corresponding to the page container when rendering page content.

[0102] The mapping maintenance scheme provided in this embodiment establishes and stores the mapping relationship between the target source and the identifier of the page container, so that the page container can quickly locate its corresponding target source without re-performing complexity evaluation during subsequent rendering and refreshing, reducing the overhead of repeated calculations; at the same time, the mapping relationship provides a query basis for dynamic adjustment during operation and process reconstruction in case of anomalies.

[0103] Optionally, to address changes in resource consumption during page container runtime and enable dynamic adjustments to the rendering process allocation strategy based on actual load, a possible implementation of re-rendering is provided below. Specifically, in Figure 2 On this basis, Figure 8 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 8 Following step 103, the following is also included: Step 106: Monitor the resource usage information of the running page container.

[0104] Step 107: If the resource usage information meets the preset adjustment conditions, redetermine the target source corresponding to the page container.

[0105] Step 108: Migrate the page content of the page container to the rendering process corresponding to the newly determined target source for rendering.

[0106] Optionally, in order to quickly restore the rendering capability of the corresponding page container when an individual rendering process encounters a runtime exception, and to prevent the exception from spreading to other page containers, the following provides a possible implementation method for rebuilding the rendering process. Specifically, in Figure 2 On this basis, Figure 9 A flowchart illustrating another page rendering method based on dynamic sources provided in this embodiment of the invention is shown below. Figure 9 Following step 103, the following is also included: Step 109: If the rendering process corresponding to the target source is running abnormally, rebuild the rendering process corresponding to the target source.

[0107] Optionally, the rendering processes for other sources are unaffected by the runtime anomaly.

[0108] For example, rendering process malfunctions include process crashes and unresponsiveness. Specifically, a script in a certain complexity tab might get stuck in an infinite loop, causing its rendering process to maintain high processor usage. The main process, through a heartbeat detection mechanism, detects that the rendering process is unresponsive within a preset time and determines it to be malfunctioning. Alternatively, a rendering process might crash due to excessive memory usage and exit unexpectedly. The main process detects this exit and determines it to be malfunctioning. In these cases, the system determines the target source corresponding to the malfunctioning rendering process based on the mapping relationship between process identifiers and target sources. Only the rendering process corresponding to that target source is rebuilt, and the page content is resent through the communication channel to restore the rendering of the corresponding tab. Rendering processes corresponding to other target sources operate normally, and only the malfunctioning tab on the display undergoes a brief reloading; the display and interaction of other tabs remain unaffected.

[0109] The process reconstruction scheme provided in this embodiment isolates runtime anomalies at the granularity of a single rendering process. An abnormal rendering process will not drag down other rendering processes or the overall application, avoiding the problem of "one tab crashing, the entire application freezing or displaying a white screen" under a single-process architecture. At the same time, by reconstructing the rendering process according to the target source, the faulty tab can automatically resume rendering, taking into account both system stability and user experience.

[0110] Optionally, to present a comprehensive overview of the entire process—including the main process, interception and evaluation module, dynamic grouping engine, and rendering process pool—collaborating to create page containers, assess complexity, dynamically group, generate sources, and isolate rendering, a complete implementation example is provided below. Specifically, Figure 10 A swimlane diagram illustrating a page rendering method based on a dynamic source provided in an embodiment of the present invention is shown below. Figure 10 The process includes: Step 200: User operation generates creation request.

[0111] Step 201: Intercept the page container creation request.

[0112] Step 202: Determine the complexity of the page content requested to be loaded by the creation request.

[0113] Step 203: Determine the complexity level.

[0114] If the complexity level is simple, proceed to step 204; if the complexity level is medium, proceed to step 205; if the complexity level is complex, proceed to step 206.

[0115] Step 204: Assign the page container to the shared group.

[0116] Step 205: Assign the page container to the medium group.

[0117] Step 206: Assign the page container to a separate group.

[0118] Step 207: Based on complexity, generate the target source corresponding to the page container.

[0119] Step 208: Create a corresponding rendering process based on the target source and perform rendering.

[0120] Step 209: Receive the rendering result and update the display interface of the page container.

[0121] For example, taking an integrated development environment based on the Theia framework and the Electron framework as an example: In this integrated development environment, the user opens a low-code designer tab through a plugin, triggering the call to the createWebviewPanel interface, thereby generating a creation request for creating WebviewPanel (as in step 200 of the example above).

[0122] An interceptor (a middleware developed based on Node.js) deployed on the page container creation path of the Electron main process captures the createWebviewPanel call request, determines whether the request source, target address and request type of the call request are valid, and records the request timestamp, request source, request type and target WebviewPanel identifier if valid (as in step 201 of the example above).

[0123] Next, the original HTML string corresponding to the Panel is obtained, and the DomParser is used to parse its static structure. Multiple complexity indicators such as the total number of page tags, the number of inline script bytes, and the number of canvas elements are extracted. After normalization and weighted summation, a complexity score of 0.83 is obtained, and its complexity level is determined to be complex (as in steps 202 and 203 of the example above). Therefore, step 206 is executed to assign the Panel to an independent group.

[0124] Then, the dynamic grouping engine obtains the available memory information of the system through the Electron API, determines the dynamic grouping strategy in combination with the complexity level, generates the source "https: / / webview-complex-{uuid}.local" (where {uuid} is the unique identifier of the Panel) for the Panel, and stores the mapping relationship between the source and the identifier of the Panel (as in step 207 of the example above).

[0125] Then, Electron automatically creates an independent rendering process based on the source (as in step 208 of the example above). This rendering process has its own 4GB memory space. The system establishes a mapping relationship between the process ID of the rendering process and the source and stores it in the database. At the same time, a child process is created through the child_process module of Node.js and a bidirectional process communication pipe is set up. The main process sends the HTML content, CSS styles and JavaScript code of the Panel to the rendering process for rendering through the communication pipe.

[0126] After rendering is complete, the rendering process returns the rendering result to the main process through the communication pipe. The main process then updates the display interface of the WebviewPanel tab based on the rendering result (as in step 209 of the example above).

[0127] Correspondingly, if the user opens a simple-level information panel with a complexity score below 0.3, then step 204 as described in the example above is executed, assigning the panel to a shared group with the corresponding source "https: / / webview-simple.local", sharing the same rendering process with other simple-level panels; if the user opens a medium-level data dashboard panel, then step 205 is executed, assigning the panel to a medium-level group with the corresponding source "https: / / webview-medium-{id}.local" (where {id} is the group identifier), and no more than N panels within the same medium-level group reuse the same rendering process.

[0128] The complete process provided in this embodiment connects the interception and evaluation of createWebviewPanel call requests, memory-aware dynamic grouping, dynamic generation of sources, and source-based isolated rendering into an automated closed loop, enabling the splitting and isolation of the rendering process to be completed automatically without manual intervention. By combining complexity-level decision-making with dynamic grouping strategies, the allocation results of simple-level Panel aggregation and sharing, and complex-level Panel independent isolation are automatically adapted to the business load. Finally, different sources force the rendering framework to isolate the processes, and each WebviewPanel runs in an independent rendering process, thus achieving horizontal scaling of memory resources and complete isolation of rendering blocking as a whole.

[0129] This invention also provides an electronic device that can execute all the steps of the examples described above to achieve the corresponding technical effects. Specifically, Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 11 The electronic device 30 includes: a memory 301 and a processor 300; Memory 301 is used to store one or more programs; Processor 300; When one or more programs are executed by a processor, the electronic device 30 can achieve the steps and corresponding technical effects when it performs the steps shown in the above-described method examples.

[0130] In the embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can also be implemented in other ways. The electronic device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of electronic devices, methods, and program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0131] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0132] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a program product. This program product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

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

[0134] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A page rendering method based on dynamic sources, characterized in that, include: Intercept the creation request of the page container; wherein the page container is a container used to embed and display a page within the application interface; Determine the complexity of the page content requested to be loaded by the creation request; wherein the complexity characterizes the resource consumption of the page content during the rendering process; Based on the complexity, a target source corresponding to the page container is generated; wherein, the target source represents information used to identify the source of the page content; page containers with different complexities correspond to different target sources; The page content is rendered based on the target source; different target sources correspond to different rendering processes.

2. The method according to claim 1, characterized in that, The steps for intercepting the creation request of the page container include: Set an interceptor on the page container creation path of the main process; wherein, the main process is the process in the application used to manage the creation of application windows and pages; The interceptor monitors and captures the creation request. Determine whether the creation request is valid; If the creation request is valid, then the request information of the creation request is recorded.

3. The method according to claim 1, characterized in that, The step of determining the complexity of the page content requested to be loaded by the creation request includes: The page content is statically structured to obtain multiple complexity metrics; wherein, the static structure is the document structure feature of the page content when it is not rendered; each complexity metric represents the complexity of the document structure in the corresponding dimension. The complexity of the page content is determined based on several of the aforementioned complexity metrics.

4. The method according to claim 3, characterized in that, The step of determining the complexity of the page content based on multiple complexity metrics includes: Each of the aforementioned complexity indicators is normalized to a preset value range; wherein, the preset value range is determined based on the simple baseline value and the complexity upper limit value corresponding to each of the aforementioned complexity indicators; The complexity score is obtained by weighted summation of the normalized complexity metrics. The complexity of the page content is determined based on the complexity score.

5. The method according to claim 1, characterized in that, The step of generating the target source corresponding to the page container based on the complexity includes: Obtain the system's available memory information; Based on the available memory information and complexity level, determine the target group to which the page container belongs; Based on the target group, the target source corresponding to the page container is generated.

6. The method according to claim 5, characterized in that, The step of determining the target group to which the page container belongs based on the available memory information and complexity level includes: When the complexity level is simple, the page container is assigned to a shared group; wherein multiple page containers in the shared group share the same source; When the complexity level is medium, the page containers are assigned to medium groups; wherein each medium group corresponds to an independent source, and the number of page containers in each medium group does not exceed N, where N is a positive integer; When the complexity level is complex, the page container is assigned to an independent group; wherein each page container in the independent group corresponds to a single source.

7. The method according to claim 5, characterized in that, The step of generating the target source corresponding to the page container based on the target group includes: Count the number of page containers that are associated with the same source within the target group; If the number does not reach the number threshold corresponding to the target group, the same source is identified as the target source; When the number reaches the specified threshold, a new source is generated as the target source; wherein, the higher the complexity level of the group, the smaller the corresponding quantity threshold.

8. The method according to claim 1, characterized in that, The step of rendering the page content based on the target source includes: Determine the target rendering process corresponding to the target source; Establish a communication channel between the main process and the target rendering process; The page content is sent to the target rendering process for rendering via the communication channel. The rendering result returned by the target rendering process is received through the communication channel, and the display interface of the page container is updated based on the rendering result; Establish and store the mapping relationship between the process identifier of the target rendering process and the target source.

9. The method according to claim 1, characterized in that, Following the step of rendering the page content based on the target source, the method further includes: Monitor the resource usage information of running page containers; If the resource usage information meets the preset adjustment conditions, the target source corresponding to the page container is re-determined; The page content of the page container is migrated to the rendering process corresponding to the newly determined target source for rendering.

10. A program product, characterized in that, When the program product is executed by the processor, it implements the method as described in any one of claims 1-9.

Images