A page display method and device

Abstract

The application relates to the field of Fintech (Fintech), and discloses a page display method and device, an application program where a page is located is built through a React Native framework; in response to a user instruction of displaying a second page, a first rendering management instance is executed to update a context environment from a first page to the second page, so that a second rendering management instance is obtained; based on the second rendering management instance, a JS execution file corresponding to the second page is acquired; a second view rendering instance of the second page is bound with the second rendering management instance, and the JS execution file is executed to obtain a rendered second page. Through configuration of a globalized rendering management object, content elements of two pages before and after display can be compared to determine content elements that need to be changed, and some content elements that are the same in the two pages are retained, so that the problem of memory occupation of a terminal during runtime of the application program can be reasonably managed.

Description

Technical Field

[0001] This application relates to the field of financial technology (Fintech), and more particularly to a page display method and apparatus. Background Technology

[0002] With the development of computer technology, more and more technologies (such as big data, cloud computing, or blockchain) are being applied in the financial sector, and the traditional financial industry is gradually transforming into fintech. For example, banks can develop and release applications that include a variety of online banking services. Users can then download and register the application using their everyday devices and complete relevant banking transactions through the application, thus improving the user experience.

[0003] Currently, banks can write and publish applications for their services using the React Native framework. However, when users interact with these React Native-based applications, the applications tend to consume a significant amount of memory on the user's device. This approach can easily lead to users abandoning the application, resulting in customer churn for online banking.

[0004] Therefore, a solution is urgently needed to address the problem that applications written based on the React Native framework tend to consume a lot of memory on user terminals during runtime. Summary of the Invention

[0005] This application provides a page display method and apparatus to overcome the problem of huge memory occupation during page display.

[0006] In a first aspect, embodiments of this application provide a page display method, wherein the application containing the page is built using the React Native framework; the method includes: responding to a user instruction to display a second page, updating the context environment from the first page to the second page on a first rendering management instance, thereby obtaining a second rendering management instance; the first rendering management instance is obtained based on a global rendering management object built when the application starts; the first page is the current display page of the application; based on the second rendering management instance, obtaining a JS execution file corresponding to the second page; binding a second view rendering instance of the second page to the second rendering management instance, and executing the JS execution file to obtain the rendered second page.

[0007] For applications built on the React Native framework, this embodiment constructs a global rendering management object at application startup. Thus, when a user commands the display of a second page from the current page (i.e., the first page), the global rendering management object is used to execute the context from the first page to the second page on the first rendering management instance. This generates a second rendering management instance, which can then be used to obtain the corresponding JavaScript executable file for the second page. After binding the second view rendering instance and the second rendering management instance, executing the JavaScript executable file renders and displays the second page. This method, by configuring a global rendering management object, allows for comparison of content elements between the two pages during display to determine which elements need modification, while retaining common content elements. This effectively manages the application's memory usage on the terminal during runtime.

[0008] In one possible implementation, the step of updating the context environment of the first rendering management instance from the first page to the second page to obtain the second rendering management instance includes: obtaining the second module configuration file of the second page; and updating the module registry of the first rendering management instance according to the second module configuration file to obtain the second rendering management instance.

[0009] In the above scheme, if the terminal is currently displaying the first page and receives a user's instruction to display the second page, the second rendering management instance can be obtained by retrieving the second module configuration file of the second page and updating the module registry of the first rendering management instance accordingly. This method only updates the content elements that differ between the second and first pages, rather than completely overwriting all content elements of the first page with those of the second page. This significantly reduces the memory consumption of the terminal during the transition from the first to the second page.

[0010] In one possible implementation, obtaining the JS executable file corresponding to the second page based on the second rendering management instance includes: obtaining the JS executable file corresponding to the second page based on the file loading interface in the second rendering management instance; and converting the JS executable file into Java low-level executable instructions based on the file conversion interface in the second rendering management instance.

[0011] In the above scheme, since the second rendering management instance encapsulates a file loading interface and a file conversion interface, after the second rendering management instance is generated, the JS executable file corresponding to the second page can be obtained through the file loading interface, and the JS executable file can be converted into Java low-level executable instructions through the file conversion interface.

[0012] In one possible implementation, binding the second view rendering instance of the second page to the second rendering management instance includes: sending instruction information to the Java underlying layer after converting the JS executable file through a bridging layer; binding the second view rendering instance of the second page to the second rendering management instance in the Java underlying layer based on the instruction information, and executing the converted JS executable file to obtain the rendered second page.

