CN113986424A - 一种页面显示方法及装置 - Google Patents

Abstract

本发明涉及金融科技(Fintech)领域，公开一种页面显示方法及装置，页面所在的应用程序通过React Native框架构建；响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到第二页面的上下文环境的更新，从而得到第二渲染管理实例；基于第二渲染管理实例，获取第二页面对应的JS执行文件；将第二页面的第二视图渲染实例与第二渲染管理实例绑定，并执行JS执行文件得到渲染后的第二页面。该方式通过配置全局化的渲染管理对象，以使得在页面显示的过程中，可对前后两个页面的内容要素进行比较后而确定需要变更的内容要素，同时保留两个页面中内容要素为相同的一些内容要素，如此可以合理化的管理应用程序在运行时对终端的内存的占用问题。

Description

一种页面显示方法及装置

技术领域

本申请实施例涉及金融科技(Fintech)领域，尤其涉及一种页面显示方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术(例如：大数据、云计算或区块链)应用在金融领域，传统金融业正在逐步向金融科技转变。比如，对于银行而言，银行可以通过开发包含有各种各样的网上银行服务的应用程序并进行发布，从而用户通过自己日常使用的终端在对该应用程序进行下载、注册后，即可通过该应用程序完成对相关银行业务的办理，如此提升了银行带给用户的体验。

目前，银行可以通过React Native框架编写相关服务对应的应用程序并进行该应用程序的发布；然而，用户在对基于React Native框架编写的该应用程序进行使用时，该应用程序容易对它所在的用户终端的内存造成很大的占用。此方案显然容易导致用户放弃使用该应用程序，从而造成网上银行客户流失的问题。

因此，对于目前的基于React Native框架编写的应用程序在运行时易对用户终端内存造成很大占用的问题，亟需一种相应的解决方案。

发明内容

本申请提供一种页面显示方法及装置，用以克服页面显示过程中对终端内存造成巨大占用的问题。

第一方面，本申请实施例提供一种页面显示方法，该页面所在的应用程序通过React Native框架构建；该方法包括：响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例；所述第一渲染管理实例是基于所述应用程序启动时构建的全局化的渲染管理对象得到的；所述第一页面为所述应用程序当前的显示页面；基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件；将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行所述JS执行文件得到渲染后的所述第二页面。

对于基于React Native框架编写而成的应用程序在对各页面进行显示的过程，本申请实施例通过在应用程序启动时构建全局化的渲染管理对象，从而对于用户就当前页面(即第一页面)发出的显示第二页面的指令，则仅需要利用全局化的渲染管理对象对第一渲染管理实例执行从第一页面到第二页面的上下文环境的，即可得到第二渲染管理实例，进而可基于第二渲染管理实例获取第二页面对应的JS执行文件，并在将第二页面的第二视图渲染实例和第二渲染管理实例绑定后，通过执行该JS执行文件就可以将第二页面渲染后进行显示。该方式通过配置全局化的渲染管理对象，以使得在页面显示的过程中，可对前后两个页面的内容要素进行比较后而确定需要变更的内容要素，同时保留两个页面中内容要素为相同的一些内容要素，如此可以合理化的管理应用程序在运行时对终端的内存的占用问题。

在一种可能实现的方法中，所述对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例，包括：获取所述第二页面的第二模块配置文件；根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例。

上述方案中，基于终端目前正在显示第一页面，而接收到用户发出的显示第二页面的指令，则可以通过获取第二页面的第二模块配置文件，并根据其对第一渲染管理实例的模块注册表进行更新，从而可以得到第二渲染管理实例。通过该方式，仅需要对第二页面与第一页面分别对应的内容要素中不相同的内容要素进行更新，而并非使用第二页面对应的各内容要素全面覆盖第一页面对应各内容要素，如此可以极大地节省终端在减少由第一页面切换显示到第二页面的过程中的内存消耗。

在一种可能实现的方法中，所述基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件，包括：基于所述第二渲染管理实例中的文件加载接口获取所述第二页面对应的JS执行文件；基于所述第二渲染管理实例中的文件转换接口将所述JS执行文件转换为Java底层可运行的指令。

上述方案中，第二渲染管理实例中由于封装有文件加载接口和文件转换接口，因此在生成第二渲染管理实例后，可以通过其中的文件加载接口来获取第二页面对应的JS执行文件，并通过其中的文件转换接口将该JS执行文件转换为Java底层可运行的指令。

