Page loading method and device, electronic equipment and storage medium

Abstract

The application discloses a page loading method and device, electronic equipment and storage medium. The method comprises the following steps: in response to a page switching request, a to-be-displayed page is acquired; if the to-be-displayed page is a non-native page, a singleton engine is controlled to render the to-be-displayed page, and the singleton engine is used for rendering different non-native pages; and a native container corresponding to the to-be-displayed page is controlled to load the rendered to-be-displayed page. In the application, different non-native pages correspond to the same singleton engine, and the non-native pages are rendered in advance through the singleton engine, so that the native container corresponding to the to-be-displayed page loads the rendered to-be-displayed page. In the application, a plurality of different non-native pages are rendered through the same singleton engine, the memory occupation of one singleton engine is low, so that the non-native pages occupy less memory when being loaded. Meanwhile, the plurality of non-native pages can communicate with each other through the singleton engine, and the intercommunication of the pages is improved.

Description

Technical Field

[0001] This application relates to the field of Internet information processing technology, and more specifically, to a page loading method, apparatus, electronic device, and storage medium. Background Technology

[0002] Hybrid development is a commonly used technique in application development. Hybrid development refers to the use of two or more technology stacks for page development in the same application (APP). In other words, while retaining the native technology stack, Flutter cross-platform technology development is introduced at the same time. The native and Flutter technologies coexist in a mixed manner, and the APP has pages or views displayed using the two technologies respectively.

[0003] View-level rendering refers to nesting Flutter pages within native pages within the same non-native application. Both Flutter and native page technologies each handle a portion of the page rendering responsibility. For example, within the same view, Flutter and native pages are displayed simultaneously, with the screen output showing part of the Flutter page and part of the native page. However, the high memory consumption of hybrid stacks when used at the view level has long been a technical problem plaguing the industry. Summary of the Invention

[0004] In view of this, embodiments of this application propose a page loading method, apparatus, electronic device, and storage medium to improve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a page loading method, the method comprising: in response to a page switching request, obtaining a page to be displayed; if the page to be displayed is a non-native page, controlling a singleton engine to render the page to be displayed, the singleton engine being used to render different non-native pages; and controlling a native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0006] Secondly, embodiments of this application provide a page loading apparatus, the apparatus comprising: a page acquisition module, configured to acquire a page to be displayed in response to a page switching request; a rendering module, configured to control a singleton engine to render the page to be displayed if the page to be displayed is a non-native page, the singleton engine being used to render different non-native pages; and a loading module, configured to control the native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0007] In one possible implementation, the rendering module is further configured to: create a native container corresponding to the page to be displayed if the page to be displayed is an unloaded page; start the native container corresponding to the page to be displayed; and control the singleton engine to render the page to be displayed.

[0008] In one possible implementation, the rendering module is further configured to restart the native container corresponding to the page to be displayed if the page to be displayed is a page that has been loaded before; and control the singleton engine to render the page to be displayed.

[0009] In one possible implementation, when the currently displayed page is a non-native page, the rendering module is further configured to, if the page to be displayed is a non-native page, control the singleton engine to stop rendering the currently displayed page when the removal time of the native container corresponding to the currently displayed page is reached; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed when the display time of the native container corresponding to the page to be displayed is reached, wherein the removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed.

[0010] In one possible implementation, when the currently displayed page is a partially displayed non-native page, the rendering module is further configured to: determine whether the page to be displayed is an unloaded page if the page to be displayed is a partially displayed non-native page; if the page to be displayed is a previously loaded page, control the singleton engine to stop rendering the currently displayed page when the display callback time of the native container corresponding to the page to be displayed is reached; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed.

[0011] In one possible implementation, when the currently displayed page is a non-native page, the rendering module is further configured to: obtain a pre-display image corresponding to the page to be displayed, wherein the pre-display image is obtained based on the content in the page to be displayed; control the singleton engine to stop rendering the current displayed page when the removal time of the native container corresponding to the current displayed page is reached; control the native container corresponding to the current displayed page to stop loading the current displayed page; load the pre-display image; control the singleton engine to render the page to be displayed when the display time of the native container corresponding to the page to be displayed is reached, wherein the removal time of the native container corresponding to the current displayed page is reached before the display time of the native container corresponding to the page to be displayed; and stop loading the pre-display image.

[0012] In one possible implementation, the rendering module is further configured to determine whether the page to be displayed is an unloaded page; if it is an unloaded page, to obtain a pre-display image corresponding to the page to be displayed.

[0013] In one possible implementation, the rendering module is further configured to obtain the first frame image corresponding to the page to be displayed through an image loading engine, and use it as the pre-display image.

[0014] In one possible implementation, the rendering module is further configured to control the image loading engine to load the pre-display image; and to control the image loading engine to stop loading the pre-display image.

[0015] In one possible implementation, the page to be displayed is a page in a target application; the device further includes: a program building module, configured to obtain program code corresponding to the target application and modification information for modifying the program code; encapsulate the modification information into a modification strategy through a target bytecode manipulation framework; and compile the target application through a target plugin based on the modification strategy and the program code.

[0016] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory is coupled to the processor, the memory stores instructions, and when the instructions are executed by the processor, the processor performs the method described above.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, which can be invoked by a processor to execute the above-described method.

[0018] Fifthly, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described above.

[0019] The page loading method, apparatus, electronic device, and storage medium provided in this application embodiment all involve different non-native pages corresponding to the same singleton engine. The singleton engine pre-renders the non-native pages so that the native container corresponding to the page to be displayed can load and render the rendered page. In this application, multiple different non-native pages are rendered through the same singleton engine. A singleton engine has low memory usage, thus reducing the memory consumption of non-native pages during loading. Furthermore, multiple non-native pages can communicate with each other through the singleton engine, improving page interoperability. Attached Figure Description

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

[0021] Figure 1 A navigation diagram of a non-native page with related page loading methods is shown;

[0022] Figure 2 A flowchart of a page switching method provided in an embodiment of this application is shown;

[0023] Figure 3 A schematic diagram of a page of a target application according to an embodiment of this application is shown;

[0024] Figure 4 This illustration shows a schematic diagram of a page of another target application according to an embodiment of this application.

[0025] Figure 5 A navigation diagram of a non-native page is shown in an embodiment of this application;

[0026] Figure 6 A flowchart of a page switching method according to another embodiment of this application is shown;

[0027] Figure 7 This illustration shows a lifecycle diagram of a non-native page in an embodiment of this application;

[0028] Figure 8 A schematic diagram of the lifecycle of a target application according to an embodiment of this application is shown;

[0029] Figure 9 A flowchart of a page switching method provided in another embodiment of this application is shown;

[0030] Figure 10 A schematic diagram of a page of another target application according to an embodiment of this application is shown;

[0031] Figure 11 A schematic diagram of another target application page is shown in an embodiment of this application;

[0032] Figure 12 A flowchart of a page switching method provided in another embodiment of this application is shown;

[0033] Figure 13 A schematic diagram of a first frame image in an embodiment of this application is shown;

[0034] Figure 14 A schematic diagram illustrating the loading process of the pre-displayed image in an embodiment of this application is shown;

[0035] Figure 15 A flowchart of a method for obtaining a target application in the above embodiments is shown;

