CN105354014A - 应用界面渲染展示方法及装置 - Google Patents

Abstract

本申请公开了应用界面渲染方法及装置，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：从所述界面数据中获取所述指定组件对应的脚本函数；从所述脚本函数中提取各个基本元素的类型取值；根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；当所述动态脚本的执行事件被触发时，调用所述原生API函数。通过本申请，适合在Dynative协议框架的基础上实现组件的交互能力。

Description

应用界面渲染展示方法及装置

技术领域

本申请涉及应用界面渲染技术领域，特别是涉及应用界面渲染展示方法及装置。

背景技术

移动终端应用(App)的本质就是无数个界面的集合，因此，在传统的移动终端App开发技术中，对于一个移动终端App产品，从开发到最终用户使用一般需要经过如下过程：

第一步：将App中所有界面模块开发测试完，并将界面代码打包成一个完整的满足发布要求的App安装包；

第二步：将App安装包发布到各种渠道，例如，应用商品店(Appstore)等)，供用户下载安装App；

第三步：用户到某一渠道下载应用安装包，将App安装到自己的移动终端上，开始使用App。

这样的开发步骤决定了现有的App开发至少会遇到以下问题：无论是新功能开发，还是bug修复，或是实现方案调整优化，都需要经过从App发布新版本到用户终端设备升级到新版这个过程，才能最终让用户使用到。例如，对于终端设备中已经安装的App，在有新版本发布时，服务器一般会将新版本的更新信息推送到Appstore等渠道，用户需要手动进入Appstore具体的更新界面，触发应用的更新，相应的，服务器可以把更新后的代码等数据发送到终端设备，完成App的升级等过程。在用户手动执行更新之前，虽然用户可以继续使用该App，但是无法使用到App的最新功能。

另一方面，存在一种Hybird开发模式，这种方式的原理是，将应用的界面数据保存在服务器端，客户端将移动的API通过系统中的webview映射成JavaScript接供HTML5使用。这种方式下，如果开发者需要更新应用的界面数据，则只需要在服务器端进行更新即可，不需要修改客户端的代码，因此，不再存在向客户端发布新版本等过程，用户可以及时使用到更新后的功能。

如果能够将Hybird技术应用到移动终端的App开发过程中，则可以解决前述问题，但是，使用Hybird技术开发的App一般是用HTML5以及JavaScript编写的，这种语言无法直接被移动终端中的原生代码调用，因此，必须借助于浏览器内核(例如webkit)，并通过webview进行转换，才能在移动终端中运行。也就是说，如果在移动终端中使用Hybird开发模式，则需要借助于移动终端中安装的浏览器进行界面的展现，这会严重依赖手机操作系统中的浏览器内核webkit，而webkit是一个通用浏览器内核，发源于传统PC浏览器技术，承载了太多传统PC上的web技术，而这其中有相当一部分并不适用于移动终端，使得整个技术方案的核心显得极其笨重，也因此暴漏出一些问题。例如：

首先，所有的JavaScript都需要通过webview的中转才能映射到移动的native层中，因此，开发者对于JavaScript与webview之间以及webview与native之间的转换关系都需要进行定义，开发成本比较高；

其次，受到PC浏览器技术固有的一些安全规则限制，对本地的各种服务和资源访问受限，包括本地文件系统或网络跨域等，例如，如果某应用需要调用移动终端设备中的相机功能，则可能会出现无法调用等情况；

再者，对各提供的新特性的使用受限于webkit内核的支持，而webkit由于其要兼容继承的东西太多，一般发展会比较缓慢，这就导致hybird方案无法及时使用移动终端上各种新技术提高产品体验，例如，其就不能顺畅的使用移动终端上特有的各种传感器技术等。

为了能够让用户更为及时地使用到App的最新功能，同时又避免hybird方案的各种缺陷，本申请人提供了一种新型的渲染引擎-Dynative，并提供了相应的协议框架，该框架提供了动态化构建Android、iOS等各种移动平台原生视图组件的能力，可以直接调用移动终端设备中的原生代码对界面进行渲染，而不再依赖于浏览器的Webkit内核以及Webview。关于该协议框架，已经通过另外一件专利另行申请。