[0013] In the above scheme, after the second rendering management instance converts the JS executable file using the file conversion interface encapsulated in the bridging layer, it can send instruction information to the Java underlying layer. Upon receiving this instruction information, the Java underlying layer can bind the second view rendering instance of the second page to the second rendering management instance, and execute the converted JS executable file to render and display the second page. This method, by binding the real-time view rendering instance to the global rendering management instance, ensures the consistency between the view and the context environment.

[0014] In one possible implementation, the step of updating the module registry of the first rendering management instance according to the second module configuration file to obtain the second rendering management instance includes: constructing the module registry into a first module tree based on the module management class; constructing the second module configuration file into a second module tree based on the module management class; and updating the module registry according to the comparison result between the first module tree and the second module tree to obtain the second rendering management instance.

[0015] In the above scheme, by converting both the module registry and the second module configuration file into a tree structure, since there is no duplication of module nodes in the tree structure, the content that needs to be updated in the module registry can be quickly determined and accurately updated based on the comparison of the two tree structures.

[0016] In one possible implementation, prior to responding to a user instruction to display a second page, the method further includes: initializing a file loading interface and a file conversion interface; initializing a first module registry for the application layer and a second module registry for the underlying layer; initializing an underlying module thread, a JS event collection thread, and a user interface rendering thread; and initializing a bridging layer creation thread; the bridging layer creation thread is used to create a connection between the application layer and the underlying layer.

[0017] In the above scheme, during the initial startup of the application, a file loading interface and a file conversion interface are initialized, a first module registry for the application layer and a second module registry for the underlying layer are initialized, and a thread for the underlying module, a JS event collection thread, and a user interface rendering thread are initialized, as well as a thread for the bridge layer creation are initialized. Based on these initialized interfaces, empty module registry and threads, the module registry can be updated based on the interfaces during the subsequent page switching display process, and the second page can be displayed by calling the relevant threads based on the updated module registry.

[0018] In one possible implementation, the second view rendering instance is obtained by: resetting the first view rendering instance to a global view rendering object; the global view rendering object being constructed based on the application startup time; and instantiating the global view rendering object based on the virtual DOM tree obtained from the JS executable file to obtain the second view rendering instance.

[0019] In the above scheme, for the process of displaying each page in an application written based on the React Native framework, this embodiment of the application constructs a global view rendering object when the application starts, so that during the process of switching the display of pages, the previous page can be reset to the global view rendering object, and then the global view rendering object is instantiated based on the virtual DOM tree obtained from the JS executable file, thereby obtaining a view rendering instance for displaying the next page.

[0020] In one possible implementation, before obtaining the second rendering management instance, the method further includes: pushing the view history state information of the first page onto the stack of the history management state class; the view history state information is used for page backtracking; the view history state information includes at least the history state of the first view rendering instance, the history state of the first rendering management instance, the history state of the module management class, and the history state of the JS engine.

[0021] In the above solution, by pushing the view history state information of the first page into the stack of the history state class, the page can be backtracked through the stack, which improves the efficiency of the page backtracking process.

[0022] Secondly, embodiments of this application provide a page display device, wherein the application containing the page is built using the React Native framework; the device includes: a second rendering management instance generation unit, configured to, in response to a user instruction to display a second page, update the context environment of a first rendering management instance from the first page to the second page, thereby obtaining a second rendering management instance; the first rendering management instance is obtained based on a global rendering management object built when the application starts; the first page is the current display page of the application; a JS execution file acquisition unit, configured to, based on the second rendering management instance, acquire the JS execution file corresponding to the second page; and a second page display unit, configured to, bind a second view rendering instance of the second page to the second rendering management instance, and execute the JS execution file to obtain the rendered second page.

[0023] Thirdly, embodiments of this application provide a computing device, including:

[0024] Memory, used to store program instructions;

[0025] A processor is configured to invoke program instructions stored in the memory and execute any implementation method of the first aspect according to the obtained program.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform any implementation method as described in the first aspect. Attached Figure Description

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

[0028] Figure 1 A schematic diagram of a React Native framework provided for an embodiment of this application;

[0029] Figure 2 A schematic diagram illustrating the generation process of a module tree provided in an embodiment of this application;

[0030] Figure 3 A schematic diagram illustrating a determination module update provided in an embodiment of this application;

[0031] Figure 4 A schematic diagram illustrating a page display method provided in an embodiment of this application;

[0032] Figure 5 A schematic diagram of a page display device provided in an embodiment of this application;

