CN105354013B

CN105354013B - 应用界面渲染方法及装置

Info

Publication number: CN105354013B
Application number: CN201410406745.8A
Authority: CN
Inventors: 康彬; 洪小龙; 高嘉峻; 黄金涌; 张津; 倪顺坚; 徐焕杰
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2014-08-18
Filing date: 2014-08-18
Publication date: 2019-07-23
Anticipated expiration: 2034-08-18
Also published as: CN105354013A

Abstract

本申请公开了应用界面渲染方法及装置，应用的客户端中设有SDK包，所述SDK包中包括一渲染引擎，所述渲染装置中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，所述方法包括，通过所述渲染引擎完成以下操作：在接收到展示所述应用的指定界面的请求时，向服务器请求该应用的所述指定界面的界面数据；接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息；根据所述第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件；对所述原生组件进行渲染。通过本申请，可以让用户更为及时地使用到App的最新功能，同时又避免hybird方案的各种缺陷。

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方案的各种缺陷，是迫切需要本领域技术人员解决的技术问题。

发明内容

本申请提供了应用界面渲染方法及装置，可以让用户更为及时地使用到App的最新功能，同时又避免hybird方案的各种缺陷。

本申请提供了如下方案：

一种应用界面渲染方法，应用的客户端中设有SDK包，所述SDK包中包括一渲染引擎，所述渲染引擎中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，所述方法包括，通过所述渲染引擎完成以下操作：

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

接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息；

根据所述第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件；

对所述原生组件进行渲染，以用于展示所述指定界面。

一种应用界面渲染方法，其特征在于，包括：

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

向所述客户端返回所述指定界面的界面数据，以便所述客户端中集成的SDK包中包含的渲染引擎接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息，根据预先保存的第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件，并对所述原生组件进行渲染，以用于展示所述指定界面；其中，所述应用的界面数据保存在应用的服务器端，所述第一对应关系为界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系。

一种应用界面渲染装置，所述装置中设有SDK包，所述SDK包中包括所述渲染引擎，所述渲染引擎中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，所述渲染引擎包括：

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

数据解析单元，用于接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息；

组件映射单元，用于根据所述第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件；

渲染单元，用于对所述原生组件进行渲染，以用于展示所述指定界面。

一种应用界面渲染装置，其特征在于，包括：

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

数据返回单元，用于向所述客户端返回所述指定界面的界面数据，以便所述客户端中集成的SDK包中包含的渲染引擎接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息，根据预先保存的第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件，并对所述原生组件进行渲染，以用于展示所述指定界面；其中，所述应用的界面数据保存在应用的服务器端，所述第一对应关系为界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系。

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

通过本申请实施例，由于Dynative可以将界面数据中定义的组件直接映射成移动终端中的原生组件，因此，可以直接调用移动终端设备中的原生代码对界面进行渲染，而不再依赖于浏览器的Webkit内核以及Webview，也就是说，使用JSON等数据格式编写的界面数据，可以像移动终端中的原生应用一样在中被执行，因此，对于使用移动终端中的各种新功能等都具有良好的适应性，可以让用户更为及时地使用到App的最新功能，同时又避免hybird方案的各种缺陷。

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

附图说明

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

图1是本申请实施例提供的一界面示意图；

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

图3-1是本申请实施例提供的逻辑树结构示意图；

图3-2是本申请实施例提供的一物理树结构示意图；

图3-3是本申请实施例提供的另一物理树结构示意图；

图4是Hybird方案中的界面代码示意图；

图5是Hybird方案中的另一界面代码示意图

图6是Hybird***结构示意图；

图7是本申请实施例提供的方案中的界面代码的示意图；

图8是本申请实施例提供的***结构示意图；

图9是本申请实施例提供的另一方法流程图；

图10是本申请实施例提供的渲染装置示意图；

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

具体实施方式

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

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

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

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

表1

属性

类型

名称

是否必选

Type

String

Image

Y

输入列表如表2所示：

表2

这样，开发人员在编写自己的界面数据时，就可以按照上述协议来定义自己需要的图片组件，例如，在某个例子中，代码可以如下：