在一种可能实现的方法中，所述将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，包括：通过桥接层在对所述JS执行文件进行转换后，向Java底层发送指示信息；在Java底层中基于所述指示信息，将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行转换后的所述JS执行文件得到渲染后的所述第二页面。

上述方案中，在第二渲染管理实例使用封装于桥接层中的文件转换接口将JS执行文件进行转换后，可向Java底层发送指示信息，从而在Java底层接收到的该指示信息后，可将第二页面的第二视图渲染实例与第二渲染管理实例进行绑定，并执行转换后的JS执行文件可以将第二页面渲染后进行展示。该方式通过将实时的视图渲染实例与全局的渲染管理实例进行绑定，可保证视图与上下文环境的一致性。

在一种可能实现的方法中，所述根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例，包括：基于模块管理类将所述模块注册表构建为第一模块树；基于所述模块管理类将所述第二模块配置文件构建为第二模块树；根据所述第一模块树与所述第二模块树的比较结果，对所述模块注册表进行更新，从而得到所述第二渲染管理实例。

上述方案中，通过将模块注册表和第二模块配置文件都转换成树形结构，因为树形结构中不存在模块节点的重复，因此可以基于对两个树形结构的对比，能快速地确定模块注册表需要被更新的内容，并进行准确地更新。

在一种可能实现的方法中，所述响应于显示第二页面的用户指令之前，还包括：初始化文件加载接口和文件转换接口，以及初始化针对于应用层的第一模块注册表和针对于底层的第二模块注册表；初始化底层模块线程、JS事件收集线程和用户界面渲染线程，以及初始化桥接层创建线程；所述桥接层创建线程用于创建应用层和底层之间的连接。

上述方案中，在应用程序初始启动的过程中，通过初始化创建文件加载接口和文件转换接口，初始化创建针对于应用层的第一模块注册表和针对于底层的第二模块注册表，此外还包括初始化创建底层模块线程、JS事件收集线程和用户界面渲染线程，以及初始化桥阶层创建线程，基于该些初始化创建的接口、空的模块注册表以及线程，则后续在页面切换展示的过程中，可以基于接口对模块注册表进行更新，并基于更新后的模块注册表、通过调用相关的线程可对第二页面进行显示。

在一种可能实现的方法中，通过如下方式得到第二视图渲染实例，包括：将第一视图渲染实例复位为全局化的视图渲染对象；所述全局化的视图渲染对象基于所述应用程序启动时构建；基于所述JS执行文件得到的虚拟DOM树，实例化所述全局化的视图渲染对象，得到所述第二视图渲染实例。

上述方案中，对于基于React Native框架编写而成的应用程序在对各页面进行显示的过程，本申请实施例通过在应用程序启动时构建全局化的视图渲染对象，从而在页面切换显示的过程中，可将上一页面复位为全局化的视图渲染对象，然后将基于JS执行文件得到的虚拟DOM树实例化该全局化的视图渲染对象，从而可以得到用于显示下一页面的视图渲染实例。

在一种可能实现的方法中，所述得到第二渲染管理实例之前，还包括：将所述第一页面的视图历史状态信息压入历史管理状态类的堆栈中；所述视图历史状态信息用于对页面回溯；所述视图历史状态信息至少包括第一视图渲染实例的历史状态、第一渲染管理实例的历史状态、模块管理类的历史状态及JS引擎的历史状态。

上述方案中，通过将第一页面的视图历史状态信息压入历史状态类的堆栈中，则可以通过堆栈对页面进行回溯，提升了页面回溯过程的效率。

第二方面，本申请实施例提供一种页面显示装置，所述页面所在的应用程序通过React Native框架构建；该装置包括：第二渲染管理实例生成单元，用于响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例；所述第一渲染管理实例是基于所述应用程序启动时构建的全局化的渲染管理对象得到的；所述第一页面为所述应用程序当前的显示页面；JS执行文件获取单元，用于基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件；第二页面显示单元，用于将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行所述JS执行文件得到渲染后的所述第二页面。

第三方面，本申请实施例提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如第一方面任一实现方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如第一方面任一实现方法。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种React Native框架的示意图；

图2为本申请实施例提供的一种模块树的生成过程示意图；

图3为本申请实施例提供的一种确定模块更新的示意图；

图4为本申请实施例提供的一种页面显示方法的示意图；

图5为本申请实施例提供的一种页面显示装置的示意图；

