Selectron-based application window switching method and device, equipment and medium

Abstract

The invention relates to a selection-based application window switching method and device, equipment and a medium, and the selection-based application window switching method comprises the steps: creating a preset number of standby windows, when a window switching instruction is received, destroying a current display window, creating a new standby window, selecting the standby window corresponding to the window switching instruction as a target window, and switching the target window according to the selected standby window. Loading a lightweight blank page or a skeleton screen in the target window for initial placeholder display; and asynchronously loading the service resources of the target window based on a routing mechanism, and rendering the service resources into the target window, thereby taking the rendered target window as a new current display window. When an Electron application is started, a group of standby windows are pre-created and kept in a hidden state, and existing window resources can be directly reused when a user triggers window switching, so that the initialization time consumption and resource overhead required by newly creating the window are remarkably reduced, the overall response efficiency of window switching is improved, and the system memory occupation is effectively reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of electron application window switching, and in particular to a method, device, equipment and medium for electron application window switching. Background Art

[0002] Currently, in the existing Electron application development, page switching is usually divided into two forms: window switching and routing switching. Among them, the Electron application is an open-source framework for developing cross-platform desktop applications, allowing the use of web technologies such as JavaScript, HTML, and CSS to build applications. Window switching is generally used for isolated display between multiple business scenarios or functional modules, while routing switching is often used for sub-page jumping within a single window. In traditional technical implementations, as Figure 7 shown, window switching is usually achieved by creating new windows in real time and loading corresponding static page resources. However, this method has obvious technical drawbacks. On the one hand, frequent window creation will cause a large number of active windows to exist simultaneously in the system, occupying too many system resources and easily causing memory leakage problems, especially in scenarios where pages are frequently jumped. On the other hand, after each window is newly created, it is necessary to reload the static page content, resulting in a long overall loading time and high response latency, seriously affecting the user experience. Summary of the Invention

[0003] In order to solve the problems that traditional Electron applications are prone to high system resource occupation, serious memory leakage, and slow page loading during frequent window switching, the present application provides a method, device, equipment and medium for electron application window switching.

[0004] A method for electron application window switching, the method for electron application window switching includes: When the electron application starts, create a preset number of standby windows, and the standby windows are window instances in a hidden state; When a window switching instruction is received, destroy the currently displayed window and create a new standby window to maintain the preset number of the standby windows; Select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; Asynchronously load the business resources of the target window based on the routing mechanism, and render the business resources into the target window, so as to use the rendered target window as the new currently displayed window.

[0005] By adopting the above technical solution, when the Electron application pre-creates a set of spare windows at startup and keeps them hidden, it can directly reuse the existing window resources when the user triggers window switching, thereby significantly reducing the initialization time and resource overhead required for creating new windows, improving the overall response efficiency of window switching, and effectively reducing the system memory occupancy.

[0006] In a preferred example of this application, it can be further configured that: the method for determining the preset quantity includes: Determine the sampling period, and record the number of window types involved in the user's window switching process within the sampling period; Determine the available system memory, and determine the maximum value of the number of windows according to the available system memory; Judge whether the number of window types is greater than the maximum value of the number of windows. If it is greater than the maximum value of the number of windows, then determine the maximum value of the number of windows as the preset quantity; If it is not greater than the maximum value of the number of windows, then judge whether the number of window types is greater than the preset minimum value of the number of windows. If it is greater than the preset minimum value of the number of windows, then determine the number of window types as the preset quantity. If it is not greater than the preset minimum value of the number of windows, then determine the minimum value of the number of windows as the preset quantity.

[0007] By adopting the above technical solution, by setting the number of spare windows to be dynamically adjustable and making a comprehensive judgment in combination with the actual window switching frequency and system memory capacity, it is possible to ensure stable performance while avoiding setting too many or too few spare windows, thereby realizing the rationality and dynamic adaptation ability of resource allocation and improving the flexibility of window management.

[0008] In a preferred example of this application, it can be further configured that: in the step of determining the maximum value of the number of windows according to the available system memory, it includes: Determine the available system memory; Determine the memory occupied by a single spare window; Divide the available system memory by the occupied memory to generate a corresponding quotient value; Round down the quotient value to determine the corresponding maximum value of the number of windows.