[0036] Figure 16A schematic diagram of the target application building process in an embodiment of this application is shown;

[0037] Figure 17 A schematic diagram illustrating the modification logic of the target application in an embodiment of this application is shown;

[0038] Figure 18 A block diagram of a page switching device according to an embodiment of this application is shown;

[0039] Figure 19 A structural block diagram of an electronic device for performing a page loading method according to an embodiment of this application is shown. Detailed Implementation

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

[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0042] With the widespread adoption of mobile networks, users have increasingly higher demands for the user interface (UI) design of their electronic devices, especially the design of UI views. To ensure that electronic devices on different platforms can load the same UI view, various tools can be used to create UI views, such as Flutter. Flutter is an open-source toolkit from Google that helps developers efficiently build cross-platform application (APP) views using a single codebase. UI views created with Flutter can be directly loaded on electronic device platforms with different operating systems such as Android or iOS.

[0043] In this application, the UI view created by Flutter is referred to as a Flutter page. The following uses the implementation of a Flutter page as an example to illustrate the process of implementing a Flutter page on an electronic device.

[0044] When a Flutter page is loaded on an electronic device, it is loaded through the device's native container to make the page visible. A native container for a Flutter page controls its loading, display, and unloading, as well as communication and coordination with other native containers. The native container used to load the Flutter page differs depending on the operating system of the electronic device. For example, if the device is iOS-based, the native container is the iOS UI view controller, i.e., the UIViewController tool; if the device is Android-based, the native container is the Android UI view controller, i.e., the Activity tool. For each Flutter page opened on the electronic device, a separate native container is created to control and maintain the Flutter page, which is processed in memory using a stack. A single native container can hold multiple Flutter pages. In this application, the native container referred to below refers to either UIViewController or Activity.

[0045] A hybrid stack refers to a technology stack obtained by combining the technology stack of native web pages with that of Flutter web pages through hybrid development techniques. Hybrid development is a commonly used technique in application development. It means that a single application (APP) uses two or more technology stacks for page development, that is, while retaining the native technology stack, it also introduces Flutter cross-platform technology development. The two technologies coexist, and the APP contains pages or views displayed using each technology respectively.

[0046] View-level refers to using Flutter pages nested within native pages within the same non-native application. Both Flutter and native page technologies each undertake a portion of the page rendering responsibility. For example, in the same view, Flutter and native pages are displayed simultaneously, with the screen output containing part of the Flutter page and part of the native page.

[0047] When using a hybrid stack at the view level, a singleton engine can be created for each native container. If multiple Flutter pages are opened on an electronic device, multiple native containers are maintained and controlled, and multiple singleton engines are created accordingly. Flutter code execution and page display both rely on the engine, which is responsible for Flutter thread management, code execution, and other tasks. The engine consumes significant memory resources, and the code running in different engines is isolated and cannot call each other.

[0048] Please see Figure 1 , Figure 1 A navigation diagram of a non-native page, illustrating the relevant page loading methods, is shown. Figure 1 In the example shown, the non-native pages are Flutter pages. Flutter pages A and B share native container 1, and Flutter pages C and D share native container 2. Native container 1 corresponds to singleton engine 1, and native container 2 corresponds to singleton engine 2.

[0049] When an electronic device jumps from native page 1 to Flutter page A, Flutter page A is rendered through singleton engine 1, and native container 1 loads the rendered Flutter page A, thereby enabling the electronic device to display the view corresponding to Flutter page A.

[0050] However, the inventors discovered that by using the relevant methods, each engine has a corresponding Flutter page for a native container and maintains it. The memory resources of the Flutter page of each native container are not shared. In other words, the engine used by each native container is a memory-intensive object, which will lead to a surge in memory usage.

[0051] In view of this, the inventors have proposed a page loading method, apparatus, electronic device, and storage medium according to this application. The method includes: in response to a page switching request, obtaining a page to be displayed; if the page to be displayed is a non-native page, controlling a singleton engine to render the page to be displayed, wherein the singleton engine is used to render different non-native pages; and controlling the native container corresponding to the page to be displayed to load the rendered page to be displayed. In this application, different non-native pages correspond to the same singleton engine. The singleton engine pre-renders the non-native pages so that the native container corresponding to the page to be displayed can load the rendered page to be displayed. In this application, multiple different non-native pages are rendered through the same singleton engine. The memory usage of a singleton engine is low, thus reducing the memory usage of non-native pages when they are loaded. Simultaneously, multiple non-native pages can communicate with each other through the singleton engine, improving page interoperability.

[0052] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0053] Please see Figure 2 , Figure 2 A flowchart of a page switching method provided in an embodiment of this application is shown. This method can be applied to electronic devices, and the method includes:

[0054] S110. In response to a page switching request, obtain the page to be displayed.

[0055] In this application, a page switching request can specifically be a page navigation request sent to an electronic device. For example, when it is detected that a user touches a link or functional control on the currently displayed page, or when the touch operation is a preset operation for a page switching request, and it is necessary to open or close one or more pages (such as a full-screen page, a partial view with a view function, or a linked view), it can be determined that a page switching request has been received. The page to be displayed in the page switching request is determined based on the user's specific operation. For example, if the user clicks the back button, a page switching request is generated to specify the previous page of the currently displayed page as the page to be displayed, based on the operation of pressing the back button. Or, if the user clicks a control on the currently displayed page, a page switching request is generated to specify the page corresponding to the control as the page to be displayed, based on the operation of clicking the control. After the electronic device determines the page switching request, it can find the page to be displayed corresponding to the page switching request.

[0056] When a page switching request is detected, the page displayed on the electronic device at the current moment is the currently displayed page. The currently displayed page can be a page in the native app of the electronic device, or a page in a non-native app of the electronic device. The currently displayed page and the page to be displayed can be different pages within the same non-native app.

[0057] Generally, native apps refer to the apps that come pre-installed on an electronic device when it leaves the factory. Non-native apps are apps that are newly installed during the use or testing of the electronic device. For example, native apps can include the phone's calendar and clock, while non-native apps can refer to third-party video or music apps. In another special case, electronic devices may come pre-installed with non-native apps, and new native apps can also be installed from official platforms.

[0058] In this application, the non-native app can be an app based on Flutter technology. This non-native app includes both native and non-native pages (in this application, non-native pages can refer to Flutter pages). In some subsequent embodiments of this application, the non-native app is also referred to as the target application. The page to be displayed can refer to the native page of a native app, the native page of a non-native app, or the non-native page of a non-native app that the electronic device needs to display after a page switching request is sent for the currently displayed page. The native page can be loaded directly, while the non-native page needs to be rendered through a singleton engine, and then the rendered non-native page is loaded through the corresponding native container before being displayed for the user to see.

[0059] Please see Figure 3The target application (non-native app) in the electronic device includes, for example, three non-native pages: a chat page (a), a directory page (b), and a settings page (c). At the bottom of the non-native app are three tab icons indicating the three different non-native pages. Different non-native pages are indicated by different tab icons: the chat page is indicated by the chat tab icon, the directory page by the directory tab icon, and the settings page by the settings tab icon. When the non-native page corresponding to a tab icon is displayed, the tab icon is filled with a different color, such as blue or green. Figure 3 In the image, the left image is the chat page, with the corresponding chat tab icon filled; the middle image is the directory page, with the corresponding directory tab icon filled; and the right image is the settings page, with the corresponding settings tab icon filled.