但在具体的应用界面中，有些组件在界面中展现时可能需要具备一定的交互能力，比如动态拉取数据配合列表组件展示数据、动态修改视图元素的属性，等等。可以通过脚本来实现这种交互能力。关于脚本语言，现有技术中已经有很多种，但是它们都不是十分适合Dynative框架。但是已有的脚本语言解析器相对于Dynative框架本身来说过于庞大，引入到具体的应用中时会使安装包变得非常庞大，而且与Dynative框架嫁接起来使用技术难度大，成本非常高。

因此，如何在Dynative协议框架的基础上实现组件的交互能力，是迫切需要本领域技术人员解决的技术问题。

发明内容

本申请提供了应用界面渲染展示方法及装置，实现简单，适合在Dynative协议框架的基础上实现组件的交互能力。

本申请提供了如下方案：

一种应用界面渲染方法，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

从所述界面数据中获取所述指定组件对应的脚本函数；

从所述脚本函数中提取各个基本元素的类型取值；

根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示。

一种应用界面渲染方法，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

接收客户端发送的展示指定界面的请求；

向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

一种应用界面渲染装置，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述装置包括：

数据请求单元，用于在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

脚本函数获取单元，用于从所述界面数据中获取所述指定组件对应的脚本函数；

类型取值提取单元，用于从所述脚本函数中提取各个基本元素的类型取值；

映射单元，用于根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

函数调用单元，用于当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示。

一种应用界面渲染装置，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

请求接收单元，用于接收客户端发送的展示指定界面的请求；

数据返回单元，用于向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于只定义了脚本语言所需的基本元素，没有任何多余的内容，在运行时，也只需要协议解析，不需要做复杂的语法解析、词法解析等，因此，解析器实现比较简单，体积也非常小。

另外，只有协议中定义了的脚本元素能被解析出来执行，避免了一些终端设备平台中的政策风险，也隔离了语言的安全风险。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的客户端方法的流程图；

图2是本申请实施例提供的服务器端方法的流程图；

图3是本申请实施例提供的客户端装置示意图；

图4是本申请实施例提供的服务器端装置示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解，下面首先对本申请人提供的Dynative协议框架及Dynative内核的工作原理进行介绍。在该协议框架中，提供了一种新型的渲染引擎(将其称为Dynative)，同时提供了Dynative协议，开发人员可以按照Dynative协议来开发自己的应用，编写界面数据，开发完成之后，只需要将这种界面数据保存在服务器端，并在应用的客户端中集成该Dynative渲染引擎，Dynative就可以将这种界面数据映射到具体的移动终端中运行，并实现相应的功能。为了便于理解，下面首先对Dynative协议进行介绍。

由于组件是用户界面(UI)的基本组成元素，因此，在Dynative协议中定义了多种组件，开发人员可以按照Dynative协议中定义的组件信息进行界面数据的编写。其中，所谓组件，是指可以在移动终端屏幕上展现的一个区块。

例如，Dynative协议中定义了图片组件、文本组件、列表组件、面板组件等，并对各种组件的类型说明、输入列表等进行了定义。例如，图片组件的类型说明如表1所示：

表1

属性	类型	名称	是否必选
				Type	String	Image	Y

输入列表如表2所示：

表2

这样，开发人员在编写自己的界面数据时，就可以按照上述协议来定义自需要的图片组件，例如，在某段界面数据代码中，定义了type为“image”的组件，这样，Dynative就会根据该类型名称信息，将其识别为一个图片组件，后续就可以将其映射为具体的移动终端中的原生组件。

关于文本组件、列表组件以及面板组件等其他组件，协议中也都给出了对应的类型说明以及输入列表信息，总之，框架使用者可以按照该协议中定义的组件信息，进行界面数据的编写，在运行时，Dynative再根据预先保存的组件信息与移动终端中原生组件之间的对应关系进行映射。

以上所介绍的各个组件都属于静态组件，如背景技术部分所述，在具体的应用界面中，有些组件在界面中展现时可能需要具备一定的交互能力，比如动态拉取数据配合列表组件展示数据，对数据进行基本的逻辑、算术运算、关系运算，动态修改视图元素的属性，等等。为此，本申请实施例还基于Dynative定义出了能在框架上运行的自定义脚本，允许框架使用者在界面中嵌入脚本，并由框架解析执行。