可见，在上述界面数据代码中，定义了type为“image”的组件，这样，Dynative就会根据该类型名称信息，将其识别为一个图片组件，后续就可以将其映射为具体的移动终端中的原生组件。当然，上述图片组件中还通过引用jump脚本函数的形式定义了动态交互信息，Dynative还可以将脚本函数映射成具体移动终端中的原生API函数，并进行调用，关于此，后续会有详细的介绍。

又如，协议中还定义了文本组件，其中，关于类型说明如以下表3所示：

表3

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

输入列表如以下表4所示：

表2

可见，在上述界面数据代码中，定义了type为“text”的组件，这样，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脚本协议定义的动态脚本。

关于界面布局数据以及静态数据内容都可以看作是界面布局样式数据，因此，可以根据实际需要选用各种界面描述语言(例如xml、json、html、xhtml、html5等等)进行描述，而关于动态脚本数据，则可以根据需要选用各种脚本语言(例如JavaScript、lua、json等等)描述交互逻辑。例如，在dynative实现方式下，客户端与服务器端之间交互的所有数据(包括界面布局样式数据和交互脚本数据)都可以采用json格式组织。

另外，为了便于进行数据的更新，界面布局数据与内容数据可以进行独立定义以及保存。当然，为了便于后续解析时，将为同一个组件定义的界面布局数据以及内容数据关联到同一个组件上，在编写界面数据时，还可以定义组件id，同一组件具有相同的id。这样，当后续新版本中，如果仅需要更新某部分内容数据，则界面布局数据可以不变，直接对这部分内容数据进行更新即可，如果需要更新某部分界面布局数据，则也是只需要更新这部分界面布局数据即可，内容数据可以不变，这样，可以避免造成对界面数据的大幅度修改，降低版本升级、更新等工作的工作量。

通过以上所述可见，在具体实现时，为了让Dynative能完整解析界面各种数据，服务器端下发的界面数据需要包含传统native界面开发时需要的所有信息，主要包括界面布局信息和界面数据内容信息，数据内容信息还包括静态信息以及动态逻辑信息。例如，在某一具体实现的例子中，Dynative服务端下发的数据结构可以如下所示：

其中，layout中存放了整个界面的布局信息，用来描述该界面中包括哪些组件，各个组件在界面中的位置、尺寸等，Dynative解析器可以将该部分数据解析映射成各个移动的真实界面元素。

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

Context中存放了界面静态数据，如果某组件展示的数据不需要另外调网络接口获取，就可以直接将静态数据存放在这里，Dynative在使用界面数据时会从这里取。

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

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

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

需要说明的是，本申请实施例中所述的组件可以包括原子组件以及容器组件两种。其中，所谓的原子组件是指最小的组件，一般用来展现某种特定形式的内容，如文本组件用来显示文本信息，图片组件用来展现图片等；所谓容器组件是用来管理组件的一种特殊组件，对其管理的所有子组件的生命周期负责，包括解析、布局、绘制等等。为了解决布局定义复用的问题，在本申请实施例中，还可以允许开发者在界面数据中定义复合组件，所谓复合组件是使用原子组件和容器组件拼装成的各种组件，一般跟实际业务紧密联系。在实际应用中，只要定义出一个复合组件，界面中任何地方都可以引用，而不需要在各个地方重复定义相同的界面布局。

例如，在实际应用的例子中，复合组件可以是通过lib进行定义，具体的数据结构可以如下所示：

在以上实例中，定义了一个名为fourfoldimage的复合组件，该复合组件的功能是，每行显示两个原子组件，并在第8行至第13行定义了第一个原子组件的类型等，在第14至第19行定义了第二个原子组件的类型，两种均为图片组件；因此，在layout中就可以使用该复合组件，其中，在第31行以及第45行各使用了一次该复合组件，并指定具体显示的图片地址，最终的显示效果可以如图1所示。

需要说明的是，在存在复合组件的情况下，服务器端下发的界面数据的完整数据结构可以如下：