[0009] By adopting the above technical solution, by quantitatively analyzing the available system memory and the memory occupancy value of a single spare window, and calculating the upper limit of the window pool capacity accordingly, it can ensure that the number of spare windows does not exceed the system load capacity, avoid system jamming or crashing caused by excessive memory allocation, and enhance the running safety and robustness of the application.

[0010] In a preferred example, the present application can be further configured as follows: in the step of asynchronously loading the service resources of the target window based on the routing mechanism, it includes: Determine the independent routing table resources bound to the target window; Based on the independent routing table resources, asynchronously load the service resources of the target window through the routing mechanism; Render the service resources into the target window, and use the rendered target window as the new current display window.

[0011] By adopting the above technical solution, during the activation process of the target window, the service resources are asynchronously loaded according to the independent routing table bound to it, decoupling the service components from the window, avoiding the blocking problem caused by all synchronous loading of page resources during the window initialization stage, improving the loading efficiency, and enhancing the module reusability and structural clarity.

[0012] In a preferred example, the present application can be further configured as follows: in the step of asynchronously loading the service resources of the target window through the routing mechanism based on the independent routing table resources, it includes: Determine the current jump path according to the window switching instruction; Match the service component path corresponding to the current jump path from the independent routing table resources; Based on the asynchronous module loading mechanism, asynchronously pull the service resources required by the target service component from the service component path, and the service resources include HTML structure, style file and script resources.

[0013] By adopting the above technical solution, by quickly matching the service component path in the independent routing table based on the jump path and using the asynchronous module loading mechanism to load the page structure, style and script resources on demand, the initial loading volume can be reduced, the network bandwidth pressure can be reduced, and at the same time, the concurrent ability of component loading and the user operation response speed can be improved.

[0014] In a preferred example, the present application can be further configured as follows: in the step of rendering the service resources into the target window and using the rendered target window as the new current display window, it includes: Parse the service resources and construct the corresponding page component object; Dynamically inject the page component object into the rendering area of the target window to replace the lightweight blank page or the skeleton screen as the new current display window.

[0015] By adopting the above technical solution, after the business resources are loaded, page component objects are dynamically parsed and generated and injected into the rendering area of the target window to overwrite the placeholder page displayed in the early stage, which can achieve a smooth transition from the skeleton screen to the complete page, effectively eliminate the blank delay during the page switching process, and improve the user's visual experience and interaction coherence.

[0016] The second invention object of the present application is achieved by the following technical solution: An electron application window switching device, the electron application window switching device includes: A creation module, configured to create a preset number of standby windows when the electron application starts, and the standby windows are window instances in a hidden state; A destruction module, configured to destroy the currently displayed window and create a new standby window when receiving a window switching instruction to maintain the preset number of the standby windows; A selection module, configured to select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; A loading module, configured to asynchronously load the business resources of the target window based on a routing mechanism, and render the business resources into the target window, so as to use the rendered target window as the new currently displayed window.

[0017] The third object of the present application is achieved by the following technical solution: A computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where when the processor executes the computer program, the steps of the above-mentioned electron application window switching method are implemented.

[0018] The fourth object of the present application is achieved by the following technical solution: A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned electron application window switching method are implemented.

[0019] In summary, the present application includes at least one of the following beneficial technical effects: 1. In the early stage of the Electron application startup, this application creates a fixed number of spare windows. These windows are in a hidden state and not bound to specific business logics, existing only as empty shell windows for resource management. During the actual page jump process, instead of executing the serial high - overhead process of destroying the old window, creating a new window, and loading resources, when the current window is destroyed, an idle window is directly selected from the spare window pool, activated as the target window, and used for subsequent display. The life cycle of the entire window object can be uniformly managed and recycled, fundamentally avoiding the memory fragmentation problem caused by frequent window creation and destruction, reducing the memory leakage risk caused by the frequent generation and destruction of the Electron rendering process, and effectively improving the overall stability and operation efficiency of the application; 2. During the window activation process, not all business content is loaded immediately. Instead, a lightweight blank page or skeleton screen is first loaded for placeholder display to make the user interface respond quickly and avoid a long - time white screen, thus enhancing the user interaction experience. While in placeholder display, based on the independent routing table resources bound to the target window, the system asynchronously parses the current jump path and fetches corresponding front - end component resources such as HTML, CSS, and JS, and completes the dynamic injection of business content through the asynchronous module loading mechanism. Compared with the traditional method of blocking the loading of static pages after window creation, this method of window reuse + asynchronous decoupled loading decouples the business logic from the window structure, greatly reducing the pressure on the main thread, improving the response speed and fluency of application page switching, ensuring the system operation efficiency and resource controllability in the multi - window high - concurrency usage scenario, and ultimately achieving multiple optimizations of the traditional Electron application window switching mechanism in terms of performance, stability, and user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a flowchart of a method for switching Electron application windows in an embodiment of this application.