[0060] like Figure 3 As shown, when an electronic device displays a chat page, the user can click the directory tab icon. Based on the user's click, the electronic device responds to a page switching request and uses the directory page as the page to be displayed. Similarly, when an electronic device displays a chat page, the user can click the settings tab icon. Based on the user's click, the electronic device responds to a page switching request and uses the settings page as the page to be displayed.

[0061] Please see Figure 4 Another target application (non-native app) in the electronic device could be a game forum app. This game forum app, for example, includes two non-native pages: a homepage (a) and a game page (b). The bottom of the game forum app has two tab icons indicating the two different non-native pages. Different non-native pages are indicated by different tab icons; the homepage is indicated by a homepage tab icon, and the game page by a game tab icon. When the non-native page corresponding to a tab icon is displayed, the tab icon is filled with a different color, such as blue or green. Figure 4 In the image, the left image is the homepage, with the corresponding homepage tab filled with icons, and the right image is the game page, with the corresponding game tab filled with icons.

[0062] The homepage can include games the user has played; for example, the icon for "My Games" corresponds to games the user has played. The homepage can also include game recommendations and game gift packs (such as new player bonuses). The game page can include various types of games not installed on the electronic device, such as featured games, editor's picks, and new games available for pre-order. Users can click the install button to install the game corresponding to the icon.

[0063] like Figure 4 As shown, when an electronic device displays the homepage, the user can click the game tab icon. Based on the user's click, the electronic device responds to a page switching request and, based on this request, sets the game page as the page to be displayed. Similarly, when an electronic device displays the game page, the user can click the homepage tab icon. Based on the user's click, the electronic device responds to a page switching request and, based on this request, sets the homepage as the page to be displayed.

[0064] S120. If the page to be displayed is a non-native page, then control the singleton engine to render the page to be displayed. The singleton engine is used to render different non-native pages.

[0065] In this application, one singleton (which can refer to a non-native app) corresponds to one singleton engine, which is used to render all non-native pages within that singleton. In other words, n non-native apps correspond to n singleton engines, where n is a non-zero natural number.

[0066] For example, an electronic device has three non-native applications installed. Non-native application a1 contains four non-native pages, non-native application a2 contains five non-native pages, and non-native application a3 contains three non-native pages. In this case, the four non-native pages of non-native application a1 correspond to one singleton engine, the five non-native pages of non-native application a2 correspond to one singleton engine, and the three non-native pages of non-native application a3 correspond to one singleton engine.

[0067] When an electronic device responds to a page switching request, it parses the page switching request to obtain the page to be displayed corresponding to the page switching request. If the page to be displayed is a non-native page, it calls the singleton engine of the non-native APP to which the page to be displayed belongs, so as to render the page to be displayed through the singleton engine of the non-native APP.

[0068] For example, an electronic device has two non-native applications installed: non-native application b1 and non-native application b2. When a non-native page of non-native application b1 is opened, non-native application b1 renders the non-native page using its corresponding singleton engine c1; when a non-native page of non-native application b2 is opened, non-native application b2 renders the non-native page using its corresponding singleton engine c2.

[0069] In this embodiment, the singleton engine used to render different non-native pages means that for the same singleton, there is only one singleton engine used to render all the non-native pages within that singleton. When displaying different non-native pages, all non-native pages are rendered using the singleton engine of that singleton. In other words, the embodiments of this application are based on a single-engine solution. A single engine refers to using a single singleton engine for reuse to display and switch between multiple non-native pages, thereby avoiding memory spikes and communication isolation issues.

[0070] For example, the non-native application d includes non-native pages e1, e2, e3, and e4. When the non-native application displays non-native page e1, it is rendered by the non-native application's singleton engine f. When switching from non-native page e1 to non-native page e3, it is also rendered by the non-native application's singleton engine f. When switching from non-native page e3 to non-native page e4, it is still rendered by the non-native application's singleton engine f.

[0071] S130: Control the native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0072] A native container refers to a view controller used to host non-native pages. In the Android system, a Fragment component used to display views can be used as a native container for non-native pages. Native pages within a singleton can be directly displayed on electronic devices, while non-native pages cannot be displayed directly. They need to be rendered by the corresponding singleton engine, and then hosted in a native container. When a non-native page is closed, its corresponding native container no longer hosts it.

[0073] In some specific implementations, the page switching request can correspond to a view-level page switching. That is, when the currently displayed page is a native page, the page to be displayed is shown in a portion of the screen, covering the corresponding area of ​​the currently displayed page, and is displayed simultaneously with the currently displayed page. For example, when the currently displayed page is a native page, if the page switching request is to open a non-native page, and the non-native page covers a portion of the native page, then the non-native page is rendered using a singleton engine, and a corresponding native container is used to hold the non-native page, so that the non-native page is displayed in the corresponding area and shown together with the native page.

[0074] In this embodiment, the non-native page rendered by the singleton engine is loaded through the corresponding native container. When the native container loads the rendered non-native page, the electronic device displays a portion of the content corresponding to the non-native page. In this embodiment, different non-native pages correspond to the same singleton engine. The singleton engine pre-renders the non-native page so that the native container corresponding to the page to be displayed can load and render the page to be displayed. In this application, multiple different non-native pages are rendered through the same singleton engine. The memory consumption of a single singleton engine is low, thus reducing the memory usage of non-native pages when they are loaded. Simultaneously, multiple non-native pages can communicate with each other through the singleton engine, improving page interoperability.

[0075] Optionally, in this application, different non-native pages can correspond to their respective native containers; that is, a native container only holds one non-native page. Once the page to be displayed is determined, the singleton engine used to render the page and the native container used to load the page are also determined. Then, the singleton engine renders the page, and the rendered page is loaded using the corresponding native container.

[0076] For a single non-native app, there is one singleton engine. When it includes multiple non-native pages, there are multiple native containers, each used to load one non-native page. Multiple non-native pages rendered by the singleton engine reside within the same singleton engine, and these pages can communicate with each other, improving page interoperability.

[0077] Please see Figure 5 , Figure 5 A navigation diagram of a non-native page is shown in an embodiment of this application. Figure 5 In the example shown, the non-native pages are Flutter pages, including Flutter page E, Flutter page F, Flutter page G and Flutter page H. Each of them corresponds to a native container. Flutter page E corresponds to native container 3, Flutter page F corresponds to native container 4, Flutter page G corresponds to native container 5, and Flutter page H corresponds to native container 6. The four non-native pages correspond to a singleton engine 3.

[0078] exist Figure 1In this scenario, when the current displayed page on the electronic device is native page 1, if a page switching request is received to open Flutter page B, then Flutter page B is rendered in singleton engine 1, and then loaded through native container 1. When loading Flutter page B in native container 1, Flutter page A is loaded first, and then the user is redirected to Flutter page B. In other words, when loading Flutter page B, Flutter page A is briefly loaded first, and then Flutter page B is loaded. Similarly, if loading Flutter page D, Flutter page C is loaded first, and then the user is redirected to Flutter page D. This Flutter page routing method is complex, making Flutter page navigation extremely difficult.