也就是说，Dynative脚本之于Dynative框架，就好比JavaScript脚本之于浏览器，当没有脚本存在的时候，Dynative框架只能展示静态的页面，没有能力提供前端交互。比如在一个商品页面中，根据接口数据，有的商品需要打“优惠价标识”，有的不需要，这个时候简单的Dynative页面无法做到动态判断哪些是有优惠价的，必须要有脚本来执行这个逻辑，并更改视图。再比如商品页面提供了收藏功能，用户点击“收藏”按钮收藏商品，按钮的文字和背景都需要改变成已收藏状态，这种交互功能也需要有脚本来执行。

为此，协议中还可以定义其他一些信息，包括：

内置变量，包括client.userid(用户id)，client.sid(身份标识)，client.ttid(客户端ttid)，client.version(客户端版本)等等。

引用方式信息，包括ui元素引用($layout开头，元素id用点隔开，例如$layout.banner.url)、变量引用($variable开头，或直接使用"$变量名"引用，例如$variable.varname)、数据引用(数据引用查找，一般以$context,$response,$args开头，根据json结构查找数据，例如{context:{data:{items:[{a:1},{b:1}]}}})、函数引用($function开头，函数方法查找，函数只支持一层查找，例如$function.method1)等。

表达式，包括二元算数运算表达式、关系表达式、逻辑表达式等等。

内置基础脚本函数，例如，string连接动作、isempty判空动作、顺序执行动作、条件执行动作、循环执行动作、属性设置动作、组件更新动作、提示动作(展现后自动消失)、alert动作、登录检查动作(如果未登录，会触发客户端登录)、远程API调用动作等等。开发人员可以使用这些基础脚本函数来定义一些动态交互内容等，并且还可以使用基础脚本函数组装自定义函数。

这样，可以基于以下基本流程实现Dynative脚本：

首先，定义脚本中涉及到的基本元素，包括运算符、语句、函数等，为每一种基本元素定义语法，也就是协议。

这样，框架使用者就可以采用通用的一定的数据格式(例如，JSON)来实现上述基本元素的脚本化定义。

Dynative框架负责解析这些JSON定义，并实例化成具体运行时的函数对象，在运行时根据协议来执行函数对象中的逻辑。

需要说明的，除了在协议中定义脚本中的各种语法等之外，还需要预先保存脚本中的各种脚本函数与具体的移动终端中的原生API函数之间的对应关系，以便Dynative框架在解析脚本时，可以完成从JSON数据到原生API函数的映射，对此，下文中会有详细的介绍，下面首先对Dynative协议中的脚本定义方式进行介绍。

首先，在Dynative协议中，针对每一个基本元素都定义了一份协议，每一份协议里都包含了至少一个type字段，它表明了协议类型，Dynative解析器需要根据这个字段的值来解析成具体移动终端中的原生API函数对象。不同类型的协议还会包含各自独有的字段，用来引用各自所需要的数据。下面分别进行介绍。

(1)赋值

协议类型为setdata，var为变量或者视图元素属性等等的引用；value为常量、另一个变量引用、一个视图元素属性引用、一个函数调用等。

(2)取值

协议类型为getdata，type字段可以省略；value为常量、另一个变量引用、一个视图元素属性引用、一个函数调用等。

(3)二元算术运算

协议类型为add、sub、mul、div中的一种，分别代表加、减、乘、除。只能对数字进行二元算术运算，操作数的值可以为常量、变量等，也可以嵌套定义另一个二元算术运算，以其返回值作为操作数。

(4)关系运算

协议类型为eq、ne、gt、ge、lt、le中的一种，分别代表等于、不等于、大于、大于或等于、小于、小于或等于，eq和ne能对数字、字符串、布尔值进行比较运算，其他关系运算只能针对数字。操作数的值可以为常量、变量引用等，也可以嵌套定义另一个二元算术运算或其他函数，以其返回值作为操作数。