[0021] Figure 2 is another implementation flowchart of a method for switching Electron application windows in an embodiment of this application; Figure 3 is an implementation flowchart of step S02 in a method for switching Electron application windows in an embodiment of this application; Figure 4 is another implementation flowchart of step S40 in a method for switching Electron application windows in an embodiment of this application; Figure 5 is an implementation flowchart of step S402 in a method for switching Electron application windows in an embodiment of this application; Figure 6 It is a flowchart of the implementation of step S403 in a method for switching electron application windows according to an embodiment of the present application; Figure 7 It is a flowchart block diagram of a page switching method in the prior art; Figure 8 It is a flowchart block diagram of a method for switching electron application windows according to an embodiment of the present application.

[0022] Figure 9 It is a principle block diagram of a device for switching electron application windows according to an embodiment of the present application; Figure 10 It is a schematic diagram of a device according to an embodiment of the present application. Detailed implementation manners

[0023] The present application will be further described in detail below with reference to the accompanying drawings.

[0024] In an embodiment, as shown in Figure 1 and Figure 8 the present application discloses a method for switching electron application windows. A method for switching electron application windows includes: S10. When the electron application starts, create a preset number of standby windows, where the standby windows are window instances in a hidden state; S20. When a window switching instruction is received, destroy the currently displayed window and create a new standby window to maintain the preset number of standby windows; S30. Select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; S40. Asynchronously load the service resources of the target window based on the routing mechanism, and render the service resources into the target window, so as to use the rendered target window as the new currently displayed window.

[0025] In this embodiment, an Electron application refers to a desktop application developed based on the Electron framework, which has the capabilities of web page rendering and native window management. It usually runs between the main process and the rendering process, and controls the creation and destruction of window instances through the main process. A spare window refers to an empty window instance that is pre-created during the application startup phase, has no bound business logic, and is not visible to the user. Its purpose is to be used as a directly callable window resource in subsequent window switches to reduce latency and resource consumption during dynamic window creation. A window instance in the hidden state refers to a window object that is not added to the visible window list during creation or is set to the invisible state. It is logically registered in the application but does not participate in the rendering and display of the current graphical interface. A window switch instruction refers to a window jump request triggered by user operations or internal system logic, which contains the identification information or jump path of the target page and is used to drive the switching behavior of the current window content. The currently displayed window refers to the window instance that is visible and active on the current user interface and is the main carrier for users to interact with the application. It needs to be replaced or destroyed during switching. The target window refers to the window instance that is selected from the spare windows and used to display the new page content after responding to the window switch instruction. It is the final carrier window for the window switch behavior. A lightweight blank page refers to a simplified page structure that does not contain actual business components and is only used to briefly display placeholder content. Its role is to improve the initial page loading response speed and alleviate the white screen problem. A skeleton screen refers to a grayscale placeholder map that imitates the page structure and is used to provide the expected page outline when business resources have not been loaded yet, enabling users to obtain visual feedback during the waiting process and enhancing the smoothness of page switching. A routing mechanism refers to a logical structure that controls page jump behavior based on a predefined mapping relationship between paths and components. It usually includes a routing table, path matching, and component loading logic and is used to achieve modular navigation between pages. Asynchronous loading refers to a loading method that pulls resources on demand in the form of callback mechanisms or Promises without blocking the main thread, allowing the foreground interface to remain responsive while loading business content in the background. Business resources refer to the structural files, style sheets, functional scripts, etc. required to construct the actual business page and are the core components for building page functions and visuals. Rendering refers to the process of parsing and converting business resources into a visible page structure that can be displayed by a browser, including DOM tree generation, style calculation, and interface drawing. The rendering area refers to the area container in the target window used to display page content, usually a nested container or mounting point of the main page framework. The new currently displayed window refers to the target window that, after being loaded and activated, takes over from the original displayed window to become the new carrier of the user interaction interface, marking the completion of a window switch.For example, in an Electron desktop application, when the user clicks the "Settings" button in the sidebar, a window switching instruction is triggered. After the system destroys the current "Home" window, a spare window is selected from the spare window pool as the target window. First, a skeleton screen is loaded for initial placeholder display, and then the business components of the "Settings Page" are asynchronously loaded through the routing mechanism and rendered to the content area of the window to complete the smooth switching display of the settings page.