另外，关于前文介绍的文本组件、图片组件等都属于***组件(包括原子组件和容器组件)，在定义这些组件时，都需要指定其type类型名称，例如，在前述例子中的第5行、第10行都分别指定了type名称信息。但是，在使用复合组件时，为了与原子组件进行区分，使用了ref作为关键字，如前述例子中的第31行以及第45行。对于Dynative解析器而言，在对界面数据信息解析时，如果发现type关键字，则可以确定其定义了一个***组件(包括原子组件和容器组件)，如果发现ref关键字，则确定其使用了一个复合组件，然后根据ref后的复合组件名称，到libs中找到对应的复合组件信息，并根据复合组件信息中定义的原子组件信息，进行后续向原生组件的映射等操作。

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

因此，具体实现时，可以为移动终端App的开发者提供SDK包，这种SDK包中可以包括Dynative渲染引擎(该引擎是的处理逻辑可以是与无关的)，以及界面数据中的组件信息与终端设备中的原生组件之间的对应关系、界面数据中存在动态脚本的情况下，还包括脚本中定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关系(上述两种对应关系信息是与相关的，例如，同样的功能在不同的中会对应不同的原生组件)。换而言之，该渲染引擎的主要作用就是，根据SDK中保存的对应关系，将界面数据中定义的组件信息，映射中当前移动终端中的原生组件，将界面数据中定义的动态脚本映射成当前移动终端中的原生API函数，并调用当前移动终端中的原生代码，对原生组件进行渲染展示。也就是说，相对于webkit而言，Dynative是一种轻量级的渲染引擎，主要起到了界面数据与原生代码之间的中介作用，不再需要Webview的中转。

如前文所述，上述两种对应关系是与相关的，例如，同样是文本组件，在Android中，对应的原生组件是textview，而在iOS中，对应的原生组件是lable，等等。因此，为了实现正确的转换，可以分别针对不同的移动终端提供不同的SDK包，在不同的SDK包中，前述对应关系是不同的。例如，对于Android而言，界面数据中的组件信息与终端设备中的原生组件之间的对应关系可以如表5所示：

表5

协议中定义的组件类型名称

原生组件

text	TextView
		Image	ImageView
list	ListView
		……	……

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

表6

协议中定义的组件类型名称	原生组件
		Text	UILable
Image	UIImageView
		list	UITableView
……	……

对于Android而言，界面数据中的动态脚本定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关系，可以如表7所示：

表7

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

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

表8

基本元素的类型取值

原生API函数

tips	UIAlertView
		alert	UIActionSheet
……	……

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

其中，为了能够直接调用移动终端中的原生代码，在为某移动终端开发SDK包时，SDK包可以是使用该移动终端设备中原生应用所使用的编码语言进行开发的。例如，对于iOS而言，其原生App一般是用ObjectC语言开发的，则为iOS提供的SDK包也可以用ObjectC语言开发，而Android的原生App一般是用Java语言开发的，因此，为Android提供的SDK包也可以是用Java语言进行开发。总之，对于为不同移动终端开发的SDK包而言，各自使用的语言可能是不同的，各自保存的组件信息与原生组件之间的对应关系也可能不同，但Dynative内核的实现逻辑是相同的。

这样，App开发者可以按照一定的格式编写App的界面数据，但是，不需要将这种界面数据代码打包到安装包中，而是仅保存在服务器中即可。在需要将其App发布到某具体的移动终端中时，可以将本申请实施例为该移动终端开发的SDK包集成到App的客户端安装包中。例如，在向Android发布时，可以将Android对应的SDK包集成到App中，在向iOS发布时，可以将iOS对应的SDK包集成到App中，等等。当然，对应不同的，在服务器中只需要保存同一份界面数据即可，相应的，不同的SDK包中的Dynative内核，可以按照各自保存的对应关系，进行从界面数据到原生组件、原生API函数的映射，并且Dynative内核还可以直接进行与进行交互，调用中的原生代码，直接进行原生组件的渲染展现，而不需要经过类似webview的中转，实现起来更加方便灵活。