(5)逻辑运算

协议类型为and、or、not中的一种，分别代表与、或、非，当类型为not时，操作数只有一个。逻辑运算只针对布尔类型进行运算。操作数可以为常量、

变量引用等，或者嵌套另一个逻辑运算、关系运算，以其返回值作为操作数。如果涉及到两个以上条件的逻辑运算，目前只能嵌套逻辑运算来进行运算。

关系运算和逻辑运算一般用于条件判断语句。

(6)顺序语句

协议类型为call。funcs字段里可存储其他任意函数列表，顺序执行。

(7)条件语句

协议类型为condition，通过执行test里的函数调用，如果为返回结果为true，执行then里的函数，否执行else里的函数。

(8)循环语句

另外，协议中还定义了其他内置功能，与上述基本定义类似，通过一个type关键字定义类型，提供一些实用的功能，比如字符串拼接、判空、远程接口调用等等。

总之，基于上述Dynative协议，框架使用者即可进行应用的开发，定义该应用的界面数据，并且，可以是以组件为单位进行定义。具体的，所谓的界面数据可以包括界面布局数据以及各组件的内容数据，界面布局数据中可以定义出各组件的坐标、尺寸等信息；而内容数据则可以包括两种，一种是为静态组件(例如，一些简单的文本组件等)定义的静态数据内容，其可以定义出组件中具体显示的内容；另一种是为动态组件定义的数据内容，这种动态组件根据触发方式的不同可以有多种形式。例如，可以包括在视图初始化时就需要通过调用网络接口等方式来获取具体内容数据的组件(例如，界面中显示的图片、视频等，一般在定义界面数据时，可能只指出图片、视频所在的网络地址，并加以引用，而不是直接在界面数据中给出图片、视频的具体数据或数据流本身)，或者，是视图元素绑定数据的时候被触发的组件(例如，一些数据列表，可能需要从某数据库表中读取数据)，再者，还可以是根据用户的动态交互动作被触发的组件(例如，一些按钮等)。对于这种动态组件，界面数据中为其定义的内容数据可以为根据Dynative脚本协议定义的动态脚本。

关于界面布局数据以及静态数据内容在Dynative协议框架的专利中已经介绍，这里不再详述。下面主要介绍与脚本相关的动态数据内容的定义方式。

可以使用function定义界面使用到的脚本函数，脚本函数的功能包括调用某个网络接口获取界面数据、响应用户点击操作跳到其他界面等等。

例如，function的具体数据结构可以为：

按照以上方式定义完脚本函数之后，可以将其保存在服务器端，后续在需要展现该界面时，就可以使用Dynative对界面数据进行解析渲染。其中，具体在对界面数据进行解析时，Dynative的一项主要工作就是将界面数据中定义的各种组件映射为移动终端中的原生组件，在存在动态脚本的情况下，将动态脚本中的各种基本元素映射成移动终端中的原生API，并使用原生代码对这种原生API进行调用。为了完成这种映射，还需要预先保存协议中的各个组件信息与具体移动终端中的原生组件之间的对应关系，另外还需要预先保存协议中为动态脚本定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关系。

关于组件级的对应关系，本申请实施例中不再详述，而关于脚本级的对应关系，是与平台相关的。也即，对于不同的终端设备操作平台，这种对应关系是不同的。例如，对于Android而言，界面数据中的动态脚本定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关系，可以如表3所示：

表3

基本元素的类型取值	原生API函数
		tips	Toast
alert	AlertDialog
		……	……

对于iOS而言，这种对应关系可以如表4所示：

表4

基本元素的类型取值

原生API函数

tips	UIAlertView
		alert	UIActionSheet
……	……

备注：以上组件和API中只列举了两三个例子来说明原理，实际上SDK中会包含多种组件及API的映射逻辑。

这样，在通过上述方式定义了界面数据的情况下，就可以将界面数据保存在服务器端，在需要展示界面时，Dynative就可以向服务器请求界面数据，并对界面数据进行解析及渲染，下面对具体的渲染过程进行介绍。

实施例一

本申请实施例一首先从客户端的角度提供了一种应用界面渲染方法，其中，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值；参见图1，该方法具体可以包括以下步骤：