[0079] exist Figure 5 In this implementation, when the current displayed page of the electronic device is native page 5, if a page switching request is received to open Flutter page F, then Flutter page F is rendered through singleton engine 3 and then loaded through native container 4. Upon receiving a page switching request, the corresponding native container 4 is determined directly through the binding relationship between the non-native page and the native container, and then Flutter page B is loaded through native container 4, without needing to preload other Flutter pages. Similarly, if loading Flutter page H, it is not necessary to load Flutter page G first; Flutter page H is directly loaded through the determined native container 6. The Flutter page routing method in this embodiment is simple, reducing the difficulty of Flutter page navigation.

[0080] like Figure 3 As shown, when the electronic device displays the chat page, the user can click the directory tab icon. The electronic device responds to the user's click operation with a page switching request. Based on this page switching request, the directory page is determined to be the page to be displayed. The singleton engine is then controlled to render the directory page. The rendered directory page is then loaded through the native container corresponding to the directory page, and the electronic device displays the directory page. The display state of the electronic device is referenced... Figure 3 (b) In this context, when the electronic device displays the chat page, the user can click the settings tab icon. The electronic device responds to the user's click operation with a page switching request. Based on this request, it determines the settings page as the page to be displayed, controls the singleton engine to render the settings page, and then loads the rendered settings page through the native container corresponding to the settings page. The electronic device then displays the settings page. The display state of the electronic device is referenced from... Figure 3 (c) in the middle.

[0081] In this embodiment, multiple non-native pages corresponding to the same singleton are rendered through a singleton engine, and a non-native page is loaded through a native container, which reduces the routing difficulty of non-native pages.

[0082] Please see Figure 6 , Figure 6 A flowchart of a page switching method according to another embodiment of this application is shown. This method can be applied to electronic devices, and the method includes:

[0083] S210. In response to a page switching request, obtain the page to be displayed.

[0084] The description of S210 is the same as that of S110, and will not be repeated here.

[0085] S220. If the page to be displayed is a non-native page, then when the removal time of the native container corresponding to the currently displayed page is reached, control the singleton engine to stop rendering the currently displayed page.

[0086] S230. Control the native container corresponding to the currently displayed page to stop loading the currently displayed page.

[0087] S240. When the display time of the native container corresponding to the page to be displayed is reached, control the singleton engine to render the page to be displayed. The removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed.

[0088] S250: Control the native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0089] The description of S250 is the same as that of S130, and will not be repeated here.

[0090] The currently displayed page and the page to be displayed can be different non-native pages within the same target application (non-native APP). The currently displayed page is loaded through the corresponding native container. In this embodiment, the lifecycle of each native container can include the creation time (onCreate), the restart time (onRestart), the startup time (onStart), the display time (onResume), the removal time (onPause), the stop time (onStop), and the destruction time (onDestroy).

[0091] For a non-native page that has never been loaded, the lifecycle of its corresponding native container consists of the creation time, startup time, display time, removal time, and shutdown time. When the non-native page needs to be displayed, the native container is first created when its creation time is reached, then started when its startup time is reached, then loads the corresponding page when its display time is reached, stops loading the corresponding page when its removal time is reached, and finally stops working when its shutdown time is reached.

[0092] For a non-native page that has been loaded before, the lifecycle of its corresponding native container consists of the restart time, the display time, the removal time, and the stop time. When the non-native page needs to be displayed, its corresponding native container has already been created, so it does not need to be created again. The lifecycle does not include the creation time. The native container is restarted when the restart time is reached. Then, when the display time is reached, the native container loads the corresponding page. When the removal time is reached, the native container stops loading the corresponding page. When the stop time is reached, the native container stops working.

[0093] When a non-native page triggers a destruction operation, the corresponding native container is destroyed. The destruction operation can be either closing the non-native page or closing the corresponding non-native application.

[0094] Please see Figure 7 , Figure 7 This diagram illustrates the lifecycle of a non-native page in an embodiment of this application. The currently displayed page is a non-native page, and both the currently displayed page and the page to be displayed belong to the same non-native app. The currently displayed page is also rendered using the corresponding singleton engine, and the rendered result is loaded using the corresponding native container. When the electronic device responds to a page switching request, it determines the page to be displayed. If the page to be displayed is a non-native page, the removal of the currently displayed page is triggered at the specified time (corresponding to...). Figure 7 When the currently displayed page is removed (at the moment of removal), the singleton engine stops rendering the currently displayed page, and the native container corresponding to the currently displayed page stops loading the currently displayed page.

[0095] If the page to be displayed is a page that has not been loaded, the creation time of the native container corresponding to the page to be displayed reaches (corresponding to) Figure 7 The creation time of the page to be displayed (the time when the page to be displayed is created), the native container corresponding to the page to be displayed is created, and then the startup time of the native container corresponding to the page to be displayed is reached (corresponding to the time when the page to be displayed is created). Figure 7The startup time of the page to be displayed in the context of the native container, the startup time of the native container corresponding to the page to be displayed, and then the display time of the native container corresponding to the page to be displayed (corresponding to the startup time of the native container corresponding to the page to be displayed). Figure 7 The singleton engine renders the page to be displayed (the time when the page to be displayed is specified in the context of the context). The page to be displayed is then rendered by the native container corresponding to the page. The page to be displayed is then visible. Afterwards, when a destruction operation is triggered, the native container corresponding to the currently displayed page is destroyed (the time when the destruction operation is specified in the context of the context is specified in the context of the context). Figure 7 When the destruction time of the currently displayed page is reached, the native container corresponding to the currently displayed page is destroyed.

[0096] If the page to be displayed is a page that has been loaded before, no creation operation is required. The page will be displayed when the native container corresponding to the page is restarted. After that, the display time of the native container corresponding to the page is reached, the singleton engine renders the page to be displayed, and the page to be displayed becomes visible.

[0097] Understandably, the Singleton engine also renders and stops rendering periodically according to the lifecycle of the non-native page: it stops rendering when the native container corresponding to the currently displayed page is removed, and resumes rendering when the native container of the page to be displayed is displayed. During the time between the removal time of the native container corresponding to the currently displayed page and the display time of the native container of the page to be displayed, the Singleton engine does not perform any rendering operations.

[0098] Please see Figure 8 , Figure 8 This illustration shows a lifecycle diagram of a target application according to an embodiment of this application. Figure 8 In this context, the target application refers to a non-native application, and the non-native pages within the target application are Flutter pages. Figure 8 The target application includes multiple Flutter pages. Figure 8 (Only two Flutter pages are shown as examples). Different native containers are rendered using a singleton engine so that the native containers can hold the rendered Flutter pages, which are then visible as Flutter views on electronic devices.

[0099] In some embodiments, when the currently displayed page can be a native page, in response to a received page switching request, the page to be displayed is determined. If the page to be displayed has not been loaded before, the native container corresponding to the page to be displayed is created when the creation time of the native container corresponding to the page to be displayed is reached. Subsequently, the startup time of the native container corresponding to the page to be displayed is reached, the native container corresponding to the page to be displayed is started, and then the display time of the native container corresponding to the page to be displayed is reached. The singleton engine renders the page to be displayed, and the page to be displayed becomes visible after the native container corresponding to the page to be displayed is loaded and rendered.