可见，在本申请实施例中，对于移动终端App而言，由于所有的界面数据都是仅保存在服务器端，因此，在需要进行App的升级、bug修复等操作时，直接对服务器保存的界面数据进行修改即可，不必再向终端设备下发升级信息等，因此，可以使得用户更及时的使用到更新后的版本。另一方面，由于客户端中集成了本申请实施例的SDK包，其中的Dynative内核是使用与原生应用相同的语言开发的，因此，既可以将界面数据映射成中的原生组件，还可以直接调用的原生代码实现对原生组件的渲染展示，因此，不再需要依赖于浏览器的webkit内核，也不再需要通过webview进行中转，所以，可以更加灵活方便的访问本地的各种服务和资源，包括本地文件***或网络跨域等，例如，如果某应用需要调用移动终端设备中的相机功能，则可能直接在界面数据中进行定义，Dynative内核可以将其映射成中的API，并利用该API进行调用，等等。另外，还可以顺畅的使用移动终端上的各种特性，包括传感器技术等。

下面对Dynative进行界面展现过程中的具体实现方式进行详细地介绍。

实施例一

参见图2，本申请实施例一首先提供了一种应用界面渲染方法，该实施例一主要从客户端的角度对本申请实施例的方案进行介绍。其中，开发者为提供的应用的界面数据保存在服务器中，应用的客户端中设有SDK包，在优选的实现方式下，所述SDK包可以是使用当前移动终端设备中原生应用所使用的编码语言进行开发的，该SDK包中包括一渲染引擎，以及界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系，具体的，该方法可以通过该渲染引擎完成以下步骤：

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

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

S202：接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息；

由于用json等语言定义的界面数据无法直接被终端设备识别，因此，在接收到服务器返回的界面数据之后，Dynative内核就可以对该界面数据进行解析，并且可以直接映射成当前终端设备中的原生组件。也就是说，Dynative内核的主要作用就是将用json等语言描述的界面数据中定义的组件，转换成移动终端中的原生组件，以便进行界面的渲染展示。为了完成该转换，可以首先对界面数据进行解析，获得其中定义的各个组件的组件信息。例如，具体的组件信息可以是指组件的类型名称信息，具体可以包括前文所述的text、image等类型名称。

S203：根据对应关系，将所述界面数据中定义的组件信息映射成当前终端设备中的原生组件；

具体在进行映射时，Dynative内核可以首先根据界面数据中各组件的类型名称信息，将界面数据中定义的组件转换为native层的逻辑组件，换而言之，也就是从界面数据中提取出各个组件的类型名称，每个类型名称对应一个逻辑组件；并且，由于SDK包中预先还保存了组件类型名称与移动终端中的原生组件之间的对应关系，因此，可以利用这种对应关系将逻辑组件转换为移动终端中的原生组件。例如，当解析出界面数据中包含类型名称为text的组件时，如果当前所在的移动终端为Android，则根据表5，可以将该组件映射为textview组件，如果当前所在的移动终端为iOS，则根据表6，可以将该组件映射为lable组件。

S204：调用当前终端设备的原生代码对所述原生组件进行渲染，以用于展示所述指定界面。

在将逻辑组件转换成当前终端设备中的原生组件之后，就可以对这种原生组件进行渲染，由于原生组件是用户界面的组成构件，因此，展现出原生组件之后，就可以展示出对一个的指定界面。

具体在进行界面展示时，可以首先根据界面数据中各组件的类型名称以及各自之间的嵌套关系等信息，生成逻辑树。所述逻辑树包括多个第一节点，每个第一节点对应一个使用界面描述语言定义的组件信息，主要用来存储界面中各组件的静态内容数据，并供脚本函数等信息。另外，每个第一节点的信息还可以包括界面布局数据中定义的坐标信息。也即，可以将服务器返回的界面数据用树形数据结构进行表示，逻辑树中包含了整个界面所有的信息，包括样式、布局、交互脚本等等。之后，可以根据每个第一节点的信息，对逻辑树进行排版布局，确定出各第一节点在屏幕上显示时的坐标；再之后，就可以遍历逻辑树中的各个第一节点，并根据各第一节点的信息，以及各个逻辑组件与原生组件之间的对应关系，将逻辑树转换为物理树。所述物理树包括多个第二节点，每个第二节点对应一个原生组件，每个第二节点的信息包括在屏幕上显示时的坐标信息以及内容信息。最后就可以将物理树上的各个第二节点绘制到屏幕上。其中，第二节点与第一节点一一对应，脚本函数只能操作第一节点，第一节点会将脚本函数的操作结果透传到对应的第二节点，并最终展现在屏幕上。