图6为本申请实施例提供的一种计算设备。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

React Native是Facebook于2015年开源的一款移动框架，属于受限于移动HTML5.0(HyperText Markup Language 5.0，超文本标记语言第五版)的性能差距与原生开发的开发维护成本而产生的技术方案。React Native基于React框架理念，可实现应用层逻辑的开发与UI(UserInterface，用户界面)的渲染；同时，底层因为封闭了原生平台的方法和一个JS的运行环境，从而可抹平各个移动平台的差异。正因为它是以Web的标准进行设计的，因此可以使得开发者能够用高效便捷的Web开发模式来构建移动应用程序。

React Native摆脱了WebView的束缚，可通过Bridge(桥接)的方式，将应用层中组件渲染的信息传递给底层来实现绘制与渲染，而模块的调用和事件的捕获等，也需要基于应用层与底层的通信机制来得以实现。其中，如图1所示，为本申请实施例提供的一种ReactNative框架的示意图，其中自上而下依次为Web应用层、Bridge桥接层、Module定制层和Native底层。

用户基于React Native框架编写的应用层逻辑会被打包成一个JS文件，其既可以集成在应用安装包中，也可以通过云端服务器进行分发。React Native框架的核心功能表现为通过内部的JavaScriptCore来解释并执行JS文件。其中，对React Native框架对JS文件的处理方式可包括以下两种情况：

情况1：若JS文件为通过Web方式编写的UI组件信息，则会映射成Virtual DOM(虚拟DOM树)的数据结构来进行存储，并通过Bridge桥接层传递到Native底层，从而Native底层可根据之前的Virtual DOM的数据结构中的属性信息设置真实的View视图信息；

情况2：若JS文件为纯粹的底层接口调用信息，则直接通过Bridge桥接层即可通知Native底层执行。

其中，通过Bridge桥接层，可实现应用层代码与底层代码的通信与数据传递，Bridge桥接层的存在使得对应用层的开发工作可以相互独立。

Native底层同时运行着UI主线程和JS线程，其中JS线程不断收集来自应用层的事件响应，然后将数据信息转发给UI主线程，最后将在Native底层完成真实的事件响应。

以终端的操作系统是Android(安卓)为例，对于在该操作系统上、基于ReactNative框架而编写的应用程序，它对页面内容进行显示的唯一入口是需要在Android的一个Activity容器中实例化出ReactRootView(渲染管理实例)，然后通过startReactApplication来启动初始化过程，初始化过程主要由reactInstanceManager(渲染管理实例)来主管，等到初始化和应用层的JS文件解释运行完成之后，页面内容就会完整的加载到ReactRootView中。对于上述描述的对页面内容进行显示的过程，reactInstanceManager主管整个初始化的过程，初始化生成的上下文与ReactRootView一一对应，ReactRootView和reactInstanceManager都附属于同一个Activity容器。此外，若从NativeView开启新的ReactRootView的话，会实例化新的reactInstanceManager，再次初始化整个流程。

上述描述的对页面内容进行显示的方案暴露出以下两个缺点：

缺点1、由于reactInstanceManager主管的大部分初始化流程与Activity容器的环境无关，因此，频繁地初始化新的上下文严重影响到启动性能；

缺点2、基于ReactRootView和reactInstanceManager依附于Activity容器的事实，因此，当内存中的Activity容器数量增加时，ReactRootView和reactInstanceManager由于均保留在各Activity容器中，如此造成对内存占用的增加。

其中，可对reactInstanceManager主管的初始化流程做如下小结：

1、JSBundleLoader(文件加载接口)和JavaScriptExecutor(文件转换接口)由于是用来加载与执行JS文件的，这与JS文件的内容无关；

2、CatalystInstance中的initializeBridge初始化Bridge桥接层的操作，是用来实现应用层与Native底层之间的通信机制，因此隶属于基础设施初始化层面，而与具体场景无关；

3、JavaScriptModuleRegistry和NativeModuleRegistry需要根据具体的ReactPackage来生成模块注册表。