[0100] In other embodiments, when the currently displayed page can be a native page, in response to the received page switching request, the page to be displayed is determined. If the page to be displayed has been loaded before, the native container corresponding to the page to be displayed is restarted when the restart time of the native container corresponding to the page to be displayed is reached. After that, when the display time of the native container corresponding to the page to be displayed is reached, the singleton engine renders the page to be displayed. The page to be displayed is then loaded and rendered by the native container corresponding to the page to be displayed, and the page to be displayed becomes visible.

[0101] Understandably, native pages do not need to be rendered by a singleton engine or loaded by a native container. When the currently displayed page is a native page, it responds to page switching requests and stops loading the currently displayed page.

[0102] Please see Figure 9 , Figure 9 A flowchart of a page switching method according to another embodiment of this application is shown. This method can be applied to electronic devices, and the method includes:

[0103] S310. In response to a page switching request, obtain the page to be displayed.

[0104] The description of S310 is the same as that of S110, and will not be repeated here.

[0105] S320. If the page to be displayed is a partially displayed non-native page, determine whether the page to be displayed is a page that has not been loaded.

[0106] In this embodiment, both the page to be displayed and the currently displayed page may be partially displayed non-native pages, which are displayed as Fragment components. For example... Figure 10As shown, a target application (a non-native app, such as a game forum app) in an electronic device includes two non-native pages: a homepage (a) and a game page (b). The game forum app has two tab icons at the bottom indicating the two different non-native pages. The different non-native pages are indicated by different tab icons; the homepage is indicated by a homepage tab icon, and the game page is indicated by a game tab icon. When the non-native page corresponding to a tab icon is displayed, the tab icon is filled with a different color, such as blue or green. Figure 10 In the image, the left image is the homepage, with the corresponding homepage tab filled with icons, and the right image is the game page, with the corresponding game tab filled with icons.

[0107] like Figure 10 In the diagram, the area enclosed by the dashed box represents a partial display of a non-native page, while the area outside the dashed box corresponds to the native page's display area. Each time a different tab is clicked to switch to a different partial non-native page, the corresponding native container loads that non-native page, and the content of the native page changes color based on the tab click.

[0108] like Figure 11 As shown, another target application (non-native app) in an electronic device includes, for example, three non-native pages: a chat page (a), a contacts page (b), and a discovery page (c). The bottom of the non-native app has three tab icons indicating the three different non-native pages. Different non-native pages are indicated by different tab icons: the chat page is indicated by the chat tab icon, the contacts page by the contacts tab icon, and the discovery page by the discovery tab icon. When the non-native page corresponding to a tab icon is displayed, the tab icon is filled with a different color, such as blue or green. Figure 11 In the image, the left image is the chat page, with the corresponding chat tab pattern filled; the middle image is the contacts page, with the corresponding contacts tab pattern filled; and the right image is the discovery page, with the corresponding discovery tab pattern filled.

[0109] exist Figure 11In the diagram, the area enclosed by the dashed box represents a partial display of a non-native page. The areas corresponding to the tab icons outside the dashed box, along with the top bar (where the titles for "Chat," "Contacts," and "Discovery" are located), constitute the native page's display area. Each time a different tab icon is clicked to switch to a different partial non-native page, the corresponding native container loads that non-native page. The content of the native page changes color and title based on the tab icon click.

[0110] S330. If the page to be displayed is a page that has been loaded before, when the display callback time of the native container corresponding to the page to be displayed is reached, control the singleton engine to stop rendering the currently displayed page.

[0111] S340. Control the native container corresponding to the currently displayed page to stop loading the currently displayed page.

[0112] S350, Control the singleton engine to render the page to be displayed.

[0113] When the page to be displayed is a page that has never been loaded, the page to be displayed is displayed in the manner described above for non-native pages. If the page to be displayed is a page that has been loaded, when the display callback time of the native container corresponding to the page to be displayed is reached, the singleton engine is controlled to stop rendering the currently displayed page.

[0114] When loading a partially displayed non-native page for the first time, the lifecycle of the partially displayed non-native page is the same as that of the non-native page mentioned above. When a partially displayed non-native page is loaded, the lifecycle of the partially displayed non-native page includes the display callback time and the hiding time corresponding to the native container.

[0115] S360. Control the native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0116] The description of S360 is the same as that of S130, and will not be repeated here.

[0117] This application controls the singleton engine to stop rendering the currently displayed page and the corresponding native container to stop loading the currently displayed page when the display callback time of the native container corresponding to the page to be displayed is reached. This achieves preemption of the singleton engine, thereby avoiding page flickering caused by singleton engine call conflicts due to unknown switching relationships between two partially displayed non-native pages in the same non-native application, as seen in related technologies.

[0118] This solution addresses a problem in related technologies where the switching relationship between two partially displayed non-native pages within the same non-native application might be unknown, leading to page flickering due to a singleton engine reuse logic failure. For example, it resolves the issue where, in a non-native application with partially displayed non-native pages g1 and g2, the switching timing is such that when switching from g1 to g2, g1 is hidden after the chime time corresponding to the native container of g1 is reached, and then g2 is displayed when the display callback time corresponding to the native container of g2 is reached; conversely, when switching from g2 to g1, the display callback time corresponding to the native container of g1 is reached first, and the hiding time corresponding to the native container of g2 is reached later, causing page flickering due to a singleton engine reuse logic failure.

[0119] Please see Figure 12 , Figure 12 A flowchart of a page switching method according to another embodiment of this application is shown. This method can be applied to electronic devices, and the method includes:

[0120] S410, In response to a page switching request, obtain the page to be displayed.

[0121] The description of S410 is the same as that of S110 above, and will not be repeated here.

[0122] S420. If the page to be displayed is a non-native page, obtain a pre-display image corresponding to the page to be displayed. The pre-display image is obtained based on the content in the page to be displayed.

[0123] In this application, the pre-display image is obtained based on the content of the page to be displayed. The pre-display image can be a thumbnail of the entire content of the page to be displayed, or it can be the first frame image of the page to be displayed. When the page to be displayed is opened for the first time, the screen output image refers to the first frame image.

[0124] In some embodiments, a screenshot of the entire content of the page to be displayed can be taken, and then replaced with a thumbnail adapted to the screen size of the electronic device. This thumbnail serves as the pre-display image. In other embodiments, operations such as background addition, blurring, or color correction can be performed on the first frame image of the page to be displayed, and the processed image is used as the pre-display image. The pre-display image corresponds to an image loading engine. The pre-display image is obtained through this image loading engine; that is, in this application, the pre-display image acquisition step is performed using an image loading engine different from the singleton engine. The image loading engine can also be used to perform subsequent pre-display image loading and stopping loading steps.

[0125] Please see Figure 13 , Figure 13 This diagram illustrates a first frame image according to an embodiment of this application. It shows the display state of three non-native pages of a non-native app on an electronic device. The non-native pages of the non-native app include a chat page (a), a contacts page (b), and a discovery page (c). The bottom discovery page of the non-native app has three tab icons indicating the three different pages. From left to right, the three tab icons are: chat, contacts, and discovery. Different native pages are indicated by different tab icons. When the non-native page corresponding to a tab icon is displayed, the tab icon is filled with a different color.