[0033] Figure 6 A computing device provided in an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail 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 in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] React Native, an open-source mobile framework released by Facebook in 2015, is a technological solution developed to address the performance limitations of mobile HTML 5.0 (HyperText Markup Language 5.0) and the development and maintenance costs of native development. Based on the React framework concept, React Native enables the development of application-layer logic and the rendering of the UI (User Interface). Furthermore, by enclosing native platform methods and a JavaScript runtime environment, it bridges the gap between various mobile platforms. Because it is designed according to web standards, it allows developers to build mobile applications using efficient and convenient web development methods.

[0036] React Native breaks free from the constraints of WebView, using Bridges to pass rendering information from the application layer to the underlying layer for drawing and rendering. Module calls and event handling also require a communication mechanism between the application and underlying layers. For example... Figure 1 The diagram shown is a schematic of a ReactNative framework provided in an embodiment of this application, wherein from top to bottom are the Web application layer, the Bridge layer, the Module customization layer, and the Native underlying layer.

[0037] The application-layer logic written by users based on the React Native framework is packaged into a single JS file, which can be integrated into the application installation package or distributed via a cloud server. The core functionality of the React Native framework lies in its internal JavaScriptCore, which interprets and executes JS files. The React Native framework handles JS files in two ways:

[0038] Scenario 1: If the JS file contains UI component information written via the Web, it will be mapped to a Virtual DOM (Virtual DOM Tree) data structure for storage and passed to the Native layer through the Bridge layer. Thus, the Native layer can set the actual View information based on the attribute information in the previous Virtual DOM data structure.

[0039] Scenario 2: If the JS file contains only low-level interface call information, the native underlying layer can be notified directly through the Bridge layer.

[0040] The Bridge layer enables communication and data transfer between application layer code and underlying code, allowing application layer development to proceed independently.

[0041] The Native layer runs both the UI main thread and the JS thread. The JS thread continuously collects event responses from the application layer, then forwards the data to the UI main thread, and finally completes the actual event response at the Native layer.

[0042] Taking Android as an example, for an application built on the React Native framework running on this operating system, the only entry point for displaying page content is to instantiate a ReactRootView (rendering management instance) within an Activity container in Android. Then, the initialization process is initiated using `startReactApplication`. This initialization process is primarily managed by `reactInstanceManager` (rendering management instance). After initialization and the interpretation and execution of the application-layer JS files are complete, the page content is fully loaded into the ReactRootView. In the process of displaying page content described above, `reactInstanceManager` manages the entire initialization process. The context generated during initialization corresponds one-to-one with the ReactRootView, and both the ReactRootView and `reactInstanceManager` belong to the same Activity container. Furthermore, if a new ReactRootView is started from a NativeView, a new `reactInstanceManager` will be instantiated, re-initializing the entire process.

[0043] The above-described method for displaying page content has the following two drawbacks:

[0044] Disadvantage 1: Since most of the initialization process managed by reactInstanceManager is independent of the Activity container's environment, frequent initialization of new contexts severely impacts startup performance.

[0045] Disadvantage 2: Since ReactRootView and reactInstanceManager are attached to Activity containers, when the number of Activity containers in memory increases, ReactRootView and reactInstanceManager will increase memory usage because they are all retained in each Activity container.

[0046] The initialization process of reactInstanceManager can be summarized as follows:

[0047] 1. JSBundleLoader (file loading interface) and JavaScriptExecutor (file conversion interface) are used to load and execute JS files, which is unrelated to the content of the JS files;

[0048] 2. The initializeBridge operation in CatalystInstance is used to implement the communication mechanism between the application layer and the native underlying layer. Therefore, it belongs to the infrastructure initialization level and is not related to the specific scenario.

[0049] 3. JavaScriptModuleRegistry and NativeModuleRegistry need to generate module registry entries based on the specific ReactPackage.

[0050] Therefore, based on the above analysis of the initialization process of reactInstanceManager, this embodiment proposes to implement a global reactInstanceManager instance when the application initially starts. This means all Activity containers can share a single reactInstanceManager, so that when a new ReactRootView is launched, the reactInstanceManager can be notified to update the new Bundle path location. Since the initialization process only executes during the first application call, subsequent checks on the existence of the reactInstanceManager instance can dynamically modify the module registry of both the application layer and the native layer, and achieve consistency between the application layer and the native layer through a Bridge layer. This approach avoids recreating the reactInstanceManager instance every time, significantly reducing the memory footprint of reactInstanceManager based on the number of Activity containers, thus noticeably slowing down the rate of terminal memory growth.

[0051] The implementation process of the above solution will be described in detail below.

[0052] Step 1: Global Encapsulation Interface Design