因此，根据上述对reactInstanceManager主管的初始化流程的分析，故本申请实施例中提出在应用程序初始启动的时候，实现一个全局的reactInstanceManager实例，也即所有的Activity容器可共用一个reactInstanceManager，从而当开启一个新的ReactRootView时，可通知reactInstanceManager更新新的Bundle路径位置。由于初始化过程只会在第一次应用程序调用的时候执行，因此，之后只要检测到reactInstanceManager实例存在，可通过动态修应用层和Native底层各自的模块注册表，并通过Bridge桥接层，便可实现应用层和Native底层两端的一致性。通过该种方式，因为不必每次都要重新创建reactInstanceManager实例，从而reactInstanceManager全局化前后随Activity容器数量变化的内存占比可极大降低，可使得终端内存增长速度明显缓减。

接下来详细描述上述方案的实现过程。

步骤1、全局封装接口设计

本申请实施例中提供的reactInstanceManager全局化接口如下表1、表2和表3所示，其中，表1为ReactInstanceManager全局化接口，表2为ReactApplicationContext全局化接口，表3为CatalystInstance全局化接口。表1、表2和表3中涉及到的所有的初始化接口只会在全局环境下运行一次，之后通过get InstanceManager来获取全局的reactInstanceManager实例。

另外，本申请中改进原设计的ReactApplicationContext和CatalystInstance两个上下文类，比如本申请中的ReactApplicationContext包含与环境有关的执行工具与模块注册表，CatalystInstance负责与Bridge桥接层的联系，把动态变化实时通知给Bridge桥接层。

表1 ReactInstanceManager全局化接口

全局封装接口	接口描述
		setReactPackages	配置ReactPackage列表
setBundlePath	配置Bundle路径
		get InstanceManager	获取InstanceManager实例
bindReactRootView	绑定ReactRootView

针对上述表1，ReactInstanceManager全局化接口负责与底层环境对接，当路由变化或者Bundle变化时，通过配置其相关接口来改变其内部的上下文环境。bindReactRootView接口可把实时的ReactRootView与全局ReactInstanceManager绑定在一起，保证视图与上下文环境的一致性。

表2 ReactApplicationContext全局化接口

针对上述表2，ReactApplicationContext全局化接口由ReactInstanceManager全局化接口初始化创建。当ReactInstanceManager通知ReactPackages变化时，genModuleRegistry通过与原来的模块注册表相比对，动态生成新的模块注册表，实时更新上下文环境。

表3 CatalystInstance全局化接口

针对上述表3，CatalystInstance全局化接口由ReactApplicationContext全局化接口初始化创建。CatalystInstance直接能够接触到上下文环境，同时能够与JavaScriptCore进行通信，由它把上下文环境的模块注册表映射到JS运行环境中。

步骤2、初始化上下文ReactApplicationContext和CatalystInstance

由reactInstanceManager管理的初始化过程中最终会创建上下文ReactApplicationContext。在创建上下文的过程中，主要构造了4个实例对象，以为后续的运行与通信作准备。参见表1，所构建的4个实例对象包括JSBundleLoader、JavaScriptExecutor、JavaScriptModuleRegistry和NativeModuleRegistry，其中：

JSBundleLoader可实现本地或者云端的JS文件的获取与载入工作，其封装了加载JS文件的相关接口；

JavaScriptExecutor通过关联Bridge桥接层的JavaScriptCore，可实现JS文件的解释与执行工作；

JavaScriptModuleRegistry初始化JS模块注册表，与应用层模块相关联，集合所有应用层模块接口信息；

NativeModuleRegistry初始化Java模块注册表，与Native底层模块相关联，集合所有Native底层模块接口信息。

上述构造的4个实例对象信息统一保存在CatalystInstance全局化接口中，并与当前的上下文相对应。

CatalystInstance可完成Java层到JNI层的初始化工作，并管理Bridge桥接层中的Java端的核心任务。在初始化的过程中，会创建nativeModuleThread，jsThread和uiThread三个线程，分别处理底层模块调用，JS事件收集和UI的渲染任务。最后在JNI层调用initializeBridge建立与Bridge层的连接，把Java层的对象关联到Bridge层中，完成上下文的创建工作之后，就可以加载应用的JS文件了。

基于初始化得到的ReactApplicationContext全局化接口和CatalystInstance全局化接口，可对应用程序的启动过程执行以下优化：

首先，可进行全局初始化，并具体包括以下内容：

在应用程序启动时，通过startReactApplication调用React Native框架时，未检测到reactInstanceManager实例的存在，开启reactInstanceManager初始化过程。首先，创建上下文环境ReactApplicationContext，其中包含两部分的初始化，一是初始化JSBundleLoader和JavaScriptExecutor两个全局化接口，用来加载执行JS文件的执行工具，二是初始化空的Java端和JS端的模块注册表；其次，创建CatalystInstance与上下文环境绑定，初始化nativeModuleThread，jsThread和uiThread三个线程，并调用intializeBridge建立与Bridge桥接层的连接。