[0126] exist Figure 13 The image only shows a portion of the chat page content; this portion represents the screen display when the page is first opened. Figure 13 From left to right, the screen displays the first frame of the images corresponding to the chat page, contacts page, and discovery page.

[0127] Understandably, users can manually swipe the chat page, and the electronic device can display the content corresponding to the user's dragging action. In this case, the screen output is no longer the first frame image of the chat page. Similarly, users can manually drag the contacts page, and the electronic device can display the content corresponding to the user's dragging action. In this case, the screen output is no longer the first frame image of the contacts page. Users can also manually drag the discovery page, and the electronic device can display the content corresponding to the user's dragging action. In this case, the screen output is no longer the first frame image of the discovery page.

[0128] When the current display page of the electronic device is the chat page, the user clicks the corresponding contact tab icon at the bottom of the screen. Based on the user's operation, the electronic device receives a page switching request, which is used to open the contact page and obtain the pre-display image of the corresponding contact page.

[0129] In some specific implementations, when the non-native application corresponding to the page to be displayed starts, the image loading engine of the non-native application obtains the pre-display images corresponding to each non-native page. When the page to be displayed is determined, the pre-display image corresponding to the page to be displayed is directly determined from the obtained pre-display images.

[0130] S430. When the removal time of the native container corresponding to the currently displayed page is reached, control the singleton engine to stop rendering the currently displayed page.

[0131] S440. Control the native container corresponding to the currently displayed page to stop loading the currently displayed page.

[0132] The descriptions of S430-S440 are the same as those of S220-S230 above, and will not be repeated here.

[0133] S450, Load the pre-display image.

[0134] In a specific implementation of this application, a pre-display image may be loaded through an image loading engine.

[0135] As described above, during the time between the removal of the native container of the currently displayed page and the display of the native container of the page to be displayed, the singleton engine does not perform any rendering operations, and the content output on the screen may be a blank page. During the time between the removal of the native container of the currently displayed page and the display of the native container of the page to be displayed, the native container of the page to be displayed is created and started. This creation and start-up time is relatively long, which makes the blank page remain for a longer period of time. Users can perceive a blank page during the transition from the currently displayed page to the page to be displayed, resulting in screen flickering (view switching flickering) phenomenon, which brings a bad visual experience to users.

[0136] Therefore, when the removal time corresponding to the native container of the currently displayed page is reached, the singleton engine is controlled to stop rendering the currently displayed page, the native container corresponding to the currently displayed page is controlled to stop loading the currently displayed page and loading the pre-display image, and the currently displayed page is no longer visible in the electronic device, while the pre-display image becomes visible.

[0137] S460. When the display time of the native container corresponding to the page to be displayed is reached, control the singleton engine to render the page to be displayed. The removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed.

[0138] The description of S460 is the same as that of S340 above, and will not be repeated here.

[0139] S470, Stop loading the pre-display image.

[0140] S480: Control the native container corresponding to the page to be displayed to load the rendered page to be displayed.

[0141] The description of S480 is the same as that of S350 above, and will not be repeated here.

[0142] When the native container corresponding to the page to be displayed reaches its display time, and the page to be displayed is about to become visible, loading the pre-display image stops to avoid the pre-display image overlapping the page to be displayed.

[0143] Please see Figure 14 , Figure 14 This illustration shows a schematic diagram of the loading process of a pre-displayed image in an embodiment of this application. The non-native page can refer to the currently displayed page or the page to be displayed. Initializing the non-native page refers to the moment when a non-native application is opened or a page switching request is received (the page switching request is used to open the non-native page). The pre-displayed image can be the first frame image of the non-native page.

[0144] Before the native container corresponding to the page to be displayed reaches its display time, the page to be displayed has not yet been loaded by the corresponding native container, and the page output by the electronic device is blank. Figure 14 (As shown in the solid line box), at this time, the pre-display image corresponding to the page to be displayed is shown. Figure 14 (dashed box) The pre-display image is overlaid on the blank page for display; when the display time of the native container corresponding to the page to be displayed is reached, the native container corresponding to the page to be displayed loads the page to be displayed. At this time, the pre-display image is removed, and the electronic device displays the page to be displayed.

[0145] Between the removal of the native container corresponding to the currently displayed page and the display of the native container corresponding to the page to be displayed, the electronic device displays a pre-display image. When the display time of the native container corresponding to the page to be displayed arrives, the page to be displayed is displayed. The pre-display image serves as a transition between the currently displayed page and the page to be displayed, ensuring that when the page to be displayed loads, the electronic device displays a pre-display image similar to the page to be displayed, rather than a blank page. This results in a high degree of visual continuity in page transitions, solves the problem of view switching flickering, and improves the user experience.

[0146] In some implementations, the page to be displayed may be a previously opened page or a page that has not been loaded. When the page to be displayed is an unloaded page, its native container has not been created, requiring the creation and startup of the native container. Since the creation and startup of the native container consumes considerable time, loading the page to be displayed according to steps S410-S480 avoids screen flickering caused by a blank page between the currently displayed page and the page to be displayed, thus improving the user experience.

[0147] If the page to be displayed is a page that has been loaded before, and the native container for the page to be displayed has been created before, then the native container for the page to be displayed will not be created again. After the removal time corresponding to the native container of the currently displayed page is reached, and the restart time of the native container for the page to be displayed is reached, the native container for the page to be displayed will be restarted. Subsequently, when the display time of the native container for the page to be displayed is reached, the rendered page to be displayed will be loaded. At this time, the restart operation of the native container for the page to be displayed takes a short time. Even if there is a blank page between the currently displayed page and the page to be displayed, the user will not be able to perceive it. Therefore, the pre-display image display process can be skipped.

[0148] Optionally, controlling the singleton engine to render the page to be displayed includes: if the page to be displayed is a page that has not been loaded, then creating a native container corresponding to the page to be displayed; starting the native container corresponding to the page to be displayed; controlling the singleton engine to render the page to be displayed; or, if the page to be displayed is a page that has been loaded, then restarting the native container corresponding to the page to be displayed; controlling the singleton engine to render the page to be displayed.

[0149] As described above, the page to be displayed may be a page that has never been loaded or a page that has been loaded before after the user starts (restarts or starts for the first time) the corresponding non-native application.

[0150] If the page to be displayed is an unloaded page, then when the creation time of the native container of the page to be displayed is reached, the native container corresponding to the page to be displayed is created; when the startup time of the native container of the page to be displayed is reached, the native container corresponding to the page to be displayed is started; when the display time of the native container of the page to be displayed is reached, the singleton engine is controlled to render the page to be displayed, and the native container of the page to be displayed is controlled to display the rendered page to be displayed.

[0151] If the page to be displayed is a page that has been loaded before, then when the restart time of the native container of the page to be displayed is reached, the native container corresponding to the page to be displayed is restarted; when the display time of the native container of the page to be displayed is reached, the singleton engine is controlled to render the page to be displayed, and the native container of the page to be displayed is controlled to display the rendered page to be displayed.