S101：在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

所谓的指定界面可以是应用的主界面，或者其他子界面，等等。在接收到展示指定界面的请求时，由于界面数据并没有跟随安装包一起下载到终端设备，因此，可以首先向服务器请求该界面的界面数据。关于界面数据的具体定义方式已经在前文中进行了介绍。

S102：从所述界面数据中获取所述指定组件对应的脚本函数；

界面数据可以是使用json等语言定义的，但是，由于用json等语言定义的界面数据无法直接被终端设备识别，因此，在接收到服务器返回的界面数据之后，Dynative内核就可以将界面数据映射到终端设备中，以便可以使用终端设备的原生代码进行调用执行。具体的，对于涉及脚本函数的动态数据内容，就可以首先通过function等关键词，获取其中的脚本函数。

S103：从所述脚本函数中提取各个基本元素的类型取值；

由于脚本函数是由至少一个基本元素表达的，因此，可以从中提取出各个基本元素的类型取值。

S104：根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

由于预先保存了各个基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，因此，就可以将所述脚本函数映射为当前移动终端中的原生API函数。

S105：当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示。

在映射为当前移动终端中的原生API函数之后，就可以使用当前终端设备的原生代码对这种原生API函数进行调用，进而实现对界面的展示。

其中，界面数据中定义的动态组件对应的动态脚本可能需要通过其他事件触发，例如页面的视图元素初始化时、视图绑定数据时，或者被用户点击等操作时，等等。但是，脚本的解析可以是一次性完成的，也即在Dynative框架启动，初始化一个Dynative页面的时候，如果发现有定义了脚本，那么就可以一次性完成所有解析。而具体的执行，则要等到视图元素触发特定事件，比如用户点击了某个按钮时，才会发生。

例如，以下是在业务中使用的Dynative脚本一个实例：它实现的功能就是通过判断传入参数里的值是否为true，来更改某个视图元素的显示或隐藏。它综合运用了条件判断、赋值运算等基本功能。结合这份示例，下面再继续介绍如何解析、执行这段脚本。

每一段Dynative脚本里由一系列函数对象的定义组成，这一系列函数往往呈嵌套关系(尤其是在用JSON这种结构化数据格式下)。就比如上面filterWapFinalPrice这段脚本里，主体是一个条件判断语句，判断语句本身调用了一段eq函数，而根据判断结果，在then、else分支里又分别调用了setdata函数。

当这样一段脚本传入Dynative解析器时，解析器也会一层层解析。每一次解析时，解析器首先提取type字段，如果type字段里的值是已注册的，也就是已经在协议中定义过的，那么根据表7或者表8中保存的对应关系，再实例化出与它映射的函数对象，并解析出其他字段里的内容。假如发现type的值不是协议里注册的，那么这段脚本将会被丢弃。当解析好一个函数对象的时候，解析器还可以将它放到一个公共函数对象池中，以该函数对象在界面数据中的id来标识它，Dynative框架的其他地方需要使用这个函数对象时，可以根据该id到该公共函数对象池中提取，而不需要再重新执行映射操作。在上述示例中这个id就是filterWapFinalPrice，只有第一层函数的id是有意义的，因为它们是一个整体，单独引用then或者else里的函数是没有意义的。

如前文所述，脚本的执行一般由事件触发，事件是指Dynative框架里定义的、在特定时候发生的事情。比如页面中的视图元素初始化的时候，视图元素绑定数据的时候，或者用户点击了按钮等控件的时候等等。上述这段filterWapFinalPrice脚本是在视图元素绑定数据之后通过调用$function.filterWapFinalPrice来触发，Dynative框架会根据id找到这段脚本对应的函数对象。不过不管是哪一种事件，触发脚本执行的流程是一样的，首先在事件里定义好需要调用的函数，被调用的函数通过上述提到的id指定；然后定义好函数所需要的参数。Dynative框架在触发调用前，会先设置好参数，这些参数在脚本里最终可以通过$args开头的变量去引用。紧接着Dynative框架通过id查找函数，假如函数存在，那么就会让函数触发执行，执行的流程则会按照协议约定好的流程进行。