[0026] In one embodiment, as Figure 2 shown, that is, the method for determining the preset quantity includes: S01. Determine the sampling period and record the number of window types involved in the user window switching process within the sampling period; S02. Determine the available memory of the system and determine the maximum number of windows according to the available memory of the system; S03. Determine whether the number of window types is greater than the maximum number of windows. If it is greater than the maximum number of windows, determine the maximum number of windows as the preset quantity; S04. If it is not greater than the maximum number of windows, determine whether the number of window types is greater than the preset minimum number of windows. If it is greater than the preset minimum number of windows, determine the number of window types as the preset quantity. If it is not greater than the preset minimum number of windows, determine the minimum number of windows as the preset quantity.

[0027] In this embodiment, the sampling period refers to the time period for statistically recording user operation behaviors within a set time range, which is used to obtain the behavioral characteristics of window switching by users within a certain period of time. Its duration can be flexibly configured according to the application usage scenario. For example, it can be set to 30 seconds, 1 minute, or other reasonable values to reflect the window switching activity within a short period. The number of window types involved in the window switching process refers to the number of different service windows that the user has actually switched to and accessed during this sampling period. Each different function or page is regarded as an independent window type, and this number is used to characterize the breadth and complexity of window switching. The available system memory refers to the physical memory capacity that the operating system has not been occupied by various running programs and can be freely allocated for use, which is an important basis for evaluating the resource capacity that the application can bear. This value is usually dynamically obtained through the operating system interface. The maximum window number refers to the theoretical maximum number of windows calculated based on the current available system memory and the memory overhead of each standby window. This value represents the maximum number of standby windows that can exist simultaneously without affecting the system stability. The minimum window number refers to the guaranteed number of standby windows set during the development stage or operation strategy. Even if the user switches windows less frequently, the minimum standby window pool capacity still needs to be maintained to ensure that the application has basic response capabilities and a smooth page switching experience. The preset number refers to the number of standby windows finally determined for actual operation. This value is dynamically adjusted according to the comparison relationship between the number of window types, the maximum value, and the minimum value, and is used to balance resource consumption and performance requirements. For example, during a certain period, the user switches five window types within the sampling period, and the current available system memory allows a maximum of four standby windows to exist simultaneously. Then, according to the judgment logic, the maximum window number four will be set as the preset number, and finally only four standby windows will be retained to reduce resource pressure. In another scenario where the system memory is relatively abundant, if the user only switches three windows and the number is higher than the minimum value two, then three will be set as the preset number to dynamically adapt to the window management strategy in different operating environments; In one embodiment, as Figure 3 shown, in step S02, that is, in the step of determining the maximum window number according to the available system memory, it includes: S021. Determine the available system memory; S022. Determine the memory occupied by a single standby window; S023. Divide the available system memory by the occupied memory to generate a corresponding quotient value; S024. Round down the quotient value to determine the corresponding maximum window number.