例如，假设某界面数据中的某段代码为：

其中定义了两个文本组件，分别为txt1和txt2，则对应生成的逻辑树如图3-1所示，如果是在Android***中，转换成物理树之后，如图3-2所示，如果是在iOS***中，转换成物理树之后，如图3-3所示。

如果界面布局数据与内容数据独立定义，则具体在生成逻辑树时，可以首先对界面布局数据(也即前述layout数据)进行解析，确定逻辑树中的各第一节点，以及各个第一节点的坐标信息，当然，同时还可以确定出各个第一节点对应的组件id，然后，根据组件id到前述Content数据以及function数据中查找各个组件的内容数据，并绑定到对应的第一节点上，生成逻辑树。

如前文所述，界面数据中为各个组件定义的内容数据，包括静态内容数据以及动态内容数据，其中，在生成逻辑树时，对于静态内容而言，可以直接从服务器端返回的界面数据中进行提取，对于动态内容而言，可以通过界面数据中的动态脚本函数来获取。

其中，如果某界面数据中仅包括静态内容数据，则Dynative的处理流程可以为：

步骤1：解析layout数据，提取出其中定义的各个组件的类型名称，确定出各个逻辑节点的名称，并根据layout数据中的嵌套关系，确定出各个逻辑节点之间的父子关系，进而生成逻辑树(相当于html中的dom树)；

步骤2：遍历逻辑树，并将对应Content中的数据绑定到逻辑树上，此时逻辑树上信息才完整；

步骤3：根据各节点中的坐标信息和内容信息，对逻辑树进行排版布局；

步骤4：遍历逻辑树，根据表5或是表6中保存的对应关系，将界面数据中定义的组件映射为具体终端设备中的原生组件，生成对应的物理节点，这样物理树生成(相当于html中的render树)；

步骤5：将物理树上各节点绘制到屏幕上。

如果某界面数据中除了静态内容数据，还包括动态内容数据，并且这部分动态数据对应的脚本需要在视图初始化时就触发，则Dynative的处理流程可以为：

步骤1：解析layout数据,生成逻辑树(对应前述步骤1以及步骤2)；

步骤2：根据逻辑树中的信息，对逻辑树进行初步布局；

步骤3：遍历逻辑树，根据各第一节点中的信息，生成对应的第二节点，创建出对应的物理树；

通过前三步生成的逻辑树中，包含了界面数据中定义的全部组件，只是其中部分组件还没有绑定数据，只确定出了坐标、尺寸等布局信息；

步骤4：根据表7或表8中保存的对应关系，将界面数据中定义的脚本函数映射为移动终端中原生API函数，并通过调用该API函数获取动态组件对应的内容数据；

步骤5：将获取到的内容数据绑定到逻辑树对应的第一节点上；

步骤6：根据补充过数据的逻辑树中的信息，再一次重新对逻辑树布局；

步骤7：将逻辑树中的更新信息同步对物理树中；

步骤8：将物理树上各第二节点绘制到屏幕上。

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

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

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

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

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

以上对本申请实施例提供的Dynative框架进行了详细的介绍，为了更好的体现出其相对于Hybird框架的优点，下面通过一个实际应用中的例子来进行介绍。

为了实现某功能，在Hybird框架下，需要准备两套代码，其中一套为HTML代码，如图4所示，另一套为Java代码，如图5所示。在运行时，需要两套代码的相互配合。例如，图4的第5行以及第10行，用HTML语言定义了两个函数，分别为javacalljs()和javacalljswithargs(arg)，如果要加载这两个函数，则需要通过Java代码来完成，参见图5中的第38行以及第40行，在Java代码中，需要调用webview的loadUrl方法来加载这两个函数，并且在此之前的第38行，还需要将java代码注册到Webview中。可见，对于Hybird框架而言，其架构如图6所示，使用HTML编写的代码，需要通过JavaScript、Webview的中转才能到达的native层完成代码的执行。