[0152] In this application, "non-native application" can refer to a non-native app. Non-native apps typically run on mobile terminals. If the methods in related technologies are used, setting a separate singleton engine for each non-native page of a non-native app results in multiple singleton engines consuming a lot of memory. However, mobile terminals have limited memory (e.g., 8GB or 4GB), leading to less memory available for other applications. This slows down the running speed of other applications, causing them to lag and providing a poor user experience. When the method of this application is applied to mobile terminals, multiple non-native pages reuse a single singleton engine. A single singleton engine consumes less memory, allowing the mobile terminal to allocate more memory to other applications. This results in faster, smoother running of other applications, providing a better user experience.

[0153] Meanwhile, when the mobile terminal switches from the currently displayed non-native page to the next non-native page, a pre-display image of the next non-native page is displayed during the time interval between the time when the currently displayed non-native page stops loading and the time when the next non-native page loads. This prevents blank pages from appearing when the mobile terminal switches pages, avoids flickering caused by blank pages between page switches, and makes page switching smoother with excellent visual effects.

[0154] Please see Figure 15 , Figure 15 A flowchart of a method for obtaining a target application according to the above embodiments is shown. The method can be used in an electronic device, and the method includes:

[0155] S510. Obtain the program code corresponding to the target application and the modification information for modifying the program code;

[0156] S520. The modification information is encapsulated into a modification strategy through the target bytecode manipulation framework.

[0157] S530. The target application is obtained by compiling the target plugin based on the modification strategy and the program code.

[0158] In this embodiment, both the page to be displayed and the currently displayed page can originate from the target application. The target application is a non-native application, which can be an app based on Flutter technology. Before modification, the target application can be the original application based on the relevant page switching method. The program code of the target application is used to build the code of the original application. The modification information of the target application refers to the modification information of the program code of the original application. This modification information is used to modify the original application into the target application so that the target application runs according to the page switching method of this application. The modification information can be, for example, code deletion information, transformation information, and addition information.

[0159] The target bytecode manipulation framework can be ASM bytecode manipulation. Modification information is encapsulated based on the target bytecode manipulation framework to obtain a modification strategy. Modification information used to solve a problem can be encapsulated into a single modification strategy. Alternatively, multiple modification messages for the original application can be encapsulated into a single modification strategy, with each modification message corresponding to a different code modification fragment.

[0160] For example, if the modification information for application A includes modification information for 10 code snippets, then the modification information for these 10 code snippets is encapsulated into a modification strategy, which is used to modify these 10 code snippets.

[0161] The target plugin can be a Gradle plugin. During compilation, the target plugin modifies the strategy to replace the program code of the original application, thus obtaining the target application.

[0162] Additionally, when the target application is obtained, the Singleton engine stops rendering and becomes idle when the removal time of the currently displayed page is reached. When the display time of the page to be displayed is reached, the Singleton engine renders the page to be displayed and does not become idle. While rendering the page to be displayed, the Singleton engine also registers and unregisters functional plugins such as keyboard and touch feedback registered for the page to be displayed.

[0163] To achieve the reuse of the aforementioned singleton engine, the passing of Inactive / Pause messages in the original application is disabled, rendering of non-native pages is completely taken over, and the back button on non-native pages is also taken over. Furthermore, the implementation details of non-native pages can be adjusted for the original application, providing display support for the single-engine solution.

[0164] Reference Figure 16 , Figure 16 This illustration shows a schematic diagram of the target application building process in an embodiment of this application. Figure 16Only two modification strategies are shown: Strategy 1 and Strategy 2. In specific applications, more modification strategies can be included.

[0165] Program code refers to the program code corresponding to the target application. Code 1, Code 2, and Code 3 are modification information used to modify the program code of the target application. They are encapsulated into Strategy 1 to solve one problem. Code 4 is also modification information used to modify the program code of the target application, and it is encapsulated into Strategy 2 to solve another problem. The code encapsulation can be performed by the target bytecode manipulation framework ASM bytecode manipulation. Code 1, Code 2, Code 3, and Code 4 can be various types of code modifications.

[0166] Please see Figure 17 , Figure 17 The illustration shows a schematic diagram of the modification logic of the target application in an embodiment of this application. Non-native pages refer to Flutter pages.

[0167] When modifying the target application, the `io.flutter` package in the target application's Flutter SDK is modified to achieve singleton engine reuse. The singleton engine is injected into the `io.flutter` package, and the lifecycle logic for non-native pages and partially displayed non-native pages in this application is added to the `io.flutter` package to synchronize their lifecycles, thus enabling the singleton engine to be reused according to the corresponding lifecycle. The singleton engine and native container's operation is implemented by carrying and calling Drat code in the target application. Calling Drat code can be a JNI (Java Native Interface) method call.

[0168] The method described in this embodiment allows the target application to be applied to different historical versions of the target application without requiring recompilation for each historical version, thus improving the compilation efficiency, adaptability, and compatibility of the target application.

[0169] Please see Figure 18 , Figure 18 A block diagram of a page switching device 500 according to an embodiment of this application is shown. The device 500 includes:

[0170] The page acquisition module 510 is used to acquire the page to be displayed in response to a page switching request;

[0171] The rendering module 520 is used to control the singleton engine to render the page to be displayed if the page to be displayed is a non-native page. The singleton engine is used to render different non-native pages.

[0172] The loading module 530 is used to control the native container corresponding to the page to be displayed to load the rendered page.

[0173] Optionally, the rendering module 520 is further configured to, if the page to be displayed is an unloaded page, create a native container corresponding to the page to be displayed; start the native container corresponding to the page to be displayed; and control the singleton engine to render the page to be displayed.

[0174] Optionally, the rendering module 520 is further configured to restart the native container corresponding to the page to be displayed if the page to be displayed is a page that has been loaded before; and control the singleton engine to render the page to be displayed.

[0175] Optionally, when the currently displayed page is a non-native page, the rendering module 520 is further configured to, if the page to be displayed is a non-native page, control the singleton engine to stop rendering the currently displayed page when the removal time of the native container corresponding to the currently displayed page is reached; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed when the display time of the native container corresponding to the page to be displayed is reached, wherein the removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed.

[0176] Optionally, when the currently displayed page is a partially displayed non-native page, the rendering module 520 is further configured to: determine whether the page to be displayed is an unloaded page if the page to be displayed is a partially displayed non-native page; if the page to be displayed is a previously loaded page, control the singleton engine to stop rendering the currently displayed page when the display callback time of the native container corresponding to the page to be displayed is reached; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed.

[0177] Optionally, when the currently displayed page is a non-native page, the rendering module 520 is further configured to: obtain a pre-display image corresponding to the page to be displayed if the page to be displayed is a non-native page, the pre-display image being obtained based on the content in the page to be displayed; control the singleton engine to stop rendering the current displayed page when the removal time of the native container corresponding to the current displayed page is reached; control the native container corresponding to the current displayed page to stop loading the current displayed page; load the pre-display image; control the singleton engine to render the page to be displayed when the display time of the native container corresponding to the page to be displayed is reached, the removal time of the native container corresponding to the current displayed page being reached before the display time of the native container corresponding to the page to be displayed; and stop loading the pre-display image.