[0028] In this embodiment, the available system memory refers to the physical memory space remaining on the current device when running an Electron application that can be allocated and used by the application, excluding the memory portion occupied by system processes, other applications, or background services. It is the basic basis for measuring the upper limit of the expandable resources of the application. The memory occupied by a single spare window refers to the average memory consumption required for a hidden spare window not bound to business logic during operation. This value is usually obtained by monitoring the memory occupancy after multiple instances are running and calculating the average value, representing the system load size required to create and maintain a spare window. The quotient obtained by dividing the available system memory by the occupied memory is a theoretical calculated value approximately representing how many spare windows the system can accommodate simultaneously under the current resource conditions. This value is a floating-point number used to evaluate the upper limit possibility of the window pool size. Rounding down this quotient means discarding the decimal part and only retaining the largest integer value less than or equal to this floating-point number to ensure that the calculation result is a practical number of windows and avoid over-allocation of resources. The maximum number of windows is determined based on this integer quotient and represents the upper limit of the number of spare windows that the current system can support within a safe and controllable range. It is used to limit the maximum size of the spare window pool and avoid a decline or crash in system performance caused by creating too many windows. For example, if the current available memory of a certain device is 800MB and the average memory occupied by each spare window is about 100MB, then the quotient obtained through division is 8. After rounding down, the maximum number of windows is 8, that is, the current system can accommodate at most 8 spare windows while ensuring stability.

[0029] Specifically, the setting of the maximum number of windows is to avoid system resource overload in scenarios of frequent window switching or massive pre-creation of spare windows. Even when in a hidden state, each spare window will occupy a certain amount of memory and rendering resources. If continuously created without limitation, it is likely to cause excessive consumption of physical memory, leading to problems such as memory leaks, lags, and even program crashes. Therefore, calculating a capacity upper limit based on the current available system memory and the average window occupancy helps to achieve adaptive resource allocation in different hardware environments and ensure the stable operation of the application on high-performance devices and resource-constrained devices. The setting of the minimum number of windows is to retain a certain number of spare windows even when window switching is infrequent or the memory condition is relatively tight, so as to ensure that the system can quickly respond and complete page rendering when the user triggers a window jump instruction, and avoid response delays or white screen problems caused by temporarily creating windows. It provides a bottom-line mechanism for maintaining the most basic window reuse ability, thus ensuring the minimum user experience level.

[0030] In one embodiment, as Figure 4As shown, in step S40, which is the step of asynchronously loading the service resources of the target window based on the routing mechanism, it includes: S401. Determine the independent routing table resources bound to the target window; S402. Asynchronously load the service resources of the target window through the routing mechanism based on the independent routing table resources; S403. Render the service resources into the target window, and thus use the rendered target window as the new current display window.

[0031] In this embodiment, the independent routing table resources bound to the target window refer to the exclusive routing configuration data corresponding to the currently selected alternate window and used to guide the page loading path and the mapping relationship of service components. This routing table resource contains the component paths, resource addresses, and jump rules required to be loaded by the service module to which the target window belongs, and is the key carrier for decoupling the window from its service content. Its independence ensures that each window can manage the corresponding page structure and logic as needed. Asynchronously loading the service resources of the target window through the routing mechanism means that the system, according to the jump path and resource location information defined in the above independent routing table, uses a non-blocking asynchronous loading method to dynamically obtain the HTML structure, CSS style, and JavaScript script resources required for the service page without affecting the response of the main thread. This operation realizes resource loading optimization through batch requests and pull-on-demand, improves the page initialization efficiency, and reduces the initial load pressure. Rendering the service resources into the target window means that after the resources are loaded, the system will parse and construct the visual structure corresponding to the page and mount it to the rendering area of the target window to achieve the complete display of the service interface and interaction functions. This process usually includes a series of rendering engine execution steps such as virtual DOM update, style rendering, and event binding. Using the rendered target window as the new current display window means that after the above rendering process is completed, the system switches the window state from hidden or candidate state to the active state and replaces the original display window to become the new user interaction interface, thus completing a complete window switch. For example, when the user clicks on the "Report" module in the menu bar, the system obtains the path information of the report component according to the bound independent routing table, then asynchronously loads the structure file and logic resources required by the report component through the asynchronous mechanism, completes the rendering in the target window, and finally sets the report window as the current display window for the user to view and operate.

[0032] In one embodiment, as Figure 5 shown, in step S402, which is the step of asynchronously loading the service resources of the target window through the routing mechanism based on the independent routing table resources, it includes: S4021. Determine the current jump path according to the window switch instruction; S4022. Match the service component path corresponding to the current jump path from the independent routing table resource; S4023. Based on the asynchronous module loading mechanism, asynchronously pull the service resources required by the target service component from the service component path. The service resources include HTML structure, style files, and script resources.