而为了实现相同的功能，利用本申请实施例提供的方案，则只需要准备一套代码(例如，JSON格式的数据)，如图7所示，其中不存在到Webview中进行注册，以及调用Webview中的方法等过程，在运行时，Dynative内核就可以识别出其中定义的组件，并映射为移动终端中的原生组件，之后通过调用原生代码，就可以实现对界面的展现。可见，对于Dynative框架而言，其架构图如图8所示，使用JSON等编写的界面数据保存在服务器端，客户端从服务器端读取界面数据，之后，Dynative core就可以直接将其映射为Native层的原生组件、原生API函数等，进而就可以在移动终端中运行，并在屏幕上展示。

总之，通过本申请实施例，不再依赖于浏览器的Webkit内核以及Webview，使用JSON等数据格式编写的界面数据，可以像移动终端中的原生应用一样在中被执行，因此，对于使用移动终端中的各种新功能等都具有良好的适应性。

最后需要说明的是，本申请实施例中所述的应用可以为移动终端设备中的App，相应的，所谓的当前终端设备可以为移动终端设备。

实施例二

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

参见图9，该实施例二提供了一种应用界面渲染展示方法，在应用的服务器端保存有所述应用的界面数据，该方法具体可以包括以下步骤：

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

S902：向所述客户端返回所述指定界面的界面数据，以便所述客户端中设有的SDK包中包含的渲染引擎接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息，根据预先保存的第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件，并对所述原生组件进行渲染，以用于展示所述指定界面；其中，所述第一对应关系为界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系。

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

与本申请实施例一提供的应用界面渲染方法相对应，本申请实施例还提供了一种渲染装置，其中，应用的客户端中设有SDK包，所述SDK包中包括所述渲染装置，所述渲染引擎中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，参见图10，所述渲染装置包括：

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

数据解析单元1002，用于接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息；

组件映射单元1003，用于根据所述第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件；

渲染单元1004，用于对所述原生组件进行渲染，以用于展示所述指定界面。

其中，所述界面数据中包括各个组件的类型名称信息，所述数据解析单元1002具体用于：

通过对所述界面数据进行解析，从所述界面数据中提取各个组件的类型名称信息，根据名称类型信息将所述界面数据中定义的组件信息转化为逻辑组件；

相应的，所述组件映射单元1003具体可以用于

根据所述第一对应关系，将所述逻辑组件映射为当前终端设备中的原生组件。

此时，渲染单元1004具体可以包括：

逻辑树生成子单元，用于根据所述逻辑组件以及各个逻辑组件在所述界面数据中的嵌套关系生成逻辑树，所述逻辑树包括多个第一节点，每个第一节点对应一个所述逻辑组件，每个第一节点的信息包括所述界面数据中为对应的组件定义的布局信息以及数据内容信息；

物理树生成子单元，用于遍历逻辑树中的各个节点，根据各个逻辑组件对应的原生组件，将所述逻辑树转换为物理树；所述物理树包括多个第二节点，每个第二节点对应一个所述原生组件，每个第二节点的信息包括在屏幕上显示时的布局信息以及数据内容信息；

绘制子单元，用于将物理树上的各个第二节点绘制到屏幕上。

其中，所述界面数据中包括各个组件的布局数据以及各个组件的内容数据，同一组件对应相同的组件id；所述逻辑树生成子单元可以包括：

节点确定子单元，用于对所述布局数据进行解析，确定逻辑树中的各节点，以及各个节点对应的组件的布局信息、组件id以及节点间的父子关系信息；

数据绑定子单元，用于根据各节点对应的组件id，以及界面数据中为各个组件id定义的内容数据获取各组件的内容数据，并绑定到对应的节点上，生成逻辑树。

如果界面数据中为某组件定义的内容数据为静态内容数据，则所述数据绑定子单元具体可以用于：

根据各节点对应的组件id，从所述内容数据中提取该组件的内容数据。