[0053] The global interfaces of reactInstanceManager provided in this embodiment are shown in Tables 1, 2, and 3 below. Table 1 is the global interface of ReactInstanceManager, Table 2 is the global interface of ReactApplicationContext, and Table 3 is the global interface of CatalystInstance. All the initialization interfaces involved in Tables 1, 2, and 3 will only run once in the global environment. After that, the global reactInstanceManager instance can be obtained by using getInstanceManager.

[0054] In addition, this application improves the original design of the two context classes ReactApplicationContext and CatalystInstance. For example, the ReactApplicationContext in this application contains environment-related execution tools and module registry, and CatalystInstance is responsible for communicating with the Bridge layer and notifying the Bridge layer of dynamic changes in real time.

[0055] Table 1 Global Interfaces of ReactInstanceManager

[0056] Global encapsulation interface Interface Description setReactPackages Configure React Package list setBundlePath Configure Bundle path get InstanceManager Get InstanceManager instance bindReactRootView Binding ReactRootView

[0057] Regarding Table 1 above, the global ReactInstanceManager interface is responsible for interfacing with the underlying environment. When the route or Bundle changes, its internal context is modified by configuring its relevant interfaces. The bindReactRootView interface binds the real-time ReactRootView to the global ReactInstanceManager, ensuring consistency between the view and the context.

[0058] Table 2 Global Interfaces of ReactApplicationContext

[0059]

[0060]

[0061] Regarding Table 2 above, the global interface of ReactApplicationContext is initialized and created by the global interface of ReactInstanceManager. When ReactInstanceManager notifies ReactPackages of changes, genModuleRegistry dynamically generates a new module registry by comparing it with the original module registry, thus updating the context environment in real time.

[0062] Table 3 CatalystInstance Global Interface

[0063]

[0064] Regarding Table 3 above, the CatalystInstance global interface is initialized and created by the ReactApplicationContext global interface. CatalystInstance has direct access to the context environment and can communicate with JavaScriptCore, which maps the module registry of the context environment to the JS runtime environment.

[0065] Step 2: Initialize the ReactApplicationContext and CatalystInstance contexts.

[0066] The initialization process managed by reactInstanceManager ultimately creates the ReactApplicationContext. During context creation, four instance objects are primarily constructed to prepare for subsequent operation and communication. See Table 1; the four instance objects constructed include JSBundleLoader, JavaScriptExecutor, JavaScriptModuleRegistry, and NativeModuleRegistry, where:

[0067] JSBundleLoader can retrieve and load JS files from local or cloud environments, and it encapsulates the relevant interfaces for loading JS files.

[0068] JavaScriptExecutor, by associating with JavaScriptCore in the Bridge layer, can perform the interpretation and execution of JS files;

[0069] JavaScriptModuleRegistry initializes the JS module registry, is associated with application layer modules, and collects interface information of all application layer modules.

[0070] NativeModuleRegistry initializes the Java module registry, is associated with the underlying Native modules, and collects all Native underlying module interface information.

[0071] The information of the four instance objects constructed above is uniformly stored in the CatalystInstance global interface and corresponds to the current context.

[0072] CatalystInstance handles the initialization from the Java layer to the JNI layer and manages the core tasks on the Java side of the Bridge layer. During initialization, it creates three threads: nativeModuleThread, jsThread, and uiThread, to handle underlying module calls, JS event collection, and UI rendering tasks, respectively. Finally, the JNI layer calls initializeBridge to establish a connection with the Bridge layer, associating Java layer objects with the Bridge layer. After completing the context creation, the application's JS files can be loaded.

[0073] Based on the global interfaces ReactApplicationContext and CatalystInstance obtained during initialization, the following optimizations can be performed on the application startup process:

[0074] First, global initialization can be performed, specifically including the following:

[0075] When the application starts and the React Native framework is invoked via `startReactApplication`, if the existence of a `reactInstanceManager` instance is not detected, the `reactInstanceManager` initialization process begins. First, a `ReactApplicationContext` is created, which includes two parts of initialization: one is the initialization of two global interfaces, `JSBundleLoader` and `JavaScriptExecutor`, used to load and execute JS files; the other is the initialization of empty Java and JS module registries. Second, a `CatalystInstance` is created and bound to the context, three threads—`nativeModuleThread`, `jsThread`, and `uiThread`—are initialized, and `initializeBridge` is called to establish a connection with the Bridge layer.

[0076] Then, the module can be loaded, specifically including the following:

[0077] When a new ReactRootView is created and the React Native framework is invoked via `startReactApplication`, if a `reactInstanceManager` instance is detected, the ReactPackages associated with the ReactRootView environment are compared with the original module registry through the configuration interface. Unnecessary modules are destroyed, and new modules are registered. After the context environment is updated, the JS executable file is retrieved from the newly configured Bundle path via the JSBundleLoader in the context environment. The JavaScriptExecutor in the Bridge layer converts the file content into a string format that the JS engine can recognize, and then runs it in JavaScriptCore. Once the JS package content is loaded, the underlying Java is notified to bind the `reactInstanceManager` to the ReactRootView. The view is then rendered on the new ReactRootView through the Bridge layer and the underlying uiThread.

[0078] Specifically, regarding the module loading process described above, the ReactPackages related to the ReactRootView environment are compared with the original module registry through the configuration interface. Unnecessary modules are destroyed, and new modules are registered. This can be illustrated by taking the updating of the Native underlying module registry as an example.

[0079] For applications built on the React Native framework as described in the background section, the construction of underlying modules is associated with `reactInstanceManager`. During `reactInstanceManager` initialization, all configured underlying modules are instantiated, and when it is destroyed from the terminal memory, all underlying module instances are also destroyed. Clearly, this purely static module management method incurs unnecessary performance overhead due to frequent creation and destruction. In this embodiment, by making `reactInstanceManager` global, the initialization and destruction process of `reactInstanceManager` is eliminated, and the creation of underlying modules is retained in memory for a long time. However, some modules are unrelated to the current environment and may occupy terminal memory. Using dynamic module memory management to handle module creation and destruction can optimize terminal memory usage. For the global `reactInstanceManager`, a module management class `DynamicModules` can be constructed to globally manage underlying modules. For example, when the terminal receives an instruction to switch from the current page to a new page (these two pages are two pages in an application written based on the React Native framework), the module management class can convert the module registry ReactPackages corresponding to the current page into a module tree. For instance, the module management class retrieves the list of underlying modules from ReactPackages, compares it with the environment's module dependency information, removes duplicate underlying modules, and organizes them into a module tree according to the module hierarchy. Each module node corresponds to an underlying module; adding a node instantiates the module in memory, and deleting a node destroys the module instance. Figure 2 The diagram shown is a schematic representation of a module tree generation process provided in an embodiment of this application. Figure 2 Figure (a) in the diagram represents the module registry. Figure 2 Figure (b) in the diagram represents the module tree; on the other hand, the module management class can generate the corresponding module tree based on the module configuration file indicated by the instruction to switch to a new page. For example... Figure 3 The diagram shown is a schematic representation of a module update determination method provided in an embodiment of this application. Figure 3 Figure (a) in the diagram represents the module tree corresponding to the current page (see also...). Figure 2 (Figure (b) in the middle) Figure 3Figure (b) in the diagram represents the module tree corresponding to the new page. Then, by comparison... Figure 3 Figure (a) and Figure 3 As shown in Figure (b), modules 2, 5, 6, 11, 12, 4, and 10 need to be deleted from the module registry corresponding to the current page; modules 14, 15, and 16 need to be added to the module registry corresponding to the current page; and modules 1, 3, 7, 8, 9, and 13 remain unchanged in the module registry corresponding to the current page.

[0080] In the React Native framework, the Activity container contains ReactRootView and reactInstanceManager. Globalizing reactInstanceManager isolates it from the Activity container, achieving local memory optimization. However, the Activity still stores a significant amount of state information to handle state transitions between containers, thus requiring the creation of multiple containers. In reality, for the React Native framework, the Activity container primarily relies on a single ReactRootView for view rendering, with render control managed by reactInstanceManager. Building on this, a history state management class, SnapshotManager, can be designed to retain the state information of each view. This allows ReactRootView to be globalized, requiring only a single Activity container for view transitions, thus optimizing terminal memory usage.

[0081] In this embodiment, the Activity container binds a global ReactRootView and a global reactInstanceManager. When the implementation view navigates forward, the view's historical state information is pushed onto the stack of the historical state management class. The reactInstanceManager loads the new context and runs the JS executable file, resetting the ReactRootView to render the new view. When the implementation view navigates backward, the view's historical state information is pushed onto the temporary storage area of ​​the historical state management class. The most recent historical state information is retrieved from the historical state management class's stack, and the states of the reactInstanceManager and ReactRootView are reset to the original view.

[0082] The view history status information is divided into four parts:

[0083] First, the historical state in ReactRootView is backed up, backing up all underlying rendered views for easy re-rendering after rollback, and backing up all environment parameters so that they correspond one-to-one with the application layer environment.