[0033] In this embodiment, the window switching instruction refers to a control signal generated under the drive of user operations or internal program logic, used to initiate the behavior of switching from the current display window to another window. This instruction carries the target page identifier or jump path information required for window jumping and is the trigger entry for the window switching process. The current jump path refers to the page jump destination path parsed based on the window switching instruction. This path corresponds to the target module or page resource in the service logic and is usually represented in the form of a string, such as a routing address, module identifier, or component name, used to locate and match resources in the routing table. The independent routing table resource refers to a set of exclusive path mapping configurations bound to the target window, used to maintain the matching relationship between different jump paths and corresponding service components. Its design purpose is to achieve isolation and flexible coupling between the window and the service logic, enabling each window to independently manage the content to be loaded. The service component path refers to the address information of the location where the service component corresponding to the current jump path is stored, which is the positioning basis for module loading. It usually includes the component path, entry file name, or post-build resource path in the project directory, used to accurately pull the required resource files. The asynchronous module loading mechanism refers to a processing flow that uses a non-blocking loading method to dynamically pull the required modules in the background according to the service component path and complete module parsing. It is often implemented through Promise, import dynamic syntax, or a module loader, so that the main thread is not blocked and the loading concurrency and execution efficiency are improved. The service resources required by the target service component refer to the set of structured page files, style sheets, and functional scripts necessary for building the component. Among them, the HTML structure is used to describe the page content and hierarchical structure, the style file is used to control the visual display style of the page, and the script resources include interaction logic and running logic to achieve the complete expression of the page function behavior. For example, after the user clicks the "Settings" button, the system parses the switching instruction to obtain the jump path " / setting". The routing mechanism matches "components / Setting / index.js" as the service component path from the independent routing table according to this path, and then loads the corresponding HTML, CSS, and JS files from this path through the asynchronous module loading mechanism, completing module initialization and dependency pulling in the background for the target window to complete rendering and display.

[0034] In one embodiment, as Figure 6As shown, in step S403, when rendering business resources into the target window and using the rendered target window as the new current display window, the steps include: S4031. Parse the business resources and construct corresponding page component objects; S4032. Dynamically inject the page component objects into the rendering area of the target window to replace the lightweight blank page or the skeleton screen as the new current display window.

[0035] In this embodiment, business resources refer to the collection of various resource files that constitute page content and functions required by target business components, including HTML files for structure definition, style files for visual display, and script files for implementing functional logic. These resources are fetched through an asynchronous loading mechanism in the previous steps. Parsing business resources refers to the process in which the system performs semantic analysis and function recognition on the above-mentioned resources, processes the resource content according to a preset component model or rendering framework, and converts static files into running objects with logical structures and interactive behaviors. This process usually includes operations such as template compilation, script execution, and style binding. A page component object refers to a component instance with a complete rendering structure and running logic generated after parsing business resources. It contains the DOM node structure of the page, a response event handling mechanism, and data binding logic, and is the basic unit for page visualization and interactive response. Dynamic injection means that during the window running process, the system actively inserts the generated page component object into the rendering area of the target window, rather than synchronously embedding it during the initial page loading stage. This operation can achieve content update without refreshing the window, effectively improving page responsiveness and loading efficiency. The rendering area of the target window refers to the specific container area in the target window for displaying page content, usually a specific mounting node or framework container in the DOM tree, which is used to carry the visual structure of the page component object. A lightweight blank page refers to a temporary page structure used for placeholder display before the business resources are loaded. It has a simple structure and low resource consumption, and is only used to avoid a blank page. A skeleton screen refers to a placeholder image used to simulate the basic structure outline of the page during the loading process. It visually presents the basic layout framework of the page to improve the user experience during the loading stage. Replacing the lightweight blank page or the skeleton screen with the page component object means that after the business resources are loaded and parsed to generate the page component object, the system replaces the previous placeholder temporary structure with the actual page content through DOM replacement or re-rendering, so as to achieve flicker-free page switching and content display. The new current display window refers to the target window that has undergone the above rendering process and completed page content update, officially replacing the original display window to become the front-end interface for user interaction operations, marking the end of a complete window switching process. For example, when a user jumps from the "home page" to the "report" page, the system generates a component object after asynchronously loading and parsing the report page resources, and injects the component object into the content area of the target window, covering the original skeleton screen content, so that the report page is rendered and the target window becomes the display interface visible to the current user.