另外，所述渲染装置中还可以保存有动态脚本中定义的基本元素与移动终端中的原生API函数之间的第二对应关系，每个基本元素包括至少一个类型取值，此时，如果界面数据中为某组件定义的内容数据为动态数据，所述数据绑定子单元具体可以包括：

脚本获取子单元，用于根据各逻辑节点中包含的脚本函数id，从所述内容数据中获取该组件对应的动态脚本；

基本元素类型取值获取子单元，用于从所述动态脚本中提取各个基本元素的类型取值；

函数映射子单元，用于根据所提取出的各个基本元素的类型取值，以及所述第二对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

函数调用子单元，用于通过调用所述原生API函数获取该组件的内容数据。

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

具体实现时，所述组件可以包括原子组件以及复合组件，此时，可以预先为使用原子组件设定第一关键词，为使用复合组件设定第二关键字，所述数据解析单元1002具体可以包括：

原子组件信息获取子单元，用于通过第一关键字，获取原子组件的组件信息；

复合组件信息获取子单元，用于通过第二关键词，确定对应的组件为复合组件，并根据所述第二关键词引用的复合组件名称，到复合组件信息中查找该复合组件包括的原子组件，并获取该原子组件的组件信息。

在优选的实现方式下，所述SDK包使用当前移动终端设备平台中原生应用所使用的编码语言进行开发。

与本申请实施例二提供的应用界面渲染方法相对应，本申请实施例还提供了一种应用界面渲染装置，参见图11，该装置具体可以包括：

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

数据返回单元1102，用于向所述客户端返回所述指定界面的界面数据，以便所述客户端中设有的SDK包中包含的渲染引擎接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面数据中定义的组件信息，根据预先保存的第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件，并对所述原生组件进行渲染，以用于展示所述指定界面；其中，所述第一对应关系为界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系，其中，应用的界面数据保存在应用的服务器端。

总之，通过本申请实施例，由于Dynative可以将界面数据中定义的组件直接映射成移动终端中的原生组件，因此，可以直接调用移动终端设备中的原生代码对界面进行渲染，而不再依赖于浏览器的Webkit内核以及Webview，也就是说，使用JSON等数据格式编写的界面数据，可以像移动终端中的原生应用一样在中被执行，因此，对于使用移动终端中的各种新功能等都具有良好的适应性。

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

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

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

Claims

1.一种应用界面渲染方法，其特征在于，应用的客户端中设有SDK包，所述SDK包中包括一渲染引擎，所述渲染引擎中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，所述方法包括，通过所述渲染引擎完成以下操作：

对所述原生组件进行渲染，以用于展示所述指定界面。

2.根据权利要求1所述的方法，其特征在于，所述界面数据中包括各个组件的类型名称信息，所述获得所述界面数据中定义的组件信息，包括：

所述根据所述第一对应关系，将所述界面数据中定义的组件信息映射为当前终端设备中的原生组件，包括：

3.根据权利要求2所述的方法，其特征在于，所述对所述原生组件进行渲染，包括：

根据所述逻辑组件以及各个逻辑组件在所述界面数据中的嵌套关系生成逻辑树，所述逻辑树包括多个第一节点，每个第一节点对应一个所述逻辑组件，每个第一节点的信息包括所述界面数据中为对应的组件定义的布局信息以及数据内容信息；

遍历逻辑树中的各个节点，根据各个逻辑组件对应的原生组件，将所述逻辑树转换为物理树；所述物理树包括多个第二节点，每个第二节点对应一个所述原生组件，每个第二节点的信息包括在屏幕上显示时的布局信息以及数据内容信息；

将物理树上的各个第二节点绘制到屏幕上。

4.根据权利要求3所述的方法，其特征在于，所述界面数据中包括各个组件的布局数据以及各个组件的内容数据，同一组件对应相同的组件id；所述根据所述逻辑组件以及各个逻辑组件在所述界面数据中的嵌套关系生成逻辑树，包括：

对所述布局数据进行解析，确定逻辑树中的各第一节点，以及各个第一节点对应的组件的布局信息、组件id以及第一节点间的父子关系信息；