然后，可进行模块加载，并具体包括以下内容：

当创建新的ReactRootView，通过startReactApplication调用React Native框架时，检测到reactInstanceManager实例的话，通过配置接口把与ReactRootView环境相关的ReactPackages和原先的模块注册表比较，销毁不需要的模块，注册新的模块。完成上下文环境的更新之后，通过上下文环境中的JSBundleLoader从新配置的Bundle路径中获取JS执行文件，通过Bridge层中的JavaScriptExecutor把文件内容转换成JS引擎能够识别的字符串格式，然后在JavaScriptCore中运行。当JS包的内容加载完毕后，通知Java底层，把reactInstanceManager和该ReactRootView绑定，通过Bridge桥接层和底层uiThread把视图渲染在新的ReactRootView上。

其中，针对上述模块加载过程，通过配置接口把与ReactRootView环境相关的ReactPackages和原先的模块注册表比较，销毁不需要的模块，注册新的模块，可以以对Native底层的模块注册表进行更新为例进行说明。

对于背景技术中描述的基于React Native框架编写的应用程序，底层模块的构建与reactInstanceManager相关联，在reactInstanceManager初始化过程中，实例化所有配置进来的底层模块，而在其从终端内存中销毁时，也会销毁掉所有的底层模块实例，显然这种纯静态的模块管理方式在频繁的创建、销毁中，产生不必要的性能开销。本申请实施例中通过将reactInstanceManager全局化后，消除了reactInstanceManager的初始化与销毁过程，底层模块的创建会长期保留在内存中。然而，有些模块与当前环境无关，会占用掉终端的内存，采用动态化的模块内存管理来处理模块的创建与销毁可优化终端的内存占用。针对全局化的reactInstanceManager，可构造一个模块管理类DynamicModules来全局化管理底层模块。例如，终端接收到将页面从当前页面切换到的一个新的页面的指令时(该两个页面为基于React Native框架编写的应用程序中的两个页面)，从而模块管理类一方面可以将当前页面对应的模块注册表ReactPackages转换为模块树，比如，模块管理类从ReactPackages获取底层模块列表，与环境的模块依赖信息相比较，去除重复的底层模块，并按模块层级结构组织成模块树。每一个模块节点对应一个底层模块，节点的添加会实例化模块到内存中，节点的删除会销毁该模块实例。如图2所示，为本申请实施例提供的一种模块树的生成过程示意图，其中图2中的(a)图表示模块注册表，图2中的(b)图表示模块树；模块管理类另一方面可以根据切换至新的页面的指令指示的模块配置文件，生成对应的模块树。如图3所示，为本申请实施例提供的一种确定模块更新的示意图，其中，图3中的(a)图表示当前页面对应的模块树(可以参看图2中的(b)图)，图3中的(b)图表示新的页面对应的模块树，则通过比较图3中的(a)图和图3中的(b)图，则可以知道的模块2、5、6、11、12、4和10需要从当前页面对应的模块注册表中进行删除，模块14、15和16需要在当前页面对应的模块注册表进行增加，以及模块1、3、7、8、9和13则原封不动地保留在当前页面对应的模块注册表中。

在React Native框架中Activity容器包含了ReactRootView和reactInstanceManager，reactInstanceManager全局化之后，使其从Activity容器中独立出来，实现了局部内存优化。但是Activity中仍保存大量的状态信息来实现容器之间跳转过程的状态转换，因此需要创建多个容器。实际上，对于React Native框架来说，Activity容器中主要靠一个ReactRootView来实现视图的渲染，而渲染的控制又由reactInstanceManager来管理。在此基础上，设计一个历史状态管理类SnapshotManager来保留每个视图的状态信息，即可把ReactRootView全局化，只需一个Activity容器来完成视图跳转以优化终端内存。

本申请实施例中，Activity容器中绑定了全局的ReactRootView和全局的reactInstaneManager。当实现视图向前跳转时，把该视图的历史状态信息压入到历史状态管理类的堆栈中去，reactInstanceManager加载新的上下文环境并运行JS执行文件，复位ReactRootView来渲染新的视图。当实现视图向后回溯时，把该视图的历史状态信息压入到历史状态管理类的暂存区中去，从历史状态管理类的堆栈中取出最近的历史状态信息，把reactInstanceManager和ReactRootView的状态重置到原先的视图。