[0036] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0037] In one embodiment, a window switching device based on an Electron application is provided. This window switching device based on an Electron application corresponds one-to-one with the window switching method based on an Electron application in the above embodiment. As Figure 9 shown, this window switching device based on an Electron application includes a creation module, a destruction module, a selection module, and a loading module. The detailed description of each functional module is as follows: The creation module is used to create a preset number of standby windows when the Electron application starts. The standby windows are window instances in a hidden state; The destruction module is used to destroy the currently displayed window and create a new standby window when a window switching instruction is received, so as to maintain the preset number of the standby windows; The selection module is used to select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; The loading module is used to asynchronously load the service resources of the target window based on the routing mechanism, and render the service resources into the target window, so as to use the rendered target window as the new currently displayed window.

[0038] Optionally, the window switching device based on an Electron application further includes: The first determination module is used to determine the sampling period and record the number of window types involved in the user window switching process within the sampling period; The second determination module is used to determine the available system memory and determine the maximum number of windows according to the available system memory; The first judgment module is used to judge whether the number of window types is greater than the maximum number of windows. If it is greater than the maximum number of windows, the maximum number of windows is determined as the preset number; The second judgment module is used to judge whether the number of window types is greater than the preset minimum number of windows if it is not greater than the maximum number of windows. If it is greater than the preset minimum number of windows, the number of window types is determined as the preset number. If it is not greater than the preset minimum number of windows, the minimum number of windows is determined as the preset number; Optionally, the second determination module includes: The first determination unit is used to determine the available system memory; The second determination unit is used to determine the memory occupied by a single standby window; The generation unit is used to divide the available system memory by the occupied memory to generate a corresponding quotient value; A third determination unit, configured to round down the quotient value to determine the maximum value of the corresponding number of windows; Optionally, the loading module includes: A fourth determination unit, configured to determine the independent routing table resource bound to the target window; A loading unit, configured to asynchronously load the service resources of the target window through a routing mechanism based on the independent routing table resource; A rendering unit, configured to render the service resources into the target window, so as to use the rendered target window as a new current display window; Optionally, the loading unit includes: A determination subunit, configured to determine the current jump path according to a window switching instruction; A matching subunit, configured to match the service component path corresponding to the current jump path from the independent routing table resource; A pulling subunit, configured to asynchronously pull the service resources required by the target service component from the service component path based on an asynchronous module loading mechanism, where the service resources include an HTML structure, a style file, and a script resource; Optionally, the rendering unit includes: A construction subunit, configured to parse the service resources and construct a corresponding page component object; An injection subunit, configured to dynamically inject the page component object into the rendering area of the target window to replace the lightweight blank page or the skeleton screen as a new current display window.

[0039] For the specific limitations on an electron application window switching device, reference may be made to the limitations on an electron application window switching method in the foregoing text, which will not be elaborated here. Each module in the foregoing electron application window switching device may be implemented in whole or in part by software, hardware, and their combination. The foregoing modules may be embedded in a processor in a computer device in a hardware form or independent of the processor, or stored in a memory in the computer device in a software form, so that the processor can call and execute the operations corresponding to the foregoing modules.

[0040] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as Figure 10As shown in the figure. The computer device includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a method for switching electron application windows.

[0041] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the following steps are implemented: S10. When the electron application starts, create a preset number of standby windows, where the standby windows are window instances in a hidden state; S20. When a window switching instruction is received, destroy the currently displayed window and create a new standby window to maintain the preset number of standby windows; S30. Select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; S40. Asynchronously load the business resources of the target window based on the routing mechanism, render the business resources into the target window, and thus use the rendered target window as the new currently displayed window.