[0084] Secondly, the historical state in reactInstanceManager is backed up, and the module registry in the context environment is backed up, so that the consistency of the two-end module mapping table can be achieved again through the Bridge layer after retracing.

[0085] Thirdly, the historical state in the module management class DynamicModules is backed up to the current module tree structure, which facilitates the re-instantiation of the underlying modules after backtracking. Due to the frequency of backtracking operations, the underlying modules of the most recently backed-up module tree are temporarily stored and not destroyed immediately.

[0086] Fourthly, the historical state in JavaScriptCore is backed up, including the Virtual DOM tree structure, which allows for direct use of the historical view after backtracking without rebuilding. Global variables and event objects are also backed up to prevent pollution of the subsequent runtime environment and to allow direct restoration to the historical state after backtracking. Since there is only one JS runtime environment, the above-mentioned backup states are still cached in JavaScriptCore, but are isolated from the current runtime.

[0087]

[0088]

[0089] Table 4 Historical Status Management Interfaces

[0090] During the operation of the React Native framework, if based on the background technical solution, as the number of Activities increases, the initialization of an equal number of ReactRootView and reactInstanceManager instances can easily lead to a high memory growth rate. Through the embodiments of this application, global memory management optimization reuses a single Activity container and utilizes the SnapshotManager class to manage historical states, achieving globalization of React Native instance management and significantly reducing the memory growth rate with route navigation.

[0091] Based on the technical solution described above, embodiments of this application provide a page display method. For example... Figure 4 The diagram illustrates a page display method provided in an embodiment of this application, wherein the application containing the page is built using the React Native framework; the method includes the following steps:

[0092] Step 401: In response to a user instruction to display the second page, update the context of the first rendering management instance from the first page to the second page, thereby obtaining the second rendering management instance; the first rendering management instance is obtained based on a global rendering management object constructed when the application starts; the first page is the current display page of the application.

[0093] Step 402: Based on the second rendering management instance, obtain the JS execution file corresponding to the second page.

[0094] Step 403: Bind the second view rendering instance of the second page to the second rendering management instance, and execute the JS executable file to obtain the rendered second page.

[0095] For applications built on the React Native framework, this embodiment constructs a global rendering management object at application startup. Thus, when a user commands the display of a second page from the current page (i.e., the first page), the global rendering management object is used to execute the context from the first page to the second page on the first rendering management instance. This generates a second rendering management instance, which can then be used to obtain the corresponding JavaScript executable file for the second page. After binding the second view rendering instance and the second rendering management instance, executing the JavaScript executable file renders and displays the second page. This method, by configuring a global rendering management object, allows for comparison of content elements between the two pages during display to determine which elements need modification, while retaining common content elements. This effectively manages the application's memory usage on the terminal during runtime.

[0096] In one implementation of step 401 above, before responding to the user instruction to display the second page, the method further includes: initializing a file loading interface and a file conversion interface, and initializing a first module registry for the application layer and a second module registry for the underlying layer; initializing the underlying module thread, the JS event collection thread, and the user interface rendering thread, and initializing the bridge layer creation thread; the bridge layer creation thread is used to create a connection between the application layer and the underlying layer.

[0097] For details, please refer to the global encapsulation interface design in the previous example.

[0098] In another implementation of step 401 above, the step of updating the context environment of the first rendering management instance from the first page to the second page to obtain the second rendering management instance includes: obtaining the second module configuration file of the second page; updating the module registry of the first rendering management instance according to the second module configuration file to obtain the second rendering management instance.

[0099] In some embodiments of this application, the step of updating the module registry of the first rendering management instance according to the second module configuration file to obtain the second rendering management instance includes: constructing the module registry into a first module tree based on the module management class; constructing the second module configuration file into a second module tree based on the module management class; and updating the module registry according to the comparison result between the first module tree and the second module tree to obtain the second rendering management instance.

[0100] For details, please refer to the examples above. Figure 2 and Figure 3 The content loaded by the module shown.

[0101] In one implementation of step 402 above, obtaining the JS executable file corresponding to the second page based on the second rendering management instance includes: obtaining the JS executable file corresponding to the second page based on the file loading interface in the second rendering management instance; and converting the JS executable file into Java low-level executable instructions based on the file conversion interface in the second rendering management instance.

[0102] Through the control of the global rendering management object, the second rendering management instance encapsulates file loading and file conversion interfaces. Therefore, after the second rendering management instance is generated, the JS executable file corresponding to the second page can be obtained through the file loading interface, and the JS executable file can be converted into Java low-level executable instructions through the file conversion interface.