其中，视图历史状态信息分成四个部分：

一是ReactRootView中的历史状态，备份所有的底层渲染视图，便于回溯后重新渲染，以及备份所有的环境参数，能够与应用层环境一一对应。

二是reactInstanceManager中的历史状态，备份上下文环境中的模块注册表，便于回溯后重新通过Bridge桥接层实现双端模块映射表一致。

三是模块管理类DynamicModules中的历史状态，备份当前模块树的结构，便于回溯后重新实例化底层模块，由于回溯操作的频繁性，暂存最近一次备份的模块树的底层模块，不立即销毁。

四是JavaScriptCore中的历史状态，备份Virtual DOM树结构，便于回溯后直接使用历史视图，不必重新构建，以及备份全局变量和事件对象，防止污染之后的运行环境和回溯后直接恢复至历史状态，由于只有一个JS运行环境，上述备份状态仍然缓存在JavaScriptCore中，但是与当前运行时隔离。

表4历史状态管理类接口

React Native框架运行过程中，若依据背景技术方案，则随着Activity数量的增长，由于初始化了等量的ReactRootView和reactInstanceManager等实例，则容易导致较高的内存增长速率。通过本申请实施例，全局内存管理优化后，统一复用一个Activity容器，利用SnapshotManager类管理历史状态，实现React Native管理实例的全局化，显著降低了内存随路由跳转的增长速率。

根据上述描述的技术方案，本申请实施例提供一种页面显示方法。如图4所示，为本申请实施例提供的一种页面显示方法的示意图，其中页面所在的应用程序通过ReactNative框架构建；该方法包括以下步骤：

步骤401，响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例；所述第一渲染管理实例是基于所述应用程序启动时构建的全局化的渲染管理对象得到的；所述第一页面为所述应用程序当前的显示页面。

步骤402，基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件。

步骤403，将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行所述JS执行文件得到渲染后的所述第二页面。

对于基于React Native框架编写而成的应用程序在对各页面进行显示的过程，本申请实施例通过在应用程序启动时构建全局化的渲染管理对象，从而对于用户就当前页面(即第一页面)发出的显示第二页面的指令，则仅需要利用全局化的渲染管理对象对第一渲染管理实例执行从第一页面到第二页面的上下文环境的，即可得到第二渲染管理实例，进而可基于第二渲染管理实例获取第二页面对应的JS执行文件，并在将第二页面的第二视图渲染实例和第二渲染管理实例绑定后，通过执行该JS执行文件就可以将第二页面渲染后进行显示。该方式通过配置全局化的渲染管理对象，以使得在页面显示的过程中，可对前后两个页面的内容要素进行比较后而确定需要变更的内容要素，同时保留两个页面中内容要素为相同的一些内容要素，如此可以合理化的管理应用程序在运行时对终端的内存的占用问题。

在上述步骤401的一个实施中，所述响应于显示第二页面的用户指令之前，还包括：初始化文件加载接口和文件转换接口，以及初始化针对于应用层的第一模块注册表和针对于底层的第二模块注册表；初始化底层模块线程、JS事件收集线程和用户界面渲染线程，以及初始化桥接层创建线程；所述桥接层创建线程用于创建应用层和底层之间的连接。

该内容具体可以参见前文例子中的全局封装接口设计的内容。

在上述步骤401的另一个实施中，所述对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例，包括：获取所述第二页面的第二模块配置文件；根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例。

在本申请的某些实施中，所述根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例，包括：基于模块管理类将所述模块注册表构建为第一模块树；基于所述模块管理类将所述第二模块配置文件构建为第二模块树；根据所述第一模块树与所述第二模块树的比较结果，对所述模块注册表进行更新，从而得到所述第二渲染管理实例。

该内容具体可以参见前文例子中的图2和图3所示的模块加载的内容。

在上述步骤402的一个实施中，所述基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件，包括：基于所述第二渲染管理实例中的文件加载接口获取所述第二页面对应的JS执行文件；基于所述第二渲染管理实例中的文件转换接口将所述JS执行文件转换为Java底层可运行的指令。