[0042] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the following steps are implemented: S10. When the electron application starts, create a preset number of standby windows, where the standby windows are window instances in a hidden state; S20. When a window switching instruction is received, destroy the currently displayed window and create a new standby window to maintain the preset number of standby windows; S30. Select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; S40. Asynchronously load the business resources of the target window based on the routing mechanism, render the business resources into the target window, and thus use the rendered target window as the new currently displayed window.

[0043] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0044] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0045] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for switching electron application windows, characterized in that, The described electron application window switching method includes: When the electron application starts, create a preset number of standby windows, where the standby windows are window instances in a hidden state; When a window switching instruction is received, destroy the currently displayed window and create a new standby window to maintain the preset number of standby windows; Select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; Asynchronously load the business resources of the target window based on the routing mechanism, and render the business resources into the target window, so as to use the rendered target window as the new currently displayed window.

2. The method for switching electron application windows according to claim 1, wherein, The method for determining the preset number includes: Determine the sampling period, and record the number of window types involved in the user's window switching process within the sampling period; Determine the available system memory, and determine the maximum number of windows according to the available system memory; Judge whether the number of window types is greater than the maximum number of windows. If it is greater than the maximum number of windows, determine the maximum number of windows as the preset number; If it is not greater than the maximum number of windows, judge whether the number of window types is greater than the preset minimum number of windows. If it is greater than the preset minimum number of windows, determine the number of window types as the preset number. If it is not greater than the preset minimum number of windows, determine the minimum number of windows as the preset number.

3. The method for switching electron application windows according to claim 2, characterized in that In the step of determining the maximum number of windows according to the available system memory, it includes: Determine the available system memory; Determine the memory occupied by a single standby window; Divide the available system memory by the occupied memory to generate a corresponding quotient value; Round down the quotient value to determine the corresponding maximum number of windows.

4. The method for switching electron application windows according to claim 1, wherein In the step of asynchronously loading the business resources of the target window based on the routing mechanism, it includes: Determine the independent routing table resources bound to the target window; Based on the independent routing table resources, asynchronously load the business resources of the target window through the routing mechanism; Render the business resources into the target window, so as to use the rendered target window as the new currently displayed window.

5. A method for switching electron application windows according to claim 4, characterized in that In the step of asynchronously loading the business resources of the target window through the routing mechanism based on the independent routing table resources, it includes: Determine the current jump path according to the window switching instruction; Match the business component path corresponding to the current jump path from the independent routing table resources; Based on the asynchronous module loading mechanism, asynchronously pull the business resources required by the target business component from the business component path, and the business resources include HTML structures, style files, and script resources.

6. The method for switching electron application windows according to claim 4, wherein In the step of rendering the business resources into the target window, so as to use the rendered target window as the new currently displayed window, it includes: Parse the business resources and construct a corresponding page component object; Dynamically inject the page component object into the rendering area of the target window to replace the lightweight blank page or the skeleton screen as the new current display window.

7. An electron application window-based switching device, characterized in that, The electron application window switching device based on includes: A creation module, configured to create a preset number of standby windows when the electron application starts, where the standby windows are window instances in a hidden state; A destruction module, configured to destroy the current display window and create a new standby window when receiving a window switching instruction to maintain the preset number of standby windows; A selection module, configured to select the standby window corresponding to the window switching instruction as the target window, and load a lightweight blank page or a skeleton screen in the target window for initial placeholder display; A loading module, configured to asynchronously load the service resources of the target window based on a routing mechanism, and render the service resources into the target window, so as to use the rendered target window as the new current display window.

8. The electron application window switching device according to claim 7, wherein, The electron application window switching device based on further includes: A first determination module, configured to determine a sampling period and record the number of window types involved in the user window switching process during the sampling period; A second determination module, configured to determine the available system memory and determine the maximum number of windows according to the available system memory; A first judgment module, configured to judge whether the number of window types is greater than the maximum number of windows. If it is greater than the maximum number of windows, determine the maximum number of windows as the preset number; A second judgment module, configured to, if it is not greater than the maximum number of windows, judge whether the number of window types is greater than a preset minimum number of windows. If it is greater than the preset minimum number of windows, determine the number of window types as the preset number. If it is not greater than the preset minimum number of windows, determine the minimum number of windows as the preset number.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of an electron application window switching method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, the steps of an electron application window switching method according to any one of claims 1 to 6 are implemented.

Images