[0103] In one implementation of step 403 above, binding the second view rendering instance of the second page to the second rendering management instance includes: after converting the JS executable file through the bridging layer, sending instruction information to the Java underlying layer; and in the Java underlying layer, binding the second view rendering instance of the second page to the second rendering management instance based on the instruction information, and executing the converted JS executable file to obtain the rendered second page.

[0104] This approach ensures consistency between the view and its context by binding the real-time view rendering instance to the global rendering management instance.

[0105] In some embodiments of this application, a second view rendering instance is obtained by: resetting a first view rendering instance to a global view rendering object; the global view rendering object is constructed based on the application startup time; and the global view rendering object is instantiated based on the virtual DOM tree obtained from the JS executable file to obtain the second view rendering instance.

[0106] In some implementations of this application, before obtaining the second rendering management instance, the method further includes: pushing the view history state information of the first page onto the stack of the history management state class; the view history state information is used for page backtracking; the view history state information includes at least the history state of the first view rendering instance, the history state of the first rendering management instance, the history state of the module management class, and the history state of the JS engine.

[0107] For details, please refer to the explanation of the historical state class in the previous example.

[0108] Based on the same concept, embodiments of this application provide a page display device, wherein the application containing the page is built using the React Native framework. Figure 5 The diagram shown is a schematic of a page display device provided in an embodiment of this application. The device includes a second rendering management instance generation unit 501, a JS executable file acquisition unit 502, and a second page display unit 503.

[0109] The second rendering management instance generation unit 501 is used to update the context environment of the first rendering management instance from the first page to the second page in response to a user instruction to display the second page, thereby obtaining the second rendering management instance; the first rendering management instance is obtained based on a global rendering management object constructed when the application starts; the first page is the current display page of the application;

[0110] The JS execution file acquisition unit 502 is used to acquire the JS execution file corresponding to the second page based on the second rendering management instance;

[0111] The second page display unit 503 is used to bind the second view rendering instance of the second page to the second rendering management instance, and execute the JS executable file to obtain the rendered second page.

[0112] Furthermore, for this device, the second rendering management instance generation unit 501 is specifically used to: obtain the second module configuration file of the second page; update the module registry of the first rendering management instance according to the second module configuration file, and obtain the second rendering management instance.

[0113] Furthermore, for this device, the JS executable file acquisition unit 502 is specifically used to: acquire the JS executable file corresponding to the second page based on the file loading interface in the second rendering management instance; and convert the JS executable file into Java low-level executable instructions based on the file conversion interface in the second rendering management instance.

[0114] Furthermore, for this device, the second page display unit 503 is specifically used to: after converting the JS executable file through the bridging layer, send instruction information to the Java underlying layer; in the Java underlying layer, based on the instruction information, bind the second view rendering instance of the second page to the second rendering management instance, and execute the converted JS executable file to obtain the rendered second page.

[0115] Furthermore, for this device, the second rendering management instance generation unit 501 is specifically used to: construct a first module tree from the module registry based on the module management class; construct a second module tree from the second module configuration file based on the module management class; and update the module registry according to the comparison result between the first module tree and the second module tree, thereby obtaining the second rendering management instance.

[0116] Furthermore, the device also includes an initialization configuration unit 504; the initialization configuration unit 504 is used to: initialize a file loading interface and a file conversion interface, and initialize a first module registry for the application layer and a second module registry for the underlying layer; initialize an underlying module thread, a JS event collection thread and a user interface rendering thread, and initialize a bridge layer creation thread; the bridge layer creation thread is used to create a connection between the application layer and the underlying layer.

[0117] Furthermore, the device also includes a second view rendering instance generation unit 505; the second view rendering instance generation unit 505 is used to: reset the first view rendering instance to a global view rendering object; the global view rendering object is constructed based on the application startup; and instantiate the global view rendering object based on the virtual DOM tree obtained from the JS executable file to obtain the second view rendering instance.

[0118] Furthermore, for this device, the second view rendering instance generation unit 505 is also used to: push the view history state information of the first page into the stack of the history management state class; the view history state information is used for page backtracking; the view history state information includes at least the history state of the first view rendering instance, the history state of the first rendering management instance, the history state of the module management class, and the history state of the JS engine.

[0119] This application also provides a computing device, which may specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), etc. The computing device may include a central processing unit (CPU), memory, input / output devices, etc. Input devices may include a keyboard, mouse, touchscreen, etc., and output devices may include display devices, such as liquid crystal displays (LCDs) and cathode ray tubes (CRTs).

[0120] The memory may include read-only memory (ROM) and random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In the embodiments of this application, the memory may be used to store program instructions for a page display method;