通过全局化的渲染管理对象的控制，第二渲染管理实例中由于封装有文件加载接口和文件转换接口，因此在生成第二渲染管理实例后，可以通过其中的文件加载接口来获取第二页面对应的JS执行文件，并通过其中的文件转换接口将该JS执行文件转换为Java底层可运行的指令。

在上述步骤403的一个实施中，所述将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，包括：通过桥接层在对所述JS执行文件进行转换后，向Java底层发送指示信息；在Java底层中基于所述指示信息，将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行转换后的所述JS执行文件得到渲染后的所述第二页面。

该方式通过将实时的视图渲染实例与全局的渲染管理实例进行绑定，可保证视图与上下文环境的一致性。

在本申请的某些实施中，通过如下方式得到第二视图渲染实例，包括：将第一视图渲染实例复位为全局化的视图渲染对象；所述全局化的视图渲染对象基于所述应用程序启动时构建；基于所述JS执行文件得到的虚拟DOM树，实例化所述全局化的视图渲染对象，得到所述第二视图渲染实例。

在本申请的某些实施中，所述得到第二渲染管理实例之前，还包括：将所述第一页面的视图历史状态信息压入历史管理状态类的堆栈中；所述视图历史状态信息用于对页面回溯；所述视图历史状态信息至少包括第一视图渲染实例的历史状态、第一渲染管理实例的历史状态、模块管理类的历史状态及JS引擎的历史状态。

该内容具体可以参见前文例子中历史状态类的说明。

基于同样的构思，本申请实施例提供一种页面显示装置，所述页面所在的应用程序通过React Native框架构建。如图5所示，为本申请实施例提供的一种页面显示装置的示意图，该装置包括第二渲染管理实例生成单元501JS执行文件获取单元502和第二页面显示单元503；

第二渲染管理实例生成单元501，用于响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例；所述第一渲染管理实例是基于所述应用程序启动时构建的全局化的渲染管理对象得到的；所述第一页面为所述应用程序当前的显示页面；

JS执行文件获取单元502，用于基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件；

第二页面显示单元503，用于将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行所述JS执行文件得到渲染后的所述第二页面。

进一步的，对于该装置，第二渲染管理实例生成单元501，具体用于：获取所述第二页面的第二模块配置文件；根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例。

进一步的，对于该装置，JS执行文件获取单元502，具体用于：基于所述第二渲染管理实例中的文件加载接口获取所述第二页面对应的JS执行文件；基于所述第二渲染管理实例中的文件转换接口将所述JS执行文件转换为Java底层可运行的指令。

进一步的，对于该装置，第二页面显示单元503，具体用于：通过桥接层在对所述JS执行文件进行转换后，向Java底层发送指示信息；在Java底层中基于所述指示信息，将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行转换后的所述JS执行文件得到渲染后的所述第二页面。

进一步的，对于该装置，第二渲染管理实例生成单元501，具体用于：基于模块管理类将所述模块注册表构建为第一模块树；基于所述模块管理类将所述第二模块配置文件构建为第二模块树；根据所述第一模块树与所述第二模块树的比较结果，对所述模块注册表进行更新，从而得到所述第二渲染管理实例。

进一步的，对于该装置，还包括初始化配置单元504；初始化配置单元504，用于：初始化文件加载接口和文件转换接口，以及初始化针对于应用层的第一模块注册表和针对于底层的第二模块注册表；初始化底层模块线程、JS事件收集线程和用户界面渲染线程，以及初始化桥接层创建线程；所述桥接层创建线程用于创建应用层和底层之间的连接。

进一步的，对于该装置，还包括第二视图渲染实例生成单元505；第二视图渲染实例生成单元505，用于：将第一视图渲染实例复位为全局化的视图渲染对象；所述全局化的视图渲染对象基于所述应用程序启动时构建；基于所述JS执行文件得到的虚拟DOM树，实例化所述全局化的视图渲染对象，得到所述第二视图渲染实例。

进一步的，对于该装置，第二视图渲染实例生成单元505，还用于：将所述第一页面的视图历史状态信息压入历史管理状态类的堆栈中；所述视图历史状态信息用于对页面回溯；所述视图历史状态信息至少包括第一视图渲染实例的历史状态、第一渲染管理实例的历史状态、模块管理类的历史状态及JS引擎的历史状态。

本申请实施例还提供了一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。该计算设备可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器，可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储页面显示方法的程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行缓存刷新方法。

如图6所示，为本申请实施例提供的一种计算设备的示意图，该计算设备包括：