根据各第一节点对应的组件id，以及界面数据中为各个组件id定义的内容数据获取各组件的内容数据，并绑定到对应的节点上，生成逻辑树。

5.根据权利要求4所述的方法，其特征在于，如果界面数据中为某组件定义的内容数据为静态内容数据，则所述根据各第一节点对应的组件id，以及界面数据中为各个组件id定义的内容数据获取各组件的内容数据，包括：

根据各第一节点对应的组件id，从所述内容数据中提取该组件的内容数据。

6.根据权利要求4所述的方法，其特征在于，所述界面数据中包括利用预置的脚本函数为某组件定义的动态内容数据，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述渲染引擎中还保存有脚本函数中定义的基本元素的类型取值与移动终端中的原生API函数之间的第二对应关系；所述根据各第一节点对应的组件id，以及界面数据中为各个组件id定义的内容数据获取各组件的内容数据，包括：

根据各第一节点对应的组件id，从所述内容数据中获取该组件对应的动态脚本；

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

根据所提取出的各个基本元素的类型取值，以及所述第二对应关系，将所述脚本函数映射为当前移动终端中的原生API函数；

将所述原生API函数确定为该组件的内容数据，以便当所述动态脚本的执行事件被触发时，通过调用所述原生API函数进行界面的展示。

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

8.根据权利要求1至7任一项所述的方法，其特征在于，所述组件包括原子组件以及复合组件，预先为使用原子组件设定第一关键字，为使用复合组件设定第二关键字，所述获得所述界面数据中定义的组件信息，包括：

通过第一关键字，获取原子组件的组件信息；

通过第二关键字，确定对应的组件为复合组件，并根据所述第二关键字引用的复合组件名称，到复合组件信息中查找该复合组件包括的原子组件，并获取该原子组件的组件信息。

9.根据权利要求1至7任一项所述的方法，其特征在于，所述SDK包使用当前移动终端设备平台中原生应用所使用的编码语言进行开发。

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

11.一种应用界面渲染方法，其特征在于，包括：

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

12.一种应用界面渲染装置，其特征在于，所述装置中设有SDK包，所述SDK包中包括渲染引擎，所述渲染引擎中保存有界面数据中定义的组件信息与当前终端设备中的原生组件之间的第一对应关系，所述渲染引擎包括：

13.根据权利要求12所述的装置，其特征在于，所述界面数据中包括各个组件的类型名称信息，所述数据解析单元具体用于：

所述组件映射单元具体用于

14.根据权利要求13所述的装置，其特征在于，所述渲染单元包括：

15.根据权利要求14所述的装置，其特征在于，所述界面数据中包括各个组件的布局数据以及各个组件的内容数据，同一组件对应相同的组件id；所述逻辑树生成子单元包括：

16.根据权利要求15所述的装置，其特征在于，如果界面数据中为某组件定义的内容数据为静态内容数据，则所述数据绑定子单元具体用于：

17.根据权利要求15所述的装置，其特征在于，所述界面数据中包括利用预置的脚本函数为某组件定义的动态内容数据，所述预置的脚本函数通过至少一个基本元素表达，每个基本元素包括至少一个类型取值，所述渲染引擎中还保存有脚本函数中定义的基本元素的类型取值与移动终端中的原生API函数之间的第二对应关系；所述数据绑定子单元具体包括：

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

19.根据权利要求12至18任一项所述的装置，其特征在于，所述组件包括原子组件以及复合组件，预先为使用原子组件设定第一关键字，为使用复合组件设定第二关键字，所述数据解析单元具体包括：

复合组件信息获取子单元，用于通过第二关键字，确定对应的组件为复合组件，并根据所述第二关键字引用的复合组件名称，到复合组件信息中查找该复合组件包括的原子组件，并获取该原子组件的组件信息。

20.根据权利要求12至18任一项所述的装置，其特征在于，所述SDK包使用当前移动终端设备平台中原生应用所使用的编码语言进行开发。

21.根据权利要求12至18任一项所述的装置，其特征在于，所述应用为移动终端设备中的App，所述当前终端设备为移动终端设备。

22.一种应用界面渲染装置，其特征在于，包括：