总之，由于只定义了脚本语言所需的基本元素，没有任何多余的内容，在运行时，也只需要协议解析，不需要做复杂的语法解析、词法解析等，因此，解析器实现比较简单，体积也非常小。另外，只有协议中定义了的脚本元素能被解析出来执行，避免了一些终端设备平台中的政策风险，也隔离了语言的安全风险。

实施例二

前述实施例一是从客户端的角度对本申请实施例提供的技术方案进行了介绍，对于服务器端而言，主要用于保存应用的界面数据，并在接收到展示请求时返回给客户端。该实施例二主要从服务器端的角度对本申请的技术方案进行介绍。

参见图2，该实施例二提供了一种应用界面渲染展示方法，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，该方法具体可以包括以下步骤：

S201：接收客户端发送的展示指定界面的请求；

S202：向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

该实施例二与前述实施例一相比，仅是描述角度上有所不同，具体的实现细节可以参见实施例一中的介绍，这里不再赘述。

与本申请实施例一提供的应用界面渲染方法相对应，本申请实施例还提供了一种应用界面渲染装置，其中，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，参见图3，该装置具体可以包括：

数据请求单元301，用于在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

脚本函数获取单元302，用于从所述界面数据中获取所述指定组件对应的脚本函数；

类型取值提取单元303，用于从所述脚本函数中提取各个基本元素的类型取值；

映射单元304，用于根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

函数调用单元305，用于当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

其中，所述基本元素包括用于表达运算/逻辑关系的元素，或函数，或语句。

具体实现时，该装置还可以包括：

判断单元，用于所述从所述脚本函数中提取各个基本元素的类型取值之后，判断所述类型取值是否为协议中已定义的，如果是，则触发针对该类型取值对应的脚本函数执行所述映射为当前终端设备中的原生API函数的步骤，否则，取消针对该类型取值对应的脚本函数的所述映射为当前终端设备中的原生API函数的步骤。

另外，该装置还可以包括：

解析结果保存单元，用于将所述脚本函数映射为当前终端设备中的原生API函数之后，将所述原生API函数保存到公共函数对象池中，并利用所述脚本函数在所述界面数据中的id标识该原生API函数，以便后续需要使用该脚本函数时，根据所述id到所述公共函数对象池中提取该脚本函数对应的原生API函数。

具体实现时，所述函数调用单元305具体可以包括：

第一调用子单元，用于在页面的视图元素初始化时，调用所述原生API函数，以便进行界面的展示。

或者，

第二调用子单元，用于在视图元素绑定数据时，调用所述原生API函数，以便进行界面的展示。

或者，

第三调用子单元，用于在视图元素被用户操作时，调用所述原生API函数，以便进行界面的展示。

与本申请实施例二提供的应用界面渲染方法相对应，本申请实施例还提供了一种应用界面渲染装置，其中，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，参见图4，该装置具体可以包括：

请求接收单元401，用于接收客户端发送的展示指定界面的请求；

数据返回单元402，用于向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

通过本申请实施例，由于只定义了脚本语言所需的基本元素，没有任何多余的内容，在运行时，也只需要协议解析，不需要做复杂的语法解析、词法解析等，因此，解析器实现比较简单，体积也非常小。另外，只有协议中定义了的脚本元素能被解析出来执行，避免了一些终端设备平台中的政策风险，也隔离了语言的安全风险。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的应用界面渲染展示方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (18)

1.一种应用界面渲染方法，其特征在于，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

从所述界面数据中获取所述指定组件对应的脚本函数；

从所述脚本函数中提取各个基本元素的类型取值；

根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前终端设备中的原生API函数之间的对应关系，将所述脚本函数映射为当前终端设备中的原生API函数；

当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示。

2.根据权利要求1所述的方法，其特征在于，所述基本元素包括用于表达运算/逻辑关系的元素，或函数，或语句。

3.根据权利要求1所述的方法，其特征在于，所述从所述脚本函数中提取各个基本元素的类型取值之后，还包括：