[0121] The processor is used to call program instructions stored in the memory and execute a cache refresh method according to the obtained program.

[0122] like Figure 6 The diagram shown is a schematic representation of a computing device provided in an embodiment of this application. The computing device includes:

[0123] The processor 601, memory 602, transceiver 603, and bus interface 604 are included; wherein the processor 601, memory 602, and transceiver 603 are connected via bus 605.

[0124] The processor 601 is used to read the program in the memory 602 and execute the above-described page display method;

[0125] Processor 601 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. It can also be a hardware chip. The aforementioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0126] The memory 602 is used to store one or more executable programs and can store data used by the processor 601 when performing operations.

[0127] Specifically, the program may include program code, which includes computer operation instructions. Memory 602 may include volatile memory, such as random-access memory (RAM); memory 602 may also include non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 602 may also include combinations of the above types of memory.

[0128] Memory 602 stores the following elements: executable modules or data structures, or subsets thereof, or extended sets thereof:

[0129] Operation instructions: This includes various operation instructions used to perform various operations.

[0130] Operating system: includes various system programs used to implement various basic business functions and handle hardware-based tasks.

[0131] The 605 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0132] Bus interface 604 can be a wired communication interface, a wireless bus interface, or a combination thereof. The wired bus interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless bus interface can be a WLAN interface.

[0133] This application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform a page display method.

[0134] Those skilled in the art will understand that embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0135] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0136] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0137] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0138] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0139] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A page display method, characterized in that, The application containing the page is built using the React Native framework; the method includes: In response to a user command to display a second page, the context of the first rendering management instance is updated from the first page to the second page, thereby obtaining a second rendering management instance; the first rendering management instance is obtained based on a global rendering management object constructed when the application starts; the first page is the current display page of the application; Based on the second rendering management instance, obtain the JS execution file corresponding to the second page; Bind the second view rendering instance of the second page to the second rendering management instance, and execute the JS executable file to obtain the rendered second page; The step of updating the context of the first rendering management instance from the first page to the second page, thereby obtaining the second rendering management instance, includes: Obtain the second module configuration file of the second page; The module registry of the first rendering management instance is updated according to the second module configuration file to obtain the second rendering management instance; The step of updating the module registry of the first rendering management instance according to the second module configuration file to obtain the second rendering management instance includes: The module registry is constructed into a first module tree based on the module management class; Based on the module management class, the second module configuration file is constructed into a second module tree; Based on the comparison results between the first module tree and the second module tree, the module registry is updated to obtain the second rendering management instance; The second view rendering instance is obtained in the following ways: The first view rendering instance is reset to a global view rendering object; the global view rendering object is built based on the application startup. Based on the virtual DOM tree obtained from the JS executable file, the global view rendering object is instantiated to obtain the second view rendering instance.

2. The method as described in claim 1, characterized in that, The step of obtaining the JS execution file corresponding to the second page based on the second rendering management instance includes: The JS execution file corresponding to the second page is obtained based on the file loading interface in the second rendering management instance; The JS executable file is converted into Java low-level executable instructions based on the file conversion interface in the second rendering management instance.

3. The method as described in claim 1, characterized in that, The step of binding the second view rendering instance of the second page to the second rendering management instance includes: After the JS executable file is converted by the bridging layer, instruction information is sent to the underlying Java layer. Based on the instruction information in the Java underlying layer, the second view rendering instance of the second page is bound to the second rendering management instance, and the converted JS executable file is executed to obtain the rendered second page.

4. The method according to any one of claims 1 to 3, characterized in that, The response to the user instruction to display the second page also includes: Initialize the file loading interface and file conversion interface, as well as initialize the first module registry for the application layer and the second module registry for the underlying layer; Initialize the underlying module thread, the JS event collection thread, and the user interface rendering thread, as well as the bridge layer creation thread; the bridge layer creation thread is used to create the connection between the application layer and the underlying layer.

5. The method as described in claim 1, characterized in that, Before obtaining the second rendering management instance, the process also includes: The view history state information of the first page is pushed onto the stack of the history management state class; the view history state information is used to backtrack the page; the view history state information includes at least the history state of the first view rendering instance, the history state of the first rendering management instance, the history state of the module management class, and the history state of the JS engine.

6. A computer device, characterized in that, include: Memory, used to store computer programs; A processor is configured to invoke a computer program stored in the memory and execute the method as described in any one of claims 1-5 according to the obtained program.

7. A computer-readable storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to perform the method as described in any one of claims 1-5.

Images