处理器601、存储器602、收发器603、总线接口604；其中，处理器601、存储器602与收发器603之间通过总线605连接；

所述处理器601，用于读取所述存储器602中的程序，执行上述页面显示方法；

处理器601可以是中央处理器(central processing unit，简称CPU)，网络处理器(network processor，简称NP)或者CPU和NP的组合。还可以是硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，简称ASIC)，可编程逻辑器件(programmable logic device，简称PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，简称CPLD)，现场可编程逻辑门阵列(field-programmable gate array，简称FPGA)，通用阵列逻辑(generic array logic,简称GAL)或其任意组合。

所述存储器602，用于存储一个或多个可执行程序，可以存储所述处理器601在执行操作时所使用的数据。

具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器602可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，简称RAM)；存储器602也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，简称HDD)或固态硬盘(solid-state drive，简称SSD)；存储器602还可以包括上述种类的存储器的组合。

存储器602存储了如下的元素，可执行模块或者数据结构，或者它们的子集，或者它们的扩展集：

操作指令：包括各种操作指令，用于实现各种操作。

操作系统：包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

总线605可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

总线接口604可以为有线通信接入口，无线总线接口或其组合，其中，有线总线接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线总线接口可以为WLAN接口。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行页面显示方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种页面显示方法，其特征在于，所述页面所在的应用程序通过React Native框架构建；所述方法包括：

响应于显示第二页面的用户指令，对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例；所述第一渲染管理实例是基于所述应用程序启动时构建的全局化的渲染管理对象得到的；所述第一页面为所述应用程序当前的显示页面；

基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件；

将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行所述JS执行文件得到渲染后的所述第二页面。

2.如权利要求1所述的方法，其特征在于，

所述对第一渲染管理实例执行从第一页面到所述第二页面的上下文环境的更新，从而得到第二渲染管理实例，包括：

获取所述第二页面的第二模块配置文件；

根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例。

3.如权利要求1所述的方法，其特征在于，

所述基于所述第二渲染管理实例，获取所述第二页面对应的JS执行文件，包括：

基于所述第二渲染管理实例中的文件加载接口获取所述第二页面对应的JS执行文件；

基于所述第二渲染管理实例中的文件转换接口将所述JS执行文件转换为Java底层可运行的指令。

4.如权利要求1所述的方法，其特征在于，

所述将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，包括：

通过桥接层在对所述JS执行文件进行转换后，向Java底层发送指示信息；

在Java底层中基于所述指示信息，将所述第二页面的第二视图渲染实例与所述第二渲染管理实例绑定，并执行转换后的所述JS执行文件得到渲染后的所述第二页面。

5.如权利要求2所述的方法，其特征在于，

所述根据所述第二模块配置文件更新所述第一渲染管理实例的模块注册表，得到所述第二渲染管理实例，包括：

基于模块管理类将所述模块注册表构建为第一模块树；

基于所述模块管理类将所述第二模块配置文件构建为第二模块树；

根据所述第一模块树与所述第二模块树的比较结果，对所述模块注册表进行更新，从而得到所述第二渲染管理实例。

6.如权利要求1至5任一项所述的方法，其特征在于，

所述响应于显示第二页面的用户指令之前，还包括：

初始化文件加载接口和文件转换接口，以及初始化针对于应用层的第一模块注册表和针对于底层的第二模块注册表；

初始化底层模块线程、JS事件收集线程和用户界面渲染线程，以及初始化桥接层创建线程；所述桥接层创建线程用于创建应用层和底层之间的连接。

7.如权利要求1至5任一项所述的方法，其特征在于，

通过如下方式得到第二视图渲染实例，包括：

将第一视图渲染实例复位为全局化的视图渲染对象；所述全局化的视图渲染对象基于所述应用程序启动时构建；

基于所述JS执行文件得到的虚拟DOM树，实例化所述全局化的视图渲染对象，得到所述第二视图渲染实例。

8.如权利要求7所述的方法，其特征在于，

所述得到第二渲染管理实例之前，还包括：

将所述第一页面的视图历史状态信息压入历史管理状态类的堆栈中；所述视图历史状态信息用于对页面回溯；所述视图历史状态信息至少包括第一视图渲染实例的历史状态、第一渲染管理实例的历史状态、模块管理类的历史状态及JS引擎的历史状态。

9.一种计算机设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如权利要求1-8任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如权利要求1-8任一项所述的方法。

Images