判断所述类型取值是否为协议中已定义的，如果是，则触发针对该类型取值对应的脚本函数执行所述映射为当前终端设备中的原生API函数的步骤，否则，取消针对该类型取值对应的脚本函数的所述映射为当前终端设备中的原生API函数的步骤。

4.根据权利要求1所述的方法，其特征在于，所述将所述脚本函数映射为当前终端设备中的原生API函数之后，还包括：

将所述原生API函数保存到公共函数对象池中，并利用所述脚本函数在所述界面数据中的id标识该原生API函数，以便后续需要使用该脚本函数时，根据所述id到所述公共函数对象池中提取该脚本函数对应的原生API函数。

5.根据权利要求1所述的方法，其特征在于，所述当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示，包括：

在页面的视图元素初始化时，调用所述原生API函数，以用于进行界面的展示。

6.根据权利要求1所述的方法，其特征在于，所述当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示，包括：

在视图元素绑定数据时，调用所述原生API函数，以用于进行界面的展示。

7.根据权利要求1所述的方法，其特征在于，所述当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示，包括：

在视图元素被用户操作时，调用所述原生API函数，以用于进行界面的展示。

8.根据权利要求1所述的方法，其特征在于，所述应用为移动终端设备中的App，所述当前终端设备为移动终端设备。

9.一种应用界面渲染方法，其特征在于，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

接收客户端发送的展示指定界面的请求；

向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

10.一种应用界面渲染装置，其特征在于，应用的界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述装置包括：

数据请求单元，用于在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；

脚本函数获取单元，用于从所述界面数据中获取所述指定组件对应的脚本函数；

类型取值提取单元，用于从所述脚本函数中提取各个基本元素的类型取值；

映射单元，用于根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

函数调用单元，用于当所述动态脚本的执行事件被触发时，调用所述原生API函数，以用于进行界面的展示。

11.根据权利要求10所述的装置，其特征在于，所述基本元素包括用于表达运算/逻辑关系的元素，或函数，或语句。

12.根据权利要求10所述的装置，其特征在于，还包括：

判断单元，用于所述从所述脚本函数中提取各个基本元素的类型取值之后，判断所述类型取值是否为协议中已定义的，如果是，则触发针对该类型取值对应的脚本函数执行所述映射为当前终端设备中的原生API函数的步骤，否则，取消针对该类型取值对应的脚本函数的所述映射为当前终端设备中的原生API函数的步骤。

13.根据权利要求10所述的装置，其特征在于，还包括：

解析结果保存单元，用于将所述脚本函数映射为当前终端设备中的原生API函数之后，将所述原生API函数保存到公共函数对象池中，并利用所述脚本函数在所述界面数据中的id标识该原生API函数，以便后续需要使用该脚本函数时，根据所述id到所述公共函数对象池中提取该脚本函数对应的原生API函数。

14.根据权利要求10所述的装置，其特征在于，所述函数调用单元包括：

第一调用子单元，用于在页面的视图元素初始化时，调用所述原生API函数，以用于进行界面的展示。

15.根据权利要求10所述的装置，其特征在于，所述函数调用单元包括：

第二调用子单元，用于在视图元素绑定数据时，调用所述原生API函数，以用于进行界面的展示。

16.根据权利要求10所述的装置，其特征在于，所述函数调用单元包括：

第三调用子单元，用于在视图元素被用户操作时，调用所述原生API函数，以用于进行界面的展示。

17.根据权利要求10所述的装置，其特征在于，所述应用为移动终端设备中的App，所述当前终端设备为移动终端设备。

18.一种应用界面渲染装置，其特征在于，应用的服务器端保存有应用的界面数据，所述界面数据中包括利用预置的脚本函数为指定组件定义的动态数据内容，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述方法包括：

请求接收单元，用于接收客户端发送的展示指定界面的请求；

数据返回单元，用于向所述客户端返回所述指定界面的界面数据，以便所述客户端从所述界面数据中获取所述指定组件对应的脚本函数，并从所述脚本函数中提取各个基本元素的类型取值，根据提取出的各个基本元素的类型取值，以及预先保存的脚本函数中定义的基本元素的类型取值与当前移动终端中的原生API函数之间的对应关系，将所述脚本函数映射为当前移动终端中的原生API函数，当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。