[0178] Optionally, the rendering module 520 is further configured to determine whether the page to be displayed is an unloaded page; if it is an unloaded page, to obtain a pre-display image corresponding to the page to be displayed.

[0179] Optionally, the rendering module 520 is further configured to obtain the first frame image corresponding to the page to be displayed through the image loading engine, and use it as the pre-display image.

[0180] Optionally, the rendering module 520 is also used to control the image loading engine to load the pre-display image; and to control the image loading engine to stop loading the pre-display image.

[0181] Optionally, the page to be displayed is a page in the target application; the device further includes:

[0182] The program building module is used to obtain the program code corresponding to the target application and modification information for modifying the program code; encapsulate the modification information into a modification strategy through a target bytecode manipulation framework; and compile the target application based on the modification strategy and the program code through a target plugin.

[0183] In this embodiment, a page switching device is provided. In response to a page switching request, a page to be displayed is obtained. If the page to be displayed is a non-native page, a singleton engine is controlled to render the page to be displayed. The singleton engine is used to render different non-native pages. The native container corresponding to the page to be displayed is controlled to load the rendered page to be displayed. In this application, different non-native pages correspond to the same singleton engine. The singleton engine pre-renders the non-native pages so that the native container corresponding to the page to be displayed can load the rendered page to be displayed. In this application, multiple different non-native pages are rendered through the same singleton engine. The memory usage of a singleton engine is low, thus reducing the memory consumption of non-native pages when they are loaded. Simultaneously, multiple non-native pages can communicate with each other through the singleton engine, improving page interoperability.

[0184] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0185] The following will combine Figure 19 This application describes an electronic device.

[0186] Figure 19 A structural block diagram of an electronic device for performing a page loading method according to an embodiment of this application is shown. It should be noted that... Figure 19The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0187] like Figure 17 As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0188] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0189] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0190] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0191] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. 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 indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated 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 or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0192] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0193] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the methods of any of the above embodiments.

[0194] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0195] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0196] In summary, this application provides a page loading method, apparatus, electronic device, and storage medium. In response to a page switching request, a page to be displayed is obtained. If the page to be displayed is a non-native page, a singleton engine is controlled to render the page to be displayed, and then the native container corresponding to the page to be displayed is controlled to load the rendered page. The singleton engine is used to render different non-native pages. In this application, different non-native pages correspond to the same singleton engine. The singleton engine pre-renders the non-native pages so that the native container corresponding to the page to be displayed can load the rendered page. In this application, multiple different non-native pages are rendered through the same singleton engine. A singleton engine has low memory usage, thus reducing the memory consumption of non-native pages when they are loaded. Simultaneously, multiple non-native pages can communicate with each other through the singleton engine, improving page interoperability.

[0197] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0198] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0199] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0200] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A page loading method, characterized in that, The method includes: In response to a page switching request, retrieve the page to be displayed; If the page to be displayed is a non-native page, then the singleton engine is controlled to render the page to be displayed. The singleton engine is used to render different non-native pages. Control the native container corresponding to the page to be displayed to load and render the page to be displayed; Wherein, when the currently displayed page is a partially displayed non-native page, the step of controlling the singleton engine to render the page to be displayed if the page to be displayed is a non-native page includes: If the page to be displayed is a partially displayed non-native page and has been loaded before, when the display callback time of the native container corresponding to the page to be displayed is reached, control the singleton engine to stop rendering the currently displayed page; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed.

2. The method according to claim 1, characterized in that, Different non-native pages correspond to their respective native containers.

3. The method according to claim 2, characterized in that, The control singleton engine renders the page to be displayed, including: If the page to be displayed is a page that has not been loaded, then create the native container corresponding to the page to be displayed; Start the native container corresponding to the page to be displayed; Control the singleton engine to render the page to be displayed.

4. The method according to claim 2, characterized in that, The control singleton engine renders the page to be displayed, including: If the page to be displayed is a page that has been loaded before, then restart the native container corresponding to the page to be displayed; Control the singleton engine to render the page to be displayed.

5. The method according to claim 1, characterized in that, When the currently displayed page is a non-native page, the step of controlling the singleton engine to render the page to be displayed if the page to be displayed is a non-native page includes: If the page to be displayed is a non-native page, then when the removal time of the native container corresponding to the currently displayed page is reached, the singleton engine is controlled to stop rendering the currently displayed page; Control the native container corresponding to the currently displayed page to stop loading the currently displayed page; When the display time of the native container corresponding to the page to be displayed is reached, the singleton engine is controlled to render the page to be displayed. The removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed.

6. The method according to claim 1, characterized in that, When the currently displayed page is a non-native page, the step of controlling the singleton engine to render the page to be displayed if the page to be displayed is a non-native page includes: If the page to be displayed is a non-native page, obtain a pre-display image corresponding to the page to be displayed. The pre-display image is obtained based on the content of the page to be displayed. When the removal time of the native container corresponding to the currently displayed page is reached, the singleton engine is controlled to stop rendering the currently displayed page; Control the native container corresponding to the currently displayed page to stop loading the currently displayed page; Load the pre-display image; When the display time of the native container corresponding to the page to be displayed is reached, the singleton engine is controlled to render the page to be displayed. The removal time of the native container corresponding to the currently displayed page is reached before the display time of the native container corresponding to the page to be displayed. Stop loading the pre-display image.

7. The method according to claim 6, characterized in that, The step of obtaining the pre-display image corresponding to the page to be displayed includes: Determine whether the page to be displayed is an unloaded page; If the page has not been loaded, obtain the pre-display image of the corresponding page to be displayed.

8. The method according to claim 6, characterized in that, The step of obtaining the pre-display image corresponding to the page to be displayed includes: The first frame image corresponding to the page to be displayed is obtained through the image loading engine and used as the pre-display image.

9. The method according to claim 6, characterized in that, Loading the pre-display image includes: The image loading engine is controlled to load the pre-displayed image; The step of stopping the loading of the pre-displayed image includes: Control the image loading engine to stop loading the pre-display image.

10. The method according to any one of claims 1 to 9, characterized in that, The page to be displayed is a page in the target application; the method for obtaining the target application includes: Obtain the program code corresponding to the target application and the modification information for modifying the program code; The modification information is encapsulated into a modification strategy using a target bytecode manipulation framework; The target application is obtained by compiling the target plugin based on the modification strategy and the program code.

11. A page loading device, characterized in that, The device includes: The page retrieval module is used to retrieve the page to be displayed in response to page switching requests; The rendering module is used to control the singleton engine to render the page to be displayed if the page to be displayed is a non-native page. The singleton engine is used to render different non-native pages. The loading module is used to control the loading and rendering of the page to be displayed by the native container corresponding to the page to be displayed; Wherein, when the currently displayed page is a partially displayed non-native page, the loading module is further configured to, if the page to be displayed is a partially displayed non-native page and is a page that has been loaded before, when the display callback time of the native container corresponding to the page to be displayed is reached, control the singleton engine to stop rendering the currently displayed page; control the native container corresponding to the currently displayed page to stop loading the currently displayed page; and control the singleton engine to render the page to be displayed.

12. An electronic device, characterized in that, The method includes a memory and a processor, the memory being coupled to the processor, the memory storing instructions, and when the instructions are executed by the processor, the processor performing the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-10.

Images